Re: infoset and bindings

Mark,

To make sure I get it; would this be a reasonably accurate summary of
your proposal:

  Bindings must define an Infoset representation of the services that
  they provide and the restrictions that they impose on the uses of
  SOAP messages. These representations should be able to be
  serialized into SOAP Header Blocks.

Cheers,



On Fri, Jun 29, 2001 at 02:57:37PM -0400, Mark Jones wrote:
> Here are some initial thoughts on a possible framework for thinking
> about things like attachments and bindings and their relationship to
> the envelope.
> 
> We have consistently been plagued by issues such as "what is the
> message", "what is the role of SOAPAction", "what is the difference
> between data in attachments or in the envelope", etc.  I'm coming to
> the view that a message should be abstractly viewed as an infoset
> comprising ALL of the relevant information to be carried along the
> wire.  The role of a binding is to determine how to convey that
> information to the next hop.  Pictorially, we have the following
> situation, where S is the originating, sender node, I1 is the first
> intermediary, ...., and R is the final recipient.
> 
> S ---> I1 ---> I2 . . . In-1 ---> R
> 
> For each node k (S, I1, ... In-1, R), we can define Out(k) to be the
> infoset of the message (leaving) node k and In(k) is the infoset
> constructable from the inbound message to node k.  [Out(k-1) is not
> necessarily equivalent to In(k) -- see the discussion below.]
> 
> In practice, a binding is selected to transmit the required parts of
> the message to the next node.  The binding specifies an underlying
> transfer/transport protocol, (optionally) content-carrying formats
> (e.g., for attachments), and the XML envelope.  Each of these levels
> in the stack may be parameterized with portions of the infoset
> (possibly redundantly).
> 
> As each node receives the transmitted message, it (theoretically)
> constructs an infoset In(k) for the inbound message, and transforms it
> according to the SOAP processing it performs into Out(k).  If the node
> is an intermediary, it then selects a binding for the next hop, etc.
> 
> The behavior of a binding is modulated by the overall messaging
> paradigm (static/dynamic routing, request/response, etc.).  To make
> this more concrete, consider a one-way message in a simple routing
> model in which all of the routing information is determined be the
> initial client, perhaps via some out of band technology such as WSDL.
> I will use an XML serialization of the infoset in this very sketchy
> example.  Don't hold me to the precise syntax -- this is just for
> illustration.  There also should be a more abstract representation in
> the infoset of the various blocks (headers, body and trailers),
> perhaps marked with dependency relationships, etc.  As given, the
> infoset for the message probably anticipates the infoset for the
> envelope a bit too much.
> 
> Out(S):
> 
> <SOAP-ENV:Message>
>   <SOAP-ENV:Path>
>     <r:Routing xmlns:r="some-routing-ns-1" SOAP-ENV:actor="I1-uri">
>       <transport>http</transport>
>       <destination>foo.com:80</destination>
>       <intent>some-acceptable-I1-intent</intent>
>     </r:Routing>
>     <r:Routing xmlns:r="some-routing-ns-2" SOAP-ENV:actor="I2-uri">
>       <transport>http</transport>
>       <destination>foo.com:80</destination>
>       <intent>some-acceptable-I2-intent</intent>
>     </r:Routing>
>     ...
>     <r:Routing xmlns:r="some-routing-ns-n" SOAP-ENV:actor="R-uri">
>       <transport>http</transport>
>       <destination>soap.baz.com:1080</destination>
>       <intent>some-final-intent</intent>
>     </r:Routing>
>   </SOAP-ENV:Path>
>   <SOAP-ENV:Header>
>     <a:SomeHeader xmlns:a="some-header-ns" SOAP-ENV:actor="H1-uri">
>       ...
>     </a:SomeHeader>
>     ...
>   </SOAP-ENV:Header>
>   <SOAP-ENV:Body>
>     ...
>   </SOAP-ENV:Body>
>   <SOAP-ENV:Trailer>
>     <t:SomeTrailer xmlns:t="some-trailer-ns">
>     ...
>     </t:SomeTrailer>
>   </SOAP-ENV:Trailer>
> </SOAP-ENV:Message>
> 
> 
> The binding strategy for the first hop (from S to I1), will consume
> the routing information for the first hop (http to foo.com:80), and
> provide the rest of the routing info in the XML envelope.  For some
> routing paths, all of the routing information for the entire path
> could be carried in the underlying protocol with none of it in the
> SOAP envelope.  [It might be necessary to explicitly characterize the
> global routing paradigm in the message infoset.]
> 
> Here is what the wire format of the SOAP envelope on the first hop
> might look like.
> 
> <SOAP-ENV:Envelope xmlns:SOAP-ENV="...">
>   <SOAP-ENV:Header>
>     <r:Routing xmlns:r="some-routing-ns-2" SOAP-ENV:actor="I2-uri">
>       <transport>http</transport>
>       <destination>foo.com:80</destination>
>       <intent>some-acceptable-I2-intent</intent>
>     </r:Routing>
>     ...
>     <r:Routing xmlns:r="some-routing-ns-n" SOAP-ENV:actor="R-uri">
>       <transport>http</transport>
>       <destination>soap.baz.com:1080</destination>
>       <intent>some-final-intent</intent>
>     </r:Routing>
>     <a:SomeHeader xmlns:a="some-header-ns" SOAP-ENV:actor="H1-uri">
>       ...
>     </a:SomeHeader>
>     ...
>   </SOAP-ENV:Header>
>   <SOAP-ENV:Body>
>     ...
>   </SOAP-ENV:Body>
>   <t:SomeTrailer xmlns:t="some-trailer-ns">
>     ...
>   </t:SomeTrailer>
>   ...
> <SOAP-ENV:Envelope>
> 
> 
> A different, but equally plausible strategy would be to carry the
> Routing information in another layer (e.g., as a MIME attachment), but
> the above approach seems to fit into the framework better since the
> routing for the next hop can be handled by a targeted module.
> 
> The infoset received by node I1 would be whatever was available from
> the SOAP envelope above and anything observable by the inbound HTTP
> request processing (i.e., by the binding on the inbound side).  Thus,
> Out(S) is not necessarily equivalent to In(I1).  More complex
> messaging patterns and routing dependencies may dictate that earlier
> routing information be preserved in the infoset.  Strategies like
> dynamic, content-based routing might carry very little explicit
> routing information in the infoset.
> 
> 
> I hope the ideas are clear enough to serve as a starting point for
> discussion.
> 
> --mark
> 
> 
> Mark A. Jones
> AT&T Labs - Research
> Shannon Laboratory
> Room A201
> 180 Park Ave.
> Florham Park, NJ  07932-0971
> 
> email: jones@research.att.com
> phone: (973) 360-8326
>   fax: (973) 360-8970
> 

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

Received on Monday, 9 July 2001 19:36:48 UTC