RE: Causality/Correlation

H Marwan,

> -----Original Message-----
> From: marwan sabbouh [mailto:ms@mitre.org]
> Sent: 29 March 2001 17:57
> To: Williams, Stuart
> Cc: Ray Denenberg; David Fallside (E-mail); w3c-archive@w3.org;
> xml-dist-app@w3.org
> Subject: 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. 

Unfortunately, all references to XMLP_DATA are typo's in the current (27th
March) snapshot. That was my error, I didn't do a thorough enough job
cleaning up the consequences of removing what was the section on XMLP_DATA.

The caption on Figure 3.1 should just be XMLP_UNITDATA only.

XMLP_DATA was *never* redundant and was *never* presented as simply two
one-way operations. It was always presented was a two-way operation where
there is an explicit causal relationship between the request message and the
response message. That causal relationship is what is lost when you simply
switch to two one-way messages.

> 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.

The point is that that is how it would be *IF* you consider it to be two
just one-way messages (ie. broken). That is how it would be with SOAP if
*ALL* you did was look at one-way messages. The fact is that it *isn't* like
that with SOAP so, IMO, there is more than on-way messaging going on here,
there *is* an operation whose semantics give you correlation.

> 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). 

But... this is an abstraction. It would be precisely the wrong thing to do
to grunge around for the application in the mire of the underlying protocol
and have to know the vaguaries of different underlying protocols.

Certainly, the functionality could be implemented in a module - and may very
well be in the future. Point is it isn't right now and SOAP/HTTP delivers
that functionality now - which is why it entered the model in the first
place.

> 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. 

Sure, but now from an XMLP user point-of-view your are delving around in the
details of the underlying protocol. *IF* you are going to go for one-way
messaging as an abstraction of *WHAT* you do (the service that you provide)
that's what you have to stick with. You send a message in one side and (with
reasonable probablity) it comes out the other end. It may leap-frog eariler
messages, it may get lost. That's pretty much all you should have to know
*if* you are sticking with one-way messaging. Reaching around the side to
derive correlation information from particular knowledge of the underlying
protocol mechanism is fine from a focussed and pragmatic implementation
point-of-view, but it is no way to present an abstraction.

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

Firstly, I don't think in a position to insist. Certainly I have my opinons
and we may differ, but in the end it will be the WG that decides what it
wishes to publish as a WD.

To answer the main point here, the answer is no I'm not suggesting that the
correlation ID is somewhere in the envelope. The Correlation.MessageRef is
local and abstract (its not some externally significant URI or GUID). The
mechanism that 'generate' the local MessageRef may be intrinsic to the
underlying protocol, as is the case with SOAP over HTTP; they may be
generically included in the design of XMLP (but we havent yet done that);
they may be introduced with a protocol binding - this model is *not*
precriptive on *HOW* it aims to present a model of *WHAT* the XMLP layer
does.

Request/response looks something like this.

       Node X                       Node Y

  .send(Message=MsgAX)
  ------------------->|     |
                      |     |
  .status(status=sent)|     |.receive(Message=MsgAY)
  <-------------------|     |----------------------->
                      |     |
                      |     |.send(Message=MsgB,
                      |     |      Correl.MsgRef=&MsgAY)
                      |     |<-----------------------
 .receive(Message=MsgB|     |
 Correl.Msgref=&MsgAX)|     |.status(status=sent)
  <-------------------|     |----------------------->
                      |     |
NB, the &MsgAX and &MsgAY references are locally only.

> Best regards,
> Marwan

Best regards

Stuart

<snip/>

Received on Thursday, 29 March 2001 13:32:14 UTC