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 Mon, 24 Jun 2013 11:17:43 GMT
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