axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Apostolopoulos Paris" <p...@freemail.gr>
Subject RE: Some help with the usage and notion of FAULT messages!
Date Mon, 17 Feb 2003 16:31:42 GMT
Thank you very much brian! 
To tell you the truth I was thinking of changing the Style of my web
service and move to a message driven one where there you have more
processing power to the logic of the request.What do you think!

The thing I know from my short experience is that Throwing a exception
IS Not the appropriate way to indentify an error generally, and FAULTS
in AXIS can wrap exceptions or form itself an exception.Or am I wrong?

-----Original Message-----
From: Brian Ewins [mailto:Brian.Ewins@btinternet.com] 
Sent: Monday, February 17, 2003 4:11 PM
To: axis-user@ws.apache.org
Subject: Re: Some help with the usage and notion of FAULT messages!


If its a client error, you throw a fault with a fault code beginning 
with the string "Client" - eg "Client.AuthenticationFailure" or 
"Client.SomeMadeUpMessage". If you want to send something more than a 
simple code, you add 'detail' to your fault. You should /not/ put 
something in the faultstring that the client is supposed to interpret - 
as the spec says:
"The faultstring element is intended to provide a human readable 
explanation of the fault and is not intended for algorithmic
processing."

You're supposed to be able to send a custom fault like this:
SOAPFaultException exception = new
javax.xml.rpc.soap.SOAPFaultException(
new QName(javax.xml.rpc.NamespaceConstants.NSURI_SOAP_ENVELOPE, 
"Client.SomeMadeUpMessage"),
"You should put on trousers first, THEN shoes",
actor, detail);
// see SOAPFactory for info on creating 'Detail's
throw exception;

For a fuller example, see the SOAPFaultException example at 
http://dev2dev.bea.com/direct/webservice/index.html. However looking at 
the axis source I can't see where SOAPFaultException is being caught - 
it should really get converted into an AxisFault in 
AxisFault.makeFault(Exception), so that it gets serialized correctly. 
This might mean you can't do this at the moment because of an Axis bug.

NB the faults you'll get from internal axis errors (what you call 
"technical problems") have a different namespace for the faultcode - 
org.apache.axis.Constants.NS_URI_AXIS. This is how you can tell them 
apart from exceptions which occurred on the server, which must have the 
namespace above.

Fundamentally the question of whether to return faults/throw exceptions,

or whether its "[your] responsibility  as a developer that should take 
care of it", is something that comes up in every language that has 
exceptions. The most concrete rule I've seen is in the Eiffel language, 
where exceptions are thrown if a method cannot ensure that its 
postconditions are true at the point when it should return a value; in 
other languages this becomes the weaker "don't use exceptions to control

the normal flow of your program". You could have a whole thread 
discussing this point.

-Baz

Apostolopoulos Paris wrote:
> The real question is, and what about a real logic error occurs during 
> the invocation. In order the caller to  identify if the call was 
> succesful , the most reasonable way of doing it is to return a 
> boolean! And lets say that a method call might not have only 2 
> possible answers and you want to notify the client, that something was

> not succesful? What I do throw an Axis Fault from my core service 
> code?
> 
> Is it me or I  have a feeling that AXIS is a bit restrictive on FAULT 
> definition and the way it is despatched in the client?
> 
> -----Original Message-----
> From: constantis@b-online.gr [mailto:constantis@b-online.gr]
> Sent: Monday, February 17, 2003 10:08 AM
> To: axis-user@ws.apache.org
> Subject: Re: Some help with the usage and notion of FAULT messages!
> 
> 
> Hi Paris!
> Good to know there's another Greek on the list! I think that if your
> service will be used by you and only you (that's usually what happens 
> with final year projects :) ), meaning that you'll be developing both 
> the provider and the requestor sides, all you have to do is code in 
> some logic to handle your "error string". That's for the easy part!
If, 
> on the contrary, you mean to develop a service that will be used by
all 
> kinds of clients-requestors you need to find a more standardized way
of 
> exposing any errors your service might encounter. And that is, as 
> you've already imagined, through the fault element of the wsdl doc.
> 
> All the above express my knowledge of the WS architecture. Correct me
> if I'm wrong...
> 
> Regards,
> Costas
> 
> ----- Original Message -----
> Από: "Apostolopoulos Paris" <papo@freemail.gr>
> Ημερομηνία: Δευτέρα, Φεβρουάριος 17, 2003 1:54π.μ.
> Θέμα: Some help with the usage and notion of FAULT messages!
> 
> 
>>Hi!
>>
>>User status : AXIS newbie
>>
>>Well I am developing some 'simple' web services as part of my final 
>>year project! I am using a 100% RPC approach! I have a service that is
>>responsible of making some sort of user validation. The client invokes
>>the Logging service passing a username and password. The service 
>>checksits credentials and if the processing is succesful returns 
>>an encrypted
>>string that is going to be used for the invocation of other
>>services,like a passport lets say :) . Ok.. my newbie question is ,
>>alright and what if the credentials are bad..and the logging is non
>>valid. Is it my responsibility  as a developer that should take 
>>care of
>>it, I mean that I should return a string saying 'ERROR' and the client
>>side.(which is implemented by me) should have the code to check the
>>string , or SHOULD i sent a FAULT response. From what i have red till
>>now, a FAULT message is only associated with exception occuring at the
>>AXIS engine as overal? Can i use FAULT messages to deliver businees
>>logic to my client? or the FAULT messages are only for technical
>>problems in the request/response flow! 
>>
>>If yes, how can i send as a response a FAULT message ? through a 
>>handleri suppose in the response flow?
>>
>>Thank you for your time
>>A.P
>>
>>
> 
> 
> 
> 



Mime
View raw message