Re: TBTF: A distillation of sorts

If the req/res header is only serialized "when needed",and in the
example you gave it is not needed for single hop HTTP, how can
the sender know whether the message is going directly to the final
node or through some intermediaries?   It seems like it might end
up being there all the time (I'm not implying that that is a bad
thing - just making an observation).
-Dug


Glen Daniels <gdaniels@macromedia.com>@w3.org on 07/26/2001 01:54:23 PM

Sent by:  xml-dist-app-request@w3.org


To:   "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>
cc:
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.

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

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

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

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

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

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

Received on Friday, 27 July 2001 07:54:46 UTC