RE: [ebxml-msg] syncReply follow-up

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

Here are some 
decisions that need be made regarding Errors:

 

- SOAP faults 
vs ebMS headers

- Should the 
MSH provide the same flexibility as WS-R layer when reporting on 
errors

(can we batch 
them? In some cases, errors should not be returned on a sync response, if WS-I 
BP compliance is required)

- if MSH is 
in "pull mode", then errors should clearly be pulled - but as result of what 
Pull request?)

- Should the 
Error mode be decoupled from the response mode, in req-response 
MEPs.

 

then it may 
be easier to figure how to specify the error reply mode... 

[Jacques Durand] 

 

 

 -----Original 
Message-----
From: Jeff Turpin 
[mailto:]
Sent: Tuesday, February 08, 2005 
8:54 AM
To: Jacques Durand; 

Subject: 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" 
  <> 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