WCF Primer

Windows Communication Foundation (WCF) is Microsoft’s communication subsystem that allows applications in one machine or across multiple machines to communicate. It unifies Web Services, .NET Remoting, Distributed Transactions, and Message Queues into a single service-oriented programming model for distributed computing. It is a service-oriented programming model that simplifies development of connected systems.

Since the client always talks to the service via a proxy, the programming model remains the same whether accessing a local or a remote service. You can dynamically switch between local and remote without affecting the client. The WCF System.ServiceModel assembly contains the majority of classes you need when creating applications that use WCF.

Services can be located:

On the same machine in the same domain
On the same machine in a separate domain, but the same process
On the same machine in a separate process
On a different machine

Windows Communication Foundation uses SOAP for all messages. However WCF services, unlike web services, are not dependent on HTTP as a transport protocol—they are transport protocol independent.

Where Is It? -- Service Address

Every service accessed via WCF has a unique address that specifies:

The service location
The transport protocol used to access the service

The service location specifies:

The name of the target computer, site, or network
A communication port, pipe, or queue
An optional path or URI (Unique Resource Identifier, such as a GUID)

WCF supports the following transport protocols:

HTTP (uses http or https for transport)
TCP (uses net.tcp for transport)
Peer Network (uses net.p2p for transport)
IPC (uses net.pipe for transport)
MSMQ (uses net.msmq for transport)

Service addresses are of the format:

[transport]://[machine or domain][optional port]

For example:

http://localhost:8001
net.tcp//localhost:8002/MyService
net.pipe://localhost/MyPipe
net.msmq//localhost/private/MyService

What Can It Do? - Service Contracts

How does a service let the outside world know what operations it can perform? All services accessed via WCF expose a service contract that describes its operations.

The ServiceContract attribute is used on a class or interface to specify it defines a service contract. The OperationContract attribute is used on methods to indicate they are part of the service contract. For example:

[ServiceContract(Namespace = "http://Microsoft.ServiceModel.Samples")]
public interface ICalculator
{
	[OperationContract]
	double Add(double n1, double n2);
	[OperationContract]
	double Subtract(double n1, double n2);
	[OperationContract]
	double Multiply(double n1, double n2);
	[OperationContract]
	double Divide(double n1, double n2);
}

WCF Hosting

There are three main options for hosting a WCF Service:

IIS Hosting
Self Hosting
Windows Activation Service (WAS) Hosting found in Windows Vista

IIS Hosting

With IIS the process is launched automatically when a client request is received, and IIS manages the life of the host process. However, with IIS hosting you can only use HTTP for transport.

Self Hosting

You can self-host a WCF service within a Windows Forms application, a Console Application or a Windows Service. You can use self hosting when you want the host and client to run in different processes / machines or in the same process.

WAS Hosting

The Windows Activation Service (WAS) is a system service available under Windows Vista. It offers advantages over IIS hosting and self hosting including idle-time management, application pooling, and isolation. WAS hosting is the best all-around choice when available.

How to Communicate with it—WCF Bindings

To help simplify communication and interaction options WCF groups together a predefined combination of transport protocol, message encoding, and interoperability as bindings:

Name	Transport	Encoding	Interop
BasicHttpBinding	HTTP/HTTPS	Text	+
NetTcpBinding	TCP	Binary	-
NetPeerTcpBinding	P2P	Binary	-
NetNamedPipeBinding	IPC	Binary	-
WSHttpBinding	HTTP/HTTPS	Text, MTOM	+
WSFederationBinding	HTTP/HTTPS	Text, MTOM	+
WSDualHttpBinding	HTTP	Text, MTOM	+
NetMsmqBinding	MSMQ	Binary	-
MsmqlIntegrationBinding	MSMQ	Binary	+

The following diagram by Juval Lowy and published in CoDe magazine is a great way to determine the best binding:

EndPoints

An endpoint is a combination of address (where it is), contract (what it does) and binding (how to communicate with it):

A WCF service exposes at least one endpoint. The endpoint is the service’s interface, similar to a CLR or COM interface.

You place the endpoint in the hosting process’ configuration file when using administrative endpoint configuration. This type of configuration offers the most flexibility since you can change the address binding and contract without recompiling. For example (make sure you fully qualify the endpoint namespace in the contract attribute):

<service name="MyService" behaviorConfiguration="returnFaults">
    <<span class="codehighlight">><endpoint contract="OakLeaf.MM.Main.IMyService" binding = "wsHttpBinding" address="http://localhost:8000/MyService" /><</span>>
</service>

Publishing WCF Service MetaData

A service can publish its metadata in one of two ways:

Over the HTTP-GET protocol
By means of a dedicated endpoint

WCF can provide HTTP-GET metadata exchange for you if you specify an explicit service behavior. You can either specify this administratively in a configuration file or programmatically. Here is an example of an HTTP-GET MEX specified in a configuration file:

<services>
	<!-- Before deployment, you should remove the returnFaults behavior configuration to avoid disclosing information in exception messages -->
	<service name="DataWCFService" behaviorConfiguration="ServiceTypeBehaviors"
		<endpoint contract="OakLeaf.MM.Main.ImmDataAccessWCF" binding="wsHttpBinding" address="mex" />
	</service>
</services>
<behaviors>
	<serviceBehaviors>
		<behavior name="ServiceTypeBehaviors">
			<serviceDebug includeExceptionDetailInFaults="true"/>
			<serviceMetadata httpGetEnabled="true" />
		</behavior>
	</serviceBehaviors>
</behaviors>

There are three things to note listed in their order of appearince in the config file:

The behaviorConfiguration attribute in the <service> element
The <endpoint> specified in the <service> element
The <serviceMetadata> element in the service behavior configuration

After enabling the MEX over HTTP-GET you can browse to the HTTP base address and a confirmation page will be displayed. For example:

Calling a WCF Service

To invoke the operations on a service, the client application needs to import the service contract in a format that can be used by the client. If you create a WCF client you use a proxy that completely encapsulates the service’s location, platform, and transport:

You can call a service in two main ways:

Using a generated proxy
Using a Channel Factory

Using a Generated Proxy

Visual Studio automatically generates a WCF proxy when you add a service reference to your project. If your service is self-hosted, you must run the service before adding the reference. You don’t need to do this if you are hosting in IIS or WAS.

When you add a service reference using Visual Studio, it automatically adds WCF client configuration settings to your application configuration file. If you right-click your application configuration file (both client and host) in Visual Studio and select Edit WCF Configuration it launches the SvcConfigEditor which provides a nice UI for editing your WCF configuration settings:

To use the proxy, instantiate it passing the endpoint information (if there is only one endpoint you don’t need to specify it). You can then call methods on the proxy. For example:

using (MyServiceClient proxy = new MyServiceClient())
{
	Result1 = proxy.MyOperation1(this.txtInput.Text);
	
	DataContract1 dc = new DataContract1();
	dc.FirstName = "Alexander";
	dc.LastName = "McNeish";

	Result2 = proxy.MyOperation2(dc);
}

You should close the proxy when you are done (as with the using statement above) with it because the ends the session with the service and closes the connection!

Using a Channel Factory

You can use a ChannelFactory to call operations on a WCF service without using a generated proxy. You must provide the constructor with an end point name. For example:

ChannelFactory<ICalculator> factory =
new ChannelFactory<ICalculator>("WSHttpBinding_ICalculator");

ICalculator proxy = factory.CreateChannel();
using (proxy as IDisposable)
{
	double value1 = 10.00D;
	double value2 = 2.34D;
	double result = proxy.Add(value1, value2);
}

Enabling Logging and Tracing

At times, the error messages generated by WCF are less than helpful, so you may want to enable logging and/or tracing on both the client and the WCF service to debug problems. To do this, right-click the project's config file and select Edit WCF Configuration... from the shortcut menu. This launches the WCF Service Configuration Editor:

In the left pane select the Diagnostics node. In the right pane click the EnableMessageLogging and/or Enable Tracing links. Clicking these links displays additional information including the location of the log file, and allows you to specify the Log and Trace levels: