RE: Resolving the Ed Note in Part 1 section 5.1 (was New Issues)

On today's call, I suggested that I might have a compromise proposal that 
would be a reasonable middle ground between those who believe that 
bindings shouldn't mess with the envelope, and those who don't want the 
same feature (e.g. reliable delivery) to appear incompatibly to 
applications depending on whether the binding does or doesn't choose to 
help provide the implementation.  Most of what Stuart has proposed for 
wording, as corrected by Mark Baker, survives.  The highlights of the 
proposal are:

Architectural Highlights
------------------------

* Stick with the prohibition on bindings changing the envelope infoset. 
Bindings are required to deliver the infoset intact to the next node (as 
we've previously agreed, the actual wire formats used to achieve this are 
completely up to the binding, and opaque to the outside.)

* Architecturally separate application level extensions (using headers) 
from binding level "features":  when we say feature, we mean an optional 
capability implemented by one or more binding specifications.  >> Features 
must be defined in terms of non-envelope properties of the state machines 
at each node, except that features can make read-only access to 
information in the envelop infoset property.<<

* Eliminate from Stuart's proposal the notion that there are multiple ways 
to provide a feature, and that nodes have discretion in choosing among 
them.  Instead, we say that each binding specification implements zero or 
more features.  For any given feature, all bindings that implement the 
feature do so compatibly as seen in the state machine (bullet above).  In 
other words, the application has a consistent model of how reliable 
delivery is requested and achieved, regardless of which binding is chosen.

Some Implications
-----------------

Consider a feature such as "reliable delivery".  We want to provide the 
same feature on two different transports, MQSeries and UDP.  MQSeries 
gives us lots of help in assuring reliability, UDP will require lots of 
work in the binding.  In this compromise design, each binding 
specification tells how it will get the job done on the wire.  The UDP 
binding is presumbably going to have to explain lots of sequencing, 
acknowledgement, retry, and perhaps even how state must be stored on disk 
if reliability is to be across system crashes.  Unlike my previous 
proposal, the UDP binding cannot insert into the envelope headers that 
would be seen by the "chapter 2" processing logic at the receiving node. 
So, the UDP binding will have to describe properties (perhaps in the form 
of XML fragments, perhaps of other type) as well as the UDP packets to be 
sent in each case. 

So, the integrity of the envelope is preserved, but we also get 
applications and nodes out of the business of trying to determine that two 
extensions, one in a binding and one in headers, are somehow equivalent. 
In the example above, the HTTP and MQSeries bindings warrant that they do 
inded implement the SAME feature.  Now we have a good base for building 
things like WSDL descriptions, pluggable middleware, etc., without getting 
the application involved.  What we've lost compared to my earlier proposal 
is the ability to apply the SOAP processing model, with mustUnderstand and 
the like, to extensibility of the bindings themselves.  We've also lost a 
lot of the ability to define features that go multiple hops in a way that 
can be in the envelope on some hops, but optimized on others.  That's a 
compromise I can live with in the interst of simplicity.

Proposed text:
--------------

(I don't have time to check the rest of the spec, so this may need some 
work for integration.  I think the sense of it is right.)


SOAP binding specifications MAY provide for support of SOAP "features", 
and each specification MUST indicate the features  supported.  For each 
such feature, the specification must provide for maintaining state (in the 
state machines) and transmitting information from node to node in a manner 
that is fully conformant with the specification for the supported 
features.  Thus, SOAP nodes (applications) are assured that features are 
supported compatibly when implemented by more than one binding.

The specification for a binding MUST provide for transmitting the complete 
envelope infoset, without modification of any kind, to the next node in 
the message path.  The specification MAY also provide for transmitting 
additional information (derived from properties of the state machine) to 
or from the next node as necessary for the implementation of supported 
features.  Envelope infosets MAY be inspected before transmission or after 
receipt, but MUST NOT be altered by any SOAP binding. 

---------------

I know this will need some cleanup, but I hope it will help to move us 
toward concensus.

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------

Received on Friday, 25 January 2002 21:08:49 UTC