Web Services

A Web service is a means of exposing application logic or data via standard protocols such as XML or SOAP (Simple Object Access Protocol). A Web service comprises one or more function endpoints, packaged together for use in a common framework throughout a network. Web services provide access to information through standard Internet protocols, such as HTTP/HTTPS. A Web Services Description Language (WSDL) contract is used to detail the input and output requirements for calling the interface. Consumers of the Web service can learn about the structure of the data the Web service provides, as well as all the details about how to actually consume this data, from the WSDL. A WSDL provides a detailed description of the remote interface offered from the Web service.

This simple concept provides for a very wide variety of potential uses by developers of Internet and intranet applications alike. Today, the Web services model is often the heart of the next generation of systems architecture because it is all of the following:

• Architecturally neutral—Web services do not depend on a proprietary wire format, schema description, or discovery standard.
• Ubiquitous—Any service that supports the associated Web service standards can support the service.
• Simple—Creating Web services is quick and easy. The data schema is human readable. Any programming language can participate.
• Interoperable—Because the Web services all conform to the same standards, and use common communication protocols, they are not concerned about the technology of the application calling them.

In basic terms, a Web service is an interface with an XML document describing all of the methods and properties available for use by the caller. Any body of code written in just about any programming language can be described with this XML document, and any application that understands XML (or SOAP) over the assigned protocol (such as HTTP) can access the object. That's because the parameters you type after the function name are passed via XML to the Web service, and because SOAP is an open standard.

Web services are remarkably easy to deploy. The power of Web services comes from the use of the WSDL contract. In addition, Web services are inherently cross-platform, even when created with Microsoft products. The standard XML schemas are part of the WSDL specification.

The key is that even though this protocol may not be as efficient or fast as some of the binary protocols of the past, its implementation-agnostic contracts make it more useful. Given that you can create a communication protocol that is either available for use by 50% of users and which runs superfast versus one that is available to 100% of users and runs fast, the tendency will be to adopt the solution with greater reach. Thus, Web services became the interoperability baseline for service communication.

For this reason, they best represent where the Internet is heading—toward an architecturally neutral collection of devices, rather than millions of PCs surfing the World Wide Web. Encapsulating code so that you can simply and easily enable cell phones to use your logic is a major boon to developers, even if they do not realize it yet.

How This All Fits Together

Microsoft's support for Web services really took off with the introduction of .NET. However, support was available to have Web services run on older operating systems like Windows NT4 SP6, with the SOAP Toolkit installed.

The .NET Framework encapsulated the Web service protocol into objects. This was great initially, but as noted earlier, over time it was generally agreed that not every communication needed to be put up as a HTTP/HTTPS-based service. WCF was the result of Microsoft taking a look at the common concepts from all of the preceding communication technologies and seeking a unified solution.

While Web services remain one of the most common underlying implementations for WCF services, the reality is that they are now a subset of what you can do with WCF. Things like the WS-* protocols become configuration settings; similarly, you can have a single interface that supports multiple different communication protocols. Thus, the same service that is used with a client that supports a binary transfer protocol like Remoting can communicate via HTTP protocol for a client that doesn't support those binary protocols.

WCF is now an integrated part of the service-oriented architecture strategy. Historically, the starting place on MSDN for Web Services was http://msdn.microsoft.com/webservices, but that link was retired. Now for WCF in .NET 4.5, you'll want to start at: http://msdn.microsoft.com/dd456779.aspx. It's not that Web services have gone away or become less important, it's simply that Web services are a subset of the complete WCF communication framework.

The goal of WCF is to provide a loosely coupled, ubiquitous, universal information exchange format. Toward that end, SOAP is not the only mechanism for communicating with WCF services.

What Makes a WCF Service

A WCF service consists of three parts:

A service is a class that is written in (or in the case of Interop, wrapped by) one of the .NET-compliant languages. The class can contain one or more methods that are exposed through the WCF service. A service can have one or more endpoints, which are used to communicate through the service to the client.

Endpoints themselves are also made up of three parts. These parts are usually defined by Microsoft as the “ABC” of WCF. Each letter of WCF means something in particular in the WCF model. Similarly,

• “A” is for address
• “B” is for binding
• “C” is for contract

Basically, you can think of this as follows: “A” is the where, “B” is the how, and “C” is the what. Finally, a hosting environment is where the service is contained. This constitutes an application domain and process. All three of these elements (the service, the endpoints, and the hosting environment) together create a WCF service offering, as depicted in Figure 11.1.

Figure 11.1 Logical diagram of the implementation layers of a service

The core idea is that when you want to create an enterprise architecture supporting multiple different applications, the most appropriate protocol will vary depending on how a service is currently being used. Having a unified strategy that allows you, as a developer, to specify a given endpoint and how that endpoint communicates means that the same underlying implementation can power multiple different endpoints. Thus, questions of security and performance can be viewed on a per-connection basis. This enables an organization to create a service-oriented architecture (SOA).