W3C home > Mailing lists > Public > www-archive@w3.org > November 2001

RE: notes from yesterday's telecom

From: Williams, Stuart <skw@hplb.hpl.hp.com>
Date: Mon, 12 Nov 2001 11:17:19 -0000
Message-ID: <5E13A1874524D411A876006008CD059F192746@0-mail-1.hpl.hp.com>
To: "'Mark Jones'" <jones@research.att.com>, Chris.Ferris@sun.com, Noah_Mendelsohn@lotus.com, henrikn@microsoft.com, highland.m.mountain@intel.com, hugo@w3.org, marc.hadley@sun.com, mnot@akamai.com, ohurley@iona.com, "Williams, Stuart" <skw@hplb.hpl.hp.com>, www-archive@w3.org, ylafon@w3.org, "David Fallside (E-mail)" <fallside@us.ibm.com>
Hi Mark

Another ramble... inspired by your note. Bottom line is that I think there
is a lot that we (you and I) would agree about. I think there are probable
some forms of expression that we disagree on, but there may be more
substance there than just presentation. 

I think the key difference is in where (concepually) we imagine the
partitioning of an outbound message infoset into SOAP message envelope with
in envelope expression of some features (as SOAP blocks) and wrappings
(carring feature expressions outside the envelope). I think I see the SOAP
layer being responsible for making the partitioning decision, forming the
SOAP envelope and delegating some feature expression to a suitably capable
binding. I think that you would push all this work into the binding and
maintain an abstract message infoset as low in the system (description) as

I think the difficult I have with that is not so much about the outbound
message formation, but about the inbound message processing and faithfully
honoring the SOAP message processing model in section 2. Processing features
expressed as SOAP headers within the message envelope calls into play the
SOAP processing rules. I don't see the binding as a separately 'addressable'
entity. Processing and removing elements from the envelope ahead of
subjecting the message to SOAP processing seems to me a violation of the
SOAP processing model. Of course, you may not see that as an implication of
what you suggest, in which case there is probably something that I'm not

Anyway... more discussion (ramblings) below for those with the time to read

Best regards


> -----Original Message-----
> From: Mark Jones [mailto:jones@research.att.com]
> Sent: 07 November 2001 21:43
> To: Chris.Ferris@sun.com;
> David_Fallside/Santa_Teresa/IBM%LOTUS@lotus.com;
> Noah_Mendelsohn@lotus.com; henrikn@microsoft.com;
> highland.m.mountain@intel.com; hugo@w3.org; jones@research.att.com;
> marc.hadley@sun.com; mnot@akamai.com; ohurley@iona.com;
> skw@hplb.hpl.hp.com; www-archive@w3.org; ylafon@w3.org
> Subject: RE: notes from yesterday's telecom
> Stuart,
> 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.

Ok... so I think that we're on the same page there.

> 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.

Again I think we're in the same place here... I think that there are two
forms of "pluggable" at work here. One is from the point-of-view of a
document collection... 'spec. pluggable' if you like where the
concepts/abstractions we put in place in our documentation enable new
features and bindings to specified in a way that they 'hook' in to that
conceptual framework and that the intended aggregate behaviour of some
specific collection of features and bindings is in some sense decernable
from the appropriate collection of specifications.

The other "pluggable" is more operational/technology centric where you would
like to be able to deliver features and bindings as (technology) components
that you can 'drop-in' to an implementation/deployment framework, and again
such that the aggregate behaviour of the collection is as would be expected
from the corresponding collection of specifications.

I think that there are some hard problems in this...

Just taking message exchange patterns for example. I think that we have
three types of message exchange patterns to talk about and if we don't keep
them separated in our dicussion, folks will get very confused:

1) Binding/Underlying protocol provided message exchange patterns: I have
been calling these transport message exchange patterns.

2) SOAP provided message exchange patterns: These are the message exchange
patterns that the SOAP layer provides to the entities that use SOAP, ie. the
primitive message exchange patterns from which applications build more
complex patterns. Recently I have been referring to these SOAP provided
MEP's as "application meps", but I now think that that is a confusing term
(to be confused with the 3rd category of MEPs). I don't really have a good
term for these MEPs other than to think of them as SOAP primitives cf.
XMLP_UNITDATA from the abstract model.

3) Application generated message exchange patterns: ie. the exchange
patterns synthesised by application through use of the primitive exchange
patterns provided by the SOAP layer. I think that term "application mep" is
a more natural fit for this type of mep.

Something that I think our spec should then describe is how to map SOAP
provided meps, 2 above, onto transport meps, 1 above. Of course if 1 and 2
are both open ended sets this becomes a big problem, and at present our
spec. really touch on this at all.

My hope would be that 1) and 2) are a relatively small in number. I might
even venture that the one-way message with corellation/casuality called out
in the AM is *the* single SOAP provided mep. In [1] I made some attempt to
show how you could recast request/response in terms of one-way with

From one-way plus cauality, I think that you can derive request/response,
request-(N)response. I also think that you can develop threaded
conversations and possibly deal with message order (in those cases where it
is important).

*IF* we have a small number of transport meps (1), say
single-request-response, single-one-way and single-one-way with casuality
then the we only have three mappings to describe. Of course each expansion
to the set of transport meps potentially adds a row/column to our matrix. I
think we'd really like to avoid this becoming an NxM problem!

Of course, so far I've ducked on features like reliablity, security or the
formation of contexts such as sessions/conversations and transactional

> 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.

Ok... but this pushes *all* the work into the binding. I think Henrik's
thesis is that much of the functionality can be provided as SOAP Modules
with header blocks that are generated and processed above the binding
according to the section 2 SOAP message processing model. I think his
concern also is that there is a danger of processing SOAP blocks down inside
the binding and that that would 'break' the SOAP message processing model.

I think this is probably where much of the debate lies. For some, almost
anything goes down in the binding subject to the sole provision that the XML
infoset of the message envelope submitted to a binding is faithfully
reproduced and delivered to the receiving end of that binding.

If we were to allow bindings to add/remove SOAP blocks from the envelope's
XML infoset, I think I would share the practical concern of how to we
distinguish those inserted by the binding from those originally submitted to
the binding. I would also share the perhaps more philosophical concern of
how can we process any such binding introducted headers at all AND argue
that the message is processed according to SOAP message processing rules...
to do that you must do the targetted mU checks which surely happen above the

At least logically, I think that the binding has no-business changing the
content of the SOAP envelope... and probably the safest way to accomplish
that is practically for a binding implementation not to insert and remove
things from the envelope.

The way I envisage things of that the SOAP layer does to more work, in that
it constructs the SOAP envelope based on the message infoset (your term) and
its knowledge (possibly hardwired) of the features and patterns supported by
the bindings available to it... ie. it is the SOAP layer, rather than the
binding, that makes a choice about whether a feature becomes expressed
within the SOAP envelope itself or whether responsiblity for providing the
functionality of a feature is delgated to the binding.

> (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.

Hmmm.... I can see where you're going here... and I could be happy with
it... (we perhaps needs some pictures, like where the SOAP processor lives
in this model). I think it lives in the world where the message infoset
becomes serialised into XML SOAP envelope, its contents and wrappings as low
down in the 'system' and as later as possible... which is probably ok on the
outbound message. But on the inbound message, I think that we have this
position that SOAP blocks MUST be processed according to the section 2
processing model... which means that the distinction between what is and is
not inside the envelope (rather than merely part of the message infoset) is

So... i think that I think the 'magic SOAP middleware' does more than merely
matchmaker... I think it needs to make the decisions about what
functionality gets provided by (available) SOAP modules and what gets
delegated to the binding.

I think that there are others still that would take the view that the SOAP
application itself forms the the SOAP envelope, and that it is the SOAP
layers job to deliver that envelope intact at least to an immediate
neighbour down a message path. I think that this view merely bundles
together the application and the SOAP layer and obviates making a
distinction between SOAP and the things that use SOAP, and possibly takes us
to a position that "SOAP is the SOAP message processing model and a set of
bindings (with their intrinsic behaviour)."

> 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.

I think I see two conceptual separations being discussed: 

1) where effectively, all work (partitioning the message infoset into
envelope and non envelope expression of features, envelope formation, and
envelope wrapping (feature expression outside of the envelope)).

2) where the SOAP layer takes on more of the work of partitioning the
message infoset, envelope formation and delegates the expression of some
features (outside the envelope) to the binding.

> 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.

I think these is true for either of the two conceptual viewpoint expressed

>    > So... I like the model you present at the end of your note, I also
>    > 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
>    > somewhere between the abstract and the pragmatic... ie in the abtract
we can
>    > pull together the package of serialising envelope, binding and
>    > protocol in zero time as late as possible... but that's not how it
>    > 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.


Apologies for being long winded (again).

> --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

Best regards

Stuart Williams
Received on Monday, 12 November 2001 06:20:41 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:42:03 UTC