The ability to easily implement custom processing within the WCF stack, is one of the main reasons why WCF (Windows Communication Foundation) is such a rich programming paradigm compared to other ways of communication.
WCF, when paired with BizTalk Server, opens up numerous extensibility options that were previously not possible.
A particularly useful piece of WCF extensibility, is commonly referred to as behaviors.
Behavior extensions are one of the components that differentiate WCF from other Web services technologies in the market. By using this feature, developers can add custom extensions that inspect and validate service configuration or modify run-time behavior in WCF client and service applications. Custom behavior extensions can exist at both the WCF service and client levels. Configuring a behavior on the call stack to a WCF service has no influence on the communication binding used to make the call. In fact, behaviors are typically invisible to the client because they are not displayed in the metadata that a service publishes. The client typically has no idea that the extensions are running during a call to a WCF operation.
Behaviors are already well documented else where, so I will try keep ramble to a minimum. What follows is the code, and steps I undertook to get a custom client side (called CookieBehavior) WCF behavior working with BizTalk Server 2010. The behaviors purpose is simple, it creates a user defined (outbound) HTTP header based on a passed in context value. It also inspects the response (inbound) for another user defined HTTP header, and if it exists, writes it into the message context for consumption by BizTalk.
Create a class that inherits from IClientMessageInspector. You have the option of building a client (i.e. the service caller) or service (i.e. the service provider) facing behaviors. Since the sample behavior here is focused around calling an existing service, have chosen to implement the IClientMessageInspector interface.
To manage the behavior’s configuration (to avoid hardcoding), I am using the following.
Next, the message inspector needs to be surfaced as an endPoint behavior, through the ApplyClientBehavior method.
Finally, expose the endpoint behavior as an extension element. This type gives us the opportunity to convey/reflect the runtime configurable properties of the behavior.
BizTalk’s WCF-Custom adapter will translate the above, to something that looks like this.
Update the machine.config located here %systemroot%\Microsoft.NET\Framework\v2.0.50727\CONFIG. The BizTalk Server 2010 Administration Console’s WCF UI is based on this version of the CLR. You will now need to restart any running instances of the BizTalk Admin Console.
To communicate with the custom behavior from BizTalk, I am using the WCF header context properties, which the WCF adapter make available. For example:
The above snippet results in this:
The custom behavior is configured to look for a WCF header called Cookies. If it exists, an HTTP header called Cookie will be created by the behavior, resulting in this going across the wire.
The service responds, with this:
The custom behavior will look for a (user configured) HTTP header, in this case Set-Cookie. If found the value of the HTTP header is placed into a WCF header (again this is user configurable) called Cookies. Resulting in the following context state for the inbound reply message.