Looking at the WCF Windows Communication Foundation

CodeGuru content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Introduction

To make your life as a developer easy, Microsoft continuously brings new technologies to the market. Sometimes, these technologies are similar to existing technologies, and at other times large enhancements are made in the current technologies. As a result, at times you see the processing architecture of a web page totally change, as was done in .NET 2.0.

.NET 2.0 does not, however, bring significant enhancements in Winform application development. So, how can you build a Windows application that can be distributed across diverse operating systems and that will gain a performance benefit when used on the same OS? The answer is Windows Communication Foundation (WCF), which had previously been code named “Indigo.”

This article will cover the basic components of WCF and dive into some of the details of its components. It will address the issues faced in previous technologies as well as show why you should use WCF.

What Is WCF?

As said earlier, WCF is a part of the .NET 3.0 framework. It is a type of service execution framework made especially to establish communication between diverse systems and gain performance benefits on similar systems. It consolidates the best features of web service, remoting, MSMQ, System.Messaging, and Microsoft enterprise services. One of the biggest advantages of WCF is that it supports most open industry standards; therefore, it can produce the best results across heterogeneous operations systems.

It is also beneficial that it was developed using managed code and that it uses the power and features of .NET 2.0. Because it supports WS-* standards, it supports transaction, security, and reliability. WCF uses SOAP as its native protocol for communication.

Prerequisites

You need the following to develop a WCF service:

• OS: Windows VISTA, Windows XP SP2, or Windows 2003 Server SP1
• Visual Studio 2005 professional Edition with SP1 (or better)
• Microsoft Windows SDK
• .NET 3.0 runtime
• WCF extensions (while working on the VS 2005 editor)

Key Components of WCF

WCF is based upon the following key components that are used to build a WCF service. Each component is covered in detail in the following sections.

1. Contract definitions
• Data contracts and data member
• Service contracts
• Fault contracts
• Message contracts
2. End points
3. Bindings
• BasicHttpBinding
• WSHttpBinding
• WSDualHttpBinding
• WSFederationHttpBinding
• MsmqIntegrationBinding
• NetMsmqBinding
• NetNamedPipeBinding
• NetPeerTcpBinding
• NetTcpBinding
4. Hosting environments
• Windows application
• Console application
• Windows service
• IIS
• WAS (Windows Activation Service), comes with IIS 7.0
• Windows presentation foundation

Problems Addressed by WCF

To understand the power of WCF, you really need to understand what issues it addresses.

Imagine you are developing an enterprise application for a bank. When you start designing the system, the requirements are very complex and critical. Consider, for example, that the application is used by bank staff, outside customers, and by payment gateway systems. You are not sure that what operating system and what type of clients will be used by outside customers. You want the system to have performance with security and reliability when used on an intranet. You want security and reliability when used from outside as well. Previously you could have gone for creating web services exposing web methods for outside clients and a remoting or COM+ application for Windows OS.

Both the web service and the remoting/COM+ based applications us the same business logic and the same database. Suppose you want to add some new business logic, such as introducing a new loan system; imagine how much it will take to change all the systems. This is perhaps the simplest example. What if you are going to modify the business logic or add 3-4 additional schemes in the span of six months?

The current design will not scale. You might start wondering: What if you had a single application exposing multiple endpoints for diverse and similar clients—an application that will give me all the benefits of industry-wide open standards.

That’s it. WCF is the answer to your question.

WCF with managed code, using the power and features of .NET 2.0, giving all the benefits of performance, security, transaction, reliability by supporting all open industry standards, makes life easy for the developer and the organization by unifying the programming model with the best features from all available technologies. WCF is interoperable with the following:

1. Web services
2. .NET—.NET communication
3. Distributed transactions
4. Support for WS-* specifications
5. Queued messaging

Key Subsystems of WCF

1. Service model
2. Connector framework
3. Hosting environment
4. System services
5. Messaging services

Key Components in WCF

The following are key components of WCF. Each of these is covered in the following sections.

1. Contracts
2. Bindings
3. End point definitions
4. Hosting environment

Contracts

Contracts are one of the most important components of WCF. Contracts make developing interoperable services possible. It is a common understanding between client and server of available methods, data structures, and message structures. They remain loosely coupled and platform independent. WCF contains the following contracts. Because SOAP is the native protocol of WCF for communication, interfaces and classes are translated to SOAP types by CLR.

1. Service contract

This is translated to WSDL. Service contract defines the operations that a service can perform. This is why a WCF service must contain at least one. It also can have more than one service contract. It is defined by using the [ServiceContract] attribute. The implementer of the service contract is managed code. Hence, the service contract also maps the interface and methods to a platform-independent description. By using the attribute feature of .NET, you can extend the behavior of the service like is it one way or two way, the exception handling behavior, and so forth.

Each service contract contains methods that are exposed outside and annotated with the [OperationContract] attribute.

A service contract also can specify the requirements that should be satisfied by the endpoint; a required session should be satisfied by endpoints. For example:

[ServiceContract(ProtectionLevel=System.Net.Security.
                 ProtectionLevel.None)]
   public interface IWCFService
   {
      [OperationContract]
      string GetSystemIPAddress();

      [OperationContract]
      List<Employee> GetEmpolyeeArray();

      [OperationContract]
      Employee CreateNewEmployee();
   }

Usually, you also can use a service contract over a class. However, it is not a good practice because interfaces allow separation from the implementation logic. When using ServiceContract and OperationContract over a method or a class, access modifiers do not make any sense. Everything that is marked with ServiceContract or OperationContract will be exposed to a client outside the application domain.

Services are of three types.

1. Typed
• Uses for the simple communication. It can accept or return simple or complex data objects.
• For example, you can use the CreateNewEmployee() method in the above class.
2. UnTyped
• It allows developers to work at the message level.
• For example, you can use Message ParseRequest(Message myRequestMessage).
3. Typed message
• Falls between typed and untyped services.
• Uses custom message classes defined with Message contracts.
• For example, you can use MyMessage ProcessedRequest(MyRequestMessage msg).

2. Data contract

This is translated to XML schema (XSD). It basically describes the data structure. When you want to pass or return more values, you go for data contract. It is a serializable object that can be passed or returned to or from a service. It supports versioning provided. You should not change the name of the existing members; instead, name the namespace to maintain compatibility.

The data contract can be defined by annotating the [DataContract] attribute on a class, structure, or enum. The data members that are to be exposed outside are annotated with the [DataMember] attribute for class and structure and [EnumMember] attribute for enum.

[DataContract] tells WCF how to serialize the object. Depending upon the client, WCF serializes the members. If the communication is between WCF and WCF, it uses binary serialization over SOAP to optimize the performance. In the case of WCF to Non-Windows client, it uses SOAP serialization.

Here also, access modifiers do not play any role.

There are some cases when you do not have a proxy generated for the given service. This may be the case when the WCF service uses only TCP endpoints to allow interaction. In that case, WSDL will not be available unless and until it is explicitly defined in the service behavior with an HTTP end point. Even if client does not have WSDL with you, you can create the same WCF dummy class or proxy class at the client side. The WCF service will remain as it is; the implementer will derive from ClientBase<IWCFService> and implement the WCF service (IWCFService). In such a case, the operation contract method will call base.Channel.GetSystemIPAddress() and it will be routed to the server by the foundation. In this case, you can have data contract members defined in the same way. The only thing—and the most important thing—is that the namespace must have the same names as that of server. Also, method names and data member names should remain the same.

3. Fault contract

These are translated to SOAP faults. The allow the developer to document the errors that a service can produce. You can define a service contract only on [OperationContract] by annotating with the [FaultContract(typeof(System.Exception))] attribute. Here, the exception type can be a exception to what you want to document. A custom exception should be marked as serializable.

4. Message contract

This is translated to a SOAP message. It describes the structure of the message, such as what goes where. WCF allows the developer to control what to go where in a message for interoperability issues. Message contracts allow you to match the expectations of other systems concerning the SOAP message. Message contracts can be defined by using the [MessageContract] attribute. Members participating in the SOAP message can be defined and placed at appropriate place by using the [MessageHeader] and [MessageBodyMember] attributes. For example:

[MessageContract]
public class MyMessage
{
   [MessageHeader]
   public string myHeader;
   [MessageBodyMember]
   public Employee myMessageBody;
}