Glen et. al,
During Monday's TBTF telcon I agreed to relate strands of the discussion so
far to mateerial within the Abstract Model.
In a note to Glen [1] I identified 4 types of information related to the
specification and usage of a binding, briefly:
a) Information about the capabilities of a binding
b) Information being exchanged between peer users of SOAP - a SOAP message
(plus attachments)
c) Information required to enable a message exchange that is not part of the
message itself, so called message metadata.
d) Transcient Information (state/context) related to exchanges of multiple
messages and the provision of mechanisms/services such as order
preservation, loss detection and recovery, duplicate detection and
supression...
[NB: the structures discussed below are abstract. Implementations may choose
to make equivalent functionality visible in other ways (or not at all where
information is implicitly known). The AM is primarilly a descriptive tool.
It is *NOT* intended to be prescriptive on implementation - just in case I
forget or it ceases to be apparent below.]
In the Abstract Model [2] a) is reflected in the tentative internal
structure of the BindingContext (section 5.2 [3]) provides partitions for
binding definitions to add sub-structure to the BindingContext. It also
recognises that some 'facets' (to use Glen's word) may be shared across
multiple binding and uses security information (references to keys, ids, and
certicates) as an example of information that might be useful to multiple
bindings. The point here is that the 'shape' of the sub-structure (and its
semantics) associated with particular protocol binding captures the range of
capabilities of a binding expressed in a binding spec. Instantiation of that
structure with particular values in particular branches of the substructure
reflect the choices, functionalities chosen in a particular instantiation of
a binding (or at least in an abstract description of an instance of a
binding!). Note that these per binding spec branches in the BindingContext
seem strongly related to the 'private' facets in Glen's message [4] while
the 'shared' branch is the root of a structure for facilities/features that
seem strongly related to the 'public' facets in Glen's message [4].
b) seems straightforward. It relates two what I think most people regard as
a SOAP Envelope and/or a SOAP envelope plus attachments carried within some
binary capable packaging format such as MIME or DIME. In the AM [2] this
information is reflected in the Message parameter and its substructure
Message.Faults, Message.Blocks, Message.Attachments (see section 3.2 [5].
Message.Blocks was orginally Message.Headers, Message.Body and (tentatively)
Message.Trailers. This became amagamated into Message.Blocks subject to the
discussion as to whether there were significant semantic and processing
differences with respect to each of these partitions.
c) is captured in the parameters of the message exchange primitives in
Section 3, [6]. In earlier versions of the AM, the distinction between the
choice between the use of XMLP_DATA and XMLP_UNITDATA signified the senders
selection of a one-way or request response pattern. These primitives model
discrete (abstract) events in the lifecycle an instance of a message
exchange. They are abstract because they are intended to be enabling of
description WITHOUT being prescriptive on implementation. It think it
relatively a straightforward syntactic change to express these primmitives
as n-nuples where the primitive name moves inside the tuple alongside the
parameters and in doing so gives an explicit indication of the MEP in force
and the phase of the operation. [I'll mention one-way plus causality further
below].
d) is spread around a little! For threading of related messages there is
certainly the Corellation (orginally Causality) parameter (see section 3 and
3.2 [6,5]) - more below. In terms of things like security context that might
be common to a sequence of messages, it is certainly implied in the AM that
this type of information may be carried in the binding context. So outbound
BindingContext might provide keys,ids and certificates for authentication
and signature and inbound BindingContext might provide authentication status
and certificates, the latter giving the identity of a peer (derived from say
SSL) that may influence the processing of the inbound message. Likewise,
transcient information related to public and private binding facets (Glen's
term) could be squirel away (or accessible via) binding context.
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'!
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).
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.
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!
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