- From: Mark Jones <jones@research.att.com>
- Date: Tue, 6 Nov 2001 11:26:47 -0500 (EST)
- To: "'Noah_Mendelsohn@lotus.com'" <Noah_Mendelsohn@lotus.com>, "'Oisin Hurley'" <ohurley@iona.com>, "'Hugo Haas'" <hugo@w3.org>, Chris.Ferris@sun.com, marc.hadley@sun.com, "'Mark Nottingham'" <mnot@akamai.com>, ylafon@w3.org, "'Mark A. Jones (E-mail)'" <jones@research.att.com>, www-archive@w3.org, "Stuart' 'Williams (E-mail)" <skw@hplb.hpl.hp.com>, "Henrik Nielsen (E-mail)" <henrikn@microsoft.com>, David_Fallside/Santa_Teresa/IBM%LOTUS@lotus.com, "Mountain, Highland M" <highland.m.mountain@intel.com>
- Cc: jones@research.att.com
This is a summary of and an attempt to make concrete the discussion of SOAP bindings and processing that we had in the TBTF call(s) on Nov. 5. Please correct me if my recollection or understanding of the discussion is wrong. [Terminological aside... By a "message infoset", I mean all of the semantically relevant information associated with the message -- as opposed to the XML infoset associated with an actual transmitted soap envelope. For example, some properties of the "message infoset" may end up being expressed as parameters in the underlying transport. A message infoset may be unpartitioned or partitioned. A partitioned message infoset has the properties divided into those handled by capabilites of the binding and those in the envelope; it may be equivalent to the "transport message exchange context" in Stuart's write-up.] As I understand the model that Glen was advocating, it looks like the following: (on the sender) application | | soap-processor-specific API that | conveys features (attribute-value | pairs), one of which can | be an envelope template V magic soap processor software, modules, ... | | a partitioned message infoset | (partitioned into binding data | and a soap envelope) V soap binding | | underlying transport protocol API | implemented by the soap binding V underlying protocol binding | | a soap envelope is transmitted | across the network on some | underlying protocol associated | with the given soap binding ... | | (on the | recipient) V underlying protocol binding | | (dispatch to the soap node) | V soap binding | | reconstructs some representation of | the message infoset, and extracts an actual | soap envelope (or envelope infoset) V soap processor (implements the soap processing algorithm on the soap envelope or envelope infoset) [I'd like to complete the diagram, but we didn't talk about the subsequent phases of processing by a recipient -- intermediary or final destination.] Questions: 1) There remains the thorny (terminological?) issue regarding whether one can tease apart the notion of a "module" from some other dispatching/processing component in a soap node, so I'm just calling it "magic soap processor software". 2) Can the application influence (other than indirectly by its choice of features) the actual binding selected by the magic soap processor software? 3) It is not clear whether the message infoset is determined just by the application in its choice of features or additionally by the magic soap processor software, but I assume the latter (it could have hardwired information, access to WSDL, etc.). Issues: 1) There is some fuzziness about how much awareness/control the application has with regard to how features get expressed (at the binding level or in the envelope). On the one hand, you might require everything that the application wants to say to be a feature (even expressing the intent of the body) with no application awareness of what blocks might get transmitted. The application just says I want "reliable messaging", "security", this RPC, etc. and doesn't know/care how it ends up being implemented (by underlying protocol capabilities or by data placed in the envelope). On the other hand, some soap applications may have the view that they are really playing pretty directly with the soap processing model (inserting and responding to blocks). This sets up a bit of tension about who is determining the soap message that will actually be seen by the next processor. This view acknowledges that applications may want to pick encodings, establish relationships between modules, etc., and this is most naturally done by talking about blocks and their relationships -- remember dependsOn? (In a purely feature-based model, we might have to invent a feature-based version of dependsOn!) If you allow application interfaces to specify a mix of abstract features and specific headers (or envelope templates), then you start down a road which seems to encourage applications to be aware of which pieces of software will be implementing the desired functionality (bindings or soap processors). This is especially true if there are rules about magic soap middleware and bindings not messing with application-provided blocks. 2) Glen asserted that while it is possible in this model for a soap binding itself to add blocks to the soap envelope to do its job, the recipient soap binding code would be obliged to strip them out before the usual soap envelope processing model was invoked. If I understood him correctly, blocks inserted by the magic soap processor software, however, could/would be seen by the next processor. There was a further assertion that a given feature should never be cooperatively implemented by a combination of blocks inserted by the magic soap processor software (to be executed by some downstream processor) and by capabilities of the soap binding. Strictly speaking, this constraint doesn't seem to be required by the model. ================================================================ I question whether it wouldn't be conceptually cleaner to think of a soap binding as something that takes an unpartitioned message infoset and decides for each feature how it should be implemented across: (1) the native capabilities of the underlying transport, (2) capabilities built into the binding itself, and (3) headers which will trigger the subsequent, requisite processing. In this view, the magic soap processor software would be responsible for selecting a well-suited soap binding based on the features required by the application, but wouldn't further try to tell the binding how to do its job. The soap binding would take responsibility for deciding how to partition the functionality across the above 3 components (the underlying transport, itself, and the envelope). Reading the spec for a soap binding would tell you all you need to know about how a given binding did such a partitioning. The goal of a binding, simply stated, would be to carry out the intentions embodied in an (unpartitioned) message infoset. It sounded like this proposal had been considered before and there were issues with it, but we didn't have time to explore that thoroughly. ================================================================ I think that captures the gist of the discussion as I experienced it. It represents my understanding of the model as it exists, which, while not necessarily correct, is closer than it was before the telcon! --mark Mark A. Jones AT&T Labs - Research Shannon Laboratory Room A201 180 Park Ave. Florham Park, NJ 07932-0971 email: jones@research.att.com phone: (973) 360-8326 fax: (973) 360-8970
Received on Tuesday, 6 November 2001 11:27:00 UTC