W3C home > Mailing lists > Public > xml-dist-app@w3.org > August 2001

TBTF: Binding First Cut for Review 8/13

From: Hugo Haas <hugo@w3.org>
Date: Mon, 13 Aug 2001 12:29:24 -0400
To: xml-dist-app@w3.org
Message-ID: <20010813122923.D11791@jibboom.w3.org>
I am forwarding here a discussion which started within the transport
binding taskforce (TBTF) and didn't make it to any publicly archived
mailing list. This discussion will continue on xml-dist-app.

Please note that those discussions might lack a little bit of context
for people who are not within the taskforce, and that the taskforce is
working towards making a concrete proposal for people to comment on.

We would therefore appreciate if people were holding their comments
for now. Thanks.

Regards,

Hugo

-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/ - tel:+1-617-452-2092

attached mail follows:


All, 

 Glen, Noah and I met Thursday to create the  "First Cut" Binding
specification.  This "First Cut" is meant to convey the general direction of
the spec for TF feedback/approval.  We will review this at the Monday,
August 13th con call.      

Specification Outline:
1) Architectural Definition of a Binding
2) Sender "Mandatory" or Core Properties (Request/Response MEP example) 
3) Sending Processor States/Behaviors
4) Receiver States/Behaviors (Request/Response MEP example) 
5) Binding Instances ( to be developed )
6) Issues Appendix

Next Steps from the 8/9 meeting:

1) Review with task force 
2) Address Issues
3) MEP Prose/Structure
4) Specific protocol instances and develop intermediary scenarios


Glen - Thanks for sending me your minutes.  
Noah and Glen - If I have misinterpreted any part of our discussion, please
let us know.


Thanks, Highland

Start of First
Cut====================================================================


1) Architectural Definition of a Binding

Architectural Description (as discussed at the FtF):

The information needed to send a message and the information available when
receiving a message is modeled abstractly as a set of named properties,
some of which may be represented as standard XML infoset entries.


Application - A SOAP node can bind to an underlying protocol for the
purpose of sending or receiving a SOAP message.


Set of Properties - Exchanging information between two or more peers often
involve agreeing on a set of properties that characterize a message
exchange and context in which the exchange is taking place. Examples of
such properties include message exchange pattern used, message role,
quality of service supported, protocol used, means of correlation,
application end point, transport end point, message encoding and
fault/error definition. Each of these properties has associated data
elements which may be defined in several ways:


1) within the underlying protocol


2) within the underlying protocol's extensibility mechanism


3) within the SOAP envelope using the SOAP extensibility mechanism


Note that it is not a requirement for a particular binding to support all
properties. Properties can be left undefined for a given named binding and
the binding specification would not reference that property in any way
shape or form. Some properties are likely to be supported by most bindings
(the core properties concept).


The Set of Properties, referenced above, is intended to indicate the
open-ended set of properties used to describe message exchange in SOAP
based protocols. Of these properties, there are some properties that are
expected to be specified by most bindings. It is strongly recommended that
a binding considers how these core properties may be supported.


Specifications for particular bindings and message exchange patterns can
require additional such properties and can provide additionally for
properties that are optional. This specification does not define any formal
framework for defining new properties.


Placement of property related information is at the discretion of the Named
Binding Author and Named Binding Customer. A Named Binding could include
flexibility as to where property information is placed over the wire for a
given property. One property could be defined as data in the protocol
header and in the SOAP envelope. It would be up to the Binding user to
implement in a way best suited to his or her application.


SOAP Envelope - This could contain Transport Binding related blocks, as
defined in the Named Binding.


Transport, e.g. HTTP - Transport Protocol header content may be derived
from the Named Binding definition.


On the wire representation - The Named Binding can specify information
included in the protocol header and in the SOAP envelop. The sending SOAP
node will be directed by the Named Binding to create the appropriate "on
the wire" representation of this bound message.


 <<bindingstack.ZIP>> 

2) Sender "Mandatory" or Core Properties (see Issue Appendix #1 below)
(in this case a Binding supporting the Request Response MEP ) 

Property named "SOAP.MEP" : value is an enumeration over { strings, URIs }
	Property named "RequestResponse.MsgRole" value is { request,
response }
	Property named "RequestResponse.NodeRole" value is { sender,
receiver }

Property named "?.destination" : opaque URI
	This URI is presumed to be sufficient (either through some kind of
directory lookup
	which ties the resource to a particular binding, or by encoding the
information into
	the URI itself) to 
	a) determine the binding in use
	b) determine the binding-specific actual endpoint address.

Property named "SOAP.Envelope" : XML (soap envelope) (see Issue Appendix #2
and 3 below)

Information in the property bag will in general be modeled as XML header
entries
and bodies, primarily in those situations where the application expects it
to be reproduced after transmission in that form, in other cases the
information should be modeled abstractly in terms of intention rather than
syntax.

An envelop template can be used to model such properties being represented
in the SOAP envelope.  

3) Sending Processor States/Behaviors

The Sending Processor will attempt to access the ?.Destination URI.  

A fault may be passed back by the processor due to the following reasons:
a) URI not recognized
b) URI was an unsupported binding
c) URI did not support the MEP specified
d) URI can not be reached

Processor success will result in the message being wire encoded per the
binding specification.  Success will also result in the properties "we" care
about being 
reconstructed at the receiver.

4) Receiver States/Behavior
(in this case a Binding supporting the Request Response MEP ) 

An event has occurred where a binding specified message has been received.
In fully reassembling the envelope, the receiver needs to:

a) Determine the complete message content per the given binding
specification (message fragments need to be reassembled, etc)
b) Verify message role (RequestResponse.MsgRole) is a "request" and set the
value of RequestResponse.NodeRole to "receiver"
c) Establish Property ResponseCookie per binding specification(correlation
mechanism bound by specified binding? see Issue Appendix #4 below)
d) Reconstruct Envelope (how will extensions be used, etc)

5) Binding Instances

a) HTTP
b) SMTP
c) Intermediary Behavior


6) Issue Appendix:

ISSUE 1: What is the structure of property names?  URIs, short names, etc?
This structure needs to be defined early.

ISSUE 2: Should the app provide a "template" envelope which potentially gets
modified by pieces of the SOAP system (extensions,bindings), or a more
abstract set of stuff which gets built into an actual SOAP envelope only at
a very late stage in the processing (typically right before engaging the
wire).

ISSUE 3: If the application is handing down pieces of XML into the "engine",
we need to deal with potential conflicts with prefixes/ids/etc.  - this can
get hairy.  We need to decide how much latitude the app has over this stuff.
This arises at least for headers + bodies, and is a potential problem
regardless of whether the app hands a "complete" (to some degree) envelope
to the SOAP processor or just fragments.

ISSUE 4: No firm resolution to correlation/extensions, more discussion is
needed. Correlation and the utility/wisdom of expressing a canonical XML
serialization + rules for a generic req/resp extension as opposed to just
leaving this up to the binding. 

End of First
Cut====================================================================



Highland Mary Mountain

Intel Corporation
eBusiness Solutions Lab
(480) 552 - 3817

highland.m.mountain@intel.com




attached mail follows:



In order to get a better idea about how various protocols relate to the
properties, I wrote up a short-story about how HTTP, SMTP, and TCP deals
with them - see attached HTML. It deals with the message exchange
patterns, destination URIs, and correlation as seen by these protocols.
I have not described how a SOAP envelope can be carried within these
protocols which I believe is the binding proper.

Please do not take this as an exhaustive description of the protocols!

Henrik Frystyk Nielsen
mailto:henrikn@microsoft.com

 -----Original Message-----
From: 	Mountain, Highland M [mailto:highland.m.mountain@intel.com] 
Sent:	Friday, August 10, 2001 14:04
To:	'David Fallside'; 'gdaniels@macromedia.com';
'skw@hplb.hpl.hp.com'; 'Noah Mendelsohn'; Frystyk;
'jones@research.att.com'; 'marc.hadley@Sun.COM'; 'Chris.Ferris@Sun.COM';
'ylafon@w3.org'
Cc:	'hugo@w3.org'; 'ylafon@w3.org'; 'ohurley@iona.com'; 'Alan
Kropp'; 'mnot@akamai.com'
Subject:	TBTF: Binding First Cut for Review 8/13

All, 

 Glen, Noah and I met Thursday to create the  "First Cut" Binding
specification.  This "First Cut" is meant to convey the general
direction of the spec for TF feedback/approval.  We will review this at
the Monday, August 13th con call.      

Specification Outline:
1) Architectural Definition of a Binding
2) Sender "Mandatory" or Core Properties (Request/Response MEP example) 
3) Sending Processor States/Behaviors
4) Receiver States/Behaviors (Request/Response MEP example) 
5) Binding Instances ( to be developed )
6) Issues Appendix

Next Steps from the 8/9 meeting:

1) Review with task force 
2) Address Issues
3) MEP Prose/Structure
4) Specific protocol instances and develop intermediary scenarios


Glen - Thanks for sending me your minutes.  
Noah and Glen - If I have misinterpreted any part of our discussion,
please let us know.


Thanks, Highland

Start of First
Cut====================================================================


1) Architectural Definition of a Binding

Architectural Description (as discussed at the FtF):

The information needed to send a message and the information available
when
receiving a message is modeled abstractly as a set of named properties,
some of which may be represented as standard XML infoset entries.


Application - A SOAP node can bind to an underlying protocol for the
purpose of sending or receiving a SOAP message.


Set of Properties - Exchanging information between two or more peers
often
involve agreeing on a set of properties that characterize a message
exchange and context in which the exchange is taking place. Examples of
such properties include message exchange pattern used, message role,
quality of service supported, protocol used, means of correlation,
application end point, transport end point, message encoding and
fault/error definition. Each of these properties has associated data
elements which may be defined in several ways:


1) within the underlying protocol


2) within the underlying protocol's extensibility mechanism


3) within the SOAP envelope using the SOAP extensibility mechanism


Note that it is not a requirement for a particular binding to support
all
properties. Properties can be left undefined for a given named binding
and
the binding specification would not reference that property in any way
shape or form. Some properties are likely to be supported by most
bindings
(the core properties concept).


The Set of Properties, referenced above, is intended to indicate the
open-ended set of properties used to describe message exchange in SOAP
based protocols. Of these properties, there are some properties that are
expected to be specified by most bindings. It is strongly recommended
that
a binding considers how these core properties may be supported.


Specifications for particular bindings and message exchange patterns can
require additional such properties and can provide additionally for
properties that are optional. This specification does not define any
formal
framework for defining new properties.


Placement of property related information is at the discretion of the
Named
Binding Author and Named Binding Customer. A Named Binding could include
flexibility as to where property information is placed over the wire for
a
given property. One property could be defined as data in the protocol
header and in the SOAP envelope. It would be up to the Binding user to
implement in a way best suited to his or her application.


SOAP Envelope - This could contain Transport Binding related blocks, as
defined in the Named Binding.


Transport, e.g. HTTP - Transport Protocol header content may be derived
from the Named Binding definition.


On the wire representation - The Named Binding can specify information
included in the protocol header and in the SOAP envelop. The sending
SOAP
node will be directed by the Named Binding to create the appropriate "on
the wire" representation of this bound message.


 << File: bindingstack.ZIP >> 

2) Sender "Mandatory" or Core Properties (see Issue Appendix #1 below)
(in this case a Binding supporting the Request Response MEP ) 

Property named "SOAP.MEP" : value is an enumeration over { strings, URIs
}
	Property named "RequestResponse.MsgRole" value is { request,
response }
	Property named "RequestResponse.NodeRole" value is { sender,
receiver }

Property named "?.destination" : opaque URI
	This URI is presumed to be sufficient (either through some kind
of directory lookup
	which ties the resource to a particular binding, or by encoding
the information into
	the URI itself) to 
	a) determine the binding in use
	b) determine the binding-specific actual endpoint address.

Property named "SOAP.Envelope" : XML (soap envelope) (see Issue Appendix
#2 and 3 below)

Information in the property bag will in general be modeled as XML header
entries
and bodies, primarily in those situations where the application expects
it
to be reproduced after transmission in that form, in other cases the
information should be modeled abstractly in terms of intention rather
than syntax.

An envelop template can be used to model such properties being
represented in the SOAP envelope.  

3) Sending Processor States/Behaviors

The Sending Processor will attempt to access the ?.Destination URI.  

A fault may be passed back by the processor due to the following
reasons:
a) URI not recognized
b) URI was an unsupported binding
c) URI did not support the MEP specified
d) URI can not be reached

Processor success will result in the message being wire encoded per the
binding specification.  Success will also result in the properties "we"
care about being 
reconstructed at the receiver.

4) Receiver States/Behavior
(in this case a Binding supporting the Request Response MEP ) 

An event has occurred where a binding specified message has been
received.  In fully reassembling the envelope, the receiver needs to:

a) Determine the complete message content per the given binding
specification (message fragments need to be reassembled, etc)
b) Verify message role (RequestResponse.MsgRole) is a "request" and set
the value of RequestResponse.NodeRole to "receiver"
c) Establish Property ResponseCookie per binding
specification(correlation mechanism bound by specified binding? see
Issue Appendix #4 below)
d) Reconstruct Envelope (how will extensions be used, etc)

5) Binding Instances

a) HTTP
b) SMTP
c) Intermediary Behavior


6) Issue Appendix:

ISSUE 1: What is the structure of property names?  URIs, short names,
etc?  This structure needs to be defined early.

ISSUE 2: Should the app provide a "template" envelope which potentially
gets modified by pieces of the SOAP system (extensions,bindings), or a
more abstract set of stuff which gets built into an actual SOAP envelope
only at a very late stage in the processing (typically right before
engaging the wire).

ISSUE 3: If the application is handing down pieces of XML into the
"engine", we need to deal with potential conflicts with
prefixes/ids/etc.  - this can get hairy.  We need to decide how much
latitude the app has over this stuff.  This arises at least for headers
+ bodies, and is a potential problem regardless of whether the app hands
a "complete" (to some degree) envelope to the SOAP processor or just
fragments.

ISSUE 4: No firm resolution to correlation/extensions, more discussion
is needed. Correlation and the utility/wisdom of expressing a canonical
XML serialization + rules for a generic req/resp extension as opposed to
just leaving this up to the binding. 

End of First
Cut====================================================================



Highland Mary Mountain

Intel Corporation
eBusiness Solutions Lab
(480) 552 - 3817

highland.m.mountain@intel.com


 <<sample_bindings.zip>> 


attached mail follows:


[ I would like to forward those messages to xml-dist-app. Highland and
  Henrik, is that ok with you? ]

* Mountain, Highland M <highland.m.mountain@intel.com> [2001-08-10 14:03-0700]
> 2) Sender "Mandatory" or Core Properties (see Issue Appendix #1 below)
> (in this case a Binding supporting the Request Response MEP ) 
[..]
> Property named "?.destination" : opaque URI

What do you mean by "opaque URI"?

RFC1630[1] states:

         As the rest of the URL (after the hostname an port) is opaque
         to the client, it shows great variety but the following are all
         fairly typical.

By definition, a URI is opaque.

[..]
> 3) Sending Processor States/Behaviors
> 
> The Sending Processor will attempt to access the ?.Destination URI.  
> 
> A fault may be passed back by the processor due to the following reasons:
> a) URI not recognized

I am not sure what this means. Does that mean that the URI scheme is
unknown? That the URI was malformed? Something else?

> b) URI was an unsupported binding

I would tend to think that (a) and (b) are the same.

> c) URI did not support the MEP specified

Shouldn't that be that the binding doesn't support the MEP specified?
A URI is just an identifier for something.

> d) URI can not be reached

A host/destination can be unreachable, I am not sure that a URI can be
"reached".

I would say that the destination could not be reached, or that the
URI could not be dereferenced.

  1. http://www.ietf.org/rfc/rfc1630.txt
-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/ - tel:+1-617-452-2092

attached mail follows:


I personally have no objection forwarding to dist-app.

>> By definition, a URI is opaque.

Right, we're picking up on that.  In other words, we're making clear that 
at the level of the SOAP spec, no substructure in the URI is used to 
specifically denote particular bindings, MEP's etc.  For example, we don't 
say one way or the other whether http:.... will come to identify a 
particular binding, or whether it will be generically useable with all 
http bindings.  Indeed, one could have URN:.....  looked up in some 
directory and have that use one of the http: bindings.  So, opaque in that 
sense.

>> Shouldn't that be that the binding doesn't support the MEP specified?

Maybe.  You might have a directory (e.g. UDDI) that says:  "this resource 
supports one way, this other one supports req/resp."  So, it's possible 
that you know how to talk to the particular resource.  We're anticipating 
that possibility.   You're right:  in the simple case the resource URI 
will suggest a binding, which either will or won't support some particular 
MEP.  I think that more indirect scenarios are possible and should be 
supported.

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



attached mail follows:


Highland et. al,

Some comments in line...

Best regards

Stuart


> -----Original Message-----
> From: Mountain, Highland M [mailto:highland.m.mountain@intel.com]
> Sent: 10 August 2001 22:04
> Subject: TBTF: Binding First Cut for Review 8/13
> 
> 
> All, 
> 
>  Glen, Noah and I met Thursday to create the  "First Cut" Binding
> specification.  This "First Cut" is meant to convey the general direction
of
> the spec for TF feedback/approval.  We will review this at the Monday,
> August 13th con call.      
> 
> Specification Outline:
> 1) Architectural Definition of a Binding
> 2) Sender "Mandatory" or Core Properties (Request/Response MEP example) 
> 3) Sending Processor States/Behaviors
> 4) Receiver States/Behaviors (Request/Response MEP example) 
> 5) Binding Instances ( to be developed )
> 6) Issues Appendix
> 
> Next Steps from the 8/9 meeting:
> 
> 1) Review with task force 
> 2) Address Issues
> 3) MEP Prose/Structure
> 4) Specific protocol instances and develop intermediary scenarios
> 
> 
> Glen - Thanks for sending me your minutes.  
> Noah and Glen - If I have misinterpreted any part of our 
> discussion, please
> let us know.
> 
> 
> Thanks, Highland
> 
> Start of First
> Cut===========================================================
> 
> 
> 1) Architectural Definition of a Binding

I'm assuming that this section (up to "2) Sender "Mandatory"..." below)  is
narrative elaborating on the diagram in 'bindingstack.zip'.

> 
> Architectural Description (as discussed at the FtF):
> 
> The information needed to send a message and the information available
when
> receiving a message is modeled abstractly as a set of named properties,
> some of which may be represented as standard XML infoset entries.

Agreed... 

> 
> Application - A SOAP node can bind to an underlying protocol for the
> purpose of sending or receiving a SOAP message.
>
>
> Set of Properties - Exchanging information between two or more peers often
> involve agreeing on a set of properties that characterize a message
> exchange and context in which the exchange is taking place.

Are we considering both 'static' and 'dynamic' notions of agreement. I would
be hopeful that most binding related properties are 'static' within a given
binding and are the sort of thing that become implicitly encoded in any
implementation of that binding rather than being operational parameters that
needed to be explicitlt accessible or that are subject to negotiation. 

> Examples of
> such properties include message exchange pattern used, message role,
> quality of service supported, protocol used, means of correlation,
> application end point, transport end point, message encoding and
> fault/error definition. 

The property items in this list seem split between properties that you might
think of a 'binding global' and those that more part of the context of a
given messaging event. eg.

"Binding Global"
	Supported MEP's
	Supported QoS's
	Supported Corelation Methods

"Messaging Context"
	MEP in use
	Message Role (ie phase within MEP?)
	Application Endpoint (from/to)
	Transport Endpoint (from/to)

> Each of these properties has associated data
> elements which may be defined in several ways:
                        ^^^^^^^
> 
> 
> 1) within the underlying protocol

Hmmm... In terms of definition this feels awkward. HTTP certainly defines a
request/response MEP, however if we want to name that
(eg.urn:soap-transport-mep:request-reponse), I don't think that the HTTP
spec to do that for us or to describe what
urn:soap-transport-mep:request-response denotes.

The discussion here might really be about how these various properties are
manifest rather than how they are defined, eg. in the case of HTTP and the
MEP denote by "urn:soap-transport-mep:request-response" this MEP is manifest
as the natural MEP provided by HTTP. In the case of SMTP, this MEP is
manifest by...[some decription that descibes how requests are wrapped in
SMTP and delivered by SMTP are recognised as responses and matched with
corresponding requests].

> 
> 
> 2) within the underlying protocol's extensibility mechanism
> 
> 
> 3) within the SOAP envelope using the SOAP extensibility mechanism

I think that there is maybe a 4th place where these properties may be
manifest, within whatever 'adaption' mechanism one might have for 'fitting'
the SOAP messaging paradigm with the underlying protocol. This is very
similar to 3, expect one is creating something of a 'shim' that uses the
underlying protocol as is, but provides for example message framing and
perhaps message numbering/ids say on stream orient protocol like TCP.

> 
> 
> Note that it is not a requirement for a particular binding to support all
> properties. Properties can be left undefined for a given named binding and
> the binding specification would not reference that property in any way
> shape or form. Some properties are likely to be supported by 
> most bindings (the core properties concept).
> 
> 
> The Set of Properties, referenced above, is intended to indicate the
> open-ended set of properties used to describe message exchange in SOAP
> based protocols. Of these properties, there are some 
> properties that are expected to be specified by most bindings. It is
strongly 
> recommended that a binding considers how these core properties may be
supported.
> 
> 
> Specifications for particular bindings and message exchange patterns can 
> require additional such properties and can provide additionally for
> properties that are optional. This specification does not define any
formal
> framework for defining new properties.

This last sentence concerns me a little. I envisage this 'property space' as
some sort of abstract structure within which we can name properties and
express the value constraints (if any) on the values those properties can
take on. I also envisage some kind of partitioning of this space such that
there are forks for: 'core' properties; properties of utility to multiple
bindings; properties specific to a particular class of bind. I think that we
ought to provide some sense of organisation on this space and offer some
guidance on the naming of parameters to avoid collisions within this
'property space'.

I also think it worthwhile separating out those properties that are 'binding
(instance) global' from those that are 'per message (event)'.

> 
> 
> Placement of property related information is at the discretion of the
Named
> Binding Author and Named Binding Customer. A Named Binding could include
> flexibility as to where property information is placed over the wire for a
> given property. One property could be defined as data in the protocol
> header and in the SOAP envelope. It would be up to the Binding user to
> implement in a way best suited to his or her application.

This also leaves me a little uncomfortable. I guess that I think of there
being a message and message metadata. At a sender this latter is information
necessary to accomplish the sending of the message and at a receiver it is
information about the message that has been received. I don't think that a
receiver should expect to have access to the senders message metadata. If it
becomes necessary to explicitly carry message metadata with the message
there is a sense in which it becomes part of the message and ceases to be
metadata. So, IMO, the senders and receivers message metadata are distinct
datasets. It is quite likely that some fields of the receivers metadata
reflect fields in the senders metadata, but in general that arises through
inference rather than through explicit communication.

> 
> SOAP Envelope - This could contain Transport Binding related blocks, as
> defined in the Named Binding.

I take this to mean that the transport binding could insert (and presumably
remove) blocks into the SOAP envelop as a way of explicitly communicating
property information, rather than meaning that an application in some sense
set all this up for transport.

> 
> 
> Transport, e.g. HTTP - Transport Protocol header content may 
> be derived from the Named Binding definition.
> 
> 
> On the wire representation - The Named Binding can specify information
> included in the protocol header and in the SOAP envelop. The sending SOAP
> node will be directed by the Named Binding to create the appropriate "on
> the wire" representation of this bound message.
> 
> 
>  <<bindingstack.ZIP>> 
> 
> 2) Sender "Mandatory" or Core Properties (see Issue Appendix #1 below)
> (in this case a Binding supporting the Request Response MEP ) 
> 
> Property named "SOAP.MEP" : value is an enumeration over { strings, URIs }
> 	Property named "RequestResponse.MsgRole" value is { request,
response }
> 	Property named "RequestResponse.NodeRole" value is { sender,
receiver }
> 
> Property named "?.destination" : opaque URI
> 	This URI is presumed to be sufficient (either through some kind of
> directory lookup
> 	which ties the resource to a particular binding, or by 
> encoding the information into
> 	the URI itself) to 
> 	a) determine the binding in use
> 	b) determine the binding-specific actual endpoint address.
> 
> Property named "SOAP.Envelope" : XML (soap envelope) (see 
> Issue Appendix #2 and 3 below)
> 
> Information in the property bag will in general be modeled as XML header
> entries and bodies, primarily in those situations where the application 
> expects it to be reproduced after transmission in that form, in other 
> cases the information should be modeled abstractly in terms of 
> intention rather than syntax.

Can you give an example of something "modeled abstractly in terms of
intention."? I'd like to get a picture of what that would be like.

> 
> An envelop template can be used to model such properties being represented
> in the SOAP envelope.  

I think that this section has covered mostly per message (event) properties.
It seems to capture the SOAP Envelope, headers and bodies. I think
attachments also ought to be hooked in here (abstractly).

> 
> 3) Sending Processor States/Behaviors
> 
> The Sending Processor will attempt to access the ?.Destination URI.  
> 
> A fault may be passed back by the processor due to the following reasons:
> a) URI not recognized
> b) URI was an unsupported binding
> c) URI did not support the MEP specified
> d) URI can not be reached
>
> Processor success will result in the message being wire encoded per the
> binding specification.  Success will also result in the properties "we"
care
> about being reconstructed at the receiver.

Who us "we"?

> 
> 4) Receiver States/Behavior
> (in this case a Binding supporting the Request Response MEP ) 
> 
> An event has occurred where a binding specified message has been received.
> In fully reassembling the envelope, the receiver needs to:
> 
> a) Determine the complete message content per the given binding
> specification (message fragments need to be reassembled, etc)
> b) Verify message role (RequestResponse.MsgRole) is a "request" and set
the
> value of RequestResponse.NodeRole to "receiver"
> c) Establish Property ResponseCookie per binding specification(correlation
> mechanism bound by specified binding? see Issue Appendix #4 below)
> d) Reconstruct Envelope (how will extensions be used, etc)
> 
> 5) Binding Instances
> 
> a) HTTP
> b) SMTP
> c) Intermediary Behavior
> 
> 
> 6) Issue Appendix:
> 
> ISSUE 1: What is the structure of property names?  URIs, short names, etc?
> This structure needs to be defined early.

The 'property space' needs to be open and extensible. I think it would be
useful to partition the space so that each class of binding can add its own
class specific properties and so that common properties can be shared by
multiple classes of binding eg. <Realm, UserID, Password> (which are more
per-message operation properties) could be used by end any binding that
supports a basic authentication scheme, likewise with something like
<PubKeyRef, CertRef> for bindings that do hop-by-hop
encryption/authenication.

One could imagine an XML instance document describing an instance of a
binding. One could imagine a top-level schema for such a document that lays
out the top level structure (cf. the SOAP enevlope schema) and where each
binding class defines a schema for some sub-structure root at some point
within the structure. Likewise, property sets that may be of use to multiple
bindings could also define schema for other parts of the sub-structure
(don't know schema weel enough to know how plausible this really is.

Bear in mind that these instance documents and their associated framework
may only be part of a descriptive framework. Their ought to be no need to
consume and process such documents in an operational system -  some may
choose to do so if we do a good job and some plugable infrstructure arises,
but I don't think it would be a conformance requirement that an
implementation be capable of processing instance docs of this form.

> ISSUE 2: Should the app provide a "template" envelope which potentially
gets
> modified by pieces of the SOAP system (extensions,bindings), or a more
> abstract set of stuff which gets built into an actual SOAP envelope only
at
> a very late stage in the processing (typically right before engaging the
> wire).

I think that this is entirely an implementation issue rather than a spec.
issue.

> 
> ISSUE 3: If the application is handing down pieces of XML into the
"engine",
> we need to deal with potential conflicts with prefixes/ids/etc.  - this
can
> get hairy.  We need to decide how much latitude the app has over this
stuff.
> This arises at least for headers + bodies, and is a potential problem
> regardless of whether the app hands a "complete" (to some degree) envelope
> to the SOAP processor or just fragments.

Again I think this is largely an implementation issue. I think that if we
allow bindings to do things inside the envelope I think our overriding
concern is that those things should be transparent, ie. they should
certainly not 'break' the envelope or its content, and IMO they are probably
removed before the envelope (message) is delivered to the local node because
they are not part of the message, they are part of the means to communicate
the message.
> 
> ISSUE 4: No firm resolution to correlation/extensions, more discussion is
> needed. Correlation and the utility/wisdom of expressing a canonical XML
> serialization + rules for a generic req/resp extension as opposed to just
> leaving this up to the binding. 
> 
> End of First
> Cut===========================================================
> 
> 
> Highland Mary Mountain
> 
> Intel Corporation
> eBusiness Solutions Lab
> (480) 552 - 3817
> 
> highland.m.mountain@intel.com
> 
> 
> 

attached mail follows:



Rather than having the notion of coming to agreement on which features
should be present in the communication be part of the binding I would
much rather see this pushed up and into a service description/behavior
mechanism which seems to me to be at a much higher level.

>> Set of Properties - Exchanging information between two or more peers 
>> often involve agreeing on a set of properties that characterize a 
>> message exchange and context in which the exchange is taking place.
>
>Are we considering both 'static' and 'dynamic' notions of 
>agreement. I would be hopeful that most binding related 
>properties are 'static' within a given binding and are the 
>sort of thing that become implicitly encoded in any 
>implementation of that binding rather than being operational 
>parameters that needed to be explicitlt accessible or that are 
>subject to negotiation. 

Henrik

attached mail follows:


Here is the corrected version for dist-app.

>  -----Original Message-----
> From: 	Mountain, Highland M  
> Sent:	Friday, August 10, 2001 2:04 PM
> To:	'David Fallside'; 'gdaniels@macromedia.com'; 'skw@hplb.hpl.hp.com';
> 'Noah Mendelsohn'; 'frystyk@microsoft.com'; 'jones@research.att.com';
> 'marc.hadley@Sun.COM'; 'Chris.Ferris@Sun.COM'; 'ylafon@w3.org'
> Cc:	'hugo@w3.org'; 'ylafon@w3.org'; 'ohurley@iona.com'; 'Alan Kropp';
> 'mnot@akamai.com'
> Subject:	TBTF: Binding First Cut for Review 8/13
> 
> All, 
> 
>  Glen, Noah and I met Thursday to create the  "First Cut" Binding
> specification.  This "First Cut" is meant to convey the general direction
> of the spec for TF feedback/approval.  We will review this at the Monday,
> August 13th con call.      
> 
> Specification Outline:
> 1) Architectural Definition of a Binding
> 2) Sender "Mandatory" or Core Properties (Request/Response MEP example) 
> 3) Sending Processor States/Behaviors
> 4) Receiver States/Behaviors (Request/Response MEP example) 
> 5) Binding Instances ( to be developed )
> 6) Issues Appendix
> 
> Next Steps from the 8/9 meeting:
> 
> 1) Review with task force 
> 2) Address Issues
> 3) MEP Prose/Structure
> 4) Specific protocol instances and develop intermediary scenarios
> 
> 
> Glen - Thanks for sending me your minutes.  
> Noah and Glen - If I have misinterpreted any part of our discussion,
> please let us know.
> 
> 
> Thanks, Highland
> 
> Start of First
> Cut====================================================================
> 
> 
> 1) Architectural Definition of a Binding
> 
> Architectural Description (as discussed at the FtF):
> 
> The information needed to send a message and the information available
> when
> receiving a message is modeled abstractly as a set of named properties,
> some of which may be represented as standard XML infoset entries.
> 
> 
> Application - A SOAP node can bind to an underlying protocol for the
> purpose of sending or receiving a SOAP message.
> 
> 
> Set of Properties - Exchanging information between two or more peers often
> involve agreeing on a set of properties that characterize a message
> exchange and context in which the exchange is taking place. Examples of
> such properties include message exchange pattern used, message role,
> quality of service supported, protocol used, means of correlation,
> application end point, transport end point, message encoding and
> fault/error definition. Each of these properties has associated data
> elements which may be defined in several ways:
> 
> 
> 1) within the underlying protocol
> 
> 2) within the SOAP envelope using the SOAP extensibility mechanism
> 
> 
> Note that it is not a requirement for a particular binding to support all
> properties. Properties can be left undefined for a given named binding and
> the binding specification would not reference that property in any way
> shape or form. Some properties are likely to be supported by most bindings
> (the core properties concept).
> 
> 
> The Set of Properties, referenced above, is intended to indicate the
> open-ended set of properties used to describe message exchange in SOAP
> based protocols. Of these properties, there are some properties that are
> expected to be specified by most bindings. It is strongly recommended that
> a binding considers how these core properties may be supported.
> 
> 
> Specifications for particular bindings and message exchange patterns can
> require additional such properties and can provide additionally for
> properties that are optional. This specification does not define any
> formal
> framework for defining new properties.
> 
> 
> Placement of property related information is at the discretion of the
> Named
> Binding Author and Named Binding Customer. A Named Binding could include
> flexibility as to where property information is placed over the wire for a
> given property. One property could be defined as data in the protocol
> header and in the SOAP envelope. It would be up to the Binding user to
> implement in a way best suited to his or her application.
> 
> 
> SOAP Envelope - This could contain Transport Binding related blocks, as
> defined in the Named Binding.
> 
> 
> Transport, e.g. HTTP - Transport Protocol header content may be derived
> from the Named Binding definition.
> 
> 
> On the wire representation - The Named Binding can specify information
> included in the protocol header and in the SOAP envelop. The sending SOAP
> node will be directed by the Named Binding to create the appropriate "on
> the wire" representation of this bound message.
> 
> 
>  <<bindingstack.pdf>> 
> 
> 2) Sender "Mandatory" or Core Properties (see Issue Appendix #1 below)
> (in this case a Binding supporting the Request Response MEP ) 
> 
> Property named "SOAP.MEP" : value is an enumeration over { strings, URIs }
> 	Property named "RequestResponse.MsgRole" value is { request,
> response }
> 	Property named "RequestResponse.NodeRole" value is { sender,
> receiver }
> 
> Property named "?.destination" : opaque URI
> 	This URI is presumed to be sufficient (either through some kind of
> directory lookup
> 	which ties the resource to a particular binding, or by encoding the
> information into
> 	the URI itself) to 
> 	a) determine the binding in use
> 	b) determine the binding-specific actual endpoint address.
> 
> Property named "SOAP.Envelope" : XML (soap envelope) (see Issue Appendix
> #2 and 3 below)
> 
> Information in the property bag will in general be modeled as XML header
> entries
> and bodies, primarily in those situations where the application expects it
> to be reproduced after transmission in that form, in other cases the
> information should be modeled abstractly in terms of intention rather than
> syntax.
> 
> An envelop template can be used to model such properties being represented
> in the SOAP envelope.  
> 
> 3) Sending Processor States/Behaviors
> 
> The Sending Processor will attempt to access the ?.Destination URI.  
> 
> A fault may be passed back by the processor due to the following reasons:
> a) URI not recognized
> b) URI was an unsupported binding
> c) URI did not support the MEP specified
> d) URI can not be reached
> 
> Processor success will result in the message being wire encoded per the
> binding specification.  Success will also result in the properties "we"
> care about being 
> reconstructed at the receiver.
> 
> 4) Receiver States/Behavior
> (in this case a Binding supporting the Request Response MEP ) 
> 
> An event has occurred where a binding specified message has been received.
> In fully reassembling the envelope, the receiver needs to:
> 
> a) Determine the complete message content per the given binding
> specification (message fragments need to be reassembled, etc)
> b) Verify message role (RequestResponse.MsgRole) is a "request" and set
> the value of RequestResponse.NodeRole to "receiver"
> c) Establish Property ResponseCookie per binding specification(correlation
> mechanism bound by specified binding? see Issue Appendix #4 below)
> d) Reconstruct Envelope (how will extensions be used, etc)
> 
> 5) Binding Instances
> 
> a) HTTP
> b) SMTP
> c) Intermediary Behavior
> 
> 
> 6) Issue Appendix:
> 
> ISSUE 1: What is the structure of property names?  URIs, short names, etc?
> This structure needs to be defined early.
> 
> ISSUE 2: Should the app provide a "template" envelope which potentially
> gets modified by pieces of the SOAP system (extensions,bindings), or a
> more abstract set of stuff which gets built into an actual SOAP envelope
> only at a very late stage in the processing (typically right before
> engaging the wire).
> 
> ISSUE 3: If the application is handing down pieces of XML into the
> "engine", we need to deal with potential conflicts with prefixes/ids/etc.
> - this can get hairy.  We need to decide how much latitude the app has
> over this stuff.  This arises at least for headers + bodies, and is a
> potential problem regardless of whether the app hands a "complete" (to
> some degree) envelope to the SOAP processor or just fragments.
> 
> ISSUE 4: No firm resolution to correlation/extensions, more discussion is
> needed. Correlation and the utility/wisdom of expressing a canonical XML
> serialization + rules for a generic req/resp extension as opposed to just
> leaving this up to the binding. 
> 
> End of First
> Cut====================================================================
> 
> 
> 
> Highland Mary Mountain
> 
> Intel Corporation
> eBusiness Solutions Lab
> (480) 552 - 3817
> 
> highland.m.mountain@intel.com
> 
> 



Received on Monday, 13 August 2001 12:29:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:03 GMT