Interview: OSGi & Spring In-depth with Adrian Colyer

Posted by Floyd Marinescu on Jun 07, 2007

Sections

Development,

Operations & Infrastructure

Topics

Java ,

Application Servers ,

Deployment / Datacenter

Tags

OSGi

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:

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?

1. Back to top

   java needs a standard kenrel

   by Bill Burke

   The Java community really needs a standardized kernel. The kludges and hacks that projects like Seam and Spring have to do to bootstrap themselves in different app server environments is just unacceptable.
   
   Although I think OSGi is a great place to define this standardized kernel, there is still a lot that needs to be done though. Specifically, we need an abstraction around defining custom packaging formats, a real deployment API, rather than having to create an RFP specification for each package format. A file/archive abstraction that can deal with exploded, unexploded archives and different archive formats like virtual archives. We also need an aspectized approach to deployment so value-add frameworks can augment existing subsystems like Java EE. I talked a little bit about why these abstractions are important in my blog. The JBoss 5 Deployment Framework is where JBoss is heading and where we want to push OSGi.
   
   Bill

   Reply

• Older >