RE: TBTF: A distillation of sorts

Hi Glen,

Some comments in-line.

Best regards

Stuart


> -----Original Message-----
> From: Glen Daniels [mailto:gdaniels@macromedia.com]
> Sent: 26 July 2001 18:54
> To: 'xml-dist-app@w3.org'
> Subject: TBTF: A distillation of sorts
> 
> 
> Here's a quick summary of some recent thoughts re: bindings and 
> extensions and blocks ("oh my" :)).
> 
> * We can pick operational semantics and define them in terms of named
> components, pieces of data, and communication patterns.  This is the
> basis of our extension framework in general.  I.e. "this custom
> security extension (named 'http://myhost/cheesy-security') is implemented
> by sending a block (ns = 'http://myhost/cheesy-security', name = 'user')
> containing a username encoded as a string....' etc.

Agreed...

> * Typically extensions are realized by a process of serializing one or
> more SOAP blocks in messages on the wire in accordance with the
> contracts defined by the extension specifications.  However, these
> blocks may be thought of as simply existing in the message "infoset",
> and some or all of them may not actually require an explicit
> serialization on the wire.

Maybe... I guess that I begin to have some trouble here, and it probably
stems from what precisisely it is that we regard as the message being
sent/transferred and how we're using the term 'infoset'.

We are using the term 'infoset' quite liberally and there is a danger that
we might be confusing ourselves over whether we mean an 'XML Infoset' or
whether we're using the term rather more loosely to mean some instance of an
information model. I think the latter. 

I think that we have a number of sources of information that contribute
toward what we are calling an 'infoset':

	a) Information about the binding.
	b) The SOAP Message itself (an XML Infoset plus attachments with
some framework for internal referencing).
	c) Message metadata required to exchange/transfer the message
(static per message).
	d) State information relating the progress of a given message
exchange or sequence of message exchanges (**)

a) basically tries to formalise a description of the capabilities of a
particular binding. It's some collection of the named things that Glen
mentions above. The resulting information items are likely to be static with
respect to a particular binding/underlying protocol.

b) This is the SOAP Message itself (plus attachments). I tend to think of
this as the piece of information that a SOAP user wants to exchange with a
peer SOAP user (the next actor/actors down a path).

c) Per message metadata about the message required in order to transfer a
particular message over a particular binding. Includes things like: where to
send the message (or some means to determine where to send the message); QoS
requirements for the message transfer; applicable MEP or MEP phase (this
message is a response to message X and not a new message soliciting its own
response); some security context with certificates/keys related to the
message transfer.

d) Once we think of services like preserving message order, suppression of
duplicate and particular MEPs we have transcient information (state) that
relates to multiple message transfers. eg. message ordering and recovery (or
not) of missing messages tends to occur with some context - ie partial
orderings either along some path or between pairs of communicating peers
(SOAP endpoints). Some of the items listed in c) are more applicable here
(eg. MEP phase, security context)... just wanted to go through the
progression in this order.

Basically, I guess I'm saying that there is information about the
capabilities of a given binding; information that peer SOAP users want to
exchange (a messsage plus attachments); per-message information (meta-data)
required to support the exchange of the messsage; and transcient (state)
information related to exchanges of multiple messages and provide services
such as order preservation, loss detection and recovery, duplicate detection
and supression...

> * The process by which we define these "extensions" is precisely the
> same process by which we can define binding "facets".
>
> * Any SOAP processor may choose to implement the semantics of particular
> extensions/facets in any way which satisfies the contracts of those
> extensions/facets - and in particular, if the processor (or a component
> thereof) has knowledge of a particular extension/facet, it may do one of
> two "special" sorts of operations:
> 
>     1. It may choose NOT to serialize particular blocks, since the
>        information they convey may be implicit in the communications
>        link to the next node, or may be pre-specified somehow by
>        out-of-band metadata.

I think there is a concern about facets that may work fine on a single-hop
basis, but where information may be lost end-to-end on a multi-hop basis.
That said, I think that the scope of a SOAP binding is a single hop between
a pair of SOAP processors (or a set of immediate successors in a multi-cast
case).

>     2. It may choose to ASSUME the existence of particular blocks, again
>        based on the particulars of the implementation or underlying
>        protocol.

Don't understand... maybe an example would help.

> * Any component (and specifically bindings) may define any kind of
> semantics/extensions that it desires, and in fact does NOT need to
> represent all such semantics as named extensions/facets.  However, if we
> wish an extension to be understood by other layers or implementable by
> other bindings, we should give it a unique name, write a specification,
> and perhaps define a normative XML serialization of the blocks which
> are involved.  Giving it a name allows other entities, both human and
> machine, to refer uniquely to the extension or block in question.

Agreed.

> --- An example which might make this a little clearer ---
> 
> 1. Define a "request-response" message pattern, called:
>      http://www.w3.org/2001/07/req-resp
>    The spec states that any request message which uses this MEP must
>    contain a "ns:RequestID" block (where ns == the req-resp URI) which
>    itself contains a string.  When a response (or a fault) is generated
>    as a result of any such message, a "ns:ResponseID" block containing
>    exactly the same information in the RequestID block must be included
>    in said response.
>
> 2. The normative HTTP binding states something like:
>    "This binding handles request-response correlation for message
>     pattern http://www.w3.org/2001/07/req-resp implicitly.  Therefore
>     when using this binding to carry request messages which follow
>     said pattern, implementations may omit the serialized form of the
>     requestID/responseID blocks on the wire, and rely on the fact that
>     the semantics of the blocks will be satisfied by the binding itself."

This reminds me of the discussion of causality from sometime ago [1,2].

> 
> 3. One can imagine a "req/resp" module being responsible for adding
>    an appropriate RequestID block to outgoing requests, and handling
>    the actual correlation (perhaps waking threads, etc) of responses
>    based on ResponseID.  So a particular implementation of this might
>    look like this for a typical RPC call:
> 
>    client -[1]-> req/resp extension -[2]-> HTTP binding -[3]-> {(net)}
> 
>    The message "infoset" at [1] contains only the structured RPC
>    request.  At [2], the message now has a 'virtual' RequestID block
>    as well (not necessarily serialized).  But when it gets to [3], the
>    serialization of the message does not contain the RequestID block.
>    When the response comes back from the HTTP binding up through the
>    req/resp extension, the binding ensures the "ResponseID" block is
>    placed correctly into any response which was received over the
>    HTTP connection (and note again that the ResponseID block is not
>    necessarily actually represented in the message, it might exist
>    in a contextual data structure, or might in fact be implicit
>    based on the thread which blocked when calling the HTTP binding).
> 
> 4. A UDP binding which is later written doesn't state anything about
>    its relationship to this message exchange pattern, and therefore
>    the RequestID/ResponseID blocks will be serialized across the UDP
>    connection.
> 
> Couple of quick notes about this example (which was written up before
> Chris' example went out):
> 
> I'm not promoting this particular set of definitions, this is just a
> toss-off model.  If we really go this route, it probably makes sense
> to not tie the correlation ID blocks so tightly to the 
> message pattern,
> for instance.
> 
> This example assumes a single hop between the requestor and the
> responder.  If intermediaries were involved and round-trip correlation
> was required (which is a case I think we need to deal with), the HTTP
> binding wouldn't be able to implicitly remove the correlation ID.
> 
>                            - * -
> 
> In any case, there you have it - I hope this made some sense, despite
> the fact that the thoughts herein are merely explorations in a
> particular direction, and somewhat imprecisely expressed.
> 
> Glen Daniels
> Macromedia
> http://www.macromedia.com/
>                                 Building cool stuff for web developers

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Mar/0216.html
[2] http://lists.w3.org/Archives/Public/xml-dist-app/2001Apr/0140.html

Received on Monday, 30 July 2001 08:23:06 UTC