Thank you very much Brian, your tips were very helpful!
-----Original Message----- From: Brian Ewins [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 6:15 PM To: [EMAIL PROTECTED] Subject: Re: Some help with the usage and notion of FAULT messages! Apostolopoulos Paris wrote: > 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! I don't see why you think responses are limited to being true/false. An RPC response can contain arbitrary stuff. Thinking in java terms, you could have something like: public class SillyResponse() { public boolean isFault(); public ComplexType getFaultDetails(); public OtherComplexType getNormalResponseDetails(); } and then have a method like: public SillyResponse doSomething(BigBallOfGoo junk) { ... } This gives you an arbitrarily complex fault response mixed with an arbitrarily complex normal response. But this use is silly, because Exceptions/Faults provide a similar mechanism without you needing to check if(response.isFault()) everywhere. The Axis architecture in this regard is just limited by whats possible in SOAP, which isn't limiting at all - you can put arbitrary stuff in a SOAP Fault, or a SOAP RPC response, and its up to you which you choose. Soap Fault details can contain arbitrary stuff about what went wrong in your call. > > 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.... Yes, that is the usual complaint about having custom exceptions - the whole point of throwing an exception is that the 'server' doesn't know how to handle the problem, so if the client can apply an 'automatic fix', then the client knows too much about the server. Usually exceptions/faults just contain a faultcode to allow you to display an appropriate internationalized message, or decide if the exception is ignorable. > > R we taliking here generally for web services architect weakness or I > am just overeacting! > I think you are overreacting a bit. It does look like there is a bug in Axis that may well prevent RPC faults being handled correctly, but the mechanism described in the SOAP, WSDL, and JAXRPC specs doesn't limit you at all. > -----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 >>> >>> >> >> >> >> > > >
