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.
