Spring apps on OSGI
In my post on April 6th, 2007 I mentioned about the availability of Spring OSGI’s first milestone. However, in that post I did not cover much of the details. Anyway, the specification of Spring-OSGI is now posted on Spring Framework’s site.
The specification mentions its goal to provide an “easier path to build Spring applications that can be deployed in an OSGi execution environment, and that can take advantage of the services offered by the OSGi framework”.
The Spring-OSGI effort targets to combine the best features of both OSGI and Spring. OSGI has its strength in providing a lightweight micro-kernel where modules (read “bundles” in OSGI) can be dynamically added or removed. OSGI also provides a better isolation. The isolation is useful to co-exist multiple version of the same service. It isolated the potential problems on class conflicts. Spring provides an easy to use framework based on DI and AOP powered with various services (Spring ecosystem). Thus the combination targets, (I am listing benefits listed in the specs into two separate buckets), to give benefits from both the worlds:
Benefits inherited from OSGI
· Better separation of application logic into modules
· The ability to deploy multiple versions of a module concurrently
· The ability to dynamically discover and use services provided by other modules in the system
· The ability to dynamically deploy, update and undeploy modules in a running system
Benefits inherited from Spring:
· Use of the Spring Framework to instantiate, configure, assemble, and decorate components within and across modules.
· A simple and familiar programming model for enterprise developers to exploit the features of the OSGi platform.
In a recent interview, Interface21’s CTO Andrian Colyer, elaborated a practical and interesting scenario of using the Spring-OSGI. If a service in use needs an upgrade, behind the scene, you can bring down the service and replace with the newer upgraded service without any glitch. Spring OSGI combination manages the switching of services in the background. Spring provides a stable proxy in this scenario while OSGI provides dynamic lifecycle and versioning.” SpringOSGI solves this problem not only for ‘stateless’ services but for ‘stateful’ services too.
We may see various service platforms leveraging this powerful combination. However, Spring-OSGi might not be the only app framework based on OSGI. e.g. OSGI based Microkernel servers currently offered by different vendors are not Spring based. In addition to Spring-OSGi combination, some independend work being done to map SCA and OSGI. Moreover, OSGI itself is going through further enhancement to support distributed case. Some ESB vendors may have a look at OSGI either for dynamic services. Anyway, With such different pieces working together, more powerful platforms may emerge. The combined platforms would be effectively used to build large and complex enterprise applications. (On a side note: There is another effort, JSR 312 for JBI 2.0, in java world to combine SCA and OSGI “like features” . I commented on the efforts in my earlier post )
Spring
OSGI
JBI
The specification mentions its goal to provide an “easier path to build Spring applications that can be deployed in an OSGi execution environment, and that can take advantage of the services offered by the OSGi framework”.
The Spring-OSGI effort targets to combine the best features of both OSGI and Spring. OSGI has its strength in providing a lightweight micro-kernel where modules (read “bundles” in OSGI) can be dynamically added or removed. OSGI also provides a better isolation. The isolation is useful to co-exist multiple version of the same service. It isolated the potential problems on class conflicts. Spring provides an easy to use framework based on DI and AOP powered with various services (Spring ecosystem). Thus the combination targets, (I am listing benefits listed in the specs into two separate buckets), to give benefits from both the worlds:
Benefits inherited from OSGI
· Better separation of application logic into modules
· The ability to deploy multiple versions of a module concurrently
· The ability to dynamically discover and use services provided by other modules in the system
· The ability to dynamically deploy, update and undeploy modules in a running system
Benefits inherited from Spring:
· Use of the Spring Framework to instantiate, configure, assemble, and decorate components within and across modules.
· A simple and familiar programming model for enterprise developers to exploit the features of the OSGi platform.
In a recent interview, Interface21’s CTO Andrian Colyer, elaborated a practical and interesting scenario of using the Spring-OSGI. If a service in use needs an upgrade, behind the scene, you can bring down the service and replace with the newer upgraded service without any glitch. Spring OSGI combination manages the switching of services in the background. Spring provides a stable proxy in this scenario while OSGI provides dynamic lifecycle and versioning.” SpringOSGI solves this problem not only for ‘stateless’ services but for ‘stateful’ services too.
We may see various service platforms leveraging this powerful combination. However, Spring-OSGi might not be the only app framework based on OSGI. e.g. OSGI based Microkernel servers currently offered by different vendors are not Spring based. In addition to Spring-OSGi combination, some independend work being done to map SCA and OSGI. Moreover, OSGI itself is going through further enhancement to support distributed case. Some ESB vendors may have a look at OSGI either for dynamic services. Anyway, With such different pieces working together, more powerful platforms may emerge. The combined platforms would be effectively used to build large and complex enterprise applications. (On a side note: There is another effort, JSR 312 for JBI 2.0, in java world to combine SCA and OSGI “like features” . I commented on the efforts in my earlier post )
Spring
OSGI
JBI
posted by Khanderao at
5:24 PM
0 Comments:
Post a Comment
<< Home