wab, eba, application.xml, ...
Why do we need to introduce all of these new concepts? One of the reasons OSGi feels so much nicer than the traditional J2EE stack is that the number of concepts is vastly reduced. The core is kept to the minimal set of concepts to achieve the properties of modularity, dynamicity, and security. When I create a plug-in project in eclipse, there is only one meta-data file, MANIFEST.MF, that I need to worry about.
Compare this to a J2EE project which introduces so many files and descriptors in my project that the IDE designers decided they need to hide them from me to make it 'usable'.
Showing posts with label osgi. Show all posts
Showing posts with label osgi. Show all posts
Friday, March 5, 2010
Wednesday, January 20, 2010
Nested Frameworks and the Scoped Service Registry
From Peter Kriens' great blog post, http://www.osgi.org/blog/2010/01/nested-frameworks.html: Nested frameworks, or the ability to run an OSGi application entirely within the boundary of a host OSGi framework, "will likely appear in a future OSGi specification".
Some more excepts from the post:
"I do not believe that the Application Server model where a number of WAR files are running in the same VM should be followed by an OSGi model where these WAR files are running in an OSGi framework only sharing their dependencies. Though it is good to manage a dependency (as OSGi does), it is best to not have a dependency in the first place. It is good to handle multiple versions of the same library but the problems caused by multiple versions quickly cascades to umanageable proportions.
I therefore believe that the original model promoted by OSGi, where the application emerges from the installed bundles, is still by far the best model we have. In this model bundles adapt to each other and collaborate with each other through services; exporting implementation classes is an anathema in this model."
"Any services in the service registry are available to all bundles because the framework is the application."
"This model raises the question how to handle multiple independent applications. Do they all require their own framework? The answer is an unequivocal yes!"
Now my thoughts:
An application does not an island make. Today's applications are collaborative and connected. This makes defining application "boundaries" tricky. Is an application the main process running on a particular system, or is it the collection of all the related processes running on potentially multiple nodes across the network?
Its pretty clear that one could group all compile dependencies (i.e. bundle and package dependencies) together and call that an "app", but what about the service dependencies? What about the optional service dependencies? How do we give applications the isolation they need, allowing them to have private services that are internal to their boundaries, while still allowing them to share/use services to/from the wider community. It would be silly that this would need to go through some kind of remoting infrastructure if the same applications are running on the same instance of the same JVM.
Even within the same application, one of the things I've stuggled with in OSGi is how to get bundle granularity right. You can build a highly modular application where each bundle contains only a few classes and offers only a single service or two...or you can combine like bundles into "cohesive" units which offer a larger number of related services. Loose coupling/high cohesion is well and good, but when rubber hits road, its always grey. A scoped service registry would allow you to mix and match your highly granular bundles into a more consumable chunk (like Eclipse features) by defining a way to register semi-private services that are only visible to other bundles within the same scope.
Unlike the song from Paul Simon, an application is neither a rock nor an island. Applications are becoming more entwined and I think this is a fundamental consequence of our industry's shift towards SOA.
The nested frameworks spec seems like step in the right direction, but I can't help but feel its a bit over-complicated. Maybe we'd be better off just introducing the notion of a scoped service registry where we can control the visibility of services between arbitrary groups of bundles?
Some more excepts from the post:
"I do not believe that the Application Server model where a number of WAR files are running in the same VM should be followed by an OSGi model where these WAR files are running in an OSGi framework only sharing their dependencies. Though it is good to manage a dependency (as OSGi does), it is best to not have a dependency in the first place. It is good to handle multiple versions of the same library but the problems caused by multiple versions quickly cascades to umanageable proportions.
I therefore believe that the original model promoted by OSGi, where the application emerges from the installed bundles, is still by far the best model we have. In this model bundles adapt to each other and collaborate with each other through services; exporting implementation classes is an anathema in this model."
"Any services in the service registry are available to all bundles because the framework is the application."
"This model raises the question how to handle multiple independent applications. Do they all require their own framework? The answer is an unequivocal yes!"
Now my thoughts:
An application does not an island make. Today's applications are collaborative and connected. This makes defining application "boundaries" tricky. Is an application the main process running on a particular system, or is it the collection of all the related processes running on potentially multiple nodes across the network?
Its pretty clear that one could group all compile dependencies (i.e. bundle and package dependencies) together and call that an "app", but what about the service dependencies? What about the optional service dependencies? How do we give applications the isolation they need, allowing them to have private services that are internal to their boundaries, while still allowing them to share/use services to/from the wider community. It would be silly that this would need to go through some kind of remoting infrastructure if the same applications are running on the same instance of the same JVM.
Even within the same application, one of the things I've stuggled with in OSGi is how to get bundle granularity right. You can build a highly modular application where each bundle contains only a few classes and offers only a single service or two...or you can combine like bundles into "cohesive" units which offer a larger number of related services. Loose coupling/high cohesion is well and good, but when rubber hits road, its always grey. A scoped service registry would allow you to mix and match your highly granular bundles into a more consumable chunk (like Eclipse features) by defining a way to register semi-private services that are only visible to other bundles within the same scope.
Unlike the song from Paul Simon, an application is neither a rock nor an island. Applications are becoming more entwined and I think this is a fundamental consequence of our industry's shift towards SOA.
The nested frameworks spec seems like step in the right direction, but I can't help but feel its a bit over-complicated. Maybe we'd be better off just introducing the notion of a scoped service registry where we can control the visibility of services between arbitrary groups of bundles?
Tuesday, September 30, 2008
Whiteboarding: A form of torture?
The whiteboard pattern is a pretty well-known "best practice" in the OSGi community. For this reason, I was somewhat surprised to hear from a co-worker (echoed by a couple folks at EclipseCon) that not everyone considers this pattern a blessing. Unfortunately, I have never seen this argument laid out in writing before, so I thought I would give it a shot in this blog entry--apologies if I do it no justice.
The whiteboard pattern is basically a modification on the standard listener pattern in which the content publisher looks up its consumers in the service registry instead of the consumers hooking themselves into the publisher. For a deeper understanding, there is lots of good info available including this whitepaper. This pattern purportedly works much better (fewer lines of code, less prone to error, etc.) in the dynamic world of OSGi services...so why wouldn't everyone love that?
The answer (and I suspect this is an eye-of-the-beholder thing) is simplicity. Although the code presented in the whitepaper makes it pretty clear that using the basic framework to implement the traditional listener pattern can be quite burdensome, I am not convinced it must be this way. With the improvements in service frameworks like Declarative Services, it is becoming easier and cheaper to develop a system based around service interactions. So if the programming complexity becomes similar, in what way does the whiteboard pattern introduce additional complexity?
I can say from first-hand experience that the loosely-coupled nature of OSGi services can be a dual edged sword...powerful yes, but also difficult to follow. When you step into a large project with lots of service dependencies, it can be hard to untangle the interactions and see how the pieces fit together. This effort is made even more difficult in code which uses the whiteboard pattern. The registry becomes entangled with a bunch of listener objects, which have no clear indication of who should call them or what service they are providing to the system. Additionally, the developer is expected to know that they can hook into a particular producer by implementing some standard interface and publishing it to the registry. This type of hidden interaction model can be very tricky to find and needs to be well documented to be effective...or else it can start to feel a bit too 'magical'.
The beauty of the service registry is that it gives us a single place for safe, dynamic, loosely-coupled bundle interaction. So what we would really like to see in the registry is the "service" a particular bundle is offering to the other bundles in the system. On the one hand we have a pool of content consumers offering only a "listen" service, while on the other we have a content publisher who allows you to register your interest with its content. Now which of these bundles do you think more accurately fits the average developer's notion of "service"? I wonder why we don't see this type of "whiteboard" pattern in distributed SOA systems...
The whiteboard pattern is basically a modification on the standard listener pattern in which the content publisher looks up its consumers in the service registry instead of the consumers hooking themselves into the publisher. For a deeper understanding, there is lots of good info available including this whitepaper. This pattern purportedly works much better (fewer lines of code, less prone to error, etc.) in the dynamic world of OSGi services...so why wouldn't everyone love that?
The answer (and I suspect this is an eye-of-the-beholder thing) is simplicity. Although the code presented in the whitepaper makes it pretty clear that using the basic framework to implement the traditional listener pattern can be quite burdensome, I am not convinced it must be this way. With the improvements in service frameworks like Declarative Services, it is becoming easier and cheaper to develop a system based around service interactions. So if the programming complexity becomes similar, in what way does the whiteboard pattern introduce additional complexity?
I can say from first-hand experience that the loosely-coupled nature of OSGi services can be a dual edged sword...powerful yes, but also difficult to follow. When you step into a large project with lots of service dependencies, it can be hard to untangle the interactions and see how the pieces fit together. This effort is made even more difficult in code which uses the whiteboard pattern. The registry becomes entangled with a bunch of listener objects, which have no clear indication of who should call them or what service they are providing to the system. Additionally, the developer is expected to know that they can hook into a particular producer by implementing some standard interface and publishing it to the registry. This type of hidden interaction model can be very tricky to find and needs to be well documented to be effective...or else it can start to feel a bit too 'magical'.
The beauty of the service registry is that it gives us a single place for safe, dynamic, loosely-coupled bundle interaction. So what we would really like to see in the registry is the "service" a particular bundle is offering to the other bundles in the system. On the one hand we have a pool of content consumers offering only a "listen" service, while on the other we have a content publisher who allows you to register your interest with its content. Now which of these bundles do you think more accurately fits the average developer's notion of "service"? I wonder why we don't see this type of "whiteboard" pattern in distributed SOA systems...
Subscribe to:
Posts (Atom)