Raymond,
Thanks for organizing this discussion much better. Responses inline...
On Jan 23, 2008 12:44 PM, Raymond Feng <[EMAIL PROTECTED]> wrote:
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.
I think this could be OK, but let's also consider adding the
exc->fault pattern to this model
in some manner. More below...
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.
So the introspection today is flawed in strictly tying the databinding
of the fault to a single
exception pattern. Someone might want to write an exception in the
Axis2 pattern which wrappers
an SDO. In today's framework you'd have to have an
Axis2-pattern-SDO-fault exc handler.
So I'm thinking we need to, for Java exceptions, figure out the
exception->fault pattern
first and then use that to figure out the type of the fault. Once
we've figured that out the fault type we can simply
do an introspectType(faultType, annotations) to figure out the
databinding of the fault.
The databinding of the fault is used to transform the fault from one
databinding to another, however it
should not be tied to the question of how to map between fault and
exception. Since we already had
to introspect to figure out that exc->fault pattern, let's save this
information, i.e. save the fault pattern.
It is that fault pattern then that should determine how to get from
fault->exc and exc->fault. These functions
are currently served by ExceptionHandler.createException() and
ExceptionHandler.getFaultInfo(), respectively.
Again, the ExceptionHandler is currently tied to a specific
databinding when it should be tied to a fault pattern.
Now.. you'll see in the patch I attached to TUSCANY-1206 a step
towards implementing this. I'm not saying
that the fields I added to DataType, 'exceptionHandler' and
'exceptionPhysical', represent the best solution. (In fact
it's incomplete since I still have the ExceptionHandler tied to a DB).
So if this is a good solution it should apply to WSDL intfs as well..
and I tried to take a step to integrate the WSDL
introspector. I haven't looked at that code in awhile though so I'll
leave it at that mention.
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
