RE: notes from yesterday's telecom - request for Noah's thoughts

Stuart Williams wrote:
>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. 

>I guess there is also the question of what, precisely we regard as the
>message, and what we regard as the means to move/transfer the message. 


+1

PS  I would very much like to know Noah's impression of this thread.  Below
is an email from Noah, dated 11/4.  If I am interpreting Noah's thoughts
correctly, it is implied that a binding specifications would increase in
complexity if required features are not supported by an underlying protocol.
Taken out of context, it may be unfair to map this text on to the two views
Mark Jones documented, but it does seem contradictory to Glen's thoughts. 
Noah, is my interpretation of your email correct?  What are your thoughts
regarding Mark J's notes? 

Noah wrote(regarding my attempt to paraphrase his goal text):
>Hmm. I'm trying to remember the context of this.  Though we did discuss 
>application requirements, I think it's in a different sense than your text 

>uses the word.   I think what I would have suggested would be along the 
>lines of:

>In addition to the core SOAP requirement to transmit one-way messages, 
>bindings can be specified that provide support for richer message exhange 
>patterns, such as request/response, and for other optional "features" such 

>as reliable delivery.  The framework specifies the means by which 
>particular binding specifications can support such Message Exchange 
>Patterns and features.  In cases where more than one binding specification 

>supports a given MEP or feature, the framework captures the capabilities 
>that can be exposed in a common manner to applications.   When supporting 
>a given feature or MEP, a binding specification has the opportunity to 
>exploit native capabilities of the transport.  For example, a "reliable 
>delivery" feature may map naturally to the capabilities of a transport 
>that itself provides for reliable message queining;  the same "reliable 
>delivery" feature could also be implemented on an unreliable transport, 
>such as UDP, but the binding specification would likely be much more 
>complex.   Features which are expressed entirely in terms of SOAP header 
>entries benefit from the mechanisms of this specification (such as the 
>processing model in chapter 2);  in general such features can be supported 

>in a binding-independent manner (bindings are free to optimize the 
>implementation of such features, but all externally observable behavior 
>MUST be indentical to that which would have been obtained per the 
>requirements of this specification.)

-----Original Message-----
From: Williams, Stuart [mailto:skw@hplb.hpl.hp.com]
Sent: Wednesday, November 07, 2001 11:43 AM
To: 'jones@research.att.com'; 'Noah_Mendelsohn@lotus.com'; 'Oisin
Hurley'; 'Hugo Haas'; Chris.Ferris@sun.com; marc.hadley@sun.com; 'Mark
Nottingham'; ylafon@w3.org; www-archive@w3.org; Williams, Stuart; Henrik
Nielsen (E-mail); David_Fallside/Santa_Teresa/IBM%LOTUS@lotus.com;
Mountain, Highland M
Subject: RE: notes from yesterday's telecom


Mark,

Thanks for the write up. It's triggered a few ramblings... not necessarily
in direct response to points/issues that you raise. Regard what follows as
'stream of conciousness' stuff.

One of the things I think we repeatedly struggle with is whether we see the
framework as a descriptive tool or an operational framework.

For me a key role of the framework is to enable us to partion our
*descriptions* of required behaviour... if the *specification* for a binding
(a document for human consumption) claims to support a given named set of
features and message exchange patterns, then that specification document
describes how binding instances conforming to that binding spec accomplish
the provision of those features and meps. We have then also choosen to
factor out the description of mep's and features into separate
(referencable) chunks of spec in order for binding specs to reference them
in the claims that they make. ie. this is a framework to enable us to
partition and organise our descriptions of behaviour.

The discussion of the framework also takes an operational path around the
dynamic selection of bindings and the dynamic partition of how features are
provisioned (between envelope, binding and underlying protocol)... and the
'magic' that might be involved to do that. That seems to take us toward the
framework having an implication on implementation structure that I at least
had hoped to avoid. I think that the 'concrete' value of the indentifiers we
use to name 'bindings' and 'features' and 'properties' *may* have some
utility in description languages (interface, service, binding DLs), but I
would venture that that is for further study.

I think that the operational style of description verges on the
reconstruction of an abstract model within the spec. (that's not a
complaint, just an observation) which possibly hints at much of the material
we have been producing being used to revise the abstract model in order to
(perhaps) maintain the focus of the spec... Personnally, I think this is
important stuff to expresss, but I think that we know it is not to
everybodies taste... the "SOAP Binding Framework Concerns" thread Marwan
started [1] is quite long; involves a relatively small number of
participants; and I have no idea how broadly or narrowly those concerns are
shared by the larger WG.

To try and return more directly to your message... I'm inlined to agree that
your concept of "message infoset" and mine of "message exchange context" are
very much aligned. I also don't think I have any particular problem with the
"concepually cleaner" framing you offer toward the end of your write-up. I
think that there are things that are different between modules and bindings.
Henrik and I have spoken about this... the scope of a binding is between two
nodes adjacent on a message path, whereas header/body blocks reach beyond
single hops and the mechanisms that operate based on those blocks
potentially reach across multiple bindings. The way I try to square this
(with myself) is that there are semantics associated with the features
supported by a binding and they are driven by the relevant properties in the
context or fragments of message infoset. The operation of the binding with
respect to these features during message exchange influences
properties/fragments of mesage infoset at the next immediate recipient of
the message. The specification of a feature needs to detail whether it makes
sense to 'relay' that feature and if so how to relay that feature. May be
another way of think of this is that the features that are probably most
ameniable to expression outside the SOAP envelope are (loosely) equivalent
to SOAP blocks targetted at ../next.

Sorry... i've started diving in again... There are features that a the
specification of a binding will say nothing about (chicken and egg). I think
that if such features are to be capable of expression within the envelope
then the right place to define such feature expression is in the feature
specification.

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. 

I guess there is also the question of what, precisely we regard as the
message, and what we regard as the means to move/transfer the message. 

Apologies for the ramble... time presses and I need to go.

Stuart
[1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Oct/0228.html

> -----Original Message-----
> From: Mark Jones [mailto:jones@research.att.com]
> Sent: 06 November 2001 16:29
> To: 'Noah_Mendelsohn@lotus.com'; 'Oisin Hurley'; 'Hugo Haas';
> Chris.Ferris@sun.com; marc.hadley@sun.com; 'Mark Nottingham';
> ylafon@w3.org; 'Mark A. Jones (E-mail)'; www-archive@w3.org; Stuart'
> 'Williams (E-mail); Henrik Nielsen (E-mail);
> David_Fallside/Santa_Teresa/IBM%LOTUS@lotus.com; Mountain, Highland M
> Cc: jones@research.att.com
> Subject: 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 Wednesday, 7 November 2001 15:37:55 UTC