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 Sunday, 4 November 2001 22:30:53 UTC