[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 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.
The operation of the single-request-response transport message exchange pattern is formally described by describing the set of traces of high level events that arise on the 'wire' during the operation of the message exchange pattern.
Alphabet = { SOReq, //Start of Request Message (on the 'wire')
EOReq, //End of Request Message
SOResp, //Start of Response Message
EOResp, //End of Response Message
fail //Transmission or reception failure.
}
Given this alphabet of events the operation of a single-request-response message exchange is described by the following process:
srr-exchange = SOReq.( EOReq.(SOResp.(EOResp | fail) | fail)
| SOResp.( EOReq.(EOResp | fail)
| EOResp.(EOReq | fail)
| fail) )
| fail ).stop
[Notation: '.' means followed by '|' means choice (CSS/CSP like).]
Expansion of this process expression yields the following set of traces which fully characterise the operation of the single-request-response message exchange pattern:
srr-traces = { [SOReq.fail.stop],
[SOReq.EOReq.fail.stop],
[SOReq.EOReq.SOResp.fail.stop],
[SOReq.EOReq.SOResp.EOResp.stop], //Success
[SOReq.SOResp.fail.stop]
[SOReq.SOResp.EOReq.fail.stop]
[SOReq.SOResp.EOReq.EOResp.stop] //Success
[SOReq.SOResp.EOResp.fail.stop]
[SOReq.SOResp.EOResp.EOReq.stop] //Success
}
[skw] This is a different formalism than using a state-machines whose evolution produces these traces - it seems to yield a compact declarative expression of the operation of this mep. Certainly more compact than the previous state machine description.
This process and trace description can be specialised to describe the behaviour of the exchange pattern at the Requesting and Responding SOAP Nodes. At the Requesting SOAP Node, SOReq and EOReq denote the start and end of transmission of the Request Message, while SOResp and EOResp denote the start and end of reception of the Response Message. Conversely, at the Responding SOAP Node, SOReq and EOReq denote that start and end of reception of the Request Message, while SOResp and EOResp denote the start and end of transmission of the Response Message.
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:
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.
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.
[skw] Need to do some work to formulate combined message traces either side of a SOAP Intermediary