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 Sunday, 18 March 2001 00:19:42 UTC