W3C home > Mailing lists > Public > xml-dist-app@w3.org > August 2001

Re: [TBTF] Binding Models and the Abstract Model. (long :-( )

From: christopher ferris <chris.ferris@east.sun.com>
Date: Wed, 01 Aug 2001 10:05:10 -0400
Message-ID: <3B680C96.7ECFFC68@east.Sun.COM>
To: "Williams, Stuart" <skw@hplb.hpl.hp.com>
CC: "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>
Stuart,

Please see below.

Cheers,

Chris

"Williams, Stuart" wrote:
<snip/>
> 
> Message Exchange Patterns and Causality:
> ----------------------------------------
> At various stages it has been apparent that we have widely differing and
> sometimes deeply held view on the issue of whether SOAP message exchanges
> are "...fundamentally one-way transmissions..." stated in Section 2 [7]. In
> the early days of the AM discussion we made explicit provision for one-way,
> unsequenced, uncorrellated messages (ie. XML datagrams for want of a better
> expression) and asymmetric request/response message patterns. The presence
> of both patterns caused some tensions within the AM sub-group!
> 
> On an evening walk with my dog... a penny (of sorts dropped) which led my
> email of Causality, [8] plus thread [9], as a possible resolution to the
> one-way v one-way plus request/response debate.
> 
> These thought propagated into more recent versions of the AM.
> 
> In a thread starting at [10] Chris Ferris, amongst other things, picked up
> on some issues with respect to Causality (Correlation as it became relablled
> - but I still prefer Causality). In the final message on that thread [11] I
> show how an interface that caoptures one-way messaging with casuality (as
> described in the AM) can be re-mapped to provide the request/response
> operation previously described by the XMLP_DATA operation. The difference
> here between remapping the interface and layering request/response on-top of
> uncorellated, unsequenced one-way messages is that in the former case there
> are no externally visible differences. The ability to be able to do this
> hinges on the 'with corellation' piece. If that piece were missing then it
> would have to be 'layered' on top which would result in externally visible
> artifacts (serialised facets in Glen's terminology).
> 
> Chris, given the thread terminated at this point I was never quite sure
> whether you 'bought it'!


Yes, I did/still do;-) And, as you point out, it opens up a wider range
of possibilities. However, I believe that the correlation mechanism,
such as that which I recently described for the RPCTF isn't sufficient
in and of itself for all cases. As you cited (I believe) a request/n-response
MEP might need to add sequenceNumber (of response) so that ordering might
be preserved (again, this might be handled implicitly by a specific
binding to a transport/transfer protocol that preserved ordering, or it
might need to be added to the envelope by the transport/transfer binding 
software acting as an actor in the SOAP message path... Applications may
also need/want to add further correlation information of their own.
A TPM might add transactionId, either as the exclusive correlation or
as a separate token (as in the case where a long running conversation
were composed of multiple "transactions", etc.)

> 
> Causality/Correlation as described in the message threads mentioned and the
> AM (Section 3.1.1 and 3.1.3 [12,13]) is described in terms of locally
> significant message references - they may in somecases be globally
> significant, but in the AM only their local significance is assumed. These
> local references may be made explicit in those cases where the underlying
> protocol does not provide any form of correlation or they may be implicitly
> derived from the operation of the underlying protocol. This again has strong
> reasonance with Glen's example in [14].
> 
> So, one-way plus corelation/causality was introduced as a way of *not*
> loosing the imlicit correlation that you get from protocols like HTTP. For
> me at least just one-way was not enough. I have reasoned that with one-way
> plus causality you can recreate request-response [11]. Of course what that
> then demand in terms of a primitive MEP provided by a binding is a mechanism
> to preserve causality either implicitly or through the inclusion of
> additional syntactic artefacts in the message (or its wrapping).
> 
> For request-response, the request message in independent (ie not marked as
> being a consequence of any previous message). The response is marked as
> being a direct consequence of the request message. However, one-way plus
> causality/correlation allows much richer functionality (if it is available
> symmetrically - see below for a thought on HTTP). Where a message arises as
> a direct consequence of another message and we have the means to keep track
> of the chain of causality through a sequence of messages we have the means
> to denote a 'conversation', literally that chain on messages (much as
> presented by a threaded email or news reader) - we have the means at least
> to impose a partial ordering over a set of messages (N-response need
> sequence numbers - implicit or explicit - if response order is important).
> 
> Whilst I haven't worked it through in detail, I think that one-way plus
> causality is the primitive building block that we need for (dare I say it)
> ALL message patterns (you'll probably prove me wrong).

See above, I think that it can as well...

> 
> Now regarding HTTP. On the surface it would seem that awkward to signfy the
> causality of a SOAP message delivered in an HTTP POST request. We have
> though so far only about the implied correlation/causality between of an
> SOAP message carried in an HTTP response wrt its direct causation. However,
> in the Web world folks do manage long running conversation between client
> and server (otherwise I'd have a hard time getting a book out of Amazon).

;-)

> One of the ways to maintain context is through cookies (of course values
> encoded in request-uri's is another). If an HTTP server were to anticipate a
> response to a message it sends in an HTTP POST response, it could include a
> cookie (a locally significant reference) that would get returned by HTTP in
> a subsequent POST request bearing a response from the client to the server.
> Again, I haven't work this through fully,  but it gives a glimmer of a
> mechanism that enables the '...with corellation' to be symmetric over HTTP.


Agreed, but this is external to the SOAP envelope, which is fine for HTTP, but
it may not apply to other transport/transfer bindings which lack a similar
capability.

> 
> Closing thoughts
> ----------------
> The AM is focussed largely on the layer between the user of SOAP and the top
> of a binding. These two are the key interfaces that deliniated the
> functionality we have to describe to describe the core of SOAP. The AM does
> discuss bindings more generally (not just binding context) in work
> contributed largely by Marc Hadley (section 5 [15]). I elaborated on that
> work at the start of a rather lengthy thread around the time of the
> formation of the TBTF [16]. That thread got a little bogged down :-).
> 
> The main point here, which is a reminder to self as much as anything, there
> are two (abstract) interfaces to consider. One between the user of SOAP and
> the SOAP Layer which 'roughly' provides a bunch of what folks have come to
> term Application MEPs... or maybe just the one - one-way plus causality and
> leave the SOAP user to synthesis the others; and a second interface between
> the 'bottom' of the SOAP layer and bindings to underlying protocols.
> Functionality to support MEPs and QoS may be added but the SOAP users(s)
> (application specific), within the SOAP Layer (to work end-to-end and across
> multiple binding eg. request on HTTP, response via email), within a binding
> (to make efficient use of the features a particular underlying protocol
> provides). Sometimes its easy to forget where one is trying to add
> functionality (and why!).
> 
> A final word on BindingContext... it is intended to be a structure that is
> accessible at all levels of the stack. Conceptually at least, it is
> instantiated per message (or in fact per message event, binding context on
> reception is different from binding context on transmission *and* the
> receiver has no direct access to the senders BindingContext). Practically,
> some bits of a BindingContext are more dynamic than others, and so
> (relatively) static pieces of the context will be the same for multiple
> messages - eg. binding capabilities, security context...
> 
> One last little thing on Infoset. Martin Gudin, John Ibbotson and I met in
> January 2001. I kept some notes of that meeting which are at [18]. In the
> middle of these notes is a section titled "Abstract Layer Interface". Again
> it's looking more at the upper interface to the SOAP layer than the lower,
> but it introduces the notion of using XML as a 'concrete' syntax for
> describing an abstract message and the properties/metadata required to
> transfer the message. You might find it interesting!

I think that what the AM describes in terms of the interfaces such as 
UNITDATA, providing the BindingContext, etc. amounts to what we've been
loosely describing as the Message "infoset" as seen from the application
and possibly as seen from the binding layer to the SOAP layer as well.

> 
> Best regards
> 
> Stuart
> --
> [1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Jul/0334.html
> [2] http://www.w3.org/TR/2001/WD-xmlp-am-20010709/
> [3] http://www.w3.org/TR/2001/WD-xmlp-am-20010709/#Sec5.2
> [4] http://lists.w3.org/Archives/Public/xml-dist-app/2001Jul/0333.html
> [5] http://www.w3.org/TR/2001/WD-xmlp-am-20010709/#Sec3.2
> [6] http://www.w3.org/TR/2001/WD-xmlp-am-20010709/#Sec3
> [7] http://www.w3.org/TR/2001/WD-soap12-20010709/#_Toc478383491
> [8] http://lists.w3.org/Archives/Public/xml-dist-app/2001Mar/0216.html
> [9] http://lists.w3.org/Archives/Public/xml-dist-app/2001Mar/thread.html#216
> [10] http://lists.w3.org/Archives/Public/xml-dist-app/2001Apr/thread.html#7
> [11] http://lists.w3.org/Archives/Public/xml-dist-app/2001Apr/0140.html
> [12] http://www.w3.org/TR/2001/WD-xmlp-am-20010709/#Sec3.1.1
> [13] http://www.w3.org/TR/2001/WD-xmlp-am-20010709/#Sec3.1.3
> [14] http://lists.w3.org/Archives/Public/xml-dist-app/2001Jul/0311.html
> [15] http://www.w3.org/TR/2001/WD-xmlp-am-20010709/#Sec5
> [16] http://lists.w3.org/Archives/Public/xml-dist-app/2001Jul/thread.html#13
> [18] http://www.w3.org/2000/xp/Group/1/01/18-adhoc-meeting.html
Received on Wednesday, 1 August 2001 10:05:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:03 GMT