Enterprise Library In-depth analysis and flexible application (8): Integration with Ehab through WCF extension [

Enterprise Library In-depth analysis and flexible application (8): Integration with the Ehab through WCF extension [last article]

In the last chapter of WCF technical Profiling (Volume 1), I gave a specific example of a distributed application of WCF, which I named PetShop. In this example, I used the extension of WCF to implement a number of design, architectural patterns, such as AOP, IOC and so on. Readers who have read this book must remember that I also implemented the integration of the Microsoft Enterprise Library (Enterprise Library) exception Handling Application Block (Exception handling application Block:ehab) through WCF extensions. Because of the lack of background knowledge, it is impossible to introduce specific implementation, now we can detail how this is achieved.

Introduction of the basic principle

In a distributed application based on WCF, the server and client require separate exception handling. On the server side, it's easy to get Ehab to handle the thrown exception, we just need to call the Excpetionpolicy HandleException method in the way shown in the code above, pass in the thrown exception and specify the appropriate exception handling policy name. The key is how to implement the exception that is thrown by the Ehab processing client for a service call.

We know that the type of exception that the client throws on the service call is always faultexception (including faultexception<tdetail>). Instead, Ehab uses an exception that is completely based on the type of exception, that is, the type of exception that is thrown determines how the exception is handled. That is, even if two completely different error scenarios, as long as the thrown exception has the same type, Ehab will handle the exception in the same way. This approach to directly handle exceptions thrown by invoking a WCF service is obviously very restrictive: if the service is good, any processing, the client will always catch faultexception (excluding faultexception<tdetail>) exceptions, If Ehab is used, it means that there is only one way to handle the exception. Of course, in the service side of the implementation of the operation you can be based on specific scenarios to throw faultexception<tdetail> exceptions, and through different types of error details (Tdetail) to encapsulate specific error messages, then the client can be specific The faultexception<tdetail> exception types are selected in different ways for processing. This makes your exception handling the real scene-driven.

Theoretically, what we need is the way the exception is handled. But in rapid development, such a method is not very operable, because an essential attribute of an exception is unpredictability. For a service operation, it is not likely to list all the error scenarios and throw the corresponding type of exception. That's why we need a configurable exception-handling framework like Ehab, so that we can define the appropriate exception handling strategy for an exception that we didn't foresee before, by modifying the appropriate configuration.

Our next presentation solves the problem in a workaround that is somewhat similar to the propagation of an exception via Servicedebugbehavior: The exception that is thrown by the server is first handled by Ehab according to the configured exception handling policy. The information associated with the processed exception, including the AssemblyQualifiedName of the exception type, is then encapsulated into a exceptiondetail-like serializable object. Finally, the Messagefault is created on the basis of the object and the fault message is passed back to the client, and the client receives the fault message and extracts the server-side exception-related The information uses reflection to reconstruct the exception object (it has been clarified that the assemblyqualifiedname of the exception type makes it possible to reconstruct the exception object) than to throw it. Then for the client's application, it's like capturing the exception thrown from the server. This exception handling is still scenario-driven by Ehab the thrown exception with the exception handling policy that is configured for the client.

In this example, we encapsulate exception-related information by using a type called Serviceexceptiondetail. For the sake of simplicity, I directly let serviceexceptiondetail inherit from Exceptiondetail. Since the Serviceexceptiondetail object needs to be delivered from the server to the client, I define it as a data contract. Serviceexceptiondetail only defines a unique attribute member: AssemblyQualifiedName, an assembly valid name for the type of exception that is required for reflection based exception reconstruction. In Serviceexceptiondetail, 3 string constants are defined to represent the Subcode name and namespace of the corresponding SOAP fault, and the action of the corresponding fault message. The principle of implementing the whole solution can be seen in Figure 1.

1:using System;
2:using System.Runtime.Serialization;
3:using System.ServiceModel;
4:namespace Artech.EnterLibIntegration.WcfExtensions
5: {
6: [DataContract (Namespace = "http://www.artech.com/")]
7:public class Serviceexceptiondetail:exceptiondetail
8: {
9:public Const string faultsubcodenamespace = "http://www.artech.com/exceptionhandling/";
10:public Const string faultsubcodename = "Serviceerror";
11:public Const string faultaction = "Http://www.artech.com/fault";
12:
[DataMember]
14:public string AssemblyQualifiedName
{get; private set;}
16:
: [DataMember]
18:public New Serviceexceptiondetail InnerException
{get; private set;}
20:
21:public Serviceexceptiondetail (Exception ex)
: Base (ex)
23: {
24:this. AssemblyQualifiedName = ex. GetType (). AssemblyQualifiedName;
25:if (null!= ex. innerexception)
26: {
27:this. innerexception = new Serviceexceptiondetail (ex. innerexception);
28:}
29:}
30:
31:public override string ToString ()
32: {
33:return this. message;
34:}
35:}
36:}


Figure 1 The implementation principle of WCF and Ehab integration

Note: Some people feel that this is the same as the Servicedebugbehavior service behavior that opens the Includeexceptiondetailinfaults switch, the exception information is completely exposed to the client, there is the risk of sensitive information disclosure. In fact, if you define the operation of sensitive information in the relevant exception handling strategy and implement it through Ehab, the information that is eventually passed to the client is already handled.