Early frameworks for distribution tended to be proprietary. Microsoft’s Distributed Component Object Model (DCOM) was intended to connect components written by using Microsoft technologies running on Windows. Java’s Remote Method Invocation (RMI) was intended to do the same thing in the Java world.

Although these are still in use, the world has moved toward a need for more connectivity and independence, and so service-based systems have become increasingly popular.

One of the hallmarks of modern service-based systems is the ability to compose parts together that have been developed independently.

This is done through the use of standards rather than proprietary technologies. So, for example, we can use XML and HTTP to connect two components rather than RMI, which was designed to work between Java components.

You will see shortly how WCF supports a wide range of the most popular and widely used standards, making it possible for you to create any type of service that you might need.

A component that you want to interact with could reside in another process on the same computer, on another computer on your local network, or out on the Internet. You have several options for connecting to such components.

For components that reside on the same computer, you would use an inter-process communication (IPC) mechanism such as named pipes, whereas for components deployed on other computers, you could use TCP/IP for binary communication or HTTP for text communication. In the enterprise world, it is also common to use messaging systems such as Microsoft MSMQ or IBM MQ to connect components located on different devices.

The problem here is that each of these communication mechanisms is implemented in a different way, using different libraries and techniques. A developer experienced in using TCP would have to learn how to use messaging.

WCF simplifies this by letting developers indicate how they want their components to be connected and leaving it up to the framework to implement the connection. For example, you can use an attribute to say that a class should be exposed as a web service using HTTP, and WCF will generate all the required code and configuration.

A service in WCF is called an endpoint. Endpoints are characterized by three facets:

The following figure shows how address, binding, and contract are related to a service:

The client talks to the service through an address linked to a binding. The binding then invokes the service operation through the contract, but the implementation is well hidden from the client. A service can also expose more than one endpoint; these might be the same operations using different bindings (for example, HTTP and TCP) or different logical sets of operations (such as user and administrator interfaces).

Endpoint definitions are used by both services and clients to instruct the WCF framework what to do. You can set up endpoints in code, but setting them up declaratively in configuration makes it possible to reconfigure services without having to rebuild the code.

The next three sections look at each of the three endpoint aspects in turn.

Every endpoint has an address composed from the following items:

Thus, to use HTTP to talk to a service called MyService, which is located at port 8080 on the local computer, you would use the following address:

http://localhost:8080/MyService

WCF supports four transports, as summarized in the following table:

A binding describes the details of how to connect to a service, such as the transport to use, the message encoding, and whether security or transaction support is required.

A binding is simply a collection of settings, and you can create your own bindings. However, you seldom need to do this because WCF supports several bindings to cover for the most standard scenarios, as summarized in the following table:

This table demonstrates that if you want to use HTTP as the transport, you could pick WSHttpBinding or WSHttpDualBinding, depending on whether or not you need bidirectional communication.

Contracts define what a service can do, and contract details are expressed in metadata for clients to use.

WCF supports four kinds of contracts:

You use contracts declaratively, by adding attributes to code. Here is a simple example of a service contract:

[ServiceContract]
interface class Foo
{
    [OperationContract]
    int SomeFunction(double d);
};

The interface is annotated with the ServiceContract attribute, which informs WCF that you are defining a set of operations. Individual functions within the interface are marked with Operation Contract, which makes them available to clients. Any function that isn’t marked with OperationContract will not be exposed to clients.

The operation SomeFunction only uses built-in types, and WCF knows how to marshal those. Suppose, though, that you wanted to expose a function like the following as an operation:

Person^ GetPersonById(int id);

In this case, you would have to instruct WCF how to marshal objects of type Person, and you could do this by using a DataContract:

[DataContract]
ref class Person
{
    [DataMember]
    String ^name;
    ...
};

The DataContract class defines this as being a serializable class, and you apply DataMember to all fields that you want to be serialized. If you don’t want or need to send a field, don’t annotate it; this will cut down the amount of data being sent over the wire.

Communication between clients and services can be one-way or bi-directional. WCF supports three message exchange patterns (MEPs) that govern how clients communicate with services:

Request-response is the default, and is typically used when the client expects a reply from the service. For example, consider this operation:

Person^ GetPersonById(int id);

The client calls the service with an ID and expects to get a Person back. Using request-response messaging, the client will block (and the connection will be maintained) until either the response has been received or a fault has been sent. This means that request-response message is synchronous, as demonstrated in the following illustration:

When using one-way (or simplex) messaging, the client sends a request but does not expect a response. This allows WCF to drop the connection to the service as soon as the call has been made because it does not have to wait for a reply. It also means that the operation must have a void return type because nothing will be returned, and it cannot declare a fault contract, because there is no way to get the error details back to the caller. One-way operations are useful for fire-and-forget operations such as logging or event notifications. They can also be useful for performing long-running operations asynchronously, where the client can use polling to ascertain when the server has the results ready. The following figure illustrates one-way messaging:

Duplex operation implies two-way communication between a client and service. Both ends can initiate a call, and neither has to wait for the other to finish before sending. To achieve this, service contracts specify a callback contract that the client must implement and which the service will call when it wants to call back to the client, as depicted in the following illustration:

Not all bindings support all MEPs. The following table summarizes what you can use:

Services have default ways of working. If you want to modify these, you use behaviors, which modify or extend the operation of services.

Examples of behaviors include:

A detailed description of behaviors and how to use them is beyond the scope of this book.

The next step is obviously to write a client to test out the service. There is a WCF Test Client included with Visual Studio, but you won’t be able to use that until you’ve added metadata support to the service, and we will leave that until later in the chapter.

One of the characteristics of services is that they are discoverable. This means that there is some way for potential clients to get details of the service, what it can do and how to call it. The standard way to provide this metadata is as a WSDL document, which describes the service in XML.

The next question is how you ask a service for its metadata. WCF services expose their metadata through an MEX endpoint. When you add such an endpoint, you can choose which transports (HTTP, TCP) that you want to support, and provide the URL.

You can use the WCF Test Client to examine and call service operations, but your service needs to publish metadata through an MEX endpoint before you can use this.

This next exercise adds an MEX endpoint to the service. It then shows how you can see the metadata and then use the WCF Test Client to exercise the service.

You have seen how to connect to a service manually by using the WCF APIs. It is also possible to get Visual Studio to create a proxy class for you, one that encapsulates the details of where the service is and what the endpoints are; in this way, you don’t have to be concerned with the low-level mechanics.

This is often the way that you would do it in C# and Microsoft Visual Basic .NET, asking Visual Studio to add a service reference to your project, and then using the generated proxy class. The problem is that this feature isn’t supported by C++/CLI in Visual Studio, but it turns out to be quite simple to do if you use a C# wrapper.