Glassfish, MySQL, and the whole "aquarium".
Goodbye Sun.
Thursday, January 21, 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?
Subscribe to:
Posts (Atom)