|
...(2) The RCP is natural progression toward integrating not only tools but also applications and services. In particular, the RCP involved the minimal set of plug-ins needed for this transformation, promoting not only modular development through plug-ins but also dynamic network provisioning. This RCP evolution, however, introduced new requirements and challenges for Eclipse.
In particular, the RCP needed to embrace dynamic management of components. With larger and more complex runtime configurations and usage scenarios, requiring restarts of the platform for changes in the runtime configuration to take effect was no longer acceptable. A service framework would nicely complement the extension framework promoted by the Eclipse registry. Indeed, service and extension frameworks correspond to complementary software design patterns. Finally, it was important that security be addressed in the context of an RCP.
Considering these technical challenges, we rapidly realized that our main challenge would be managing change itself. The necessary changes mandated a quantum leap in the design and architecture of the core platform, but the planning, target dates, and the requirement for maintaining backward compatibility (that is, compatability with previous versions) all favored instead a rather timid evolutionary path. A deep-seated overhauling of the Eclipse cote runtime (3) would be both risky and difficult to achieve without disrupting the rest of the Eclipse 3.0 planning process.
We decided to try a new approach, one that would allow for fast experiments intended to scout for best solutions, but would also ensure that such solutions could be easily integrated into the main development stream of Eclipse 3.0. Specifically, we decided to leverage the existing Eclipse Technology Projects program. (4) Technology projects are meant to explore adventurous ideas with a loose connection to the Eclipse mainstream.
Our technology project was called Equinox. From the start, we involved committers (5) of the Eclipse platform team as well as external contributors. The goal was concrete: scouting practical solutions for direct inclusion in Eclipse 3.0. Through both Eclipse committers and external contributors, we achieved the right balance between fresh new ideas and an intimate knowledge of the Eclipse internal structure. The Eclipse committers provided invaluable connections to the other groups of Eclipse when it was rime to transfer the results of Equinox back into mainstream Eclipse. Overall, this approach proved to be a successful one for managing cote change in a mature open-source project.
In Equinox, we examined two primary technical avenues. One focused on using an Eclipse-specific runtime, evolving it to support the new requirements. The other involved evaluation of existing open standards providing similar functionality. In the end, we followed the latter course and chose an approach based on specifications from the OSGi ** Alliance. (6) The OSGi Alliance provides an open standard that specifies the OSGi Service Platform (SP), a platform for network-provisioned software components. (7) Although the OSGi specifications seemed a natural choice, their adoption posed technical challenges as well as educational ones.
This paper traces the Equinox project, assuming familiarity with Eclipse 2.x. (8) We briefly present OSGi technology in the following section and then discuss its adoption by Eclipse. The next section details the extensions to the OSGi specifications that we added to our implementation in order to support Eclipse. We also discuss the necessary changes to the Eclipse core runtime. Finally, we present conclusions derived from our work and discuss directions for future efforts.
OSGI SERVICE PLATFORM RELEASE 3
The OSGi Alliance publishes specifications (9) that define the SP depicted in Figure 1. The SP was initially targeted at residential Internet gateways with home automation applications. It consists of a small layer above a Java ** Virtual Machine (JVM **) that provides a shared platform for network-provisioned components and services. It is shared by different providers of components, potentially across organizational boundaries. It provides an extensive security model and at the same time promotes cooperation and reuse between components. The most attractive features of the platform are its long-running design based on a service-oriented architecture and its ability to support dynamic updates with minimal perturbation of the running environment.
[FIGURE 1 OMITTED]
Component and service model
The SP embodies a component and service model. An OSGi component, or bundle, is a set of Java packages containing both classes and resources, essentially what would be traditionally packaged in a JAR (Java archive) file. The difference, however, is that the SP manages such bundles and their dependencies that are expressed as meta-data attached to each bundle.
Each bundle expresses its dependencies at the level of Java packages. A bundle explicitly imports the Java packages that it needs but does not itself define. Conversely, a bundle may export some Java packages that it defines. The SP automatically matches imports and exports based on name equivalence. This matching process is dynamic as bundles are installed or uninstalled. A bundle is said to be resolved when all its dependencies are met, that is, when exporters for all the Java packages it imports are available. When a bundle is resolved, its exported Java packages automatically become available for matching to the import requirements of other bundles.
Above the component model, the SP provides a service-oriented architecture. In particular, it relies on the ability to activate a bundle. In other words, after a bundle is resolved, it may be started and stopped. A bundle may be activated if it defines an activator class. When a bundle is started, the SP creates an instance of that activator class, called the activator object, on which it calls the methods start and stop.
The start provides...
NOTE: All illustrations and photos
have been removed from this article.
More articles from IBM Systems Journal
Aspect-oriented programming with AspectJ., June 01, 2005
Looking for additional articles?
Search our database of over 3 million articles.
Looking for more in-depth information on this industry?
Search our complete database of Industry & Market reports by text, subject, publication
name or publication date.
About Goliath
Whether you're looking for sales prospects, competitive information, company
analysis or best practices in managing your organization,
Goliath can help you meet your business needs.
Our extensive business information databases empower business
professionals with both the breadth and depth of credible,
authoritative information they need to support their business
goals. Whether it be strategic planning, sales prospecting,
company research or defining management best practices -
Goliath is your leading source for accurate information.
|
%20%20&position=1)