W3C home > Mailing lists > Public > www-ws-desc@w3.org > July 2004

RE: Revised Asynch Binding

From: Ugo Corda <UCorda@SeeBeyond.com>
Date: Thu, 8 Jul 2004 08:13:03 -0700
Message-ID: <EDDE2977F3D216428E903370E3EBDDC9032B8B56@MAIL01.stc.com>
To: <paul.downey@bt.com>, <sanjiva@watson.ibm.com>, <www-ws-desc@w3.org>

Please see below.

> -----Original Message-----
> From: paul.downey@bt.com [mailto:paul.downey@bt.com] 
> Sent: Thursday, July 08, 2004 5:49 AM
> To: Ugo Corda; sanjiva@watson.ibm.com; www-ws-desc@w3.org
> Subject: RE: Revised Asynch Binding
> Ugo wrote:
> > Even if we are currently only talking in abstract terms about
> > the capabilities needed to support asynchronous messaging (since 
> > we cannot refer to a concrete established standard), I suggest that 
> > we explicitly mention in our wording both the concept of addressing 
> > and the concept of correlation/reference, given the fact that they 
> > are both essential components of asynchronous messaging. 
> +1 to explaining the concepts separately
> > If the industry settles on WS-Addressing and/or WS-MD, all the
> > better: both concepts are already supported in those two specs.
> you said earlier: addressing and correlation are 'orthogonal'. 
> Whilst i'd agree in principle, in practice i'm finding it hard to 
> imagine employing one without the other. i'd like to hear a use-case 
> for a service which has one mechanism for addressing and a different 
> method for message correlation. 

Correlation could also be based on particular content of the exchanged
message having some business significance, for example request and
response sharing the same value for the purchase order. This is a
mechanism used extensively in BPEL, for example, and is independent from
the addressing mechanism used.

> at the very least i think the default for a separate correlation 
> feature (if we define one) should be the addressing feature.
> Paul
Received on Thursday, 8 July 2004 11:13:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:54:49 UTC