.NET

Pimp Your WCF Runtime - Episode One

James Bender — Wed, 07 May 2008 01:32:09 GMT

If you have ever made any effort in learning WCF, you have probably seen some variation of this:

static void Main(string[] args)
{
    ServiceHost host = null;
    try
    {
        host = new ServiceHost(typeof (HelloWCF), new Uri("http://localhost:8080/HelloWCF"));
        host.Description.Endpoints[0].Behaviors.Add(new MyCustomMessageFormatter("message"));
        host.Description.Behaviors.Add(new MyInstanceProvider());

        host.Opening += host_Opening;
        host.Opened += host_Opened;
        host.Faulted += host_Faulted;

        host.Open();

        Console.WriteLine("Service is available.");

        Console.ReadKey();
    }
    finally
    {
        if (host != null)
        {
            Console.WriteLine("Closing service...");
            host.Close();
        }
    }
}

This hosting code, or some variant of it, appears in almost every book on WCF, usually in a console application. It demonstrates creating an instance of ServiceHost for a service implementation (in this case HelloWCF) with a specified URI. A couple of behaviors are added at runtime and we wire up some custom event handlers. All in all, for WCF, nothing complicated.

But what if you want to host your service in IIS? Since it comes with Windows Activation Service (WAS), IIS7 is an ideal environment to host your WCF service. So how do we get the same ability to customize our runtime in IIS?

It's actually pretty easy.

System.ServiceModel.Activation to the rescue!

IIS uses an instance of a ServiceHostFactory to create a runtime for your hosted service. If you do not provide an implementation for this class, IIS will provide you with a default implementation.

If we want to use are own hosting logic, all we have to do is create our own host class which inherits from ServiceHostFactory like so:

public class MyCustomHost : ServiceHostFactory
{
    public override ServiceHostBase CreateServiceHost(string constructorString, Uri[] baseAddresses)
    {
        string serviceType = 
            string.Format("{0}, {1}", constructorString,
            constructorString.Substring(0, constructorString.IndexOf(".")));

        Type t =Type.GetType(serviceType);
        
        ServiceHost host = new ServiceHost(t, baseAddresses);

        return host;
    }

    protected override ServiceHost CreateServiceHost(Type serviceType, Uri[] baseAddresses)
    {
        ServiceHost host = new ServiceHost(serviceType, baseAddresses);

        return host;
    }
}

When we do this we need to override both implementations of CreateServiceHost, which is the method IIS calls to create the runtime for you service. For both versions we get a service type and an array of base addresses. The only real difference between the two is that the version that takes the string as the first argument is taking the service type information as a string as opposed to a .NET Type. It's an easy matter to take this string and create an instance of a Type object, in which case we can refactor the code to this:

public class MyCustomHost : ServiceHostFactory
{
    public override ServiceHostBase CreateServiceHost(string constructorString, Uri[] baseAddresses)
    {
        string serviceType = 
            string.Format("{0}, {1}", constructorString,
            constructorString.Substring(0, constructorString.IndexOf(".")));

        Type t =Type.GetType(serviceType);
        
        return this.CreateServiceHost(t, baseAddresses);
    }

    protected override ServiceHost CreateServiceHost(Type serviceType, Uri[] baseAddresses)
    {
        ServiceHost host = new ServiceHost(serviceType, baseAddresses);

        return host;
    }
}

I think this is a better way to handle this as you are able to keep all the specialized host creation logic to the second method. For example, lets add the events from the first example:

public class MyCustomHost : ServiceHostFactory
{
    public override ServiceHostBase CreateServiceHost(string constructorString, Uri[] baseAddresses)
    {
        string serviceType = 
            string.Format("{0}, {1}", constructorString,
            constructorString.Substring(0, constructorString.IndexOf(".")));

        Type t =Type.GetType(serviceType);
        
        return this.CreateServiceHost(t, baseAddresses);
    }

    protected override ServiceHost CreateServiceHost(Type serviceType, Uri[] baseAddresses)
    {
        ServiceHost host = new ServiceHost(serviceType, baseAddresses);

        host.Opening += host_Opening;
        host.Opened += host_Opened;
        host.Faulted += host_Faulted;
        return host;
    }

    void host_Faulted(object sender, EventArgs e)
    {
        // Some logic...
    }

    void host_Opened(object sender, EventArgs e)
    {
        // Some logic...
    }

    void host_Opening(object sender, EventArgs e)
    {
        // Some logic...
    }
}

See, nothing to it!

All that's left is hook this up to our SVC file.

Unfortunately in Visual Studio 2008 it can be a little difficult to edit the SVC file. Double clicking it brings up the code behind file and not the SVC file. To get to that file, right click the file in the Solution Explorer and select "Open with..." Select "XML Editor" from the list and you should see something that looks like this:

<%@ ServiceHost Language="C#" Debug="true" Service="CustomHostExample.Service1" CodeBehind="Service1.svc.cs" %>

To add our service host, we just add a Factory attribute that identifies our service host:

<%@ ServiceHost Language="C#" Debug="true" Service="CustomHostExample.Service1" 
    CodeBehind="Service1.svc.cs" Factory="CustomHostExample.MyCustomHost" %>

Save the SVC file and that's it! You just customized your IIS runtime environment for you WCF service.

It's Your Fault!

James Bender — Thu, 17 Apr 2008 23:52:06 GMT

In talking to people about WCF, I've noticed that a lot of people, new to WCF and not, have not realized that WCF has the ability to send rich fault information back to the client by using a Fault Contract. It's very easy. In fact, you can do it in four steps...

Step 1: Admit your faults

The first thing we need to do is determine what kind of information we want to return back to the client and create a data contract that contains that information. You may have several kinds of fault classes, and you should so that you can return specific types of information for specific faults. Kinda like why there isn't just one Exception class in .NET. Although these are data contracts, you should not use them for anything other than sending faults back to the client. Here's a sample fault class:

[DataContract]
    public class MyFault
    {
        private string _message = string.Empty;

        public MyFault(string message)
        {
            _message = message;
        }

        [DataMember]
        public string Message
        {
            get
            {
                return _message;
            }
            set
            {
                _message = value;
            }
        }
    }

Like any .NET class, you can create a fault class the inherits from another .NET class, BUT that class also needs to be a data contract and be a known type.

Step 2: Find where you may go wrong

Next, we need to let WCF know where these faults might be coming from. This is done at the operation in the service contract. You simply use a FaultContract attribute which lets WCF know what kind of possible fault class to expect:

[ServiceContract]
public interface IFaultyService
{
    [OperationContract]
    [FaultContract(typeof(MyFault))]
    void ThrowMeAnError();
}

You can specify as many faults for the operation as you like, simply add more FaultContract attributes:

[ServiceContract]
public interface IFaultyService
{
    [OperationContract]
    [FaultContract(typeof(MyFault))]
    [FaultContract(typeof(MyOtherFault))]
    [FaultContract(typeof(YetAnotherFault))]
    void ThrowMeAnError();
}

Step 3: The throw...

Throwing faults from a service is a little different than throwing them from C# or VB code. We need to enclose our fault class in a FaultException<T>, which represents a SOAP exception. This is just as easy as the other steps:

throw new FaultException<MyFault>(new MyFault("This is a fault"), "Demonstration");

The second argument, in this case "Demonstration" is the reason for the fault. And yes, "reason" is the attribute name of the fault too. This can either be a string or a FaultReason object which allows you to send more detailed information about the exception.

Step 4: ... and the catch

If you've done everything correctly, when you generate a reference to your service, in addition to the normal proxy information, you should have a class representing the data contract you created for your fault class. Catching this exception on the client side is similar to throwing it on the server side. It will come wrapped in a FaultException<T> and you will need to specify that to catch it correctly:

.
.
.
catch(FaultException<MyFault> itsMyFault)
{
    Console.WriteLine("MyFault was caught");
    Console.WriteLine(string.Format(@"Message: {0}", itsMyFault.Detail.Message));
    Console.WriteLine(string.Format(@"Reason: {0}", itsMyFault.Reason));
}
.
.
.

As you can see, getting the reason is pretty straight forward. Our message, and any other field me might have added, will be accessible as a member of the Detail child object of our fault.

That's it. See, nothing to it.

Actually, this rabbit hole does go a little deeper, but this should be enough to get you all started with capturing rich error information from your services.

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 Four

James Bender — Wed, 02 Apr 2008 17:27:57 GMT

Over the past month or so I've demonstrated how to create a custom behavior for WCF. I explained how behaviors fit into the WCF stack, created one based on the Message Dispatcher and then added it to the service via the configuration file.

The last piece is enabling our behavior to take property information from the configuration file.

Currently, our behavior intercepts the output message a replaces it with some text that has been hard coded into the behavior class. This is great, but how often do we hard code data like that in the code and never have to change it? That's right; almost never.

The plan then is to make some alteration so our behavior so that it can accept the message to insert from our configuration file:

<CustomBehaviorElement customMessage="This is a test message"/>

In part three I changed our class to implement the BehaviorExtensionElement so that it could be added to the service runtime via configuration. I did this for the sake of simplicity, but in general this is not a good idea. You will want to keep the behavior logic separate from the logic that allows it to be managed via the configuration. You'll see why in a few minutes.

This also gives me an opportunity to back up a little and explain what BehaviorExtensionElement does. Last time when we set up the behavior to be added via configuration, we changed the class to inherit from BehaviorExtensionElement and we referenced the behavior in the configuration like such (remember, the "type" information has to be on one line, no breaks please):

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

The WCF runtime looked in the behavior assembly for a class that derives from BehaviorExtensionElement named MyCustomMessageFormatter. This trick is, it doesn't necessarily expect that class to be the behavior. It merely expects the class to know how to create the behavior.

This abstraction presents us with some interesting possibilities. For example, with the behavior code in a separate class we have the ability to influence how the behavior is created in different circumstances by creating different classes that implement BehaviorExtensionElement.

Some key benefits of this separation of duties is the ability to pass runtime information to the behavior via the configuration and to control how the actual behavior class is created.

The first step in making our change is to add a member variable to hold the message we are going to be sending. Simply stated....

private string _message;

The next step is creating (or if you already have one, changing) the constructor for the behavior class (MyCustomMessageFormatter) to take a string from the config, which just so happens to be our message:

public MyCustomMessageFormatter(string serviceMessage)
            : base()
        {
            this._message = serviceMessage;
        }

You can have any initialization code in this constructor you want. Need four different parameters for your constructor? Not a problem. Want to make some database calls to perform initialization? You can do that too. Want to delegate to some other class or service? Just write the code.

A change also needs to be made to the actual code that inserts the new message. Instead of using the hard coded message, it will now use the value that is being passed in to the constructor:

xmlDictionary.WriteString(this._message);

Now we have to make a new class that derives from BehaviorExtensionElement. We'll go ahead and call this BehaviorExtensionElementSample. Once we've done that we need to change the behavior class (MyCustomMessageFormatter) and remove it's inheritance reference to this class. In doing this, we will need to move the BehaviorType property and the CreateBehavior method we previously created in out behavior to the new class:

class BehaviorExtensionElementSample : BehaviorExtensionElement
{
    public override Type BehaviorType
    {
        get 
        {
            return typeof(MyCustomMessageFormatter);
        }
    }

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

As you can see, a change was also made to the CreateBehavior method that calls the constructor of the Behavior class. It's going to pass in a string that will be the message text from the config file. But it doesn't even need to do that. You have a lot of flexibility at this point in what kind of behavior gets created. For example, you could use the incoming configuration information to determine what kind of behavior to create (Strategy pattern anyone?) including not creating a behavior at all.

Again, the WCF runtime doesn't necessarily expect the class that inherits from BehaviorExtensionElement to provide the behavior logic, but it does expect it to be able to handle the creation of the behavior.

So now that we know how the information gets from BehaviorExtensionElement to our behavior class, how does the information get from the config file to the BehaviorExtensionElement?

To answer that, we need to learn a little bit about some of the classes in the System.Configuration namespace. Specifically ConfigurationProperty and ConfigurationPropertyCollection.

To our BehaviorExtensionElementSample, we add the following:

private ConfigurationPropertyCollection _prop = null;

protected override System.Configuration.ConfigurationPropertyCollection Properties
{
    get
    {
        if (this._prop == null)
        {
            this._prop = new System.Configuration.ConfigurationPropertyCollection();
            this._prop.Add(new System.Configuration.ConfigurationProperty("customMessage", typeof(string), 
                "Default Message", System.Configuration.ConfigurationPropertyOptions.IsRequired));
        }
        return this._prop;
    }
}

A ConfigurationProperty is an abstraction of configuration information, like the kind we have in our config files. It stores the value along with various meta-data like type, default value, type conversion rules and a description of the property. The ConfigurationProperyCollection is (surprise!) a collection of these ConfigurationProperty objects. By adding this code, we are overriding the implementation in ConfigurationElement, which BehaviorExtensionElement inherits from.

So, in the code above our class derived from BehaviorExtensionElement creates a private instance of the ConfigurationPropertyCollection and exposes a protected property called "Properties." Within our override of "Properties" we need to create ConfigurationProperty elements for out custom attributes. We only have one, the "customMessage" so that's all we are creating here. A base class will call this property on our implementation, and over write it's instance of the ConfigurationProperyCollection with ours.

Now that we've got to get our custom message in and out of our BehaviorExtensionElement. We add this code to our BehaviorExtensionElementSample:

[System.Configuration.ConfigurationProperty("customMessage", DefaultValue = "Default message.",
    IsRequired = true)]
public string CustomMessage
{
    get
    {
        return (string)base["customMessage"];               
    }
    set
    {
        base["customMessage"] = value;
    }
}

The first thing you'll notice is the ConfigurationProperty attribute. This mirrors the information we used to create our ConfigurationProperty element for our ConfigurationPropertyCollection above. You'll notice the name "customMessage" is the same identifier that we used to identify our value in the config file. This is very important because it tells the WCF runtime how to map the information from the config file to a property on our class. When the runtime collects the configuration information from the config file and creates an instance of our extension element, it will populate all of our properties automatically for us.

The rest of this is pretty simple "store a value, return a value" type code; storing the incoming value in the ConfigurationPropertyCollection we created ("Properties" is our base classes default indexer property) and returning a value (in our case, cast to a string).

So, to tie all this fun configuration stuff back into our behavior, the code that actually creates the behavior class:

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

Passes in our message to our behavior:

private string _message;

public MyCustomMessageFormatter(string serviceMessage)
    : base()
{
    this._message = serviceMessage;
}

Which in turn, injects it into our outgoing message:

xmlDictionary.WriteString(this._message);

See! It was, uh... easy? :)

In reality, this may seem complicated for something as simple as passing an initialization value into a class. But when you think about it, WCF is a communications framework whose mission to support flexibility and extensibility. The leveraging of the ConfigurationElement and ConfigurationProperty classes allows us to leverage existing functionality in the .NET framework and the separation of duties between our behavior code and the BehaviorExtensionElement class gives us complete control over how things happen in the runtime. At any point along the way we had the ability to examine what is going on and customize our functionality based on any number of conditions. As complex as this may seem (and once you do a few, it's actually not too tough) I promise it's easier than trying to achieve this same level of configurable customization in ASMX or .NET Remoting!

Over the next few months I'll post some content on how to create/use the other types of behaviors. For now feel free to download and play with the code.

See ya 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...