airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Danushka Menikkumbura <danushka.menikkumb...@gmail.com>
Subject Re: Initiating GSoC Project - JSON support and JSON to XML bidirectional conversion for Airavata
Date Tue, 25 Jun 2013 02:38:19 GMT
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.

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

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