RE: [ws-caf] proposal for soap faults

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.

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

amfletcher@iee.org (also tony_fletcher@btopenworld.com)

-----Original Message-----
From: Mark Little [mailto:mark.little@arjuna.com]
Sent: 01 February 2005 23:39
To: ws-caf
Subject: [ws-caf] proposal for soap faults

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.

<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"/>

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.

ws-caf message