[rabbitmq-discuss] RabbitMQ / Spring integration

[Alexis Richardson]

Mark

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.

Understood.



> 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
.NET.


> 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?

alexis






> 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
>>
>
>