Erlang/OTP Forums

Author Message

<  RabbitMQ mailing list  ~  JMS/AMQP use case

Guest
Posted: Tue Jan 05, 2010 7:33 am Reply with quote
Guest
Hi all,

We currently use JMS between a lot of internal components, and also
expose a JMS interface externally (a set of topics) to our customers. As
JMS is a Java only thing, we are looking into language neutral
alternatives for the customer facing interface. The AMQP standard seems
to fit our needs, but I haven't figured out yet what the ideal
deployment scenario (with rabbitMQ) would be.

Is it possible (and desirable) to continue using JMS internally (without
rabbitMQ) in a first phase, and have an AMQP interface on top of it? If
so, could you give me some hints on how the setup would be than. I guess
I need to deploy the rabbitMQ server, and develop some component which
makes the "bridge" between JMS and AMQP (listening to incoming JMS
messages and "forwarding" them to the rabbitMQ server or something like
that).

Does this sound like a good idea at all, or should I maybe try to use
rabbitMQ as the underlying implementation for the internal JMS as well?

I'm sorry if these are newbie questions... The individual pieces of
documentation seem comprehensive enough, but I currently fail to get the
overall idea of how to apply it to my use case (could be me of course).

Thanks in advance,
Jan

_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post received from mailinglist
Guest
Posted: Tue Jan 05, 2010 11:07 am Reply with quote
Guest
Jan,

Thanks for your question.

On Tue, Jan 5, 2010 at 7:32 AM, Jan Van Besien <janvanbesien@gmail.com> wrote:
> Hi all,
>
> We currently use JMS between a lot of internal components, and also
> expose a JMS interface externally (a set of topics) to our customers. As
> JMS is a Java only thing, we are looking into language neutral
> alternatives for the customer facing interface. The AMQP standard seems
> to fit our needs, but I haven't figured out yet what the ideal
> deployment scenario (with rabbitMQ) would be.
>
> Is it possible (and desirable) to continue using JMS internally (without
> rabbitMQ) in a first phase, and have an AMQP interface on top of it?

Yes and no Wink

It's not really possible to do this in an elegant ('built in to the
broker') way at the moment. The AMQP model is more general than JMS,
making it hard to model AMQP from JMS without (in effect) building a
Java AMQP broker from scratch. On the other hand, because AMQP is
more general than JMS, providing a JMS interface to an AMQP broker has
been done, modulo some warts and gotchas.

It may get easier to expose AMQP interfaces to JMS brokers when we
finally reach AMQP 1.0. This is intended to be factored in such a way
that 'legacy' message brokers can expose AMQP message formats but not
full behaviours. This would be similar, in effect, to how a JMS
broker might expose a STOMP interface today.

That said....

> If
> so, could you give me some hints on how the setup would be than.

Despite my remarks above, about AMQP being more general than JMS, this
is certainly something you could try. Let's say you want to run JMS
as your core system and gradually layer AMQP on top of it. You could:

1. Install and run RabbitMQ
2. Set up some queues and bindings (perhaps, one for each of your public topics)
3. Publish AMQP messages to RabbitMQ
4. Consume AMQP messages from RabbitMQ using a Java client.
5. In the same Java client, create JMS messages from the payloads of
the AMQP and forward them to your JMS system

You could do the above yourself, and it would work, but with some
drawbacks I am sure I don't need to enumerate. Indeed, this approach
could potentially be extended to something a bit more robust.

*Alternatively*

Have you looked at STOMP? If your infra requires JMS based messaging
inside for some time, then STOMP is one way to cross the language
barrier. It's not as powerful as AMQP for defining broker behaviour
(routing, delivery, qos), but, you don't always need that.





> I guess
> I need to deploy the rabbitMQ server, and develop some component which
> makes the "bridge" between JMS and AMQP (listening to incoming JMS
> messages and "forwarding" them to the rabbitMQ server or something like
> that).

Well, now you are asking a different question Smile

Above I described how to expose a JMS infra using some sort of AMQP
gateway, so that you could send messages to RabbitMQ in AMQP and
forward them to JMS brokers.

If you want to do this the other way round, ie. send JMS messages to
RabbitMQ, then you can use the JMS client.

Note that:

1) Because JMS is an API not a protocol, it is possible to expose it
on the client side 100%, and use any protocol you like to communicate
between your JMS client and your broker. This by the way raises the
question "what is a JMS broker?". And the answer is: "something that
has a JMS client". Go figure.

2) Because AMQP's model is somewhat different from JMS, not all of the
JMS 'TCK' API is modelled in the current JMS clients.

3) Not very many people use JMS with RabbitMQ, so I am not sure what
currently works with what.

Here is a 'how to' -
http://www.lshift.net/blog/2009/03/16/openamqs-jms-client-with-rabbitmq-server

We hope to make all this much easier to run OOTB very soon.



> Does this sound like a good idea at all, or should I maybe try to use
> rabbitMQ as the underlying implementation for the internal JMS as well?

Honestly, it depends on your use case and the extent to which your
existing messaging infra is welded into place.

At this stage I would recommend *experimenting* with some of the
approaches I described above. By all means ask any question on this
list if you get stuck.


> I'm sorry if these are newbie questions... The individual pieces of
> documentation seem comprehensive enough, but I currently fail to get the
> overall idea of how to apply it to my use case (could be me of course).

I am sorry the JMS-AMQP thing is not as clear as it could be.

alexis



> Thanks in advance,
> Jan
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss@lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>

_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post received from mailinglist
Guest
Posted: Tue Jan 05, 2010 2:53 pm Reply with quote
Guest
Many thanks for your answers. This already clarified a lot. It also made
me realise that my question was a bit vague in some parts Wink

Some further remarks inline:

Alexis Richardson wrote:
> 1. Install and run RabbitMQ
> 2. Set up some queues and bindings (perhaps, one for each of your public topics)
> 3. Publish AMQP messages to RabbitMQ
> 4. Consume AMQP messages from RabbitMQ using a Java client.
> 5. In the same Java client, create JMS messages from the payloads of
> the AMQP and forward them to your JMS system

This sounds like a workable aproach to me. Certainly because my setup
will even be a bit easier I think.

What I didn't make clear in my initial question is that the JMS
interface we expose to the "outside" (i.e. the set of topics I
mentioned) is only used to push data from the internal (JMS) system to
external clients. From the perspective of the external clients, it is
read only.

This (I think) means that I wouldn't need to consume AMQP messages from
RabbitMQ (step 4 and 5 above). I would only need an internal component
which consumes JMS messages, turns them into AMQP messages and sends
them to rabbitMQ.
If I understand correctly, the "consume JMS messages" part of that
component would not depend on rabbitMQ at all (just a JMS message
listener), and the "turn into AMQP messages and send to rabbitMQ" can be
done with the rabbitMQ java api.

> *Alternatively*
>
> Have you looked at STOMP? If your infra requires JMS based messaging
> inside for some time, then STOMP is one way to cross the language
> barrier. It's not as powerful as AMQP for defining broker behaviour
> (routing, delivery, qos), but, you don't always need that.

I had never heard of it, but it seems indeed more than enough for my
simple use case. I'll certainly have a closer look at it.

thanks again,
Jan

_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post received from mailinglist
Guest
Posted: Tue Jan 05, 2010 2:56 pm Reply with quote
Guest
Jan

Cool.

Yes, in that case do take a look at STOMP and do take a look at the
JMS client, which lets a publisher speak in JMS to RabbitMQ. The
client turns the JMSy stuff into AMQPy stuff.,.

Note that the RabbitMQ 'Java client' that is on our web site is not
the JMS client that I am referring to. Our main Java client is POJO
AMQP.

alexis


On Tue, Jan 5, 2010 at 2:52 PM, Jan Van Besien <janvanbesien@gmail.com> wrote:
> Many thanks for your answers. This already clarified a lot. It also made
> me realise that my question was a bit vague in some parts Wink
>
> Some further remarks inline:
>
> Alexis Richardson wrote:
>> 1. Install and run RabbitMQ
>> 2. Set up some queues and bindings (perhaps, one for each of your public topics)
>> 3. Publish AMQP messages to RabbitMQ
>> 4. Consume AMQP messages from RabbitMQ using a Java client.
>> 5. In the same Java client, create JMS messages from the payloads of
>> the AMQP and forward them to your JMS system
>
> This sounds like a workable aproach to me. Certainly because my setup
> will even be a bit easier I think.
>
> What I didn't make clear in my initial question is that the JMS
> interface we expose to the "outside" (i.e. the set of topics I
> mentioned) is only used to push data from the internal (JMS) system to
> external clients. From the perspective of the external clients, it is
> read only.
>
> This (I think) means that I wouldn't need to consume AMQP messages from
> RabbitMQ (step 4 and 5 above). I would only need an internal component
> which consumes JMS messages, turns them into AMQP messages and sends
> them to rabbitMQ.
> If I understand correctly, the "consume JMS messages" part of that
> component would not depend on rabbitMQ at all (just a JMS message
> listener), and the "turn into AMQP messages and send to rabbitMQ" can be
> done with the rabbitMQ java api.
>
>> *Alternatively*
>>
>> Have you looked at STOMP?

Display posts from previous:  

All times are GMT
Page 1 of 1
This forum is locked: you cannot post, reply to, or edit topics.

Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum