On 11/22/06, Tomek Sztelak <[EMAIL PROTECTED]> wrote:
On 11/22/06, Kalle Korhonen <[EMAIL PROTECTED]> wrote: > Well, instead you could return a PersonResponse wrapper object that would > have your Person as a property if the operation succeed. Don't do it :) Do you really want to create wrappers for every type you want to return from webservice ? Beside this why exceptions/faults
I beg to differ. This depends entirely on your service - in some cases a single response wrapper works for all of your services. Of course, there's sometimes a fine line between an error case and a case with multiple different return values. If you find an object by its name, is it an error if none are found or multiple matching objects are found? The answer depends on your service and whether you expect your client to be able to handle it as a non-error case (compared to an error case where the client often needs to delegate handling of that error case to somebody else, for which faults are good for). exist, to report errors,so we don't have return meaningless error
codes ( ERROR_CODE=300477630 and you have half a day to find out what this is for ;) .
Well, instead of a meaningless error code, you could return something meaningful, say an enum for example. I use faults, but I'm just saying they aren't necessarily the right solution for each differing return value. Kalle
If it didn't, you > return a null in person property and an error code in an errorcode property. > This makes some sense, because you can then reserve the faults for generic > failures, such as your "database not available" or "service initialization > failure" cases which are likely to affect all of you web service operations. > Even in pure Java client/server, using fault handlers for these generic > error types makes IMHO more sense than trying to use faults for each > specific error case for a particular operation. > > Kalle > > On 11/21/06, Bill Burton <[EMAIL PROTECTED]> wrote: > > Hello, > > > > I've written a simple service that provides a way to lookup Person objects > by id or email address. The Person object just has some name and address > information. When a record is not found, I'm catching the runtime exception > from the Spring JDBC API, and rethrowing a checked exception which causes > XFire to generate a SOAP fault as follows: > > > > <soap:Envelope > xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"; > xmlns:xsd=" http://www.w3.org/2001/XMLSchema " > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> > > <soap:Body> > > <soap:Fault> > > <faultcode>soap:Server</faultcode> > > <faultstring>No record with id 000123005 was found by the > findById method!</faultstring> > > <detail> > > <RecordNotFoundException xmlns=" http://webservice.teds.pms"/> > > </detail> > > </soap:Fault> > > </soap:Body> > > </soap:Envelope> > > > > Right now, I'm just using the default generated bindings in my Spring > applicationContext.xml > > > > <bean name="PersonService" > class="org.codehaus.xfire.spring.ServiceBean"> > > <property name="serviceBean" ref="PersonServiceImpl"/> > > <property name="serviceClass" > value="pms.teds.webservice.PersonService"/> > > </bean> > > > > but plan to switch to Aegis to have better control over the mapping for > other reasons. > > > > However, the person who's writing a C# .NET client to handle this > complains that it's hard to check for a fault whereas if I were to return an > error code and error text in my Person object, he would have no problem. As > the Person object is supposed to be a reflection of the database columns, I > really don't want to change it in this manner. > > > > What are the best practices for generating an error such as "record not > found" or "database not available" cases? > > > > Thanks for any assistance, > > -Bill > > -- > > Bill Burton < bburton ayht mail daht com> > > > > > > -- ----- When one of our products stops working, we'll blame another vendor within 24 hours. --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
