|
You don't *need* to define the SOAP faults, but you
*should* do so if you want to ba able to support non-Java clients. If you don't
define the faults, Axis will simply return the Java exception, and a VB.NET
client has no idea what to do with a Java exception.
You define the SOAP fault <detail>
information as a message <part>. A fault message is always formating using
the document style.
Anne
----- Original Message -----
Sent: Monday, June 30, 2003 4:48 PM
Subject: Re: Exception handling strategy
question
I am not a 100% sure, but as far as I understand it now, you
don't need to specify the SOAP Faults in your xsd, these are SOAP specific,
not part of your response message.
r
Tony Opatha wrote:
>Therefore you need to define a fault message for each of your
exceptions, and then tell >Axis to map the exceptions to the faults
accordingly.
So, this means that AXIS supports application-specific Faults for both
document-style
and RPC-style so long as the .xsd schema for the custom Fault messages
is specificied
as part of the WSDL, right?
thanks,
Tony
Remko,
You don't have to return a Document in order
to ensure language-neutrality. The whole point of SOAP and WSDL is to
provide a layer of abstraction between your object model and your message
structure that ensures language-neutrality. Axis lets you return whatever
your application would like to return, and then Axis will convert that
return into a document for you. No matter how you define your service (RPC
or Document -- whether you marshal the message or you let Axis marshal the
message), the client SOAP processing engine (e.g., .NET, MS SOAP,
PocketSOAP, SOAP::Lite, Axis, etc) will receive a document, and that SOAP
processing engine can automatically transform that document into the
appropriate language objects on the client side (VB, C#, Java, Perl,
etc).
It's fine if you want your application to
work directly with the XML -- the Axis Messaging style lets you do so --
but I want to make sure that you understand that you don't have to do so
to ensure language-neutrality.
When you return a fault, you don't return a
response message -- you return a fault message. Axis can automatically
capture an exception and return that exception to the client in a fault
message, but that doesn't help much if the client isn't Java. Therefore
you need to define a fault message for each of your exceptions, and then
tell Axis to map the exceptions to the faults accordingly.
Anne
-----
Original Message -----
Sent:
Friday, June 27, 2003 1:31 PM
Subject:
Re: Exception handling strategy question
Situation:
OK, so far this helped, and pointed
out the right direction in which to go. I had seen the SOAP Faults and
understand now when to use them.
I use the document/literal or
message style of web services in axis, since I am sending XML only.
I
use the
'public Document method(Document doc)'
signature,
and I need to be language neutral, and therefor have to return a
Document regardless. The Java Exceptions are indeed caught by the
client, but I can't use this method.
I managed to add a Fault to the
SOAPBody object from the MessageContext and set its parameters, but as
mentioned I need to return the Document, eg responseDoc, so the/any
client can query this for Faults.... or do I have to deal with it
differently??
Question:
How do I append the Fault
object to the Document to be returned??
Anne
Thomas Manes wrote:
There are four defined reasons to return a SOAP fault [1]:
- VersionMismatch: the request didn't specify the correct SOAP namespace
- MustUnderstand: a SOAP node did not understand a SOAP header that said
mustUnderstand='1'
- Client: the request failed either because it was malformed or contained
invalid data
- Server: the request failed because of some type of server error
Remko's example requires an error code of Client. The error report should be
returned in the fault <details> element. As long as you have Java on both
sides of the wire, the SOAP system on the client should be able to simply
rethrow the original exception (assuming that it has the exception class
installed). But if you intend to support non-Java clients, you should map
your various exceptions to specific SOAP fault messages.
[1] http://www.w3.org/TR/SOAP/#_Toc478383510
Regards,
Anne
----- Original Message -----
From: "George Jagodzinski" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, June 24, 2003 3:22 PM
Subject: RE: Exception handling strategy question
if you are refering to business logic that happens after the request has
been accepted I would say that the best way is to return some type of
error
report. I could be wrong but it seems like soap fault should only be
thrown
if there was a conformance issue. Someone please correct me if I am wrong.
--George
-----Original Message-----
From: remko de knikker [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 24, 2003 3:22 PM
To: [EMAIL PROTECTED]
Subject: Exception handling strategy question
when implementing a web service and a ws client, what is the general
design principle for exception handling, when
1. when user entered a non-valid input value, for instance it doesn't
exist in the database?
Do I simply through a SOAPFault or is it better to append my own
<doesnotexist> tag?
2. as a client, do I catch an xxxxException/Fault, do I look for the
soapenv:Fault tag or do I have to look the webservice specific <wserror>
tag??
What is the best design strategy here??
thanks,
r
Do you Yahoo!?
SBC
Yahoo! DSL - Now only $29.95 per month!
|
