Introduction

Windows Communication Foundation (WCF) is a part of the .NET Framework which allows for rapidly building service-oriented applications. Personally, I believe the strongest aspect of WCF is the speed in which you can construct and deploy business applications which require a service oriented architecture (SOA) based solution. WCF is mainly for building SOAP-based web services. Although it is possible to build RESTful web services using WCF (see WebHttpBinding), it is generally recommended to use ASP.NET Web API 2 or another framework such as the Django REST framework to build RESTful Web APIs instead.

Decline of SOAP

SOAP-based web services are becoming increasingly less popular due to the surging popularity of RESTful web services. In my experience as a developer, the key advantage of REST over SOAP is that it is far more interop-friendly. Any platform which has an HTTP stack can access a RESTful web service (which nearly every platform today has one). SOAP on the other hand is plagued both by the fact that the chance of a platform having a SOAP toolkit is far less likely and that individual vendors’ implementations of the Web Service (WS) specifications vary. Variations in implementations (even very small differences) of SOAP and WS-* standards can lead to problems when communicating across platform boundaries.

Wait! So is SOAP and WCF dead?

RESTful web services provide an alternative to SOAP web services and not a replacement. As with any project – Pick the right tool for the job. For enterprise systems, the ability to have a service self-describe itself via Web Services Description Language (WSDL) is extremely helpful. Additionally, SOAP toolkits allow for automated proxy generation via the WSDL that client-code can immediately use. On the other hand, REST interfaces commonly do not support such tools as they are more light-weight in nature and are meant for human (and not machine) consumption. There are some efforts for REST to support machine-readable self-description via something known as the Web Application Description Language (WADL), but it is not standardized like WSDL is for SOAP. SOAP also supports additional features such as distributed transactions, reliable messaging and strongly typed data whereas REST does not. Although the concepts of REST can theoretically be implemented over any protocol – HTTP is currently the only way to go. Again, SOAP is the big winner in this category as there are a multitude of transports to choose from.

Personally, when working on an enterprise application where both ends of the wire will be developed utilizing the .NET Framework, then the speed and many extensible features granted by leveraging the power of WCF and therefore SOAP make it a fairly easy choice. Some readers may have had their palms meet their faces at this point as this decision has limited the options available for possible clients early on in the development of the application. But why develop a REST API instead of a SOAP API for the off chance that you may want Python or Java clients in the future. YAGNI! A well designed backend should not be too painful to refactor in order to add support for both SOAP and REST APIs in the event you wish to expand your system with an Android client. Plus, it’s not always impossible (just sometimes a bit of a struggle) to get different platforms to communicate using SOAP.

WCF Tutorial

This tutorial will use the approach where there is a single owner for both ends of the wire (client and server) and for the foreseeable future this will hold true (such as an in-house enterprise system). With this in mind, this will be a pure .NET to .NET solution and therefore this tutorial will use the “shared contract assembly” approach. While sharing the contracts (service operations, data transfer objects (DTOs), faults, etc.) between the client and server will gain us quite a few benefits – A drawback is that it will induce a stronger coupling between the two ends of the wire than generating a proxy for the client via the WSDL would. For cases where the service mainly controls business logic and data access and the client is just for presentation (UI) then this is certainly okay.

WCF Basics

The four major components of this WCF based solution are: service interface, service library, service host and client.

The service interface (contract library) describes the operations that a service has available as well as the Data Transfer Objects (DTOs) and SOAP Faults to be exchanged. The contract library is known to both ends of the wire. The service library is the implementation of the contract and is what executes whenever a service operation is invoked. The service library is known only to the server-side and for the client to have direct access to the library is a huge violation of SOA. The service host is what exposes a particular service for consumption by client applications. The host is what loads the service, configures the endpoints, applies any security settings, and starts listeners in order to handle incoming requests to a service. The client is what consumes the service and can belong to any application model (WinForms, ASP.NET, WPF, Console, etc.) and is what the end user interacts with directly.

This contrived example will be a service called MathService which supports two operations: The first is PerformBinaryOperation which takes a BinaryOperation DTO, performs the designated binary operation (add, subtract, multiply, divide) and returns the result as a double. The second is CalculateSlope which takes a pair of TwoDimensionalPoint DTOs (XY-coordinates), calculates the slope between the two and returns the result as a double. This example will also showcase how to communicate SOAP faults between a client and server as well as how to use the ChannelFactory class to generate a proxy at runtime.

So let’s begin the tutorial by creating our service interface/contract (coming soon).