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

Hi Noah,

In terms of the proposal at the end I have a couple of comments, but its
mostly... "can live with". 

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:
> 
> 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'.

> * 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). 

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 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).

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].

> * 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.).

> 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!

> 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.

>  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.

> 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.

> 
> ---------------
> 
> 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

Received on Monday, 28 January 2002 09:31:02 UTC