Thanks Stuart - very interesting write-up, plenty of pointers for us to
research!
Regards
- Rob
Stuart McCulloch wrote:
2009/2/3 Rob Walker <[email protected]>
The servicebinder model has served us very well and still does. I note
though that there are perhaps newer approaches such as Declarative Services
and iPojo. Very interested in views on:
* benefits of moving from servicebinder (especially any real
experiences from others who have done this)
* pros and cons of either DS or iPojo as the model to move to
interesting, Karl and I were just chatting about this...
iPOJO provides a really comprehensive component model, where you
can add almost any sort of behaviour using handlers - the downside in
my opinion is that it requires you to instrument your bundles in the build
phase - these bundles cannot then be used without iPOJO
however, as Karl rightly pointed out, when you instrument your bundle
you basically make it very extendable and adaptable, so the runtime
dependency on iPOJO is not that big a deal (iPOJO core is small)
of course if iPOJO provided runtime instrumentation that would totally
eliminate this downside (not sure if that's in the works, but it should be
feasible and would be really cool, hint-hint!)
another question is how well iPOJO integrates with other DI frameworks
- unfortunately I haven't had time to look into this, but again it should be
possible (at the very least it can interoperate via the service registry)
the benefit of DS is that it's a standard that's been around the block,
but the Spring DM / blueprint spec seems to have had more focus
going forward. This of course doesn't mean DS is going away any
time soon, as for example Eclipse/PDE is adding support for DS:
http://wiki.eclipse.org/PDE/Incubator/DS
you can also use the Bnd Tool or the maven-scr-plugin to generate
DS metadata, minimizing the amount of XML you have to deal with.
personal summary: DS is a safe choice, iPOJO requires a bit more
effort to begin with but opens up a lot more possibilities in the future
the most important thing to realize is that all these frameworks can
co-operate via the OSGi service registry, so you can mix-n-match
them and see which approach suits your application best. Most of
them try not to intrude too much on component internals.
will round things off with a couple of plugs:
EclipseCon 2009 has a tutorial about OSGi component models
( http://www.eclipsecon.org/2009/sessions?id=245 )
Kai has a presentation of a Swing app using DS/iPOJO/etc...
( http://www.toedter.com/blog/?p=44 )
also feel free to take a peek at http://code.google.com/p/peaberry/
While it's not a component model per-se (that is being looked into)
it does provide a fluent Java 5 API for injecting dynamic services.
it also abstracts the registry, so in the very near future you'll be able
to inject both services and Eclipse extensions (as well as your own
registry if you happen to have one lying around) .. the downside of
peaberry is that it requires you to use Java5 and Guice
FWIW I've heard people mention they've been doing comparisons
between the various component models on the Guice-OSGi group,
but afaik none of these comparisons are ready for publication...
HTH
Any thoughts welcomed
Regards
-- Rob
Ascert - Taking systems to the Edge
[email protected]
+44 (0)20 7488 3470
www.ascert.com
--
Ascert - Taking systems to the Edge
[email protected]
+44 (0)20 7488 3470
www.ascert.com
