[ogsa-wg] OGSA message broker service

[Geoffrey Fox]

You might want to look at Enterprise Grid work using Mule 
http:mule.codehaus.org by Israeli association of Grid Technologies 
http:www.grid.org.il
With OGF there is long running activity called INFOD and of course there 
is WS-Eventing/Notification and their merger
Apache Synapse project addresses some relevant issues
We use publish-subscribe http://www.naradabrokering.org in nearly all 
projects we have -- especially for real-time sensors

Djaoui, A (Abdeslem) wrote:
> 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
> --
>   ogsa-wg mailing list
>   ogsa-wg at ogf.org
>   http://www.ogf.org/mailman/listinfo/ogsa-wg
>
>   

-- 
:
: Geoffrey Fox  gcf at indiana.edu FAX 8128567972 http://www.infomall.org
: Phones Cell 812-219-4643 Home 8123239196 Lab 8128567977
: SkypeIn 812-669-0772 with voicemail, International cell 8123910207