Just as you may be paying an undue price for redundant libraries, so too are you likely paying for
unused application server services, such as EJB1.x and 2.x support, or JCA. Here again, OSGi can help by
providing a “server à la carte” model, where your application is provisioned by the container only with
the services it needs.
OSGi is, on the large, a deployment concern. However, using it effectively requires changes to
your code, as well. It affects how you acquire dependencies for your application. Naturally, this is
where Spring is strongest, and where dependency-injection in general can be a very powerful tool.
SpringSource has made several forays into the OSGi market, first with Spring Dynamic Modules, which
is an enhanced OSGi framework that provides support for Spring and much more. Then, on top of
Spring Dynamic Modules, SpringSource built SpringSource dm Server, which is a server wired from top
to bottom with OSGi and Spring. SpringSource dm Server supports dynamic deployment, enhanced
tooling, HTTP, and native .WAR deployment. It also sports superb administrative features.
OSGi is a specification, not a framework. There are many implementations of the specification,
much like Java EE is a specification, not an implementation. Additionally, OSGi is not a user component
model, like Spring or EJB 3. Instead, it sits below your components, providing life-cycle management for
Java classes. It is, conceptually, possible to deploy to an OSGi runtime in the same way that you deploy
to a Java EE runtime, completely unaware of how Java consumes your .jar files and MANIFESTS and so
on. As you'll see in this chapter, however, there's a lot of power to be had in specifically targeting OSGi
and exploiting it in your application. In this chapter, we will discuss Spring Dynamic Modules, and to a
lesser extent, Spring dm Server.
12-1. Getting Started With OSGi
You understand OSGi conceptually, but you want to see what a basic, working example with raw OSGi
looks like. It's hard to appreciate the sun, after all, if you've never seen the rain.
In this solution, we'll build a simple service and then use it in a client. Remember, in OSGi, anything
used by something else is a service. “Service” doesn't imply any concrete inheritance, it doesn't imply
transactional qualities, and it doesn't imply RPC. It's merely a class on whose concrete, black-box
functionality and interface your class relies.
In this example, we'll use Eclipse's OSGi distribution, Eclipse Equinox. There are many distributions to
choose from. Popular ones include Apache's Felix and Eclipse's Equinox. You may use any distribution
you want, but for this example, the instructions will be for Felix. The concepts should be the same across
implementations, but the specifics may vary wildly in both commands and mechanism.
Osgi and “JavaBeans™”
This is sort of like what a “JavaBean” was originally intended to be. These days, OSGi is starting to take
on the very vivid marketing life that JavaBeans did before it. You'll occasionally note products promoting
chief among their upgrades their new, internal use of OSGi, as products did years ago with JavaBeans
and object-oriented programming (“Now object-oriented!”). Be mindful of the hype.