W3C home > Mailing lists > Public > www-ws-arch@w3.org > July 2002

[hst] SOAP architecture harvest (repost)

From: <jones@research.att.com>
Date: Fri, 12 Jul 2002 09:18:36 -0400 (EDT)
Message-Id: <200207121318.JAA02705@bual.research.att.com>
To: www-ws-arch@w3.org

[this is a repost to the public list of a message sent earlier
to the member list]

- - - - - 

This is a summary of the harvesting exercise on the architectural
aspects of SOAP for the Web Services Architecture Working Group.
I've tried to determine all of the ways in which the SOAP
specification interacts with other components, formats, etc.
The summary reflects only SOAP Version 1.2 Part 1: Message Framework.
(Conformant SOAP implementations must implement everything in Part 1;
they may implement anything in Part 2 if they conform to the relevant
parts of the specification.)

Under each subheading, items are listed with a spec URL paired with
brief descriptions or quotations from the spec.

Mark Jones

General Note: There are broad dependencies throughout the SOAP
specification on the basic web and XML standards (URIs, XML 1.0,
namespaces, schema).  In particular, section 6 of part 1
details the use of URIs in SOAP.

Media types, namespaces and schema
 application/soap+xml media type

 namespace http://www.w3.org/2002/06/soap-envelope and
 schema http://www.w3.org/2002/06/soap-faults

 namespace http://www.w3.org/2002/06/soap-faults and
 schema http://www.w3.org/2002/06/soap-faults

 namespace http://www.w3.org/2002/06/soap-upgrade and
 schema http://www.w3.org/2002/06/soap-upgrade

 namespace http://www.w3.org/2002/06/soap-encoding

 The SOAP envelope has the namespace name

 The SOAP Misunderstood element information item has the namespace
 name "http://www.w3.org/2002/06/soap-faults"

 The SOAP Upgrade element information item has the namespace name

Processing model
 SOAP provides a distributed processing model that assumes a
 SOAP message originates at an initial SOAP sender and is sent to
 an ultimate SOAP receiver via zero or more SOAP intermediaries.

 A SOAP node can be the initial SOAP sender, an ultimate SOAP
 receiver, or a SOAP intermediary.  A SOAP node receiving a SOAP
 message MUST perform processing according to the SOAP processing

 In processing a SOAP message, a SOAP node is said to act in one or more
 SOAP roles, each of which is identified by a URI known as the SOAP
 role name.

 This specification defines the following SOAP roles:

 A SOAP header block MAY carry a role attribute information item that
 is used to target the header block at SOAP nodes operating in the
 specified role.

 A SOAP header block is said to be understood by a SOAP node if the
 software at that SOAP node has been written to fully conform to and
 implement the semantics conveyed by the combination of local name and
 namespace name of the outer-most element information item of that
 header block.

 ... for every mandatory SOAP header block targeted to a node, that
 node MUST either process the header block or not process the SOAP
 message at all, and instead generate a fault

 An ultimate SOAP receiver MUST correctly process the immediate
 children of the SOAP body

 Rules for SOAP processing and the kinds of faults that must be

 A SOAP Version 1.2 message has a child <em>element information item
 of the document information item with a local name of Envelope and a
 namespace name of "http://www.w3.org/2002/06/soap-envelope".

 If a SOAP node receives a message whose version is not supported it
 MUST generate a fault with a Value of Code set to
 "env:VersionMismatch". Any other malformation of the message
 construct MUST result in the generation of a fault with a
 Value of Code set to "env:Sender".

SOAP extensibility model
 The specification of a feature MUST include ... (several
 constraints on nodes follow).

 A SOAP module MUST identify itself with a URI.

 MUST clearly and completely specify the content and semantics of the
 header blocks used to implement the behavior in question, including
 if appropriate any modifications to the SOAP Processing model.

 A SOAP Message Exchange Pattern (MEP) is named by a URI.

SOAP protocol binding framework
 The SOAP Protocol Binding Framework provides general rules for the
 specification of protocol bindings; the framework also describes the
 relationship between bindings and SOAP nodes that implement those

  The creation, transmission, and processing of a SOAP message,
  possibly through one or more intermediaries, is specified in terms
  of a distributed state machine.

  ... each SOAP message is modeled as an XML Infoset ...
  ... the XML Infoset of a SOAP message MUST NOT include a DTD ...
  Bindings MAY provide for streaming when processing messages.
  Bindings MAY depend on state that is modeled as being outside
    of the SOAP XML Infoset.
Received on Friday, 12 July 2002 09:19:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:01 GMT