RE: MOM and reliable messaging article by Chris

I read the article and I found the section "WS-ReliableMessaging as middleware interoperability protocol" both interesting and unclear regarding the proposed solution. The section says:

"We believe that the most important prospect for the WS-ReliableMessaging protocol will be to provide the standard protocol for interoperability between different vendors' message oriented middleware environments. In this scenario, we envisage that WS-ReliableMessaging would be augmented with a set of standardized WSDL portTypes and bindings that would be specific to endpoint managers. These standardized portTypes and bindings would be implemented by vendors of messaging middleware products to enable messages from other middleware environments to be reliably, and interoperably exchanged with their own".

What is not clear to me is what type of transport the WS-ReliableMessaging protocol would use in this scenario. Would it be HTTP? Would it be a new transport specifically designed to support reliable messaging and still to be standardized? (Evidently it cannot be one of the existing MOM protocols, or JMS providers, since they all have their own wire protocol implementation and only one endpoint manager would be able to understand it).

Ugo 

> -----Original Message-----
> From: Champion, Mike [mailto:Mike.Champion@softwareag-usa.com]
> Sent: Friday, May 09, 2003 2:11 PM
> To: www-ws-arch@w3.org
> Subject: MOM and reliable messaging article by Chris
> 
> 
> 
> http://www-106.ibm.com/developerworks/webservices/library/ws-rmimp/
> 
> Implementation strategies for WS-ReliableMessaging
> 
> Christopher Ferris (chrisfer@us.ibm.com), IBM
> John Ibbotson (john_ibbotson@uk.ibm.com), IBM
> Tony Storey (tony_storey@uk.ibm.com), IBM
> May 5, 2003
> This paper discusses considerations for realizing robustness, 
> integrity, and
> performance required for reliable messaging implementations using the
> recently released WS-ReliableMessaging specification and 
> describes the role
> of message oriented middleware to address these.
> 
>

Received on Monday, 12 May 2003 13:46:55 UTC