Home > Store

Understanding Web Services: XML, WSDL, SOAP, and UDDI

Register your product to gain access to bonus material or receive a coupon.

Understanding Web Services: XML, WSDL, SOAP, and UDDI


  • Sorry, this book is no longer in print.
Not for Sale



Key topics include:

  • XML facilities for structuring and serializing data.
  • How WSDL maps services onto communication protocols and transports.
  • WSDL support for RPC-oriented and document-oriented interactions.
  • SOAPs required and optional elements for Web services.
  • Message processing and the role of intermediaries in SOAP.
  • UDDI data formats.
  • SOAP APIs used to store and retrieve information from UDDI.
  • How ebXML offers an alternative to Web services that supports reliable messaging, security, and trading partner negotiations.


  • Copyright 2002
  • Dimensions: 7-3/8" x 9-1/4"
  • Pages: 368
  • Edition: 1st
  • Book
  • ISBN-10: 0-201-75081-3
  • ISBN-13: 978-0-201-75081-2

In Understanding Web Services, leading Web Services expert Eric Newcomer systematically addresses the core issues developers and IT professionals need to understand to make intelligent decisions about Web Services. Newcomer explains exactly how Web Services work, reviews each key standard for enabling Web Services, and previews tomorrow's most important products and technologies for Web Services development. Newcomer reviews the key goals and advantages of Web Services, the applications they are best suited for, and today's key standards for describing, sending, receiving, publishing, discovering, and utilizing them. He explains how Web Services are being built upon the foundation of XML technologies, then covers each key Web Services standard in detail: SOAP transport, WSDL services description, UDDI discovery services, and ebXML message exchange. Newcomer concludes with insightful, vendor-independent coverage of today's leading tools and products for Web Services development. For every IT manager, architect, developer, and strategist who wants a thorough understanding of Web Services.

Sample Content

Online Sample Chapters

Describing Web Services: WSDL

Introducing Web Services

Table of Contents

(NOTE: Each chapter concludes with a Summary.)




1. Introducing Web Services.

The Basics of Web Services.

A Simple Example: Searching for Information.

The Next Generation of the Web.

Interacting with Web Services.

RPC-Oriented Interactions.

Document-Oriented Interactions.

The Technology of Web Services.

Usage Example.

XML: The Foundation.

WSDL: Describing Web Services.

SOAP: Accessing Web Services.

UDDI: Publishing and Discovering Web Services.

XML for Business Collaboration: ebXML.

Web Services versus Other Technologies.

Additional Technologies.

Vendor Approaches to Web Services.

2. Describing Information: XML.

A Simple Example.

Instance and Schema.

Data Type and Programming Language.

More on XML Schemas and DTDs.

Processing XML Documents.





Document Structure.

Mapping Tools.

A Simple Example (Revisited).

XML Specifications and Information.

XML Specifications Related to Web Services.

General Information.

3. Describing Web Services: WSDL.

WSDL Basics.

WSDL Elements.

The Extensible WSDL Framework.

Defining Message Data Types.

Defining Operations on Messages.

Mapping Messages to Protocols.

Putting It All Together.

Importing WSDL Elements.

WSDL-Related Namespaces.

Extensions for Binding to SOAP.

4. Accessing Web Services: SOAP.

A Simple Example.

The SOAP Specification.

SOAP Envelope.

SOAP Header.

SOAP Body.

SOAP Faults.

I first encountered XML as an integration technology in early 1998 during a visit to KPN Telecom in The Netherlands. They were asking for proposals to help them develop an enterprise integration architecture based on the hub and spoke model, using XML as the canonical message format that would tie together their thousands of systems and hundreds of programming languages. My employer at the time, Compaq (Digital) did not win the project, but the controversial idea of using XML in a data-independent integration layer stuck with me. Now Web services are fulfilling that potential for everyone.

After joining IONA in the fall of 1999, among other things I ended up chairing the Object Management Group submitter's team drafting the XML Value specification, mapping XML to CORBA. In early 2000 I got involved in the new effort Microsoft was leading to define a distributed computing protocol for the Internet-SOAP. Previous attempts to promote the CORBA protocol had failed by then, and the W3C's own attempt, HTTP-NG, had also fallen flat. But the idea of serializing XML over HTTP seemed to hold promise for a solution.

IONA joined the SOAP effort in March 2000, before IBM joined and put the effort on the map. I worked with Andrew Layman, David Turner, John Montgomery, and others at Microsoft to bring IONA into the picture as a SOAP supporter--in fact, the first J2EE vendor to support SOAP. IONA demonstrated Web services interoperability at several Microsoft events during that year. The Microsoft presenter would introduce their SOAP Toolkit and demonstrate interoperability with a COM server. Then they would call on the IONA presenter to describe how the same SOAP interface could interoperate with a CORBA server.

After that, I organized IONA's initial participation at W3C, supported the establishment of the XML Protocols Working Group, helped write the group charter, and began representing IONA along with Oisin Hurley. IONA also supported the submission of SOAP to W3C, and WSDL, SOAP with Attachments, WSDL, and XKMS. One thing led to another, and eventually I took on the responsibility of delivering IONA's implementation of Web services technologies. I haven't had much time for committee work since then, but maybe now that this book is done, and our initial products released, I can jump back in.

In October of 2000, I attended the UDDI kick off meeting for IONA. It was at that meeting that I realized the potential for Web services technologies inside the firewall. Why not use UDDI and WSDL for internal integration projects? Then you can use the same approach for integration, regardless of whether it's inside the company or across the Internet.

David Vaskevitch presented at the UDDI conference, and this reminded me of the 1995 chapter that I co-authored for Digital Equipment Corporation for a book called The Future of Software. David was co-author of the Microsoft chapter in that same book. Digital's chapter was called "The Key to the Highway," and in it Peter Conklin and I compared the potential power of software standards to the impact of standards on the automobile. Standardized parts enabled mass production, which revolutionized industry and society. Today, software remains essentially a craft business, as automobiles were at the start of the twentieth century. Widely adopted standards have remained elusive, despite many attempts. We may be finally at the crossroads; Web services may finally do the trick.

I hope this book helps you understand what this Web services thing is all about. If it serves as a decent introduction to the main ideas, concepts, and technologies, it will have done its job, and found its place in the Web services community. One can only hope and aim for that.



Web services are changing the way we think about distributed software systems, but there's a limit to what they can do. This book describes the core enabling technologies--WSDL, SOAP, and UDDI--and identifies where Web services begin and end and where existing technologies take over.

This book describes the concepts behind the basic Web services technologies, and it also includes chapters on ebXML, additional Web services technologies, and product implementations. The book is intended for IT professionals who are interested in understanding Web services, how they work, and what they are good for.

About Web Services

Web services provide a layer of abstraction above existing software systems, such as application servers, CORBA, .NET servers, messaging, and packaged applications. Web services work at a level of abstraction similar to the Internet and are capable of bridging any operating system, hardware platform, or programming language, just as the Web is.

Unlike existing distributed computing systems, Web services are adapted to the Web. The default network protocol is HTTP. Most existing distributed computing technologies include the communications protocol as part of their scope. With Web services, the communications protocol is already there, in the far-flung, worldwide Web.

New applications become possible when everything is Web service enabled. Once the world becomes Web service enabled, all kinds of new business paradigms, discussion groups, interactive forums, and publishing models will emerge to take advantage of this new capability.

Software and hardware vendors alike are rushing Web services products to market. The widespread adoption of the core standards represents a significant breakthrough in the industry. Applications can truly be built using a combination of components from multiple suppliers. Specialists are emerging to provide services in the areas of security, transaction coordination, bill processing, language translation, document transformation, registries and repositories, accounting, reporting, and specialized calculation. Applications being built anywhere, anytime, on any system can take advantage of prebuilt components, speeding time to market and reducing cost.

Meanwhile, ebXML, which chartered and maintains a separate course, continues to solve tough problems for corporate trading partners that are establishing automated supply chain purchasing and invoicing systems, large electronic document transfers, and business communities sharing common goals. The rightful heir to EDI, ebXML is providing an easier-to-use, lower-cost alternative to businesses automating their interactions with other businesses. With ebXML, a company's internal IT systems are connected to the IT systems of its trading partners, subcontractors, and business collaborators. The value inherent in these systems is therefore greatly increased, as they become essentially part of one large IT system, with essential information flowing freely across corporate boundaries rather than stuck within them.

Considerable overlap exists between the core Web services technologies and ebXML. Convergence between the two is based on their common adoption of SOAP as the transport and on the ability of the respective registries to share data. The ebXML specifications include many qualities-of-service requirements that are not yet included in Web services, such as message integrity and nonrepudiation, reliable messaging, business process flow, and protocol negotiation. Further convergence is possible as the core Web services technologies begin to adopt proposals in these additional technology areas.

Disagreement remains over the best approach to defining these additional technologies in the context of Web services. Once the core standards are adopted widely, the discussion moves up the stack to tackle quality-of-service issues. Security, transactions, process flow, and reliable messaging standards are needed, and some are further along than others.

The power of XML drives Web services technologies in general, whether it's the core standards, additional technologies, or ebXML. XML finally solves the problem of data independence for programming languages, middleware systems, and database management systems. Previously, data types and structures were specific to these types of software, and attempts at common definitions, such as CORBA IDL, gained limited acceptance. XML is well on its way to becoming as well established as its sibling, HTML.

The Web services technologies described in this book are all created using applications of XML in one way or another. XML is not one thing but rather a variety of technologies in itself, covering instance data as well as typing, structure, and semantic information associated with data. XML not only describes data independently but also contains useful information for mapping the data into and out of any software system or programming language.

Web services provide almost unlimited potential. Any program can be mapped to Web services, and Web services can be mapped to any program. Transformation of data to and from XML is essential, but XML is flexible enough to accommodate any data type and structure and even to create new ones, if necessary. When all programs and software systems are finally Web service enabled, the world of distributed computing will be very different from what it is today.

About This Book

To provide a background and sufficient detail for practical understanding and use of these technologies, this book is organized into chapters on the main topics of interest.

Chapter 1, Introducing Web Services

This chapter highlights the most important aspects of Web services and what they can be used for, as well as contains a detailed overview of the entire book. Information is provided about the following:

  • XML (Extensible Markup Language), the family of related specifications on which all Web services technologies are built
  • WSDL (Web Services Description Language), providing the fundamental and most important abstraction of Web services, the interface exposed to other Web services and through which Web services are mapped to underlying programs and software systems
  • SOAP (Simple Object Access Protocol), providing communications capability for Web services interfaces to talk to one another over the Internet and other networks
  • UDDI (universal description, discovery, and integration), providing registry and repository services for storing and retrieving Web services interfaces
  • ebXML (electronic business XML), an architecture and set of specifications designed to automate business process interaction among trading partners
  • Additional technologies, going beyond the core Web services standards to meet requirements for security, reliable messaging, transaction processing, and business process flow so that more complex and critical business applications can use them
  • Vendor implementations, providing a variety of implementations usually aligned with existing products but in some cases entirely new products for flexible and extensible Web services

Chapter 2, Describing Information: XML

The Extensible Markup Language (XML), like the Hypertext Markup Language, shares a common ancestry in the Standard Generalized Markup Language (SGML). One of the characteristics of SGML was the separation of format and content. Whether a document was produced for A4 or in letter format, for example, the format was described independently of the content of the document. The same document could therefore be output in multiple formats without changing the content. This principle of markup languages is applied to Web services through the separation of the document instance, which contains the data, and the schema, which describes the data structures and types, including semantic information useful for mapping the document to multiple programming languages and software systems.

XML represents a large number of specifications, many of which are more pertinent to document processing than to information processing. This chapter describes the XML specifications and technologies most important to Web services, which in general can be said to go "beyond markup" to provide facilities for structuring and serializing data. This chapter includes only those XML technologies relevant to Web services and explains how and what they are.

Chapter 3, Describing Web Services: WSDL

The Web Services Description Language (WSDL) provides the mechanism through which Web services definitions are exposed to the world and to which Web services implementers need to conform when sending SOAP messages. WSDL describes the data types and structures for the Web services, explains how to map the data types and structures into the messages that are exchanged, and includes information that ties the messages to underlying implementations.

WSDL is defined so that its parts can be developed separately and combined to create a comprehensive WSDL file. The data types and structures can be shared among multiple messages, as can the definition of the services exposed within the interface. WSDL lists the interfaces and, within an interface, associates each service with an underlying implementation.

In order to achieve communication for Web services, WSDL maps them onto communication protocols and transports. Both parties in a Web services interaction share a common WSDL file. The sender uses the WSDL file to generate the message in the appropriate format and to use the appropriate communication protocol. The receiver uses the WSDL file to understand how to receive and parse the message and how to map it onto the underlying object or program.

Chapter 4, Accessing Web Services: SOAP

Once an interface is defined for them, Web services need a way to communicate with one another and to exchange messages. The Simple Object Access Protocol (SOAP) defines a common format for XML messages over HTTP and other transports. SOAP is designed to be a simple mechanism that can be extended to encompass additional features, functionalities, and technologies.

This chapter describes the parts of SOAP and the purpose of each. SOAP is a one-way asynchronous messaging technology that can be adapted and used in a variety of message-passing interaction styles: remote procedure call (RPC) oriented, document oriented, and publish and subscribe, among others.

If anything defines the minimum criterion for a Web service, it must be adherence to SOAP. SOAP messaging capability is fundamental to Web services. SOAP is defined at a very high level of abstraction and can be mapped to any number of underlying software systems, including application servers, .NET servers, middleware systems, database management systems, and packaged applications.

The chapter describes the required and optional parts of SOAP, explains how SOAP messages are processed, and discusses the role of intermediaries in SOAP message processing. Background information on the specification is provided, as are examples of the major SOAP parts. An explanation of SOAP with Attachments is also included.

Chapter 5, Finding Web Services: UDDI Registry

The initiative for universal description, discovery, and interoperability (UDDI) produces specifications and an active implementation of a repository for Web services descriptions. The UDDI registry can be searched using various categorization criteria to obtain contact information for businesses offering services of interest. UDDI provides a publicly accessible means to store and retrieve information about Web services interfaces and implementations.

This chapter describes the UDDI data formats and the SOAP APIs used to store and retrieve information from UDDI. This chapter also provides background on the UDDI organization that sponsors the physical registry and the process by which UDDI specifications and technologies are moving toward adoption.

The Web needs something like UDDI to provide a clearinghouse for Web services information so that publishers and consumers can find each other. Only then can the true value of Web services be realized: when Web services consumers can easily and quickly locate and begin accessing Web services implementations anywhere in the world.

Chapter 6, An Alternative Approach: ebXML

The electronic business XML (ebXML) initiative was started around the same time that the Web services community began to grow. For the first several months, ebXML was an entirely separate and parallel effort. Many of the goals of ebXML are common to Web services, and many of the technologies overlap in concept. In general, however, ebXML is focused more at the industrial or enterprise computing level, addressing as the top goal the issue of business process definition.

This chapter explains the background, goals, and origin of ebXML and covers the ebXML architecture in detail. Individual specifications are described and placed into their proper context within the overall architecture.

The ebXML architecture includes many of the same things as the core Web services technologies but goes beyond them in defining quality-of-service requirements for reliable messaging, security, and trading-partner negotiation. Beginning as a replacement for EDI, ebXML seeks to avoid some of the problems with EDI implementations and acceptance, especially in smaller businesses.

Chapter 7, Web Services Architecture: Additional Technologies

After the core Web services technologies are implemented and adopted, a whole range of additional technologies is needed to enable Web services to address complex and critical application requirements. Businesses will need to secure their Web services against unauthorized use, to guarantee that their SOAP messages arrive at their intended destinations and are processed reliably, and to define and execute automated business process flows according to a standard mechanism.

This chapter describes these and other technologies in the context of the vendor and industry initiatives in which they are likely to progress toward adoption. In some cases, competing proposals vie for adoption, and the leading candidates are discussed. The chapter also includes descriptions of two technologies on which many Web services concepts are based: RosettaNet and XML-RPC.

Chapter 8, Implementing Web Services

Web services specifications and technologies are not meaningful or particularly useful without implementations in software vendor products. This chapter summarizes the major architectural approaches to Web services implementation, describes the major development communities of .NET and J2EE, and presents information supplied by BEA Systems, Cape Clear, IBM, IONA, Microsoft, Hewlett-Packard, Oracle, Sun Microsystems, and Systinet on their current product offerings and views of the future.

Some vendors tend to view Web services implementations primarily within the context of their existing products, as additional clients or adapters into and out of the existing application servers, database management systems, and middleware systems. Other vendors seek to mine the value of the Web services layer itself, where multiple, disparate software system domains are put into relationship and integrated. Other vendors offer products in multiple categories, including some aimed purely at providing an implementation of Web services standards as well as some aimed at exposing Web services interfaces to existing products.

Although vendors tend to agree on the adoption and widespread implementation of the core standards, very little, if any, agreement exists at the next level; that is, what should come next. Security, transactions, process flow, and reliable messaging are all part of various vendors' plans but in somewhat differing orders and levels of importance.


Submit Errata

More Information

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020