[rabbitmq-discuss] RabbitMQ / Spring integration

[carlos.quiroz-castro at nokia.com]

Hi

I have to say that I'm no expert on AMQP but I have used quite a bit
camel with both STOMP and OpenWire (ActiveMQ own messaging protocol).
I'd think that an ideal component should try to preserve as much as
possible the semantics of AMQP and for that a generic AMQP adapter could
be quite useful. Camel already has one here:

http://activemq.apache.org/camel/amqp.html

Now, the scenario which interest me more is a very simple one where you
really care very little about the protocol itself and basically care
about destinations, payload and perhaps headers and that is an area
where camel is very good since it allows you to connect to different
messaging entities using different protocols.

For the latter case a rabbitmq direct connection using the java client
would probably suffice and be possibly easier to implement. In any case
you can give your rabbitmq component any configuration file you need for
the specifics of the protocol.

Regards
Carlos Quiroz

>-----Original Message-----
>From: ext Ben Hood [mailto:0x6e6562 at gmail.com] 
>Sent: 19 August, 2008 11:07
>To: Quiroz-Castro Carlos (Nokia-NRC/Helsinki)
>Cc: rabbitmq
>Subject: Re: [rabbitmq-discuss] RabbitMQ / Spring integration
>
>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.
>
>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?
>
>Ben
>