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 <sma...@apache.org> wrote: > On Jun 24, 2013, at 10:38 PM, Danushka Menikkumbura < > danushka.menikkumb...@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....@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....@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 < > glah...@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 < > >>>> shameerai...@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.menikkumb...@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/
