Dear
Mark and others,
I am
not sure if what I am about to suggest is a counter proposal or an extension
of your proposal - I intended the latter.
I
suggest that we use the SOAP Fault elements and mechanisms purely for SOAP
message processing errors and that we have our own Fault message for problems
at a CAF level. This has the approach that all the use of SOAP 1.2 maybe
initially the 'norm', the CAF specifications will be able to use other
transports as well (for instance HTTP directly, but I am sure there are many
other possibilities already, and there will be more in the
future).
So I
propose that we do have a single definition for a Fault message at any level
of CAF - WS-Context already has one. The CF level, or what ever it turns
out to be should either reuse the WS-Context one or perhaps define its own
based on that of Context (by restriction and / or extension) or define its own
from scratch. One of the parameters of this message would be the error
code along the lines suggested by Mark below. I can envisage other
parameters such as 'additional information' which might contain a copy of the
message that prompted the fault, severity, retry time and so forth - to be
debated.
When
considering parameters for a fault message I understand that there are two
considerations:
Firstly is the current message exchange dead, or can it continue and if
so what is the next step with a probability of success and not just faulting
again.
Secondly providing diagnostic information to the other party in the
exchange, and / or to a third (management) party so that action can be taken
to lesson the probability of that fault in the future (i.e information
pertinent to locating and fixing the problem long term even if this particular
exchange has had it).
Best Regards
Tony
A M Fletcher
Tel: +44 (0) 1473
729537 Mobile: +44 (0) 7801 948219
In yesterday's teleconference I took an action to
produce a proposal for when we should use SOAP faults and when we might use
more protocol-specific messages to convey error conditions. So, here it is,
though in the process of doing this it changed slightly and it's no longer a
proposal, but something to prime the discussion. Please note that is a bit
difficult to do for WS-CF in its current state because some names may change,
some interfaces may disappear, but hopefully you'll get the idea of what we
can accomplish. If accepted, I think we should use this for all of the
specifications and not just WS-CF.
There's an open issue about whether and how we
might change our open content model for addressing, but let's assume there is
some equivalent in whatever addressing model we take of the wsa:FaultTo. So
what I would expect us to state that assumption but not rely on a specific
fault-handling mechanism. Our specifications would defined specific error
codes (and maybe additional information) that are to be used in conjunction
with the fault-handling mechanism. If SOAP 1.2 was used by an implementation,
then the error code becomes the fault sub-code and additional information is
passed in the detail.
On option would be to use this for all error
messages. Hence our schema would add something like:
<xsd:simpleType
name="ErrorCodes">
<xsd:restriction
base="xsd:QName">
<xsd:enumeration
value="wscf:GeneralFault"/>
<xsd:enumeration
value="wscf:WrongState"/>
<xsd:enumeration
value="wscf:DuplicateParticipant"/>
<xsd:enumeration
value="wscf:InvalidProtocol"/>
<xsd:enumeration
value="wscf:InvalidParticipant"/>
<xsd:enumeration
value="wscf:ParticipantNotFound"/>
<xsd:enumeration
value="wscf:NotCoordinated"/>
<xsd:enumeration
value="wscf:ProtocolViolation"/>
<xsd:enumeration
value="wscf:InvalidCoordinator"/>
<xsd:enumeration
value="wscf:InvalidActivity"/>
</xsd:restriction>
</xsd:simpleType>
Note, some of these error codes may be going away
anyway.
And for each error code we would stipulate the
expected/mandated/optional actions that are taken by a recipient and by the
sender. For example, whether it's a recoverable error condition.
I quite like this. It has the advantage in that
the WSDL no longer contains any error conditions and allows for extensibility
- if we missed an error that can/should be returned from a particular WSDL
operation, then adding it/allowing it within the model doesn't require a
change to the associated WSDL: it's up to the fault-handling mechanism to
figure out. It has the disadvantage that given the WSDL you can't see the
entire possible message exchange pattern/errors that may happen. But then
again, you've hopefully got the schema to assist.
The other option would be to use the CORBA
UserException and SystemException paradigm. If you look at the error codes I
wrote above, then the following could be classified as UserExceptions - only
returned from very specific operation invocations: DuplicateParticipant,
InvalidParticipant, InvalidProtocol, ParticipantNotFound, ProtocolViolation.
These could be modelled in the WSDL (as they currently are) as explicit
messages with the others as originally mentioned.
My current option would be to recommend the first
option: all errors are considered equal and managed in the same way; the WSDL
of a service only shows the normal expected interaction messages.
Comments?
Mark.
----
Mark Little,
Chief
Architect,
Arjuna Technologies Ltd.
www.arjuna.com