Tech Chat - Craig Walls on Spring Dynamic Modules

Craig Walls is author of the recently published DZone Refcard, "Getting Started with Spring-DM", as well as previous Refcardz on Spring, such as "Spring Configuration" and "Spring Annotations". In this interview, Craig looks at some of the advantages of using Spring-DM, how it differs from OSGi Declarative Services, and some of the challenges around testing Spring-DM enabled OSGi bundles.  Finally, Craig discusses why he thinks OSGi is ready to meet the challenges of enterprise development today.

DZone: What's the primary advantage of Spring DM?

Craig Walls: One of the primary benefits of OSGi is that it brings a framework for modularity to the Java platform. And one of the ways that OSGi offers modularity to the Java platform is by enabling encapsulation of a module's functionality behind services. But programming directly to the OSGi API can be tedious and results in a lot of boilerplate code for both publishing and consuming OSGi services. Spring-DM eliminates that boilerplate by providing a declarative service model where OSGi services are published and consumed as if they were any other POJO in a Spring application context. Rather than writing several lines of Java against the OSGi API, working with services in Spring-DM often involves only one or two lines of XML.

DZone: Spring DM enables a declarative service model for OSGi. But the OSGi compendium defines a declarative services specification. Is Spring-DM a supplement for OSGi Declarative Services, or an alternative?

Craig: Spring-DM is one of a handful of declarative service models for OSGi which includes OSGi's own Declarative Services (DS) and other declarative service models such as Apache Felix iPOJO. These are all great options for eliminating the need to work directly with the OSGi API. And, on the surface, they all appear to do the same thing, only in different ways. Unlike the other alternatives, Spring-DM offers more than just wiring OSGi services together. Being based on the Spring Framework, Spring-DM

not only enables you to wire services, but also the beans that make up those services at a lower level.

DZone: It seems that the core component of Spring-DM is the extender bundle that creates the application context for Spring enabled bundles. What about the rest of the Spring DM JAR files? Are they the same Spring JAR files we're accustomed to using? Is all functionality we're accustomed to with Spring available in Spring-DM?

Craig: Those are the same Spring JAR files. As of Spring 2.5, all of the Spring Framework JAR files come in the form of OSGi bundles. Everything you've come to know and love about the Spring Framework is available to you as you develop Spring-enabled OSGi bundles.

DZone: Are bundles that aren't Spring-DM enabled incompatible with Spring-DM enabled bundles in an OSGi environment?

Craig: Not at all. Services published by Spring-DM are no different than services published in OSGi through other means. That means that you're free to mix-n-match Spring-DM enabled bundles with bundles that use the OSGi API, OSGi DS, or iPOJO. Once those services are in the OSGi registry, it doesn't matter much to a service consumer how they got there.

Craig: Developing web applications in OSGi used to be a tricky thing. You could either use the HttpService (which is effectively a web container within the OSGi framework) or an OSGi Servlet Bridge (which is an OSGi framework within a web container). Most implementations of the HttpService were weak in that they offered basic support for Java Servlets and little else. Even then you had to programatically register your Servlets with the HttpService and could not declare them in the familiar web.xml file. The Servlet Bridge offered an alternative approach where you would build a somewhat traditional web application (as a WAR file) with an OSGi framework implementation embedded within it.

Spring-DM took a different approach with their support for web applications. Rather than offer a watered-down HttpService and requiring programmatic  registration of Servlets, Spring-DM lets traditional web containers such as Jetty and Catalina do all of the heavy lifting--after all, they're pros at deploying web apps. Spring-DM's web extender takes care of the hand-off of web bundles (OSGi bundles in WAR file form) to the web container as they're installed in the OSGi container. The main benefit of the web extender is that you can develop a web bundle in much the same way you've always developed WAR files.

DZone: The RefCard points out that in a dynamic environment like OSGi, services can come and go. What happens if a consumer bundle is holding a reference to a service in a provider bundle and someone stops or uninstalls the provider bundle? How does Spring-DM or OSGi manage this situation?

Craig: That depends. When a bundle uses Spring-DM to consume an OSGi service that isn't available, the default behavior is for Spring-DM to wait up to 5 minutes for the service to become available, after which an exception is thrown. But if 5 minutes doesn't suit you, then you can specify a different timeout or you can specify '0..1' cardinality to indicate that the service reference is optional and doesn't require the backing service to be available.

DZone: Testing is an important development practice. How difficult it is to test Spring-DM enabled OSGi bundles versus OSGi bundles that don't leverage Spring DM?

Craig: Ultimately, Spring-DM bundles publish and consume services in the same OSGi service registry as those that don't leverage Spring-DM. What this means is that bundle testing isn't much different for Spring-DM enabled bundles than for non-Spring-DM bundles. In fact, the only real difference is whether or not the Spring-DM extender must be installed in the test OSGi framework or not.

DZone: So Spring-DM does provide some additional functionality that encourages testing inside an OSGi framework. Cool. But what about testing bundles that have dependencies on other bundles? Does Spring-DM install dependencies too? Or are these forms of OSGi "integration tests" discouraged?

Craig: In fact, that's precisely the reason you'd want to test bundles in-container as offered by Spring-DM's testing support. If all you want to test is the functionality within a single bundle, you're better off writing conventional unit and integration tests of the Java classes within the bundle and not involving an OSGi framework at all.

The way I see it is that there are three kinds of testing in question here:

•  Unit testing of the classes within a bundle
•  Integration testing the classes within a bundle with themselves
•  Integration testing two or more bundles within an OSGi framework

The first two types of testing don't need to involve OSGi at all and you're free to use whatever testing tools that are already available for such tests. The third kind of testing checks to see how well bundles play together in an OSGi framework and there's no way to do that without testing them in-container.

DZone: In general, tools for OSGi development seem sparse. Do you have any recommendations on tools or frameworks that aid bundle development, management, or runtime environment setup? Do you have a preferred OSGi development stack?

Craig: I'm a huge fan of the work done on the OPS4J Pax projects. They offer several great tools for working with OSGi, including Pax Construct, a script-driven approach to developing OSGi projects that is quite similar to working with frameworks like Rails and Grails. and a runtime setup tool called Pax Runner that's great for bootstrapping an OSGi framework with a selection of bundles. I can't imagine developing OSGi bundles without Pax Construct or starting an OSGi-based application without Pax Runner.

I'm also an Eclipse user and Eclipse does have a decent OSGi development environment that is cleverly disguised as a plugin development environment (PDE). But to be honest, I only use Eclipse for its Java development tools (refactoring support mainly) and rarely use the features of the PDE. In fact, with all of the help I get from Pax Construct, all of the OSGi-specific work I do could easily be done in a plain text editor.

DZone: There's been some controversy surrounding how the enterprise will use OSGi. Some say OSGi should be hidden away and it's benefits leveraged indirectly. Others argue that developers should have access to the programming model. What are your thoughts?

Craig: I would ask why they'd want OSGi to be hidden away? And, if it were hidden away, then how would developers reap the modular benefits that OSGi offers? If the application servers see benefit in using OSGi internally, then wouldn't you think that the applications that run on those servers could also benefit?

I look to the current mix of application servers available and see several that use OSGi under the covers and one application server (SpringSource dm Server) that exposes it to the apps deployed on that server. In the former, applications are developed and deployed in no way different than they have always been--business as usual. The familiarity of that model is appealing, but that model hasn't fostered modular development.

In the latter, applications can be developed as they always have been, but it is strongly encourage that they be developed in a modular way so that they are easier to maintain, test, change, and comprehend--all of the benefits of modularity. One of the nice things about SpringSource dm Server is that it offers a migration path from traditional applications, through partially modular applications, all the way to applications that take full advantage of OSGi. You don't have to rewrite your applications to be modular all at once--you have the freedom to make small improvements toward modularity over time.

I imagine that those who want to hide OSGi either do so because they think that OSGi is too difficult for the average developer. But development tools such as Pax Construct and declarative service models such as Spring-DM make working with OSGi a snap.

DZone: Do you feel OSGi is ready for enterprise development today? Or are there only specific development use cases where it's more or less suitable?

Craig: Any application that would benefit from modularity will benefit from OSGi. The interesting thing, however, is that most any application could benefit from modularity. Certainly applications that include some form of plugin system (such as Eclipse or Atlassian JIRA) are quick to realize those benefits. But it's hard to imagine any application that wouldn't be a little easier to maintain, a little easier to test, a little easier to comprehend, and a little easier to develop in parallel if it were partitioned in to highly-cohesive, loosely-coupled modules.

Deep down, most developers know this to be true. That's why they tend to partition their applications into various structures such as JAR files, packages, and even objects. The problem, however, is that JAR files and packages are a counterfeit form of modularity and the modularity offered by objects is at too low of a level to be practical for large applications. OSGi enables us to build coarse-grained, JAR file-sized modules that are truly highly-cohesive and loosely-coupled.

DZone: Where can I go to find out more information about OSGi and Spring? Any good books, reference material, or websites?

Craig: The OSGi Alliance website at is a great source of information about OSGi in general. And the Spring-DM homepage is where you can find information on Spring-DM.

Honestly, though, I follow OSGi and Spring-DM primarily through the blogs of other OSGi/Spring-DM advocates. There are far too many of them to list here, but sites like DZone and JavaBlogs are a great place to find these blogs aggregated in one place. Also Filippo Diotalevi maintains a great collection of OSGi-oriented articles on his site called "The OSGi Look".

There are many great books on Spring available and also a few covering OSGi and Spring-DM. My bias may be obvious, but I recommend my book, "Modular Java", which is a practical guide to OSGi, Spring-DM, and a handful of the Pax tools. And my bias wouldn't be complete if I didn't suggest "Spring in Action" for anyone who wants to get to know the framework that Spring-DM is based upon.

And, of course, I try to write something now and again about OSGi on the OSGi portion of my blog.

DZone: Thank you Craig. We enjoyed speaking with you.

Craig: The pleasure was mine.