Nearly all but the simplest of applications can benefit from the modularity features OSGi provides.
Common scenarios where OSGi can be helpful
- ClassNotFoundExceptions when starting your application because the class path wasn’t correct. OSGi can help by ensuring that code dependencies are satisfied before allowing the code to execute.
- Execution-time errors from your application due to the wrong version of a dependent library on the class path. OSGi verifies that the set of dependencies are consistent with respect to required versions and other constraints.
- Type inconsistencies when sharing classes among modules: put more concretely, the dreaded appearance of foo instanceof Foo == false. With OSGi, you don’t have to worry about the constraints implied by hierarchical class-loading schemes.
- Packaging an application as logically independent JAR files and deploying only those pieces you need for a given installation. This pretty much describes the purpose of OSGi.
- Packaging an application as logically independent JAR files, declaring which code is accessible from each JAR file, and having this visibility enforced. OSGi enables a new level of code visibility for JAR files that allows you to specify what is and what isn’t visible externally.
- Defining an extensibility mechanism for an application, like a plugin mechanism. OSGi modularity is particularly suited to providing a powerful extensibility mechanism, including support for execution-time dynamism.
The OSGi Service Platform is composed of two parts:
- OSGi framework
- OSGi standard services
The framework is the runtime that implements and provides OSGi functionality. The standard services define reusable APIs for
common tasks, such as Logging and Preferences.
If you use an IDE to do your Java development, it’s possible you already have experience with OSGi.
OSGi layered architecture
- Module layer—Concerned with packaging and sharing code.
- Lifecycle layer—Concerned with providing execution-time module management and access to the underlying OSGi framework
- Service layer—Concerned with interaction and communication among modules, specifically the components contained in them
General approach when creating an OSGi-based application
- Design your application by breaking it down into service interfaces (normal interface-based programming) and clients of those interfaces.
- Implement your service provider and client components using your preferred tools and practices.
- Package your service provider and client components into (usually) separate JAR files, augmenting each JAR file with the appropriate OSGi metadata.
- Start the OSGi framework.
- Install and start all your component JAR files from step 3.
-OSGi in Action
No comments:
Post a Comment