How about using one single wsdl:fault with the specific fault string and detail set?
This would mean the client always gets a fault in case of failure. At the same time - - Keeps the application simple - Not too many faults - For a new error on the server, the wsdl still remains same, client remains same.. - I don't see any performance benefit at the client side if it has specific faults. What do you think? On Mon, Feb 9, 2009 at 12:22 PM, Glen Mazza <[email protected]> wrote: > > Hello, I have a design question. For a web service that handles standard > database CRUD actions on a table, I was wondering about a good way to > return > error messages to the SOAP client based on standard database errors. > > For example, an "addWidget()" web service operation that adds a widget to > the widgets table, multiple errors can occur: > -- duplicate primary key > -- unique key violation > -- invalid value for a particular column > -- foreign key not found > > One way to handle this would be to create a wsdl:fault for each type of > error, which will get converted into a Java exception by wsdl2java. Then, > have the web service provider throw the appropriate Java exception on error > and have the SOAP client trap that error. > > But I think the client would still want a response even on a successful > insert of a widget (instead of a one-way "ping" type SOAP client call when > making the addWidget request.) A successful response would presumably just > be a xsd:string with value of "OK". But since I would then have to return > a > response anyway, fail or no fail, perhaps it would be better to avoid > wsdl:faults for database exceptions and just place the error in the > response > message, say with "FAIL" replacing "OK" and a detail element giving the > problem. > > So I see two solutions: > > 1.) Standard SOAP response of "OK" if the addWidget() succeeds, specific > wsdl:fault exceptions if it does not > > 2.) Standard SOAP response of "OK" or "FAIL", with a detail element giving > the problem if the latter; no wsdl:faults are defined or used. > > Any idea which is better--or other ideas? > > Thanks, > Glen > > -- > View this message in context: > http://www.nabble.com/Returning-database-SQL-errors-to-the-SOAP-client-tp21907792p21907792.html > Sent from the cxf-user mailing list archive at Nabble.com. > >
