Mailing-List: contact dev-help@airavata.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@airavata.apache.org
Received-SPF: pass (nike.apache.org: domain of shameerainfo@gmail.com
 designates 209.85.128.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <7E5B7D21-420A-4A79-BE5F-1A8D021A3917@apache.org>
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>
 <CAJvLytpcXpx=qeNgJYWJcz7_sy3xH3gAF0N5SwVR13_+rcvm+w@mail.gmail.com>
 <CAKq9_6KGenNb5pgivq+hG_6WXXEjdXU8yKgO_tqmvjd4BBHxjQ@mail.gmail.com>
 <CAF-nVSmPmPeAxVc7JU=Qf4FcFoiG1XG-ZriPGf4p7kfjnEmbPQ@mail.gmail.com>
 <CAF4V=3HKCTewfx2PRwEMfR8prvhUbATfiRhB-1D5Kyp7NpqVGg@mail.gmail.com>
 <7E5B7D21-420A-4A79-BE5F-1A8D021A3917@apache.org>
From: Shameera Rathnayaka <shameerainfo@gmail.com>
Date: Tue, 25 Jun 2013 08:34:59 +0530
Message-ID: 
 <CAJvLytr=o7HWa1fN12MgeXimU7A6MXL97VMpGa7GwKREmGgo-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>
Content-Type: multipart/alternative; boundary=20cf307f38d0a2d6c804dff1cc31

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

Hi Suresh,

I already have written JSON to XML bridge for workflow interpreter. Now
working on registry side implementation.We(Lahiru and me) are talking
about  a best way to support existing rest api  too with this
implementations.

Thanks,
Shameera.


On Tue, Jun 25, 2013 at 8:18 AM, Suresh Marru <smarru@apache.org> wrote:

> On Jun 24, 2013, at 10:38 PM, Danushka Menikkumbura <
> danushka.menikkumbura@gmail.com> wrote:
>
> > Hi Vijayendra,
> >
> > I am almost done with the WS-Messenger AMQP client API. As we have
> > discussed thus far, the plan is to wrap Java API calls in the JS API. Can
> > you please own the pub/sub bits in the JS library?. I will provide you
> with
> > a patch for the Java interfaces. With that we should be able to work in
> > parallel. Please stick the source directory structure as we have
> discussed
> > on the other thread. Please holler if you have any issues.
>
> This is very exciting to hear. As soon as we agree upon the repo structure
> lets gets the patches in.
>
> Suresh
>
> >
> > Cheers,
> > Danushka
> >
> >
> > On Tue, Jun 25, 2013 at 12:11 AM, Vijayendra Grampurohit <
> > vijayendra.sdm@gmail.com> wrote:
> >
> >> Hi Dhanushka/All
> >>
> >> Can we start discussing here what all
> technologies/libraries/implemention
> >> are we going to
> >> for AMQP and Monitoring module?
> >>
> >> At the client side i.e for monitoring module we can use  nodejs +
> socketio.
> >> How are we implementing Rabbitmq pub/sub .
> >> I came across [1] for this. What do you think about this?
> >>
> >>
> >> [1] https://github.com/squaremo/rabbit.js
> >>
> >>
> >>
> >> On Mon, Jun 24, 2013 at 4:47 PM, Vijayendra Grampurohit <
> >> vijayendra.sdm@gmail.com> wrote:
> >>
> >>> Hi
> >>>
> >>> Yesterday I was looking at rabbitMq + webmessaging [1].  Then I was
> >>> playing around
> >>> nodejs.
> >>>
> >>>
> >>> Currently The monitoring system (messaging) is implemented via pub/sub
> >>> model and messages are sent(published) to xbaya monitoring.
> >>>
> >>> As a part of GSoC we are writing a API to convert xml data to JSON.
> >>>
> >>>
> >>> Why cant we connect to the API (which converts xml to json) and fetch
> >> JSON
> >>> data using nodejs.
> >>> and then using websockets with nodejs we can easily come up with
> >>> browser based monitoring system.
> >>> nodejs+websockets(socketio) is all we require. Am I missing here
> >> something
> >>> ?
> >>>
> >>> Yesterday I was writing a application wherein I was trying to
> >>> display real time twitter streaming data in the browser using
> >>> nodejs+socketio.
> >>> Hence I got the above idea. Please let me know I am missing
> >>> some thing above.
> >>>
> >>> Regards
> >>> Vijayendra
> >>>
> >>>
> >>>
> >>> On Fri, Jun 14, 2013 at 12:50 AM, Lahiru Gunathilake <
> glahiru@gmail.com
> >>> wrote:
> >>>
> >>>> 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
> >>>>
> >>>
> >>>
> >>
>
>


-- 
Best Regards,
Shameera Rathnayaka.

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

--20cf307f38d0a2d6c804dff1cc31--