Other OSGi blogs |
Nested Frameworks
2010-01-17
I do not think we had application servers in mind when we had our first OSGi discussions in 1998. On the contrary, the OSGi service platform was the application; the idea of running multiple applications inside the same OSGi Service Platform did not cross our minds. Would somebody have explained the concept at that time, it would probably have been considered an anathema to us. Bundles were not meant to be applications, they were meant to be the constituents; the application was what appeared when you ran different bundles together in a service platform.
History played an interesting trick with this model. The class loading model of OSGi was more or less an afterthought, necessary to support the service oriented programming model. This detail caught the eye of many developers struggling with the class loaders in Java. However, instead of seeing a collaborative programming model, most saw class loaders on steroids. With release 4 we provided the zenith of all class loaders: allowing multiple versions to reside in the same framework. This was by many seen as the grail that solved the pesky problem of using multiple libraries that had conflicting version requirements. Though OSGi indeed could solve this problem better than anyone else it is illustrative that multiple versions was completely unnecessary for the original OSGi service oriented programming model. Actually, Richard Hall and BJ Hargrave had to explain the paradoxically sounding idea of exporting implementation classes many times to me.
With release 4, OSGi became salon fähig for the Application Server space. JONAS was the first but over time BEA WebLogic, IBM Websphere, JBoss followed. Even SAP and Oracle promised to follow this lead. The advantages of OSGi on this level are crystal clear but having the OSGi framework so close to the applications creates the temptation to allow applications to also use OSGi. Many applications are bursting out of their WAR format seams. The modularization provided by OSGi seems very attractive to remove the duplication that is embedded in the WAR architecture. It was Spring Source that made this module first available for enterprise developers with their Spring Source server. This lead is now followed by Oracle, IBM, and JBoss in a diverse set of open source projects.
The first automobiles in 1889 looked very much like the technology they replaced: horse carts. Over time the unique capabilities and requirements of an internal combustion engine resulted in the designs we see today. Is there an analogy with Application Servers and OSGi? Is OSGi just like an Application Server's programming model or should it be treated differently?
Though the OSGi indeed has class loaders on steroids, these class loaders can only alleviate the dependency problems caused by today's application models. 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! The cost of this model with the current OSGi frameworks could be quite high. Fortunately, the OSGi CPEG is currently working on nested frameworks. Nested frameworks allow the creation of a composite bundle. This is a bundle that acts as a wormhole to another framework. Nested frameworks will have low overhead and can easily share services and packages among each other.
Nested frameworks will likely appear in a future OSGi specification. It will definitely take time to work out all the special cases but it looks very promising so far. Thomas Watson from IBM has been experimenting and the latest versions of Equinox already provide some of the behavior in experimental form. For me, this is the most exciting RFC in progress. The nested model will enable an application programming model very close to the original OSGi service oriented programming model we envisioned a decade ago. However, with this simple recursive rule of nested frameworks we do not limit it to small embedded devices but enable the same model for (very) large enterprise applications running in large application servers as well.
Peter Kriens
History played an interesting trick with this model. The class loading model of OSGi was more or less an afterthought, necessary to support the service oriented programming model. This detail caught the eye of many developers struggling with the class loaders in Java. However, instead of seeing a collaborative programming model, most saw class loaders on steroids. With release 4 we provided the zenith of all class loaders: allowing multiple versions to reside in the same framework. This was by many seen as the grail that solved the pesky problem of using multiple libraries that had conflicting version requirements. Though OSGi indeed could solve this problem better than anyone else it is illustrative that multiple versions was completely unnecessary for the original OSGi service oriented programming model. Actually, Richard Hall and BJ Hargrave had to explain the paradoxically sounding idea of exporting implementation classes many times to me.
With release 4, OSGi became salon fähig for the Application Server space. JONAS was the first but over time BEA WebLogic, IBM Websphere, JBoss followed. Even SAP and Oracle promised to follow this lead. The advantages of OSGi on this level are crystal clear but having the OSGi framework so close to the applications creates the temptation to allow applications to also use OSGi. Many applications are bursting out of their WAR format seams. The modularization provided by OSGi seems very attractive to remove the duplication that is embedded in the WAR architecture. It was Spring Source that made this module first available for enterprise developers with their Spring Source server. This lead is now followed by Oracle, IBM, and JBoss in a diverse set of open source projects.
The first automobiles in 1889 looked very much like the technology they replaced: horse carts. Over time the unique capabilities and requirements of an internal combustion engine resulted in the designs we see today. Is there an analogy with Application Servers and OSGi? Is OSGi just like an Application Server's programming model or should it be treated differently?Though the OSGi indeed has class loaders on steroids, these class loaders can only alleviate the dependency problems caused by today's application models. 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! The cost of this model with the current OSGi frameworks could be quite high. Fortunately, the OSGi CPEG is currently working on nested frameworks. Nested frameworks allow the creation of a composite bundle. This is a bundle that acts as a wormhole to another framework. Nested frameworks will have low overhead and can easily share services and packages among each other.
Nested frameworks will likely appear in a future OSGi specification. It will definitely take time to work out all the special cases but it looks very promising so far. Thomas Watson from IBM has been experimenting and the latest versions of Equinox already provide some of the behavior in experimental form. For me, this is the most exciting RFC in progress. The nested model will enable an application programming model very close to the original OSGi service oriented programming model we envisioned a decade ago. However, with this simple recursive rule of nested frameworks we do not limit it to small embedded devices but enable the same model for (very) large enterprise applications running in large application servers as well.
Peter Kriens
BTW, JOnAS should be written with a 'n', not a 'N' ;)
Maybe we could add that if people are only interested in scoped services (aka services isolation), not isolated packages, iPOJO provides a nice concept of composite.