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

Noah,
  I haven't been following the discussions too closely, so forgive me
if this has already been covered...this proposal seems to imply that
the binding is a separate component from the SOAP Node - which is
fine - I can see it going either way.  If it is really a different
component, not considered part of the SOAP Node, and therefore should
not modify the SOAP infoset (as your note proposes), does that mean
that even adding something and then removing it on the other end
before it enters the next SOAP Node is also disallowed?  In this case
the infoset will be "unaltered" by the time it is delivered to the
next Node (since the next Node doesn't start until after we leave
the binding) so it doesn't violate the proposed text.  If you want
to disallow this option then the text might need to be firmed up
a bit - or if you do want to allow this option then it show be clear
that this is an option.  Right now the text is a little vague as to
whether or not this is allowed.
-Dug


Noah Mendelsohn/CAM/Lotus@Lotus@w3.org on 01/25/2002 08:57:44 PM

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


To:    skw@hplb.hpl.hp.com
cc:    "'Henrik Frystyk Nielsen'" <henrikn@microsoft.com>, Noah
       Mendelsohn/CAM/Lotus@Lotus, xml-dist-app <xml-dist-app@w3c.org>
Subject:    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 Monday, 28 January 2002 07:36:48 UTC