A transport message exchange pattern is a template for the exchange of messages between SOAP Nodes supported by one or more transport binding instances.
In general the definition of a transport message exchange pattern:
Transport binding specifications may declare their support for one or more named transport message exchange patterns.
Transport message exchange patterns are named by URI.
A transport message exchange has a lifecycle governed by a transport message exchange pattern.
The following table describes the particular property definitions (in accordance with the property naming conventions defined in this document) which support the description of Transport Message Exchange Patterns. Other properties may also be involved in the specification for particular TMEPs, but these are generally applicable to all TMEPs.
| Property Name | Property Decription |
| transport:ExchangePatternName | A URI that names the transport message exchange pattern in operation. |
| single:Role | A URI that names the pattern specific role of the local SOAP Node with respect to the transport message exchange denoted by the enclosing property container. |
| single:State | A relative URI relative with a Base value carried in the PatternSpecificRole property which denotes the current state of the transport message exchange denoted by the enclosing property container. This value is managed by the binding instance and may be inspected by other entities monitoring the progress of the message exchange. |
| transport:FailureReason | A URI value that denotes a pattern specific, binding independent reason for the failure of a message exchange. Transport binding specifications may define properties to convey more binding specific details of the failure. |
| transport:CurrentMessage | An abstract structure that represents the current message in a message exchange. This abstracts both SOAP Envelope and any other information structures that are transferred along with the envelope due to the action of the message exchange. Depending on pattern dependent state this may be an inbound or outbound message. |
| transport:ImmediateDestination | A URI denoting the immediate destination of an outbound message. |
| transport:ImmediateSender | A URI denoting the immediate sender of an inbound message. |
[Ed. Note: The use of single here is to capture the notion that this there is to be no implied timing relationship between contemporaneous exchanges conforming to this transport exchange pattern, ie. nothing can be said about the relative temporal ordering of the transmission and reception of messages arising from distinct exchanges. Might rename Independent-Request-Response. Single could be misinterpreted as just 1 response or a unicast pattern (both of which happen to be the case but are not the motivation for the prefix)]
This message exchange pattern is named by the URI
http://www.w3.org/2001/09/soap/transport-mep/single-request-response/ abbreviated to single-request-response throughout this document.
Transport binding specifications may use the full-name of this transport message exchange pattern to declare their support for the transport message exchange pattern and associated semantics described herein.
The following are standard prefix mappings which we assume to hold throughout this section.
| Prefix | Namespace |
| transport | http://www.w3.org/2001/09/soap/bindingFramework/TransportExchangeContext/ |
| mep | http://www.w3.org/2001/09/soap/transport-mep/ |
| fail | http://www.w3.org/2001/09/soap/transport-mep/FailureReasons/ |
| single | http://www.w3.org/2001/09/soap/transport-mep/single-request-response/ |
The single-request-response transport message exchange pattern defines a pattern for the exchange of two messages between two adjacent SOAP nodes along a SOAP Message Path. One message is exchanged in each direction between a Requesting SOAP Node and a Responding SOAP Node.
The normal operation of a message exchange conforming to the single-request-response exchange pattern is such that a Request Message is first transferred from Requesting SOAP Node to Responding SOAP Node. Following the successful processing of the Request Message by the Responding SOAP Node, a Response Message is then transferred from Responding SOAP Node to Requesting SOAP Node.
Abnormal operation of a message exchange conforming to the single-request-response exchange pattern may arise due to a failure to transfer the Request Message, a failure at the Responding SOAP Node to process the Request Message, or a failure to transfer the Response Message. Such failures MAY be silent at requesting, responding or both SOAP Node involved in the exchange. Also, under abnormal operation each SOAP Node involved in the message exchange MAY differ in their determination of the successful completion of the message exchange.
[Ed.Note This is intended as a logical description of the operation of this MEP. It is not intended to describe a real implementation or to imply that a real implementation should be structured.]
To initiate an transport message exchange conforming to the single-request-response transport message exchange pattern, the Requesting SOAP Node instantiates a local transport message exchange context. This context is initialised as follows:
| Property Name URI | Value |
| transport:ExchangePatternName | http://www.w3.org/2001/09/soap/transport-mep/single-request-response/ |
| single:Role | RequestingSOAPNode |
| single:State | Requesting |
| transport:FailureReason | None |
| transport:CurrentMessage | An abstraction of the Request Message |
| transport:ImmediateDestination | An identifier (URI) that denotes the Responding SOAP Node |
In addition other properties related to the operation of features to be used in conjunction with this particular instance of the transport message exchange are initialised in accordance with the relevant feature specification.
Once initialised control of the transport message exchange context is passed to a (conforming) local binding instance.
The diagram below shows the logical state transitions at requesting and responding SOAP Nodes during the lifetime of the message exchange. At each SOAP Node the value of the single:State property is updated (logically) to reflect the current state of the message exchange as perceived by the local binding instance. These state names are relative URIs, relative to a Base URI value carried in the single:Role property of the local transport message exchange context.
At the Responding SOAP Node a transport message exchange context is (logically) instantiated by the local binding instance when it starts to receive an inbound Request Message.
| Property Name | Value |
| transport:ExchangePatternName | http://www.w3.org/2001/09/soap/transport-mep/single-request-response/ Initialised as early as possible during the lifecycle of the message exchange. |
| single:Role | RespondingSOAPNode Initialised as early as possible during the lifecycle the message exchange. |
| single:State | Receiving |
| transport:FailureReason | None |
| transport:CurrentMessage | NULL |
| transport:ImmediateSource | An identifier (URI) that denotes the Requesting SOAP Node (if available) |
[Ed Node: The initial value for single:State feels a bit awkward. generally when a Message start to be received the transport-mep in operation may not be known in which case the intial receiving state cannot be scoped by mep name or node role with respect to the exchange.]
[Ed.Note Incomplete tables for illustrative purposes]
| CurrentState | Input | NextState | Action |
| Requesting | Fail | Set transport:FailureReason to TransmissionFailure | |
| Waiting | |||
| Waiting | Fail | Set transport:FailureReason to NoResponse | |
| Receiving | |||
| Receiving | Fail | Set transport:FailureReason to ReceptionFailure | |
| Success | Set transport:ImmediateSender to denote the sender of
the Response Message (may differ from the value in transport:ImmediateDestination) Replace transport:CurrentMessage with abstraction of Response Message |
Requesting SOAP Node State Transition Table
| CurrentState | Input | NextState | Action |
| Receiving | Fail | Set transport:FailureReason to ReceptionFailure | |
| Processing | Set transport:ImmediateSender
to denote the sender of the Request Message (if
determinable) Set transport:CurrentMessage with abstraction representing Request Message Pass control of transport message exchange context to SOAP Processor. | ||
| Processing | Fail | Set transport:FailureReason to NoResponse; | |
| Responding | SOAP Processor has replaced transport:CurrentMessage with an abstraction of the
Response Message.; Initiate transmission of Response Message. | ||
| Responding | Fail | Set transport:FailureReason to TransmissionFailure | |
| Success |
Responding SOAP Node State Transition Table
During the operation of the single-request-response transport message exchange pattern, the participating SOAP Nodes may generate SOAP Faults.
If a SOAP Fault is generated during the processing of a Request Message then relaying of that message toward ultimate Responding SOAP Node should be terminated and the generated SOAP Fault should be propagated toward the initial Requesting SOAP Node in place of the Response Message.
If a SOAP Fault is generated during the processing of a Response Message then the generated SOAP Fault should be propagated toward the initial Requesting SOAP Node in place of the Response Message.
[skw] This may be overly prescriptive, but it seems like a good starting point. Extensions like SOAP-RP and ebXML may modify Fault Handling behaviour.
[gd] Do we want this section in the current WD, or should we just note that it's an issue?
The single-request-response transport message exchange pattern can be extended over multiple transport binding hops to form an extended single-request-response transport message exchange with a SOAP message path that extends through multiple SOAP intermediaries.
By default, Response Message follow the same set of hops between SOAP Nodes as the Request Message, but in reverse order. Specific SOAP extensions (eg. SOAP-RP) may modify this default behaviour.
A Request Message received by a SOAP Intermediary may be processed and forwarded toward an ultimate Responding SOAP Node. By default, a Response Message SHOULD NOT be returned toward the initial Requesting SOAP Node until a Response Message has been received (and possibly processed) at the SOAP Intermediary.
A failure by a SOAP Intermediary to forward a Request Message or to receive a Response Message MAY result in the generation of a SOAP Fault at the SOAP Intermediary.
TBD