When building Grid applications, coordinating ativities may be necessary as pointed out in a recent Email about workflow http://www.ogf.org/pipermail/ogsa-wg/2006-November/002324.html Usually, in traditional Enterprise Application Integration (EAI), the problem is solved using message oriented middleware (MOM) such as JMS. These (MOMs) provide asynchronous point-to-point communication as well as pub/sub capabilities, but Interoperability is difficult to achieve with the existing multitude of proprietary MOMs. Although messaging is briefly described in section 3.9.4.2 (message delivery) of the OGSA specification 1.5, no activity in this area was deemed necessary so far. As OGSA moves beyond the basic service capabilities into service composition, it is necessary to specify a standard message queuing and routing interface, if OGSA is to enable new kinds of useful distributed applications (similar to EAI). Amazon Web Services (AWS) http://aws.amazon.com Recognize the power of message queuing and provide a Simple Queue Service for their customers. In AWS, distributed application components performing different tasks can exchange messages without requiring the receiving party to be ready to receive the message of even be available at the time of exchange. To enable, interoperable message queuing and routing OGSA will need to define similar interfaces (and semantics) for client applications to publish and consume messages to/from OGSA broker services. Broker services accept messages and route them to other brokers or to different consumers. A variety of message patterns will need to be supported (e.g. point-to-point, one-to-many, notification, ...). For OGSA service composition/coordination, it is inevitable for some to draw a parallel with classical massively parallel computer where services playing the role of computer nodes and messaging playing the role of the Message Passing Interface (MPI). Of course there are limitations to this parallel. One is the performance, reliability and latency of messaging system compared to MPI. Another is the need to federate broker services from different security realms having potentially different policies. I would like to start exploring how an OGSA message broker might be used by client applications. An example use case for the discussion could be two (or more) independent BPEL processes (exposed as web services) that need to share/exchange (internal) state information. This currently not possible in WS-BPEL, but is needed for coordinating/coupling distributed activities. See you at OGF19. Abdeslem DJAOUI