Ben Alex of SpringSource announced this last night at the Sydney Java Users Group meeting.
As big as the Spring framework has been, I think this product is going to have a pretty profound impact on the Java world. I have always wondered why we couldn't use OSGi for server-side deployment when it seemed such a natural model for dealing with dynamic modules. Apparently, while the model has been working for client-side apps for years, there have been issues with connections and threads on the server side, and these issues have only just been solved by the SpringSource "platform", which enhances the basic OSGi container.
OSGi bundles have long been a good way to build applications with flexibly-definable dependencies. Multiple versions of the same library can be deployed into a container without conflicts, allowing other modules that depend on them to run without problems. One can also deploy urgent patches to production servers without having to bring them down. All this is huge, because it allows application modules to be developed in a loosely-coupled manner, by specifying dependency ranges and following standards for version numbering. This is a Service-Oriented approach to deployment.
Going one step further is the ability to build the App Server itself in the form of bundles rather than as a monolithic executable. (JBoss does this too, but not with OSGi). The SpringSource App Server (S2AP) is the first of this new breed of beast. By way of analogy, S2AP is as different from earlier generations of app servers as the T-1000 of Terminator 2 was different from the earlier T-800 (think liquid metal). It means app servers need be no larger than necessary for the task at hand.
Well, the S2AP product is still in beta, so a few more months are going to pass while the industry kicks its tyres. But ultimately, I think there will be a shift to this more modular, version-friendly style of application deployment.
As big as the Spring framework has been, I think this product is going to have a pretty profound impact on the Java world. I have always wondered why we couldn't use OSGi for server-side deployment when it seemed such a natural model for dealing with dynamic modules. Apparently, while the model has been working for client-side apps for years, there have been issues with connections and threads on the server side, and these issues have only just been solved by the SpringSource "platform", which enhances the basic OSGi container.
OSGi bundles have long been a good way to build applications with flexibly-definable dependencies. Multiple versions of the same library can be deployed into a container without conflicts, allowing other modules that depend on them to run without problems. One can also deploy urgent patches to production servers without having to bring them down. All this is huge, because it allows application modules to be developed in a loosely-coupled manner, by specifying dependency ranges and following standards for version numbering. This is a Service-Oriented approach to deployment.
Going one step further is the ability to build the App Server itself in the form of bundles rather than as a monolithic executable. (JBoss does this too, but not with OSGi). The SpringSource App Server (S2AP) is the first of this new breed of beast. By way of analogy, S2AP is as different from earlier generations of app servers as the T-1000 of Terminator 2 was different from the earlier T-800 (think liquid metal). It means app servers need be no larger than necessary for the task at hand.
Well, the S2AP product is still in beta, so a few more months are going to pass while the industry kicks its tyres. But ultimately, I think there will be a shift to this more modular, version-friendly style of application deployment.
