Rough Draft of Proposed Rewording
For SOAP Section 2.0
Noah Mendelsohn
June 6, 2001
SOAP messages are fundamentally one-way transmissions from a sender to a receiver, but as illustrated above, SOAP messages are often combined to implement patterns such as request/response.
SOAP implementations can be optimized to exploit the unique characteristics of particular network systems. For example, the HTTP binding described in section 6 provides for SOAP response messages to be delivered as HTTP responses, using the same connection as the inbound request.
Node is the term applied to software responsible for the processing of an inbound SOAP message. A node receiving a message MUST perform processing, generate faults, responses, and if appropriate send additional messages, as provided by the remainder of this specification. Regardless of the protocol to which XMLP/SOAP is bound, messages are routed along a so-called "message path", which allows for processing at one or more intermediate nodes in addition to the ultimate destination.
In processing a message, a node is said to act in the role of one or more Actors, each of which is identified by a URI known as the Actor name. Each node MUST act in the role of the special actor named http://schemas.xmlsoap.org/soap/actor/next; and can additionally assume the roles of zero or more other actors. A node can establish itself as the distinguished end point for the message path by acting in the (additional) role of the anonymous actor. The roles assumed must be invariant during the processing of an individual message; because this specification deals only with the processing of individual messages, no statement is made regarding the possibility that a given piece of software might or might not act in varying roles when processing more than one message.
Actors MAY but need not be named with a URI useable to route SOAP messages to an appropriate processing node. Conversely, it is also appropriate to use actor roles with names that are related more indirectly to message routing (e.g. http://example.org/banking/anyaccountmgr) or which are unrelated to routing (e.g. a URI meant to identify "all cache management software"; such a header might be used, for example, to carry an indication to any concern software that the containing message is idempotent, and can safely be cached and replayed.)
Header entries carry optional SOAP-ENV:Actor attributes which are used to target headers to the appropriate processing nodes; headers with no SOAP-ENV:Actor and the SOAP-ENV:BODY element are implicitly targeted to the anonymous actor, implying that they are to be processed by the end point node. We refer to the value of the Actor attribute as the actor for the entry.
We say that a header entry or body is targeted to a node if the actor (if any) on the entry matches a role played by the node, or in the case of the body or headers with no actor attributes, if the node has assumed the role of the anonymous actor.
We presume that specifications for a wide variety of header functions will be developed over time, and that each node MAY include the software necessary to implement one or more such extensions. We say that a header entry is understood by a node if the software at that node has been written to fully conform to and fully implement the specification for the function employed in that entry (question: should we specifically state that such determination must be made purely based on the entry QNAME, or should we leave it flexible?)
Processing messages
This section sets out the rules by which messages are processed. Unless otherwise stated, processing must be semantically equivalent to performing the following steps separately, and in the order given. Note however that nothing in this specification should be taken to prevent the use of optimistic concurrency, roll back, or other techniques that might provide increased flexibility in processing order as long as all messages, faults and application-level side effects are equivalent to those that would be obtained by direct implementation of the following rules. In the following, the term "header entry" applies also to the SOAP body element.
If the node is an intermediary, the message pattern and results of processing (e.g. no faults generated) MAY require that the message be sent further along the message path. Such relayed messages MUST contain all header entries and the body from the original message, in the original order, except that header entries targeted to the relaying node MUST be removed (such entries are removed regardless of whether they were processed or ignored.) Additional header entries MAY be inserted at any point in the message, and such inserted entries MAY be indistinguishable from one or more just removed (effectively leaving them in place...but emphasizing the need to reinterpret at each target.)