[rabbitmq-discuss] status of available message buses compatible with Java client

Thu Jun 24 13:15:01 BST 2010

Shane

I would question maturity of Camel as well as some of the statements they make especially when referring to EIP.
The major problem I see with Camel is the fact that they have completely missed a major piece of EIP that allows for loosely coupled, flexible wiring of the endpoints and that is Channel abstraction. However they claim support for it on their website http://camel.apache.org/message-channel.html which is misleading. Camel uses the concept of 'routs' via rout builders essentially hard wiring two endpoints together which IMHO is the same as directly invoking consumer endpoint methods from the producer endpoint (se below) tightly coupling the two together. They've also misrepresented the concept of routing which states: "... filter which consumes message from one channels and republishes it to a different channel(s) depending on the set of conditions..." - http://www.enterpriseintegrationpatterns.com/MessageRouter.html

<route>
      <from ref="inputEndpoint"/>
      <to uri="outputEndpoint"/>
</route>

On the flip side Spring Integration provides quite a number of Channels, Routers and other EIP implementations completely decoupling producers from the consumers while allowing one to manage the behavior of how message will be retrieved by the consuming endpoint without the knowledge of producing endpoint. It also allows one to introduce the change in such behavior by changing the type of channel (from direct-channel to publish-subscribe, queue etc... channel which have different semantics when it comes to message distribution) without affecting/changing neither producing nor consuming endpoint.

This integral piece (decoupling Producers from the Consumers) of Messaging architecture is obviously well represented in AMQP which creates a great synergy between SI and Rabbit as a distributed messaging system. Producers send messages to the exchanges where such messages are routed based on the exchange type to a different queues (channels in EIP terms) to be later retrieved by the Consumers. Neither producer nor the consumer have any awareness of each other structure, implementation and even existence at any given time.

Oleg

On Jun 23, 2010, at 8:36 PM, Shane wrote:

Thanks for the thorough reply, Mark. I'm going to start looking at the
source.

Shane

On Jun 23, 8:09 pm, Mark Fisher <markfis... at vmware.com> wrote:
Shane, see my replies inline...

On Jun 23, 2010, at 6:28 PM, Shane wrote:

I'm still feeling my way around RabbitMQ (as you might have noticed
from the number of posts I've written lately). One decision I'm
wrestling with is what to use for message routing with the Java
client. I've started looking into the following:

- Writing my own helper classes with Spring
- Apache Camel
- Spring Integration with OpenCredo's contributions (amq template, amq
spring integration)

We will soon be releasing the first milestone of our Spring AMQP project. That includes support at the same basic level as Spring's JMS support (AmqpTemplate, SimpleMessageListenerContainers for Message-driven POJOs, MessageConverter strategies, and more). We will be providing Spring Integration Channel Adapters, Gateways, etc. that will build on top of that functionality.

Since RabbitMQ was recently acquired by SpringSource, SI w/OpenCredo
seems like the natural choice but there hasn't been any development on
the OpenCredo stuff since March? (looking at github).

We're going to be collaborating with OpenCredo on the project I mentioned above, and that project is actually quite active already. However, as I mentioned, we're just now approaching the first milestone release. We'll be moving to Git any moment now, but until it's moved, you can browse the current codebase here:https://src.springsource.org/svn/se-amqp/trunk/(after the move it will be at git.springsource.org/spring-amqp<http://git.springsource.org/spring-amqp>)

Although Apache Camel seems to be more mature, I'd rather go the
Spring Integration route since all of our apps already use Spring for
dependency injection, etc.

As the lead of Spring Integration, I'm a bit biased. That said, if your main concern is having a solid (and "mature" I might add) Spring foundation with implementations that are absolutely consistent with Spring, then Spring Integration is probably the best choice (and 2.0 GA is only a couple months away).

Can someone from Rabbit comment on the state of development with
respect to integration with Spring? Is the contributions from
OpenCredo going to be used?

Hopefully this question has been answered above. Let me know if there is anything that I missed.

Regards,
Mark

I'm also interested in other message bus solutions people are using
with the Java client.

Thanks again,
Shane
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-disc... at lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-disc... at lists.rabbitmq.comhttp://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss at lists.rabbitmq.com<mailto:rabbitmq-discuss at lists.rabbitmq.com>
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss