airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vijayendra Grampurohit <vijayendra....@gmail.com>
Subject Re: Initiating GSoC Project - JSON support and JSON to XML bidirectional conversion for Airavata
Date Tue, 25 Jun 2013 09:28:01 GMT
> > 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?

     Its fine with me. I will work on that. Can you elaborate on wrapping
of java API in the JS . And I think we
are going to use rabbitmq for AMQP and for implementing pub/sub.
Please correct me if I am wrong.

Regards
Vijayendra


On Tue, Jun 25, 2013 at 8:34 AM, Shameera Rathnayaka <shameerainfo@gmail.com
> wrote:

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

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