Hi Oisin, Do you know if the Camel vm transport works in an OSGi container? If not, then I suspect traditional Camel vm transport users might consider migrating towards the NMR transport during their migration to OSGi. Does that make sense?
/Ron ----- Original Message ---- From: Oisin Hurley <[email protected]> To: [email protected] Sent: Tuesday, July 21, 2009 2:41:14 PM Subject: Re: [SMX4] JBI or not JBI 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
