Platinum Partner
java,enterprise-integration,frameworks,architecture

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

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 ;-)

{{ tag }}, {{tag}},

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}
{{ parent.authors[0].realName || parent.author}}

{{ parent.authors[0].tagline || parent.tagline }}

{{ parent.views }} ViewsClicks
Tweet

{{parent.nComments}}