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 < [email protected]> 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 <[email protected]>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 < >> [email protected] >> > 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 < >> > [email protected]> 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 >> > >
