airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shameera Rathnayaka <shameerai...@gmail.com>
Subject Re: Initiating GSoC Project - JSON support and JSON to XML bidirectional conversion for Airavata
Date Tue, 25 Jun 2013 03:04:59 GMT
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