Gabriel Claramunt wrote:I'll always found the OSGi concept really powerful, but found the whole framework a little unwielding. Does Spring makes it easier?
I'm not sure that I agree that the OSGi framework is unwieldy. It's a bit more involved than necessary, yes...but I never found it prohibitively unwieldy.
But yes, Spring does make it tremendously easier. One of the fundamental offerings of OSGi is a service registry through which modules can publish and consume services. OSGi is often referred to as "SOA in a JVM", as it offers a service-oriented architecture, but within a single JVM (no remoting). That's the part of OSGi that Spring-DM primarily addresses. What could take a dozen or so lines of
Java code to publish a service or consume a service takes only one or two lines of Spring configuration.
Note, however, that whether you work with Spring-DM or develop against the OSGi API, service implementations themselves are typically just POJOs. Usually, the only place where the OSGi API gets involved is in plumbing and infrastructural classes...your application code can remain OSGi-free.
What do you recommend to use as the "hello world"?
First, let me say that the problem with "Hello World" examples are often a great way to dip your toes in the
water of a new technology, but their value quickly depreciates as you desire to learn more. That's even more true with something like OSGi where the benefits of OSGi aren't realized until you have at least 2 distinct modules.
Nevertheless, I present a basic hello world example in
Modular Java. The first version I present simply uses a BundleActivator to echo out the familiar greeting. This example accomplishes little more than to introduce the reader to the OSGi API, but there are virtually no benefits of writing that example in OSGi. I then take it a step further by creating two modules...one that publishes a "hello" service and another that consumes it. That example is better at pointing out the benefits of OSGi. But as it is an overly simple example, the benefits require a bit of imagination from the reader. A more interesting example is required to truly "feel" OSGi...so that's what the rest of the book covers.