WCF is Awesome

I had heard of the Windows Communication Foundation (WCF) a while ago while researching inter-process communication in .NET. I recently tried it out, and I discovered that it's really awesome.

WCF is based on services which expose endpoints. A service is a server application, and can be in the form of a normal .NET process, a dedicated Windows service, or an IIS web site. Each service has one or more endpoints, which are like network listeners. WCF supports several protocols, including HTTP, TCP, and (should you really feel the need) MSMQ.

For a client to consume (use) a service, both parties must be able to load a .NET interface type that defines what the service does. An interface designed for WCF must be tagged with ServiceContract, and each function must be tagged with OperationContract. Those attributes can specify other options, such as the required encryption level or whether a connection must remain open. The server application actually implements the service interface, and tells the ServiceHost the implementation type. Once the Open method is called on the ServiceHost, the server is listening for clients.

The client creates a channel with an EndpointAddress configured with the server's address and connection properties (e.g. encryption) and passes it the .NET type of the server interface. Magic happens, and poof you get an object that implements the server interface and that talks to the server over the network when you call its methods, acting like a local object all the while. (Like ye olde .NET Remoting, except it won't fall over as soon as you turn your back.)

Since you probably want to give information to the client even if the client didn't initiate anything, WCF also includes support for duplex bindings. When a ServiceContract is marked as requiring duplex communication, there is also a client interface associated with the service. It is then the client application's job to implement it. Once the duplex channel is opened, poof the server can call methods on what looks like a local object, but actually sends information over the network to the client.

WCF doesn't actually have to be over a network - it works for inter-process communication on the local machine too. I haven't tried this yet, but it looks like named pipe binding is the way to go.

When the channel is authenticated with Windows credentials, impersonation (and if you really persevere, delegation) is a simple matter of calling a method. The client spews its security token over the network to the server, which then checks it with a domain controller using Kerberos and knows for sure that the client's identity is legit.

There are all kinds of properties on the communication context object that let you manage the state of a specific connection and read properties about the client, such as its IP address.

Unfortunately, there are lots of Internet tutorials on WCF that are really bad and are super inconvenient. I'm also not really a fan of the XML (WSDL) configuration style; I prefer that my code do the set-up of network connections. There doesn't seem to be as much information on programmatic control of WCF bindings, channels, and endpoints as there is for WSDL, but it's there if you poke around and experiment. This might be more of a personal preference than anything (maybe nostalgia?), and I'm sure WSDL set-up of WCF works fine for lots of people.

So, WCF is really awesome. I'm never writing my own networking code again.