You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Scott Kurz <sc...@gmail.com> on 2008/01/11 02:14:14 UTC
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Exception->Fault mapping
Posted by Raymond Feng <en...@gmail.com>.
Hi,
We had some explanations in the same thread before. Please see it below.
Simply speaking, when a SCA programmer works with Web Services, it uses Java
exceptions to represent WS faults. If she/he starts from WSDL, WSDL2Java
tool will generate the java exception from the WS fault. If she/he starts
with Java, Java2WSDL tool will generate the WS fault from java exceptions.
Different WS stacks have different patterns to map the Java Exception and WS
fault. We're trying to understand the patterns so that databinding framework
can help transform the fault data.
Thanks,
Raymond
<extracted from the previous note>
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.
</extracted>
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
Sent: Saturday, February 02, 2008 11:13 PM
Subject: Re: Exception->Fault mapping
> Raymond Feng wrote:
>> The binding-specific exception/fault mapping won't be exposed to the
>> programming model. I was proposing to make the mapping extensible so that
>> we can support multiple patterns without impacting the SCA application
>> code.
> [snip]
> Scott Kurz wrote:
>>> I agree that this is where the mapping patterns are coming from.
>>> But doesn't this undermine the
>>> whole binding-independent programming model feature advertised by SCA?
>
> Maybe it's just me, but I'm having trouble understanding what problem
> we're trying to solve. Could one of you post an example illustrating the
> issue in application developer terms?
>
> My naive view is:
> - binding-independent programming model sounds good!
> - extensible mapping sounds scary, as an application developer will I need
> to understand all these extensible mappings?
>
> But again I'm probably missing something as I'm not really able to
> understand what you're talking about, an example would help a lot.
>
> Thanks.
> --
> Jean-Sebastien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Exception->Fault mapping
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Raymond Feng wrote:
> The binding-specific exception/fault mapping won't be exposed to the
> programming model. I was proposing to make the mapping extensible so
> that we can support multiple patterns without impacting the SCA
> application code.
[snip]
Scott Kurz wrote:
>> I agree that this is where the mapping patterns are coming from.
>> But doesn't this undermine the
>> whole binding-independent programming model feature advertised by SCA?
Maybe it's just me, but I'm having trouble understanding what problem
we're trying to solve. Could one of you post an example illustrating the
issue in application developer terms?
My naive view is:
- binding-independent programming model sounds good!
- extensible mapping sounds scary, as an application developer will I
need to understand all these extensible mappings?
But again I'm probably missing something as I'm not really able to
understand what you're talking about, an example would help a lot.
Thanks.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Exception->Fault mapping
Posted by Raymond Feng <en...@gmail.com>.
The binding-specific exception/fault mapping won't be exposed to the
programming model. I was proposing to make the mapping extensible so that we
can support multiple patterns without impacting the SCA application code.
Thanks,
Raymond
----- Original Message -----
From: "Scott Kurz" <sc...@gmail.com>
To: <tu...@ws.apache.org>
Sent: Monday, January 28, 2008 2:30 PM
Subject: Re: Exception->Fault mapping
>I agree that this is where the mapping patterns are coming from.
> But doesn't this undermine the
> whole binding-independent programming model feature advertised by SCA?
>
> Scott
>
> On Jan 28, 2008 11:51 AM, Raymond Feng <en...@gmail.com> wrote:
>> 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" <sc...@gmail.com>
>> To: <tu...@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 <en...@gmail.com> 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" <sc...@gmail.com>
>> >> To: <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
>> >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >> >
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Exception->Fault mapping
Posted by Scott Kurz <sc...@gmail.com>.
I agree that this is where the mapping patterns are coming from.
But doesn't this undermine the
whole binding-independent programming model feature advertised by SCA?
Scott
On Jan 28, 2008 11:51 AM, Raymond Feng <en...@gmail.com> wrote:
> 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" <sc...@gmail.com>
> To: <tu...@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 <en...@gmail.com> 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" <sc...@gmail.com>
> >> To: <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
> >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Exception->Fault mapping
Posted by Raymond Feng <en...@gmail.com>.
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" <sc...@gmail.com>
To: <tu...@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 <en...@gmail.com> 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" <sc...@gmail.com>
>> To: <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Exception->Fault mapping
Posted by Scott Kurz <sc...@gmail.com>.
Raymond,
Thanks for organizing this discussion much better. Responses inline...
On Jan 23, 2008 12:44 PM, Raymond Feng <en...@gmail.com> 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" <sc...@gmail.com>
> To: <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Exception->Fault mapping
Posted by Raymond Feng <en...@gmail.com>.
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" <sc...@gmail.com>
To: <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org