proposal for soap faults

["Mark Little" <mark.little@arjuna.com>]

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