RE: Correlation [was: Transaction IDs]

My concern about not providing a default correlation ID scheme for XMLP is
that it means there will not be standarization of this feature.  I would
like the default cid scheme to be global across the Modules.  

I haven't heard any reason why we shouldn't standardize the default
correlation id scheme, except that they can evolve.  Yet I think we have
enough experience with cids to standardize this.  I'd like to snapshot the
evolution of cids for implementations so that we don't have to create
something at a vocabulary level. 

My counter paragraph in the straw-man is 

Explicit correlation is provided by a Module. The definition of a default
mechanism is in scope for XML Protocol. Explicit correlation may be used
over transport bindings with implicit correlations, in which case it
overrides implicit correlation of the messages, from XMLP's view.

Dave Orchard
XML Architect
Jamcracker Inc.,    19000 Homestead Dr., Cupertino, CA 95014
p: 408.864.5118     m: 604.908.8425    f: 408.725.4310

www.jamcracker.com - Sounds like a job for Jamcracker.

> -----Original Message-----
> From: xml-dist-app-request@w3.org 
> [mailto:xml-dist-app-request@w3.org]On
> Behalf Of Mark Nottingham
> Sent: Saturday, March 17, 2001 9:20 PM
> To: Williams, Stuart
> Cc: 'frystyk@microsoft.com'; 'Orchard, David'; XML Distributed
> Applications List
> Subject: Correlation [was: Transaction IDs]
> 
> 
> 
> [moving this over to dist-app]
> 
> I've been thinking of correlation as being supplied by either a) a
> Module or b) implicit in the transport binding. This seems to fit
> with Jeff's #1, except that explicit correlation is supplied by a
> module, rather than included in the envelope.
> 
> To me, this makes the most sense because it allows us to move forward
> (correlation *is* supplied implicitly in the HTTP binding's message
> exchange pattern, satisfying the immediate need and most common use
> case of RPC), while allowing correlation mechanisms to evolve, rather
> than baking them into the envelope.
> 
> Here's a straw-man definition of correlation that I've been thinking
> about. Comments appreciated.
> 
> Correlation
> 
> Many XML Protocol applications will require multi-message exchanges,
> where individual messages are correlated by some means.
> 
> Correlation provides a way to associate an arbitrary number of
> messsages with each other, and may be provided either implicitly, in
> the protocol binding, or explicitly, in a Module. Correlated messages
> can be used to build an XMLP Application's message exchange pattern.
> 
> Implicit correlation is defined by a transport binding, and is
> restricted by the nature of the transport. For example, HTTP has a
> 1:1 request/response correlation; a request message is correlated
> with its accompanying response message. An XMLP Application may use
> implicit correlation when there is some knowledge of the transport
> binding being used, and the transport binding's message exchange
> pattern can accommodate the XMLP Application's in a single
> invocation.
> 
> Explicit correlation is provided by a Module. The definition of such
> a mechanism is out of scope for XML Protocol. Explicit correlation
> may be used over transport bindings with implicit correlations, in
> which case it overrides implicit correlation of the messages, from
> XMLP's view.
> 
> 
> 
> message path implications, routing
> 
> 
> 
> On Fri, Mar 16, 2001 at 03:21:18PM -0000, Williams, Stuart wrote:
> > Hi Henrik,
> > 
> > > -----Original Message-----
> > > From: Henrik Frystyk Nielsen [mailto:frystyk@microsoft.com]
> > > Sent: 15 March 2001 02:35
> > > To: 'Orchard, David'; w3c-xml-protocol-wg@w3.org
> > > Subject: RE: [i44] Transaction IDs
> > > 
> > 
> > <snip/> 
> > 
> > > One of the basic assumptions about XMLP is that we can 
> extend the set of
> > > services by filling in "XMLP Modules" to do the work. 
> Modules are likely
> > > to be all over the map - some are very specific to 
> certain applications
> > > while others are general to lots of applications which 
> means that they
> > > have to compose well. I consider the latter as obvious 
> candidates for
> > > standardization as they will be used again and again.
> > > 
> > > I think it is fairly uncontroversial to consider message 
> correlation to
> > > be in the latter group.
> > 
> > I don't think I'm as convinced as you that this is 
> uncontrovertial - SOAP as
> > it is used today does message correlation and it doesn't 
> seem do it using a
> > module. 
> > 
> > > However, I would argue, that we should use the
> > > composability model in XMLP to accommodate this feature 
> just as well as
> > > we will accommodate an open-ended set of other features. 
> Unless anybody
> > > can provide proof that this is not possible I would 
> therefore suggest
> > > that we use the XMLP Module mechanism for defining 
> features like message
> > > correlation as well as any other feature that doesn't 
> absolutely have to
> > > be in XMLP itself because otherwise we would not be able 
> to build a
> > > reliable system. 
> > 
> > I think the burden of proof, specifically wrt to message 
> correlation, lies
> > the other way round.
> > 
> > > 
> > > Henrik
> > > 
> > > [10] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x44
> > > [11]
> > 
http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2001Mar/0027.html
> 
> <snip/>
> 
> Stuart

-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA USA)

Received on Thursday, 22 March 2001 16:39:50 UTC