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
<[EMAIL PROTECTED]> 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
