In this chapter, we provide the information you need to understand the basic principles behind XML Web services. We begin with a discussion of what constitutes an XML Web service and describe the benefits of this exciting new technology. We then take you on a tour of the protocols and standards that make XML Web services work.
XML Web services are a category of software components that provide functionality over a network. This broad definition of XML Web services can be qualified with the following characteristics that are normally present:
Interaction with XML Web services is usually performed using standard Internet protocols. These include well-established Internet standards such as Transmission Control Protocol/Internet Protocol (TCP/IP), Hypertext Transfer Protocol (HTTP), and Extensible Markup Language (XML), but also include new standards that have been developed specifically for use with XML Web services, such as the Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL), and Universal Discovery, Description, and Integration (UDDI). We discuss the protocols and technologies used to implement XML Web services in the section "XML Web Services Standards and Protocols" later in this chapter.
An XML Web service is rarely a complete application and is most frequently a functional component of a larger solution. As such, XML Web services are primarily oriented toward program-to-program interaction.
XML Web services expose functionality through well-defined interfaces. In this case, we are not talking about user interfaces such as those on Web pages or in Microsoft Windows applications, but programmatic interfaces defined using a standardized interface description language such as WSDL. These definitions provide enough detail for a programmer to use the functionality provided by an XML Web service. WSDL is discussed in the section "Data Integration, Aggregation, and Analysis" later in this chapter.
XML Web services are advertised in a directory, which may be public or private depending on the nature of the XML Web service and the scope of its audience. The process of registering and finding XML Web services in a directory is defined by the UDDI standard. We provide more detail on UDDI in the section "Extending and Integrating Applications" later in this chapter.
The definition of XML Web services we provided in the previous section is rather abstract and does not provide a clear picture of how they can be used; some examples will help to clarify this situation.
Note
It is important that you understand the meaning of the following terms in the context of XML Web services:
A consumer is the entity that interacts with an XML Web service to make use of the functionality it provides. A consumer is most often a software component acting on behalf of a person or a larger system.
A provider is the person or company that creates an XML Web service and makes it available for use by consumers.
The most common type of XML Web service provides programmatic access to information; for example, stock prices, currency exchange rates, plane arrival times, and language translation. This information might already be accessible to humans electronically in the form of a Web page or a document or via a proprietary system. However, in these forms the information can be difficult to access and manipulate programmatically. With an XML Web service, the information is available through a well-defined interface and is accessed using standard protocols and data representations. Any device or program, regardless of platform or implementation language, can communicate with the XML Web service across the network to access the information. The possibilities for such services are endless; any information provision scenario is a prime target for delivery using an XML Web service model.
Instead of providing information to a consumer, an XML Web service can just as easily act as a repository of information. This capability allows many applications across different platforms to share and manipulate the same information. Services such as Internet-based calendars and file storage are perfect examples of situations in which an XML Web service adds value. These services would allow people access to their information irrespective of their locations or the platforms they are using. The centralization of information also opens opportunities for people to give trusted third parties access to their information.
A critical mass of simple services providing information across a broad range of subject areas, coupled with the centralization and accessibility of user information, opens many opportunities for applications and intermediary XML Web services. The ability to access so much data programmatically regardless of its location and host platform presents opportunities to create new and compelling services derived from the component data. For example, if every transportation company made its bus, train, and plane timetables available for programmatic interrogation via XML Web services, an application or intermediary XML Web service could use the information to plan the optimal route between two places. If a person had travel plans and a flight time was changed, the airline could automatically update this information in the customer’s Web-based calendar.
Companies often have significant ties to existing enterprise information systems. Sometimes, successful long-lived systems become problematic because they lack the capabilities to easily share information with newer applications, or the platform they run on makes it difficult to integrate with current technologies.
XML Web services can integrate legacy systems into modern IT solutions. The technologies required for XML Web service communications are simple and exist on most computing platforms. Using an XML Web service as a layer of abstraction between clients and a legacy system has numerous benefits. Many new client platforms gain access to the legacy system, and the XML Web service can coordinate activities across multiple systems as it processes client requests.
XML Web services do not predicate an architecture in which many clients consume services from a central source. XML Web services are equally applicable to highly distributed peer computing solutions or to situations in which a central source is responsible for pushing information to many distributed clients. In these situations, the XML Web service is not running at the server, but rather at the client end. Processes running on the server connect to the XML Web service running on the client. The automated distribution of software updates or a real-time news service that pushes information to consumers are examples of this model.
As you can see from the examples, the XML Web services model provides some interesting capabilities. However, these capabilities are achievable using other application models. The benefits of XML Web services stem not so much from what they do as how they do it.
The principle benefit of XML Web services is integration. The cost to businesses of trying to integrate disparate applications, systems, and technologies is staggering. XML Web services are a widely agreed-on standard that represents the perfect integration tool, providing a mechanism to communicate and exchange information between disparate systems, offering real interoperability and significant cost-savings. We highlight some of the key benefits of XML Web services in the following sections.
Being standards based means that all XML Web service implementations operate in the same way, use the same protocols, and encode data consistently, which makes consuming XML Web services a simple process no matter what platform the service and consumer are running on.
The standards used by XML Web services are developed in an open, community-based manner, with contributions from technology vendors, general business, and academia. This consensual approach gives XML Web services protection from monopolization by a single vendor; while the standards allow for innovation and proprietary features, the core of the XML Web services technology is open and neutral.
The architecture and technologies used by XML Web services are simple in comparison with many other distributed computing solutions. Although the number of standards and protocols employed in the field of XML Web services can be confusing, a programmer does not necessarily need to understand them because they are abstracted by operating systems and modern development tools such as Microsoft Visual Studio .NET.
The only requirements for consuming an XML Web service are the ability to communicate over TCP/IP and the ability to process XML. XML Web services do not enforce the use of any particular programming language or operating system. A program written in C (a procedural language) running on a handheld device can consume an XML Web service written in C# (an object-oriented language) that’s running on a Windows 2000 server.
XML Web services not only provide a layer of abstraction between disparate technologies and programming languages but also offer the ability to provide functional abstraction. The functionality exposed by an XML Web service does not need to map directly to the underlying functional implementation. An XML Web service may provide an interface that aggregates the underlying functionality of more than one system. For example, an XML Web service that provides information about the weather might take temperature information from one system and tidal information from another to provide a more comprehensive weather service.
A key addition to the XML Web service model is the important and well-defined role played by service registries. Service registries offer a mechanism by which providers can advertise their services and consumers can find them.
As with all component-based development architectures, the reuse of existing XML Web services as components of new solutions can reduce the time and cost of development. XML Web services take component reuse to a new level by allowing many consumers to use the same component simultaneously and by enabling the sharing of components across organizational boundaries.
In addition, because the XML Web service protocols are all text based, developers can read them and more easily understand what is going on. This simplifies the debugging of problems and is a significant advantage over other distributed computing technologies that rely on binary protocols.
Despite the immaturity of the XML Web service model, it has strong industry support and has captured the interest of both commercial organizations and programmers. This broad interest provides the field of XML Web services with momentum, but the technology faces many challenges before it can be considered a successful and staple part of computing.
The immaturity of the XML Web service model (especially some of the newer technologies) is perhaps the biggest challenge the field faces today. Many of the technologies on which XML Web services are based are yet to be standardized, and the current technologies simply don’t provide an answer to many issues, such as security, transactions, and message routing.
The success of the XML Web service model depends on the consumer. By consumer, we do not mean people buying things; we are referring to people and companies willing to use XML Web services as a component of the solutions they develop. XML Web service providers clearly need to build useful and compelling services to attract consumers, but if consumers do not embrace these new services, XML Web services will fail. We see two major issues that will affect consumer adoption:
Human Nature
Many simple XML Web services provide information in response to some form of request, such as a stock quote or a train arrival time. People are familiar and comfortable with this type of service and will adopt them with little resistance. The chances are that such services will flourish rapidly.
However, there is a big difference between simple information services and what the technology evangelists and marketers are predicting will be possible in the future. Many predictions revolve around the use of XML Web services to provide massive and complex integration of many disparate devices and systems. Frequently, these visions paint the picture of omnipresent and near omnipotent systems that dynamically share information to coordinate the activities of people, control machinery and appliances, automate decision-making processes, and execute commercial transactions.
These more revolutionary uses of XML Web services will expose people to situations with which they are unfamiliar and possibly uncomfortable. Some of these future uses might simply be too extreme for the majority of people to accept.
Commercial Issues
Technology often runs ahead of legislation and business processes. This is particularly true of XML Web services, which overlap the business side of an organization more than many technologies.
Some proponents of XML Web services propose a model in which a consumer can dynamically discover and use a service without any form of human interaction. Unfortunately, current commercial practices do not lend themselves to such free-wheeling automation. Today, businesses might have multiple suppliers of a product or service, but they do not shift fluidly between one supplier of a service and another. Nor do they generally enter into agreements with companies without undertaking a level of due diligence. This might involve meeting people, visiting facilities, establishing service level agreements, and putting contracts in place.
The automation of commercial transactions works between closed sets of counterparties in which contractual and commercial terms are determined or operate within a set of flexible, but agreed-on rules. It is hard to imagine a day when a company delegates authority to a computer system to dynamically search out a supplier of widgets, negotiate a price, and place an order.
Companies that adopt XML Web services as a solution for the delivery of services to their customers face the uncertainty of the unproven business model provided by XML Web services. Currently, far more work is going on to figure out how to make the technology work than to figure out how to charge for a service and make it a profitable business model.
One of the benefits of the XML Web service model is its simplicity relative to other distributed computing solutions. This simplicity is apparent in the protocols that are used and enhanced by the tools provided by vendors to simplify the development and consumption of XML Web services. As the XML Web service model is applied to solutions that are more sophisticated, it will hit many of the barriers faced by other distributed computing technologies. The challenge facing the architects of the XML Web service model is to maintain simplicity while allowing the technology to expand to meet future needs. This is a difficult balancing act.
A major benefit of XML Web services stems from the fact that they are built on standards developed and agreed to by many organizations. Should this consistency break down, XML Web service consumption would be a frustrating process, having to deal with many variants of the supposed standards. The challenges facing consistency come from two areas:
Speed of Adoption
People and companies are embracing XML Web services with such enthusiasm that the limits of the defined technologies are already being tested and found wanting in key areas such as security. The inability of the standards processes to stay ahead of the technology innovators forces vendors and companies to make unilateral technology decisions.
Conflicting Requirements
Not all vendors have the same vision for the future of XML Web services, and not all companies will use them in the same way. XML Web services are a generic solution that can be applied to many problem domains across many different industries. The needs of one industry can be very different from the needs of others. This often gives rise to industry-specific or problem-specific extensions to technologies. The challenge for the architects of XML Web service standards is to maintain consistency under the pressure of conflicting requirements.
IT solutions are all too often developed and deployed without giving adequate thought to the operational requirements of the system. The success of an XML Web service will depend on many factors, but reliability, performance, and security are key areas of concern to the service’s consumers. XML Web services are designed to be a key point of interaction between companies and their partners and customers. Decades of operational experience have shown companies how best to manage their systems, and many tools are available to test and support the operation of the system. However, XML Web services are being thrust into key roles within companies with little experience in their management and operation and that lack the advanced tools to monitor and support them.
Although XML Web services are a new technology, they make use of many relevant protocols and standards that you should already be aware of. In this section, we provide an overview of the technologies that form the basis of XML Web services. We do not go into detailed discussions of each technology; our goal is merely to provide you with a frame of reference from which you can more easily understand the programming topics covered in later chapters. One of the main benefits of using Visual Studio .NET is that you can develop complex XML Web services without understanding any of the underlying technologies.
Although there is broad consensus about the content of the current specifications used to provide XML Web services, some of the standards and protocols are still undergoing regular revision to meet the needs of a wide range of industries and users. The entire field is in a state of flux, and new features, protocol versions, and specifications are constantly being produced. The following illustration shows a simplified view of the technologies that are used in XML Web services. Each of these is discussed in the following sections.
The key to using an XML Web service is having a formalized description of the functionality it exposes. The purpose of the discovery technologies is to enable a developer to obtain the description of an XML Web service so that the developer can use it as a component in the system being developed. This section describes the two forms of discovery that are most applicable to Visual Studio .NET developers.
UDDI (Universal Description, Discovery and Integration) is an initiative to provide a registry of XML Web services. In simple terms, UDDI provides a directory of companies that can be searched using a company name, the industry in which a company operates, and the region in which a company offers services. Each company record contains details of the purpose and location of the XML Web services it’s made available.
UDDI aims to bridge the gap between those companies developing and publishing XML Web services and programmers trying to locate and consume them. Without UDDI, consuming an XML Web service requires a programmer to know about the service’s existence, purpose, and location through some other mechanism.
At the time of writing, there are three publicly available UDDI registries, one maintained by IBM (http://www.ibm.com/services/uddi/), one by SAP (http://uddi.sap.com/), and the other by Microsoft (http://uddi.microsoft.com). Each of the public UDDI registries contains the same information, and new entries are replicated to all of the hosting organizations. Currently, there is no reason to use one registry provider over another, although the need to choose one registry or another is likely to change as the market for XML Web services matures and competition increases.
Companies can also establish private UDDI registries to list the services available within their private network. While this approach is feasible only for large organizations, it does foster the idea of reusing XML Web services wherever possible.
DISCO (short for discovery) files are a proprietary Microsoft format that allows a Web site to advertise the XML Web services that are available on it. Each DISCO file contains information about one or more XML Web services, including references to the description files, which are discussed in the following section.
DISCO and UDDI are complementary technologies. DISCO differs from UDDI in that in using it, a programmer who is seeking an XML Web service must already know about the Web site that offers the services. Currently, the main consumer of DISCO files is Visual Studio .NET. Other providers of XML Web service products have been slow adopting this technique. Given the proprietary nature of the DISCO file format, it is unlikely that it will be prevalent outside Microsoft products.
The principle benefit of DISCO is simplicity. DISCO allows departments and small organizations to facilitate simple XML Web service discovery without having to create and maintain a full UDDI registry.
Once an XML Web service has been discovered (using UDDI or DISCO), we need a way to understand what interactions the service supports. Clients that consume XML Web services need to know how to interact with a service before they can use it. Obtaining a description of the service is the ultimate goal of the discovery process described previously.
The Web Services Description Language (WSDL) is the standard means of describing an XML Web service. WSDL is an XML format for describing interactions and contains information about each message that can be sent to the service and the kind of response (if any) that will be returned. WSDL documents provide the basis for a contract that tells the client how the XML Web service will behave. Although fundamentally simple, WSDL documents often need to describe complex interactions and can become long and confusing. Fortunately, Visual Studio .NET negates the need for you to work directly with WSDL, so you do not need to understand how these documents are structured.
Once we have discovered an XML Web service and obtained the document that describes the interactions available, we are able to send messages to the service to make use of its functionality. We don’t have to send these messages manually (or even be aware of the message contents) because Visual Studio .NET integrates XML Web services into development projects using proxy classes. We discuss proxies in the section "Proxy Objects" later in this chapter.
The Simple Object Access Protocol (SOAP) has been adopted as the preferred mechanism used to send messages between clients and XML Web services. Messages include requests from the client instructing the XML Web service to perform a task and the response from the service detailing the result. Like many of the other standards and protocols that are part of Web services, SOAP is based on XML.
SOAP is not tied to any particular programming language or operating system, which means a client written in the Java programming language can understand messages sent by an XML Web service written using C# or Microsoft Visual Basic .NET. The price of this neutrality is that not all of the features of a programming language can be represented using a SOAP message. For more information about the limitations of SOAP, see Chapter 6.
All of the protocols and standards we have described are based on the Extensible Markup Language (XML). This book is not an XML primer, and, because we do not list the contents of XML documents, we will not cover this topic. For the purposes of this book, it is sufficient to know that every aspect of XML Web services uses XML (hence the name).
The transport is the mechanism used to send SOAP messages over a network. The most common means of doing this is the Hypertext Transfer Protocol (HTTP), which was selected because it is simple, ubiquitous, and can be used over the Internet with ease. HTTP is the protocol that is used to request and receive the contents of Web pages, although in recent years the protocol has been adapted for a wide range of uses. XML Web services are only the most recent technology to adopt this protocol.
Although effective over the Internet, HTTP is not particularly efficient, and efforts are underway to standardize the use of XML Web services over other protocols, such as the Simple Mail Transport Protocol (SMTP), that require less bandwidth or offer performance improvements. As XML Web service technology matures, a range of standards will likely emerge that allow XML Web services to operate easily over technologies such as message queues. For the moment, however, HTTP is the transport of choice.
Now that we have identified the standards and protocols, we can fit these pieces together to describe the basic architecture of an XML Web service. The following diagram shows XML Web service architecture from the perspective of the Microsoft .NET Framework.
The diagram illustrates the relationship between the technologies and protocols described in the previous sections and shows how the client uses them sequentially.
The first three steps allow the client to locate a description of the XML Web service, defined by a WSDL document. The discovery step is specific to Microsoft products, and XML Web services created by other tools may skip this step and place references in the UDDI registry that point directly to the WSDL description.
The process of using the directory, processing the discovery document, and obtaining the description are performed only once. From the perspective of the Visual Studio .NET programmer, the purpose of these steps is to create a proxy object that can be used by the XML Web services client.
A .NET XML Web service proxy (more commonly called just a proxy) is the glue between the .NET Framework and an XML Web service. It allows a programmer to make use of the service quickly and easily. A proxy is a C# or Visual Basic .NET class that exposes the functionality of the XML Web service via methods.
Without a proxy, a programmer must handle all of the interactions with the XML Web service manually, using the WSDL document as a reference to the operations that are supported. This approach would require that each SOAP message sent to the server be crafted manually and each response parsed for data or errors—an error-prone and painstaking procedure.
With the proxy, a programmer can access the XML Web service in the same way that any other .NET Framework class is used; calling the methods of the class results in SOAP messages being sent and received automatically, without requiring direct interaction. Visual Studio .NET creates proxy objects automatically, further freeing a programmer from the details of the underlying technology and significantly reducing the scope for introducing errors. We demonstrate how proxy objects are created in Chapter 4.
The key .NET technology for developing XML Web services is ASP.NET, which is the next generation of the Active Server Pages (ASP) platform. ASP.NET provides a framework for developing Web-based applications in which the user interacts with a service using a browser. (Think of sites such as Amazon.com that use Web pages to sell books and other merchandise.)
Although the main emphasis of ASP.NET is to build conventional Web applications, Microsoft has added support for building XML Web services as well. The discussion of this support is the essence of this book.
You do not need to understand the workings of ASP.NET to develop XML Web services, and the majority of ASP.NET features have no relevance to this book. However, some advanced features can be applied to your projects, and we discuss these in Chapter 10, and Chapter 12.
In this chapter, we began our exploration of XML Web services. We defined what an XML Web service is and provided examples of real-world situations in which XML Web services are applicable. We described the high-level capabilities of XML Web services and their benefits, also listing situations in which we think XML Web services do not represent the best solution. After reading this chapter, you should have a basic understanding of the standards and protocols that XML Web services rely on and how these are linked to form the basic XML Web service architecture.
We have tried to emphasize that although the technologies used by XML Web services can be complex, the relationships between them are simple, and that the designers of Visual Studio .NET have put a huge amount of effort into freeing programmers from dealing with the painstaking low-level details.
Armed with an increased understanding of XML Web services, you’ll be better able to see through the hype surrounding this technology and the products from specific vendors. By continuing to read this book, you will learn in more detail about the technical architecture of XML Web services as well as how to create and use them.