Windows Communication Foundation
By Scott Klein
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?"
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 allowing for communication of information across different platforms and regardless of the client. Also with .NET, you have .NET Remoting providing 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?
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 combination 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 I list those it would behoove us to get into the details of WCF 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 as follows:
- 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.