RE: notes from yesterday's telecom

Stuart,

Thanks for the lengthy reply.  It does further and sharpen the discussion.

    > From: "Williams, Stuart" <skw@hplb.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>
    > Subject: RE: notes from yesterday's telecom
    > Date: Mon, 12 Nov 2001 11:17:19 -0000

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

I think the main difference is that I see the act of partitioning as
an act of binding in the binding continuum.  Partitioning yields a
division of responsibility for transport and delivery processing which
must be correspondingly matched in the inbound message processing by a
subsequent node(s).  That is very similar to the typical notion of
bindings.  They impose a model for transport and delivery which must
be correspondingly implemented by subsequent node(s).

Suppose I have an application that supplies an attachment (and
references it with some "attachment" URI).  T could have a binding
that decides whether to use a MIME layer or base64-encode it into a
message header depending on the type of the data, length of the data,
etc.  The binding could be implemented such that attachment URI
references would succeed no matter which encoding/transport mechanism
happened to be used.  The SOAP layer should not know the details of
the algorithm used by this binding, and it certainly shouldn't have to
do the base64-encode itself just to satisfy some rule that a binding
can't touch the envelope.

The problem I have with the strategy of making the SOAP layer (my
magic SOAP middleware) handle the partitioning (or reassembly from the
recipient point of view) is that this middleware is not documented the
way that a binding would be.  If it partitions and layers things in
odd ways, it is likely there will be impedence mismatches that are
wholely undocumented.  A binding can do clever partitioning while
still being well-documented and re-implementable by others wishing to
do so.  I don't see how placing this responsibility inside a magic
SOAP processor black box is an advantage.

By the way, I'm not against some scheme for having the SOAP layer
compose binding as long as there is a mechanism for the recipient
to identify such a composition.  You could think of the MIME binding
that I suggested above as being an equally useful transformation
over various underlying transports.

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

I would agree that processing and removing elements from the envelope
ahead of subjecting the message to SOAP processing IS a violation of
the SOAP processing model.  That is what I thought Glen was
advocating, not me.  Since the processing model for headers has such a
nice independent, extensibility model, I was assuming that in some
cases a feature might simply be handled (e.g., by the 'next' actor)
through the normal SOAP processing mechanism.  In the spirit of "one
man's binding feature is another man's SOAP extension", I was simply
advocating that we not draw any bright line between them.  An
application requesting a feature certainly should not care what
machinery implements it.  The partitioning code, wherever we decide it
lives, would determine how the feature was to be expressed.


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

    > Best regards

    > Stuart

    > > -----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
    > corellation/causality.

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

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

    > Yep...

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

    > Agreed.

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

No, no.  I also want them to be handled in the SOAP processing model.
See above.  I just object to thinking of the decision to place feature
functionality in headers as somehow not being a binding decision, or a
binding strategy.  SOAP bindings for functionally impoverished
transport bindings will indeed frequently resort to using SOAP Modules
with headers to accomplish things that they would otherwise not be
able to accomplish.

When you say it pushes *all* the work into the binding, the problem is
that all the work has to go somewhere.  I think it greatly complicates
the job of the SOAP middleware to make it hyperaware of the
algorithms/strategies employed by the SOAP bindings that it has
available to it.  Furthermore, you have to reason about the joint
behavior the SOAP middleware and SOAP bindings to understand how a
given message infoset will end up being serialized.  I'm advocating a
broader notion of binding that simply encapsulates that knowledge in the
binding itself.

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

Binding-induced headers would be targetted appropriately (e.g., at
actor 'next') and appropriately marked mU.  I don't see why they
otherwise need to be distinguished ... and for good reason.  There
isn't any bright line between features managed by bindings and those
managed by modules (perhaps in coordination with bindings).  A given
transport binding that did not have security in it today may evolve
to have security in it tomorrow.  An appropriately written SOAP
binding for that transport might migrate support for that feature from
the envelope to the transport over time.  I could envision that happening
without recoding any of the SOAP middleware that was deployed to be
aware of the change -- just revving the SOAP binding.  This is the power
of letting the bindings handle the partitioning.

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

Here we may disagree.  If you want applications to be blissfully
unaware about whether a given feature is implemented within the
envelope, outside the envelope, or possibly using support from within
and without, then something has to do the selecting of a transport
strategy and the partitioning among the various mechanisms for
serialization.  I'd like to think of that something as a binding,
or a binding strategy at the very least.  (Also, consider the above
example of a transport binding which evolves native support for some
feature.)

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

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

Maybe it is a matter of semantics as to whether those decisions are made by the
binding or the middleware.

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

Now we effectively have the applications knowing so much about
bindings that they feel comfortable making partitioning decisions.
Argh!!  This definitely feels like a move in the wrong direction from
a separation of concerns perspective.

--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 Monday, 12 November 2001 15:44:50 UTC