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!)
The reason for this decision build-time instrumentation is because it
will work across all OSGi framework impls without requiring an
containerisms. For example, since there is no standard way to hook into
OSGi class loading, it is difficult to property set the protection
domain of classes instrumented at run time. We know this, because iPOJO
started life using run-time instrumentation. :-) Once a standard hook is
available, then run-time instrumentation is possible without any difficulty.
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)
I am not sure what this really means, since I think pretty much all OSGi
DI frameworks integrate through the service registry. What else you are
thinking about?
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
DS would certainly be easier coming from SB, since there is lineage
between the two.
Obviously, I am biased for iPOJO. It is written specifically for OSGi
and can offer more OSGi-specific stuff as a result, e.g., minimal
metadata via byte code inspection, automatic concurrency handling for
service dependencies, component participation in provided service
lifecycle, dynamic service properties for provided services, service
scoping through hierarchical composition, etc. Still, in iPOJO we strive
to keep the simple case simple. (See the presentation on our wiki for
some simple examples.)
However, I imagine the best way to figure it out is to create some
examples in the various technologies.
-> richard
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
