On Thu, Mar 28, 2013 at 5:31 PM, Danushka Menikkumbura <[email protected]> wrote: > Hi Suresh, > > The AMQP exchanges fit the Airavata notification model quite nicely. > Basically we can map elements in the workflow tracking schema to the > Header/Topic exchanges (or even to Direct/Fanout exchanges). For an > example, we can define a topic (MyTopic) and associate few message types in > the schema with it so that whoever subscribes to MyTopic would receive > those messages. Furthermore we can let subscribers have durable > subscriptions so that the messages will get stored and forwarded in case > the subscriber in on an unreliable network. Likewise we can make use of the > rich set of building blocks available in AMQP model to have a very robust > notification framework. > > RabbitMQ has a nice article [1] about the AMQP model that explains > different types of exchanges, etc nicely. I suggest you read the "Exchanges > and Exchange Types" section.
Hi Danushka, I am not overly familiar with AMQP. But I am just curious to know, which AMQP implementation you suggest for Airavata ? (Knowing Airavata requirements) Thanks Amila > > [1] - http://www.rabbitmq.com/tutorials/amqp-concepts.html > > Thanks, > Danushka > > > On Thu, Mar 28, 2013 at 1:48 AM, Suresh Marru <[email protected]> wrote: > >> Hi Danushka, >> >> Good thinking, I agree with you for the most part. There are few other >> concrete use cases I can suggest, but let me get your thoughts on a >> particular example: >> >> Currently WS-Eventing is used to track workflow progress. In reality its >> not so much of the eventing spec, but the Airavata Information Model which >> is currently based on Workflow Tracking schema [1]. As you can see form the >> Web Based XBaya discussion, if a light weight java script based workflow >> GUI has to monitor progress and show real-time status (like the current >> color coded), would you say AMQP has any additional advantages? Or if you >> were to design from scratch, what would you pick which can build upon a >> pre-defined information model. >> >> Suresh >> [1] - >> https://svn.apache.org/repos/asf/airavata/trunk/modules/commons/workflow-tracking/src/main/resources/schemas/workflow_tracking_types.xsd >> >> On Mar 27, 2013, at 4:07 PM, Danushka Menikkumbura < >> [email protected]> wrote: >> >> > Hi, >> > >> > When I go through [1], I get the impression that what we really need is >> an >> > extensible event bus that can provide notification push/pull >> functionality >> > so that a gateway developer has the flexibility to come up with his own >> > protocol for receiving notifications. At a very higher level the >> messenger >> > would have two main layers, the routing layer and the transport layer. We >> > would have the routing rules defined in the routing layer that makes >> > notifications available to different transports, such as WS-Notification, >> > WS-Eventing, file, mail, AMQP, JMS, etc or any other custom type >> developed >> > as you wish. >> > >> > Along the line of AMQP, basically the requirements could be twofold. >> > >> > 1. AMQP broker semantics to support pub/sub behavior >> > 2. AMPQ wire-level format >> > >> > I am not quite sure which makes AMQP more appealing to the scientific >> > community, specially in environments like XSEDE. Furthermore, I would >> like >> > to know a typical scenario, either real or hypothetical that could >> exploit >> > the capabilities of AMQP. >> > >> > [1] - https://issues.apache.org/jira/browse/AIRAVATA-339 >> > >> > Thanks, >> > Danushka >> >>
