Re: Causality/Correlation

Hi Stuart

Thanks for discussing the issue.  My comments are below.
<snip>
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.
</snip>
let us be more precise.  is it Soap that delivers the functionality or
is it http? (http)


<snip>
*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
</snip>

I am sorry but I do not agree with the above.  I think if u model it as
a one-way message, the message can still be delivered reliably,, and in
order.  The underlying transport protocol could ensure that.  In this
fashion, from an XMLP perspective, there is only one message.  However,
the transport protocol would exchange multiple messages on the wire to
make that happen.


My preference is for one way only.  But I can live with the decision of
the group.

thanks again
Marwan

"Williams, Stuart" wrote:
> 
> 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 18:07:13 UTC