WCF behaviors vs. pipelines on BizTalk Server R2
BizTalk Server R2 is close to be released and one of the most attractive features for traditional BizTalk developer is the new set of Windows Communication Foundation (WCF) adapters. As of today, this set of adapters represents the best way of leveraging the WCF capabilities into BizTalk Server applications. Arguably, the WCF adapters can be seen as a continuation of the previous SOAP and WSE 2.0-3.0 adapters. However, there are major differences between WCF and its technology predecessors. WCF is fundamentally a messaging framework that offers a lot of capabilities beyond the traditional Web Services frameworks. By this time you might already know that WCF is going to be the core of the future BizTalk messaging engine. However, at this point, there is still some overlapping between WCF and the BizTalk messaging engine capabilities. Why I am writing all this? Well, I decided to start writing a series of posts about how to utilize some of the WCF capabilities that present some overlapping and also complement existing BizTalk Server features. Thinking about that, I don't see a better place to start than with WCF behaviors and BizTalk Server pipelines.
WCF Behaviors
Behaviors are one of the components that differentiate WCF from other Web Services technologies in the market nowadays. Using this feature, developers can add custom extensions that inspect and validate service configuration or modify runtime behavior in Windows Communication Foundation (WCF) client and service applications. WCF behaviors can be implemented at different scopes of the WCF programming model such as Contract, Service, Endpoint and Operation. In that sense there are four types of WCF behaviors:
- Service Behaviors: Implement IServiceBehavior and are the primary mechanism by which you modify the entire service runtime.
- Contract Behaviors: Implement the IContractBehavior interface and are used to extend both the client and service runtime across a contract.
- Endpoint Behaviors: Implement IEndpointBehavior and are the primary mechanism by which you modify the entire service or client run time for a specific endpoint.
- Operation Behaviors: Implement the IOperationBehavior interface and are used to extend both the client and service runtime for each operation.
Another important aspect of WCF behaviors is that they can be applied on both the service (ServiceHost) and the client (ChannelFactory) level. Depending of where they are applied WCF behaviors can be executed in different orders.
The ServiceHost applies behaviors in the following order:
- 1. Contract
- 2. Operation
- 3. Endpoint
- 4. Service
Within any collection of behaviors, no order is guaranteed.
The ChannelFactory applies behaviors in the following order:
- 1. Contract
- 2. Endpoint
- 3. Operation
One of the most popular uses of behaviors is as a mechanism to plug in message interceptors into the WCF processing pipeline. If you find that familiar with the role of pipelines in BizTalk Server you should keep reading this paper.
WCF behaviors and BizTalk Server R2
BizTalk Server R2 presents some peculiarities in regards to the use of WCF behaviors. On the current release, the WCF-Custom adapters allow the use of Service and Endpoint behaviors but not Operation and Contract. There are a number of reasons behind that design decision which can be the topic of another paper altogether. Just to give an example, typically (there are some exceptions to this) a BizTalk orchestration exposed as a WCF services will implement only one contract generated from the exposed port types. That means that there is no real difference between Service and Contract behaviors from the BizTalk Server R2 standpoint.
The interesting thing is that both Behaviors and pipelines have the capability of intercept and manipulate the messages to enter or leave BizTalk Server. So is time for the classic question: when to use what?
WCF Behaviors vs. BizTalk pipelines
Although there is some overlapping between the features of BizTalk pipelines and WCF behaviors there are also important differences that can help to determine when to use one technology vs. the other. I have put together a simple list of some of the most important similarities and differences between the two technologies.
Similarities:
- Scope: Both WCF behaviors and BizTalk pipelines can be executed before the message is processed by a Transmit adapter or after the message is received by a Receive adapter.
- Message manipulation: Both WCF behaviors and BizTalk pipelines have the capability of modify the message that enter or leave BizTalk Server.
- Endpoint relationship: Both WCF behaviors and BizTalk pipelines can be associated with a send port or receive location.
- Configuration: Both WCF behaviors and BizTalk pipelines can be configured at deployment time.
Differences:
- Execution context: BizTalk pipelines are executed under the BizTalk Server context which gives them the capability of accessing and modifying BizTalk specific artifacts such as context properties, endpoint configuration, etc. WCF behaviors, on the other hand, are executed under a WCF-specific context which gives them access to WCF-specific parameters that are not available at other stages of the message lifecycle.
- Stages: BizTalk pipelines presents a state machine model based on different message manipulation stages such as Decode, Disassemble, Validate, Resolve Party, Assemble, etc. That model dictates the expected actions that should be performed to the message at each state. Contrary, the WCF behaviors state machine model is based on the different components of the WCF Service model: Service, Contract, Operation and Endpoint. This model doesn't make any assumptions about the expected actions to be performed against a message.
- Message input-output: The artifacts created by WCF behaviors such as Message interceptors or Parameter interceptors are executed against a single message. That is, they can receive one message and output one message. Some BizTalk pipeline components such disassembles or assemblers can perform operations against multiple messages.
- BizTalk orchestration execution: BizTalk pipelines can be executed from BizTalk orchestrations. WCF behaviors operate exclusively at the adapter level.
- Deployment time execution (see example on the next section): Some behavior's operations can be executed when the endpoint is configured. For instance, by implementing the Validate operation on WCF Service or Endpoint behaviors developers can enforce certain aspects of the configuration based on business rules. That facilitates the implementation of Governance practices that are very difficult to enforce in classic BizTalk Server scenarios. BizTalk pipelines are always executed at runtime against a set of messages.
- Runtime configuration (related with above): WCF behaviors have the capability of dynamically adding parameters that can modify the execution of the WCF runtime (WCF adapter). BizTalk pipeline are executed under a predefined runtime configuration.
An example might help: Using WCF behaviors in BizTalk Server R2
This section will explore how to use a basic WCF behavior with BizTalk Server R2. Our behavior is going to plug in a message interceptor that can modify the message after is processed by the WCF-CustomIsolated adapter. Also the behavior applies some validation logic against the receive location configuration at deployment time. The following code illustrates the message interceptor we are going to use.
In order to intercept the messages for a WCF service we need to implement the IDispatchMessageInspectorinterface as illustrated on the following code.
|
public class MessageTransformer: IDispatchMessageInspector { public object AfterReceiveRequest(ref Message request, IClientChannel channel, InstanceContext instanceContext) { Implement processing logic here... return null; } public void BeforeSendReply(ref Message reply, object correlationState) { } } |
The interceptor can act on a message after is received by the WCF adapter or before it is sent. Sounds Familiar? Just like pipelines.
In order to plug in the interceptor into the WCF processing model we need to implement a Service Behavior and override ApplyDispatchBehavior operation.
|
public class TransformerBehavior: IServiceBehavior { public void AddBindingParameters(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase, Collection<ServiceEndpoint> endpoints, BindingParameterCollection bindingParameters) { }
public void ApplyDispatchBehavior(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase) { MessageTransformer inspector = new MessageTransformer(); foreach (ChannelDispatcher chanDisp in serviceHostBase.ChannelDispatchers) { foreach(EndpointDispatcher endDisp in chanDisp.Endpoints) endDisp.DispatchRuntime.MessageInspectors.Add(inspector); } }
public void Validate(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase) { if (!serviceDescription.Namespace.Contains("temp")) throw new InvalidMessageContractException("testing baheviors"); } } |
Similarly, the behavior also applies some validation rules against the endpoint configuration. This is done primarily by implementing the Validate method of the interface.
After that, we need to implement a very simple WCF Binding element that allows our custom behavior to be configured at deployment time.
|
public class TransformerBindingElement: BehaviorExtensionElement { public override Type BehaviorType { get { return typeof(TransformerBehavior); } }
protected override object CreateBehavior() { return new TransformerBehavior(); } } |
After exposing an orchestration as a WCF service we can plug in our custom behavior adding the following sections to the configuration file.
|
<system.serviceModel> <extensions> <behaviorExtensions><SampleInspector /> </serviceBehaviors> </behaviors> <services> <service name="Microsoft.BizTalk.Adapter.Wcf.Runtime.BizTalkServiceInstance" behaviorConfiguration="ServiceBehaviorConfiguration"> <endpoint name="HttpMexEndpoint" address="mex" binding="mexHttpBinding" bindingConfiguration="" contract="IMetadataExchange" /> </service> </services> </system.serviceModel> |
The WCF behavior is applied when the WCF endpoint (receive location) is configured at deployment time. At that time, the WCF behavior will to plug the message inspector and apply the validation rules implemented as part of the Validate operation. After that, each time a client application invokes an operation from the WCF service (BizTalk orchestration) the inspector operations are invoked.
Where are we?
WCF behaviors and BizTalk Server pipelines provide mechanisms for intercepting and modifying messages that are processed by BizTalk Server. Although there are some overlapping between the use cases for both technologies; for most of the scenarios is possible to determine which technology provides a better fit. WCF behaviors can be an interesting option when comes to enforcing deployment configuration practices.
PS: Do you have more similarities and differences between WCF behaviors and BizTalk pipelines? Let's debate.