What Is Windows Communication Foundation?

I assume that you are reading this book because you want to know how to build distributed applications by using WCF. But what actually is WCF, and why should you use it anyway? To answer these questions, it is helpful to take a few steps back into the past.

The Early Days of Personal Computer Applications

In the early days of the personal computer, most business solutions comprised integrated suites of applications, typically consisting of word processing software, a spreadsheet program, and a database package (much like Microsoft Office does these days). A skilled user could store business data in the database, analyze this data using the spreadsheet program, and maybe create reports and other documents integrating the data and the analyses by using the word processor. More often than not, these applications would all be located on the same computer, and the data and file formats they used would be proprietary to the application suite. This was the classic desktop business platform; it was single-user, usually with very limited scope for multi-tasking.

As personal computers became cheaper and more widely adopted as business tools, the next challenge was to enable multiple users to share the business data stored on them. This was not actually a new challenge, as multi-user databases had been available for some time, but they ran predominantly on mainframe computers rather than PCs. However, networking solutions and network operating systems (NOS) soon started to appear for the PC platform, enabling departments in an organization to connect their PCs together and share resources. Database management system vendors produced versions of their software for the networked PC environment, adapted from the mainframe environment, enabling networked PC solutions to share their business data more easily.

Inter-Process Communications Technologies

A networked platform is actually only part of the story. Although networking solutions enabled PCs to be able to communicate with each other and share resources such as printers and disks, applications needed to be able to send and receive data and coordinate their actions with other applications running at the same time on other computers. Many common inter-process communications mechanisms were available, such as named pipes and sockets. These mechanisms were very low-level and using them required a good understanding of how networks work. The same is true today. For example, building applications that use sockets to send and receive data can be a challenging occupation; ostensibly the process is quite simple, but factors such as coordinating access (you don’t want two applications to both try and read from the same socket at the same time) can complicate matters. As computers and networks evolved, so did the variety and capabilities of the inter-process communications mechanisms. For example, Microsoft developed the Component Object Model, or COM, as the mechanism for communicating between applications and components running on the Windows platform. Developers can use COM to create reusable software components, link components together to build applications, and take advantage of Windows services. Microsoft itself uses COM to make elements of its own applications available as services for integration into custom solutions.

Microsoft originally designed COM to enable communications between components and applications running on the same computer. COM was followed by DCOM (distributed COM), enabling applications to access components running on other computers over a network. DCOM was itself followed by COM+. COM+ incorporated features such as integration with Microsoft Transaction Server, enabling applications to group operations on components together into transactions so that the results of these operations could either be made permanent (committed) if they were all successful, or automatically undone (rolled back) if some sort of error occurred. COM+ provided additional capabilities, such as automatic resource management (for example, if a component connects to a database, you can ensure that the connection is closed when the application finishes using the component), and asynchronous operations (useful if an application makes a request to a component that can take a long time to fulfill; the application can continue processing, and the component can alert the application by sending it a message when the operation has completed). COM+ was followed in turn by the .NET Framework, which further extended the features available and renamed the technology as Enterprise Services. The .NET Framework also provided several new technologies for building networked components. One example was Remoting, which enabled a client application to access a remote object hosted by a remote server application as though it was running locally, inside the client application.

The Web and Web Services

Technologies such as COM, DCOM, COM+, Enterprise Services, and .NET Framework Remoting all work well when applications and components are running within the same local area network inside an organization. They are also specific to the Microsoft Windows family of operating systems.

While Microsoft was developing COM and DCOM, the World Wide Web appeared. The World Wide Web is based on the Internet, which has been around for several decades. The World Wide Web provides an infrastructure that enables developers to build applications that can combine components and other elements located almost anywhere in the world, running on computers of varying architectures, and executing using a bewildering array of operating systems (not just Windows). The first generation of “Web applications” was quite simple, consisting of static Web pages that users could download and view using a Web browser application running on their local computer. The second generation provided elements of programmability, initially through the use of components, or applets, that could be downloaded from Web sites and executed locally in the users’ Web browser. These have been followed by the third generation–Web services. A Web service is an application or component that executes on the computer hosting the Web site rather than the user’s computer. A Web service can receive requests from applications running on the user’s computer, perform operations on the computer hosting the Web service, and send a response back to the application running on the user’s computer. A Web service can also invoke operations in other Web services, hosted elsewhere on the Internet. These are global, distributed applications.

You can build Web services that execute on Windows by using Visual Studio 2005 and the .NET Framework. You can create Web services for other platforms by using other technologies, such as Java and the Java Web Services Developers Pack. However, Web services are not specific to any particular language or operating system. To establish Web services as a global mechanism for building distributed applications, developers had to agree on several points, including a common format for data, a protocol for sending and receiving requests, and handling security. All of these features had to be independent of the platform being used to create and host Web services.

Using XML as a Common Data Format

Different types of computers can store the same values by using different internal representations–computers based on a “big-endian” 32-bit processor use a different format for numeric data than a computer based on a “small-endian” 32-bit processor for example. So, to share data successfully between applications running on different computers, developers had to agree on a common format for that data that was independent of the architecture of the computer they were using. To cut a long story short, the currently accepted universal data format is eXtensible Markup Language, or XML. XML is text-based and human-readable (just), and lets you define a grammar for describing just about any type of data that you need to handle. In case you have not seen XML data before, here is an example:

 <Person>   <Forename>John</Forename>   <Surname>Sharp</Surname>   <Age>42</Age> </Person>

More Info 

For detailed information about XML and how you can use it, visit the XML.org Web site at http://www.xml.org.

Without trying too hard, you can probably guess what this data actually means. An application that needs to send information about a person to another application could format the data in this way, and the receiving application should be able to parse the data and make sense of it. However, there is more than one way to represent this information by using XML. You could also structure it like this:

 <Person Forename="John" Surname="Sharp" Age="42" />

There are many other variations possible as well. How does an application know how to format data so that another application can read it correctly? The answer is that both applications have to agree on a layout. This layout is referred to as the XML schema for the data. Now, this is neither the time nor the place to become embroiled in a discussion of how XML schemas work. Just accept that an application can use an XML schema to convey information about how the data it is emitting is structured, and the application receiving the data can use this schema to help parse the data and make sense of it.

So, by adopting XML and schemas as a common data format, applications running on different computers can at least understand the data that they are using.

More Info 

If you want to know more about XML schemas and how they work, visit the World Wide Web Consortium (W3C) Web site at http://www.w3.org.

Sending and Receiving Web Service Requests

Using XML and XML schemas to format data enables Web services and users’ (or client) applications to pass data back and forth in an unambiguous manner. However, client applications and Web services still need to agree on a protocol when sending and receiving requests. Additionally, a client application needs to be able to know what messages it can send to a Web service and what responses it can expect to receive.

To curtail another long story, Web services and client applications communicate with each other by using the Simple Object Access Protocol, or SOAP. The SOAP specification defines a number of things. The most important are the following:

• The format of a SOAP message

• How data should be encoded

• How to send messages

• How to handle replies to these messages

A Web service can advertise the messages that a client application can send it, and the responses the client application will receive, by publishing a Web Services Description Language (WSDL) document. A WSDL document is a piece of XML that conforms to a standard XML schema and that describes the messages the Web service can accept and the structure of the responses it will send back. A client application can use this information to determine how to communicate with the Web service.

More Info 

If you want detailed information about SOAP, visit the World Wide Web Consortium page at http://www.w3.org/TR/soap. If you want further information about WSDL, visit the page at http://www.w3.org/TR/wsdl.

Handling Security and Privacy in a Global Environment

Security is concerned with identifying users and services and then authorizing their access to resources. In a distributed environment, maintaining security is vitally important. In an isolated, non-networked, desktop environment, you could physically secure a PC to prevent an unauthorized user from typing on its keyboard or viewing its screen. When you connect computers together over a network, this is no longer sufficient; you now have to ensure that users accessing shared resources, data, and components running on a computer over a network have the appropriate access rights. Companies developing operating systems, such as Microsoft with Windows, incorporate many security features into their own platforms. Typically, these features include maintaining a list of users and the credentials that they use to identify these users, such as their passwords. These solutions can work well in an environment where it is possible to maintain such a list, such as within a single organization, but clearly it is not feasible to record identity and credential information for all computers and users accessing your services across the World Wide Web if you wish to make your services available outside of your enterprise.

A lot of research has been performed in understanding the challenges of maintaining security in a global environment, and many solutions have been proposed. To communicate in a secure manner, Web services and client applications need to agree on the form of security that they will use and how they will identify and verify each other. The Organization for the Advancement of Structured Information Standards (OASIS) is a consortium of organizations that have proposed a number of standard mechanisms for implementing security, such as using username/password pairs, X509 certificates, and Kerberos tokens. If you are creating Web services that provide access to privileged information, you should consider using one of these mechanisms to authenticate users.

More Info 

For detailed information about the OASIS security standards, visit the OASIS Web Service Security site at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss.

Privacy is closely related to security, and equally important, especially when you start to communicate with services on the World Wide Web. You don't want other users to be able to intercept and read the messages flowing between your applications and Web services. To this end, Web services and client applications must also agree on a mechanism to ensure the privacy of their conversations. Typically, this means encrypting the messages that they exchange. As with security, there are several mechanisms available for encrypting messages, the most common of which relies on using public and private keys.

More Info 

For a good overview and introduction to public key cryptography, visit the Wikipedia Web site at http://en.wikipedia.org/wiki/Public-key_cryptography.

Incorporating security and privacy into a Web service and client application can be a non-trivial task. To make life easier for developers building Web services using the Microsoft .NET Framework, Microsoft introduced the Web Services Enhancements (WSE) package. WSE is a fully supported add-on to Microsoft Visual Studio, designed to help you create Web services that retain compatibility with the evolving Web service standards. It provides you with wizards and other tools that you can use to generate much of the code necessary to help protect Web services and client applications and can simplify the configuration and deployment of Web services.

The Purpose of Windows Communication Foundation

So, by using Visual Studio, the .NET Framework, and WSE, you can quickly build Web services and client applications that can communicate and interoperate with Web services and client applications running on other operating systems. So why do we need WCF? Well, as you have already seen, Web services are just one technology that you can use to create distributed applications for Windows. Others already mentioned include Enterprise Services and .NET Framework Remoting. Another example is Microsoft Message Queue (MSMQ). If you are building a distributed application for Windows, which technology should you use, and how difficult would it be to switch later if you need to? The purpose of WCF is to provide a unified programming model for many of these technologies, enabling you to build applications that are as independent as possible from the underlying mechanism being used to connect services and applications together (note that WCF applies as much to services operating in non-Web environments as it does to the World Wide Web). It is actually very difficult, if not impossible, to completely divorce the programmatic structure of an application or service from its communications infrastructure, but WCF lets you come very close to achieving this aim much of the time. Additionally, using WCF enables you to maintain backwards compatibility with many of the preceding technologies. For example, a WCF client application can easily communicate with a Web service that you created by using WSE.

To summarize, if you are considering building distributed applications and services for Microsoft Windows, you should use WCF.