[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: syncReply follow-up
Follow-up on f2f "syncReply" discussion:
It appears we need something playing the role of previously SyncReply,
so that when a message is pushed to a receiving MSH, the latter knows whether it should
wait for a "response" to be returned on the same SOAP MEP instance or not.
Don't reuse SyncReply for the following reasons:
- terminology: the term "Reply" is already used in WS-Rel, where the synchronous aspect of Acks
is driven by something else (replypattern). And "synchronized" is an ambiguous term, too close to protocol binding.
SOAP MEPs do not talk of sync vs async. SOAP MEPs is really the right level of abstraction we need:
whether a response goes over a SOAP request-response MEP or a SOAP One-way MEP.
WS-Reliability avoided to use the term "synchronized" (except for the Poll signal and in HTTP binding)
- design: syncReply was controlling every case of [synchronous] response in ebMS2: MSH signals, receipts,
business responses, and all combinations.
Here, it is likely that each "type" of response (faults, errors, acks, bus responses) will specify its own
reply pattern in a different header element.
Reliability functions already have their own way (reply pattern). Errors should probably have their own
"pattern specification" element, like <ErrorPattern><value>...</value></ErrorPattern>
(I dont think we have the option of just using the WS-A header wsa:FaultTo as probably not all ebms errors are SOAP Faults, yet we'll have also SOAP Faults, so they will probably also be separately governed by wsa headers)
The response pattern for business responses should then be specified in its own element, and only distinguish
which SOAP MEP is to be used for the response.
<ResponsePattern soapmep="same"/> (for using the Response leg of this SOAP MEP
to carry the ebms business response to this message. Would be equivalent to SyncReply element)
<ResponsePattern soapmep="other"/> (for an "async" Response on another SOAP MEP instance. Default attribute value.)
Note that the PullRequest message does not need to specify this, as the response mode is entirely determined by this MEP.