You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Glen Mazza <gl...@gmail.com> on 2009/02/09 07:52:40 UTC
Returning database SQL errors to the SOAP client
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.
Re: Returning database SQL errors to the SOAP client
Posted by Glen Mazza <gl...@gmail.com>.
(Thanks Benson and Bharath for your suggestions.)
Jaro, just to clarify, when you say a "single soap fault type" do you mean
you throw a SOAPFaultException (which is not defined within the WSDL) or is
it a single wsdl:fault defined in the WSDL? I guess it really doesn't
matter, but just want to get a better idea of your design.
Also, in your latest post in this thread, you say the method returns an
empty complex type--just to confirm, the SOAP client does *not* need to
bother to inspect that empty complex type on return, the fact that the
method returned with no SOAP exception thrown means everything's good,
correct? Also, that single empty complex type defined in the WSDL can be
used for countless different database CRUD-type web service operations,
providing you throw exceptions on an error, correct? I.e., InsertWidget,
InsertThingy, UpdateWidget, DeleteThingy, etc. can all use that same return
type providing you don't need to return any real information for a
successful web service call.
Thanks,
Glen
Jaroslav Libak-2 wrote:
>
> Hello
>
> I use a single soap fault type, with integer code and string message.
> String
> message is only meant for debugging, and usually contains exception
> message (or
> class name), including messages of nested exceptions. Integer codes
> roughly
> correspond to HTTP error codecs, and determine error handling of client.
>
> You should avoid having too many fault types, and adding new fault types
> to
> existing web service methods.
>
> Jaro
>
--
View this message in context: http://www.nabble.com/Returning-database-SQL-errors-to-the-SOAP-client-tp21907792p21924608.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Returning database SQL errors to the SOAP client
Posted by Jaroslav Libak <ja...@seznam.cz>.
If no error occurred, then in java the web method returns "void", which in WSDL
means it returns an empty complex type.
You should not throw faults for ok conditions.
Jaro
Glen Mazza schrieb:
> OK, but what do you do if there is *no* error and the database action
> occurred--return nothing, or return a string that just says "OK"?
>
> I like the elegance of using a wsdl:fault for errors, but I was assuming I
> should still return something on success, and given that I going to be
> returning a response message on success, I could possibly use that same
> response message to list a failure.
>
> Thanks,
> Glen
>
>
>
> Jaroslav Libak-2 wrote:
>> Hello
>>
>> I use a single soap fault type, with integer code and string message.
>> String
>> message is only meant for debugging, and usually contains exception
>> message (or
>> class name), including messages of nested exceptions. Integer codes
>> roughly
>> correspond to HTTP error codecs, and determine error handling of client.
>>
>> You should avoid having too many fault types, and adding new fault types
>> to
>> existing web service methods.
>>
>> Jaro
>>
>> Bharath Ganesh schrieb:
>>> 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 <gl...@gmail.com> 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.
>>>>
>>>>
>>
>>
>
Re: Returning database SQL errors to the SOAP client
Posted by Benson Margulies <bi...@gmail.com>.
I'm not a fan of WSDL faults except for web-service specific problems.
Here's why. Often, I find that the code that I want to call via a web
service today I want to call directly tomorrow. Given that faults rarely map
quite precisely to exceptions, I'd build errors like this into the protocol
and map them out to exception further out.
On Mon, Feb 9, 2009 at 5:10 PM, Glen Mazza <gl...@gmail.com> wrote:
>
> OK, but what do you do if there is *no* error and the database action
> occurred--return nothing, or return a string that just says "OK"?
>
> I like the elegance of using a wsdl:fault for errors, but I was assuming I
> should still return something on success, and given that I going to be
> returning a response message on success, I could possibly use that same
> response message to list a failure.
>
> Thanks,
> Glen
>
>
>
> Jaroslav Libak-2 wrote:
> >
> > Hello
> >
> > I use a single soap fault type, with integer code and string message.
> > String
> > message is only meant for debugging, and usually contains exception
> > message (or
> > class name), including messages of nested exceptions. Integer codes
> > roughly
> > correspond to HTTP error codecs, and determine error handling of client.
> >
> > You should avoid having too many fault types, and adding new fault types
> > to
> > existing web service methods.
> >
> > Jaro
> >
> > Bharath Ganesh schrieb:
> >> 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 <gl...@gmail.com>
> 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.
> >>>
> >>>
> >>
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Returning-database-SQL-errors-to-the-SOAP-client-tp21907792p21923178.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
>
Re: Returning database SQL errors to the SOAP client
Posted by Glen Mazza <gl...@gmail.com>.
OK, but what do you do if there is *no* error and the database action
occurred--return nothing, or return a string that just says "OK"?
I like the elegance of using a wsdl:fault for errors, but I was assuming I
should still return something on success, and given that I going to be
returning a response message on success, I could possibly use that same
response message to list a failure.
Thanks,
Glen
Jaroslav Libak-2 wrote:
>
> Hello
>
> I use a single soap fault type, with integer code and string message.
> String
> message is only meant for debugging, and usually contains exception
> message (or
> class name), including messages of nested exceptions. Integer codes
> roughly
> correspond to HTTP error codecs, and determine error handling of client.
>
> You should avoid having too many fault types, and adding new fault types
> to
> existing web service methods.
>
> Jaro
>
> Bharath Ganesh schrieb:
>> 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 <gl...@gmail.com> 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.
>>>
>>>
>>
>
>
>
--
View this message in context: http://www.nabble.com/Returning-database-SQL-errors-to-the-SOAP-client-tp21907792p21923178.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Returning database SQL errors to the SOAP client
Posted by Jaroslav Libak <ja...@seznam.cz>.
Hello
I use a single soap fault type, with integer code and string message. String
message is only meant for debugging, and usually contains exception message (or
class name), including messages of nested exceptions. Integer codes roughly
correspond to HTTP error codecs, and determine error handling of client.
You should avoid having too many fault types, and adding new fault types to
existing web service methods.
Jaro
Bharath Ganesh schrieb:
> 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 <gl...@gmail.com> 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.
>>
>>
>
Re: Returning database SQL errors to the SOAP client
Posted by Bharath Ganesh <bh...@gmail.com>.
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 <gl...@gmail.com> 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.
>
>