airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lahiru Gunathilake <glah...@gmail.com>
Subject Re: Initiating GSoC Project - JSON support and JSON to XML bidirectional conversion for Airavata
Date Thu, 13 Jun 2013 19:20:59 GMT
I am +1 for the first approach. Our original plan is to have a solid web
application to support science gateway developers to easily develop their
gateway without dealing with too much complexity in the backend.

So once we have it running, we really don't need to maintain two apis (we
might use java thing internally).

Lahiru


On Thu, Jun 13, 2013 at 3:14 PM, Shameera Rathnayaka <shameerainfo@gmail.com
> wrote:

> 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/
>



-- 
System Analyst Programmer
PTI Lab
Indiana University

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