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

I think we're close to agreeing on most of the significant points, and we 
can probably work out the rest on the call tomorrow (unfortunately, I am 
booked tomorrow AM US time ahead of the call.)  Anyway, here are a few 
comments:

Stuart Williams writes:

>> Hi Noah,
>> 
>> In terms of the proposal at the end I have a couple of comments, but 
its
>> mostly... "can live with".
>> 
Good, that's very encouraging, thanks.  I view the proposal as a 
compromise, and I certainly feel no better than "can live with" about some 
of it.

>> In terms of the discussion that precedes the proposal I have some
>> thoughts/comments that probably continue to highlight differences in 
the way
>> we are thinking.
>> 
>> > -----Original Message-----
>> > From: Noah Mendelsohn [mailto:noah_mendelsohn@us.ibm.com]
>> > Sent: 26 January 2002 01:58
>> > To: skw@hplb.hpl.hp.com
>> > Cc: 'Henrik Frystyk Nielsen'; Noah Mendelsohn; xml-dist-app
>> > 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:
Oops.  I thought I got that out.  I had thought that your original wording 
was surviving, but I actually just rewrote from scratch.  See "proposed 
text"  (I know you didn't catch this, but thought I should point it out 
anyway.)

>> >
>> > 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.)
>> 
>> Ok... personnally, I'd be Ok with just the constraint that 'Bindings 
are
>> required to deliver the envelope infoset intact, without modification'.
>> 
I think we're agreeing...the above was not intended as exact wording 
anyway.  See below.

>> > * 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.<<
>> 
>> I have some mixed feeling about this, but am mostly ok. I think my 
concern
>> is centred around the distinction between a feature (eg. 
request/response
>> corelation) and the mechanism used to provide/implement the feature (a
>> binding/binding specification).
>> 
That's a distinction we could make too, but I think it's implicit in what 
we've already put in about features.  It seems to me very clear that we've 
allowed individual binding specifications great latitude in how to express 
a feature.  The new exception is that bindings are NOT allowed to express 
features in terms of headers (except insofar as read-only access is 
helpful.)

>> If we had more time... I think that we could use the concepts of 
features
>> and properties to describe SOAP extensibility more formally than we 
have to
>> date. 
I agree.

>> I also think that it would be tenable for a SOAP module spec'd on
>> single hop basis (ie. one where the headers were alway labelled with
>> actor='../next') to provide semanitically identical functionality to
>> functionality provided directly by a binding. For example, consider
>> functionality (a feature?) named
>> 
http://www.w3.org/2002/01/soap/features/single-hop-request-response-correlat
>> ion. Our existing SRR transport-mep could be said to directly provide 
that
>> functionality/feature. Likewise, it is conceivable that a module named
>> 
http://example.org/soap/modules/single-req-resp-corelation-over-single-one-w
>> ay could be defined for use inconjunction with a one-way TMEP to 
deliver
>> identical functionality. The module would also modify the fault 
handling
>> behaviour of the one-way TMEP (assuming that the one-way TMEP allows 
such
>> overriding). I think that with more effort and F2F time that we could 
square
>> this one... but I think that we're out of time (probably).
Yes, one could try and express such equivalence, but I think it's a mess 
to try to impose it at the SOAP level, or to assume that middleware will 
be written to paper over the kludge.  I've gradually come to the opinion 
that we have two choices (a) if we want to have such equivalence between 
header-based and transport based implementations of a capability, then the 
right way to do it is to let the bindings mess with the headers, deeply 
integrate the processing models, and let bindings benefit from mU or (b) 
avoid any general notion of equivalence.  If the spec for a module wants 
to claim equivalence with the spec for a feature, that's fine, but I 
suggest we leave it to others to generalize the equivalence concept.  The 
majority of the TBTF has strongly shied away from (a), which was my 
original position.  I am therefore proposing (b) as what seems to me the 
clean, simple alternative.

>> 
>> I continue to have a lingering discomfort with the blending of the 
terms
>> feature and mep. I find myself conceiving of an mep as a context in 
which
>> features/functionality can be delivered. Request/Response corelation,
>> message authentication, message privacy (encryption), delivery 
assurance...
>> all have the feel of being features/functionality that get provided 
within
>> the context of some message exchange, and that for me sets MEPs aside 
from
>> features.
>> 
>> There is also the re-emergence of the distinction between 
transport-meps and
>> meps at higher levels (either within the SOAP node or synthesised 
higher up
>> in the application) [1].
>> 
I think I'd stand by the answer above.  In general, the approach we're 
taking (I.e. the compromise proposed) is going to be quite weak in getting 
the bindings involved in anything that is specified as a multi-hope 
abstraction, like an end-to-end req/resp through intermediaries.  We lose 
that, gain simplicity.

>> > * 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.
>> 
>> This works for the module/binding distinction when we define features 
in
>> such a way that only bindings can provide them. However, at a given 
SOAP
>> node ther may still be multiple bindings that are capable of providing 
the
>> range of features required for a given message exchange and the SOAP 
node
>> (possibly influenced by the application in some mannere unspecified) 
has
>> discretion over which particular binding it uses for a message exchange 
in
>> those circumstances where more than one are capable of doing the job 
(and
>> reaching the next ImmediateDestination :-)).
>> 
>> So... I would content that even if we restrict ourselves to just 
bindings
>> (as is our scope as the TBTF) there remain multipe ways in which a 
feature
>> may be provided at a given node (multiple bindings conforming to the 
same or
>> different binding specs.).
>> 
Agreed, but as I said above, I think that's covered.  I think our spec 
already calls out a notion of feature that can be re-implemented by 
various binding specs.  I think it's easy to see how description languages 
and middleware will offer the right information and options to 
applications.

>> > 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.
>> 
>> The alternative would be to define a "reliable delivery" module that 
gets
>> used wholly above the binding and is subject to the chapter 2 
processing
>> logic and may be used over some defined set of (T?)MEPs (including
>> unsequenced lossy one-way). Which would seem like the right thing to 
do...
>> and could be extended to cover end-2-end reliable delivery.
>> 
>> > 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.
>> 
>> I'll agree that assertion of equivalence is hard - it may not be 
possible -
>> it would probably take more time than we have to demonstrate this one 
way or
>> the other. My own belief is that there are features for which such
>> equivalences (between binding/module provision) can be asserted.
>> Demonstrating this would take a while!
>> 
I think it brings implementation (and testing) complexity as well as 
specification complexity, hence my reluctance.

>> > 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.
>> 
>> Basically, I think that we have more work to do to understand the 
operation
>> of bindings and modules and the features/functionality they provide in
>> multi-hop scenarios. This stuff is just hard... if you want to be 
really
>> precise.
>> 
>> I'd certainly agree that there are some features that work simply by
>> extension across multiple hops... but I'm not sure that that is the 
general
>> case. I thad been forming a view that there is an 'infoset' associated 
with
>> a feature and that the operation of the feature in a sense has to
>> communicate the values of those 'infoset' items between peers along a
>> message path. The description of a feature can then speak in terms of 
how to
>> relay those properties across an intermediary (subject to possible
>> modification) to be re-expressed along with the relayed envelope. Over 
a
>> given hop a choice would be made (IMO by the node) whether to delgate 
the
>> feature to a binding or to use a module over the next hop.
>> 
>> I don't know how we get to have this discussion in focussed enough for 
long
>> enough that we can reach some common articulation of the abstractions 
that
>> we are dealing with.
>> 
>> > 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.
>> 
>> Agreed.
Good, thanks!
>> 
>> >  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.
>> 
>> I think I agree... however, it may be the case that at crucial points 
an
>> exchange some invariants must hold with respect to the values held in a
>> bunch of properties rather than it being imperative that some 
trajectory
>> through a state-machine be followed.
Right, but I don't think we have to do anything to make that possible.  If 
I write my feature spec to highlight such invariants, or to be only in 
terms of such invariants, then my specification can be written that way. 
Why call it out as general to all of SOAP?

>> 
>> > Thus, SOAP nodes (applications) are assured that features are
>> > supported compatibly when implemented by more than one binding.
>> 
>> Agreed.
>> 
>> > 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'd be ok to relax the last clause to: "but MUST be delivered unaltered 
to
>> the next node."
>> 
>> ie. emphasis that what is delivered is what was sent... but interms how 
the
>> infoset is encoded on the wire and whether it gets 'annotations' that 
are
>> removed  etc... we remains silent.
>> 
We can wordsmith according to preferences of the group.  The point is, 
soap chapter 2 "runs" and prepares an infoset.  The binding recreates the 
infoset at the next node, using any desired wire representation, including 
multiple small message exchanges, etc.  Note that while the infoset itself 
always flows to the next hop, I believe that bindings can also send 
information the other way at any time.  Binding-level ACKs are an 
example...they update the sender's state machine.
>> >
>> > ---------------
>> >
>> > 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
>> > ------------------------------------------------------------------
>> 
>> 
>> Regards
>> 
>> Stuart
>> 

Thanks for your careful comments.  I'm encouraged that we seem to be near 
agreement on the major points. 

------------------------------------------------------------------
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 19:13:48 UTC