A last note on Oisin's very insterestin comment. The choice between
exposing OSGi services or NMR services has also to deal with the level
of SOA adoption you want to adopt. The NMR promotes a looser coupling
(since you depend "only" on the WSDL/XML specification of your services)
and enables the use of a BPEL engine, such as ODE. With OSGi you have
stronger coupling, since you're working on the Java level (coupling to
the technology).
From what you've described of your concerns, I would recommend using
(2) for your refactored components, (3) for the others (you have a
perfect compatibility between SMX3.2 & SMX4), and (1) for the internal
plumbing of your components, if you need componentization and/or service
dynamicity.
Oisin Hurley a écrit :
2009/7/21 Juan José Vázquez Delgado <[email protected]>:
[deletia]
I´m not sure if I understand the whole picture but I see three options
really. For instance, regarding Camel components, we might have three
different aproaches:
(1) Camel on OSGi, but neither NMR nor JBI [1]
(2) Camel on NMR but no JBI compliant [2]
(3) Camel on NMR and JBI compliant [3]
Really, I have doubts chosing between the second and third ones.
The choice between the last two is which standard you would
like to adhere to for lifecycle and packaging. With (2) you are
constructing OSGi bundles, with (1) you are are constructing
service assemblies, service units, etc.
If my requirement was for a single Camel route, or more than
one non-interacting Camel routes in a container, then I would
go for (1).
If my requirement was for multiple interacting Camel routes in a
single container, or multiple interacting Camel routes in multiple
containers, I would probably go for (2). [If I didn't like the normalization
then I would write another cross-context passthru bundle, ie.
copy the nmr bundle and take out the 'n' bit].
If I had a whole heap of JBI-trained people, or I had a
lot of JBI packages already, or if I wanted to allow people to
run my stuff on OpenESB, or if I had some tools that made
it easy to develop with JBI, then I might choose (3) :)
That's just a personal opinion, of course - it comes down to
what exactly you want to do, what the parameters of your
solution are...
--oh
