SOA, Web Services, and Exceptions
Wednesday, February 11 2004
Ryan Rinaldi asks the question of how exceptions should be handled in a service oriented architecture, his solution is to return a status code but also complains that is feels way too much like HRESULT. So is there an alternative?
Not really. When you look at dealing with exceptions across a web service you have to keep the primary goal of web services in mind, which is enabling loosely coupled systems. Keeping this primary goal in mind means that we need to throw an exception that is XML and its probably a good idea to be at least partly human readable (I would want to include a message AND an ID, not just an ID), the SOAP specification handles this with the SOAP Fault.
.NET accommodates the SOAP fault with the SoapException which creates a SOAP fault (<fault> element) automatically for you based on the .NET exception that you threw inside your application. You can also create a SoapException on your own and use the detail element to add any sort of extra information to the SoapException, this is where you can put your exception code or other special information about your exception. (You could even serialize your exception using binary serialization and stick it in the detail element if you really wanted to, but then what's the point of using XML)
So basically in the end I think you do need to use some sort of error code instead manually parsing a string, but by creating your own SoapException you can use the detail element to put it in the right place. Learn about the soap fault and the SoapException, don't just let .NET hide it all from you.
Does anyone else have any ideas/opinions on this? Am I missing something?
Here is a little extra reading:
Handling and Throwing Exceptions in XML Web Services - MSDN
Framework Patterns: Exception Handling, Logging, and Tracing - informIT
-James
Comments
- #1 Scott Mitchell on 2.11.2004 at 3:58 AM
-
James, you're spot on, IMO. You can use the details section to return an XML document specifying details about the exceptional behavior.
A slight pedantic comment - SOAP 1.2 makes some changes to the SOAP Fault specification (no more <fault> element). See: http://www.w3.org/TR/SOAP/#soapfault - #2 James Avery on 2.11.2004 at 12:30 PM
-
From what I can tell it looks like it still requires a <fault> element:
"To be recognized as carrying SOAP error information, a SOAP message MUST contain a single SOAP Fault element information item as the only child element information item of the SOAP Body ."
What am I missing? - #3 Udi Dahan - The Software Simplis on 2.12.2004 at 12:42 AM
-
Assuming you had the original exception, what would you do with it ?
( Think about this for a second before answering ) - #4 James Avery on 2.12.2004 at 12:58 AM
-
Ummm... I would catch it? :)
Basically having the original exception would allow me to have a try catch statement that has a catch explicity for that exception and error handling based on that exception. The exception could also be bubbled up and caught at any level of the client application. (Whereas I would not want to let a SOAPException bubble past my service calling layer)
I am not sure where you are going here.
-James - #5 David Regan on 4.28.2004 at 9:38 AM
-
Scott Mitchell was pointing out that the 1.2 soap spec for faults is different to the 1.1 spec. This is an example of 1.2 fault:
<env:Fault>
<env:Code>
<env:Value>env:Sender</env:Value>
<env:Subcode>
<env:Value>m:MessageTimeout</env:Value>
</env:Subcode>
</env:Code>
<env:Reason>
<env:Text xml:lang="en">Sender Timeout</env:Text>
</env:Reason>
<env:Detail>
<m:MaxTime>P5M</m:MaxTime>
</env:Detail>
</env:Fault>
and this is an example of a 1.1 fault:
<soap:Fault>
<faultcode>soap:Client</faultcode>
<faultstring></faultstring>
<faultactor>http://localhost/SoapFaultExample/ThrowFault.asmx</faultactor>
<detail>
<mySpecialInfo1 xmlns="http://tempuri.org/"">http://tempuri.org/">">http://tempuri.org/"">http://tempuri.org/">
<childOfSpecialInfo />
</mySpecialInfo1>
<mySpecialInfo2 t:attrName="attrValue" xmlns:t="http://tempuri.org/"">http://tempuri.org/" xmlns="http://tempuri.org/"">http://tempuri.org/" />
</detail>
</soap:Fault>
Apologies for the poor formatting.
ASP.NET 1.1 SoapExceptions generate the 1.1 format not the 1.2. This is not a criticism just an observation that people might find helpful if they are building cross platform SOAs.