TBTF: Four possible points of concensus

As was announced on Oct. 11 [1], the the transport binding task force TBTF
has prepared several documents that capture design ideas relating to a
transport binding framework.  In the meantime, the TBTF been working to
resolve a set of concerns as to how these proposals relate to the rest of
SOAP architecture, and some other similar issues.

On a TBTF call today, we discussed four directions that may lead to a
resolution of some of these concerns.  This note is intended primarily for
the benefit of the TBTF members, as we agreed to set these ideas down for
discussion.  We are generally trying to do our work "in public", so
comments from other members of the Protocol WG or other members of the
dist-app community are also welcome (though you may not find enough
background here that everything will be entirely comprehensible....if these
ideas start to gel within the TBTF, we will definitely present them in a
more coherent manner for easier consideration by others.)

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.

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.

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.

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.

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 Tuesday, 16 October 2001 21:50:27 UTC