cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: Concerns about the Camel / CXF documentation
Date Thu, 28 Aug 2008 12:44:55 GMT
Benson Margulies schrieb:
> My question is dumber. If Camel, a part of Apache, is a superior
> comestible for this purpose, should we consider decommissioning or
> deprecating the existing CXF JMS in favor of just using it?
>
> On Thu, Aug 28, 2008 at 6:15 AM, Christian Schneider
> <chris@die-schneider.net> wrote:
>   
I think it would be bad idea to simply use Camel as is as a JMS 
transport replacement for CXF in the long run. Camel and CXF have 
different object models for example for Messages and Exchanges.
So when a CXF Exchange crosses the border to Camel it has to be 
converted. Additionally you get a lot more dependencies when you add 
Camel to your stack.

So for me there are two different possibilities to improve CXF JMS.

The first is to rewrite the JMS code for CXF. The camel JMS 
implementation can be a good starting point for this but it would mean a 
separate code base from Camel.

The other possibility is to base Camel and CXF perhaps even also 
Servicemix on a common kernel of Objects like Message and Exchange. Then 
there could also be a common codebase for Transports that can then be 
used for all these projects. Perhaps Servicemix kernel could be this 
common base but I do not know enough about it to be sure.

What way is the better depends on two things the goals of the projects 
and how well the teams can depend on each other. If the goals are quite 
common and the teams work well together then the second way is the 
better else it is better to keep the codebases separate. But that´s only 
my two cents ;-)

Best regards

Christian


Mime
View raw message