- From: <Noah_Mendelsohn@lotus.com>
- Date: Tue, 16 Oct 2001 21:41:02 -0400
- To: xml-dist-app@w3.org
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