RE: Bindings : a quick cut at an abstract definition

Hi Glen,

Thanks for doing this... I think it looks quite good. I have a couple of
thoughts on your item 3 comment.

> Item 3 certainly could/should be expanded into more detail.  I also
> note that it seems to me that the difference between a binding and
> any other SOAP extension becomes somewhat unclear if we head down this
> road - bindings, I think, are the only extensions allowed to specify
> "private" patterns as in item 2, but aside from that it's very similar.
> This may be a good thing or not.

I think that one of the differences to give some thought to is any
difference in how the Processing Model (Section 2) handles what you describe
and how 'normal' SOAP extensions are handled.

For example, consider functionality that preserves message order. Loss is
ok... messages are passed to the receving SOAP user/application/actor in the
order that they were originally sent. Losses leave holes in the message
sequence.

If we imagine that some underlying protocols are naturally order preserving
and others are not and that we have defined a public facet as you suggest
eg. the binding at the sending node serialises a monotonically increasing
sequence number into a header block. Some short arrivals buffer might be
maintained to enable re-ordering of messages and/or late arrivals are
discarded to prevent mis-ordered delivery - this is just an example. 

The issue here is that this extension affects the delivery of a message. A
message that arrives too late (outside any buffering window) is actively
discarded, but that requires processing of the message. IIRC the processing
model in section 2 regard the document ordering of headers as insignificant,
so we would rely on mU processing which would require that in order to
'fully understand' this extension it must be understood that the processing
of this message ordering extension could have the side-effect of the message
being discarded as if it had never arrived (aside perhaps from logging and
discard stats).

So maybe this is ok... it just feels a little awkward in that the extension
in a sense is a filter on the delivery of messages, but the message has to
sort-of be delivered/processed in order to apply the filter. The same would
apply wrt duplicate detection and also wrt a reliablity extension that
caused lost messages to retransmitted.

Anyway, just some thoughts.

Regards

Stuart

> -----Original Message-----
> From: Glen Daniels [mailto:gdaniels@macromedia.com]
> Sent: 30 July 2001 12:51
> To: xml-dist-app@w3.org
> Subject: Bindings : a quick cut at an abstract definition
> 
> 
> This is a quick take at what a high-level "binding" abstraction might
> look like.  I start off by presenting a little context, then take a
> stab at a (very small) abstract binding framework.
> 
> A couple of things to note first:
> 
> The message infoset is an entirely abstract notion, and the actual
> representation of the infoset in memory or on the wire is entirely up to
> the application.  An example: we may define an infoset item which
> indicates that a given message is an RPC request.  One possible
> implementation might actually insert a block into the message which
> carries this information.  Another implementation may implicitly "know"
> that this information is "virtually" in the message by virtue of the
> fact that an API such as "call(method, arguments)" was invoked in the
> execution path.
> 
> To send or receive a SOAP message, a binding must be selected.  Therefore,
> it seems likely that the binding name itself is an item in the message's
> infoset.
> 
> Bindings supply "facets".  Some of these facets may be entirely internal
> to the binding in question, and in this case they do not need to be
> specified in any particular way.  Some facets, however, may be expressed
> in terms of the message infoset - doing this allows the definition of
> concepts that are shared or referenced across multiple bindings or other
> extensions.
> 
> OK, so a proposal for a binding framework might look as 
> simple as this:
> 
> A binding should include:
> 
> 1. A name (URI) for the binding
> 
> 2. A specification of the binding's "private" facets.  This would be
> any binding features/behaviors which do not have a well-defined
> normative representation in the SOAP infoset, but still must be
> clearly specified so that multiple implementations of the binding may
> interoperate.  An example might be "this binding uses TCP port 4999".
> 
> 3. A specification of the binding's "public" SOAP facets.  These would
> be descriptions of how the binding generates, consumes, or in some
> other way relates to particular normatively defined pieces of the
> message infoset or other extensions/bindings.  This might include
> message exchange patterns, security, or anything else that has been
> defined by the WG or by extension writers.
> 
> ... and that might be it.
> 
> I am still unsure about how to characterize the difference between
> "encapsulation" bindings and "transport" bindings, and so 
> have left this
> intentionally vague in that respect.
> 
> Item 3 certainly could/should be expanded into more detail.  I also
> note that it seems to me that the difference between a binding and
> any other SOAP extension becomes somewhat unclear if we head down this
> road - bindings, I think, are the only extensions allowed to specify
> "private" patterns as in item 2, but aside from that it's 
> very similar.
> This may be a good thing or not.
> 
> Glen Daniels
> Macromedia
> http://www.macromedia.com/
>                                 Building cool stuff for web developers

Received on Monday, 30 July 2001 10:38:50 UTC