WCF Overview

As stated, the Windows Communication Foundation is a means to build distributed applications in a Microsoft environment. Though the distributed application is built upon that environment, this doesn’t mean that the consumers are required to be Microsoft clients or to take any Microsoft component or technology to accomplish the task of consumption. On the other hand, building WCF services means you are also building services that abide by the principles set forth in the aforementioned SOA discussion and that these services are vendor agnostic - thus, they are able to be consumed by almost anyone.

WCF is built upon the .NET Framework 3.0, which also includes the Windows Presentation Foundation and the Windows Workflow Foundation. Because it is part of the .NET Framework, as a developer you are able to use Visual Studio 2005 to build WCF services. Being able to build your services in Visual Studio just as you build any other .NET-based application also means that you can take advantage of the various integrated development systems offered via the IDE, such as debugging, Visual Studio’s outstanding IntelliSense capabilities, refactoring, and more.

Note that because this is a .NET Framework 3.0 component, you are actually limited to the operating systems in which you can run a WCF service. While the other Microsoft distribution technologies previously mentioned in this chapter really do not have too many limitations on the Microsoft operating systems in which they can run, a .NET Framework 3.0 application can only run on Windows XP SP2, Windows Vista, or the upcoming Windows Server “Longhorn.”

Capabilities of WCF

The WCF framework provides you with the capability to build all kinds of distributed applications. You can build Web Services just as you could previously in earlier .NET Framework releases. This means that your services will support SOAP, and therefore will be compatible with older .NET technologies, older Microsoft technologies, and even non-Microsoft technologies (such as any Java-based consumers).

WCF is not about pure SOAP over a wire, but you can work with an Infoset, and create a binary representation of your SOAP message that can then be sent along your choice of protocol. This is for folks who are concerned about the performance of their services and have traditionally turned to .NET Remoting for this binary-based distribution system.

The WCF framework can also work with a message through its life cycle, meaning that WCF can deal with transactions like those of the Enterprise Services mentioned earlier. Along with distributed transactions, WCF can deal with the queuing of messages, and it allows for the intermittent connected nature that an application or process might have to deal with.

When you need to get messages from one point to another, the WCF is the big gun in your arsenal to get the job accomplished. For instance, most developers might be thinking of using the WCF primarily to communicate ASP.NET Web Service-like messages (SOAP) from one disparate system to another, but you can use the WCF for much more than this. For instance, WCF can be used to communicate messages to components contained on the same machine on which the WCF service is running. This means you can use the WCF to communicate with components contained in different processes on the same machine. You can also use the WCF to communicate with components on another machine - even if that machine is not a Microsoft-based machine.

Probably the biggest and most exciting part of the WCF model is that it enables you to develop a service once and then expose that service via multiple endpoints (even endpoints on entirely different protocols) via simple configuration changes.

Working with the WS-* Protocols

There hasn’t been a larger set of WS-* specifications that any other Microsoft distribution technology can work with but that WCF cannot. WCF understands a framework of WS-* specifications, and these specifications can be enabled to allow for defined ways of dealing with security, reliability, and transactions. For this capability, many previous developers turned to the WSE. Figure 30-1 shows the architectural stack on which the WCF relies.

Figure 30-1

WCF can make use of these specifications if the developer wishes. Messages, as defined by the Messaging layer, rely on SOAP (sent as open text or in a binary format). The other advanced WS-* specifications make heavy use of the SOAP header, thereby enabling messages to be self-contained and not have any real reliance on the transport protocol to provide items such as security, reliability, or any other capability beyond the simple transmission of the message itself. Message Transmission Optimization Mechanism (MTOM) is a new capability to replace Direct Internet Message Encapsulation (DIME) as a means to transmit binary objects along with a SOAP message. An example binary object would be a JPEG image that you want to expose through a WCF service.

The Metadata section enables you to define your interface. When you build a service that you want to include in your application, you need to determine which parameters the service requires in order for the consumption process to work. In addition, after you pass the parameters to the service, you need to know what is returned so you can properly use the passed information within your own application. Without this information, using the service would prove rather difficult. Just as there are standard ways to represent the message itself with technologies such as SOAP, there is an industry standard for getting a description of a service that you are attempting to consume. The WCF framework makes use of the Web Services Description Language (WSDL) to describe the service. WSDL is a language that uses XML to describe a service and define the format of the messages a service understands. The other item the WCF provides from the Metadata layer is WS-Policy. This specification provides consumers with an understanding of what is actually required to consume a service.

The Security part of WCF enables you to work with WS-Security. Before WS-Security came along, the initial lack of a security model in Web Services kept many companies from massively adopting them companywide and moving onto a service-oriented architecture. WS-Security, developed by Microsoft, IBM, and VeriSign, addresses the main areas that are required to keep messages secure - credential exchange, message integrity, and message confidentiality.

WS-Security enables two entities to exchange their security credentials from within the message itself (actually from the SOAP header of the message). The great thing about WS-Security is that it doesn’t require a specific type of credential set to be used. Instead, it allows any type of credentials to be used. In addition, because it is possible to send messages through multiple routers and, in effect, bounce messages from here to there before they reach their final destination, you want to ensure that the messages are not tampered with in transport. As messages move from one SOAP router to another, these SOAP nodes can make additions to or subtractions from the messages. If such SOAP nodes were to get into the hands of malicious parties, the integrity of the messages could be compromised. This is where WS-Security comes into play. The other area WS-Security helps with is when you need to have WS-Security encrypt all or part of your SOAP messages. When your messages are zipping across the virtual world, there is a chance that they might be intercepted and opened for viewing by parties who should not be looking at their contents. That’s why it’s often beneficial to somehow scramble the contents of the message. When it reaches the intended receiver, the application can then use your encryption key and unscramble the message to read the contents.

WS-SecureConversation works to establish a connection that enables entities to exchange multiple messages and maintain their established security arrangements. WS-Trust, conversely, works in conjunction with WS-Security and allows for the issuance of security tokens and a way in which entities can exchange these tokens. This specification also deals with establishing trust relationships between two entities.

WS-ReliableMessaging allows for reliable end-to-end communications of messages to ensure that they are delivered.

The Transactions section allows for the use of WS-Coordination and WS-AtomicTransaction. WS-Coordination is there for the purposes of addressing the description of the relationships that multiple services have to one another. As companies start developing a multitude of services within their enterprise, they realize that many of the services developed have a relationship with one another, and that’s where WS-Coordination comes into play. This specification is meant to be expanded by other specifications that will further define particular coordination types.

WS-AtomicTransaction uses WS-Coordination and WS-Security to allow for the definition of a service transaction process. An atomic transaction is a way of creating a transaction process that works on an all-or-nothing basis. These transactions are meant to be short-lived, so when you use them you are locking data resources and holding onto physical resources such as connections, threads, and memory.

The important part of this discussion is that you have a whole slew of WS-* specifications at your disposal. The nice thing in working with WCF is that you really don’t have to be aware that these specifications are even there - you can access the capabilities these specifications offer through programmatic or declarative programming.