Enterprise Integration Zone is brought to you in partnership with:

Peter has posted 3 posts at DZone. You can read more from them at their website. View Full User Profile

Nobody is Talking About The Whiteboard Pattern - Does OSGi Violate "Separation of Concerns"

05.01.2009
| 15267 views |
  • submit to reddit

I have known OSGi since Version 2 and started using it since Version 3. What made me a believer was the Service Oriented Programming model and the positive impact it had on my software. If you start thinking in OSGi terms then following the principle of "separations of concern" would become rather easy. And OSGi comes with a lot of astonishing stuff: hands up, who has heard or even used "org.osgi.service.wireadmin"? Who has used the whiteboard-pattern in "org.osgi.service.event"? Ok, I guess it's just a few guys...The later is an example for a very clever design, a small API with big capability if used in the right way.

What I really wonder about is the fact, that about 87% of OSGi coverage ignores these wonderful features but rather deals with class loading stuff. Tons of articles and blogs have been and will be written about how to overcome class loading subtleties - Most of all I like the DynamicProxyGenerator-Service that creates a classloader per call. Okay but this is another story. And look how class loading dominates the OSGi spec itself (in terms of overall pages) and how more and more subtleties have driven changes in the Spec. I say "Dynamic-Import: *", nothing more ;-)

Thinking about the proportions of coverage regarding technical things and articles about the wonderful business solution you can build with OSGi, I came to the conclusion that there is something wrong. And I came to the conclusion that the OSGi Framework itself violates the "separations of concerns" principle: I think that there should be a clear separation between all the class loading stuff and the service oriented programming approach. Both are very valuable but they are linked together too closely. Why is it so hard to do a web app in the OSGi way? Why is it even necessary to write an article about that? Why is it necessary to provide extra software to allow for the OSGi service oriented programming model in an web app? Why?

What if I split things up and separate the OSGi programming model from the module/class loading parts? I think from time to time I would just want to enjoy the programming model without having all the class loading overhead onboard. What about you?

The programming model is basically all the API for issuing/retrieving services.

The module part is basically responsible for all the class loading stuff (discovering Activators from jars, etc.)

Inbetween could be some arbitrary complex glue part that would take the "resolved bundles" and would deliver them into the Runtime...What would that look like?

1. For each traditional OSGI container it would be


static void main() {


//reading bundles from an url
ResolvedBundle bundles[] = BundleProcessor.discover(new URL("file:///anywhere");

//build a session to host the bundles
OSGISession session = OSGIRuntime.createSession();

for(;;) {

session.activate(bundles[i].getActivator());

}
}

2. For a web app it could be a list of Activator Class names in the web.xml and an InitServlet that just goes like this...


class InitServlet extends HttpServlet {
void init() {

String[] listOfActivatorNames = ...

OSGISession session = OSGIRuntime.createSession();

//just activate stuff without real bundles
for(;;) {

session.activate(Class.forName(listOfActivatorNames[i]);

}

}
}



3. For the next even more sophisticated class loading architecture...I would need to implement an even more powerful BundleProcessor...
public class WeiredActivator implements BundelActivator {

start(BundleContext b) {
OSGISession s = b.getSession();

ClassWorldsBundles a[] = ClassWorlds.find(...);
for(;;) {
s.activate(a[i].mainClass());
}
SeasonOtherThanSpringModules b[] = Spring.canDoEverything();
for(;;) {
s.activate(new SpringAdaptEverything(b[i].picoComponent()));
}
}

}

 

 

So guys at OSGiAlliance...it's never to late to separate concerns ;-)

Published at DZone with permission of its author, Peter Huber.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Guido Amabili replied on Fri, 2009/05/01 - 3:25am

I think you are right.

Modular Classloading should be built in the JVM. Then use your framework/specification (ejb,war, whatever..) to build applications.

 Guido 

Toni Menzel replied on Fri, 2009/05/01 - 4:16am

hi, i agree that you can do a lot of mess when not knowing what you are doing. But thats true for mostly everything - not just osgi. ;)

As you probably know, osgi already has clean separation between service and module layer. Its just not enforced by using core api. So, now the enterprise expert group (EEG) comes into the game.

Up until now, you surely have the oportunity to have a clean service layer, look at ipojo, spring-DM or even just DS.

They all sit on top of a small - very conshise api. And thats clearly a strength of osgi. It is not coming with an all bouncing service model that fits to everyone, but it provides a good foundations where you can build upon.

This is also what the EEG is going now, take emerged solutions (see Spring-DM gets standardized into Blueprint Services) and bring it out as a separate - build on top of core - standard.

At that point + with good tooling, you will have much more fun with osgi. But still, even best tooling, its always a good idea to know what you are doing. i think osgi has also educated many people to think more about how they put apps together.

When it comes to the classic web app example: well, there is always the option to just develope an ordinary WAR and deploy it into an osgi container (see Pax Web: http://wiki.ops4j.org/display/ops4j/Pax+Web+Extender+-+War) which is also getting a standard as part of the EEG progress.

Remember: OSGi is not a application api and was never intended to be. Its a runtime. You can use like you want to. But don't create apps where YOU (not osgi) polute the businesslayer with osgi api.

Bottomline: you can do shit with osgi. but you don't have to. ;)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.