Multi-tiered applications are sometimes deployed over distributed network nodes and need computer-to-computer connections and remote software calls. Windows Communication Foundation (WCF) is the .NET 3.0 framework for building service-oriented applications. One of its major features is the location-transparency. In other words, a WCF service can be invoked from anywhere in the network by any piece of software that knows about the endpoint to reach and the contract to fulfill. WCF services are more general than Web services.
WCF should be seen as the sum of a number of existing Microsoft connectivity technologies. WCF unifies and extends into a single programming model .NET Remoting, Microsoft Message Queue, Enterprise Services, ASMX Web services, named pipes, and more. WCF is independent of underlying communications protocols and lets native applications interoperate with other applications using open standards and protocols. Especially in future versions of the .NET Framework and ASP.NET, WCF services are going to be a pillar and a central piece of architecture that virtually any developer has to know very well.
A WCF service is characterized by a contract where all available methods are listed. From a coding perspective, a contract is an interface decorated with a few ad hoc attributes. Let's see how to create and configure a WCF service.
[ServiceContract]
public interface IMyContract
{
[OperationContract]
string DoSomething(int id, int length);
}
A service implementation is nothing more than a class that implements the contracted interface. Here's an example:
public class MyContractService : IMyContract
{
public string int id, int length)
{
:
}
}
Once compiled to an assembly, the class becomes the service and can be publicly deployed. How would you do that?
At the very minimum, a service is characterized by a name, a contract, an address, and some protocol information. A client needs to know who to call, where to place the call, and what to ask. This information is published by the service host and is incorporated in the client. The service host is an external application that listens for incoming calls to forward to the service. A host application can be a custom console application as well as IIS. For simplicity, let's use IIS to publish a sample service. You create an IIS virtual folder and add a web.config file that contains the following entry.
<system.serviceModel>
<services>
<service name="Samples.MyContractService">
<endpoint contract="Samples.IMyContract"
binding="wsHttpBinding"/>
</service>
</services>
</system.serviceModel>
What about the address of the service? You need to define a public IIS resource, that is a name that IIS knows how to map to a physical resource and handle. You do this through a .svc file placed in the same IIS virtual folder. Here's the contents of a .svc file.
<%@ ServiceHost Service="Samples.MyContractService, samples" %>The SVC file references an assembly (samples.dll) and a class in the assembly where the service (and all of its contracted interfaces) are implemented. The path to the SVC resource is the address of the service that clients need to know to connect.
The configuration file of the client application (web.config for an ASP.NET client) maps to the published service through a slightly different <serviceModel> section, as below.
<system.serviceModel>
<client>
<endpoint address="http://server/Wcf/yourUrl.svc"
binding="wsHttpBinding"
contract="IMyContract"
name="WSHttpBinding_IMyContract">
<identity>
<servicePrincipalName value="host/server" />
</identity>
</endpoint>
</client>
</system.serviceModel>
What kind of code will the client include to call a remote service? The channel to the service can be created manually through lower-level code or it can be automatically generated by a utility in the form of a proxy class. A system-provided utility named svcutil.exe will take the physical address of the remote service class and generate a proxy class with all the methods of the contracted interfaces. At this point, all that the client has to do is to call into the members of the proxy class.
The essence of WCF is all in these simple facts. Of course, WCF services may implement many more rich and advanced features such as security, reliability, or transactionality. But that's another story and beyond the scope of this article. For more information, I suggest you get a copy of Programming WCF Services, by Juval Lowy, O'Reilly, 2007.
