Introduction

I’m impressed! And that’s not an easy thing to do. I’ve been playing with the CTP (February 2006) release for a while now, and believe it or not, I think we may actually have something here. I have not had the time to explore the other ‘Foundation’ members (of WinFX), but from what I’ve seen of the Windows Communication Foundation (WCF), it really is a very nice package. Yes, I know that each time there is a new technology released, there is always some neat features. But in the past, I always thought that we were paying more (in complexity) than what we were getting (in functionality), can you spell COM? This time, it feels like we are getting the whole thing for free. It’s possible that it may be just my naïve perspective, but hey it’s all about me anyway.

I like to preface my articles with a disclaimer. The content in this article is simply my impressions and interpretation, and it should be read in that context. Even though the prose may at times seem like I know what I’m talking about, any similarity to actual facts may simply be coincidence. Enjoy the journey.

Why can’t we just talk?

The minute we stepped out of the DOS box, we realized that we were not alone any more, and we needed to learn to get along and communicate with the other inhabitants of the virtual world. DDE, OLE, COM, DCOM, and Remoting have been some of the attempts at providing mechanisms for two applications to be able to talk to each other. Remember how OLE and COM were described when first introduced? As the ‘foundation for all future products’. With hindsight, we can see that they were really just baby steps. Each one solved only a small part of the whole problem. So if they were baby steps, then WCF is certainly a giant leap. WCF provides a complete solution to the communication problem. And it does it with elegance and simplicity. Can you tell that I’m just a little enthusiastic?

Whether your requirement is to communicate with another module on the same machine, or another module implemented in a different language, or you need to communicate with a module that’s on a machine on the other side of the world, or you want to communicate with a module running on a different platform, or even communicate with a module that’s not even running!, yup, you can do it under WCF.

In my opinion, the beauty of WCF is that it is an ‘all-inclusive’ solution. It is the first one to provide a complete end-to-end solution covering the scope and depth of the problem. It is also the simplest from a programmer's point of view; you are always just making a method call. Yeah, I am sure that there is quite a bit of magic going on under the covers to support that simplicity of use.

Now, I have not explored every nook and cranny, or option, or possibility, but from what I’ve seen, it’s an excellent solution. At least for me, and as I said before…

What is a service?

Let’s see how much trouble I can get myself into here. I think that, in its most elemental form, a service is simply some functionality (code) running in some external process that is made available to other processes in a standard way. That’s pretty much the crux of it, except that in a standard way also encompasses platform and language neutrality.

So, by the above definition, a service really has two parts. First is the code that must be running somewhere in order to provide some functionality to clients. And second, there must be some generic mechanism that can be used by any process, regardless of the platform, language, or locality, that makes the service accessible. That generic mechanism has turned out to be XML and SOAP. Of course, there are some additional facilities required in order for a client to be able to know (or discover) what functionality the service makes available. But I think of those as supporting technologies.

There is also some glue that is required in order to tie the two parts of a service together. That glue is the code that will support the communication medium (transport) that is being used by the service and the client to talk to each other. Being lazy…I mean smart, we’ve come up with some generic glue also. This way, each service implementation does not have to re-invent the wheel. For Web Services, the generic glue is a Web Server. So, a Web Server provides a hosting environment for services that use HTTP as their transport mechanism. I would also like to suggest that Web Services are a special implementation of a service as defined above.

Here are the things that we will be examining in the rest of this article. How do you define a service? How do you implement a service? How do you host a service? How do you access and use a service? Once we have the basics nailed down, we’ll look at some of the more complex communication options that WCF facilitates.

So what is WCF?

Here is what WCF is for me:

WCF is an inter-application communication platform. It provides a common API that hides the underlying communication medium. It can be platform neutral, and it provides for locality indifference. Essentially, under WCF, I, as a programmer, do not need to know or care where the other end is or how the actual communication is taking place. To me, that is beautiful!

WCF is services based technology. It has, as its roots, Web Services, and thus XML and SOAP are its core technologies. WCF took the concept of Web Services and super-charged it. Much of the look and feel of WCF behaves like traditional Web Services. In fact, I like to think of WCF services as Web Services on steroids. You define WCF services much like Web Services. You can interrogate a known service for its methods with the same protocols that are available for Web Services. And you have very similar infrastructure requirements as are for Web Services. The main difference is that WCF has expanded the transports that are available to include TCP/IP, IPC (named pipes), and message queue-ing, in addition to HTTP. I think the focus of Web Services is to solve the interoperability problem, and the focus of WCF is to solve the much broader communication problem. And it has done this while still maintaining a uniform API as well providing more efficient mechanisms.

The most important feature from a developer perspective is that you don’t have to be concerned with what or how you are communicating. The code is the same, no matter what the final transport mechanism or locality of service might be.

Service Contracts-exposing functionality

Our WCF journey starts with how services define the functionality that they expose. Much of the infrastructure required to implement services under WCF is specified using declarative programming. That means, using attributes to specify functionality. The following shows how to declare an interface that will be exposed as a service:

The ServiceContract attribute specifies that the interface defines the functionality of a service. OperationContract is used to decorate each method that is to be exposed as part of the service. That is all that is required to create a WCF service. Just slightly more is required to actually deploy the service, which we’ll cover later on.

By the way, you don’t have to use interfaces when implementing a service, just like you don’t have to use an interface to define a class. You do have to specify what you want exposed through a service, explicitly. You can define anything else you want or need as part of the interface, but only methods, and only methods that get decorated with [OperationContract], will be exposed by the service.

Data Contracts-exposing data types

WCF also allows you to expose custom data types so that you are not restricted to simple data types of the CLR. These are simple structs with no methods associated with it. This can be a little confusing sometimes, because the same syntax is used for both services as well as for CLR definitions. Here’s an example of a DataContract that we will use.

DataContract specifies the data type that you are exposing and, DataMember specifies the members that are part of the data type. As is the case with ServiceContract, you have to explicitly declare which members are to be exposed to external clients, using DataMember. What that means is that you can include anything else that you may want (or need) as part of the class definition, but only the members decorated with DataMember will be visible to clients.

Coding options in WCF

As we saw above, one of the options available to specify functionality under WCF is to use attributes. Attributes are translated by the compiler to generate much of the infrastructure required by WCF in order for us to create and use services.

The second way you can specify many of the options is through configuration files. This allows you to make changes without having to re-compile. Many of the WCF classes will automatically use default values from the config file. Here’s an example of an endpoint specified using config data (endpoints will be described shortly). First, the config file, then the code statement referencing the config file data:

Finally, the third way of coding functionality is, of course, programmatically. Many of the things that you can do via attributes or config files can also be done programmatically. Here is the previous endpoint, defined programmatically:

Endpoints

Endpoints are the ‘identity’ of a service. They define all the information that we need in order to establish and communicate successfully with a service. Endpoints are made up of three pieces of information: Address, Binding, and Contract. The address is obviously the location of the service, such as ‘net.pipe://localhost/LocalTimeService’. The binding specifies security options, encoding options, and transport options, which means a lot of options! Luckily, there is a collection of pre-defined bindings provided with WCF that we can use to make our life simpler. And finally, the contract is the actual interface that the service implements.

Implementing a WCF Service

So, a service is nothing more than a regular class that gets decorated with some special attributes. The attributes are then translated by the compiler to generate the special infrastructure code required to expose the class as a service to the world. In the following code, we first define an interface that has one method that returns the local time of where the service has been deployed. The LocalTimeService class then implements the interface, and thus exposes the functionality to the world, or at least to whomever is interested.

That’s all that’s needed to create a WCF service. If you compile the above code into a DLL (a library), you will have created a service. Of course, there is a little more needed in order to have something that’s useable. We need two other pieces in order to complete the service. We need something that will be able to load the service DLL when a client requests the functionality of the service. And we need something that will be able to listen on a communication port, and look through everything that is being received to see if it matches what we are responsible for, our service contract.

Deploying a WCF Service

There are a number of ways to deploy our service. First, if we implement our service to support HTTP, then we could deploy our service just like a regular Web Service, using IIS. If we want to support some of the other transports, then we could deploy the service using Windows Activation Service (WAS), which is an enhancement available in IIS 7.0. If either of these is not suitable or we want more control over the service, then the other solution is to build our own hosting environment by using ServiceHost. ServiceHost is a class available in WCF to host services, almost like a mini IIS, just for our service. We can implement ServiceHost in any housing available under Windows, in a console app, a Windows executable, or a Windows service (formerly NT service).

ServiceHost will listen on whatever channel we specify for our service, using whatever protocol we specify, and call our service whenever a client request for our specific service comes in. That’s a lot of bang for just a couple of lines of code. All that we need to do is tell ServiceHost the endpoint that it is responsible for and the class that it should instantiate when a matching message is received. Here’s the code that’s required to host the LocalTimeService in a console app:

You can now compile the service. However, if you try to run it, you’ll get an error message indicating that you haven’t provided ServiceHost with an endpoint. As we saw above, you can specify endpoints either programmatically, or by using the configuration file. The nice thing about using configuration is that you can change it at any time and you don’t have to recompile. As we’ll see later, you can specify multiple endpoints for a service, depending on the clients that you want to support. And if at some point later, you decide to not support a specific transport, you just have to edit the configuration file.

Let’s examine the entries in the config file. You should note that there could be as many entries as needed. For example, there could be several endpoints that the service supports (different transports). There is also only one service being specified in this example, but there could be several services provided in the same housing. You can see that the endpoint has three properties: address, binding, and contract. The binding indicated is referencing the standard netNamedPipeBinding provided in WCF. There are various default binding classes provided for each transport. You can see the options for each in the docs.

I will say here that you too will encounter the “zero application (non-infrastructure) endpoints” exception at some point. There won’t be too many clues as to what exactly is not matching up, so you’ll have to scrutinize the text. Make sure that you have the correct namespaces specified.

Now you can execute the application, and the service will be available to any client that knows how to communicate with it.

Proxies

Just by saying we want to go to New York and we are going to go by car, does not get us there. We need a car to actually get us there. Having a completely defined endpoint is not enough. We need something (code) that will actually take the endpoint as a parameter and allow us to do what we want to do, call a method. And that something is a proxy.

As was the case in the past with COM, proxies take care of all the low level plumbing (serializing and packaging our parameters) so that we just need to make the call. We don’t care how they are forced through the ‘spigot’ or how they are pulled out on the other side.

And as we’ve also had in the past, there is a utility that will create the proxies for us. However, this is one area of WCF that needs some improvement. And I’m guessing this functionality will become incorporated into Visual Studio in future releases. At least, I would hope so. To create a proxy, you need to use the command line utility, svcutil, which has a number of switches that are not all or well documented. But hey, I’m not complaining, it’s a small inconvenience for a whole lot of major improvements. And it’s still only Beta.

So, you run svcutil against your service DLL and bam! You got your proxy class. There are other options, like if the service has a MEX endpoint, you can direct it to the service, and it will extract the service information dynamically from the service. This is essentially the same functionality provided through Studio when creating a Web Service, and we use the ‘Add Web Reference’ dialog. What I really want is for Visual Studio to automatically generate the proxies since it has all the information in the source files to begin with! But as I said, I’m not complaining. ;)

Currently then, creating the proxy is a two step process. First, you run svcutil against your service DLL, which will create the schema (XSD) and WSDL files. Then, you invoke svcutilagain, but this time, you run it against the output it just created (*.xsd, *.wsdl).

The svcutil will generate ‘output.cs’ as the default file name, unless you specify otherwise, I normally just rename it. There are also options to just generate DataContracts or just ServiceContracts, and also an option to generate a client config file. Here’s the proxy file for the LocalTimeService, with some portions edited for readability. There’s not much there, since all the magic occurs in ClientBase.

Consuming a WCF Service

So now, the next logical step is to build a client that knows how to consume the service that is being provided. The client code only needs two things: the proxy that allows it to communicate with the service, and the endpoint to the service. Here’s one version of a client that consumes the LocalTimeService:

Not much to this client. All that it's doing is making a call to the service method GetLocalTime(), once a second. As you can see, the client code has no indication as to what or where the other end of the method call is. Nor what mechanism is actually being used to make the connection. It is just a simple class method call! As we look at other examples, you'll keep seeing the simplicity of coding that is provided under WCF. And here is the config file that specifies the endpoint to the service which is required by the client.

Compile and run the client. Start several instances. Just make sure that the service is started before you start the clients, otherwise nobody will be listening.

That’s it for the basics in getting services listening and consuming services. In Part 2, we'll build some examples that will demonstrate WCF's support for the various communication patterns. The download includes all of the source code for the sample applications described in the articles.

I read your article its very much comperhensive,but since I am new to WCF just strated today I have a question that how we can actually used WCF over LAN , for e.g we made one service name MathService and selfhost it ,now I wnat the clinet to run on different PC on LAN, how can I add namespaces to the client because service resides on ifferen machine or just simply svcutil.exe will takecare of namesapce and required dlls and one more question do I have to use sockets on client side or wcf provides any othr tchnique

Please read all three articles in the series and it will start to make sense. All you'll need to do is specify the service endpoint in the config file for the client. Build and run the sample code with variations, that's the best way to learn. Good luck.

Hi, I used the temperature sensor example and moved the client to a Form Window where I can subscribe and unsubscribe to the service with buttons and I observed this problem:

I let the client run for a longer time (half or full hour) to receive temperature data and once in a while I un-subscribe and then subscribe again to the service during that time. If this goes on long enough then I get always a timeout exception upon un-subscribing:

"This request operation sent to net....did not receive a reply within the configured timeout (00:01:00). ..."

I use VS2008 and I reduced the Temperature Simulator sleep time to Thread.Sleep(100) to move more data. Happens with Tcp or namedPipe binding.

There's one thing you need to keep track of which I found out the hard way. There is a default timeout for a connection of I think 10 minutes. This is not the 1 minute reply timeout, it is an inactivity timeout. It is best to create connections and release them. I had a process that sometimes would take a long time and of course I did not release the connection until it completed. Since this occurred randomly and there were hundreds of threads running simulataneously it took a little work to discover it. What happens is that after that timeout (with no activity) the system terminates the connection and then when you try to communicate again you'll get the 1 minute timeout. Good luck, I hope this is what you were experiencing since it will be easy to fix.

I think that when I moved the client console to a Windows Form I encountered the issue of a possible deadlock. Just using the attribute setting:[CallbackBehavior(UseSynchronizationContext = false)]stopped the timeout exception.

The articles/links above have some further comments and considerations.

Hi, In WServices with .net you can throw a SoapException and the communication channel with WS stands OK, but in WCF when you throw an Exception the channels changes its state and do not allow more operations.

The exception: The communication object, System.ServiceModel.Channels.ServiceChannel, cannot be used for communication because it is in the Faulted state.

I wrote a subsequent article to this one which you may find useful 'Debugging WCF Apps'. What is the source of the exception? What is the connection type your using in WCF? One thing I found out the hard way is that are also timeout exceptions. Each connection type will have different 'behavior', which one to use will depend on what your application requirements might be.

Please share your thoughts and experience on the subject.Essentially the application of WCF/WPF in Industrial automation and SAN domain. Share the case studies if you can if you have implemented for any client and commercial applications.

Let me tell you my problem first after that you tell me whether I should go over WCF or not?

See I am creating a new process from windows service when client application invoke it. I could do this successfully if my service is running under system account interactively and its displays all the windows (like notepad,services.msc everything) but if I make service to run as domain\user account then I could run all script,batch progs etc but not interactive processes. So in this case notepad window does not appearing while client invoke notepad.exe even though in task manager it is showing process is running.I found that Microsoft providing interactive window station only for system account and this is the reason its happening like this. So basically my purpose is to create interactive window station in non-system account.

I found something like GetWindowStation and SetWindowStation. Do you think so I could achieve this thing by these functions. At present I am digging all these functions.Ig you have any idea regarding this then it will be really helpful to me.

// This is a start of addition // A channel to describe the service. Used with the proxy scvutil.exe tool

ServiceMetadataBehavior metadataBehavior = serviceHost.Description.Behaviors.Find<servicemetadatabehavior>(); if (metadataBehavior == null) { // This is how I create the proxy object that is generated via the svcutil.exe tool // I found this somewhere in CodeProject but I do not where // I am using it but I did not write the code

serviceHost.Open(); Console.WriteLine("Service is running....press any key to terminate."); Console.ReadKey(); serviceHost.Close();

Having this part done there are couple more steps:

1) Run the service2) Run "svcutil.exe http://localhost:8001/LocalTimeService /out:Proxy.cs" from Visual Studio command prompt. It will create both .config for client and Proxy.cs class. You can chose another name for the class. It does not matter.3) Stop the service4) Comment extra code because once when you got new proxy - "Proxy.cs" class you will not need extra code that you have added before. The part of code to be commented is:

ServiceMetadataBehavior metadataBehavior = serviceHost.Description.Behaviors.Find<servicemetadatabehavior>(); if (metadataBehavior == null) { // This is how I create the proxy object that is generated via the svcutil.exe tool // I found this somewhere in CodeProject but I do not where // I am using it but I did not write the code

metadataBehavior = new ServiceMetadataBehavior(); metadataBehavior.HttpGetUrl = new Uri("http://localhost:8001/LocalTimeService"); metadataBehavior.HttpGetEnabled = true; metadataBehavior.ToString(); serviceHost.Description.Behaviors.Add(metadataBehavior); }5) Go to folder two new files are saved5) Insert them into Client part "TimeService" project. You can use new "Proxy.cs" instead "LocalTimeService.cs" proxy class.

Hi there,This article is very knowledgably and to a beginner like me it’s fantabulous. Well I am currently having a problem (may not be directly to this article but I am sure it is based on / extension of this).I would like to use self-host or callback (which ever is efficient in terms of memory use sage [for storing endpoint address for responding to the clients request], response time and overhead) in order to communicate between clients and services which are placed on different location on internet. Problem I’m facing exactly can be simulated by the sample below.Let us consider I’m having clients within a local network whose public IP is 209.76.23.12(let us assume this IP is on router and no additional configuration can be done directly) and my client are on 3 different machines which has got private dynamic addresses such as 10.10.10.4, 10.10.10.15 and 10.10.10.21. And finally my service is located on a server on internet having public IP as 89.123.54.12. And I would like to get a response from the service when ever a client has changed something on the service database. I used delegates to raise events of that type. The only thing that is happening is when I send a request from client I also send my endpoint address in order for the service to reply back to the same address when ever there is a service level change. What is happening is I am not able to directly connect to my local IP in spite of giving the service my endpoint address to communicate. It is able to see my routers IP in the endpoint address but not the local IP. I have discussed this with my network administrator and he has actually opened a port for me to redirect the messages based on port address. I don’t think this is a write way when it comes to sharing same port address within a network of different computers. I was wondering if there is a way to overcome this client-service communication problem without using Socket level programming. I would appreciate anyone who comes out with a solution as this is very crucial for my company to implement. If this query is not fully clear please feel free to mail: ptpavankumar@gmail.com Thanks a million in advance.Regds,Pavan

If all tehnical articles were written in the friendly, easy to read style you seem to adopt so naturally, then some of the more complex techniques and technologies would be much easier to understand and digest by their readers.

Thanks for the reply. I had a doubt here i executed the client in another machine and with the server(host) with the active state but i am not able to retrive the time in the client(in another machine). But it works in the same machine(client and host in the same machine).

Check the config file. You need to specify the endpoint of the server. Make sure server is running on other machine. And make sure it's not named pipe because that only works for local communication. Remember, the best learning is done through mistakes. Good luck.

I'm just starting to learn the new WCF stuff. After completing my first 'Hello World' example I ran into a problem. Everything works fine as long as I reference the service via the ASP.Net development server but when I try to reference the service via a virtual directory in IIS it gives the following error when trying to create the proxy or add a service reference in Visual Studio:

Metadata contains a reference that cannot be resolved: 'http://localhost/hello2/HelloWorldService.svc'.

The HTTP request was forbidden with client authentication scheme 'Anonymous'.

The remote server returned an error: (403) Forbidden.

The virtual directory is pointing to my project folder so IIS and the .Net development server are using the exact same files so I'm assuming it's something with my IIS configuration. I have anonymous access enabled in IIS and I even added the ASP.Net and Anonymous logon user accounts to see if that made any difference and it didn't.