Hi, Scott.
Thank you for bringing this issue up again for discussion.
I think the topic is mostly about how to work with WSDL faults in Java. If
we start with a WSDL port type, the WSDL2Java mapping will generate the
corresponding Java exceptions to represent the WSDL faults. If we start with
a java interface, the Java2WSDL mapping will derive the fault definition
from the checked exception on the business methods.
Let's look at various aspects in this area:
1) The model to represent the exception/fault metadata
We have the following model today:
DataType
physical ---- the exception class
logical --- DataType
physical --- the fault data class
logical --- the fault data logical type, for example, the XMLType
for the fault element
I think it's OK.
2) The Exception/Fault patterns (How does a java exception wrap/represent a
fault)
There are a few important fault patterns:
* JAX-WS section 2.5 pattern (i.e. getFaultInfo() returns wrappered fault
with specific constructors)
* JAXWS section 3.7. It derives a WSDL fault from the plain Java exception
on the SEI.
* Axis2 pattern: It's similar to JAX-WS 2.5 pattern, but the method name is
getFaultMessage()
* Plain Java Exception: The exception itself has properties corresponding to
the fault data
* Other patterns such as JAX-RPC?
The exception/fault pattern could be independent of the databinding of the
fault data. For example, we could use the JAX-WS 2.5 pattern for fault data
in SDO. We should replace the FAULT_ELEMENT with @WebFault.
We can try to unify the fault wrapper exception pattern using JAX-WS. The
fault data can be represented using different databindings, such as SDO,
JAXB or POJO.
When we introspect Java interfaces, we need to match the exceptions by
supported patterns and populate the DataType for the exceptions.
3) Service specific exception (user fault) vs. Protocol level exception
(system fault)
There are two types of faults:
a) User fault: The service-specific fault decalred on the business
operation, for example, SymbolNotFound
b) System fault: The WS stack hits a system/procotol level problem
Both faults could be seen in the SOAP messages, and we need to be able to
distinguish them.
We use a FaultException to represent the fault data from different bindings
as the uniform wrapper. Different stack may use different exceptions for the
SOAP fault, for example, SOAPFaultException by JAXWS and AxisFault by Axis2.
4) The algorithm to match the fault data back to the corresponding java
exception
We also need to refine the algorithm to map a fault data back to a Java
exception declared on the business method. It can be based on the fault
QName. If there is no match, we should wrap the fault into a
ServiceRuntimeException.
Thanks,
Raymond
----- Original Message -----
From: "Scott Kurz" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Thursday, January 10, 2008 5:14 PM
Subject: Exception->Fault mapping
A few months back, I wrote up a proposal for "decoupling the fault
databinding from the way that the exception maps to a fault"
which would among other things "get the exception handlers out of the
introspection business."
The mail is here:
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg24973.html
and I attached a patch to:
https://issues.apache.org/jira/browse/TUSCANY-1206
Can we re-open this discussion? I know I may have missed some of
the discussion in the meantime; I apologize and if so maybe someone
wouldn't mind pointing me to that.
Anyway at the time Raymond said it sounded like a good idea, but I
don't think anything came of it.
I know there's been some related work, e.g. Simon Nash's work on
TUSCANY-1939, but to me it seems the issues I encountered still exist.
This isn't just a question of elegance. One problem with using the
ExceptionHandler.getFaultType() as an introspector can be seen by
considering:
public class MyExcMsg extends Exception {
private int fault;
public static QName FAULT_ELEMENT = new
QName("http://blah","MyFault";);
// The rest follows the JAX-WS Sec 2.5 pattern,
So with the current code, the SDOExceptionHandler will say, "yes, I
recognize this" and we'll set up SDO as the DB for the fault. But
the DB should be "simple".
And the bigger point I'm making is: the question of SDO, JAXB, or
simple should be a question of what the fault looks like, not the
pattern by which the exception
maps to a fault.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
