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

Folks:

As I mentioned on yesterday's call, I have some trepidations about this compromise.  Here's the main part I have a problem with:

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

This seems to be rather antithetical to the original purpose of abstracting out "features" in the first place.

I think it is critical that we have a mechanism to express the semantic equivalence of particular binding-level features that might be provided "natively" and those same features when expressed/implemented in the SOAP envelope.  The ability of a given feature (request-response, say) to be transparently implemented either at the binding layer or as a SOAP module without necessarily impacting the implementation of an application running on a "smart" soap node has always seemed a key goal of the TBTF.

As I recall, this precise equivalence (for instance, being able to implement the SAME concept of request-response by either using HTTP or SOAP headers over some native one-way protocol) was what we spent an awful lot of time on for the first few months of this group, and I'm very concerned that this continue to be reflected in the framework.

Personally, I prefer the original text in the spec to this, and prefer Stuart's edits over the spec text.

In the conversation leading up to this point, it seemed to me that we were all on the same page with respect to the fact that decisions would get made as to how to express particular application-requested features (based on binding capabilities, endpoint descriptions, etc), but there was some disagreement as to "which piece" of the system made those decisions.  Noah was pushing for it being the binding's responsibility, while I felt it was up to the node.  I still think this is a resolvable issue, and would prefer to see a resolution which does not move the framework away from what I perceive to be one of its key features.

--Glen

Received on Wednesday, 30 January 2002 08:51:28 UTC