OSGi is going to change the deployment and run time model for enterprise applications, according to Adrian Colyer in an InfoQ video interview. Adrian goes in-depth on OSGi, its uses, future impact on the industry, and how Spring will make development with OSGi easier (Spring OSGi m1 was recently released). Adrian talks about how OSGi may change the definition of an application server and JSR 277 vs. OSGi.
Watch OSGi & Spring with Adrian Colyer (29 min)
Adrian starts off explaining the origins of OSGi as a dynamic component model in the embedded space, "Over the years it has evolved and got picked up and now it’s basically the leading state of the art micro kernel". Today OSGi is used by most developers transparently as it is the plugin-model for Eclipse, it is being used as the basis for Websphere, WebLogic and other major appservers, but one emerging area of interest is OSGi's use for application development. Adrian explained:
Adrian went on to suggest a possible best practice for how very large web apps could be partitioned using OSGi:
Adrian concludes that OSGi is going to "change the deployment and run time model for enterprise applications". See also InfoQ's indepth coverage of OSGi.
What do you think about OSGi's impact on enterprise app development?
Watch OSGi & Spring with Adrian Colyer (29 min)
Adrian starts off explaining the origins of OSGi as a dynamic component model in the embedded space, "Over the years it has evolved and got picked up and now it’s basically the leading state of the art micro kernel". Today OSGi is used by most developers transparently as it is the plugin-model for Eclipse, it is being used as the basis for Websphere, WebLogic and other major appservers, but one emerging area of interest is OSGi's use for application development. Adrian explained:
First you get proper modularity then you get versioning concurrent deployment, and then the next thing you get is a level of operational control over that environment that you never had before....[with Spring OSGi] with anyone of those application contexts we can install it, uninstall it, start it, stop it, refresh it, all at run time, keeping the rest of the applications up and running, without impacting it. OSGi had its foundations in, a light weight and dynamic environment, and it’s been built to address the issues of that in a way that no other framework really has.
Adrian went on to suggest a possible best practice for how very large web apps could be partitioned using OSGi:
What a large web application will look like in the OSGI world probably 1, 2, 3, how many MVC bundles, so take each layer and partition it vertically, so that you got the side by side partitions of the system. Then in your service layer, again divide that by major service root; each of those would become a bundle, exposing its services. The same for your repositories; the domain main model might be split across one or more bundles. The supporting libraries you need - they are also bundles. And Spring OSGI is going to wire that together for you, using the OSGI service registry to do the cross bundle bean things. When you got these larger complex web applications, suddenly you get a way of getting a lot more structure and control around it. When you’ve got those big large web applications, you probably got a big large team working on it. And it’s going to be much easier to update and extend parts of it separately, in parallel, and it wouldn’t have been previously when it was one big lump.
Adrian concludes that OSGi is going to "change the deployment and run time model for enterprise applications". See also InfoQ's indepth coverage of OSGi.
What do you think about OSGi's impact on enterprise app development?