notes from yesterday's telecom

[I sent this last night to Glen and Highland for comments and sanity
check, but figured I may as well send it out to all so you can get
it ASAP.]

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:28:47 UTC