Making the OSGI service model better by implementing the model that makes extension points so great [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 8 years ago.

Improve this question

This question is for folks that are very familiar with OSGI and the development road map in place. I've grown up on Eclipse/Equinox and have found the extension point framework to be invaluable when building extendable software due to the ability to create rich xml metadata through the construction of a schema allowing extension points to be consumed out of java code and in the plugin.xml with design-time xml validation. This combined with the PDE Eclipse tooling for defining and consuming extension points is one of my favorite features of Equinox.

I think I've used extension points in just about every context I can think of from extending an equinox server-side schema with ECore packages to be mapped to a hibernate schema to modeling a web.xml extension point allowing for modular web application development where each plugin has the ability to contribute to a single web.xml file that gets generated based on extensions. I've enjoyed porting the JSF config file in a similar fashion to a single extension point allowing plugins to contribute managed beans and in the world of modular web application development I think extension points are a great solution to the challenge of decoupling the ugly war. In addition to alternative frameworks If you look at the Eclipse UI it is hard to imagine life without extension points but I've recently hit a cross-road in my development as more and more stake holders are pushing to build OSGI applications transparent to any implementation like Equinox or Felix forcing me to fall back on OSGI declarative services as my main strategy for extendibility

My biggest gripe is a missing an optional xml based rich meta-data layer for creating things like "service-points" (for lack of better words) which uses an xml schema to define an xml representation of a method invocation defined in the service interface allowing for something like "service-extensions" to consume OSGI services in xml and not in code making your development a lot more flexible and easier to maintain.

I don't know if that is the best approach to providing a higher level meta-data layer to OSGI Services but it's a good example because it shows the benefits of making OSGI Service contracts smarter than a Java Interface with an xml paradigm for service consumption not just service binding. With something like the above all the boiler plate code that is used to inject a service or get a service reference and then invoking methods in Java code to do something as simple like registering a http context on the HttpService could all be done in xml. Taking things a step further it becomes possible if not easier to build complex extendable UI frameworks using pure OSGI Services in either a rich client application (like extension points in eclipse today) or in a web application framework where one service-point makes it possible to define a standard container for an extendable web application with a unique ID, url mapping and controller, in the same framework other service-points allow other bundles to add things like menu tabs to the main menu with a relative index order as well as a link reference to a jsp page located in the bundle. The Web.xml could become a service-point in the http service allowing bundles to contribute servlet mappings or filters via "service-extensions" of the web.xml "service-point" which is all expressed in xml without the need of referencing the service in code and calling the correct methods.

I'm not suggesting that we port the extension point framework into OSGI but follow the same spirit of having an xml based meta-data layer for declarative OSGI services allowing a service to expose method invocations contained in its service interface as "service-points" which is defined as an xml schema that other declarative services or bundles can consume through "service-extensions." What I like about eclipse extension points is that it is easy to add extensions, you get a nice dialog of the available extension points based on your bundle classpath and with the PDE tooling an extension UI is dynamically rendered based on the schema of the target extension point. With this xml meta-data layer allowing bundle developers to expose OSGI service methods as "service-points" we can follow the same pattern for OSGI Services, the MANIFEST editor for example could have a tab called "Service Extensions" and when I click on "Add" I get a dialog of all the available service-points based on my bundle classpath that I can consume and like the PDE tooling the UI to create a new "service-extension" would be built around the schema associated with the "service-point." which during activation of my bundle is translated into a method call defined by the service point.

This is how I would like to use OSGI Services! All the neat UI frameworks we see in Eclipse like UI contributions or project nature builders, resource listeners, editor contributions you name it could be built out and extended in similar fashion using OSGI Services and a rich xml meta-data layer for wrapping service method calls into "service-points" and actual invocations as "service-extensions." So my crying request is show me something that offers this functionality in OSGI today! If you don't know of anything then what are your arguments for or against this approach of taking what is so great about eclipse extension points and building something similar into the OSGI Declarative Service model allowing us to enjoy easier and better extendablity in plain OSGI! - Duncan Krebs

Answer 1

What you're basically arguing for is the extender pattern. You're right that not everything is best represented as a Java object implementing a service interface. Some contributions are best offered as static or declarative resources in a bundle.

The Eclipse Extension Registry is essentially just an instance of the more general extender pattern. DS and Blueprint are examples as well. You can implement the extender pattern yourself pretty easily with portable OSGi APIs, such as BundleTracker. Also make sure you take full advantage of the Provide- and Require-Capability headers, to make sure that your extender actually gets picked up and installed by a resolver.

One word of warning about Eclipse Extensions... while there is a lot to like about them, they get the lifecycle all wrong. The extension registry will consume bundles in the RESOLVED state, but this means that you have no control over which bundles are consumed and which aren't. Most extenders should only consume STARTING or ACTIVE bundles, since the active state can actually be controlled.

UPDATE

Incidentally the Eclipse extension registry is implemented with a couple of bundles, and as far as I'm aware they work on any standard OSGi framework, i.e. not just Equinox. So there is nothing "non-OSGi" about them... they are just an additional layer on top of OSGi. If you really like them, then please continue using them! The reason most people in the OSGi community don't use them, I believe, is that they are not really worth bothering with. Once you get used to the proper way to work with services and extenders, you will probably find Eclipse-isms less attractive.

Answer 2

If you are happy to be tied in with Equinox, then have a look at Server Side Equinox - http://www.eclipse.org/equinox/server/ - I think is exactly what you want...