Re: Causality/Correlation

Hi Stuart,
Thanks for your prompt reply. 
>Were you ok. with the XMLP_DATA operation in the abstract model, or is >that
> something whose presence you would also question? My guess would be the
> later

The model that I favor is that of a simple one-way messaging system
(XMLP_UNITDATA without the correlation parameter). By looking at the XML
protocol abstract model, you introduce XMLP_DATA on page 4. However, in
Figure 3.1 you define XMLP_DATA in terms of XMLP_UNITDATA events. (The
only other reference to XMLP_Data comes before Section six or near the
end.) This tells me that XMLP_DATA is redundant. However, I can live
with it. My stronger objection is to the correlation parameter. 

>Simply looking at an XMLP
> message it is not possible to determine whether it is a response to an
> earlier one.

Isn't that the point? That is why it is fundamentally a one-way
messaging system. Again, you could determine whether it is a response to
an earlier message by examining the transfer protocol layer, or this
functionality could be implemented in a module (such as a biztalk 2.0
module). 

In the example described in [1], the answer could be that the XMLP
application uses a module that tracks the correlation ID of the two
requests. Alternatively, a web browser does this today. I'm guessing it
keeps track of the two requests by virtue of using different TCP
connections. 

Also, if you insist on the current model, aren't you suggesting that the
correlation ID is somewhere in the envelope? 

Best regards,
Marwan
   
"Williams, Stuart" wrote:
> 
> Hi Marwan,
> 
> Thanks for responding, and I think we should take this discussion onto
> xml-dist-app, probably by replaying some of this.
> 
> A couple of clarifying questions...
> 
> Were you ok. with the XMLP_DATA operation in the abstract model, or is that
> something whose presence you would also question? My guess would be the
> later - ie. simple one-way messaging (XML_UNITDATA without the Correlation
> parameter) is your model for SOAP/XMLP.
> 
> > My question remains which concept of of soap cannot be articulated
> > without the introduction of this notion.
> 
> My answer to your question is that simple one-way messaging fails to capture
> the concept of correlation that is practically present in SOAP 1.1 over HTTP
> as it is used today. I am concious that section 2 of the SOAP spec states
> that SOAP is fundementally one-way, however mere assertion of something,
> even in a spec. doesn't necessarily make it 'true'.
> 
> This was my 'hang up' over request-response. Simply looking at an XMLP
> message it is not possible to determine whether it is a response to an
> earlier one. Take a look at the example I offer in [1]. Taken as on-way
> messages the only way you can match up the request/responses in that example
> is because you know apriori what the answers to the computations should be.
> 
> The request response (XMLP_DATA) implicitly captured the causal relationship
> between a pair of messages that is there and is present in the way SOAP is
> being used today. Simple one-way messaging will not do... more functionality
> is required.
> 
> If you are or were ok. with XMLP_DATA walk down the path I walked down and
> ask what would be lost by removing it and see if you come up with a very
> different answer.
> 
> Best regards
> 
> Stuart
> PS. I am at least relieved that you don't find my reasoning flawed.
> [1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Mar/0076.html
> 
> > -----Original Message-----
> > From: marwan sabbouh [mailto:ms@mitre.org]
> > Sent: 29 March 2001 15:44
> > To: Williams, Stuart
> > Cc: Ray Denenberg; David Fallside (E-mail); w3c-archive@w3.org
> > Subject: Re: Causality/Correlation
> >
> >
> > Hi Stuart
> >
> > I don't think your reasoning is flawed.  However, I question why the
> > concept of causality is needed.   As far as I could tell, soap did not
> > touch on the concept of causality at all.  Also, I am not sure the
> > concept of causality is needed for the purpose of correlating rpc
> > request and response. ( I mean no logical clock is needed for this
> > purpose.)   However, the concept is very handy for the purpose of
> > ordering the delivery of events, as you pointed out in your document.
> >
> > My understanding has been that if someone requires that functionality,
> > the soap message can be bound to a group communication transport
> > protocol or ordered/reliable delivery semantics  can be
> > implemented in a
> > module.
> >
> > My question remains which concept of of soap cannot be articulated
> > without the introduction of this notion.
> >
> > Best regards
> > Marwan
> >
> > "Williams, Stuart" wrote:
> > >
> > > Marwan, Ray,
> > >
> > > I thought I'd just send you a copy my earlier message
> > introducing the notion
> > > of causality. This copy is the original version that I
> > floated with the AM
> > > subgroup ahead of its subsequent posting to xml-dist-app.
> > >
> > > I have the sense that Marwan thinks this approach is flawed
> > and I would be
> > > interested in his perspective.
> > >
> > > Ray, I know this is a topic we have discussed and you may
> > have found the
> > > change suprising particularly because it came from me.
> > Personnally, I think
> > > that this approach is more primitive and more flexible than
> > what we had with
> > > one-way plus request-response.
> > >
> > > I would be happy to take time on the phone or on email to
> > discuss this
> > > further with you. If the discussion does go to email I
> > guess the right thing
> > > to do is to take the discussion to xml-dist-app - perhaps
> > picking but the
> > > casuality thread or the initial draft of a revised section
> > 3 (before I
> > > substituted it for what in an earlier snapshot).
> > >
> > > Unfortunately, I am offline right now so I can't generate
> > the URLs for the
> > > archived messages. You will find any messages on this topic
> > that circulated
> > > amongst the AM group in the w3c-archive.
> > >
> > > Should you want to call me, my phone numbers are:
> > >
> > >         Office: +44 117 3128285
> > >         Mobile: +44 7785 110771
> > >         Home:   +44 1454 620173
> > >
> > > Please be sensitive to reasonable UK times 9am-10pm. This
> > week we are 9hrs
> > > ahead of PST, 6 hrs ahead of EST.
> > >
> > > Best regards
> > >
> > > Stuart
> > >
> > >
> > --------------------------------------------------------------
> > ----------
> > >
> > > Subject: [AMG]: Causality: A possible remedy to our
> > one-way, request/respo
> > >      nse debate.
> > > Date: Fri, 23 Mar 2001 14:54:54 +0100
> > > From: "Williams, Stuart" <skw@hplb.hpl.hp.com>
> > > To: "'Henrik Frystyk Nielsen (E-mail)'" <frystyk@microsoft.com>
> > > CC: "'David Fallside (E-mail)'" <fallside@us.ibm.com>,
> > >      "'w3c-archive@w3.org'" <w3c-archive@w3.org>, 'Mark Nottingham'
> > >      <mnot@akamai.com>, "EZELL, DAVID (HP-Verifone,unix1)"
> > >      <david_e3@verifone.com>, "Henrik Frystyk Nielsen (E-mail)"
> > >      <frystyk@microsoft.com>, "Jean-Jacques Moreau (E-mail)"
> > >      <moreau@crf.canon.fr>, "John Ibbotson (E-mail)"
> > >      <john_ibbotson@uk.ibm.com>, "Krishna Sankar (E-mail)"
> > >      <ksankar@cisco.com>, "Lynne Thompson (E-mail)"
> > >      <Lynne.Thompson@unisys.com>, "Marc Hadley (E-mail)"
> > >      <marc.hadley@uk.sun.com>, "Mark A. Jones (E-mail)"
> > >      <jones@research.att.com>, "Martin Gudgin (E-mail)"
> > <marting@develop.com>,
> > >      "Nick Smilonich (E-mail)" <nick.smilonich@unisys.com>,
> > >      "Oisin Hurley (E-mail)" <ohurley@iona.com>, "Scott
> > Isaacson (E-mail)"
> > >      <SISAACSON@novell.com>, "Yves Lafon (E-mail)" <ylafon@w3.org>
> > >
> > > Henrik,
> > >
> > > I've had some thoughts that I think might manage to resolve
> > our respective
> > > difficulties on the "one-way only" v "one-way plus
> > request/response" issue.
> > > I'm airing these thoughts with you and the AM subgroup
> > first to get a sense
> > > of whether they feel like they would get us to a place
> > where you would be
> > > happy (and also as a first attempt to write them down). If
> > it looks like
> > > something that you feel would get us (you and I at least)
> > to a point of
> > > concensus I will spend some further time developing the
> > ideas into a form
> > > that can either be presented to the WG as an alternative to
> > the current
> > > section 3 or that the subgroup as a whole believes is
> > better that what we
> > > have.
> > >
> > > I'd like to get a quick read from you on whether you think
> > that the approach
> > > outlined below could yield a result that you and I can both
> > agree to. Also,
> > > I'd like a quick read from the subgroup (and I've Cc'd also
> > Mark Nottingham
> > > because I know this is a topic that interests him) on
> > whether they think we
> > > loose anything if I restructure the Service Model section
> > around the ideas
> > > presented below (developed a little further).
> > >
> > > If folks think this is a productive approach to concluding
> > this issue...
> > > I'll work it up some more and transfer discussion to xml-dist-app.
> > >
> > > Best regards
> > >
> > > Stuart Williams
> > > --
> > >
> > > Thoughts on one-way v one-way+request/response
> > > ----------------------------------------------
> > >
> > > [So here goes with the thought that has arisen (last night whilst,
> > > literally, walking the dog (Bracken) in the rain!).]
> > >
> > > Q. What would we loose if we removed the XMLP_DATA
> > operation from the
> > > abstract service model?
> > > A. Causality.
> > >
> > > Q. Can we introduce causality into a one-way messaging primitive?
> > > A. Yes... (at least I think so).
> > >
> > > So that's the very short version!
> > >
> > > To elaborate a little further, in request/response,
> > causality is very much
> > > part of the semantics of the operation. The response
> > message is causally
> > > dependent on the request. No request, no response. No
> > response without a
> > > request. In SOAP 1.1 over HTTP the causality inherent in
> > the http POST
> > > request and response is exploited to provide correlation at
> > least when SOAP
> > > is being used for RPC, if not more generally.
> > >
> > > So how might we introduce causality into the UNITDATA
> > operation (which
> > > currently defines the following 3 primitives):
> > >
> > >         XMLP_UnitData.send( To, [ImmediateDestination], [OrigPath],
> > > [{Headers}], [{Bodies}], [{Attachments}], [BindingContext]);
> > >         XMLP_UnitData.receive( To, From, [OrigPath], [ActualPath],
> > > [{Faults}], [{Headers}], [{Bodies}], [{Attachments}],
> > [BindingContext]]);
> > >         XMLP_UnitData.status( Status, [{Faults}], [BindingContext]);
> > >
> > > I'm going to dispense with the OrigPath/ActualPath
> > parameters for now just
> > > to avoid stepping into that problem. I'm also going to
> > collapse Faults,
> > > Headers, Bodies and Attachments into a single parameter
> > Message that has sub
> > > fields Message.Faults, Message.Headers, Message.Bodies and
> > > Message.Attachments. Then I'm going to introduce a
> > Causality parameter that
> > > has at least Causality.MessageRef and could have
> > Causality.Sequence (which
> > > I'll mention a bit later on). In summary:
> > >
> > >         XMLP_UnitData.send( To, [ImmediateDestination], Message,
> > > [Causality], [BindingContext]);
> > >         XMLP_UnitData.receive( To, From, Messsage, [Causality]
> > > [BindingContext]]);
> > >         XMLP_UnitData.status( Status, [{Faults}], [Causality]
> > > [BindingContext]);
> > >
> > > [Need to think some more about abstraction of Faults, are
> > they actually a
> > > particular sort of Message?]
> > >
> > > In .send, Casuality.MessageRef is a local (local, abstract)
> > reference to a
> > > previously received message that gives rise to the message
> > being sent. In
> > > .receive the Causality.MessageRef is a (local, abstract)
> > reference to a
> > > previously sent message the processing of which the
> > received message is a
> > > direct consequence.
> > >
> > > The *mechanism* by which causality is determined is *NOT*
> > specified in the
> > > AM. It may be through the exploitation of features in the underlying
> > > protocol eg. the request/response nature of HTTP; It may be through
> > > mechanism introduced either by the XMLP processor to
> > operate across multiple
> > > possible underlying protocols eg. the inclusion of a header
> > entry like
> > > <c:Causality c:msgID="myMsg1234" c:CasualMsg="yourMsg5278"
> > c:Msgseq="1"/>;
> > > It may be something that a binding for a particular
> > underlying protocol
> > > introduces within the domain of the underlying protocols own header
> > > extension mechanism.
> > >
> > > What is this Causality.Sequence thing? It's just think a
> > little ahead to
> > > your multicast question and to the request/multi-response
> > question. The
> > > sequence is to index (order) causal responses from the same
> > responding
> > > source. It deals with potential misordering, it
> > distinguishes duplicates and
> > > it spots holes in the sequence.
> > >
> > > Personally, I believe that this gives us a more primitive
> > and flexible
> > > service interface that enables one-way messaging and
> > retains the causality
> > > inherent in request/response.
> > >
> > > A couple of SOAP questions:
> > >
> > > Your presentation [1] indicates that the HTTP POST response
> > can be empty
> > > (slide 31) - although the last major bullet says: "SOAP
> > response doesn't
> > > require SOAP request."
> > >
> > > Is it the case with the SOAP/HTTP bindings that any SOAP
> > message carried in
> > > the POST response MUST be causally dependent on the SOAP
> > message carried in
> > > the corresponding HTTP POST request? The introductory
> > paragraph in section
> > > 6. [2] of the strongly imply this and *do* talk in terms of
> > "SOAP request"
> > > and "SOAP response" outside of the RPC conventions.
> > >
> > > [1]
> > http://www.w3.org/2000/xp/Group/Admin/minutes-oct1100/soap-xp-wg.ppt
> > > [2] http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383526
> > >
> > >
> > --------------------------------------------------------------
> > ----------
> > >
> > > Subject: FW: [AMG]: Causality: A possible remedy to our
> > one-way, request/r
> > >      esponse debate.
> > > Date: Fri, 23 Mar 2001 22:33:06 +0100
> > > From: "Williams, Stuart" <skw@hplb.hpl.hp.com>
> > > To: "'Henrik Frystyk Nielsen (E-mail)'" <frystyk@microsoft.com>
> > > CC: "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>
> > >
> > > Henrik,
> > >
> > > I have had some further thoughts centred on our discussion
> > of the "one-way
> > > only" v "one-way plus request/response" issue which I think
> > might lead to a
> > > resolution of the issues. The thoughts below are also
> > probably closely
> > > related to the [i44] thread on correlation and transaction
> > IDs [3] - which I
> > > have not been paying close enough attention to.
> > >
> > > Anyway, let me know what you think and whether you too
> > think this is a path
> > > (pun intended) can resolve or respective issues.
> > >
> > > Best regards
> > >
> > > Stuart Williams
> > >
> > > --
> > >
> > > Thoughts on one-way v one-way+request/response
> > > ----------------------------------------------
> > >
> > > Q. What would we loose if we removed the XMLP_DATA
> > operation from the
> > > abstract service model?
> > > A. Causality.
> > >
> > > Q. Can we introduce causality into a one-way messaging primitive?
> > > A. Yes... (at least I think so).
> > >
> > > So that's the very short version!
> > >
> > > To elaborate a little further, in request/response,
> > causality is very much
> > > part of the semantics of the operation. The response
> > message is causally
> > > dependent on the request. No request, no response. No
> > response without a
> > > request. In SOAP 1.1 over HTTP the causality inherent in
> > the http POST
> > > request and response is exploited to provide correlation at
> > least when SOAP
> > > is being used for RPC, if not more generally.
> > >
> > > So how might we introduce causality into the UNITDATA
> > operation (which
> > > currently defines the following 3 primitives):
> > >
> > >         XMLP_UnitData.send( To, [ImmediateDestination], [OrigPath],
> > > [{Headers}], [{Bodies}], [{Attachments}], [BindingContext]);
> > >         XMLP_UnitData.receive( To, From, [OrigPath], [ActualPath],
> > > [{Faults}], [{Headers}], [{Bodies}], [{Attachments}],
> > [BindingContext]]);
> > >         XMLP_UnitData.status( Status, [{Faults}], [BindingContext]);
> > >
> > > I'm going to dispense with the OrigPath/ActualPath
> > parameters for now just
> > > to avoid stepping into that problem. I'm also going to
> > collapse Faults,
> > > Headers, Bodies and Attachments into a single parameter
> > Message that has sub
> > > fields Message.Faults, Message.Headers, Message.Bodies and
> > > Message.Attachments. Then I'm going to introduce a
> > Causality parameter that
> > > has at least Causality.MessageRef and could have
> > Causality.Sequence (which
> > > I'll mention a bit later on). In summary:
> > >
> > >         XMLP_UnitData.send( To, [ImmediateDestination], Message,
> > > [Causality], [BindingContext]);
> > >         XMLP_UnitData.receive( To, From, Messsage, [Causality]
> > > [BindingContext]]);
> > >         XMLP_UnitData.status( Status, [{Faults}], [Causality]
> > > [BindingContext]);
> > >
> > > [Need to think some more about abstraction of Faults, are
> > they actually a
> > > particular sort of Message?]
> > >
> > > In .send, Causality.MessageRef is a local (local, abstract)
> > reference to a
> > > previously received message that gives rise to the message
> > being sent. In
> > > .receive the Causality.MessageRef is a (local, abstract)
> > reference to a
> > > previously sent message the processing of which the
> > received message is a
> > > direct consequence.
> > >
> > > The *mechanism* by which causality is determined is *NOT*
> > specified in the
> > > AM. It may be through the exploitation of features in the underlying
> > > protocol eg. the request/response nature of HTTP; It may be through
> > > mechanism introduced either by the XMLP processor to
> > operate across multiple
> > > possible underlying protocols eg. the inclusion of a header
> > entry like
> > > <c:Causality c:msgID="myMsg1234" c:CasualMsg="yourMsg5278"
> > c:Msgseq="1"/>;
> > > It may be something that a binding for a particular
> > underlying protocol
> > > introduces within the domain of the underlying protocols own header
> > > extension mechanism.
> > >
> > > What is this Causality.Sequence thing? It's just think a
> > little ahead to
> > > your multicast question and to the request/multi-response
> > question. The
> > > sequence is to index (order) causal responses from the same
> > responding
> > > source. It deals with potential misordering, it
> > distinguishes duplicates and
> > > it spots holes in the sequence.
> > >
> > > Personally, I believe that this gives us a more primitive
> > and flexible
> > > service interface that enables one-way messaging and
> > retains the causality
> > > inherent in request/response.
> > >
> > > A couple of SOAP questions:
> > >
> > > Your presentation [1] indicates that the HTTP POST response
> > can be empty
> > > (slide 31) - although the last major bullet says: "SOAP
> > response doesn't
> > > require SOAP request."
> > >
> > > Is it the case with the SOAP/HTTP bindings that any SOAP
> > message carried in
> > > the POST response MUST be causally dependent on the SOAP
> > message carried in
> > > the corresponding HTTP POST request? The introductory
> > paragraph in section
> > > 6. [2] of the strongly imply this and *do* talk in terms of
> > "SOAP request"
> > > and "SOAP response" outside of the RPC conventions.
> > >
> > > [1]
> > http://www.w3.org/2000/xp/Group/Admin/minutes-oct1100/soap-xp-wg.ppt
> > > [2] http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383526
> > > [3]
> > http://lists.w3.org/Archives/Public/xml-dist-app/2001Mar/0115.html
> >

Received on Thursday, 29 March 2001 11:59:50 UTC