Discussion on issue 1008

With respect to issue 1008, I support Gary's proposal and feel that we should pursue it. By separating the fault name from its underlying type, as this type may be reusable, we will:

1) Uniquely identify WSDL 1.1 faults - at present one cannot uniquely identify a WSDL 1.1 'fault name' using the information type. 

2) Avoid unnecessary duplication of definitions - at present information type is used to identify a fault; as a fault is scoped to a particular operation, we can end up defining an excessive number of information types for a wide range of faults, when these faults may actually be all associated with a small set of real types.

Using fault name and information type, it is possible to infer the 'fault' being referenced in either WSDL 1.1 and WSDL 2.0, providing a consistent approach which simplifies the CDL definition, while not adding any constraints on the user.

This isn't inconsistent with the CDL exception handling mechanism, as it doesn't actually 'throw' an exception; instead it simply correlating information type on the throwing element to the field in hasExceptionOccurred. As it exists, the CDL exception handling mechanism allows for two parts of a choreography to cause exception on a node that has the same fault informationType. In this situation, the exception handler for that informationType would not have information on which part of the choreography had caused the problem, forcing it to examine the choreographies state to determine what had gone wrong. As part of his proposal Gary suggests we modify causeException to provide and exception name, rather than using the information type - a minor change to the syntax with zero effect on the semantics. This achieves the objective of having the exception mechanism not being bound to particular types.

Let's discuss this at the next conference call (2005-May-10) towards resolving the issue.

Received on Tuesday, 3 May 2005 19:20:15 UTC