1. © 2007 Open Grid Forum OGSA Message Broker Service - MBS proposal OGF19 OGSA-WG session #3 Abdeslem DJAOUI 30 January, 2007 9-10:30pm Chapel Hill, NC

2. © 2007 Open Grid Forum 2 Agenda Rationale for a message broker service Requirements Message patterns Messages, routers and queues Relation to existing system

3. © 2007 Open Grid Forum 3 Rationale Grid application = distributed, coordinated activities Applications require more than orchestration of input and output messages between two partner services. Coupling two or more complex activities reliably and efficiently Asynchronous messaging is necessary for robust distributed applications Existing messaging systems founded on proprietary technology – interoperability difficult Need: Standard, Interoperable, Asynchronous, Reliable messaging

4. © 2007 Open Grid Forum 4 requirements To support OGSA based applications that need coupling/coordination, not just point-to-point exchanges To permit applications to dynamically adjust/control routing and queuing of messages To accommodate relevant messaging systems and APIs And to extend them where necessary To allow federations of OGSA brokers to interoperate, in delivering messages

5. © 2007 Open Grid Forum 5 Typical Message patterns Store and forward Reliable messaging Group communication Multicast/Broadcast patterns, one-to-many Many-to-many Pub/Sub and Callback

6. © 2007 Open Grid Forum 6 Messages, routers and queues A message is a SOAP message with headers and body Coordination context Secureconversation token, … Headers also contain routing information E.g: Subscription topic as destination address A router uses the routing information to send the message to a queue or to another router

7. © 2007 Open Grid Forum 7 Example interfaces Client/MBS CreateQueue() SendMessage() Subscribe() MBS/MBS Essentially one MBS acts as a client to another MBS Parallel with EMAIL Email works by using DNS for routing purposes Parallel with IP multicast Add reliability

8. © 2007 Open Grid Forum 8 Relation to existing systems Relevant existing systems: NaradaBrokering, Mule, JMS, WSN, … No standard interface for various MEPs No standard for QoS properties E.g. Transacted exchanges No standard for inter-broker communication Existing system could provide implementation or partial implementation MBS is not just another abstraction of existing systems Leverage what is already there and working MBS focuses on new requirements for coordinating/coupling multiple activities new MEPs (reliable multicast) Standard model for QoS (WS-Policies for requirements and capabilities of MBS, routers and queues)

9. © 2007 Open Grid Forum 9 Related work Service Availability Forum High availability and management interfaces http://www.saforum.org/home Implementation Openais http://www.jgroups.org Reliable multicast Not just UDP