Hi, Scott.
I agree with you that the Fault<-->Exception mapping pattern should be
independent of the databinding for the fault data. Generally speaking,
the
mapping patterns are defined by the Web Service stack, for example,
JAXWS,
JAXRPC or Axis2. We probably we need to make the mapping handler
extensible
and then binding/implementation providers can plug in their own patterns.
Thanks,
Raymond
----- Original Message -----
From: "Scott Kurz" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Thursday, January 24, 2008 3:01 PM
Subject: Re: Exception->Fault mapping
> 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
