Enterprise Library In-depth analysis and flexible application (8): WCF and Exception handling APPBL

Enterprise Library In-depth analysis and flexible application (8): WCF and exception handling Appblock integration [Next]

In the previous article, I explained in detail how to implement the exception handling in WCF and Microsoft enterprise libraries by customizing Clientmessageinspector and ErrorHandler Application The integration between block (Ehab). The basic idea of this scheme is that when the exception is thrown from the server, the Ehab is processed for a configured exception handling policy, then the handled exception is encapsulated by the Serviceexceptiondetail object, and the final serialization is placed in the fault message, which is eventually returned To the client, after the client receives the fault message, extracts and creates the Serviceexceptiondetail object, rebuilds the exception through reflection, and throws the exception so that the client can further process the exception based on the exception handling policy configured by the client.

To implement WCF serialization and deserialization of Serviceexceptiondetail objects, we must define the type as an error contract through the Faultcontractattribute attribute, as shown in the following code. In general, if you define a service that is used by others, such as Third-party service consumers, the definition of the error contract is necessary because the corresponding error detail type needs to be published in the form of metadata to instruct the client how to deserialize the received message. However, if the service is only for your own application, then you can dynamically add the appropriate error description at run time to avoid applying such a faultcontractattribute to each service operation method of the service contract.

1:　[ServiceContract(Namespace　= 　"http://www.artech.com/")]
2:　public　interface　 ICalculator
3:　{
4:　　　　　 [OperationContract]
5:　　　　　[ExceptionHandlingBehavior ("myExceptionPolicy")]
6:　　　　　[FaultContract(typeof (ServiceExceptionDetail),　Action　=　"http://www.artech.com/fault")]
7:　　　　　int　Divide(int　x,　int　y);
8:　}

The Faultcontractattribute feature that we apply above the operation method will eventually be converted to the error description (faultdescription) of the operation description (OperationDescription), If we can add the corresponding error description to all the operation descriptions at run time, we can avoid applying the same Faultcontractattribute attribute to each service operation. However, in order to reuse the service, I do not mind this lazy, so this program is only for research, learning.

I. Dynamically adding error descriptions (service side) through custom ServiceHost

First you need to add a Serviceexceptiondetail error description on the server for each service operation, which can be achieved by customizing the ServiceHost. Since the service description needs to be generated before ServiceHost open (the specific reason is relatively complex, you can find the answer in the 7th chapter of the WCF Technical Analysis (Volume 1) On the Service boarding section), so we define the relevant logic in the Onopening method. In the following code, I have defined such a simple servicehost:exceptionhandlingservicehost.

1:using System;
2:using System.ServiceModel;
3:using System.ServiceModel.Activation;
4:using System.ServiceModel.Description;
5:
6:namespace Artech.EnterLibIntegration.WcfExtensions
7: {
8:public class Exceptionhandlingservicehost:servicehost
9: {
10:public Exceptionhandlingservicehost (Type T, params uri[] baseaddresses)
One:: Base (T, Baseaddresses)
12: {}
13:
14:protected override void Onopening ()
15: {
16:base. Onopening ();
17:foreach (ServiceEndpoint endpoint in this. description.endpoints)
18: {
19:foreach (OperationDescription operation in endpoint. Contract.operations)
20: {
21:faultdescription faultdescription = new Faultdescription (serviceexceptiondetail.faultaction);
22:faultdescription.detailtype = typeof (Serviceexceptiondetail);
23:operation. Faults.add (faultdescription);
24:}
25:}
26:}
27:}
28:}

The logic is relatively simple: traversing all endpoints (serviceendpoint), each operation of the contract for each endpoint (ContractDescription) (operationdescription) Adds an error description (faultdescription) with an error detail type of Serviceexceptiondetail and specifies a predefined action.

For custom ServiceHost, you can directly use a hosted scenario that does not require an. svc file for access, meaning that you can directly use a custom ServiceHost for service boarding except for IIS and was. Services need to adopt custom ServiceHost in both IIS and was, and you need to create a corresponding servicehostfactory (for servicehostfactory roles and usage, see also WCF profiling (Volume 1 ) (chapter 7th). Below, we define a simple servicehostfactory:exceptionhandlingservicehostfactory for exceptionhandlingservicehost.

1:　using　System;
2:　using　 System.ServiceModel;
3:　using　 System.ServiceModel.Activation;
4:　using　 System.ServiceModel.Description;
5:
6:　namespace 　Artech.EnterLibIntegration.WcfExtensions
7:　{
8:　　　　　public　class　ExceptionHandlingServiceHostFactory　:　 ServiceHostFactory
9:　　　　　{
10:　　　　　　　 　　protected　override　ServiceHost　CreateServiceHost(Type　 serviceType,　Uri[]　baseAddresses)
11:　　　　　　　　　{
12:　　　　　　　　　　　　　return　new　 ExceptionHandlingServiceHost(serviceType,　baseAddresses);
13: 　　　　　　　　　}
14:　　　　　}
15:　}