RE: notes from yesterday's telecom

Stuart,

   > From: "Williams, Stuart" <skw@hplb.hpl.hp.com>
   > To: "'jones@research.att.com'" <jones@research.att.com>,
   >         "'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,
   >         www-archive@w3.org, "Williams, Stuart" <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>
   > Subject: RE: notes from yesterday's telecom
   > Date: Wed, 7 Nov 2001 18:42:49 -0000 
   > ...

For me, the main issue has to do with getting the separation of
concerns right in the model.  This doesn't mean that someone can't
create an implementation that blurs everything together, but you
want a decomposition that encourages the particular kinds of
abstractions that you want to make.

For example, we have often talked about "pluggable" bindings.  To me,
that strongly suggests that SOAP processors wouldn't be required to
know too much about bindings.  The magic SOAP middleware would know
about binding capabilities (what features they agree to handle), but
certainly not their algorithms/strategy -- whether they use the
envelope or their own facilities or some combination, whether they use
encoding layers (DIME/MIME) or base64 encoding into the envelope, etc.
Again, processors would be free to hardwire an understanding of
binding internals for the purpose of optimizing the selection or
invocation of a binding, but that would be viewed as exceptional from
a separation-of-concerns perspective.

Someone who wants to reimplement a given binding on other platform
will need to know the algorithmic/strategic details of that binding,
but the soap processor middleware (on the sender or receiver) needn't.
Furthermore, we want interoperability.  A reasonable interoperability
condition would be that the other site is running the same (or
compatible) binding and has the proper application-level software
running.  It would be much tougher on interoperability if you also had
to take into account arbitrary transformations performed by unnamed,
magic SOAP processor middleware.

Maybe it would help to enumerate what we think represent are
appropriate separations of concern.  Here is my list:

(1) A sending application should be able to abstractly
    specify features, message exchange patterns, and blocks
    (the message infoset or message exchange context) in a
    fashion that is binding-independent.

(2) A binding accepts this message context (from (1)) and
    implements some strategy for delivery to the next node
    which is faithful to the requested features, etc. in
    the message infoset.

(3) The principal job of the magic SOAP middleware is then
    cleanly reduced to that of matchmaker between (1) and (2).
    Given a message infoset, it finds an appropriate binding to
    handle it.

Sure, a given implementation could let a sending application designate
the binding to be used.  A given implementation could use its detailed
knowledge of a binding's algorithm to optimize how it invokes a
binding or munges the data before doing so.  Implementations are
always free to selectively disregard conceptual separations for their own
purposes.  But note that even in these optimized cases, the receiver
still cleanly needs only to know whether it implements the binding
[discretely identified] being used by the sender.  It doesn't have
to know about magic in the sending processor.

   > So... I like the model you present at the end of your note, I also find
   > myself in broad agreement with Glen and what I have some difficulty with is
   > identifying quite where the two of you part company... I think it lies
   > somewhere between the abstract and the pragmatic... ie in the abtract we can
   > pull together the package of serialising envelope, binding and underlying
   > protocol in zero time as late as possible... but that's not how it happens
   > in practice. 

Perhaps this is somewhat analogous to the view that we have adopted
toward the SOAP envelope processing model.  It has to act as though it
processed all of the headers and checked for mustUnderstand faults,
whether it in fact does so.  As long as an implementation (externally)
appears to adhere to a clean conceptual model, it can optimize in any
way it cares to.

--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 Wednesday, 7 November 2001 16:43:32 UTC