You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by Juan José Vázquez Delgado <ju...@gmail.com> on 2009/07/21 16:10:57 UTC
[SMX4] JBI or not JBI
Hi,
Currently I have two enterprise solutions made up of several JBI
service assemblies and deployed on a ServiceMix 3.3 instance. These
SAs contain a few SUs deployed on different kind of JBI components
such as smx-cxf-bc, smx-cxf-se, smx-jms, camel, smx-bean, amongst
others.
Now, I´m planning to move to ServiceMix 4. My idea is refactoring some
components taking advantage of the new OSGi architecture but my doubt
is if I should keep myself close to JBI specification or not. In other
words, is the JBI stuff supported in SMX4 for legacy reasons or is
intented to be the main way to develop for SMX4?.
In the other hand, I´d like taking advantage of the new clustering
stuff provided in SMX4 too.
Any advices or best practices?.
Thanks in advance.
Regards,
Juanjo.
Re: [SMX4] JBI or not JBI
Posted by Juan José Vázquez Delgado <ju...@gmail.com>.
> 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.
Yep, it´s exactly what I´ll do.
Thank you everybody for your comments and for this interesting thread.
Regards,
Juanjo.
Re: [SMX4] JBI or not JBI
Posted by Vincent GIRARDREYDET <vi...@thalesgroup.com>.
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 <ju...@gmail.com>:
> [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
>
>
Re: [SMX4] JBI or not JBI
Posted by Oisin Hurley <oi...@gmail.com>.
Hi Ron,
> 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?
Your timing is good, this particular nugget was being debated in the
FUSE forums [0] today :)
The result : vm: works to allow communication between two disparate
Camel contexts in separate bundles in an SMX4 container instance.
I had previously thought vm: was limited to a single classloader, but
janstey tested vm: between two separate contexts in two separate
bundles and confirms that it works.
So maybe no migration is necessary. If it was, I would suggest using the
camel-osgi rather than the camel-nmr if normalization and a standard API
was not at issue.
cheers
--oh
[0] http://fusesource.com/forums/message.jspa?messageID=3662#3662
Re: [SMX4] JBI or not JBI
Posted by Adrian Trenaman <tr...@progress.com>.
Hi Ron,
Yes, the vm: transport does work in the OSGi container; as far as I know
though it only works at present for one-way exchanges. I think a fix is
coming for this...
Hope all is well,
Ade.
Ron Gavlin wrote:
> 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 <oi...@gmail.com>
> To: users@servicemix.apache.org
> Sent: Tuesday, July 21, 2009 2:41:14 PM
> Subject: Re: [SMX4] JBI or not JBI
>
> 2009/7/21 Juan José Vázquez Delgado <ju...@gmail.com>:
> [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
>
>
Re: [SMX4] JBI or not JBI
Posted by Ron Gavlin <rg...@yahoo.com>.
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 <oi...@gmail.com>
To: users@servicemix.apache.org
Sent: Tuesday, July 21, 2009 2:41:14 PM
Subject: Re: [SMX4] JBI or not JBI
2009/7/21 Juan José Vázquez Delgado <ju...@gmail.com>:
[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
Re: [SMX4] JBI or not JBI
Posted by Oisin Hurley <oi...@gmail.com>.
2009/7/21 Juan José Vázquez Delgado <ju...@gmail.com>:
[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
Re: [SMX4] JBI or not JBI
Posted by Juan José Vázquez Delgado <ju...@gmail.com>.
> Hi Juan José,
Hi, and thank you for your comments.
>
> 1. If you think you will need some EIP features like those in Camel, or you
> will still have complex integrations that JBI can make easier (such as
> routing from a WS to a FTP, or things like that) and that can be done easily
> with the JBI components (that is, with few code !), then stick to JBI
This is my case, so +1 to JBI as you are saying.
>
> 2. If you need some of the features of OSGi, such as service lifecycle, then
> convert your old components
Probably, I might get out some functionality from my current SUs and
build some OSGi bundles with it.
>
> 3. Decide what bus is the most appropriate ! As I view it, SMX4 has 2 busses
> : the NMR, which is JBI-compliant, and OSGi. Each one has its advantages and
> drawbacks. For JBI, it is the *standardization* of the message format, and
> the fact that the message is really instanciated and transmitted. But it
> requires much plumbing. For OSGi, it is the speed of development when you
> are in pure-java, and the services lifecycle. But as it is not a true bus,
> you must stick to Java/JavaRMI (for dOSGi), and you have not "true" message
> exchanges between components, you just have RPC.
>
> I am personally mixing the 2: I use OSGi for the internal plumbing of my
> solution, and JBI for integration with other systems in the enterprise or
> with external systems, as it provides a nice loose coupling (the interface
> is in the message, not in the RPC façade).
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.
Regards,
Juanjo.
[1] http://svn.eu.apache.org/repos/asf/servicemix/smx4/features/trunk/examples/camel-osgi
[2] http://svn.eu.apache.org/repos/asf/servicemix/smx4/features/trunk/examples/camel-nmr
[3] http://svn.eu.apache.org/repos/asf/servicemix/smx4/features/trunk/examples/bridge-camel/bridge-camel-su
Re: [SMX4] JBI or not JBI
Posted by Vincent GIRARDREYDET <vi...@thalesgroup.com>.
Hi Juan José,
Here is my modest opinion. This depends of the time and needs you have :
1. If you think you will need some EIP features like those in Camel, or
you will still have complex integrations that JBI can make easier (such
as routing from a WS to a FTP, or things like that) and that can be done
easily with the JBI components (that is, with few code !), then stick to JBI
2. If you need some of the features of OSGi, such as service lifecycle,
then convert your old components
3. Decide what bus is the most appropriate ! As I view it, SMX4 has 2
busses : the NMR, which is JBI-compliant, and OSGi. Each one has its
advantages and drawbacks. For JBI, it is the *standardization* of the
message format, and the fact that the message is really instanciated and
transmitted. But it requires much plumbing. For OSGi, it is the speed of
development when you are in pure-java, and the services lifecycle. But
as it is not a true bus, you must stick to Java/JavaRMI (for dOSGi), and
you have not "true" message exchanges between components, you just have RPC.
I am personally mixing the 2: I use OSGi for the internal plumbing of my
solution, and JBI for integration with other systems in the enterprise
or with external systems, as it provides a nice loose coupling (the
interface is in the message, not in the RPC façade).
regards,
Vincent
Juan José Vázquez Delgado a écrit :
> Hi,
>
> Currently I have two enterprise solutions made up of several JBI
> service assemblies and deployed on a ServiceMix 3.3 instance. These
> SAs contain a few SUs deployed on different kind of JBI components
> such as smx-cxf-bc, smx-cxf-se, smx-jms, camel, smx-bean, amongst
> others.
>
> Now, I´m planning to move to ServiceMix 4. My idea is refactoring some
> components taking advantage of the new OSGi architecture but my doubt
> is if I should keep myself close to JBI specification or not. In other
> words, is the JBI stuff supported in SMX4 for legacy reasons or is
> intented to be the main way to develop for SMX4?.
>
> In the other hand, I´d like taking advantage of the new clustering
> stuff provided in SMX4 too.
>
> Any advices or best practices?.
>
> Thanks in advance.
>
> Regards,
>
> Juanjo.
>
>