WCF Technical Insider 25:2nd Part _ 5th Chapter _ Message: Create a message (Messagefault)

Message and SOAP Fault

The message type defines a number of factory methods that are used to create a SOAP fault messaging object. A SOAP fault is a form of a SOAP message that is used to represent an error message. In the SOAP specification (1.1 and 1.2) there is a difference between the content of the message body and, at some point, the rules for the header block of the SOAP message. A message is a CLR abstraction for a SOAP messaging that can represent the soap Fault and represents a SOAP message. This section describes the basic concepts of some SOAP fault and creates basic types that represent SOAP fault messages, and how to create a message instance that represents a SOAP fault.
Analysis of SOAP Fault

SOAP fault comply with the SOAP specification (1.1 and 1.2). Essentially, SOAP1.1 fault contains a SOAP body,body that wraps a necessary faultcode old Xu Memo 2, faultstring element, and an optional faultactor and faultdetail element. To avoid repeating these specifications, you can find more http://www.w3.org/TR/soap11 of the optional elements here. At a higher level, faultcode represents an identifier that the recipient and the sender can use to identify the error SOAP1.1 specification and define a small set of FaultCode, but the program can define the only faultcode that it uses. FaultString represents an artificially readable faultcode that is not meant to be given to the receiving program (unless you want to faultstring show it to the user). FaultCode is a URI that describes the source of the error.

Soap Fault has changed a lot from SOAP 1.1 to SOAP 1.2. Because SOAP 1.2 is built on Infoset, the SOAP 1.2 fault essentially consists of a collection of information items. In addition to these changes, the names of the SOAP fault components have been modified and extended to include more descriptive information. SOAP 1.2 stipulates that the SOAP fault should contain a required code and Reason (reason), an optional node, role, or detail (details). Details of when to add this information can be viewed here: http://www.w3.org/TR/soap12-part1/#soapfault. Typically, code is an identifier that has an error, and it also allows you to use a child code to represent finer grained information. SOAP 1.2 defines some code and allows the program to define its own code. Reason is a human-readable error-interpreting message. Node represents the message participant that generated the error. The role information represents the roles of the message participants when SOAP errors are generated. Detail is an error message that is prepared for other message participants.

SOAP 1.1 and 1.2 Fault, throwing away their differences, are similar to the types of information they describe. Both specify the label of the error code, the human-readable error description information, the SOAP fault message participant information, and other information about the error. For this purpose, WCF defines a type that represents the SOAP 1.1 and SOAP 1.2 FaultSystem.ServiceModel.Channels.MessageFault. Before we learn how to represent the SOAP fault of SOAP 1.1 and SOAP 1.2, let's look at how the Messagefault type summarizes the SOAP fault.
Messagefault

The Messagefault type is a way to describe error information in a soap-version-agnostic manner. Keeping in mind this WCF has a highly layered architecture, the Messagefault type provides tremendous when pro Cessing SOAP messages and optionally generating exceptions.

The Messagefault type can describe error messages for various SOAP versions. Remember that WCF has a higher level of architecture, and the Messagefault type provides a great deal of flexibility when handling SOAP messages or generating exceptions.

Create a Messagefault object like many other types in WCF, Messagefault is an abstract type that defines several factory methods. These factory methods accept parameters that represent the information stored in the SOAP fault. In addition, Messagefault also defines the identity of the message participant that produces the SOAP fault as an argument. It is noteworthy that Messagefault defines a factory method that accepts a message as an argument. This method is useful when WCF receives a SOAP Fault message and needs to pass this error information to other WCF infrastructure parts for processing.

The System.ServiceModel.FaultCode type represents faultcode information. This type defines several factory methods as constructors. All build Methods The cloud uses the child code. The factory method on the FaultCode type automatically generates the sender and receiver error codes (as defined by SOAP 1.1 and SOAP 1.2).

The System.ServiceModel.FaultReason type represents the Faultreason. In the simplest case, a constructor accepts a string string as a parameter. A string represents a human-readable error message. Because people speak different languages (Microsoft. NET developers do not speak a single language, Faultreason types define constructors and methods that allow programs to embed multiple versions of string and appropriate descriptive information based on different cultures.

In addition to that one Messagefault defined factory method, the others accept a faultcode and Faultreason type as parameters. Therefore, these types must be instantiated before Messagefault is created, except to create Messagefault from the message. Several factory methods also accept object as an argument, which represents an additional error message. For object parameters in the message factory method, they must support serialization (more serialized content in chapter 9th). The existence of this parameter poses a problem, "What type should I use as an argument?" "Because System.Exception is serializable, you might pass a Exception parameter." I strongly advise you to dismiss the idea. I prefer to customize a type that passes the error message to other message participants. As we will see in chapter 9th, this brings a change to the contract.