You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by janne postilista <ja...@gmail.com> on 2011/02/28 10:38:58 UTC
Integration design architecture question
The roles of ServiceMix 4 and Camel (and others) are a bit confusing to me.
Take the ServiceMix architecture pictured as:
http://fusesource.com/docs/esb/4.3.1/esb_getting_started/ESBGetStartedArchIntro.html
(could not find similar pic in servicemix.apache.org)
Lets say I'm building an integration system which reads from an JMS
queue A, does some processing to the messages, and writes them to
another queue B.
Wouldn't I just implement all of this inside Camel? Camel has features
for routing and processing the messages, and components for reading /
writing all kinds of protocols (JMS/file/ftp/...). Is this a typical
way of using ServiceMix?
In which situations it would be better to use the parts outside of
Camel, pictured in
http://fusesource.com/docs/esb/4.3.1/esb_getting_started/ESBGetStartedArchIntro.html
- NMR, JMS, JAX-WS?
Re: Integration design architecture question
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Just another thing:
- Camel is a mediation, routing and EIP framework
- ServiceMix is complete ESB platform, where Camel is the prefered
routing framework
to summarize in few words :)
Regards
JB
On 02/28/2011 10:38 AM, janne postilista wrote:
> The roles of ServiceMix 4 and Camel (and others) are a bit confusing to me.
>
> Take the ServiceMix architecture pictured as:
> http://fusesource.com/docs/esb/4.3.1/esb_getting_started/ESBGetStartedArchIntro.html
> (could not find similar pic in servicemix.apache.org)
>
> Lets say I'm building an integration system which reads from an JMS
> queue A, does some processing to the messages, and writes them to
> another queue B.
>
> Wouldn't I just implement all of this inside Camel? Camel has features
> for routing and processing the messages, and components for reading /
> writing all kinds of protocols (JMS/file/ftp/...). Is this a typical
> way of using ServiceMix?
>
> In which situations it would be better to use the parts outside of
> Camel, pictured in
> http://fusesource.com/docs/esb/4.3.1/esb_getting_started/ESBGetStartedArchIntro.html
> - NMR, JMS, JAX-WS?
Re: Integration design architecture question
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
My comments inline:
On 02/28/2011 11:07 AM, janne postilista wrote:
> Thanks...I still don't fully understand though. FYI I do plan to use
> ServiceMix and Camel inside of it, not thinking of using only Camel.
Understood, but I mean that you can use pure Camel inside ServiceMix, or
Camel with NMR inside ServiceMix. The two options are possible.
> Looking at it, it seems I have an option of doing everything inside
> Camel (which seems simpler) or do some parts inside Camel and others
> outside of Camel (NMR, CXF, etc) - which seems more complex. I can't
> understand what the benefits of the more complex option are, and why I
> would use it.
NMR introduces an additional abstraction layer. It's more complicated
than directly using Camel but it allows you to plug'n play endpoint
"outside" Camel.
Let me take a scenario.
You have a Camel route looking like:
<from uri="jms:A"/>
<to uri="jms:B"/>
Now, you want to use a custom endpoint that you develop, interacting
with your own system.
In pure Camel, you have to implement a custom Camel component and update
the routes like:
<from uri="jms:A"/><to uri="your:C"/><to uri="jms:B"/>
With the NMR, your "original" routes look like:
<from uri="jms:A"/><to uri="nmr:PNP"/>
<from uri="nmr:PNP"/><to uri="jms:B"/>
You can ovveride the PNP endpoint with your own implementation, without
changing Camel at all.
It's the same for CXF as we provide cxf-nmr.
>
> 2) You use CXF as an example. Camel also has a CXF component. How is
> it better to use "Camel can use a NMR endpoint provided by CXF." which
> I understand to be
>
> CXF => NMR => Camel
>
> than just utilize the Camel CXF component (not going to NMR at any point)?
Yes, you can use CXF in Camel directly or use NMR between CXF and Camel.
>
> 3) How is the solution that uses NMR more configurable / better than
> the one that just uses Camel? I understand it decouples the "IN" and
> "OUT" messages from each other, but in this example I can change both
> endpoints just as easily in both examples.
>
> - I also need the integration processing to be reliable, so that if
> ServiceMix crashes during the processing of the message at any point,
> the message is not lost and processing continues next time. Does this
> change the design, and the reasonings behind doing everything inside
> Camel or splitting work between Camel and rest of ServiceMix?
>
> On Mon, Feb 28, 2011 at 11:46 AM, Jean-Baptiste Onofré<jb...@nanthrax.net> wrote:
>> Hi Janne,
>>
>> Some comments
>>
>> 1/ ServiceMix is an integration platform. It embeds ActiveMQ, CXF, Camel,
>> ODE, NMR to provide a complete Enterprise ESB powered by OSGi.
>> 2/ NMR is a complete messaging platform. It allows you to decouple the
>> different integration tiers. For instance, Camel can use a NMR endpoint
>> provided by CXF. It introduces a new abstraction layer to allow you plug and
>> play of endpoints, these endpoints could be provided by Camel, CXF, or your
>> own implementation. Please, don't think that NMR == JBI, it's not the case,
>> JBI is only an endpoint implementation on top of the NMR.
>> More over, the NMR provides additional stuff such as a complete Event API,
>> an Audit layer, etc.
>> You can take a look on examples/cxf-camel-nmr to see how it works.
>> 3/ Your scenario could be implemented directly using Camel (using camel-jms
>> endpoint). Your Camel route could look like:
>> <from uri="jms:"/>><to uri="jms:"/>
>> You can also use the NMR to decoupled in two routes:
>> <from uri"jms:"/><to uri="nmr:"/>
>> <from uri="nmr:"/><to uri="jms:"/>
>> It allows you to be able to totally change the second route without changing
>> the first one.
>>
>> Hope it helps.
>> Regards
>> JB
>>
>> On 02/28/2011 10:38 AM, janne postilista wrote:
>>>
>>> The roles of ServiceMix 4 and Camel (and others) are a bit confusing to
>>> me.
>>>
>>> Take the ServiceMix architecture pictured as:
>>>
>>> http://fusesource.com/docs/esb/4.3.1/esb_getting_started/ESBGetStartedArchIntro.html
>>> (could not find similar pic in servicemix.apache.org)
>>>
>>> Lets say I'm building an integration system which reads from an JMS
>>> queue A, does some processing to the messages, and writes them to
>>> another queue B.
>>>
>>> Wouldn't I just implement all of this inside Camel? Camel has features
>>> for routing and processing the messages, and components for reading /
>>> writing all kinds of protocols (JMS/file/ftp/...). Is this a typical
>>> way of using ServiceMix?
>>>
>>> In which situations it would be better to use the parts outside of
>>> Camel, pictured in
>>>
>>> http://fusesource.com/docs/esb/4.3.1/esb_getting_started/ESBGetStartedArchIntro.html
>>> - NMR, JMS, JAX-WS?
>>
Re: Integration design architecture question
Posted by janne postilista <ja...@gmail.com>.
Thanks...I still don't fully understand though. FYI I do plan to use
ServiceMix and Camel inside of it, not thinking of using only Camel.
Looking at it, it seems I have an option of doing everything inside
Camel (which seems simpler) or do some parts inside Camel and others
outside of Camel (NMR, CXF, etc) - which seems more complex. I can't
understand what the benefits of the more complex option are, and why I
would use it.
2) You use CXF as an example. Camel also has a CXF component. How is
it better to use "Camel can use a NMR endpoint provided by CXF." which
I understand to be
CXF => NMR => Camel
than just utilize the Camel CXF component (not going to NMR at any point)?
3) How is the solution that uses NMR more configurable / better than
the one that just uses Camel? I understand it decouples the "IN" and
"OUT" messages from each other, but in this example I can change both
endpoints just as easily in both examples.
- I also need the integration processing to be reliable, so that if
ServiceMix crashes during the processing of the message at any point,
the message is not lost and processing continues next time. Does this
change the design, and the reasonings behind doing everything inside
Camel or splitting work between Camel and rest of ServiceMix?
On Mon, Feb 28, 2011 at 11:46 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Hi Janne,
>
> Some comments
>
> 1/ ServiceMix is an integration platform. It embeds ActiveMQ, CXF, Camel,
> ODE, NMR to provide a complete Enterprise ESB powered by OSGi.
> 2/ NMR is a complete messaging platform. It allows you to decouple the
> different integration tiers. For instance, Camel can use a NMR endpoint
> provided by CXF. It introduces a new abstraction layer to allow you plug and
> play of endpoints, these endpoints could be provided by Camel, CXF, or your
> own implementation. Please, don't think that NMR == JBI, it's not the case,
> JBI is only an endpoint implementation on top of the NMR.
> More over, the NMR provides additional stuff such as a complete Event API,
> an Audit layer, etc.
> You can take a look on examples/cxf-camel-nmr to see how it works.
> 3/ Your scenario could be implemented directly using Camel (using camel-jms
> endpoint). Your Camel route could look like:
> <from uri="jms:"/>><to uri="jms:"/>
> You can also use the NMR to decoupled in two routes:
> <from uri"jms:"/><to uri="nmr:"/>
> <from uri="nmr:"/><to uri="jms:"/>
> It allows you to be able to totally change the second route without changing
> the first one.
>
> Hope it helps.
> Regards
> JB
>
> On 02/28/2011 10:38 AM, janne postilista wrote:
>>
>> The roles of ServiceMix 4 and Camel (and others) are a bit confusing to
>> me.
>>
>> Take the ServiceMix architecture pictured as:
>>
>> http://fusesource.com/docs/esb/4.3.1/esb_getting_started/ESBGetStartedArchIntro.html
>> (could not find similar pic in servicemix.apache.org)
>>
>> Lets say I'm building an integration system which reads from an JMS
>> queue A, does some processing to the messages, and writes them to
>> another queue B.
>>
>> Wouldn't I just implement all of this inside Camel? Camel has features
>> for routing and processing the messages, and components for reading /
>> writing all kinds of protocols (JMS/file/ftp/...). Is this a typical
>> way of using ServiceMix?
>>
>> In which situations it would be better to use the parts outside of
>> Camel, pictured in
>>
>> http://fusesource.com/docs/esb/4.3.1/esb_getting_started/ESBGetStartedArchIntro.html
>> - NMR, JMS, JAX-WS?
>
Re: Integration design architecture question
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Janne,
Some comments
1/ ServiceMix is an integration platform. It embeds ActiveMQ, CXF,
Camel, ODE, NMR to provide a complete Enterprise ESB powered by OSGi.
2/ NMR is a complete messaging platform. It allows you to decouple the
different integration tiers. For instance, Camel can use a NMR endpoint
provided by CXF. It introduces a new abstraction layer to allow you plug
and play of endpoints, these endpoints could be provided by Camel, CXF,
or your own implementation. Please, don't think that NMR == JBI, it's
not the case, JBI is only an endpoint implementation on top of the NMR.
More over, the NMR provides additional stuff such as a complete Event
API, an Audit layer, etc.
You can take a look on examples/cxf-camel-nmr to see how it works.
3/ Your scenario could be implemented directly using Camel (using
camel-jms endpoint). Your Camel route could look like:
<from uri="jms:"/>><to uri="jms:"/>
You can also use the NMR to decoupled in two routes:
<from uri"jms:"/><to uri="nmr:"/>
<from uri="nmr:"/><to uri="jms:"/>
It allows you to be able to totally change the second route without
changing the first one.
Hope it helps.
Regards
JB
On 02/28/2011 10:38 AM, janne postilista wrote:
> The roles of ServiceMix 4 and Camel (and others) are a bit confusing to me.
>
> Take the ServiceMix architecture pictured as:
> http://fusesource.com/docs/esb/4.3.1/esb_getting_started/ESBGetStartedArchIntro.html
> (could not find similar pic in servicemix.apache.org)
>
> Lets say I'm building an integration system which reads from an JMS
> queue A, does some processing to the messages, and writes them to
> another queue B.
>
> Wouldn't I just implement all of this inside Camel? Camel has features
> for routing and processing the messages, and components for reading /
> writing all kinds of protocols (JMS/file/ftp/...). Is this a typical
> way of using ServiceMix?
>
> In which situations it would be better to use the parts outside of
> Camel, pictured in
> http://fusesource.com/docs/esb/4.3.1/esb_getting_started/ESBGetStartedArchIntro.html
> - NMR, JMS, JAX-WS?