Mailing-List: contact dev-help@airavata.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@airavata.apache.org
Received-SPF: pass (athena.apache.org: domain of shameerainfo@gmail.com
 designates 209.85.128.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAF4V=3FaRn_KnTcvNs=83qoBwfXib4y1jD3nzE8Rq0YpnxsKoQ@mail.gmail.com>
References: 
 <CAJvLytpxWzUucFvU33_0UL+PPnT-rvJin9UfYkZ-JMLjKOOAbA@mail.gmail.com>
 <CAF4V=3EAgCqztzrMmQk_YjT40pvsSstRBeiz1_qaDi9L6L4UsQ@mail.gmail.com>
 <CAJvLytqd6+oij8dqcCSZyLNZNgL69DZCh4meT=McXbsRBxvBOw@mail.gmail.com>
 <CAF4V=3GTPCjaiRS7giocrX0OFmki-WwuU-pJEUfy_DZYt6M9FQ@mail.gmail.com>
 <CAJvLytp6oLyEAG4Yp-2EfixmfUgQ=akxTqt=4DzjzWOLwjXLVA@mail.gmail.com>
 <CAKUcLKb8b4LnpF9Shj9E7zQE7W7eT8NRB_-TNPvmYaoDsX51rA@mail.gmail.com>
 <51B08CA7.7010002@iu.edu> <56CDE5CC-C79B-4FC3-A566-6935FA12412F@gmail.com>
 <CAF4V=3HymaqbSGaJSzAshCPoijRYvPALNKk8hmD8ZvPbaPdhkw@mail.gmail.com>
 <241964AD-D670-4BF6-B7BD-0FCA78033E1C@gmail.com>
 <CAJvLytrwd48QowHrSAS+iAXz_WXetFRyGhbFnP1KYVYRLocwVg@mail.gmail.com>
 <CAF-nVSm-3rcuEQYiL0iy-+nmFDrxD0HBLp2gLfLtpaqyd22WtQ@mail.gmail.com>
 <CAF4V=3FaRn_KnTcvNs=83qoBwfXib4y1jD3nzE8Rq0YpnxsKoQ@mail.gmail.com>
From: Shameera Rathnayaka <shameerainfo@gmail.com>
Date: Fri, 14 Jun 2013 00:44:41 +0530
Message-ID: 
 <CAJvLytpcXpx=qeNgJYWJcz7_sy3xH3gAF0N5SwVR13_+rcvm+w@mail.gmail.com>
Subject: Re: Initiating GSoC Project - JSON support and JSON to XML
 bidirectional conversion for Airavata
To: dev <dev@airavata.apache.org>
Cc: Lahiru Gunathilake <glahiru@gmail.com>
Content-Type: multipart/alternative; boundary=20cf307cfd8c7622a404df0df222

--20cf307cfd8c7622a404df0df222
Content-Type: text/plain; charset=ISO-8859-1

Hi all,

According to the above suggestions now we have 3 options. Here i have
summarized all pros and cons of each option. Still need some help on
selecting best one. If it is possible, it would be good to have a hangout
session for this.

*1. Write a new JS Client*
*pros *
Don't need to get mixed with java
Better tooling support
Perfectly match with front-end developments

*cons *
Have to maintain two APIs
Need more effort to make it stable

*2.Extend Airavata java client API to use JSON as it's underline data
fromat.Call this API withing JS code. *
*pros*
Single API, easy to manage
Already stable component

*cons*
Front-end mixed with java
Lack of tooling support

*3.Write a new JS API by wrapping extended Airavata java client, which use
JSON as data format.* (This is combination of option 1 and 2)
*pros and cons*
Front-end developer has all pros and cons of option 1
API provider has all pros and cons of option 2


I personally don't think Airavata need two GUIs (XBaya and Web UI) for
front end. We can gradually navigate to web based UI from XBaya. Then we
don't need to maintain two APIs if we choose first option.

As there is no any concerns for provided conversion, we can select it as
our standard, WDYT?

Cheers,
Shameera.


On Sun, Jun 9, 2013 at 6:40 AM, Danushka Menikkumbura <
danushka.menikkumbura@gmail.com> wrote:

> 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.
>
> Thanks,
> Danushka
>


-- 
Best Regards,
Shameera Rathnayaka.

email: shameera AT apache.org , shameerainfo AT gmail.com
Blog : http://shameerarathnayaka.blogspot.com/

--20cf307cfd8c7622a404df0df222--