RE: Correlation [was: Transaction IDs]

ebXML uses a MessageId element to uniquely identify each message. A
RefToMessageId element is used to correlate messages. This message level
binding makes it possible to correlate messages regardless of which
transport mechanisms are used during a message exchange.

If the group consensus is to include a means to correlate messages as part
of XMLP then I suggest the group consider ebXML's solution.

Dick Brooks
Group 8760
110 12th Street North
Birmingham, AL 35203
dick@8760.com
205-250-8053
Fax: 205-250-8057
http://www.8760.com/

InsideAgent - Empowering e-commerce solutions

> -----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 11: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 Sunday, 18 March 2001 14:16:24 UTC