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 <[EMAIL PROTECTED]> 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" <[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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
