Basics of Failure

A WCF message exchange session consists of three types of messages.

1. Application messages are defined by the service contract and are what most people think of when they use the word message.
2. Infrastructure messages are used to support the protocols of message exchange. For example, security negotiation messages and receipt acknowledgment messages generally are not included as first-class application messages. These types of messages are more likely to be created and consumed by protocol layers below the application level.
3. Fault messages are carriers that signal that the server is unable to understand or process an application or infrastructure message from the client.

I'll be talking about fault messages for the next two weeks. This first post is an introduction to some of the terminology used to describe faults in a SOAP messaging system. Even though there are differences in fault handling between SOAP 1.1 and SOAP 1.2, I'm not going to belabor that point. I will mostly be referring to SOAP 1.2 fault messages and you can translate those concepts into other messaging systems.

Faults come with a code that lets you programmatically determine the type of the fault. Fault codes sound a lot like error codes but are actually implemented using the model of exception types. The representation of fault codes consist of opaque strings (much like an exception namespace and type name). Creating new fault codes should be a lot like creating new exception types. It's unnecessary to create a new code for every possible fault. Instead, a new code is needed only when the client is expected to programmatically handle the fault differently than other types of fault.

The differentiator between multiple faults using the same fault code is often the fault reason. A fault reason is the human readable description of the fault. Users are unlikely to make a decision based on the fault code. Anything that could have been figured out from the fault code should have been performed automatically. Instead, users are going to read this description to understand what corrective action they should take.

The last part of a fault is the fault detail. Fault details are arbitrary content attached to the fault that the client may be able to make use of. Interpretation of the fault detail is often only possible if you know something about the particular system that generated the fault. Otherwise, the fault detail is essentially a blob that lives inside of the fault.

These three elements are part of the WCF object model for faults. Put together, these elements form the bulk of the body of a fault message. I'm going to cover the object model in more detail starting next time.

Next time: Creating Faults, Part 1

Comments

• Anonymous
  December 12, 2006
  The idea of metadata is to provide a description of your service such that someone, with no other information

• Anonymous
  January 08, 2007
  The last piece of this eleven part series on fault messages covers advice for channel authors that need

• Anonymous
  February 19, 2007
  I haven't forgotten about the goal to put together a table of contents for all of these articles. The