This chapter is from the book
This chapter is from the book
This chapter is from the book
2.2 Why OSGi?
If OSGi is so small and simple, what makes it so special? To understand more, let's first look at a traditional Java application. A Java system is composed of types—classes and interfaces. Each type has a set of members—methods and fields—and is organized into packages. The set of Java packages defines a global type namespace, and the Java language defines the visibility rules used to manage the interactions between types and members. As shown in Figure 2-2, types and packages are typically built and shipped as Java Archives (JARs). JARs are then collected together on one classpath that is linearly searched by the Java virtual machine (JVM) to discover and load classes.
)
Figure 2-2 A Java application
So far it sounds pretty good—packages feel modular and there are visibility rules to enable information hiding. At the low level the story is reasonable, but things break down at the system and collaboration level. There are two main issues: Packages are too granular to be modules, and JARs are simply a delivery mechanism with no runtime semantics.
The Java type and member visibility rules allow developers to hide elements within a package, so it feels natural to say that packages == modules. In practice this forces either packages to be too large or modules to be too numerous. Experience tells us that modules are often themselves composed of code from various sources and that it is a best practice to use fine-grained package naming to enable later refactoring. Mixing packages with modularity is counter to both experiences.
The JAR concept is very useful. It could be argued that the JAR as a delivery vehicle was one of the drivers of the original success of Java. Producers create JARs of useful function, and consumers use these JARs to build systems. Unfortunately, JARs really are just a delivery vehicle and have minimal impact on the running of the system. Delivered JARs simply go on a flat classpath with no control over the accessibility of their contents.
Combined, these characteristics mean that Java has no support for defining or enforcing dependencies. Without dependencies, modularity is not possible. You end up with systems where JARs fight for position on the classpath, JAR content has more to do with who wrote the code rather than its functionality, APIs are unclear, and the relationships between JARs are at best managed by weak conventions. As shown in Figure 2-3, the net result is monolithic applications composed of tightly coupled JARs with multidirectional and even cyclical dependencies. Collaboration and sharing between teams is impacted and application evolution hindered.
)
Figure 2-3 A monolithic application
OK, so what makes OSGi better? It's still Java, right? True. OSGi builds on the basic Java mechanisms just outlined but adds a few key elements. In particular, rather than talking about JARs, OSGi talks about bundles. A bundle is typically implemented as a JAR, but with added identity and dependency information; that is, bundles are self-describing JARs. This simple idea has two effects: Producers and consumers have an opportunity to express their side of the contract, and the runtime has the information it needs to enforce these expectations.
By default the packages in a bundle are hidden from other bundles. Packages containing API must, by definition, be available to other bundles and so must be explicitly exported. Bundles including code that uses this API must then have a matching import. This visibility management is similar in concept to Java's package visibility but at a much more manageable and flexible level.
The OSGi runtime enforces these visibility constraints, thus forming the basis of a strong but loosely coupled module system. Importing a package simply states that the consuming bundle depends on the specified package, regardless of the bundles that provide it. At runtime a bundle's package dependencies are resolved and bundles are wired together, based on rules that include package names, versions, and matching attributes. This approach effectively eliminates the classpath hell problem while simultaneously providing significant class loading performance improvements and decreased coupling.
No code is an island. All this loose coupling comes at a price. In a traditional Java system, if you wanted to use some functionality, you would simply reference the required types. The tightly coupled approach is simple but limiting. In a scenario that demands more flexibility this is not possible. The Java community is littered with ad hoc and partial solutions to this: Context class loaders, Class.forName, "services" lookup, log appenders—all are examples of mechanisms put in place to enable collaboration between loosely coupled elements.
While the importing and exporting of packages express static contracts, services are used to facilitate dynamic collaboration. A service is simply an object that implements a contract, a type, and is registered with the OSGi service registry. Bundles looking to use a service need only import the package defining the contract and discover the service implementation in the service registry. Note that the consuming bundle does not know the implementation type or producing bundle since the service interface and implementation may come from different bundles—the system is collaborative yet remains loosely coupled.
Services are dynamic in nature: A bundle dynamically registers and unregisters services that it provides, and it dynamically acquires and releases the services that it consumes. Some bundles are service providers, some are service consumers, and others are both providers and consumers.
In many ways OSGi can be thought of as an extension to the Java programming language that allows package visibility and package dependency constraints to be specified at development time and enforced at runtime. Through these constraints it is easier to build applications that are composed of loosely coupled and highly cohesive components.