Re: TBTF: A distillation of sorts

Glen,

This looks good. Some initial thoughts;

I'm primarily interested in the intermediary scenerios (of course).
It may be helpful to think in terms of the SOAP endpoints vs. the
underlying protocol endpoints; for example,

  +------------------------------*  <--- SOAP transaction between endpoints
  SOAP1 ----------> SOAP2 -> SOAP3  <--- SOAP nodes and hops
  +-----------------*   +--------*  <--- HTTP transactions and endpoints
  HTTP1 -> HTTP2 -> HTTP3 -> HTTP4  <--- HTTP nodes and hops

Some endpoints (*) might have a URI associated with them. The SOAP
endpoints always correlate to corresponding underlying endpoints,
which is nice, but the SOAP hops and the underlying hops and/or
transactions aren't, neccessarily.

So, a service provided by HTTP is available from HTTP end-to-end, not
SOAP end-to-end. As such, it seems like the processing model would
need to know about the underlying protocol's endpoints in order to
process these correctly.

In TB call before today's, there was talk of the 'core' services that
we need to accommodate in our framework. Correlation is one which
we've covered, but endpoint identification *and* routing is also
important.

HTTP provides implicit endpoint identification for the client by
virtue of the fact that it's the one that made the request. The
routing of the response message is determined by the routing of the
request message, in reverse order. Other protocols may not provide
this, especially non-transactional or unconnected protocols. For
example, SMTP could provide for response endpoint identification
through the From: header, but the routing to that endpoint will
probably be much different.

These problems only insert themselves when you use intermediaries
(either SOAP or some kinds of transport intermediaries). Correlation
is somewhat straightforward; it would probably be good to think about
how this model would work with other things like routing, endpoint
identification, security, etc.

Cheers,


On Thu, Jul 26, 2001 at 01:54:23PM -0400, Glen Daniels wrote:
> 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
> 

-- 
Mark Nottingham
http://www.mnot.net/

Received on Thursday, 26 July 2001 18:11:52 UTC