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

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.

0201750813P02062002

Introduction

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.



Updates

Submit Errata

