This chapter is from the book
This chapter is from the book
This chapter is from the book
2.7 Collaboration
OSGi-based systems are composed of self-describing bundles as outlined previously. Bundles can collaborate by directly referencing types in other bundles. That is a simple pattern familiar to all Java programmers, but such systems are tightly coupled and miss out on the real power of modularity—loose coupling and dynamic behavior.
To loosen the coupling between modules, there must be a collaboration mechanism, a third party, that acts as an intermediary and keeps the collaborators at arm's length. The typical OSGi mechanism for this is the service registry. Equinox, of course, supports the service registry but also adds the Extension Registry. These complementary approaches are outlined in the following sections and discussed in more detail throughout the book.
2.7.1 Services
The OSGi service registry acts like a global bulletin board of functions coordinating three parties: bundles that define service interfaces, bundles that implement and register service objects, and bundles that discover and use services. The service registry makes these collaborations anonymous—the bundle providing a service does not know who is consuming it, and a bundle consuming a service does not know what provided it. For example, Figure 2-6 shows Bundle C that declares an interface used by Bundle B to register a service. Bundle A discovers and uses the service while remaining unaware of, and therefore decoupled from, Bundle B. Bundle A depends only on Bundle C.
)
Figure 2-6 Service-based collaboration
Services are defined using a Java type, typically a Java interface. The type must be public and reside in a package that is exported. Other bundles—and perhaps even the same bundle—then implement the service interface, instantiate it, and register the instance with the service registry under the name of the service interface. The classes that implement the service, being implementation details, generally are not contained in packages that are exported.
Finally, a third set of bundles consumes the available services by importing the package containing the service interface and looking up the service in the service registry by the interface name. Having obtained a matching service object, a consuming bundle can use the service until done with it or the service is unregistered. Note that multiple bundles can consume the same service object concurrently, and multiple service objects may be provided by one or more bundles.
The dynamic aspect of service behavior is often managed in conjunction with the lifecycle of the bundles involved. For example, when a bundle is started, it discovers its required services and instantiates and registers the services it provides. Similarly, when a bundle is stopped, its bundle activator unregisters contributed services and releases any services being consumed.
2.7.2 Extensions and Extension Points
The Equinox Extension Registry is a complementary mechanism for supporting inter-bundle collaboration. Under this model, bundles can open themselves for extension or configuration by declaring an extension point. Such a bundle is essentially saying, "If you give me the following information, I will do . . . ." Other bundles then contribute the required information to the extension point in the form of extensions.
In this book we use the example of an extensible web portal that allows actions to be contributed and discovered via the Extension Registry. In this approach the portal bundle declares an actions extension point and a contract that says,
- "Bundles can contribute actions extensions that define portal actions with a path, a label, and a class that implements the interface IPortalAction. The portal will present the given label to the user organized according to the given path and such that when the user clicks on the label, a particular URL will be accessed. As a result of the URL request, the portal will instantiate the given action class, cast it to IPortalAction, and call its execute method."
Figure 2-7 shows this relationship graphically.
)
Figure 2-7 Extension contribution and use
Extension-to-extension-point relationships are defined using XML in a file called plugin.xml. Each participating bundle has one of these files. As bundles are resolved in the system, their extensions and extension points are loaded into the Extension Registry and made available to other bundles. A full set of Extension Registry events is broadcast to registered listeners along the way. Extension and extension points can also be managed programmatically.