Hi Danushaka, The Scientific Use Case demands from the WS-Messenger are documented in [1] and [2]. If we look at the use of WS-Messenger, it is primarily three fold:
* Easy integration for Gateway Interfaces which are implemented in multiple programming languages * Scalable so all of Airavata internal systems can use the eventing for rapid communications * Easily support the Web Based Real-Time workflow monitoring - currently supported by the Workflow Tracking Schema. I am not sure if we can make a call on JMS vs AMQP and not sure one will be better to address the three usage modes described above. So I would suggest your project have proof of concepts so you can come up with a recommendation on what eventing system will be good for Airavata internal and external client communications. Also please make your project align with the master project, so you can provide some working solution so the Web Based project can subscribe and provide real-time monitoring capabilities. Suresh [1] - http://www.extreme.indiana.edu/xgws/messenger/doc/HuangY-WSMessenger.pdf [2] - http://pervasive.iu.edu/sites/default/files/SimmhanIPAW06.pdf On May 1, 2013, at 1:33 PM, Danushka Menikkumbura <[email protected]> wrote: > Hi, > > I am currently working on my GSoC proposal based on AIRAVATA-339 and trying > to figure out what exactly the scientific community would expect from > having support for AMQP in the WS-Messenger?. > > For an example why not JMS but AMQP?. I would say AMQP is quite rich in > terms of pub/sub semantics compared to JMS and also its extensible and > interoperable wire-level binary protocol would count as well. Anyways I > wonder if there are any specific requirements when it comes to scientific > computing paradigm. Because as far as I know, it originated at JPMorgan > Chase targeting the financial community. > > Please shed some light on this. > > Thanks, > Danushka
