[rabbitmq-discuss] RabbitMQ / Spring integration

[carlos.quiroz-castro at nokia.com]

Hi 

>-----Original Message-----
>From: alexis.richardson at gmail.com 
>[mailto:alexis.richardson at gmail.com] On Behalf Of ext Alexis Richardson
>Sent: 19 August, 2008 14:20
>To: Ben Hood
>Cc: Quiroz-Castro Carlos (Nokia-NRC/Helsinki); 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.

I'd also see that as a way to go for a lightweitght style integration. A
simple component with a set of configuration options that you could use
in the form rabbitmq:queue:myqueue or something along those lines

I'd certainly be quite interested to contribute. My interest is on an
application that uses messaging and that is currently limited on the
amount of clients the messaging queue can support (Not throughput so
much). For that the rabbitmq/erlang concurrentcy architecture should, at
least in theory provide a solid advantage.

Regards
Carlos Quiroz

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