[rabbitmq-discuss] RabbitMQ / Spring integration

Alexis Richardson alexis.richardson at cohesiveft.com
Mon Sep 1 10:31:07 BST 2008


Thanks for getting back on this.

On Fri, Aug 29, 2008 at 7:09 PM, Mark Pollack
<mark.pollack at springsource.com> wrote:
> The latest release candidate of Spring.NET has individual support classes
> for MSMQ, ApacheMQ, and TIBCO EMS and other vendors are planned.  I don't
> have any RabbitMQ experience but a quick look through the RabbitMQ api docs
> indicates to me that it is a low level API much in the same spirit of the
> JMS/JDBC APIs and that a template class would offer programming convenience
> to developers.

Excellent and yes we agree.  An analogy with RabbitMQ C# to Spring.NET
integration would be our WCF integration which is higher level and
provides Visual Studio integration too.  That is very much about
programming convenience.

> That said, I really don't know RabbitMQ so I'm not in the
> best position now to suggest what the interface of the template class would
> look like.


> When I spoke with you at QCon a while ago (sorry for not following up on the
> email after that) you suggested that developers from rabbitmq would be
> interested in helping in the dev effort of spring support for rabbit-mq.

Yes, there have been a number of people asking about this on the
rabbitmq list and off list too.  Although, when I mentioned this at
QCon, I was thinking about Java-RabbitMQ primarily.  However, in the
same way that our Java and C# clients are very similar to each other,
any template work will most likely involve overlap between Java and

> If
> that is the case, then I suggest we can form a spring-extensions project and
> start with a .NET implementation.

Would it be possible for the same project to be a home for both a .NET
implementation and a Java implementation?  (Pace your comments below)

> On the Java side there is so much momentum and developer mind-share around
> the JMS API that I don't think a case can be made for including this in the
> general spring framework.   I agree that for integration with Camel, Spring
> Integration etc., there isn't a reason the native API should be used and
> that use-case in itself isn't motivation to create template or other higher
> level helper classes to RabbitMQ

Not sure I agree with this.  Connecting frameworks to Java clients
ought to be a walk in the park; at least that has been the case with
other products eg Mule.  Putting JMS in the middle seems to create
inconvenience.  But - what do other people think?


> Cheers,
> Mark
> -----Original Message-----
> From: alexis.richardson at gmail.com [mailto:alexis.richardson at gmail.com] On
> Behalf Of Alexis Richardson
> Sent: Tuesday, August 19, 2008 7:20 AM
> To: Ben Hood
> Cc: carlos.quiroz-castro at nokia.com; rabbitmq; Ben Hale;
> mark.pollack at springsource.com
> Subject: Re: [rabbitmq-discuss] RabbitMQ / Spring integration
> Carlos, Ben,
> I am cc'ing folks from SpringSource who have discussed these concepts
> with me in the past.
> On Tue, Aug 19, 2008 at 9:06 AM, Ben Hood <0x6e6562 at gmail.com> wrote:
>> Hi Carlos,
>> On Tue, Aug 19, 2008 at 7:05 AM,  <carlos.quiroz-castro at nokia.com> wrote:
>>> Hi
>>> I can see two ways of implementing this. One is to use the existing AMQP
>>> component which uses qpid in turn. I haven't used it and I don't know
>>> its maturity. The other one is to implement directly using the RabbitMQ
>>> library
>> I think it would be most useful for users if the semantics of the AMQP
>> model were exposed via a Spring template, rather than just confining
>> users to the semantics of JMS. This could make functionality available
>> such configuring message routing that isn't available via JMS, for
>> example.
>> An alternative route would be to say I want to keep the JMS template
>> semantics and then back the interface with the RabbitMQ java lib. Your
>> use case may be to provide migration without having to change client
>> code. Some concepts might be mappable between JMS and AMQP, e.g.
>> Connection(Factories), Sessions (Channels?) and Destinations (Queues),
>> but if you would have to bear in mind that this would probably not
>> pass a TCK, especially wrt transactions.
> At least initially, this second approach is strongly preferable in
> being far easier to implement and manage IMO.  The creation of an
> AMQPTemplate and suitable factories using the RabbitMQ Java client
> would deliver the required integration.  These should follow the
> example of the corresponding JMS tooling classes.  With this done then
> other more generic integration could be thought about and then
> achieved.
>> As for Camel, although I'm not an expert, isn't part of the value-add
>> of Camel be able to abstract away different message passing paradigms
>> and so therefore AMQP would be just another transport?
> I am not an expert either but I agree with this and suspect the
> pattern would be similar to that for other message based integration
> toolkits such as Mule, which used the RabbitMQ Java client directly
> without needing to go via JMS or Spring.  It was not much work at all.
> alexis
>> Ben
>> _______________________________________________
>> rabbitmq-discuss mailing list
>> rabbitmq-discuss at lists.rabbitmq.com
>> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

More information about the rabbitmq-discuss mailing list