Development

Working with WCF: Part One: Introduction and Your First Service

James Bender — Sat, 06 Mar 2010 12:52:14 GMT

I’ve been playing with WCF since .NET 3 came out. Sometimes I have to be reminded that not everybody is as familiar with all it’s “cob-webby corners” as I am. And that’s OK. Often (too often) I encounter someone who has NEVER used WCF and doesn’t even know where to begin.That’s not so OK.

Usually I encounter these poor souls right when they need to be able to create or deal with WCF services NOW! Since it’s generally too late for them to attend my “Getting Started with WCF” talk by this time, and I can’t always drop what I’m doing to help them, I’ll be devoting several posts to the basics of WCF. While these posts are created with the new user (no previous WCF experience) in mind, even seasoned users may get something out of these posts.

The first post will cover creating your first service. Future posts will demonstrate the various ways to consume services, custom messages, what behaviors are, transports, what channels are, REST vs. SOAP and how to create a REST service in WCF, deployment, what’s coming in .NET 4.0, some entry-level RIA service work and all sorts of other WCF goodness.

Every Journey Begins With yada yada yada…

As mentioned, this post will take you through creating your first service. In this series I will be using Visual Studio 2010 (currently using Beta 2) with the .NET 3.5. You do NOT need VS 2010 for this example, VS 2008 will work fine. At some point I will dedicate a post to what’s new in .NET 4, and having Visual Studio 2010 will be necessary if you want to follow along.

We’ll be creating a simple service and hosting it in the test WCF Server that ships with Visual Studio. In the next post we will create a console application to host our service. Hosting in IIS is a deep topic, and will be covered in a future post. Remember, when starting Visual Studio you will need to run it as an administrator. For information on how to do this, see this post by Jeff Blankenburg.

Away We Go…

In our example we are going to be building a serviced based front end for an internet-based bakery called Web Bagels.

Open the dialog in Visual Studio to create a new project. Open the C# node and select the WCF sub-node.You’ll see a list of available WCF projects. We are going to create a WCF Service Library and call it WebBagels. The resulting dialog should look something like this:

Although we are going to be doing these demos in C# you can easily accomplish the same thing in VB.NET.

Click OK and wait for Visual Studio to perform its magic. When it’s done you’ll have what appears to be a normal class library with a few files in it:

The files IService1.cs and Service1.cs are sample WCF files. Feel free to open them up and look through them if you like, but we’re not going to use them for the demo, so delete them when you’re finished. Unlike most class libraries, this one has an app.config file. We’re going to need this, so make sure you keep it around.

The next step is to create a file for our service. Create a C# class file called BagelOrderService. Your solutions should look like this:

Our First Actual WCF Stuff

The first service we’re going to create is a simple service to allow users to submit bagel orders. They’ll tell us how many dozen bagels they want and what flavor.

WCF services are simple classes; they have public methods that generally take arguments (but don’t have to), do some work and may or may not return values. The difference between WCF services and plain objects is that we must tell WCF that the methods of this class are going to be accessed externally via a channel (Http, TCP, MSMQ, etc.) that is going to send a message to the class to execute an action.

So how do we do this? Turns out with WCF it’s very easy.

The first step is to create an interface that defines our bagel ordering method:

Now I know what some of you are probably saying: “[gasp] He put the interface in the same file as the class! HERETIC!”

Relax. This is a demo. They are in the same file ~~because I am lazy~~ for the sake of clarity. In reality I would not put interfaces for WCF services in the same file as the service. That’s not to say I never put interfaces and classes in the same file, but that’s another post.

Let go ahead and implement our interface in our BagelOrderService class:

We now have a class that will take bagel orders and return an order number! OK, it’s not actually doing that much. But it’s enough to get us going. We’ll be building this service out over the course of this series.

To turn it into a WCF service we need to identify it to the .NET framework as a WCF service. This is done using the ServiceContact and OperationContract attributes:

Notice the new using statement at the top of the class. ServiceContract and OperationContract reside in the System.ServiceModel assembly. Visual Studio was kind enough to include a reference to this assembly for us when we told it we were creating WCF services. If we hadn’t we’d have had to add the reference manually.

ServiceContract identifies the interface as being an interface for a service. When you run a hosting application (one you write or IIS) the .NET runtime knows to look at this interface and build a service mechanism around it. You can set specific attributes about your service here like namespace and session mode as arguments to the ServiceContract attribute. We’ll cover this in a later post, for now the defaults will be find.

For the most part WCF operates on an “opt-in” model, meaning that just identifying a class of interface as being a WCF object (via the ServiceContact attribute) doesn’t mean that the individual methods or properties are going to be recognized and used by WCF. This can be contrasted with the .NET XML serializer which is an “opt-out” model, meaning that if you decorate a class with the Serializable attribute, all the public properties will be serialized. If you want properties to be ignored you must specify which ones to ignore.

OperationContract is the attribute we use to identify which methods in our interface we want to be exposed as actions on our service. Like ServiceContract there are a variety of attributes we can specify about the action that will be exposed on the service like action name and if the call is a one-way action.

One thing to note, you don’t have to use an interface here. You could add the ServiceContract and OperationContract to your class and things would work just fine. But don’t do this. Tieing your service implementation, or any “service based” class to a concrete implementation is never a good idea.

Actions are basically the service equivalent of methods. More on those in a later post.

It Wouldn’t Be .NET Without a Configuration File…

… and WCF is no exception.

Remember when I said we were going to hold on to that app.config file? Good, because now is when we need it. Open it in Visual Studio. It should look something like this:

There is A LOT of stuff to cover in this file. Today we’re just going to worry about the bare necessities to the our service up and running. The first step is to make sure this configuration file is actually using our service. Find this line in the configuration file:

This is the node in our configuration that tells WCF which concrete implementation of our service we are going to be using. In our case it’s the BagelOrderService class. Change this line to look like this:

We’re almost done! All that’s left is to let WCF know where our service contact is. That’s done by change the contact attribute of our endpoint. The endpoint for our service should like something like this:

We just need to change the contact attribute to point to our service contract:

We’re ready to test!

Let’s Light This Candle

Our WCF class library is a little different than an traditional Visual Studio class library. Normally when you try to debug a class library in Visual Studio you’re given a “gentle reminder” that you can’t actually run libraries. Our WCF library is special though. In order to ease development and testing of WCF services Microsoft has included a small testing service host (think of it as Cassini for services) and a test client. Press F5 in Visual Studio to start debugging. Your solution will compile and Visual Studio will start the test host for you:

This may take a few moment, especially the first time you run the service. Once the service is up and running you’ll be presented with the WCF test client:

On the left side we have a tree view which represents our service. Currently we only have one method (PlaceOrder) in our service, so we only have the one node under our interface. Double click on that node and the right section of the window should present you with a data entry screen to test our service with:

Let’s try it go head and enter some data in the “Value” fields for both arguments and press the Invoke button. It may take several seconds the first time, but you should see a result similar to this:

There are a few more goodies hidden in this test client which we’ll explore in a future post.

Congratulations, you just created a WCF service!

In the next post I’ll explain more about the configuration file and show you how to create a console application to host your new service.

Code on!

Make your investment count

James Bender — Sun, 02 Aug 2009 14:05:05 GMT

I recently had a conversation with a friend and fellow developer who was very excited. His company recently welcomed a new CIO to the organization, who had some, comparatively, progressive idea. One of his first actions was to increase IT development spending by several million dollars to tackle some projects that had had to be put off over the past few years, including renovating several applications that we’re quite performing up to expectations.

Unfortunately, while the CIO’s spirit was in the right place it became clear that his money was not.

The various development groups began developing applications the way they had always done, but made no effort to update their tools, techniques or practices. Instead of spending part of their substantial investment to introduce things like Agile methodologies, Test Driven Development, Web Standards, Source Control policies or automated builds, they proceeded to develop a whole new collection of applications like they had been developing them for years.

The group knew that these old practices had led them to a lot of pain in the past and needed to be revamped. But the organization placed value on raw lines of code and not the quality of what was being produced. As a result, those applications that needed “renovation” were simply ported from .NET 2.0 (and in some cases 1.1) to 3.5. Management was surprised when “upgrading” these applications did not result in large performance and stability increases.

Making a lot of changes to the way we work as developers can be scary. There’s a lot to learn, it seems complicated at the start, and no one wants to risk looking stupid. But it’s also important for us as individuals and software development in general to be willing to examine and investigate new techniques and tools that will make it easier to develop higher-quality code more efficiently. Keeping an open mind will unlock a lot of doors to improvement.

Companies need to understand that their code is an asset just like a building, vehicle fleet or piece of manufacturing equipment. You wouldn’t dream of letting those things fall into disrepair, so why are companies OK with their code base rot? When making an investment in IT, it’s important to understand where that money is going, and what it’s going to buy you in the long run. If you have a code base of dubious quality and pay for large teams to simply “plough ahead” you will just end up with a larger base of low quality code.

2009 Columbus Give Camp is in the books…

James Bender — Tue, 21 Jul 2009 18:50:54 GMT

… and it was a tremendous experience!

The goal of a Give Camp is to unite non-profits that need technical assistance, be it a new web site, help with a CRM or making changes to an existing line of business application with passionate geeks in the area who are willing to give a weekend to help these non-profits accomplish their goals.

This year, in Columbus, about 45 software professionals came together to help eight non-profits. The results were amazing. In about 48 hours, eight full scale applications were either completed, or nearly completed. Most starting from scratch. It was great to see the variety of technologies and talents in one place and one time. It was also great to see the results a small but committed team of developers could create in a short period of time. Truly amazing! I want to thank all the volunteers who came out to help. A weekend can be a big thing to give up, and the Give Camp organizers and non-profits are extremely thankful of your efforts.

I would also like to thank all the non-profits that participated. We had a great time getting together and learning from each other while helping you.

I would also like to thank our sponsors. Quick Solutions for providing us with a great workspace, and soda and coffee through the weekend. Discount ASP.NET for providing hosting for the non-profit applications. Tech Smith for providing funds and licenses of their amazing products. Telerik provided us with licenses for some of their products and swag. Microsoft for providing funds and swag. eRubycon for providing a free pass to eRubycon 2009. And The Sophic Group for sponsoring dinner on Saturday night. Please remember the support these sponsors provided.

I would like to single out two sponsors who went above and beyond for us: Potbelly and Pei Wei. One of the most difficult things about organizing an event that lasts all day is feeding people. When that even spans multiple days AND encourages participants to stay over-night, that task is even harder. Potbelly and Pei Wei made some of those meals a whole lot easier for us! Please remember them if you’re in the Polaris area at lunch or dinner time (Potbelly is here, Pei Wei is here)

See you all at Give Camp 2010!

If I Do A Good Job, Can We Go To Dietsch Brothers for Ice Cream After The Meeting?

James Bender — Sun, 26 Apr 2009 23:28:20 GMT

This Tuesday, April 28th, I’ll be speaking at the Findlay Area .NET User Group.

I’ll be presenting “How I Learned To Love Dependency Injection,” which if my .NET Kicks stats are to be believed, is turning out to be quite the popular talk. The meeting is at the Marathon Oil building in downtown Findlay.

I spoke at this group a couple of years ago and had a GREAT time. I’m excited to be going back!

Are YOU going to the Microsoft Developer Conference?

James Bender — Tue, 13 Jan 2009 16:44:55 GMT

And if not, why not?

The MDC (Microsoft Developer Conference) makes a stop in scenic Detroit, MI next Thursday, January 22nd. If you missed the PDC, or even if you didn’t this is a great event and a terrific opportunity to see what’s next in the .NET development stack.

In addition to getting your very own copy of the Windows 7 Beta (assuming your one of the last three people who haven’t already gotten the torrent) you’ll be able to see presentations on Azure, Silverlight, F#, ASP.NET with JQuery and SQL Data services by some great speakers like Brian, Jennifer, Jay, Jeff and Jason, other Jeff, Carey, Chris and yet another Jeff.

Damn, that’s a lot of Jeff’s.

And at $99 bucks, that’s only $33/Jeff!

But wait, there’s more!

Alan will be there running ~~Open Spaces~~ Community Courtyard, where you’ll be able submit your own topics and talk with some way-smart people.

There will also be a Women Build workshop, which despite the name is open to both women and men. Admittedly I don’t know too much about that except that Lego’s are involved, Based on that I’m guessing it’s pretty cool!

So if you haven’t, go register now and I hope to see you all there!

Thoughts on the WCF REST Starter Kit

James Bender — Tue, 23 Dec 2008 01:53:13 GMT

One of the announcements that was kinda missed at PDC was the release of the WCF REST Starter Kit. In brief, the REST Starter Kit provides a was for developers to “jump-start” the development of REST services in WCF.

The Premise

In .NET 3.0 WCF allowed developers to abstract the way a service communicates with the world from the way the functionality of the service was implemented. Developers designing services in a “contract first” manner were able to specify minimum requirement and rules for their services. Provided that the communication medium (transport and binding) was able to provide the service with the facilities that it needed, that service could be invoked via that medium. For example, a service could expose both HTTP based and TCP based endpoints without having to change the functionality of the service. In WCF there is not a concept of a “web service”: there are just services. Some are available via HTTP over the web.

WCF also provided developers with ways to customize and extend the way the service communicated and behaved at runtime via custom channels and custom behaviors.

What it didn’t do very well was provide a way for developers to easily create REST based services. But that changed with the release of .NET 3.5. Using the WebGet and WebInvoke attributes in the Service Contract gave developers a way to write REST services in WCF

The Problem

For all it’s power, configurability and extensibility WCF has always had a bit of an image problem. Most developers view it as difficult to work with, difficult to understand and tied to a obnoxiously verbose configuration model. The inclusion of REST abilities in 3.5 did nothing to help do away with this perception.

The Solution

Enter the WCF REST Starter Kit. The Starter Kit provides a set of templates for creating a variety of REST-based services including Singleton Services (exposing a single resource on the server), Collection Service (exposing a list of resources/data), POX Service and projects for ATOM feeds and ATOM publishing protocols. The starter kit also comes with a new assembly called Microsoft.ServiceModel.Web which contains an API the provides a lot of out-of-the box functionality to support REST services including customized help pages, customized caching, easier ways to return exceptions, URI templates, and the ability to use request and response headers.

The long and the short of it is that you select a project template based on what kind of service you want to write and then add the appropriate functionality to a few methods and bang, you’ve got a service.

The Good

The starter kit comes with templates for most kind of REST based services you will need to write. While a basic knowledge of REST and how routing works (if you’ve done any significant MVC work you’ll be fine) you can get a REST based service up and running in a matter of minutes with data represented as both XML and JSON. Little real WCF knowledge is required to simply get a service up and running.

The API extensions will offer something to those more experienced with WCF by providing a means to perform some customization without having to write a custom behavior or channel.

The Bad

It started with the install. Part of the starter kit is a bunch of Visual Studio content. The installer kept giving me a Null Reference Exception. I found a workaround here.

The classes created by the starter kit are designed for ease of implementation, not for extensibility. Customization involves a lot of friction. If you need to do anything beyond a basic REST implementation you will need to acquaint yourself with the object model that the starter kit uses, which can be a little overly complex. If you need to do complex routing or create a service to provide more than one data type you’ll need a level of knowledge about REST in WCF that the start kit is supposed to insulate you from.

Another issue I’ve encountered is that when I try to rename the Service.svc file in the project generated by the Starter Kit I get an “… operation not completed. Unspecified error.” error.

In the End

I’m in favor of a REST Starter Kit, or ANYTHING for that matter that increases adoption of WCF. I think the Starter Kit is a good late-beta/1.0 release, but it’s got a ways to got before I consider it a major part of my tool-box.

Code On!

Is WCF the Death of .NET?

James Bender — Tue, 04 Nov 2008 18:10:46 GMT

I had the good fortune to attend the PDC pre-conference and was able to attend a day-long WCF session with Juval Lowy and Ron Jacobs.

Juval went first and spoke for most of the day. Juval has been working closely with Microsoft for quite some time, and his COM(+) roots were showing big time. Essentially, Juval is of the opinion that WCF is a .NET killer and should be the way ALL applications are written from here on it.

As Juval has extensive expertise with COM, I think he tends to see everything in terms of that model, and he may have a point. As a result, he made the bold statement in the pre-conf session of referring to WCF as a .NET killer.

While I'm not prepared to follow Juval in claiming .NET dead at the hands of WCF, he makes some good points. If you think of the communication between objects in a system analogous to the communication of services in an architecture, WCF provides some cool abilities that the traditional model in .NET does not.

Services provide metadata about what they are and how to use them. .NET classes do not. WCF allows developers to provide a rich security model around their services. .NET classes have some security abilities, but they are based around determining if a user has specific permissions at runtime. WCF allows you to set timeouts for a service call. The service dies, your application goes on. Calling a method on a .NET class that dies means your entire app dies. WCF allows the way services communicate to be configured at runtime. Reflection makes that possible in .NET, but be ready to build lots of plumbing to implement this. MEF makes this WAY easier, but WCF still has it beat as an out-of-the-box solution. Want to distribute your components on multiple tiers? WCF inherently allows this. Heck, it's WCF's "thing." You can do this in .NET too, if you use WCF. There's more, but those are the big wins for most developers.

Yeah, WCF does offer some advantages. So much so that Juval claims that every class from here on out MUST be a service from now till the end of time.

So why hasn't the development world fallen in line?

WCF offers metadata about it's services and classes don't. True, but let's be honest; if .NET classes did offer that level of metadata how often would it really be used? In most cases I've found having the class implement a contract is sufficient. Presumably, if good naming standards are used, I know what the class does and what methods are available to me. Security in services is great. Security is important. But let's face it; security slows systems down. I'm a big believer of checking security ACL's in every method call (ESPECIALLY if it's a web app!) but that call is relatively cheap compared to how the comparable model in WCF security is implemented. The configuration stuff could be very useful, but one of the biggest complaints I hear about WCF is that the configuration, even with the WCF configuration tool, is difficult and generally a pain to deal with. And any facility to do this with .NET classes would be just as painful.

And let's not forget the two biggest dings

Performance. A WCF call with the named pipes binding can be VERY fast. But it's still not going to beat inter-process call to an object in the same app domain. Sure, not by much and it would be almost imperceptible to the user, but it's there. Add that to the up-front time needed to spin up a service host and establish connections (especially if security is being used) and it's definitely something to think about.
Complexity. One of the biggest obstacles to widespread WCF adoption is that it's still perceived as a more complex solution to ASMX web services and .NET Remoting. To be sure, WCF gives you an abundance of options. But having too many options can make things more confusing. And have you ever seen a production WCF configuration file? It's ugly! No argument there.

I don't know which is better. This is because I've never actually built an application the way Juval suggests. But I'm curious to see what an application built in the manner would look like. It goes without saying that it would be designed and developed very differently from the traditional .NET applications we all use today. For every design consideration I can think of sitting here writing this, there are several more that haven't occurred to me yet. In the end the adage holds true: You don't know what you don't know.

So my plan is to pit both of these approaches against each other and see what happens. Over the course of the next few weeks, as time allows, I'm going to write the same application twice. Once as a traditional .NET application and again using the approach Juval is advocating. Here are the ground rules:

This will be a simple application. It will not necessarily mirror and real-life business case. It's sole purpose is to demonstrate each architectural approach in a variety of everyday business situations. That's right, I'm living many a developers dream; using technology for the sake of using technology. Mmmmmm...... self-indulgence....

Both applications will be developed using TDD to the extent that my TDD chops allow. In addition to improving my TDD chops, using the same unit and UAT test for each application will help ensure parity. Each application must pass ALL tests to ensure that each is delivering the same features. I will be the primary tester, but if anyone would like to volunteer help out that would be great!

Each application will have a standard UI tier (WPF), business tier and data store. Additionally, each application will utilize one service within the application that will mimic and internal Enterprise service and one publicly available web service (TBD)

I'll be posting my progress as I go. Please feel free to add any suggestions or ask any questions in the comments section

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