Re: [ebxml-msg] syncReply follow-up

[Jeff Turpin <jturpin@cyclonecommerce.com>]

Title: Re: [ebxml-msg] syncReply follow-up

I agree that we need a header element of some kind to indicate whether a synchronous business reply is expected. <ResponsePattern> seems fine and makes sense to me. As for Errors, we need to decide what we want to do for MSH level errors. If possible I would like to avoid having three different header elements indicating what response pattern to use (Reliablilty, Errors, Business Response). Perhaps we can discuss this on tomorrows call. Cheers!


Jeff Turpin



On 2/5/05 9:16 PM, "Jacques Durand" <JDurand@us.fujitsu.com> wrote:

> 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. 
>
> Proposal: 
>
> 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. 
>
> Something like: 
>
> <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.
>
> Jacques