ws-tx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: New issue : WS-BA: Distinguish early and late fault - add Refuse message
- From: "Peter Furniss" <peter.furniss@erebor.co.uk>
- To: <ws-tx@lists.oasis-open.org>
- Date: Fri, 30 Jun 2006 00:15:46 +0100
Issue name -- WS-BA: Fault and Exit overloaded and overlapping - add Refuse message
PLEASE DO NOT
REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL THE ISSUE IS ASSIGNED A
NUMBER.
The issues coordinator will notify the list when that has
occurred.
Target document and draft:
Protocol:
WS-BA
Artifact: spec
Draft: BA spec cd 2
Link to the
document referenced:
http://www.oasis-open.org/committees/download.php/18819/wstx-wsba-1.1-spec-cd-02.doc
Section and PDF line number: section ,
lines
Issue type: Design
Related issues:
Issue
Description:
The semantics of Fault and
Exit are unclear, and partly overlapping. If the messages are
considered in terms of what they mean to the relationship between the parties
rather than the internal behaviour, there are three distinct
semantics. There should be three messages.
Issue
Details
The
present definition of the Fault message is
in terms of an internal event ("the participant has failed"); it would be better
to define it in terms of the effect on the application contract. However, as it
is currently, the Fault message means both “I have not done any of the work you
asked me” and “I have failed to undo the work
I was told to compensate”, depending on
when it was sent.
There
is also a related ambiguity in the use of the Exit message – the text
suggests
that this could be used to mean both “The application work you asked
me to do has no
effect” (perhaps because it has already been done) and “I
have not done any of the work
you asked me to” – which latter is also one of
the meanings of Faulted. Application messages
would
need to be sent to remove the
ambiguity.
Combining those two, there in fact three semantics : no
work, failed work, failed compensation. The semantics should be distinguished,
rather than rely on stage of the interaction or application
messages.
Proposed resolution
Create a new message, Refuse, for a
participants rejection of the work, and define the semantics of all
three:
Exit = The application work
you asked me to do has no effect : Close, Cancel and Compensate would all leave
our business relationship in the same state.
Refuse = I have not done any of
the work you asked me to. (a spontaneous statement of unwillingness to be part
of this activity.)
Faulted = I have failed to
reach the requested final state
Following the pattern for other messages,
Refuse would have a Refused reply.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]