Export (0) Print
Expand All

Integrating with WCF

Windows Communication Foundation (WCF) provides extension points that allow you to support custom scenarios such as checking security attributes and performing policy assertions. The Validation Application Block includes a WCF integration library that adds a custom behavior, and a parameter inspector. This extension allows the application block to validate WCF messages, data contracts, and parameters.

When the WCF service begins, it invokes the custom behavior. This custom behavior then adds the parameter inspector. WCF calls the parameter inspector twice for each message it processes. The first time is before it sends the call to the service implementation. The second time is after the service generates the return message. This section explains how you can use the Validation Application Block with your WCF applications. In general, you must do the following:

You can either use attributes or configuration to include the Validation Application Block in your service contract. The following sections discuss each approach.

Using Attributes

To use attributes, add the ValidationBehavior attribute to your service contract. This is shown in the following code example.

[ServiceContract(Namespace = "http://tempuri.org")]
interface IMyService
  // ...

By adding this attribute, the application block automatically validates all input values that are associated with rule sets. You can specify the rule set to use by including the rule set name as an argument to the ValidationBehavior attribute. If you do not specify a specific rule set, it uses the default rule set. You can use different rule names for different operation or you can use a single name across the service contract.

You then add attributes to the members of your OperationContract interface to define the validation rules. You should not apply the validation attributes to the implementation of the interface.

Using Configuration

To use configuration, you must edit the <System.serviceModel> section of the configuration file. First register the behavior extension. This is shown in the following code example, which registers a behavior extension named "validation".

<add name="validation"
             Microsoft.Practices.EnterpriseLibrary.Validation.Integration.WCF" />

After you include the application block, you can define a behavior that uses it. You can use either a service behavior or an endpoint behavior. The following code example defines an endpoint behavior.

      <behavior name="ValidationBehavior">
        <validation enabled="true" ruleset="MyRuleset"/>

This example specifies a rule set named "Bank2Rules" in the behavior element. If you do not specify a rule set, the application block uses the default rule set.

You can also define operation and contract behavior as in the following two examples.

  <behavior name="operationBehavior">
    <validation enabled="true" ruleset="MyRuleset"/>

The following defines a contract behavior.

  <behavior name="contractBehavior">
    <validation enabled="true" ruleset="MyRuleset"/>

Finally, define the endpoint that uses this behavior. This is shown in the following code example.

<service behaviorConfiguration="MyService_Behavior"
  <endpoint binding="basicHttpBinding"
            behaviorConfiguration="ValidationBehavior" /> 
  <endpoint address="mex" binding="mexHttpBinding"
            contract="IMetadataExchange" />

If you want the client to receive relevant validation failure information, you must modify the service contract. To do this, use the FaultContract attribute, as demonstrated in the following code example. The implementation of the StartTransaction method of the IMyService interface and the implementations of the types for its parameter and return value are not shown here.

public interface IMyService
  StartTransactionResponse StartTransaction(request StartTransactionRequest);

Any time a client invokes the StartTransaction method, the rule sets that are associated with the StartTransactionRequest type run. If any of the validators included in the rule set fail, the service is not called and the client receives an exception of type FaultException<ValidationFault>. If you do not specify the FaultContract attribute, the client only receives the generic exception message and any specific validation error information is lost.

Because WCF messages and data contracts are all .NET types, they can be associated with validators either by using the standard validation attributes or with the configuration tools, just as you can for any other type. In most applications, you can apply validators to properties, fields, and methods in your OperationContract interface (not in the implementation of an interface). However, with WCF applications, you can also associate validators with specific parameters of a method. This is shown in the following code example.

void ValidateMyParameters(
  string ssn,
  [RangeValidator(5, RangeBoundaryType.Inclusive, 50, RangeBoundaryType.Inclusive)]
  int value)

This example checks that one parameter is a non-null string that is formatted as a valid social security number and that the other parameter is an integer in the range of 5 to 50. This validation should occur within the operation contract.

For more information about WCF, see Windows Communication Foundation on MSDN.

You can only validate parameters with attributes, and not with configuration.

© 2015 Microsoft