Brian Just to comment something from your reply , "don't use exceptions to control the normal flow of your program". You could have a whole thread discussing this point!"
I agree but is that the AXIS arcitecture that forces you to do it, is that right? I mean there is not other way to tell my client that there was a logic error during invocation, the only alternative is via the return type! A true/false but it is very limiting anyway! As I said in my previous reply, the message oriented approach is more flexible! Because I am controlling 100% the actual response , I can embend my fault logic in my custom body , and the client can have a look! Ok ok the weak point here is that the client side ..must have knowledge of the server-side logic.... R we taliking here generally for web services architect weakness or I am just overeacting! -----Original Message----- From: Brian Ewins [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 4:11 PM To: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Monday, February 17, 2003 10:08 AM > To: [EMAIL PROTECTED] > 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 ----- > &Agr;&pgr;&oacgr;: "Apostolopoulos Paris" <[EMAIL PROTECTED]> > &EEgr;&mgr;&egr;&rgr;&ogr;&mgr;&eegr;&ngr;&iacgr;&agr;: &Dgr;&egr;&ugr;&tgr;&eacgr;&rgr;&agr;, &PHgr;&egr;&bgr;&rgr;&ogr;&ugr;&aacgr;&rgr;&igr;&ogr;&sfgr; 17, 2003 1:54&pgr;.&mgr;. > &THgr;&eacgr;&mgr;&agr;: 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 >> >> > > > >
