airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Danushka Menikkumbura <>
Subject Re: Initiating GSoC Project - JSON support and JSON to XML bidirectional conversion for Airavata
Date Sun, 09 Jun 2013 01:10:48 GMT
Hi Vijayendra,

I want to know where do we implement RabbitMQ message broker. As RabbitMQ
> implements AMQP. Where exactly are we going to implement this and where
> exactly
> RabbitMQ clients(publisher) be?  It would be better if you can put it in a
> diagram. I am not able to see any of your diagrams in the proposal.
> How exactly messaging system fits in the fig1.(shameera's diagram) ?

The RabbitMQ broker will run independently. We will have a Java client API
to facilitate publish/subscribe to the broker and necessary bits in the
JSON/XML library to wrap those calls.

> one more question is, as we are implementing AMQP  a wire-level protocol
> standard for messaging, AMQP
>  specification essentially creates a message-based interoperability model.
> This means that as long as you are using AMQP you can connect and send
> message to
> any AMQP message broker using any AMQP client.
> Are we doing away with traditional and popular JMS ?? I don't see the need
> of that any more.

Yes.We do not need JMS here. As you have mentioned, since AMQP defines a
standard wire-level protocol, different implementations are ought to be
inter-operable, nevertheless it is more theoretical than practical :-).
Anyway I know that a Qpid/Java client can talk to a Qpid/C++ broker without
any issue.

> I also came across another AMQP messaging system Apache Qpid.
> I want to know Why are we not thinking of using this? Why RabbitMQ ? I am
> new to both of them :) .

The main reasons why we opted for RabbitMQ were its rich user community and
its robustness. I have mixed feelings about Qpid. On the good side, the C++
implementation is very robust and well-written. We could have used the
Qpid/C++ broker. On the bad (sad) side, the Java broker nor the client API
is robust. There are(were) lots of memory leaks that are very difficult to
live with, and few other issues.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message