Wrox Home  
Search
Professional SQL Server 2005 XML
by Scott Klein
January 2006, Paperback


Windows Communication Foundation Guts — Exploring the 3 Main WCF Elements

Address

As briefly noted before, every endpoint must contain an address. This address is what allows other endpoints with which to start communications and specifies where the service is located. Addresses are pretty straightforward. They are URI's that specify the machine name and an endpoint on that machine. Every endpoint must specify an endpoint (as well as a contract and binding).

From the example above, the address specifies to the endpoints where the service is located, as shown in the highlighted section below.

<services>
  <service serviceType="FirstTest">
    <endpoint
      address="http://localhost:8080/FirstTest"
      binding="basicHttpBinding"
      contract="ITest" />
  </service>
</services>

Binding

The binding information of an endpoint contains all the necessary information to make the endpoint known to the outside world. Binding information includes items such as whether or not security on the endpoint is enabled, is communication being streamed or buffered, what type of transport the endpoint should communicate, and what data encoding is to be used.

In its simplest form, a binding must contain at least one transport element, one message encoding element, and one or more protocol elements. Once you have all of this information, you have a binding. But a binding can contain more than one binding element, with each element containing the information above, which details how the endpoint connects and exchanges information with the client.

As you are defining your bindings you have a couple of options depending on the type of services you need. You can choose a predefined binding or you can create a custom binding. Using the binding elements in the System.ServiceModel namespace you can create your own custom bindings to provide information such as transactional processes or endpoint state retention.

However, creating your own custom binding can be quite labor intensive and one of the things you need to be mindful of when creating a custom binding is that some binding elements cannot co-exist with other binding elements. Luckily, WCF comes with a good set of predefined bindings that nine times out of ten will contain all of the functionality you will need.

Contract

As specified earlier, a contract specifies what information the endpoint can hand out. A contract is merely a collection of one or more operations that determine what the endpoint can make available to the world. Each operation is simply an exchange of messages.

When creating a service, the service class determines which methods will be exposed to the outside world and made available to the clients. We accomplish this by including them in a service contract. This is done by including the most fundamental attribute — the ServiceContract. A WCF service class is simply a class that has been tagged with the ServiceContract attribute.

For example, the following code snippet shows how this is done.

using System.ServiceModel;[ServiceContract]
class SimpleMath
{
  [OperationContract]
  private int SimpleAdd(int a, int b)
  {
    return a + b
  }
  private int SimpleSubtract(int a, int b)
  {
    return a + b
  }
}

In the example above, the SimpleAdd method is tagged with the OperationContract attribute, but the SimpleSubtract method is not. This means that the SimpleAdd method will be exposed by the endpoint, but the SimpleSubtract method will not.

All the attributes, such as OperationContract and ServiceContract, are defined in the System.ServiceModel namespace, thus you see the first line of the code snippet using System.ServiceModel.

Another way of doing this same thing, and probably a more affective way, is to use the language's interface type. So, the above example would look like this:

using System.ServiceModel;[ServiceContract]
interface ISimpleMath
{
  [OperationContract]
  Int SimpleAdd (int a, int b)
}
class SimpleMath : iSimpleMath
{
  public int SimpleAdd(int a, int b)
  {
    return a + b
  }
  public int SimpleSubtract(int a, int b)
  {
    return a + b
  }
}

The results of the two examples are the same because the service exposes the same contracts as the previous example. What is the difference? A few things. First, the second example uses explicit interfaces and this is a bit more difficult to do compared with first example. Yet, using explicit interfaces does give you a bit more flexibility because your class can have more than one interface and can therefore have more than one service contract.

Another difference is that if you tag the class with ServiceContract and OperationContract (as in the first example), contract definitions will automatically be generated in the WSDL.

Behaviors

The last topic to touch on briefly are behaviors. Behaviors are types that can modify and extend either the service or the client runtime behavior. For example, they can modify and dictate how a message is supposed to be sent to service operations, or they can add new functionality.

No examples will be given here but it is important enough to mention them. If you want to modify the service behavior you simply need to implement IServiceBehavior. If you want to modify how the client behaves you need to implement IChannelBehavior and all behaviors will be applied to the client channels.

WCF Benefits

By now you should have pretty good handle on WCF and what it can do. But as explained at the beginning of this article, there are some darn good reasons why WCF makes sense.

  • The biggest benefit is that you now have a single programming model for all CLR-based distributed technologies. This benefit was explained earlier when it was mentioned that you now get, in a single framework, all the best of .NET Remoting, ASMX, MSMQ, and system messaging. You would be hard pressed to be that.
  • The ability to have your WCF services hosted by other applications. What does this mean? You can have your WCF service used in any application domain enabling the exchange of data with other endpoints.
  • Support for transaction programming is enabled on WCF-enabled versions of Windows (Vista, for example). This is made possible by the System.Transaction namespace, enabling the support for SQL Server, ADO.NET, MSMQ, and DTC (Distributed Transaction Coordinator).

Summary

OK, there it is. Windows Communication Foundation in its simplest form. The intent of this article is to provide a helpful explanation and overview of Windows Communication Foundation and show the simplicity and flexibility it provides over existing and previous technologies that are in use today when building distributed systems. Once you start getting into WCF you start to understand the simplicity and power of the programming model and can grasp what WCF can offer.

Scott Klein has been involved with databases for over ten years. He started using Microsoft Access prior to beta 1, then started using SQL Server when version 4.2 came out and has been using it heavily ever since. XML caught his attention about three years ago and most of his development since that time has been around XML and SQL Server. Scott is the author of the recently published Wrox book Professional SQL Server 2005 XML and his next book Professional WCF Programming: .NET Development with the Windows Communication Foundation (Wrox, ISBN: 0470089849) is scheduled to publish in early 2007 or when WCF is available. Scott's previous article on Wrox.com is SQL Server 2005 Programmability Enhancements — Common Table Expressions.