You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by cmoulliard <cm...@gmail.com> on 2008/09/19 14:07:46 UTC
Idea : Merge Apache Cxf project with Camel
Hi,
I'm investigating CxF project. During the reading of their documentation
(http://cwiki.apache.org/CXF20DOC/how-do-i-integrate-my-application-with-cxf.html),
I discovered that CxF use an internal bus to send messages over HTTP, JMS,
... My question is perhaps stupid but why don't we merge Cxf project with
Camel in order to avoid that both projects continue to develop their ESB bus
separetely ?
"L'union fait la force"
Charles Moulliard
-----
Enterprise Architect
Xpectis
12, route d'Esch
L-1470 Luxembourg
Phone +352 25 10 70 470
Mobile +352 621 45 36 22
e-mail : cmoulliard@xpectis.com
web site : www.xpectis.com www.xpectis.com
My Blog : http://cmoulliard.blogspot.com/ http://cmoulliard.blogspot.com/
--
View this message in context: http://www.nabble.com/Idea-%3A-Merge-Apache-Cxf-project-with-Camel-tp19571141s22882p19571141.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Idea : Merge Apache Cxf project with Camel
Posted by cmoulliard <cm...@gmail.com>.
Personnaly, such bus integration already exist because when you read the
following article, we recommand to the user to use camel jms factory instead
of Cxf bus
(http://cwiki.apache.org/CAMEL/better-jms-transport-for-cxf-webservice-using-apache-camel.html).
My feeling is that we can improve Cxf integration within Camel (and that was
the purpose of my post) at by example the level of the bean camel component
to avoid code like inside the Bean (who is processing the message coming
from the CxF endpoint)
BindingOperationInfo boi =
(BindingOperationInfo)exchange.getProperty(BindingOperationInfo.class.toString());
if (boi != null) {
LOG.info("boi.isUnwrapped" + boi.isUnwrapped());
}
// Get the parameters list which element is the holder.
MessageContentsList msgList =
(MessageContentsList)exchange.getIn().getBody();
Holder<String> personId = (Holder<String>)msgList.get(0);
Holder<String> ssn = (Holder<String>)msgList.get(1);
Holder<String> name = (Holder<String>)msgList.get(2);
>From my point of view, the routing done by Cxf is substituted by Camel
rounting even when we would like to use WS-ADDRESSING. The WS-RM (=
reliability) is another topic but I'm sure that we can cover this matter
within Camel.
Kind regards,
Charles Moulliard
willem.jiang wrote:
>
> There are hug difference between the CXF and Camel.
> CXF is a service framework which helps us to export a POJO as a
> WebServices
> Camel is a rule based mediator , it has lots of component which can help
> us to connect different endpoints
> Even Camel and CXF has the same HTTP, JMS components, they don't share
> the same architecture of the Bus
> 1. CXF bus works as a component repository, which will wire the CXF
> components together
> CXF components don't need to know each other , they just ask the bus
> for getting the reference of other component
> 2. Camel's bus in my opinion, is a pipeline or filter which connects
> different endpoints and routing the messages.
> So we have the Camel-CXF component and Camel transport for CXF to make
> these two great framework working together.
>
> If your bus means the message handler chain, I should say there is not
> much difference between the CXF and Camel, but it is a high level
> abstraction of message handling framework :)
>
> Willem
>> Hi,
>>
>> I'm investigating CxF project. During the reading of their documentation
>> (http://cwiki.apache.org/CXF20DOC/how-do-i-integrate-my-application-with-cxf.html),
>> I discovered that CxF use an internal bus to send messages over HTTP,
>> JMS,
>> ... My question is perhaps stupid but why don't we merge Cxf project with
>> Camel in order to avoid that both projects continue to develop their ESB
>> bus
>> separetely ?
>>
>> "L'union fait la force"
>>
>> Charles Moulliard
>>
>> -----
>> Enterprise Architect
>>
>> Xpectis
>> 12, route d'Esch
>> L-1470 Luxembourg
>>
>> Phone +352 25 10 70 470
>> Mobile +352 621 45 36 22
>>
>> e-mail : cmoulliard@xpectis.com
>> web site : www.xpectis.com www.xpectis.com
>> My Blog : http://cmoulliard.blogspot.com/
>> http://cmoulliard.blogspot.com/
>>
>
>
>
-----
Enterprise Architect
Xpectis
12, route d'Esch
L-1470 Luxembourg
Phone +352 25 10 70 470
Mobile +352 621 45 36 22
e-mail : cmoulliard@xpectis.com
web site : www.xpectis.com www.xpectis.com
My Blog : http://cmoulliard.blogspot.com/ http://cmoulliard.blogspot.com/
--
View this message in context: http://www.nabble.com/Idea-%3A-Merge-Apache-Cxf-project-with-Camel-tp19571141s22882p19574854.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Idea : Merge Apache Cxf project with Camel
Posted by Willem Jiang <wi...@gmail.com>.
There are hug difference between the CXF and Camel.
CXF is a service framework which helps us to export a POJO as a WebServices
Camel is a rule based mediator , it has lots of component which can help
us to connect different endpoints
Even Camel and CXF has the same HTTP, JMS components, they don't share
the same architecture of the Bus
1. CXF bus works as a component repository, which will wire the CXF
components together
CXF components don't need to know each other , they just ask the bus
for getting the reference of other component
2. Camel's bus in my opinion, is a pipeline or filter which connects
different endpoints and routing the messages.
So we have the Camel-CXF component and Camel transport for CXF to make
these two great framework working together.
If your bus means the message handler chain, I should say there is not
much difference between the CXF and Camel, but it is a high level
abstraction of message handling framework :)
Willem
> Hi,
>
> I'm investigating CxF project. During the reading of their documentation
> (http://cwiki.apache.org/CXF20DOC/how-do-i-integrate-my-application-with-cxf.html),
> I discovered that CxF use an internal bus to send messages over HTTP, JMS,
> ... My question is perhaps stupid but why don't we merge Cxf project with
> Camel in order to avoid that both projects continue to develop their ESB bus
> separetely ?
>
> "L'union fait la force"
>
> Charles Moulliard
>
> -----
> Enterprise Architect
>
> Xpectis
> 12, route d'Esch
> L-1470 Luxembourg
>
> Phone +352 25 10 70 470
> Mobile +352 621 45 36 22
>
> e-mail : cmoulliard@xpectis.com
> web site : www.xpectis.com www.xpectis.com
> My Blog : http://cmoulliard.blogspot.com/ http://cmoulliard.blogspot.com/
>
Re: Idea : Merge Apache Cxf project with Camel
Posted by cmoulliard <cm...@gmail.com>.
This post will not at all solved the debate concerning this architectural
question about integrating or not the bus but are you sure that you simplify
the life of an architect/developer when you must understand so many
different bus in order to design a project based on CxF, Camel and/or
servicemix ?
I agree with you that this is the strenght of the opensource community to
propose interesting solutions with lot of capabilities but at the end, when
you have to convince an executive or someone from infrastructure team, do
you think that they will support a solution based on 2/3 different bus.
If I compare the Camel/Cxf versus Mule/CxF approach, I see that CxF is
better integrated into Mule than Camel and removed a part of the complexity
liked to the addressing/security and manipulating the message.
Kind regards,
Charles
willem.jiang wrote:
>
> Ah, It's long history for the Camel, CXF and ServiceMix integration.
>
> First , each project didn't think about merge together when they did the
> architecture work, even you can find some common similar component here.
> But if you want one of project integrate with other project you need to
> follow a certain rule. That is why we integrate Camel and ServiceMix
> with CXF by implementing CXF transport API, we have the CXF BC and CXF
> SE for ServiceMix , camel-cxf component for Camel, servicemix-camel
> component for ServiceMix.
> I don't know how much work will be do , if we merge the common module
> together. But it must be a huge reconstruct work.
>
> Second, each project should work on their own. When we talk about Camel,
> CXF and ServiceMix merge, we should also know each project solving the
> partial problem, and we alway want them do their best work by them self.
> I don't see much convinces, if these project share a same basic
> component together.
>
> Any thought?
>
> Willem
>
>
> Christian Schneider wrote:
>> I would even go further and say:
>>
>> Could Camel, CXF and Servicemix share a common bus? This could be part
>> of perhaps Servicemix core or another basic module and the other
>> projects could build upon this.
>> Of course this should not make cxf and camel dependent on servicemix
>> in whole. It should be as small as possible.
>>
>> The camel integration with cxf works very well but it does not remove
>> the fact that both implment their own bus components. Still these
>> components are quite similar. So I see some good
>> oportunity for synergies.
>>
>> Greetings
>>
>> Christian
>>
>> cmoulliard schrieb:
>>> Hi,
>>>
>>> I'm investigating CxF project. During the reading of their documentation
>>> (http://cwiki.apache.org/CXF20DOC/how-do-i-integrate-my-application-with-cxf.html),
>>>
>>> I discovered that CxF use an internal bus to send messages over HTTP,
>>> JMS,
>>> ... My question is perhaps stupid but why don't we merge Cxf project
>>> with
>>> Camel in order to avoid that both projects continue to develop their
>>> ESB bus
>>> separetely ?
>>>
>>> "L'union fait la force"
>>>
>>> Charles Moulliard
>>>
>>> -----
>>> Enterprise Architect
>>>
>>> Xpectis
>>> 12, route d'Esch
>>> L-1470 Luxembourg
>>>
>>> Phone +352 25 10 70 470
>>> Mobile +352 621 45 36 22
>>>
>>> e-mail : cmoulliard@xpectis.com
>>> web site : www.xpectis.com www.xpectis.com My Blog :
>>> http://cmoulliard.blogspot.com/ http://cmoulliard.blogspot.com/
>>
>>
>
>
>
-----
Enterprise Architect
Xpectis
12, route d'Esch
L-1470 Luxembourg
Phone +352 25 10 70 470
Mobile +352 621 45 36 22
e-mail : cmoulliard@xpectis.com
web site : www.xpectis.com www.xpectis.com
My Blog : http://cmoulliard.blogspot.com/ http://cmoulliard.blogspot.com/
--
View this message in context: http://www.nabble.com/Idea-%3A-Merge-Apache-Cxf-project-with-Camel-tp19571141s22882p19607321.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Idea : Merge Apache Cxf project with Camel
Posted by Willem Jiang <wi...@gmail.com>.
Ah, It's long history for the Camel, CXF and ServiceMix integration.
First , each project didn't think about merge together when they did the
architecture work, even you can find some common similar component here.
But if you want one of project integrate with other project you need to
follow a certain rule. That is why we integrate Camel and ServiceMix
with CXF by implementing CXF transport API, we have the CXF BC and CXF
SE for ServiceMix , camel-cxf component for Camel, servicemix-camel
component for ServiceMix.
I don't know how much work will be do , if we merge the common module
together. But it must be a huge reconstruct work.
Second, each project should work on their own. When we talk about Camel,
CXF and ServiceMix merge, we should also know each project solving the
partial problem, and we alway want them do their best work by them self.
I don't see much convinces, if these project share a same basic
component together.
Any thought?
Willem
Christian Schneider wrote:
> I would even go further and say:
>
> Could Camel, CXF and Servicemix share a common bus? This could be part
> of perhaps Servicemix core or another basic module and the other
> projects could build upon this.
> Of course this should not make cxf and camel dependent on servicemix
> in whole. It should be as small as possible.
>
> The camel integration with cxf works very well but it does not remove
> the fact that both implment their own bus components. Still these
> components are quite similar. So I see some good
> oportunity for synergies.
>
> Greetings
>
> Christian
>
> cmoulliard schrieb:
>> Hi,
>>
>> I'm investigating CxF project. During the reading of their documentation
>> (http://cwiki.apache.org/CXF20DOC/how-do-i-integrate-my-application-with-cxf.html),
>>
>> I discovered that CxF use an internal bus to send messages over HTTP,
>> JMS,
>> ... My question is perhaps stupid but why don't we merge Cxf project
>> with
>> Camel in order to avoid that both projects continue to develop their
>> ESB bus
>> separetely ?
>>
>> "L'union fait la force"
>>
>> Charles Moulliard
>>
>> -----
>> Enterprise Architect
>>
>> Xpectis
>> 12, route d'Esch
>> L-1470 Luxembourg
>>
>> Phone +352 25 10 70 470
>> Mobile +352 621 45 36 22
>>
>> e-mail : cmoulliard@xpectis.com
>> web site : www.xpectis.com www.xpectis.com My Blog :
>> http://cmoulliard.blogspot.com/ http://cmoulliard.blogspot.com/
>
>
Re: Idea : Merge Apache Cxf project with Camel
Posted by Christian Schneider <ch...@die-schneider.net>.
I would even go further and say:
Could Camel, CXF and Servicemix share a common bus? This could be part
of perhaps Servicemix core or another basic module and the other
projects could build upon this.
Of course this should not make cxf and camel dependent on servicemix in
whole. It should be as small as possible.
The camel integration with cxf works very well but it does not remove
the fact that both implment their own bus components. Still these
components are quite similar. So I see some good
oportunity for synergies.
Greetings
Christian
cmoulliard schrieb:
> Hi,
>
> I'm investigating CxF project. During the reading of their documentation
> (http://cwiki.apache.org/CXF20DOC/how-do-i-integrate-my-application-with-cxf.html),
> I discovered that CxF use an internal bus to send messages over HTTP, JMS,
> ... My question is perhaps stupid but why don't we merge Cxf project with
> Camel in order to avoid that both projects continue to develop their ESB bus
> separetely ?
>
> "L'union fait la force"
>
> Charles Moulliard
>
> -----
> Enterprise Architect
>
> Xpectis
> 12, route d'Esch
> L-1470 Luxembourg
>
> Phone +352 25 10 70 470
> Mobile +352 621 45 36 22
>
> e-mail : cmoulliard@xpectis.com
> web site : www.xpectis.com www.xpectis.com
> My Blog : http://cmoulliard.blogspot.com/ http://cmoulliard.blogspot.com/
>
--
Christian Schneider
---
http://www.liquid-reality.de