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