Read an Excerpt
Chapter 1
INTRODUCTION
What Are Web Services?
If you search the Internet, you will find an astounding variety of answers to the question "What is a web service?" The only common consensus is that web services share the following characteristics:
1. Web services use XML-based standards. As you will see in this book, web services are built on numerous APIs, standards, and protocols. Almost all of these systems use XML as a core component.
2. Web services use the Internet. In truth, most web services use standard Internet protocols, including HTTP and TCP/IP. However, web service technologies can also be deployed over messaging systems and other transport protocols.
3. Web services are platform- and language-neutral. You can build and deploy web services on almost any platform, using almost any language. Assuming you use the same version(s) of the same standard(s), a client developed in Java could easily use a web service developed in C# and hosted on Microsoft's Internet Information Services.
The next obvious question is "How can I use web services?" The answer to this question varies, depending on your specific need:
1. Linking legacy systems. If you work in a large corporation, you may want to take advantage of web services to provide cross-language and cross-platform compatibility. Why spend the time and money to rewrite your perfectly functional COBOL system in Java when you can develop a web service layer that allows your COBOL system to communicate with your new Java web portal?
2. Business to Business (B2B). The long-standing dream of simple, workable B2B communication can take a giant step forward with web services. Because web services work on open protocols, using XML you can develop B2B systems that actually work. No longer do you have to struggle with shared platforms or open large holes in your corporate firewall. Simply create straightforward web services that let your B2B partner build his own client using his own technology choices. Each side maintains control of the important pieces (technology choice, infrastructure, security, etc.), but both sides share a common, easy-to-understand set of services.
3. Service-based software. Web services open the door for many different types of service-based software. In the future, you may find small shell client programs that connect to a wide variety of web services on a subscription basis. The companies that host the web services can monitor your connections and charge you for each use. This approach may help prevent the ever-increasing bloat in common software packages.
A TYPICAL WEB SERVICE
A typical web service involves three distinct components. First, you need a contract that defines the service. Second, you need a producer, or host, for the service. Finally, you need a consumer, or client, to use, or consume, the service.
The Contract
The web service contract defines the name of the service, the service's input and output parameters, and how to communicate with the service. With some APIs the contract may also include information related to publication and discovery. In any case, the contract is always an XML document that follows a rigidly defined XML Schema (or dTD in some cases). The contract does not specify which software you have to use for either the server or client, nor does it specify security or transactional control.
The Producer
The producer generates the web service and hosts it. In most cases, the producer is a combination of a small-footprint web server with additional back end systems. The back end can be anything from a few simple stand-alone programs all the way up to enterprise systems using EJB. The real power of web services is that the contract isolates the producer from the client. The producer can use almost any back end system to host the service and provide the functionality, provided that the system can handle the appropriate web service standards.
The Consumer
The consumer, or client, finds the appropriate contract, connects to the producer, and uses the web service. In most cases, the client code is fairly simple and involves a few API calls. As with the producer, the consumer can use any technology that understands the web service API. The client program can be 100 percent pure Java even if the producer is using C# and IIS (or Apache and Perl for that matter).
The Roadmap
CodeNotes for Web Services is divided into seven chapters:
1. Introduction: The remainder of this chapter provides a short history of distributed computing and web services. We will also introduce you to the various standards, vendors, and technologies involved in building, promoting, and consuming web services. You may skip ahead to Chapter 3 if you want to see web services in action.
2. Installation: Throughout this book you will find web service examples built in a variety of languages and deployed on a variety of platforms, ranging from .NET and IIS, to Java and Apache. The installation chapter will show you the software and hardware requirements for building and supporting web services in each of these environments. Throughout this chapter you will find many CodeNotes pointers to more detailed installation instructions.
3. Simple Web Services: Chapter 3 consists of some simple web services built in various languages and implementations. This chapter is specifically designed to show you how easy web services are to build and to illustrate the basic web service framework. Once you have worked through this chapter, you will be better able to understand and appreciate the details of the various standards and systems in the remaining chapters.
4. SOAP and WSDL: The Simple Object Access Protocol, or SOAP, has emerged as a clear favorite among the various vendors pushing web services. SOAP is a pure XML-based standard for building and supporting web services. The Web Services Description Language, or WSDL, complements SOAP by providing a concise method for describing a web service. In this chapter, we will examine the details of both the SOAP and WSDL grammars.
5. Web Services in Java: In this chapter, we will take a detailed look at how web services can be developed using the Apache 2.2 SOAP API for Java. This chapter essentially builds on the examples in Chapter 3 and highlights the details specific to the Java implementation of SOAP and WSDL.
6. Web Services in .NET: In Chapter 6, we will look at how the .NET platform, and VS.NET in particular, can be used to build and use web services. This chapter also builds on the examples in Chapter 3 and highlights the details specific to web services in VB.NET and C#, built on VS.NET and IIS.
7. UDDI: The Universal Description, Discovery, and Integra-tion standard is both an XML-based directory service and a language-neutral specification for a web-based API to access the service. With regard to web services, the UDDI repository is the preferred place for storing WSDL documents and "publishing" your services to other businesses and the general public. In Chapter 7, we will examine the UDDI XML grammar, the API, and how you can use UDDI with web services.
In addition to these chapters, you can also find a short survey of several public web services at aWS010003.
Why Web Services: A History Lesson
Before you can understand why the concept of web services is so popular in computing literature, you must understand something of the history of distributed computing. In this section, we will take a quick look at the key technologies that have shaped distributed computing over the past ten years. These technologies and systems set the stage for web services and form the background against which web services will be measured.
DISTRIBUTED COMPUTING RPC, CORBA, AND COM
Almost as soon as businesses realized how powerful desktop PCs could be, the question arose of how to make two computers work together. Sharing files is a good start, but real applications require more than a common place to drop text files. The first attempts at solving the distributed computing dilemma or answering the question "How do I make my program talk to yours?" involved Remote Procedure Calls (RPC), Common Object Request Broker Architecture (CORBA), and Component Object Model (COM).
Remote Procedure Calls (RPC)
The first RPC implementations were available as early as 1988. In particular, Sun's RPC implementation (called Sun RPC or ONC RPC) was widespread and available for Unix platforms. Early RPC systems helped shape the way for many of the distributed computing technologies that followed. The DCE RPC standard, for example, introduced the concept of an Interface Definition Language (or IDL), which carried through CORBA and COM. The two major drawbacks of RPC are that it is vendor and platform dependent, and that it is strictly procedure based. This second limitation basically restricted RPC calls to low-level calls working with simple data types. For more information on the history of RPC, see aWS010004.
Common Object Request Broker Architecture (CORBA)
Depending on your computing platform, the next step forward in distributed computing was the Common Object Request Broker Architecture, or CORBA. The CORBA standard attempted to provide a language-neutral and platform-neutral system for passing around objects or pieces of code. Although you can use CORBA to perform simple procedure calls (like RPC), you can also use it to pass around full objects. The unfortunate drawbacks of CORBA were that early implementations were rather bulky and vendor dependent. Until the finalization of the IOR and IIOP protocols, it was difficult to make one vendor's Object Request Broker (ORB) talk to another vendor's ORB. Many of these problems have been resolved, but CORBA is still a rather large and complicated system to set up and maintain. For more information on CORBA, see aWS010005.
Component Object Model (COM/DCOM/COM+)
At the same time that the Unix world was working with CORBA (on Unix and Windows platforms), Microsoft developed and proposed the Component Object Model, or COM. The COM standard is similar to CORBA in many ways. In particular, you can use COM to work with either simple data types or more complex objects. However, the main drawback of COM was that it was designed to work on a single computer and restricted to the Windows platform. The next step for Microsoft was Distributed COM (DCOM) and the Microsoft Transaction Server (MTS). These technologies rapidly evolved into COM+. COM+ solved many of the early problems of COM and provided numerous additional services such as security and transaction control. However, all the COM variants are restricted to Windows operating systems. For more information on COM and its derivatives, see aWS010006.
XML AND THE WORLD WIDE WEB
Although the web service standards are new and evolving, the ideas behind web services go much further back into the history of the World Wide Web. In this section, we will take a quick look at several of the major technologies that are similar to web services but not part of the web service standards.
HTML
The HTML standard evolved in the early 1990s out of the Standard Generalized Markup Language (SGML), which was originally developed to support the growth of the electronic publishing industry. HTML has become ubiquitous along with the web and the Internet. With regard to web services, HTML can be thought of as one of the first. If you consider that a web browser issues a request over Internet protocols to a web server and that the web server returns a "string" of HTML in response, then a request for a web page is a web service and a web browser is a web service client. This paradigm is actually more appropriate if you are working with server-side content such as JSP, Servlets, PHP, or ASP.
RDF, RSS, and Content Syndication
The Resource Description Framework (RDF) and RDF Site Summary (RSS) are W3C standards developed by the various web-based news portals. Basically, the idea was to create a simple service that provided syndicated content. RDF and RSS provide XML-based standards and mechanisms for describing website content and sharing it with other news portals. Many of the major news sites support RDF and RSS as an alternative to "HTML scraping" and using frames to link content. In addition, many of the streaming news services use RDF and RSS to provide headlines. For more information on RDF and RSS, including links to websites using the technologies, see aWS010007.
BizTalk
Microsoft's BizTalk is an XML grammar that implements XML Schema data typing and a set of XML tags for transferring data between businesses. The BizTalk framework allows you to create BizTalk framework schemas, which are customized schemas that contain the data types and definitions used for your particular business. These schemas can be registered on the BizTalk website, http://www.biztalk.org, and then utilized by other businesses in the same industry, allowing them to integrate their B2B applications. In many respects, BizTalk provided the first commercial set of web services. For more information on BizTalk, see aWS010008.
