WCF Programming Model

SO or OO
When developing WCF services, which do you use? Do you use a service-oriented approach or an object-oriented approach to developing a WCF solution? The answer is, both. Simply put, object-oriented programming is used to develop applications, and service-oriented programming is used to connect those applications. The trick is to understand the distinction between the two and understand when and how they are used and the benefits they provide.

Think “object-orientation = tightly coupled, and service-orientation = loosely coupled.” Object-oriented applications are two or more class libraries that are dependent on each other and share a common type system. These class libraries communicate with each other via distributed object calls, with each object class communicating with the other classes’ exposed interface.

Service-oriented applications are programs that know nothing about each other, thus are loosely coupled. Each application communicates with other applications via messages, and what makes this approach ideal is that these messages can be sent from one application to another regardless of the platform of each service.

When developing WCF services, the trick is to understand how to link OO and SO together. The terms classes and interfaces are extremely familiar to the object-oriented developer, and they are still used when developing WCF services. This is the OO part of the equation. The SO part of the equation comes in when you apply the WCF attributes to define the entities.

For example, the following class defines an object-oriented interface:

public interface coolservice
{
     decimal CalculateShipping(string state, int shiptype)
     {
          //do something
     }

     decimal CalculateTax(string state, decimal bookcost)
     {
          //do something
     }
}

The first step is to define the interface using your favorite .NET programming language, in this case, C#.  Now comes the SO part, which is to add the necessary attributes used to designate this interface as a WCF contract. The preceding code now looks like this:

[ServiceContract]
public interface coolservice
{

     [OperationContract]
     decimal CalculateShipping(string state, int shiptype)
     {
          //do something
     }

     [OperationContract]
     decimal CalculateTax(string state, decimal bookcost)
     {
          //do something
     }
}

This example shows the fusion of object-oriented programming and service-oriented programming. You get to use a language that you already know while taking advantage of the great benefits of service-orientation.

Service Model
When you create a web service you are indeed creating a service. A web service contains an XML document that is used to describe everything there is to know about the service. This document is the Web Service Description Language (WSDL) for the service and contains three parts or sections:

·         Service

·         Binding

·         PortType

The first part, the service part, contains information as to where the service is. The second part, the binding section, contains information as to how this service will communicate, such as what protocols the service will use, and so on. The third part, the portType section, explains what the service will do. Coincidently, the Windows Communication Foundation service model is very similar to the web service model. Using the service model, you specify where the service is (that is, URI), how it communicates, and what the service can do. Just like the WSDL. The only difference is the naming of the parts. In WCF, they are not called service, binding, and portType. In WCF, they are called address, binding, and contract. Simply put, a service is an application or piece of software that communicates with other services or applications. That service has one or more endpoints. Each of those endpoints contains an address, binding, and contract.

System.ServiceModel
In Windows Communication Foundation, the System.ServiceModel namespace is used to model and develop the service application and how it communicates. This namespace provides a large number of classes that allow developers to be flexible with respect to how their service will be developed.

The following table lists some of the more commonly used classes used to model and build your service.