Re: TBTF: Four possible points of concensus

+1.  I think I agree pretty much with all your comments and 
clarifications.  Thanks.

------------------------------------------------------------------------
Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------------







Christopher Ferris <chris.ferris@sun.com>
10/17/2001 08:02 AM

 
        To:     Noah_Mendelsohn@lotus.com
        cc:     xml-dist-app@w3.org
        Subject:        Re: TBTF:  Four possible points of concensus


Noah,

Nice write-up. Some comments follow. Sorry I missed the call,
sounds like quite a bit of progress was made.

Cheers,

Chris

Noah_Mendelsohn@lotus.com wrote:

<snip/>
> 
> Concern #1:  are we inventing duplicate mechanisms (soap processing vs. 
TB
> framework state machine)?
> Proposed resolution:  no, it's one combined state machine...TB machine
> covers message flow, and provides input to and takes messages from the
> processing logic in SOAP chapter 2.


Sounds reasonable.


> 
> Concern #2: one could model all features in the envelope.  The design in
> [1] also allows for properties outside the envelope to be modeled.  This
> does not leverage SOAP as much.  Should we stick with it?
> Proposed resolution:  yes.  Features can be modeled in the envelope
> property, in other properties, or both.   Either way, a binding can 
"reach
> in" and do a customized implementation (e.g. secure delivery over https,
> reliable delivery over MQSeries).  If the feature is purely in the
> envelope, then the binding need not do anything special to get the 
feature
> to work.   Reasons for these choices:  (a) in SOAP 1.1 we've already 
seen
> what are effectively properties outside the envelope.  These include the
> destination URI for http, and also SOAPAction (b) you also need to model
> state local to the node (retry counts) as well as data to be sent in a
> message--that's hard to do with an envelope-only model.


Again, sounds reasonable. However, I think that some careful wording
that strongly encourages features be modeled within the SOAP envelope
where possible and appropriate might be needed. Maybe some prescriptive
language along the lines of what you describe as being "outside"
the envelope would be in order.


> 
> Concern #3:  Does that mean we need to invent a new equivalent to
> "mustUnderstand" so an application can find out whether the binding in 
use
> supports the features it needs?
> Proposed resolution:  No.  The mustUnderstand we have deals with
> communication from node to node, and it's appropriate for that purpose. 
At
> a given node, such as a sender, it's your business to make sure the
> software you use (such as a binding implementation) supports the 
features
> you need (reliable delivery.)  If such features must be agreed between 
two
> nodes, and if they are modeled outside the envelope, then the binding
> implementations are implicitly obligated to negotiate the required 
feature,
> or else they wouldn't be compatible implementations of the same binding.
> In short: no explicit SOAP mechanism needed.  Keep it simple.


Agree on KISS;-) However, it also suggests that specifics regarding
extra-envelope feature negotiation should be called out in the framework.
Maybe it is in the Feature specification, or maybe in the Binding
Framework, but somewhere, it needs to be said that "features that are
expressed external to the SOAP envelope that require bilateral
behavior of the two SOAP nodes (Sender and Receiver) MUST provide
for negotiated understanding/agreement either through specific out-of-band
means or through a specified negotiation aspect/mechanism of the 
underlying
protocol."


> 
> Concern #4:  SOAP chapter 2 state machine works within a node.  The 
machine
> introduced in [1] effectively goes to the next hop.  Where do we find 
logic
> that covers an entire path?  Where are end to end semantics for features
> such as encryption?
> Proposed resolution:  these will show up above the SOAP core.  For 
example,
> MEP's can be created that build on the mechanisms above to provide an
> overall state machine for a message routed through intermediares.  On 
top
> of such an MEP, a feature specification could describe end-to-end 
behavior
> for some particular feature such as encryption.  Also:  many features 
can
> be built purely using mechanisms within the envelope, and these also 
build
> on the normal SOAP processing model (and possibly also on some
> intermediate-aware MEP).
> 
> We also agreed that it remains important to make the presentation of the
> state machines and the architecture yet clearer and more accessible.


Agreed.


> 
> TBTF members: did I get this about right?
> 
> [1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Oct/0146.html
> 
> ------------------------------------------------------------------------
> Noah Mendelsohn                                    Voice: 1-617-693-4036
> Lotus Development Corp.                            Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------------
> 
> 
> 
> 
>

Received on Wednesday, 17 October 2001 09:55:42 UTC