[rabbitmq-discuss] RabbitMQ / Spring integration

Thu Aug 21 10:51:00 BST 2008

Hi Alex

I'll have a got at first at sending messages over camel to rabbitmq,
that should be enough to see if the concept makes sense. Receiving
messages often requires some extra work.

I'll share my findings with the list 

Regards
Carlos Quiroz

>-----Original Message-----
>From: alexis.richardson at gmail.com 
>[mailto:alexis.richardson at gmail.com] On Behalf Of ext Alexis Richardson
>Sent: 20 August, 2008 12:25
>To: Quiroz-Castro Carlos (Nokia-NRC/Helsinki)
>Cc: rabbitmq-discuss at lists.rabbitmq.com
>Subject: Re: [rabbitmq-discuss] RabbitMQ / Spring integration
>
>Carlos
>
>I am going to combine your two emails into one.
>
>> 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).
>
>Good.  You'll find AMQP a bit richer in its behaviour but 
>RabbitMQ's Java client and docs should provide enough guidance 
>to make the core use cases obvious.
>
>
>> 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
>
>Right.  So this adaptor assumes Qpid whose Java API is more 
>JMS-like than RabbitMQ's which is more plain ole Java.  
>Refactoring the Camel adaptor to simple Java oughtn't to be a 
>problem for you but it might be useful to discuss a few cases 
>on this list.  Do you want to have a go with one or two 
>methods and we can talk through them with you?
>
>
>
>
>> 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.
>
>Yes, this is a good goal.
>
>
>> 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.
>
>One would hope so :-)
>
>
>On Wed, Aug 20, 2008 at 8:20 AM,  
><carlos.quiroz-castro at nokia.com> wrote:
>>
>>>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.
>
>Excellent - do you have enough to get started?  Again, feel 
>free to show your working on the list.  Not only will people 
>help, but the use cases will be helpful in understanding how 
>the Java client can be improved.
>
>alexis
>