SOA. Service-Oriented Architecture. This buzzword has been around for quite a while now and in the last year and a half or so Microsoft has taken quite a step into anchoring themselves into the SOA soil. It wasn’t too long ago that they announced that they were working on something really cool called “Indigo” and that it would be the latest thing that should be added to the Service-Oriented application utility belt.
The more developers read about “Indigo” they realized that it wasn’t anything to sneeze at. They read about a fusion of current distributed-system technologies and ease of deployment. They read about increased productivity and, lo and behold, a single programming model. So, we (I am including myself in this “we” and “they”) began to ask “What is Indigo?”.
Let’s Review
Through the years, developers have had a plethora of technology choices to choose from when it has come to building distributed applications. Lately it has been ASP.NET and WSE (Web Service Enhancements), used to build Web Services which allow for the communication of information across different platforms and regardless of the client. Also with .NET you have .NET Remoting which provides object communication no matter where the application components reside. Prior to that you had COM+ and MSMQ. MSMQ provided a fast and reliable method of application communication through the process of sending and receiving messages.
I remember not many years ago using MSMQ in a fairly large project because the guaranteed delivery of information was critical , yet today I use ASP.NET Web Services almost religiously because of the many benefits they offer (simplicity, diversity of environments, etc).
These were, and still are, great technologies that provided great solutions to countless development problems. Yet every time you as a developer had a distributed system problem to solve, you had to re-ask yourself “which one of these technologies more easily and efficiently solves my problem?”. The downside to each one of these is that your method of implementation will vary greatly based on your choice of solution, especially if your solution uses more than one of these technologies.
Wouldn’t it be great of all of these were combined into a single SOA solution?
The Answer
Windows Communication Foundation (WCF) is what was formally code-named “Indigo”. It is the combination of all the best features of the previously mentioned distributed-system technologies (ASMX, MSMQ, COM+, etc) into a new, single SOA programming model. This is accomplished via a layered architecture and CLR-based distributed system technology. This is a welcome for current .NET developers because no new technology needs to be learned. Developers can build reliable, transactional, distributed systems using technology they already know.
There are obviously a number of benefits that come with this new distributed system platform, but before those are listed it would behoove us to get into the details of WCF first and discuss how WCF works. The great thing is, it is not that complicated.
The Guts of WCF
There are three main elements or components that make up a valid WCF endpoint, and they are an Address, Binding, and Contract. If you are at all familiar with WSDL (Web Service Description Language) descriptions then you should look at this and recognize how similar the concept is. Basically, the three elements are:
* Address: Where is the service, or what is the endpoint address? This information is contained in the wsdl:service section and connects the wsdl:binding to the valid endpoint address.
* Binding: This information is found in the wsdl:binding section and contains all of the communication necessary to make an endpoint available.
* Contract: Specifies what information the endpoint can hand out. This information is contained in wsdl:portType, wsdl:type and wsd:message sections.
With all of this in place you have a WCF service, or in other words, a collection of one or more endpoints, each endpoint being a gateway for exchanging information with its clients.
Setting this information is done by including and filling in the WCF configuration scheme. The basic WCF configuration scheme is shown below.
<configuration>
<system.serviceModel>
<bindings>
</bindings>
<services>
</services>
<behaviors>
</behaviors>
</system.serviceModel>
</configuration>
As you can see, the <system.serviceModel> element is used to configure a service type with one or more endpoints and settings for a service. As previously discussed, each endpoint is configured with an address, binding, and contract. The following is a simple example of an endpoint specified with each.
<configuration>
<system.serviceModel>
<bindings>
</bindings>
<services>
<service serviceType="FirstTest">
<endpoint
address="http://localhost:8080/FirstTest"
binding="basicHttpBinding"
contract="ITest" />
</service>
</services>
<behaviors>
</behaviors>
</system.serviceModel>
</configuration>
In the above example, the address specifies the URI that the endpoints will use to talk with this service. The binding attribute tells the service that this is either a custom or predefined binding for this endpoint. This example used a predefined binding. If a binding is not specified, the default is BasicHttpBinding. The contract attribute tells the service which contract the endpoint needs to make available. This property can be left off if the service is only exposing a single contract.
A client is a program that can connect and communicate with one or more endpoints. However, the three elements need to be discussed in a bit more detail.
Address
As briefly noted above, 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 straight forward. 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 will determine which methods will be exposed to the outside world and made available to the clients. This is accomplished by including them in a service contract. This is done by including the most basic, 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 hard to do over the 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 they provide 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.