Development

Extending WCF using the IInstanceProvider and IServiceBehavior Interfaces

James Bender — Wed, 09 Apr 2008 15:15:39 GMT

Recently, meaning yesterday, two of my colleagues, Kriss Scott and Matt Casto ran into an issue with one of WCF services.

To make a long story short, they needed to do some policy injection, which one or both of them will probably blog about at some point. The difficulty was getting access to the constructor of the WCF service object.

Luckily the ability to create custom behaviors in WCF makes this relatively easy.

The first step was to choose what type of functionality the behavior needed to provide. Since we are looking to effect the way the service object is created, IInstanceProvider was the obvious choice. Kriss and Matt also wanted this behavior to effect all calls to this service object, so IServiceBehavior was also to be used.

What's different?

In my last series of posts on behaviors, I created a behavior based on the IDispatchMessageInspector which, hence the name, attached to (and effected) the behavior of the message dispatcher in the WCF runtime. If you remember from my previous posts, the Dispatchers are responsible for passing messages around the runtime and controlling service runtime attributes (channel dispatcher is connected to the endpoint dispatcher, the endpoint dispatcher is connected to the operation dispatcher, the operation dispatcher is connected to the operation). This was implemented as an IEndpointBehavior which meant that it was applied to a specific endpoint. So, if a message came through the endpoint we applied the behavior to, the behavior logic would execute. If a message come into the same operation of the same service but through a different endpoint the behavior would not execute.

We "attached" our behavior (in code) thusly...

In the hosting code, before we opened the host, we added an instance of the behavior to the behavior collection for our endpoint:

host.Description.Endpoints[0].Behaviors.Add(new MyCustomMessageFormatter("message"));

This caused the runtime to call the ApplyDispatchBehavior of our custom behavior object:

public void ApplyDispatchBehavior(ServiceEndpoint endpoint, EndpointDispatcher endpointDispatcher)
{
    endpointDispatcher.DispatchRuntime.MessageInspectors.Add(this);
}

This was the code actually responsible for adding our custom logic to the correct place in the WCF runtime, in this case the MessageInspectors collection for the EndpointDispatcher passed in from the WCF runtime. If this code wasn't here, the behavior would never have actually been implemented in our service.

But that was IDispatchMessageInspector and IEndpointBehavior.

IInstanceProvider and IServiceBehavior are different animals.

For starters, your implementation of IInstanceProvider has to be attached to the endpoint dispatchers instance provider. Unlike the message inspector, there can only be one instance provider per endpoint.

But there are a couple little "wrinkles" in this whole thing. Remember when I said that Matt and Kriss wanted to implement this at the service level and not the endpoint level? That means they need to use IServiceBehavior, not IEndpointBehavior. Well, like IEndpointBehavior, IServiceBehavior has an implementation of the ApplyDispatchBehavior:

public void ApplyDispatchBehavior(ServiceDescription serviceDescription, 
    ServiceHostBase serviceHostBase)
{

}

One thing you may notice is that unlike the endpoint behaviors version of ApplyDispatchBehavior, we get references to ServiceDescription and ServiceHostBase passed in; not ServiceEndpoint or EndpointDispatcher. But, we need to attach this behavior to an endpoint. Here's how we do it:

public void ApplyDispatchBehavior(ServiceDescription serviceDescription, 
    ServiceHostBase serviceHostBase)
{
    foreach (ChannelDispatcherBase channelDispatcherBase in serviceHostBase.ChannelDispatchers)
    {
        ChannelDispatcher channelDispatcher = channelDispatcherBase as ChannelDispatcher;
        if (channelDispatcher != null)
        {
            foreach (EndpointDispatcher endpoint in channelDispatcher.Endpoints)
            {
                endpoint.DispatchRuntime.InstanceProvider = this;
            }
        }
    }
}

Service host base gives us access to the collection of channel dispatchers, which in turn gives us a collection of endpoint dispatchers. From here it's a simple matter to iterate through each collection and attach the behavior as need.

This is the easy example. I'm just attaching the behavior to all the endpoints in all the channel dispatchers for this service. If I wanted to I could examine each endpoint and make some kind of determination about what kind of action I wanted to take on that endpoint. In this case we didn't need to.

From here it's a simple matter to add it to our runtime from code (remember to do this BEFORE you call host.Open()):

host.Description.Behaviors.Add(new MyInstanceProvider());

Or from configuration:

<service name="Sample.HelloWCF" behaviorConfiguration="MyInstanceProviderBehavior">

...

<behaviors>
    <serviceBehaviors>
        <behavior name="MyInstanceProviderBehavior">
            <MyInstanceProvider/>
        </behavior>
    </serviceBehaviors>
</behaviors>

...

<extensions>
    <behaviorExtensions>
        <add name="MyInstanceProvider"
             type="CustomBehaviorSample.InstanceProviderExtensionElement, Behavior,

Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
    </behaviorExtensions>
</extensions>

Remember, to add this behavior via configuration, you'll need a class based on BehaviorExtensionElement to do the "heavy lifting." I covered this here and a bit more here. This time around our implementation is much simpler since we aren't passing any information in at configuration and we are starting with our behavior extension element as a separate class:

class InstanceProviderExtensionElement : BehaviorExtensionElement
{
    protected override object CreateBehavior()
    {
        return new MyInstanceProvider();
    }

    public override Type BehaviorType
    {
        get { return typeof (MyInstanceProvider); }
    }
}

The last step is to implement the methods from IInstanceProvider:

public object GetInstance(InstanceContext instanceContext)
 {
     return GetInstance(instanceContext, null);
 }

 public object GetInstance(InstanceContext instanceContext, Message message)
 {
     return new HelloWCF();
 }

 public void ReleaseInstance(InstanceContext instanceContext, object instance)
 {
     return;
 }

As you see, this is relatively trivial. We have two overrides of the GetInstance method; one that takes a message (in case we want to inspect the message before deciding what kind of object to return) and one that doesn't. We also have a ReleaseInstance method to allow us to perform any additional cleanup that is needed.

So, that's all there is too it! If you have any questions feel free to leave a comment or ping me on twitter.

Later!

Making WCF "Behave" - Part Three

James Bender — Sat, 01 Mar 2008 15:29:03 GMT

When last we left our weary adventures, they had created a custom WCF Behavior based on the IDispatchMessageInspector that when attached to an endpoint of a WCF service intercepted the outgoing message and replaced it with it's own nefarious text (see here).

Their plan was brilliant! Brilliant that is, except for one minor detail.

You see, in their haste our motley crew had simply attached the behavior to the endpoint at runtime when the service host was initiated. They quickly realized that the real power of WCF is the ability to change behaviors via configuration. This would require a little more work...

Now, back to our story...

In order to be able to add our custom behavior through configuration, we need to make sure the WCF Service Model knows it exists. We do this by having our behavior inherit from System.ServiceModel.Configuration.BeahviorExtensionElement. This gives us an abstract property called "BehaviorType" which tells the service model the type of our custom Behavior, and an abstract method "CreateBehavior" which actually returns an instance of our custom behavior.

For this example I've chosen to implement this in my actual custom behavior class. And yes, if that was the way you do it all the time the service model should be smart enough to get the type and call a default constructor on our custom behavior. But the reason for this base class, and the methods it exposes, is that you could implement all of this in a class other than your actual behavior. This allows a lot of power in the way that custom behaviors are created, and I will cover strategies for this in another post.

Anyway...

If we add this to the custom behavior from last time, we get:

class MyCustomMessageFormatter : BehaviorExtensionElement,
    IDispatchMessageInspector, 
    IEndpointBehavior
{
    ...

    public override Type BehaviorType
    {
        get 
        { 
            return typeof(MyCustomMessageFormatter);
        }
    }

    protected override object CreateBehavior()
    {
        return new MyCustomMessageFormatter();
    }
}

The next step is to let your application know about the behavior in the configuration file. This is done by adding the and "extensions" node to the configuration:

<extensions>
    <behaviorExtensions>
        <add name="CustomBehaviorElement"
             type="CustomBehaviorSample.MyCustomMessageFormatter, 
			Behavior, Version=1.0.0.0, 
			Culture=neutral, PublicKeyToken=null" />
    </behaviorExtensions>
</extensions>

This tells WCF where to find the bits for your custom behavior. The name you assign here will be used when we create the behavior configuration. The type attribute is the full name of the class with all the rest of the type information WCF needs to locate and load it. In your config file is it CRUCIAL that this all be on one, non broken line. I broke it here so it would be easier to read. Also remember that spelling counts. I spent about 25 minutes trying to figure out why this didn't work for me the first time, only to discover that I had misspelled the word "neutral."

So far, so good. The next step is creating the behavior configuration.

Do you remember last time when I said there were two type of behaviors? Service and Endpoint Behaviors. Well, trust me, I said it.

Anyway, since Service and Endpoint configurations need to be separated in our config file, this is where we need that information again. For the record, we created an Endpoint behavior, so our behavior configuration will look like this:

<behaviors>
    <endpointBehaviors>
        <behavior name="MyCustomEndpointBehavior">
            <CustomBehaviorElement/>
        </behavior>
    </endpointBehaviors>
</behaviors>

Let's contrast that with a behavior configuration for an out-of-the-box behavior:

<behaviors>
    <serviceBehaviors>
        <behavior name="MEXBehaviour">
            <serviceMetadata httpGetEnabled="true"/>
        </behavior>                
    </serviceBehaviors>
</behaviors>

Aside from the fact that one of these is an Endpoint behavior and one is a Service behavior, there aren't a lot of differences. We set a name so that we can reference the behavior elsewhere in our configuration. In our WCF-supplied MEX behavior we have a pre-defined configuration tag which supplies the configuration information for us. In the configuration for our custom behavior, we are doing the same thing, except that the behavior tag that we are using was defined by when we added the behavior type information in the behaviorExtensions section of the configuration.

The other difference we see is that we are setting a property of the MEX behavior; httpGetEnabled. We have the ability to add our own custom properties and we'll do this in the next post.

OK, we're almost there!

All that's left is to wire up are endpoint behavior configuration:

<endpoint address="HelloWCF" binding="wsHttpBinding" 
	contract="CustomBehaviorSample.IHelloWCF" 
          behaviorConfiguration="MyCustomEndpointBehavior"/>

And that's pretty much it. If we run it, we get the result we expect:

Easy peasy! But, that message is hard coded into our behavior, and I don't really like that. We'll fix that in the next post...