I’m aware that there are quite a few examples already for how to implement and consume services using WCF in Visual Studio 2008. However, I’d like to provide a slightly different example by providing some additional aspects that you may want to consider for commercial deployments. This includes propagating error conditions and system design aspects, all using the same running example. At times this will certainly stretch the blog format somehow and I may provide a more detailed documentation in a different format.
Enough talk. Let’s get something done!
WCF (Windows Communication Foundation) is a very powerful part of the Microsoft .NET framework. In this post I will show you how to implement a very simple service. And as a running example I’ll use ducks. So the service will be called PondService where ducks can feed. As a tool I’ll use Visual Studio 2008 augmented with ReSharper and AnkhSVN. ReSharper (commercial) is a very powerful tool for refactoring (has some limitation in certain scenarios, e.g. memory consumption) while AnkhSVN (free, open-source) is an extremely helpful plug-in and client for Subversion.
Creating The Solution
As a first step I need an empty solution, which I’ll call RubberDuck. Here’s the recipe:
- From the menu select “File” - “New” - “Project…”
- In the tree on the left expand “Other Project Types”
- Select “Visual Studio Solutions”, then on the right “Blank Solution”
- Enter “RubberDuck”
Here is what it should look like:
Click “OK”.
Add the Service Library
Next, I’ll add a service library to the solution. We’ll call it DuckServiceLibrary. Here’s the recipe:
- In the “Add New Project” dialog in the tree on the left select “Visual C#” then “WCF”.
- Then select “WCF Service Library” on the right.
- As a name enter “DuckServiceLibrary”.
At this stage the dialog should look as follows:
After I click OK the solution looks as follows:
Next we’ll add the PondService to the new service library. For this step you need to be aware that there are (at least) two items that look as if they are a fit: “Windows Service” and “WCF Service”. The former would be an old-style web service which technically would work. However, we choose “WCF Service” in the “Add New Item” dialog box. Here is how the dialog looks before I click “Add”:
The solution still contains IService1.cs and Service1.cs which were generated when I added the service library. I simply delete them. However, there is more cleanup work required. The DuckServiceLibrary contains a file named “app.config”. Of course I could go in and just delete the entries for Service1. However, there is a second option: The Microsoft Service Configuration Editor. You can launch it from the context menu on “app.config”:
There are two places in the Service Configuration Editor (SCE) where I’ll remove the configuration entries for Service1. First there is the Service1 and there is the Service1Behavior:
Delete the two highlighted nodes. Then make sure you client “Save” before exiting. While I’m comfortable to edit XML files I prefer the SCE since it is harder to accidentally delete items you still need.
The Actual Service Implementation
With all of this in place (just takes a couple of minutes, once you get used to it), I’m now in a position to define the interface I’d like the service to have. To stay with the running example the duck would like to know whether a particular pond is currently frozen or not. During winter a frozen pond doesn’t really help finding food. After removing all unused using’s (ReSharper function) the service interface looks as follows:
1 using System.ServiceModel;
2
3 namespace DuckServiceLibrary {
4 [ServiceContract]
5 public interface IPondService {
6 [OperationContract]
7 bool IsFrozen(string pondName);
8 }
9 }
The implementation is even simpler. Using the “fake it ‘till you make it” I simply return true. Of course real ducks wouldn’t like that service level so you probably want to offer something more substantial!
1 namespace DuckServiceLibrary {
2 public class PondService : IPondService {
3 #region Implementation of IPondService
4
5 public bool IsFrozen(string pondName) {
6 return true;
7 }
8
9 #endregion
10 }
11 }
By convention I’ve surrounded the service implementation with a region. In this example it doesn’t make a big difference but once a class becomes larger then it pays off to use a region per interface implementation.
Trying Out the Service
Although I haven’t implemented a client I can still try out what I have so far. Hit F5 and Visual Studio will compile the service library and launch a WcfServiceHost that host the service. It will also launch a WCF Test Client with the PondService added to it already:
To try the service out I double click on the “IsFrozen()” operation. The WCF Test Client will open a tab in the right hand pane into which I can enter a pond name as follows:
Next I click the Invoke button and I get the response from the service. I can verify the response in the lower right part of the WCF Test Client window:
By the looks of it we didn’t make a mistake with our implementation: The Clearwater Lake is frozen.
So this is it for this post. In subsequent posts I’ll cover:
- How to implement a WCF client?
- How to exchange data between server and client?
- How to propagate error conditions?
- Others
Stay tuned!
