Eclipse extensions and OSGi services are very similar in both nature and intent. However, despite their similarities they carry several differences having come from different backgrounds. Recently re-published on his blog as a PDF, Neil Bartlett has written an article that performs a comparative analysis of Eclipse extensions and a variety of flavors of OSGi services. The article has been specifically targeted towards Java developers familiar with the Eclipse registry, but not OSGi.
The comparison is prefaced with an explanation of the common confusions caused by the co-existence of the Eclipse extension registry and the OSGi service layer:
The key elements of the article are summarized with a comparison matrix that answers the following questions for Eclipse Extensions as well as all previously described varieties of OSGi services (Services, Declarative Services, and Spring-OSGi).
The comparison is prefaced with an explanation of the common confusions caused by the co-existence of the Eclipse extension registry and the OSGi service layer:
Since Eclipse adopted the OSGi runtime in version 3.0, there has been some tension between the Extension Registry, which has been a feature of Eclipse from its beginning, and the Service Layer, which came from OSGi and pre- existed the involvement of Eclipse. The cause of the tension is that these two models overlap somewhat, and because they are both intended to solve very similar problems. However "the Devil is in the details", and these two models are different enough to make it impractical for them to be merged. Therefore developers of Eclipse plugins and RCP applications need to make a choice between the two.The Eclipse extension registry is based on a series of entries in an XML file for each Eclipse plug-in. Bartlett describes the various benefits that XML markup provides over strictly using executable Java. Basic OSGi services, in contrast to Eclipse extensions, are defined and registered with regular Java code, which has several implications on their behavior. While describing OSGi services, Bartlett explains the inherent differences in their implementation when compared to Eclipse extensions, and the related advantages and disadvantages, making this point:
So what we really want is something that combines the advantages of both extensions and services. Something that is implicitly dynamic like services, but loaded “on demand” like extensions. Ideally, something that can also simplify the code that application developers must write.This is the void that declarative services are meant to fill. Since both Eclipse extensions and OSGi services have benefits and drawbacks in different areas, declarative OSGi services were created in an attempt to provide benefits from both technologies. Declarative services are still a relatively new technology, and for the 3.3 release of Eclipse (the most recent stable release), declarative services are available in incubator status as a separate download from the Equinox download site.
The key elements of the article are summarized with a comparison matrix that answers the following questions for Eclipse Extensions as well as all previously described varieties of OSGi services (Services, Declarative Services, and Spring-OSGi).
- What are registered?
- How are they registered?
- How are they consumed?
- What is the cardinality?
- When are they loaded?
- How is dynamic installation/uninstallation dealt with?
- Can caching references to extensions/services cause problems?
In this article I have described in general terms some of the strengths and weaknesses of Eclipse-style extensions and OSGi-style services. However I would not wish my readers to take away a simplistic message that “extensions aren’t dynamic” or “services can’t be used in RCP applications.” I’m afraid the issues are too subtle for that, and there is no substitute for making your own evaluation in the context of your requirements.To learn more about the relationship of Eclipse Equinox and OSGi, visit the Eclipse Equinox site.