MHonArc v2.5.0b2 -->
ebxml-msg message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: 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]
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]