Hi, Just to let you know I am using one application from a manufacturing system vendor that can recognize the exception thrown from my xfire webservice. On this software, it is actually easier to branch out from the exception, rather than process the an error wrapper. But it is not Java.
You can always wrap the error, but throwing exception xfire-style make my life so much easier. User can send me the exception and I can almost recognize what the actual problems on the server side. Adli On 11/23/06, Tonio Caputo <[EMAIL PROTECTED]> wrote:
Hi, Well I tell about problem that happened to me when evaluating Aqualogic Service Bus regarding faults an errors. Aqualogic let's you configure a Proxy for the WS implementation (the real logic). The Proxy configuration lets you retry calling to the WS Implementation if there is a fault, you can call the same end-point or iterate through a list of end-points. Of course as you imagine, Aqualogic cannot distinguish between what in EJB we call ApplicationException and SystemException, so if for example your web-service returns a fault if the result is not found or bad parameters in the service call, Aqualogic will retry although it will always fail. So I begin trying to figure out what should web-service must return in case of ApplicationException ( bad parameters, object not found, object already persisted, etc....) it seems that Object Wrapper is the only solution ( :-( ). I really don't know if all JBI implementations will work this way, but if they do we (Hate Wrappers Fanatics) are dead. I suppose we must read w3c/oasis/WS-I specifications to see what they say, and attach(?) to their recommendation. Hope this helps tonio On Wed, 2006-11-22 at 01:00 -0800, Kalle Korhonen wrote: > Well, instead you could return a PersonResponse wrapper object that > would have your Person as a property if the operation succeed. 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> > > --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
