I don't think fault/exception behavior has been sufficiently specified -- hence the interop issues.
The way it should work is thus:
On the server side:
Application throws an exception in its native language. The exception routine should map the error to a SOAP fault. The SOAP engine should return the SOAP fault.
On the client side:
The SOAP engine receives the SOAP fault. It maps the SOAP fault to a local language exception and throws the appropriate exception.
But to make that happen you need a way to properly configure the SOAP engine to map the SOAP fault to the exception.
When you have Java on both sides, the SOAP engines will automatically handle throwing the appropriate exceptions for you, but they don't really map the exceptions to specific SOAP faults. Axis maps most exceptions to Server.userException (which doesn't make any sense -- if the error is caused by the user, i.e., client -- then it should be mapped to a Client exception, not a Server exception). But anyway -- Axis returns the Java exception in the fault <details> element. If the client is anything other than Java, that exception won't be especially informative to the client application.
Anne At 10:33 AM 9/25/2003 -0500, you wrote:
Anyone else knowledgeable in Soap Faults have any comments on this?
Steve
> Steve, > > I am not knowledgeable enough to comment on whether your expectations are too > high or not. However, it all boils down to WSDL to a particular language > binding and how that binding maps SOAP faults defined in WSDL. I am not sure > whether there exists a standard language binding for each language (which may > or may not have a concept of exception e.g. a procedural language like C) that > addresses SOAP fault to error handling strategy native to that programming > language. > Hope someone on the list can enlighten us ... > Thanks, > > Ajay > > > > > > "Steve Pannier" <[EMAIL PROTECTED]> > > 09/24/2003 09:58 PM > > Please respond to > [EMAIL PROTECTED] > > > > To > [EMAIL PROTECTED] > cc > > Subject > Re: Soap Fault question > > > > > > > > > > Ajay, > > Thanks for the response. > > So maybe I'm not understanding the purpose for describing > Soap faults in a WSDL file. I was under the impression > that a soap implementation (regardless of > language/programming environment) would create the > appropriate "exception class" (or object, or whatever the > case may be for that environment) for all soap faults > defined in the WSDL, so that a client developer could > "catch" a specific fault (as opposed to, for example, a > .NET client having to catch a general System.Exception, > then interrogate it further to find out exactly what went > wrong). > > All I'm trying to do is simply describe the custom > exceptions my service throws in my WSDL, and then test > against various client environments to insure my WSDL > describes the faults correctly. But how do I test this > against non-Java clients? Or even Java clients for that > matter? > > Take the Axis samples/faults example. In VB .NET, after > retrieving the WSDL, does the client have any knowledge > at all about NoSuchEmployeeFault? It didn't look like > it when I tried it. And in BEA WebLogic (which generates > Java client code), the NoSuchEmployeeFault class it > generated did not subclass from Throwable, even though > NoSuchEmployeeFault is described in wsdl:fault elements > in the WSDL. > > Am I expecting too much here? Is there a better way for > me to test that my custom faults are described correctly > in my WSDL? > > Is there anybody who can set this lost soul straight? > > Regards. > > Steve Pannier > > > > Steve, > > > > I have experimented a bit with SOAP faults on .NET side and server side > > exceptions on Axis side. As far as my understanding goes: > > - You can access the SOAP fault from .NET client. However, that's "SOAP > fault" > > view - not the "Exception" view of the server side problem. I have not > seen > > SOAP faults being converted to exceptions on the .NET client side. In our > > > prototype, we are just accessing SOAP fault code, string etc. We can > convert > > that to appropriate exception but that's application's job not web > services > > infrastructure's job (in this case .NET) > > - I am not sure that a "custom" exception can be caught by non-Java (even > > > non-Axis clients implemented in Java) because there is no standard (and > hence > > interoperable) way of communicating that this SOAP fault maps to this > exception > > so that client side web services infrastructure can instantiate the > exception. > > In fact, you might consume a web service from a programming language > which does > > not have any concept of exception. In Axis server-client scenario > > interoperability is not an issue. Axis client knows where in the SOAP > fault to > > look for exception mapping information and as long as client has the > exception > > class in the classpath it can instantiate the exception but achieving the > same > > thing in a language independent way is difficult and I don't think web > services > > standards address this. Someone please correct me if my understanding is > not > > quite right .. > > > > Ajay > > > > > > > > > > "Steve Pannier" <[EMAIL PROTECTED]> > > > > 09/24/2003 02:54 AM > > > > Please respond to > > [EMAIL PROTECTED] > > > > > > > > To > > [EMAIL PROTECTED] > > cc > > > > Subject > > Soap Fault question > > > > > > > > > > > > > > > > > > Axis 1.1 > > > > I'm trying to get my web service to throw a > > custom exception subclassed from RemoteException. > > So to start off I looked at the code under > > samples/faults. I deployed the service, ran the > > supplied Axis client, everything looked good. (I > > had to 1st put a try/catch around the call.invoke > > in the client to see if catching the > > NoSuchEmployeeFault exception really works). > > > > Now, my goal is to be able to support many different > > types of clients (.NET, JWSDP, BEA WebLogic, etc). > > So I tried JWSDP: After getting the Employee.wsdl > > file from Axis, I generated the client code. But > > it wouldn't compile, because the "cause" property > > in the generated exception class is defined as Object > > instead of Throwable. (Axis did inform me that "The > > class java.lang.Throwable is defined in a java or > > javax package and cannot be converted into an xml > > schema type. An xml schema anyType will be used to > > define this class in the wsdl file", so I knew > > something was amiss.) > > > > OK. So I moved on to VB .NET. I retrieved the WSDL > > and created my client code. I was able to catch > > System.Exception, but not a NoSuchEmployeeFault > > exception. .NET did not create an object to > > represent the NoSuchEmployeeFault exception. > > > > I tried BEA WebLogic also, but it didn't work there > > either. The NoSuchEmployeeFault class it created > > does not subclass from Throwable, so it couldn't be > > used in a "catch" clause. > > > > So my questions: > > > > - Has anyone else got the samples/faults service > > code to work correctly against a non-Axis client > > environment? > > > > - Am I correct in assuming that my custom exception > > can be "caught" by any client, even if non-Java > > (provided my WSDL describes it correctly)? > > > > - In order to have Axis return a Soap Fault, is it a > > requirement to add *all* the configuration information > > shown in the samples/faults deploy.wsdd file to my > > WSDD deployment file? (i.e. Do I need to define all > > operation elements, even for the methods that don't > > return a Soap fault?) > > > > Any examples would be greatly appreciated. > > > > Regards. > > > > Steve Pannier > > > > > > > > > >
