RE: Capturing Noah's Goal - Framework Description

Noah,

Thanks for forwarding this on to the group.  Strangely enough, this is the
first I have seen this note, since I did not receive the original.  Weird.

Anyway, the context of the original conversation, if I remember correctly,
was to build on the list of framework goals at the start of our content.
These should be short statements which give the reader an intro of the
framework.  

Regarding your comments:

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

You seem to be seeing things they way I was, in that our framework will aid
binding specification writers in capturing messaging related features (like
reliable delivery) whether they are supported natively by the underlying
protocol or not.  That is how I interpret your statement "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."
This is what I expected also, but my concern is that the framework is very
light on how such complex spec would be constructed, and what such specs
would include to facilitate interoperability.  Yes, I know we need to keep
things simple, but we are not talking about a framework for implementation
code, we are talking about a framework to create a clear and testable
binding spec (at least that is what I thought).

Thanks for your input.  Sorry you cannot make Monday's meeting.

Highland

-----Original Message-----
From: Noah_Mendelsohn@lotus.com [mailto:Noah_Mendelsohn@lotus.com]
Sent: Sunday, November 04, 2001 8:19 PM
To: 'Oisin Hurley'; 'Hugo Haas'; Chris.Ferris@sun.com;
marc.hadley@sun.com; 'Mark Nottingham'; 'Noah Mendelsohn';
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
Cc: Mountain, Highland M
Subject: Re: Capturing Noah's Goal - Framework Description


I sent Highland the following reply, and now realize that it wasn't copied 
to the rest of you.  This is a couple of days old, so it is not 
specifically in response to comments from Glen & Co.  Thanks, and sorry 
for the delay.

------------------------------------------------------------------------
Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------------







Noah Mendelsohn
11/02/2001 03:21 PM


        To:     "Mountain, Highland M" <highland.m.mountain@intel.com>
        cc: 
        Subject:        Re: Capturing Noah's Goal - Framework Description


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

Still a bit lumpy, but closer to what I meant, I think.  Feel free to 
forward to the group.  Unfortunately, I am unlikely to be on the call. 
Thanks.

------------------------------------------------------------------------
Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------------







"Mountain, Highland M" <highland.m.mountain@intel.com>
11/02/2001 12:35 PM

 
        To:     "Noah Mendelsohn (E-mail)" <Noah_Mendelsohn@lotus.com>
        cc:     "Mountain, Highland M" <highland.m.mountain@intel.com>
        Subject:        Capturing Noah's Goal - Framework Description




To advise communicating peers how to craft transport binding 
specifications
which facilitate system interoperability. <!-- No Problem --> 

Here is my first attempt to capture your statement about the framework. 
The
wording is rough but I need to capture something prior to Monday's 
meeting.
Hope the main concepts are accurate:

Any binding specification would have a set of messaging requirements. Some
of these requirements could be expressed as features provided by the
underlying protocol's native feature set.  Other requirements of the 
binding
may need to be provided outside of the underlying protocol. 
The requirements not provided natively by the underlying protocol of 
choice
will need to be expressed in the resulting binding specification, as
features and associated properties.  Engaged nodes will have to determine
which resident modules can satisfy the features outside the scope of the
underlying protocol, in order to be compliant with a given binding
specification. 


Highland Mary Mountain

Intel Corporation
eBusiness Solutions Lab
(480) 552 - 3817

highland.m.mountain@intel.com

Received on Monday, 5 November 2001 01:21:46 UTC