[rabbitmq-discuss] RabbitMQ / Spring integration

Wed Aug 20 10:25:10 BST 2008

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