![handful of facets of Web services that can appear at several levels of the wire stack.
There is no well-accepted standard for these facets, but work is underway in these areas.
The Description Stack
The wire stack is only where the capabilities of Web services begin. Even the simplest
example of Web service use shows the need for a higher level of interoperability.
Consider the following situation (we'll see this example in greater detail in Chapter 3). A
company has provided an inventory checking service, allowing customers to determine
whether a particular number of items are in stock for a given product code (as
represented as a stock keeping unit [SKU]). The Web service takes as parameters a
string representing the SKU and an integer representing the number of units needed. If
the company has on hand the requested number of units, the Web service responds with
a Boolean true value; otherwise, the response is a Boolean false.
From a pure SOAP perspective, the interaction with this Web service is trivial. However,
things get much more complicated when we consider how much common understanding
must exist between the service requestor and the service provider. For the interaction to
succeed, at a minimum, the service requestor needs to know the following:
• The address of the Web service.
• It should make requests and receive responses over HTTP.
• It should use SOAP 1.1.
• Requests and responses should use the SOAP data encoding.
• Requests will be RPC requests containing as parameters a string SKU
and an integer indicating the desired quantity.
• Responses will be RPC responses containing a Boolean indicating the
inventory check outcome.
Throw in security, payments, error handling, and other capabilities required to build
enterprise-grade Web services, and the need for shared knowledge expands even
further…. How can the service requestor acquire this information? Well, traditionally Web
services have advertised their capabilities in some human readable form. Developers
have read the description of these capabilities and configured user applications to be able
to communicate with particular Web services.
While this approach works in principle, it is not scalable for many reasons:
• It requires costly (in terms of both time and money) manual
configuration by highly skilled, and therefore scarce, personnel.
• It is error prone because it does not utilize formalized service
specifications.
• It precludes automatic discovery and engagement of Web services; a
priori knowledge is required for configuration of the user
application.](https://image.slidesharecdn.com/2216908-250610162334-18f79d31/85/Building-Web-Services-With-Java-Making-Sense-Of-Xml-Soap-Wsdl-And-Uddi-1st-Steve-Graham-31-320.jpg)
![Document-Centric XML
Because of its SGML origins, in the early days of its existence XML gained rapid adoption
within publishing systems as a mechanism for representing semi-structured documents
such as technical manuals, legal documents, and product catalogs. The content in these
documents is typically meant for human consumption, although it could be processed by
any number of applications before it is presented to humans. The key element of these
documents is semi-structured marked-up text.
The following markup is a perfect example of XML used in a document-centric manner.
The content is directed towards human consumption—it's part of the FastGlide
skateboard user guide. The content is semi-structured. The usage rules for tags such as
<B>, <I> and <LINK> are very loosely defined; they could appear pretty much anywhere
in the document:
<H1>Skateboard Usage Requirements</H1>
<P>In order to use the <B>FastGlide</B> skateboard you have to
have:</P>
<LIST>
<ITEM>A strong pair of legs.</ITEM>
<ITEM>A reasonably long stretch of smooth road surface.</ITEM>
<ITEM>The impulse to impress others.</ITEM>
</LIST>
<P>If you have all of the above, you can proceed to <LINK
HREF="Chapter2.xml">Getting on the Board</LINK>.</P>
Data-Centric XML
By contrast, data-centric XML is used to mark up highly structured information such as
the textual representation of relational data from databases, financial transaction
information, and programming language data structures. Data-centric XML is typically
generated by machines and is meant for machine consumption. It is XML's natural ability
to nest and repeat markup that makes it the perfect choice for representing these types
of data.
Consider the purchase order example in Listing 2.1. It is a purchase order from the
Skateboard Warehouse, retailer of skateboards to SkatesTown. The order is for 5
backpacks, 12 skateboards, and 1,000 SkatesTown promotional stickers (this is what the
stock keeping unit [SKU] of 008-PR stands for).
Listing 2.1 Purchase Order in XML
<po id="43871" submitted="2001-10-05">
<billTo>
<company>The Skateboard Warehouse</company>
<street>One Warehouse Park</street>
<street>Building 17</street>
<city>Boston</city>
<state>MA</state>
<postalCode>01775</postalCode>
</billTo>
<shipTo>
<company>The Skateboard Warehouse</company>
<street>One Warehouse Park</street>
<street>Building 17</street>
<city>Boston</city>](https://image.slidesharecdn.com/2216908-250610162334-18f79d31/85/Building-Web-Services-With-Java-Making-Sense-Of-Xml-Soap-Wsdl-And-Uddi-1st-Steve-Graham-39-320.jpg)
![<state>MA</state>
<postalCode>01775</postalCode>
</shipTo>
<order>
<item sku="318-BP" quantity="5">
<description>Skateboard backpack; five pockets</description>
</item>
<item sku="947-TI" quantity="12">
<description>Street-style titanium skateboard.</description>
</item>
<item sku="008-PR" quantity="1000">
</item>
</order>
</po>
The use of XML is very different from the previous user guide example:
• The ratio of markup to content is high. The XML includes many
different types of tags. There is no long-running text.
• The XML includes machine-generated information; for example, the
submission date of the purchase order uses a date-time format of
year-month-day. A human authoring an XML document is unlikely to
enter a date-time value in this format.
• The tags are organized in a highly structured manner. Order and
positioning matter, relative to other tags. For example,
<description> must be under <item>, which must be under <order>,
which must be under <po>. The <order> tag can be used only once in
the document.
• Markup is used to describe what a piece of information means rather
than how it should be presented to a human.
In short, if you can easily imagine the XML as a data structure in your favorite
programming language, you are probably looking at a data-centric use of XML. An
example Java class that could, with a bit more work, be used to represent the purchase
order data is shown here:
class PO
{
int id;
Date submitted;
Address billTo;
Address shipTo;
Item order[];
}
Document Lifetime
Document- and data-centric uses of XML can differ in one other very significant aspect—
the lifetime of the XML document. Typically, XML documents for human consumption
(such as technical manuals and research papers) live a long time because the](https://image.slidesharecdn.com/2216908-250610162334-18f79d31/85/Building-Web-Services-With-Java-Making-Sense-Of-Xml-Soap-Wsdl-And-Uddi-1st-Steve-Graham-40-320.jpg)
![UTF-8 is a variable-length character encoding standard that generates 7-bit safe output.
This type of output makes it easy to move XML on the Internet using standard
communication protocols such as HTTP, SMTP, and FTP. Keep in mind that XML is
internationalized by design and can support other character encodings such as Unicode
and ISO/IEC 10646. However, for simplicity and readability purposes, this book will use
UTF-8 encoding for all samples.
If you omit the XML declaration, the XML version is assumed to be 1.0, and the
processing application will try to guess the encoding of the document based on clues
such as the raw byte order of the data stream. This approach has problems, and
whenever interoperability is of high importance—such as for Web services—applications
should always provide an explicit XML declaration and use UTF-8 encoding.
XML document prologs can also include comments that pertain to the whole document.
Comments use the following syntax:
<!-- Sample comment and more ... -->
Comments can span multiple lines but cannot be nested (comments cannot enclose other
comments). Everything inside the comment markers will be ignored by the processing
application. Some of the XML samples in this book will use comments to provide you with
useful context about the examples in question.
With what you have learned so far, you can extend the purchase order example from
Listing 2.1 to include an XML declaration and a comment about the document (see Listing
2.2).
Listing 2.2 XML Declaration and Comment for the Purchase Order
<?xml version="1.0" encoding="UTF-8"?>
<!-- Created by Bob Dister, approved by Mary Jones -->
<po id="43871" submitted="2001-10-05">
<!-- The rest of the purchase order will be the same as before -->
...
</po>
In this case, po is the root element of the XML document.
Elements
The term element is a technical name for the pairing of a start and end tag in an
XML document. In the previous example, the po element has the start tag <po> and the
end tag </po>. Every start tag must have a matching end tag and vice versa. Everything
between these two tags is the content of the element. This includes any nested elements,
text, comments, and so on.
Element names can include all standard programming language identifier characters ([0-
9A-Za-z]) as well as underscore (_), hyphen (-), and colon (:), but they must start with
a letter. customer-name is a valid XML element name. However, because XML is case-
sensitive, customer-name is not the same element as Customer-Name.
According to the XML Specification, elements can have three different content types.
They can have element-only content, mixed content, or empty content. Element-only
content consists entirely of nested elements. Any whitespace separating elements is not
considered significant in this case. Mixed content refers to any combination of nested
elements and text. All elements in the purchase order example, with the exception of
description, have element content. Most elements in the skateboard user guide
example earlier in the chapter had mixed content.](https://image.slidesharecdn.com/2216908-250610162334-18f79d31/85/Building-Web-Services-With-Java-Making-Sense-Of-Xml-Soap-Wsdl-And-Uddi-1st-Steve-Graham-42-320.jpg)
![(>); ampersand (&); apostrophe, a.k.a. single quote ('); and quote, a.k.a. double quote
("). Table 2.1 shows the syntax for escaping these characters.
Table 2.1. Pre-defined XML Character Escape Sequences
Character Escape sequence
< <
> >
& &
' '
" "
For example, to include a chunk of XML as text, not markup, inside an XML document, all
special characters should be escaped:
<example-to-show>
<?xml version="1.0"?>
<rootElement>
<childElement id="1">
The man said: "Hello, there!".
</childElement>
</rootElement>
</example-to-show>
The result is not only reduced readability but also a significant increase in the size of the
document, because single characters are mapped to character escape sequences whose
length is at least four characters.
To address this problem, the XML Specification has a special multi-character escape
construct. The name of the construct, CDATA section , refers to the section holding
character data. The syntax is <![CDATA[, followed by any sequences of characters
allowed by the document encoding that does not include ]]>, followed by ]]>. Therefore,
you can write the previous example much more simply as follows:
<example-to-show><![CDATA[
<?xml version="1.0"?>
<rootElement>
<childElement id="1">
The man said: "Hello, there!".
</childElement>
</rootElement>
]]></example-to-show>
A Simpler Purchase Order
Based on the information in this section, we can re-write the purchase order document as
shown in Listing 2.4.
Listing 2.4 Improved Purchase Order Document
<?xml version="1.0" encoding="UTF-8"?>
<!-- Created by Bob Dister, approved by Mary Jones -->
<po id="43871" submitted="2001-10-05">
<billTo id="addr-1">
<company>The Skateboard Warehouse</company>
<street>One Warehouse Park</street>
<street>Building 17</street>](https://image.slidesharecdn.com/2216908-250610162334-18f79d31/85/Building-Web-Services-With-Java-Making-Sense-Of-Xml-Soap-Wsdl-And-Uddi-1st-Steve-Graham-49-320.jpg)
Building Web Services With Java Making Sense Of Xml Soap Wsdl And Uddi 1st Steve Graham
- 1. Building Web Services With Java Making Sense Of Xml Soap Wsdl And Uddi 1st Steve Graham download https://ebookbell.com/product/building-web-services-with-java- making-sense-of-xml-soap-wsdl-and-uddi-1st-steve-graham-4433816 Explore and download more ebooks at ebookbell.com
- 2. Here are some recommended products that we believe you will be interested in. You can click the link to download. Building Web Services With Java Making Sense Of Xml Soap Wsdl And Uddi 2nd Edition 2nd Edition Steve Graham https://ebookbell.com/product/building-web-services-with-java-making- sense-of-xml-soap-wsdl-and-uddi-2nd-edition-2nd-edition-steve- graham-2128566 Building Restful Web Services With Java Ee 8 Create Modern Restful Web Services With The Java Ee 8 Api Paperback Marioleander Reimer https://ebookbell.com/product/building-restful-web-services-with-java- ee-8-create-modern-restful-web-services-with-the-java-ee-8-api- paperback-marioleander-reimer-10416642 Building Restful Web Services With Java Ee 8 Marioleander Reimer Marioleander Reimer https://ebookbell.com/product/building-restful-web-services-with-java- ee-8-marioleander-reimer-marioleander-reimer-7261842 Developing Restful Services With Jaxrs 20 Websockets And Json A Complete And Practical Guide To Building Restful Web Services With The Latest Java Ee7 Api Bhakti Mehta https://ebookbell.com/product/developing-restful-services-with- jaxrs-20-websockets-and-json-a-complete-and-practical-guide-to- building-restful-web-services-with-the-latest-java-ee7-api-bhakti- mehta-5468964
- 3. Building Restful Web Services With Spring 5 Leverage The Power Of Spring 50 Java Se 9 And Spring Boot 20 2nd Edition 2nd Edition Raja Csp Raman https://ebookbell.com/product/building-restful-web-services-with- spring-5-leverage-the-power-of-spring-50-java-se-9-and-spring- boot-20-2nd-edition-2nd-edition-raja-csp-raman-38560882 Building Web Services With Microsoft Azure Quickly Develop Scalable Restbased Applications Or Services And Learn How To Manage Them Using Microsoft Azure Alex Belotserkovskiy https://ebookbell.com/product/building-web-services-with-microsoft- azure-quickly-develop-scalable-restbased-applications-or-services-and- learn-how-to-manage-them-using-microsoft-azure-alex- belotserkovskiy-5468056 Building Web Services With Abap And Sap Web Application Server 2003 Sap https://ebookbell.com/product/building-web-services-with-abap-and-sap- web-application-server-2003-sap-11146956 Building Restful Web Services With Go Learn How To Build Powerful Restful Apis With Golang That Scale Gracefully 1st Edition Naren Yellavula https://ebookbell.com/product/building-restful-web-services-with-go- learn-how-to-build-powerful-restful-apis-with-golang-that-scale- gracefully-1st-edition-naren-yellavula-52767254 Building Restful Web Services With Net Core Developing Distributed Web Services To Improve Scalability With Net Core 20 And Aspnet Core 20 Gaurav Aroraa Tadit Dash https://ebookbell.com/product/building-restful-web-services-with-net- core-developing-distributed-web-services-to-improve-scalability-with- net-core-20-and-aspnet-core-20-gaurav-aroraa-tadit-dash-11077150
- 5. Building Web Services with Java™: Making Sense of XML, SOAP, WSDL, and UDDI By Steve Graham, Simeon Simeonov, Toufic Boubez, Doug Davis, Glen Daniels, Yuichi Nakamura, Ryo Neyama Publisher : Sams Publishing Pub Date : December 12, 2001 ISBN : 0-672-32181-5 Pages : 600 Slots : 1 The Web services approach is the next step in the evolution of distributed computing. Based on open industry standards, Web services enable your software to integrate with partners and clients in a fashion that is loosely coupled, simple, and platform- independent. Building Web Services with Java: Making Sense of XML, SOAP, WSDL, and UDDI presents the concept of Web services and explains how to incorporate Web services into your business. The book addresses emerging standards associated with Web services, such as Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL), and Universal Description Discovery and Integration (UDDI). Copyright Copyright © 2002 by Sams Publishing
- 6. All rights reserved. No part of this book shall be reproduced, stored in a retrieval system, or transmitted by any means, electronic, mechanical, photocopying, recording, or otherwise, without written permission from the publisher. No patent liability is assumed with respect to the use of the information contained herein. Although every precaution has been taken in the preparation of this book, the publisher and author assume no responsibility for errors or omissions. Nor is any liability assumed for damages resulting from the use of the information contained herein. Library of Congress Catalog Card Number: 2001090920 Printed in the United States of America First Printing: December 2001 04 03 02 01 4 3 2 1 Trademarks All terms mentioned in this book that are known to be trademarks or service marks have been appropriately capitalized. Sams Publishing cannot attest to the accuracy of this information. Use of a term in this book should not be regarded as affecting the validity of any trademark or service mark. Warning and Disclaimer Every effort has been made to make this book as complete and as accurate as possible, but no warranty or fitness is implied. The information provided is on an "as is" basis. The authors and the publisher shall have neither liability nor responsibility to any person or entity with respect to any loss or damages arising from the information contained in this book. Executive Editor Michael Stephens Acquisitions Editor Michael Stephens Development Editor Tiffany Taylor Managing Editor Matt Purcell Project Editor Christina Smith Copy Editor Tiffany Taylor Indexer
- 7. Eric Schroeder Proofreader Plan-It Publishing Technical Editor Chad Fowler Craig Pfiefer Team Coordinator Pamalee Nelson Media Developer Dan Scherf Interior Designer Anne Jones Cover Designer Aren Howell Page Layout Heather Stephenson About the Authors Steve Graham is an architect in the Emerging Technologies division of IBM Software Group. He has spent the last several years working on service-oriented architectures, most recently as part of the IBM Web Services Initiative. Prior to this, Steve worked as a technologist and consultant on various emerging technologies such as Java and XML, and before that he was an architect and consultant with the IBM Smalltalk consulting organization. Before joining IBM, Steve was a developer with Sybase, a consultant, and a faculty member in the Department of Computer Science at the University of Waterloo. Steve holds a BMath and MMAth in computer science from the University of Waterloo. You can reach him at sggraham@us.ibm.com. Simeon (Sim) Simeonov has been developing software for more than 15 years. Sim's areas of expertise encompass object-oriented technology, compiler theory, Internet tools, enterprise computing, and the broad spectrum of XML technologies. As chief architect at Macromedia Inc., Sim provides direction for the evolution of the company's technology and product strategy as well as the architecture of its server-side platform products. Previously, Sim was chief architect at Allaire Corporation, where his initiatives brought about numerous innovations to the core product lines. Sim is currently working on service-oriented architectures for the next generation of distributed XInternet applications. He is actively involved with the Java Community
- 8. Process in the areas of Internet applications, XML, and Web Services. Sim also represents Macromedia on the W3C working group on XML Protocol. He is a regular speaker at conferences and a monthly columnist for XML Journal. Sim holds a B.A. in Computer Science, Economics, and Mathematics and a MSc in Computer Science. Toufic Boubez is the chief technology officer of Saffron Technology. Prior to joining Saffron, he was a senior technologist in IBM's Emerging Technologies group, and lead architect of IBM's Web services initiative. He was IBM's technical representative to the UDDI Web Services Consortium with Microsoft and Ariba and co-authored the UDDI API specification. He was also the IBM technical lead on the UN/CEFACT/OASIS ebXML initiative and helped drive IBM's early XML and Web services strategies. Dr. Boubez has more than 15 years of experience in IT and has published and presented on Web services, XML, object technology, distributed computing, intelligent agents, B2B, business modeling, simulation, neural networks, and wavelet analysis. He holds a doctorate in Biomedical Engineering from Rutgers University. Doug Davis works in the Emerging Technology organization of IBM, working on IBM's Web Services Toolkit, and he is one of IBM's representatives in the W3C XML Protocol working group. Previous projects include WebSphere's Machine Translation project, TeamConnection, and IBM's FORTRAN 90 compiler. Doug has a Bachelor of Science degree from the University of California at Davis and a Master's degree in Computer Science from Michigan State University. Glen Daniels, in his 13 years in the software industry, has run the gamut from device drivers and network stacks up through user interface and Web site work, in everything from assembly language to C++ to Lisp. Distributed computing has always been a passion, and as such he is currently technical lead for the JRun Web Services team at Macromedia. Glen is an active member of the W3C XML Protocol group as well as one of the lead developers of Axis. When not coding, he can often be found playing bass or harmonica, hanging out with his many crazy friends in the Boston area, or relaxing with his cats. Yuichi Nakamura is an advisory researcher at the IBM Tokyo Research Laboratory. His research interests are Web services including SOAP and XML security, object-oriented systems, J2EE, multiagent systems, B2B e-commerce, and knowledge engineering. He received an MSc and a PhD in Applied Physics from Osaka University in 1987 and 1990, respectively. Ryo Neyama is a researcher at the IBM Tokyo Research Laboratory. His research interests are distributed object systems including Web services, object request brokers, and security. He received an MSc in Information and Computer Science from Waseda University in 1999. Acknowledgments To Karen, Erin and Jessie, my family, my inspiration. For all the moments sacrificed to create this book, my most heartfelt thanks for your understanding. My thanks to my coworkers at IBM, and in particular the WSTK team for doing such an outstanding job. My thanks also to Rod Smith for fostering an excellent environment for creative work. My thanks also to the staff at Sams, particularly Tiffany Taylor and Michael Stephens, for the hard work that went into making this project a reality. Romans 12:2. —Steve Graham
- 9. It is much easier to write a book when others believe you can. My deepest thanks to Pyrra: my true love and a constant source of inspiration. Thanks also to all my friends and co-workers who never stopped being interested in Web services and the progress of the book. See? It's done. —Sim Simeonov To Lucy and Yasmine: Thank you for your patience, love, and understanding. This was a major undertaking for a new dad with another full-time job. To my old IBM team, Sam Adams, Steve Burbeck, Jay Casler, Steve Graham, Maryann Hondo, and Rod Smith, thank you for the great, challenging, and receptive work environment. I seriously don't think the concept of Web services would have evolved to where it is today in a different environment. To my new team at Saffron, thank you for replicating that environment! —Toufic Boubez Lin—I owe so many things to your patience, support, and most of all your sense of humor. I can never say it enough, but thank you. —Doug Davis For all my friends and family who so patiently continue to be there for me through even the busiest times—love and thanks to all of you. —Glen Daniels To Michiyo: Thank you for your understanding and patience during this work. Thanks to my kids, Arisa and Ryotaro: You always made me happy with your lovely smiles. My thanks to all XML and Security team members at IBM Tokyo Research Laboratory. —Yuichi Nakamura My thanks to my parents, Jun and Sachie, for bringing me up and always supporting me. My thanks also to Takako and my friends for their encouragement and understanding. My thanks to my coworkers at IBM Tokyo Research Laboratory for their deep insights on Web services and related technologies. —Ryo Neyama Tell Us What You Think! As the reader of this book, you are our most important critic and commentator. We value your opinion and want to know what we're doing right, what we could do better, what areas you'd like to see us publish in, and any other words of wisdom you're willing to pass our way. As an Executive Editor for Sams Publishing, I welcome your comments. You can fax, e- mail, or write me directly to let me know what you did or didn't like about this book—as well as what we can do to make our books stronger. Please note that I cannot help you with technical problems related to the topic of this book, and that due to the high volume of mail I receive, I might not be able to reply to every message. When you write, please be sure to include this book's title and authors' names as well as your name and phone or fax number. I will carefully review your comments and share them with the authors and editors who worked on the book. Fax: 317-581-4770
- 10. E-mail: feedback@samspublishing.com Mail: Michael Stephens Executive Editor Sams Publishing 201 West 103rd Street Indianapolis, IN 46290 USA Introduction Welcome to the world of Web services! This is a rapidly evolving set of standards and implementation technologies that have great promise for the world of application integration and distributed computing. Before we get going, we need to clarify some things about the purpose and structure of the book. Let's talk about them now. Goals of this Book The overall goal of this book is to familiarize you with the concept of Web services and what it will take to incorporate Web services as part of your business. We will introduce the concept of Web services and give you a framework that describes how you can position the various emerging standards that are associated with Web services, such as Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL), and Universal Description Discovery and Integration (UDDI). We will help position Web services from a business and technical perspective, explaining and demonstrating how Web services can be used to address various business problems, particularly related to application integration. Another goal of this book is to help developers understand the issues and details related to building Web services using the techniques covered by this book. What pieces are required when you're planning a Web services strategy? What things do you need to take care of when developing Web services? We provide lots of examples and running code to demonstrate these approaches. We also review in detail the Apache Axis Web services infrastructure with our running examples. Other tools and Web services infrastructures are discussed as well, but not in the same detail as Axis. Assumed Background This book is meant for computing technical professionals with some experience building Web applications and distributed computing systems. You don't need to be a seasoned veteran of the distributed object wars to appreciate this book, but some familiarity with Web-based architectures and techniques such as HTTP and HTML is assumed. If you do not have any experience with these techniques, some of the material could be a little confusing—particularly some of the code examples—but you should still be able to get a lot out of this book. We assume you are familiar with Java, and in particular the Java Server Pages (JSP) and Java servlet technologies. We also briefly discuss the relationship between Enterprise Java Beans (EJBs) and Web services, so some familiarity with EJBs is helpful as well. If you need to supplement your understanding of these techniques, many, many good books on programming with Java, JSP, servlets, and EJB are available on the market.
- 11. You will also discover that the Extensible Markup Language (XML) is at the core of all things dealing with Web service. Although we devote an entire chapter to explaining the core pieces of XML needed to build Web services, the more understanding of XML you have, the more successful you will be in building Web services. Philosophy It is difficult to structure a book on Web services. The concepts and standards are very much interdependent. It is hard to cover each topic in isolation, because it is the combination of these concepts and standards that make Web services important to distributed computing. The philosophy of this book can be summarized by four points: pragmatics, progressive disclosure, a running example, and a service-oriented architecture framework. Pragmatics In this book, we try to get to programming examples and running code as quickly as possible. In particular, we focus on building and consuming SOAP-based Web services using the Apache Axis Web services infrastructure. This is a Java-centric approach to building Web services. Whereas we emphasize that Web services are fundamentally programming language neutral, ultimately, any given Web service is implemented in some programming language technology. In the case of this book, we have chosen Java. Where issues of interoperability with Web services written in other programming languages might appear, we note them. Detailed coverage of other Web services implementation approaches, such as Microsoft's .NET, is beyond the scope of this book, although we do give some basic examples of .NET and other environments in Chapter 8, "Interoperability, Tools, and Middleware Products." Progressive Disclosure After the overview of Web services, we start with the fundamentals of XML, and then layer on new concepts, motivated by a business computing problem. These layers produce a series of Web services technology "stacks." For each of the technologies and standards in the Web services arena, we focus on understanding the technology from the perspective of what problems it solves, balancing the explanation of the technology itself. Running Example The technologies and standards that make up the Web services concept are each examined in the context of a running example (which we discuss later in this introduction). The use of the running example adds insight to the explanation of the concept in the text of the book and supports the progressive disclosure approach as we follow the example, adding the layers of Web services technology to the solution. This approach helps position various best-practices approaches to Web service development and deployment. You can download the source code for these running examples from www.samspublishing.com. When you reach that page, enter this book's ISBN number (0672321815) in the search box to access information about the book and a Source Code link. Service-Oriented Architecture The examples and Web services concepts are discussed in the context of a service- oriented architecture (SOA) that we introduce in Chapter 1, "Web Services Overview." We use the SOA framework to help position the various Web services concepts back into a bigger picture. Overview of the Book's Composition
- 12. Chapter 1 begins the book with an explanation of what the Web services approach is all about. We describe what a Web service is, what standards and technologies are associated with Web services, and what problems can be solved using Web services. We use this chapter to introduce the SOA conceptual framework and begin to explain how the various Web services standards such as SOAP, WSDL, and UDDI fit together. This chapter will give you a solid conceptual basis for the rest of the book. Before we can get into the core Web services standards, we take a brief side trip to explain XML in Chapter 2, "XML Primer." Because XML is at the heart of all the Web services standards and techniques, it is important you understand it well. XML is a huge topic, but we focus our examination of XML on what you will need to know in order to understand the rest of the Web services topics. After the review of XML, Chapter 3, "Simple Object Access Protocol (SOAP)," dives in to the core problem of invoking a Web service. We review the topic of XML messaging in a distributed computing environment, focusing on the SOAP message enveloping standard. SOAP forms the core basis of communication between a service requestor and a service provider in a Web services environment. Chapter 4, "Creating Web Services," refines your understanding of SOAP in the context of a particular SOAP infrastructure: the Apache Axis project. Chapter 4 dives into the details of how Axis works and how you can use it to make it easy to deploy Web services and have your applications consume Web services. At this point, you will have a great background understanding of SOAP and at least one way to make SOAP real: Axis. But SOAP alone is not enough to do more than very simple Web services. Chapter 5, "Using SOAP for e-Business," adds detail to the concepts introduced in Chapters 3 and 4 by explaining how you can build Web services for complete business computing problems. Chapter 5 discusses how Web services addresses many distributed computing problems including security, performance, quality of service, reliability, and so on. Chapter 6, "Describing Web Services," introduces the important notion of service description, which is key to making Web services the great application integration technology for building loosely coupled systems. Chapter 6 discusses how Web services uses service description to address the problem of communicating what details the service requestor needs to know about the Web service in order to properly understand how (and why) to invoke it. Now, you need to understand how the service requestor got the service description in the first place. Chapter 7, "Discovering Web Services," picks up where Chapter 6 left off, discussing the various techniques for Web service discovery. This chapter examines the standards related to finding what Web services are provided by businesses with which a company might want to collaborate. Chapter 8, "Interoperability, Tools, and Middleware Products," fills out your understanding of best practices in the Web services arena by examining various other Web services infrastructure and tooling environments. The book concludes with a forward-looking Chapter 9, "Future Concepts," which speculates on some possible future uses of Web services technologies to address other problems in distributed computing. Note This book introduces quite a few terms with which you might not be familiar. We have included a glossary at the back of this book that acts as a great reference guide to the terminology used in the book. We will annotate the first use of each term appearing in the glossary using the symbol.
- 13. So, before we get started, let's introduce the fictional company we'll use for our examples throughout this book: SkatesTown. We will follow SkatesTown as the company exploits Web services to improve its business. Introducing SkatesTown SkatesTown is a small but growing business in New York founded by three mechanically inclined friends with a passion for cars and skateboards. They started by designing and selling custom pre-built boards out of Dean Carroll's garage, and word soon spread about the quality of their work. They came up with some innovative new construction techniques, and within months they had orders piling up. Now SkatesTown has a small manufacturing operation in Brooklyn, and the company is selling boards, clothing, and equipment to stores around the city. Dean, Frank Stemkowski, and Chad Washington couldn't be happier about how their business has grown. Of the three, Chad is the real gearhead, and he has been responsible for most of the daring construction and design choices that have helped SkatesTown get where it is today. He's the president and head of the team. Frank, gregarious and a smooth talker ever since childhood, now handles marketing and sales. Dean has tightly tracked the computer revolution over the years, and is chief technical officer for the company. A few years back, Dean realized that networking technology was going to be big, and he wanted to make sure that SkatesTown could catch the wave and utilize distributed computing to leverage its business. This focus turned out to be a great move. Dean set up a Web presence so SkatesTown could help its customers stay up-to-date without requiring a large staff to answer phones and questions. He also built an online order-processing system to help streamline the actual flow of the business with network- enabled clients. In recent months, more and more stores who carry SkatesTown products have been using the system to great effect. Our Story Begins… At present, Dean is pretty happy with the way things are working with SkatesTown's electronic commerce systems. But there have been a few problems, and Dean is sure that things could be even better. He realizes that as the business grows, the manual tasks associated with order gathering and inventory resupply will limit the company's success. Always one to watch the horizon, Dean has heard the buzz about Web services, and wants to know more. At the urging of a friend, he got in touch with Al Rosen, a contractor for Silver Bullet Consulting. Silver Bullet specializes in Web services solutions, and after a couple of meetings with Al, Dean was convinced—he hired SBC to come in, evaluate SkatesTown's systems, and help the company grow into a Web service–enabled business. As we move through the rest of the book, we'll keep an eye on how SkatesTown uses technologies like XML and, later, SOAP, WSDL, and UDDI to increase efficiency, productivity, and establish new and valuable relationships with its customers and business partners. Silver Bullet, as we'll see, usually lives up to its name. Chapter 1. Web Services Overview IN THIS CHAPTER • What Is a Web Service? • The Web Service Opportunity
- 14. • Trends in e-business • Why Do We Need a Web Services Approach? • Service-Oriented Architectures • Web Services Interoperability Stacks In this chapter, we will provide the basic terminology and set of concepts that put the remainder of the book into context. We will define what we mean by a Web service and describe situations in which Web services will play an important role. We will describe a simple framework, called service-oriented architecture , that helps structure the application of Web services technologies. We will also provide a framework, in the form of three "interoperability" stacks that position how the various Web services technologies such as Simple Object Access Protocol (SOAP) , Web Services Description Language (WSDL) , and Universal Description Discovery and Integration (UDDI) relate. The rest of the book, then, is an elaboration of the basic concepts presented here. What Is a Web Service? This is a book about building Web services. We cannot describe how to build a Web service without first clarifying what we mean by a Web service. The term Web services has gained a lot of momentum in the last year. Many software vendors (large and small) are announcing Web services initiatives and adoption (see the sidebar "Web Services Market Dynamics"). Many organizations are involved in the refinement of Web services standards. Although there seems to be a slow convergence towards a common understanding of what the term means, there is no single, universally adopted definition of what is meant by the term Web service. This situation is reminiscent of the early days of object-oriented programming: Not until the concepts of inheritance, encapsulation, and polymorphism were well defined did object-oriented programming become accepted into the mainstream of development methodologies. Several major Web services infrastructure providers have published their definitions for a Web service: IBM offers this definition at http://www4.ibm.com/software/solutions/Webservices/pdf/WSCA.pdf: A Web service is an interface that describes a collection of operations that are network accessible through standardized XML messaging. Web services fulfill a specific task or a set of tasks. A Web service is described using a standard, formal XML notion, called its service description, that provides all of the details necessary to interact with the service, including message formats (that detail the operations), transport protocols, and location. The nature of the interface hides the implementation details of the service so that it can be used independently of the hardware or software platform on which it is implemented and independently of the programming language in which it is written. This allows and encourages Web services based applications to be loosely coupled, component-oriented, cross-
- 15. technology implementations. Web services can be used alone or in conjunction with other Web services to carry out a complex aggregation or a business transaction. Microsoft has a couple of definitions for Web service. The first is at http:// msdn.microsoft.com/library/default.asp?url=/nhp/Default.asp?contentid=28000442: A Web service is a unit of application logic providing data and services to other applications. Applications access Web services via ubiquitous Web protocols and data formats such as HTTP, XML, and SOAP, with no need to worry about how each Web service is implemented. Web services combine the best aspects of component-based development and the Web, and are a cornerstone of the Microsoft .NET programming model. The other Microsoft definition is at http://msdn.microsoft.com/library/default.asp?url=/library/en- us/dnWebsrv/html/Websvcs_platform.asp: A Web service is programmable application logic accessible using standard Internet protocols. Web services combine the best aspects of component- based development and the Web. Like components, Web services represent black-box functionality that can be reused without worrying about how the service is implemented. Unlike current component technologies, Web services are not accessed via object-model-specific protocols, such as the distributed Component Object Model (DCOM), Remote Method Invocation (RMI), or Internet Inter-ORB Protocol (IIOP). Instead, Web services are accessed via ubiquitous Web protocols and data formats, such as Hypertext Transfer Protocol (HTTP) and Extensible Markup Language (XML). Furthermore, a Web service interface is defined strictly in terms of the messages the Web service accepts and generates. Consumers of the Web service can be implemented on any platform in any programming language, as long as they can create and consume the messages defined for the Web service interface. Sun provides the following definition at http://www.sun.com/software/sunone/faq.html#2: Web services are software components that can be spontaneously discovered, combined, and recombined to provide a solution to the user's problem/request. The Java™ language and XML are the prominent technologies for Web services. As you can see, there is broad agreement on what a Web service might be, but no single agreed-upon definition. Many developers will claim they cannot define what a Web service is, but they know one when they see one. From the perspective of this book, a Web service is a platform and implementation independent software component that can be: • Described using a service description language • Published to a registry of services • Discovered through a standard mechanism (at runtime or design time) • Invoked through a declared API, usually over a network • Composed with other services
- 16. One important point is that a Web service need not necessarily exist on the World Wide Web. This is an unfortunate historical naming issue. A Web service can live anywhere on the network, Inter- or intranet; some Web services can be invoked by a simple method invocation in the same operating system process, or perhaps using shared memory between tightly coupled processes running on the same machine. In fact, Web services have little to do with the browser-centric, HTML-focused World Wide Web. Sometimes, the names we choose in the information technology (IT) industry don't make a lot of sense; they simply take on a life of their own. Another important point is that a Web service's implementation and deployment platform details are not relevant to a program that is invoking the service. A Web service is available through its declared API and invocation mechanism (network protocol, data encoding schemes, and so on). This is analogous to the relationship between a Web browser and a Web application server: Very little shared understanding exists between the two components. The Web browser doesn't particularly care if the Web application server is Apache Tomcat, Microsoft IIS, or IBM Websphere. The shared understanding is that they both speak HTTP and converse in HTML or a very limited set of MIME types. Similarly, the Web application server really doesn't care what kind of client is using it— various brands of Web browsers or even non-browser clients. This minimal shared understanding between components allows Web services to form a system of loosely coupled components. Business Perspective To a business person, the Web services approach is all about integration: integrating application functionality within an organization or integrating applications between business partners (in a supply chain, for example). The scenario in this book illustrates this approach, particularly in Chapter 7, "Discovering Web Services." This application integration allows time and cost efficiencies for receiving purchase orders, answering status inquiries, processing shipment requests, and so on. The important point is that application integration is enabled without tight lock-in to any particular business partner. If another supplier has a better price, shipping terms, or quality assurance, then a company's reorder systems can be easily repositioned to use that supplier; doing so is as easy as pointing a Web browser at a different Web site. With a broader adoption of Web services and XML document format standards, this style of dynamic business partner integration will become more broadly used. When systems are this easy to integrate, an organization's reach to suppliers, customers, and other business partners is extended, yielding cost savings, flexible business models, better customer service, higher customer retention, and so on. Just as IT is fundamental to the efficient operations of an organization, Web services-based systems integration will be fundamental to flexible, lightweight systems integration—for internal application integration within an organization over an intranet and external partner integration over the Intranet or extended virtual private network. So, from a business perspective, a Web service is a business process or step within a business process that is made available over a network to internal and/or external business partners to achieve some business goal. Technical Perspective From a technical perspective, a Web service is nothing more than a collection of one or more related operations that are accessible over a network and are described by a service description. At this level, the Web services concept is not new. With Web services, the IT industry is trying to address the fundamental challenge of distributed computing that has been around for decades—locating and accessing remote systems. The big difference is that now the industry is approaching this problem using open technology (XML and Internet protocols) and open standards managed by broad consortia such as the World Wide Web Consortium (W3C, which manages the
- 17. evolution of the SOAP and WSDL specifications). Further, the approach often taken with Web services uses capabilities-based lookup , where the kind of service is searched for, as opposed to a service of a particular name or object identifier. The Web Service Opportunity The Web services approach is an application integration concept; it is a set of technologies that provides access to business functionality, such as purchase order processing. Often, the business functionality already exists in the form of legacy transaction processing systems, existing Web applications, Enterprise Java Beans, and so on. Web services technology is about access and application integration; it is not an implementation technology. Organizations use Web services technology in two broad categories: Enterprise Application Integration (EAI) and business-to-business (B2B) partner integration over the Internet. In either of these categories, Web services can range in sophistication from simple request response functions such as a credit card check to very complicated multi-party, multi-stage long-running business transactions such as a supply configuration and order system. Web services can be invoked by PC-based programs, mainframe systems, Web browsers, or even small mobile devices such as cell phones or personal digital assistants (PDAs). Regardless of the application, Web services will be used for systems integration: flexible, loosely-coupled systems integration yielding systems that can be decomposed and recomposed to reflect changes in the business. Enterprise Application Integration Enterprise Application Integration is still a field where large consulting companies command multimillion dollar contracts to help their clients deal with a mess of applications that were never meant to interoperate. The state of the art within many enterprise systems remains that of large, monolithic application "silos." These systems are often extremely difficult to change, let alone integrate with other systems. These applications often define unique data formats, and sometimes (for historical, often performance-related reasons) even define their own communications protocols. Furthermore, many systems, particularly in large organizations, can exist on multiple different platform technologies. Interoperability between systems is a significant challenge. In many organizations, particularly organizations that result from a merger of two previously independent companies, IT integration costs can seriously impact the financial health of the company. The Web services approach offers an attractive set of technologies by which existing legacy systems can be wrappered as Web services and made available for integration with other systems within the organization. Applications exposed as Web services are accessible by other applications running on different hardware platforms and written in different programming languages. Using this approach, the complexity of these systems can be encapsulated behind industry-standard XML protocols. Pair-wise system integration projects can be replaced with one-to-many systems interactions based on Web services. The promise of higher-level interoperability initiatives is that over time we will be able to develop the set of standards, technologies, and tools that will enable small and large businesses all over the world to easily integrate systems internally, and then mix and match the implementation of various activities within a business process, maintaining the option to, at any time, choose to outsource any or all of these activities if doing so makes business sense. For many organizations, their first implementations using Web services technology will be internal application integration, because that is the biggest problem for them to address
- 18. with IT. Flexible systems will yield flexible business models. Flexible business models will yield organizations better able to adapt to changes in the business environment. B2B Another key driver behind the rise of Web services is the continuing evolution of B2B computing. B2B computing is about integrating the business systems of two or more companies to support cross-enterprise business processes such as supply chain management. Some industry pundits claim that supply chain integration will be the killer application of Web services, particularly as a result of the standardization of common industry formats for XML and Web services related to supply chain business processes. B2B applications can be as simple as automated credit card validation or as complex as the full automation of the multi-billion- dollar supply chain of a Fortune 100 company. The challenges of building B2B applications combined with their huge market potential drove rapid innovation that has taken the industry from simple business-to-consumer (B2C) applications to SOAP-enabled Web services in a matter of five years. B2C, B2B, and Web services Online HTML-based applications are consumer-oriented. The classic example of a B2C Web application is the Amazon book search. To access this functionality, a human being needs to use a Web browser to navigate the company's site through multiple page transitions, input information using Web forms, submit them, and get the results back in human-readable form. The only way to automate this process is to simulate how a human uses the system. Doing so involves reverse-engineering the Web application to see how it moves data between pages, passing the data automatically from page to page, and, finally, parsing any data contained in the response HTML of pages. This screen-scraping approach was popular in the early years of the Web (1995–97). It is very error prone. Any changes in the Web application—even changes that are completely UI- centric and do not change the data being passed back and forth—can break screen- scraping applications. These problems are compounded because most of these applications do not properly separate presentation from application processing logic. The only true way to integrate applications on the Web is to use a B2B-focused solution. Because B2B applications are designed to have other applications as their clients, they are fundamentally different from B2C applications. Table 1.1 summarizes some of these differences for Java applications. Both types of application are unrestricted as to the type of backend they can use—typically, Java classes or Enterprise Java Beans (EJBs). (We discuss how Web services work with EJBs in more detail in Chapter 5, "Using SOAP for e- Business.") This is where the similarities end, however. To customize backend logic, B2C applications use servlets or Java Server Pages (JSPs) that are hosted in a servlet engine. B2B applications customize their backends using straight Java code (often EJBs) that is hosted inside a Web service engine. B2C applications communicate with a browser over HTTP. B2B applications can use any of the open Internet protocols such as HTTP, SMTP, or FTP, or proprietary networks such as EDI. B2C applications handle data over the straight HTTP protocol. Input comes as GET parameters (on the URL/query string) or as POST parameters from Web forms. Only strings can be exchanged. Any other datatypes, even numbers, need to be encoded as strings. For output, data is mixed together with formatting rules inside HTML pages. This is in marked contrast with B2B applications that use XML for both data input and output. XML is perfect for B2B computing because it is programming language- and platform-neutral, it can represent arbitrary data structures, it is easy to process, and it can be validated independently of its processing. B2C applications need to have some UI (typically HTML, although some have used Java applets) because their clients are humans. B2B applications have no UI because their clients are other applications. Table 1.1. Comparing B2C and B2B Java Applications
- 19. Area B2C application B2B application Backend logic Java classes and EJBs Java classes and EJBs Custom logic Servlets and JSPs Web service engine Communication protocol HTTP HTTP, SMTP, FTP, TCP/IP, EDI, JMS, RMI/IIOP… Data input HTTP GET/POST parameters XML Data output HTML XML UI HTML + script N/A Client Human behind a browser Software application Trends in e-business It is clear that the network economy is currently driving the evolution of business. Businesses must respond to increasingly dynamic marketplaces. Within corporate departments, application integration has been a major issue in the last few years. Traditional architectures are brittle, and this brittleness is being exposed as the scale, demand level, transaction volume, and rate of change of transaction volume increases. Interoperability, particularly between heterogeneous distributed systems components, has been one of the major themes in software engineering in general, and EAI in particular, for the last decade. It's unfortunate that the seamless interoperability vision is still a dream. Brittleness in all current architectures is preventing software from achieving this vision. Brittleness comes from tightly coupled systems that generate dependencies at every level in the system. One of the most important lessons we learned as developers and architects is that systems need to be able to find resources (software or otherwise) automatically, when and as needed, without human intervention. This ability frees business people to concentrate on their business and customers rather than worry about IT complexities. At the same time, it frees system developers to concentrate on enabling their business and their customers rather than deal with interoperability headaches by writing glue code and patching systems together. More than any technical consideration, this concept of implicit, seamless integration as a major business benefit is one of the main drivers for service orientation. In other words, the time has come for "just in time" integration! Trends in application design are moving from rigid structures to flexible architectures. Trends in business partner interactions are moving from static agreements to more dynamic agreements. Trends in B2B integration are moving from technology-based integration to business process-based integration. There is a corresponding shift in programming and architecture models to enable these trends: from tightly coupled applications to loosely coupled services. On the technical side, major shifts have occurred toward flexibility and interoperability, through open and widely accepted standards. The first major shift happened two decades ago with the advent of TCP/IP as an open platform for networking. This step enabled such important and pervasive architectures as client-server computing. It took the advent of the World Wide Web for the next major shift, with HTML and HTTP providing the first truly universal open and portable user interface. Next, Java gave us truly open portable programming, and finally XML brought with it open portable data exchange. The next step in this evolution of open standards is the integration step. How do all these ingredients come together to facilitate the next evolution of e-business? Web services.
- 20. One aspect of more loosely coupled systems is reflected in the move from Remote Procedure Call (RPC) interfaces towards a messaging or document-centric model of distributed computing interface. With a document-centric approach, the interface to the Web service becomes much more simple and flexible. An RPC interface presenting a fixed set of parameters in a fixed order is quite brittle. Small changes to information required— for example, a new requirement for an expiration date on a credit card—require a new interface to be created, published, and understood by the service requestor. With a document-centric approach, the new information can be added to the document schema defined in the Web service interface. Programs that use the older schema don't necessarily break when the new XML element is added (this is a property of XML namespaces that you will see in Chapter 2, "XML Primer"). This approach yields Web services interfaces that are much more flexible, resulting in systems that are much more adaptive. Web Services Market Dynamics Most major software companies and many smaller software vendors have embraced the concept of Web services in one form or another. Some might just be giving it lip service, hedging on whether it's just another fad, or using it as a buzzword to generate marketing fodder. Others have staked their future on it. Here is a brief examination of the Web services initiatives from a few major players: • IBM: Dynamic e-business—IBM provides a broad collection of Web services technology, including a SOAP stack as part of WebSphere (derived from Apache SOAP 2.2), WSDL tooling in the Web Services Toolkit, and a UDDI implementation. Many major products within IBM are incorporating the Web services approach in some fashion. • Microsoft: .NET—It can be argued that Microsoft is "betting the business" on the success of .NET. Although .NET is based on Web services technologies, the .NET initiative is much broader than Web services, including a new programming language, C#, and a common runtime layer upon which implementations of multiple programming languages can be built. We will look at .NET in more detail in Chapter 8, "Interoperability, Tools, and Middleware Products." • Sun: SunOne (Open Net Environment)— Sun declared the notion of smart Web services that can somehow understand the context in which they were deployed or invoked (such as user identity, type of client device and privacy policy, and so on). Smart Web services includes a standard for sharing this notion of "context" and an infrastructure SunONE upon which to deploy it. Sun's approach to Web services is fairly similar to the approach taken by the other major IT vendors, in that Sun bases its Web services technology on the core XML, SOAP, WSDL, UDDI technology set. Sun also augments these technologies with technologies derived from ebXML. The details are not clear as to how these technologies merge
- 21. together. Sun's sponsorship of the Java Community Process and its definition of Java specifications related to Web services is also a major component of the company's Web services initiative. • Oracle: Oracle 9i Web Services Broker— The Oracle approach to Web services also follows the traditional SOAP, WSDL, UDDI perspective. Oracle emphasizes the role of its database technology as a service registry (broker) providing security and other value added services as an intermediary between service requestor and service provider. • Macromedia: Macromedia platform— Macromedia has embraced Web services throughout its mass-enterprise platform. Its rich clients can display information retrieved through Web services, its application servers make building Web services possible for developers at all skill levels, and its tools provide high-level support for building applications that leverage Web services. It is exciting to see so many software vendors active in Web services. With multiple vendors, there is a risk of incompatibility of implementations. Unless Web services from different vendors can interoperate, Web services will fail to attain critical mass of adoption. Happily, there is significant focus among the various Web services implementations to develop and maintain interoperability. Chapter 8 will look at a collection of Web services implementations in the industry, from large software vendors to smaller boutique Web services infrastructure providers. Why Do We Need a Web Services Approach? The beginning of this chapter explained the motivation for application-to-application communication over the Internet to address the current challenges of distributed computing and B2B integration in particular. Since 1999, the software industry has been rapidly evolving XML-based Web services technologies as the approach to these problems. In the maelstrom of press hype, product releases, and standards announcements, many people have been left wondering whether this is a good in which direction to go. After all, we already have many different mechanisms for distributed computing. Surely, some of them would be able to rise to meet the challenges of e- business. Why build a completely new distributed computing stack based on Web services? This is a very good question and one that is hard to give a short answer to. "Because Web services use XML" is not the right answer. It is a correct observation, but it doesn't answer the crucial question as to why using XML makes such a big difference. At a basic level, there are three key reasons why existing distributed computing approaches are inferior to Web services for solving the problems of e-business: • The scope of problems they try to address • The choice of available technology • Industry dynamics around standards control and innovation Scoping the Problem
- 22. Traditional distributed computing mechanisms have typically evolved around technical architectures rather than broader problems of application integration. For example, CORBA evolved as a solution to the problem of implementing rich distributed object architectures. At the time, it was implicitly assumed that this was the right approach to getting applications to communicate with one another. As we discussed earlier, experience has shown that RPCs are not always the best architecture for this requirement. The need for loosely coupled applications and business process automation has clearly shown the benefits of simply exchanging messages containing data (typically a business document) between the participants of e-business interactions, a so-called document-centric approach. Distributed computing specifications address messaging as a computing architecture; however, there has been no unifying approach that brings RPCs and messaging to the same level of importance—until Web services, that is. Web services have evolved not around pre-defined architectures but around the problem of application integration. This is a very important distinction. The choice of problem scope defines the focus of a technology initiative. Web services technologies have been designed from the ground up to focus on the problems of application integration. As a result, we are able to do things outside the scope of traditional distributed computing approaches: • Support both document-centric messaging and RPCs • Transport encoded data from both applications and business documents • Work over open Internet protocols such as HTTP and SMTP In other words, Web services are better suited for the task than what we have so far because we have specifically built them with this in mind. COM/CORBA/RMI are still great technologies for tying together distributed objects on the corporate network. However, the e-business application integration problem is best tackled by Web services. Core Technologies Because Web services address a much more broadly scoped problem, they use much more flexible technologies than traditional distributed computing approaches. Further, with Web services we can leverage all that we have learned about connecting and integrating applications since we first started doing distributed computing. These two factors put Web services on a better technology foundation for solving the problems of e- business than traditional distributed computing approaches. Later, in the "Web Services Interoperability Stacks" section, we introduce the notion of Web services interoperability stacks. These interoperability stacks organize a layering of technologies that define the capabilities of Web services. It is possible to compare the Web services approach to traditional distributed computing approaches level-by-level to see why the technical foundation of Web services is more appropriate for the problems it needs to solve. Rather than going through this lengthy process, let's focus on two key capabilities: the ability to represent data structures and the ability to describe these data structures. Data encoding is a key weakness for traditional distributed computing approaches, particularly those that are programming language independent. Sure, they typically have a mechanism to represent simple data (numbers, strings, booleans, date-time values, and so on), basic arrays, and structures with properties. However, mapping existing complex datatypes in applications to the underlying data encoding mechanisms was very difficult. Adding new native datatypes was practically impossible (doing so required a complete update of specifications). The fact that data was encoded in binary formats further complicated matters. For example, processing code had to worry about little- vs. big-endian issues when reading and writing numbers.
- 23. Web services address these issues by using XML to represent information. XML's text- based form eliminates byte ordering concerns. The wide availability of XML processing tools makes participation in the world of Web services relatively easy. XML's hierarchical structure (achieved by the nesting of XML elements) allows changes at some level of nesting in an XML document to be made with ease without worrying about the effect on other parts of the document. Also, the expressive nature of attributes and nested elements makes it considerably easier to represent complex data structures in XML than in the pure binary formats traditionally used by COM and CORBA, for example. In short, XML makes working with arbitrary data easier. The choice of XML brought another advantage to Web services—the ability to describe datatypes and validate whether data coming on the wire complies with its specification. This happens through the use of XML meta-languages such as XML Schema. Binary data encodings typically used for distributed computing offered no such mechanism and thus pushed data validation into application logic, considerably complicating applications dealing with non-trivial data. Industry Dynamics Momentum is a very important aspect of the dynamics of software innovation. Great problems gate great opportunities. The desire to capitalize on the opportunities generates momentum around a set of initiatives targeted at solving the problem. This momentum is the binding force of our industry. This is how major innovation takes place on a broad scale. The challenge of e-business application integration is great; this is why all the key players in the industry are focused on it (see the sidebar "Web Services Market Dynamics"). Customer need, market pressure, and the desire to be part of the frontier-defining elite have pushed many companies to become deeply engaged with Web services. Good things are bound to happen. Consider this: The last time every one of the key infrastructure vendors was focused on the same set of issues was during the early days of e-business when the industry was trying to address the challenges of building Web applications. The net result was a new model for application development that leveraged the Web browser as a universal client and the Web application server as a universal backend. In short, trust that some of the very best minds in the industry working together under the aegis of organizations such as the W3C and OASIS will be able to come up with a good solution to the problems of e-business integration. To the veterans of the software industry, momentum sometimes equals hype. So, are we trying to say that Web services will succeed because there is so much hype around them? Absolutely not! The momentum around Web services is real and different from what we have experienced so far with other distributed computing fads. The fundamental difference is around the ability of many industry players to engage in complementary standardization in parallel. Parallelism is key to building real momentum and increasing the bandwidth of innovation. Traditional distributed computing efforts could not achieve this kind of parallelism because they were either driven by a single vendor—Microsoft promoting COM, for example—or they were driven by a large, slow organization such as the Object Management Group (OMG), which owns the CORBA standards. In both cases, the key barrier to fast progress was the centralized management of standards. Any change had to be approved by the body owning the standard. And Microsoft and OMG owned all of COM and CORBA, respectively. This is no way to gain real momentum, regardless of the size of the marketing budgets to promote any given technology. Vendors that feel they have very little control over the evolution of a technology will likely spend very little time investing in its evolution. In other words, you might use COM, but if you think you have no chance of influencing Microsoft's direction on COM you will probably not spend much time thinking about and prototyping ways to improve COM. Open-source efforts such as the Linux operating system and projects of the Apache Software Foundation fundamentally generate momentum because people working on them can have a direct influence on the end product. The momentum of Web services is real because
- 24. standardization work is going on in parallel at the W3C, OASIS, UDDI, and many other horizontal and vertical industry standards organizations. Further, the major players so far have shown a commitment to do a lot of innovation out in the open. The interesting thing from a technical perspective is that XML actually has something to do with the ability of Web service standardization to be parallelized. XML has facilities (namespaces and schema) that enable the decentralized evolution of XML-based standards without preventing the later composition of these standards in the context of a single solution. For example, if group A owns some standard and group B is trying to build an extension to the standard, then with some careful use of XML, group B can design the extensions such that: • Its extension can be published independently of the standard. • Its extension can be present in cases where the standard is used. • Applications that do not understand the extension will not break if the extension is present. • Applications that need the extension will only work if the extension is present. The industry's focus on Web services combines the right scope (e-business application integration) with the right technologies (XML-based standards) with the potential for significant parallelism and high-bandwidth innovation. This is why Web services will be successful. Distributed Computing History Historically, distributed computing has been focused on the problem of distributing computation between several systems that are jointly working on a problem. The most often used distributed computing abstraction is the RPC. RPCs allow a remote function to be invoked as if it were a local one. Distributed object-oriented systems require object-based RPCs (ORPCs). ORPCs need some additional context to be able to invoke methods on specific object instances. The history of RPC-style distributed computing and distributed objects is fairly complicated. The following timeline illustrates some of the key events: • 1987 o Sun Microsystems developed the Open Network Computing (ONC) RPC system as the basic communication mechanism for its Network File System (NFS). o Apollo Computer developed the Network Computing System (NCS) RPC system for its Domain operating system. • 1989 o The Open Software Foundation (OSF, now The Open Group) issued a Request for Technology (RFT) for an RPC system. OSF received two key submissions. The first submission came from HP/DEC based on NCS (HP had acquired Apollo). The other submission came from Sun
- 25. based on ONC. OSF selected NCS as the RPC mechanism for its Distributed Computing Environment (DCE). o The Object Management Group (OMG) was formed to deliver language- and platform-neutral specifications for distributed computing. (The consortium includes about 650 members as of the time of this writing.) The OMG began development of specifications for Common Object Request Broker Architecture (CORBA), a distributed objects platform. • 1990 o Microsoft based its RPC initiatives on a modified version of DCE/RPC. • 1991 o DCE 1.0 was released by OSF. o CORBA 1.0 shipped with a single language mapping for the C language. The term Object Request Broker (ORB) gained popularity to denote the infrastructure software that enables distributed objects. • 1996 o Microsoft shipped the Distributed Component Object Model (DCOM), which was closely tied to previous Microsoft component efforts such as Object Linking and Embedding (OLE), non-distributed COM (a.k.a. OLE2), and ActiveX (lightweight components for Web applications). The core DCOM capabilities are based on Microsoft's RPC technologies. DCOM is an ORPC protocol. o CORBA 2.0 shipped with major enhancements in the core distributed computing model as well as higher-level services that distributed objects could use. The Internet Inter-ORB Protocol (IIOP) was part of the specification. IIOP allows multiple ORBs to interoperate in a vendor-agnostic manner. IIOP is an ORPC protocol. • 1997 o Sun shipped JDK 1.1, which included Remote Method Invocation (RMI). RMI defines a model for distributed computing using Java objects. RMI is similar to CORBA and DCOM but works only with Java objects. RMI has an
- 26. ORPC protocol called Java Remote Method Protocol (JRMP). o Microsoft announced the first iteration of COM+, the successor of DCOM. The capabilities of COM+ brought it much closer to the CORBA model for distributed computing. • 1999 o Sun shipped J2EE (Java 2 Platform Enterprise Edition). The Java 2 platform integrated RMI with IIOP, making it easy to interoperate between Java and CORBA systems. o Simple Object Access Protocol (SOAP) appeared for the first time. The era of Web services was born. Although RPCs and distributed objects have been the traditional approaches for building distributed systems, they are by no means the only ones. Another very important approach is that of data-oriented or document-centric messaging. Rather than being focused on distributing computation by specifically invoking remote code, messaging takes a different approach. Applications that communicate via messaging run their own independent computations and communicate via messages that contain pure data. Messaging was popularized via the efforts of system integrators who were trying to get highly heterogeneous systems to interoperate. In most cases, the systems were so different that the requirement to perform fine-grain integration via RPCs was impossible to satisfy. Instead, system integrators were happy to be able to reliably move pure data between the systems. Commercially, the importance of messaging applications has been steadily growing since IBM released its messaging product MQSeries in 1993. Microsoft's messaging product is the Microsoft Message Queuing Server (MSMQ). J2EE defines a set of APIs for messaging through the Java Messaging Service (JMS). There has been no attempt to define a standard interoperability protocol for messaging servers. One of the key benefits of Web services is that the core Web service protocols can support RPCs and messaging with equal ease. Chapter 3, "Simple Object Access Protocol (SOAP)," has a section that addresses this topic in detail. Service-Oriented Architectures Early on in the Web services technology evolution, we noticed a pattern. Each time we applied Web services technologies to an application integration problem, a pattern emerged. We called this pattern service-oriented architecture (SOA). SOA is a simple concept, which makes it applicable to a wide variety of Web services situations. Figure 1.1 depicts the main roles and operations in an SOA. Figure 1.1. Service-oriented architecture.
- 27. Any service-oriented architecture contains three roles: a service requestor , a service provider , and a service registry : • A service provider is responsible for creating a service description , publishing that service description to one or more service registries, and receiving Web service invocation messages from one or more service requestors. A service provider, then, can be any company that hosts a Web service made available on some network. You can think of a service provider as the "server side" of a client-server relationship between the service requestor and the service provider. • A service requestor is responsible for finding a service description published to one or more service registries and is responsible for using service descriptions to bind to or invoke Web services hosted by service providers. Any consumer of a Web service can be considered a service requestor. You can think of a service requestor as the "client side" of a client-server relationship between the service requestor and the service provider. • The service registry is responsible for advertising Web service descriptions published to it by service providers and for allowing service requestors to search the collection of service descriptions contained within the service registry. The service registry role is simple: be a match-maker between service requestor and service provider. Once the service registry makes the match, it is no longer needed in the picture; the rest of the interaction is directly
- 28. between the service requestor and the service provider for the Web service invocation. Each of these roles can be played by any program or network node. In some circumstances, a single program might fulfill multiple roles; for example, a program can be a service provider, providing a Web service to downstream consumers as well as a service requestor, itself consuming Web services provided by others. An SOA also includes three operations: publish , find , and bind . These operations define the contracts between the SOA roles: • The publish operation is an act of service registration or service advertisement. It acts as the contract between the service registry and the service provider. When a service provider publishes its Web service description to a service registry, it is advertising the details of that Web service to a community of service requestors. The actual details of the publish API depend on how the service registry is implemented. In certain simple or "direct publish" scenarios, the service registry role is played by the network itself, with publish being simply an act of moving the service description into a Web application server's directory structure. Other services registry implementations, such as UDDI, define a very sophisticated implementation of the publish operation. • The find operation is the logical dual of the publish operation. The find operation is the contract between a service requestor and a service registry. With the find operation, the service requestor states a search criteria, such as type of service, various other aspects of the service such as quality of service guarantees, and so on. The service registry matches the find criteria against its collection of published Web service descriptions. The result of the find operation is a list of service descriptions that match the find criteria. Of course, the sophistication of the find operation varies with the implementation of the service registry role. Simple service registries can provide a find operation with nothing more sophisticated than an unparameterized HTTP GET. This means the find operation always returns all Web services published to the service registry and it is the service requestor's job to figure out which Web service description matches its needs. UDDI, of course, provides extremely powerful find capabilities. • The bind operation embodies the client-server relationship between the service requestor and the service provider. The bind operation can be quite sophisticated and dynamic, such as on-the-fly generation of a client-side proxy based on the service description used to invoke the Web service; or it can be a very static model, where a developer hand-codes the way a client application invokes a Web service.
- 29. The key to SOA is the service description. It is the service description that is published by the service provider to the service registry. It is the service description that is retrieved by the service requestor as a result of the find operation. It is a service description that tells the service requestor everything it needs to know in order to bind to or invoke the Web service provided by the service provider. The service description also indicates what information (if any) is returned to the service requestor as a result of the Web service invocation. Each time a service-oriented architecture is deployed, there might be different technologies to fulfill each role. Chapter 7, "Discovering Web Services," discusses various options for implementing a service registry and goes into great detail on the UDDI service registry technology. Chapter 6, "Describing Web Services," discusses service description and how a service description can be used to automate the task of building a client-side proxy to the Web service and a server-side skeleton to dispatch the Web service invocation to the target Web service implementation. Chapters 3 and 4, "Simple Object Access Protocol (SOAP)" and "Creating Web Services," focus on the use of SOAP to fulfill the bind operation; Chapter 5, "Using SOAP for e-Business," details how the bind can be made ready for e-business. Web Services Interoperability Stacks An alphabet soup of technologies is swimming around the Web services space. We have XML, SOAP, WSDL, UDDI, WSEL, WSFL, and more. How can anyone make sense of what these technologies are and how they fit together? Well, that is one of the purposes of this book. To help put a framework around these technologies, we refer to a trio of Web services interoperability stacks, first proposed to the W3C by IBM and Microsoft in March 2001 (http://www.w3.org/2001/03/WSWS-popa/paper51). This proposal factored Web services technologies into three stacks: • The wire stack • The description stack • The discovery stack The contents of the stacks presented in this book reflect a different factoring than originally proposed to the W3C, due in part to the additional standards efforts that have come into play since March 2001. The Wire Stack Figure 1.2 shows the wire stack as we define it. Figure 1.2. The wire stack.
- 30. The wire stack represents the technologies that determine how a message is sent from the service requestor to the service provider. The base of the wire stack is a network protocol. Web services can be based on a variety of standard, Internet wire protocols such as HTTP or HTTPS, SMTP, FTP, and so on, as well as sophisticated enterprise-level protocols such as RMI/IIOP and MQSeries. For data encoding, Web services use XML. In addition, non-XML content can be referenced from a Web service invocation message, allowing full flexibility in the kinds of data used in the message. For data specification, Web services use XML Schema. This includes both custom schemas in the case of XML messaging or schemas conforming to a set of pre-defined rules, such as the SOAP encoding rules discussed in Chapter 3. Built on top of the networking protocol and data-encoding layers are the XML messaging layers. For XML messaging, Web services use SOAP in all its data encoding, interaction style, and protocol binding variations. SOAP is used as a simple approach to wrapper an XML message in an envelope. The result is a solid, standards-based foundation for Web services. Conceptually layered on top of the SOAP enveloping mechanism is a mechanism for envelope extensions called SOAP headers . With SOAP headers, orthogonal extensions such as a digital signature can be associated with the body of the message contained within the SOAP envelope. Chapter 3 will give details on the SOAP enveloping mechanism and the SOAP header facility. The layers of this stack are well defined, either as standard networking protocols or as the SOAP specification itself. This stack is the most accepted and most widely deployed set of technologies for Web services. At right in Figure 1.2 are three vertical columns representing associated technologies that impact multiple levels of the wire stack. Security, for example, can appear at each level— SSL at the network protocol level and digital signatures at the envelope extensions level, for instance. It is doubtful there will ever be a single standard that fits all aspects of Web services security needs. Chapter 5 goes into more detail on the current Web services– related security technologies like XML digital signatures and XML cryptography. Other vertical towers listed include Quality of Service and Manageability. These are just a
- 31. handful of facets of Web services that can appear at several levels of the wire stack. There is no well-accepted standard for these facets, but work is underway in these areas. The Description Stack The wire stack is only where the capabilities of Web services begin. Even the simplest example of Web service use shows the need for a higher level of interoperability. Consider the following situation (we'll see this example in greater detail in Chapter 3). A company has provided an inventory checking service, allowing customers to determine whether a particular number of items are in stock for a given product code (as represented as a stock keeping unit [SKU]). The Web service takes as parameters a string representing the SKU and an integer representing the number of units needed. If the company has on hand the requested number of units, the Web service responds with a Boolean true value; otherwise, the response is a Boolean false. From a pure SOAP perspective, the interaction with this Web service is trivial. However, things get much more complicated when we consider how much common understanding must exist between the service requestor and the service provider. For the interaction to succeed, at a minimum, the service requestor needs to know the following: • The address of the Web service. • It should make requests and receive responses over HTTP. • It should use SOAP 1.1. • Requests and responses should use the SOAP data encoding. • Requests will be RPC requests containing as parameters a string SKU and an integer indicating the desired quantity. • Responses will be RPC responses containing a Boolean indicating the inventory check outcome. Throw in security, payments, error handling, and other capabilities required to build enterprise-grade Web services, and the need for shared knowledge expands even further…. How can the service requestor acquire this information? Well, traditionally Web services have advertised their capabilities in some human readable form. Developers have read the description of these capabilities and configured user applications to be able to communicate with particular Web services. While this approach works in principle, it is not scalable for many reasons: • It requires costly (in terms of both time and money) manual configuration by highly skilled, and therefore scarce, personnel. • It is error prone because it does not utilize formalized service specifications. • It precludes automatic discovery and engagement of Web services; a priori knowledge is required for configuration of the user application.
- 32. • No built-in mechanism exists for change notifications and/or failure recovery; every time a Web service evolves, there is a risk that existing user applications will fail. These are some of the reasons why industry leaders are developing the standards described in a service description stack. Figure 1.3 shows the service description stack. Figure 1.3. The service description stack. Key to the entire service-oriented architecture approach is the service description itself. Many aspects of a Web service need to be communicated, and therefore the description stack has multiple levels. The focus on service description is to communicate those aspects of a service that might be important to the service requestor. Chapter 6 goes into detail on each of the technologies used for service description. In Web services, XML is the basis of service description. XML schema is the base data type mechanism in the service description and all of the service description technologies in the stack are expressed using XML. Much of the power of Web services is derived from the power of XML.
- 33. The next two levels of the stack, service implementation and service interface, are described using the Web Services Description Language (WSDL). WSDL is a note to the W3C, and there is active work to refine this language into a standard. WSDL is the interface definition language for Web services; it is the key to understanding Web services. With WSDL, a developer describes the set of operations supported by a Web service, including the kinds of objects that are expected as input and output of the operations, the various bindings to concrete network and data encoding schemes. This level constitutes the core definition of the service's interface. The service implementation defines the network address where the service itself can be invoked. WSDL allows for automatic code-generation of Web service clients based on this information. But IDL is not enough for Web services. Other aspects of the Web service could affect whether a service requestor would choose to bind to a Web service. For example, if two different service providers host implementations of the same service interface, perhaps a stock quote service, then from the IDL perspective, the services are almost indistinguishable: The network address is the only difference. However, the service providers might differ widely in their privacy policy, cost to use, timeliness of response, and so on. These non-operational characteristics might be critical to the service requestor. The role of the endpoint definition is to layer on top of the WSDL description information about characteristics of the Web service that are impacted by its implementation environment. Work in this area is at its very beginnings. The notion of a Web Services Endpoint Language (WSEL) has only been hinted at publicly. Other examples of this sort of description include the ebXML Collaboration-Protocol Profile and Agreement Specification (CPP). At the top of the service description stack is the elusive promise of seamless, automatic service integration: the service orchestration layer. With service orchestration , the developer describes how a collection of Web services is combined to produce a more sophisticated Web service. For example, you would use service orchestration to model how a purchase order submission Web service could be combined with a notification service and a returns-processing service to produce a richer overall purchasing Web service. At this level, several alternative approaches exist. IBM has proposed the Web Services Flow Language, and Microsoft has Xlang. A single standard has not emerged in this space. The orchestration of Web services poses significant challenges from both a technical and a business perspective. On the technical side, seamless service integration requires a significant technological foundation. Most important is the description of service behavior, defined by the rules for sequencing operation invocations and for sending and receiving messages. Next is the problem of composing services into process-based interactions. The problem is made harder by the requirement that some composition bindings must happen at runtime. Without this capability, it is difficult to map the technology to well- established business processes such as representation, referral, and brokering. On the business side, the problems are no less significant. From a business perspective, service integration is a workflow problem and as such could introduce dependencies on aspects of companies' core business models. Particularly difficult in this perspective is potentially the most valuable type of service integration—the one that spans enterprise boundaries. The Discovery Stack Given the ability to describe Web services, we are better off than we were, but we still have solved only part of the Web service integration problem. Service descriptions tell us how to bind to Web services, but how did the service requestor get the service description in the first place? Clearly, we need some form of a Web service discovery mechanism. The requirement here is for a directory or search engine for Web services. Service providers will need a publication mechanism so that they can provide information about the Web services they offer and make changes as their Web services evolve.
- 34. Service requestors will need well-defined find APIs. This is the SOA service registry role we described earlier. Figure 1.4 shows the third interoperability stack, the discovery stack. The discovery stack organizes technologies associated with Web service discovery. Figure 1.4. The discovery stack. The first level of the stack represents a simple inspection level. Inspection is a technique of discovering the service description given that the details about the service (a service identifier or URL, for example) are already known. Once again, no single standard exists in this space. IBM has ADS and Microsoft has DISCO . The directory level represents the capability of discovering Web services and business partners using a capabilities-based lookup. Unlike previous distributed computing techniques that relied on well known names as the basis for remote discovery of services, Web services can use find techniques based on the kind of service or service capabilities. The UDDI standard is the proposed technology for Web services directory. Chapter 7 is dedicated to explaining service discovery in much more detail, and in particular reviewing the UDDI standard. Putting the Interoperability Stacks Together Does any given Web service require all of these technologies in order to be considered a Web service? Certainly not. Looking at the wire stack, no single network protocol—not even HTTP—is a required part of a Web service; any number of networking protocols can be used. Some Web services don't even need to use a network protocol. Techniques such as the Web Services Invocation Framework (WSIF) (http://www.alphaworks.ibm.com/tech/wsif) discuss the possibility of a Web service being a simple Java method invocation, where the service requestor and service provider are in the same Java Virtual Machine. Moving up the stack, we can discover that even SOAP is not a necessary technology for Web services. It is possible that a component accessed through a simple HTTP POST can be considered a Web service. In these cases, the commonality that makes these components Web services is the use of WSDL to describe the service. So, is a service description required in order for a component to be considered a Web service? Again, not necessarily. Many Web services, particularly older Web services developed when SOAP was first introduced, do not have a corresponding service description. These components are considered Web services, but it is worth noting that without a service description, the Web service cannot be a part of the publish, find, bind operations in a service-oriented architecture. As the WSDL standard is adopted, you will see fewer Web services provided that do not have a corresponding WSDL description.
- 35. Many developers have concluded that a Web service is simply "anything that can be described using WSDL." Does a Web service have to appear in a UDDI registry in order to be considered a Web service? Clearly not. Many Web services advertised on the Web do not appear in UDDI and do not support the ADS or DISCO simple service discovery conventions. So you will agree that any given Web service doesn't need all of these technologies to be considered a Web service. But are any of these technologies found in each and every Web service? If you follow the arguments above, clearly not. Is SOAP required in all Web services? No. Is WSDL? No. UDDI? No. There is no single Web services technology whose use determines that a component is a Web service. For this reason, defining what is a Web service remains difficult. In addition to writing great specifications, the Web services industry has been busy building software that makes the standards come to life and solve meaningful business problems. This book uses Apache Axis at the heart of our Web services examples. Axis is an advanced Web services engine with a highly scalable and extensible architecture. We will examine Axis in great depth in Chapter 4. There are, however, other great Web services implementations from multiple vendors. Chapter 8 looks at the currently available best-of-breed Web services tooling, its capabilities and its interoperability record. Interoperability is key for Web services. In the World Wide Web, does my browser care about which Web server you are running? No. The same thing is true in Web services. Any service requestor should be able to consume any standard (no custom extensions) Web service provided via any Web services engine. We might be some distance from this holy grail, but the industry is working hard at it because everyone knows this is the only way to make Web services (and dynamic application integration) successful. Summary In this chapter, we provided you with a definition for Web services and helped position where these technologies will benefit businesses. We also provided a conceptual framework—service-oriented architecture—you can use to think about problems related to Web services. We introduced the alphabet soup of Web services technologies and illustrated an organizational framework around three related interoperability stacks. The rest of this book builds upon what we introduced here. Chapter 2 explores the root of all Web services technologies: XML. Chapter 3 builds upon that discussion by examining the wire stack and, in particular, the SOAP technology as the access mechanism of choice for many Web services. Chapter 4 shows how SOAP is implemented in the Apache Axis project. Chapter 5 expands upon SOAP and Axis, describing how other e-business aspects such as security can be layered into a Web service. Chapter 6 explores the service description stack, focusing on how the service requestor knows what kind of message to send and where to send it. Chapter 7 examines the discovery stack and in particular the UDDI standard. Chapter 8 explores other Web services infrastructures. We close with Chapter 9, "Future Concepts," which discusses some future trends for Web services. Chapter 2. XML Primer IN THIS CHAPTER • Origins of XML
- 36. • Document- Versus Data-Centric XML • XML Instances • XML Namespaces • Document Type Definitions • XML Schemas • Processing XML Since its introduction in 1998, Extensible Markup Language (XML) has revolutionized the way in which we think about structuring, describing, and exchanging information. The ways in which XML is used in the software industry are many and growing. Certainly for Web services the importance of XML is paramount; all key Web service technologies are based on it. One great thing about XML is that it is constantly changing and evolving. However, this can also be its downside. New problems require new approaches and uses of XML that drive aggressive technological innovation. The net result is a maelstrom of invention—a pace of change so rapid that it leaves most people confused. To say that you are using XML is meaningless. Are you using DTDs or XML Schema and, if so, then whose? How about XML Namespaces, XPointer, XLink, XPath, XSLT, XQuery, RDF, SOAP, WSDL, UDDI, XAML, WSFL, WSCL, or WS-I? Does your software use SAX, DOM, JAXB, JAXP, JAXM, JAXR, or JAX-RPC? It is easy to get lost, to drown in the acronym soup. You are interested in Web services (you bought this book, remember?). How much do you really need to know about XML? The truth is pleasantly surprising. First, many XML technologies you might have heard about are not relevant to Web services. You can safely forget half the acronyms you wish you knew more about. Second, even with relevant technologies, you need to know only a few core concepts. (The 80/20 rule does not disappoint.) Third, this chapter is all you need to read and understand to be able to handle the rest of the book and make the most of it. This chapter will cover, in sufficient detail: • The origins of XML and the fundamental difference between document- and data-centric XML applications • The syntax and rules governing XML documents • XML Namespaces, the key specification enabling the distributed evolution of XML technologies • XML Schema, the de facto standard for describing document structure and XML datatypes for data-oriented applications • The key mechanisms for creating and processing XML with Java software This chapter will develop a set of examples around SkatesTown's purchase order submission and invoice generation process. The examples will cover all the technologies we've listed here. If you are an old hand at XML who understands the XML namespace mechanism and feels at home with schema extensibility and the use of xsi:type, you should go straight to Chapter 3, "Simple Object Access Protocol (SOAP)" and dive into Web services. If you can parse and process a significant portion of the previous sentence, you should skim
- 37. this chapter to get a quick refresher of some core XML technologies. If you are someone with more limited XML experience, do not worry—by the end of this chapter, you will be able to hold your own. Origins of XML World Wide Web Consortium (W3C) began work on Extensible Markup Language (XML) in the middle of 1996. XML 1.0, released on February 10, 1998, resulted from the computer industry's need to develop a simple yet extensible mechanism for the textual representation of structured and semi-structured information. The design inspiration for XML came from two main sources: Standard Generalized Markup Language (SGML) and HTML. The concept of generalized markup (GM) has been around for decades. It involves using tags to identify pieces of information. Simply put, tags are names surrounded by pointy brackets (< and >). For example, <title> is a tag. The innovative thing about GM is that it requires information to be surrounded by both start and end tags. End tags look like start tags with the addition of a forward slash (/) before the tag name, as in </title>. The notion of start and end tags allows for nesting, which, in turn, lets you structure information in a hierarchical manner. Consider the following example, which uses markup to indicate that a book has a title and several authors: <book> <title>Building Web Services with Java</title> <authors> <author>Steve Graham</author> <author>Simeon Simeonov</author> <author>Toufic Boubez</author> <author>Doug Davis</author> <author>Glen Daniels</author> <author>Yuichi Nakamura</author> <author>Ryo Neyama</author> </authors> </book> Using markup to represent information about books has many benefits. The information is readily readable by humans. It is also quite easy to process with software because start and end tags clearly delineate where certain pieces of information start and where they end. Further, this way to represent information is inherently extensible. For example, you can easily imagine how to add more authors or other information (such as the book's ISBN) to the book description. Markup is appealing because of its simplicity combined with the potential for extensibility. Not all markup is simple, though. In fact, our industry's first attempt to formally define generalized markup yielded a very complex specification. SGML was ratified by ISO in 1986. It defined everything you could ever want to know about markup and more. SGML-enabled software was expensive; typically, only large companies could afford it. The software also tended to be full of defects. Over time, a growing community of SGML experts began to voice opinions that, perhaps, the core ideas of SGML could be organized in a much simpler fashion. All that was needed was a catalyst to force the change and an organization that could lead the standardization effort. The catalyst was the combination of HTML and the Web. The organization was the W3C. By its nature, SGML is a meta-language . It does not prescribe any particular markup; instead, it defines how any given markup language can be formally specified. For better or worse, the term for these markup languages is SGML applications .
- 38. Because the term is confusing (a markup language specification is not a piece of software), it is rarely used nowadays, but you still might encounter it in some of the reference materials pointed out at the end of the chapter. The most popular SGML application is HTML, the markup language that rules the Web. HTML combines markup from several different categories to provide a rich hypertext experience: • Text structuring tags: <H1>, <H2>, <P>, <BR> • Formatting tags: <B>, <I> • Linking and embedding tags: <IMG>, <A> • Data input tags: <FORM>, <INPUT>, <SELECT> The HTML specification is owned by W3C. Unfortunately, due to the rapid growth of the Internet and the market pressure caused by the browser wars, the leading browser vendors introduced a number of incompatible tags to HTML completely outside the scope of the HTML specification. These tags created problems for Internet software vendors and HTML document authors—they had to be careful what markup they used, based on the type of browser that would display the HTML document. Yet at the same time, they themselves were not able to extend HTML with markup that could have been useful to them. The need to simplify SGML coincided with the need to control the evolution of HTML and create a simple generalized markup language for use on the Web. SGML was too heavy for this purpose—it simply took too much effort to support and process. XML became that lightweight language. After about one-and-a-half-years of work, the XML working group at the W3C produced a final specification. XML is similar to SGML in that it preserves the notion of GM. However, the specification is much simpler. There are very few optional features, and most SGML features that were deemed difficult to implement were abandoned. XML is here to stay. The XML industry is experiencing a boom. XML has become the de facto standard for representing structured and semi-structured information in textual form. Many specifications are built on top of XML to extend its capabilities and enable its use in a broader range of scenarios. One of the most exciting areas of use for XML is Web services. The rest of this chapter will introduce the set of XML technologies and standards that are the foundation of Web services: • XML instances— The rules for creating syntactically correct XML documents • XML Schema— A recent standard that enables detailed validation of XML documents as well as the specification of XML datatypes • XML Namespaces— Definitions of the mechanisms for combining XML from multiple sources in a single document • XML processing— The core architecture and mechanisms for creating, parsing, and manipulating XML documents from programming languages Document- Versus Data-Centric XML Generally speaking, there are two broad application areas of XML technologies. The first relates to document-centric applications, and the second to data-centric applications. Because XML can be used in so many different ways, it is important to understand the difference between these two categories.
- 39. Document-Centric XML Because of its SGML origins, in the early days of its existence XML gained rapid adoption within publishing systems as a mechanism for representing semi-structured documents such as technical manuals, legal documents, and product catalogs. The content in these documents is typically meant for human consumption, although it could be processed by any number of applications before it is presented to humans. The key element of these documents is semi-structured marked-up text. The following markup is a perfect example of XML used in a document-centric manner. The content is directed towards human consumption—it's part of the FastGlide skateboard user guide. The content is semi-structured. The usage rules for tags such as <B>, <I> and <LINK> are very loosely defined; they could appear pretty much anywhere in the document: <H1>Skateboard Usage Requirements</H1> <P>In order to use the <B>FastGlide</B> skateboard you have to have:</P> <LIST> <ITEM>A strong pair of legs.</ITEM> <ITEM>A reasonably long stretch of smooth road surface.</ITEM> <ITEM>The impulse to impress others.</ITEM> </LIST> <P>If you have all of the above, you can proceed to <LINK HREF="Chapter2.xml">Getting on the Board</LINK>.</P> Data-Centric XML By contrast, data-centric XML is used to mark up highly structured information such as the textual representation of relational data from databases, financial transaction information, and programming language data structures. Data-centric XML is typically generated by machines and is meant for machine consumption. It is XML's natural ability to nest and repeat markup that makes it the perfect choice for representing these types of data. Consider the purchase order example in Listing 2.1. It is a purchase order from the Skateboard Warehouse, retailer of skateboards to SkatesTown. The order is for 5 backpacks, 12 skateboards, and 1,000 SkatesTown promotional stickers (this is what the stock keeping unit [SKU] of 008-PR stands for). Listing 2.1 Purchase Order in XML <po id="43871" submitted="2001-10-05"> <billTo> <company>The Skateboard Warehouse</company> <street>One Warehouse Park</street> <street>Building 17</street> <city>Boston</city> <state>MA</state> <postalCode>01775</postalCode> </billTo> <shipTo> <company>The Skateboard Warehouse</company> <street>One Warehouse Park</street> <street>Building 17</street> <city>Boston</city>
- 40. <state>MA</state> <postalCode>01775</postalCode> </shipTo> <order> <item sku="318-BP" quantity="5"> <description>Skateboard backpack; five pockets</description> </item> <item sku="947-TI" quantity="12"> <description>Street-style titanium skateboard.</description> </item> <item sku="008-PR" quantity="1000"> </item> </order> </po> The use of XML is very different from the previous user guide example: • The ratio of markup to content is high. The XML includes many different types of tags. There is no long-running text. • The XML includes machine-generated information; for example, the submission date of the purchase order uses a date-time format of year-month-day. A human authoring an XML document is unlikely to enter a date-time value in this format. • The tags are organized in a highly structured manner. Order and positioning matter, relative to other tags. For example, <description> must be under <item>, which must be under <order>, which must be under <po>. The <order> tag can be used only once in the document. • Markup is used to describe what a piece of information means rather than how it should be presented to a human. In short, if you can easily imagine the XML as a data structure in your favorite programming language, you are probably looking at a data-centric use of XML. An example Java class that could, with a bit more work, be used to represent the purchase order data is shown here: class PO { int id; Date submitted; Address billTo; Address shipTo; Item order[]; } Document Lifetime Document- and data-centric uses of XML can differ in one other very significant aspect— the lifetime of the XML document. Typically, XML documents for human consumption (such as technical manuals and research papers) live a long time because the
- 41. information contained in them can be used for a long time. On the other hand, some data-centric XML could live for only a few milliseconds. Consider the example of a database that is returning the results of a query in XML format. The whole operation takes several milliseconds. After the query is used, the data is discarded. Further, no real XML document exists. The XML is just bits on a wire or bits in an application's data structure. Still, for convenience purposes, we will use the term XML document to refer to any particular whole piece of XML being used. As a general identification of parts of a whole XML document, this book uses the highly technical term chunk. Web services are about data-centric uses of XML. Through the rest of this chapter and the rest of this book, we will purposefully ignore discussing document-centric XML. XML Instances The structure and formatting of XML in an XML document must follow the rules of the XML instance syntax. The term instance is used to explicitly distinguish the difference between the use of some particular type of XML and its specification. This usage parallels the difference in object-oriented terminology between an object instance and an object type. Document Prolog XML documents contain an optional prolog followed by a root element that contains the contents of the document. Typically the prolog serves up to three roles: • Identifies the document as an XML document • Includes any comments about the document • Includes any meta-information about the content of the document A document can be identified as an XML document through the use of a processing instruction . Processing instructions (PIs) are special directives to the application that will process the XML document. They have the following syntax: <?PITarget ...?> PIs are enclosed in <? ... ?>. The PI target is a keyword meaningful to the processing application. Everything between the PI target and the ?> marker is considered the contents of the PI. In general, data-oriented XML applications do not use application-specific processing instructions. Instead, they tend to put all information in elements and attributes. However, you should use one standard processing instruction—the XML declaration —in the XML document prolog to determine two very important pieces of information: the version of XML in the document and the character encoding: <?xml version="1.0" encoding="UTF-8"?> The version parameter of the xml PI tells the processing application the version of the XML specification to which the document conforms. Currently, there is only one version: "1.0". The encoding parameter is optional. It identifies the character set of the document. The default value is "UTF-8". Note
- 42. UTF-8 is a variable-length character encoding standard that generates 7-bit safe output. This type of output makes it easy to move XML on the Internet using standard communication protocols such as HTTP, SMTP, and FTP. Keep in mind that XML is internationalized by design and can support other character encodings such as Unicode and ISO/IEC 10646. However, for simplicity and readability purposes, this book will use UTF-8 encoding for all samples. If you omit the XML declaration, the XML version is assumed to be 1.0, and the processing application will try to guess the encoding of the document based on clues such as the raw byte order of the data stream. This approach has problems, and whenever interoperability is of high importance—such as for Web services—applications should always provide an explicit XML declaration and use UTF-8 encoding. XML document prologs can also include comments that pertain to the whole document. Comments use the following syntax: <!-- Sample comment and more ... --> Comments can span multiple lines but cannot be nested (comments cannot enclose other comments). Everything inside the comment markers will be ignored by the processing application. Some of the XML samples in this book will use comments to provide you with useful context about the examples in question. With what you have learned so far, you can extend the purchase order example from Listing 2.1 to include an XML declaration and a comment about the document (see Listing 2.2). Listing 2.2 XML Declaration and Comment for the Purchase Order <?xml version="1.0" encoding="UTF-8"?> <!-- Created by Bob Dister, approved by Mary Jones --> <po id="43871" submitted="2001-10-05"> <!-- The rest of the purchase order will be the same as before --> ... </po> In this case, po is the root element of the XML document. Elements The term element is a technical name for the pairing of a start and end tag in an XML document. In the previous example, the po element has the start tag <po> and the end tag </po>. Every start tag must have a matching end tag and vice versa. Everything between these two tags is the content of the element. This includes any nested elements, text, comments, and so on. Element names can include all standard programming language identifier characters ([0- 9A-Za-z]) as well as underscore (_), hyphen (-), and colon (:), but they must start with a letter. customer-name is a valid XML element name. However, because XML is case- sensitive, customer-name is not the same element as Customer-Name. According to the XML Specification, elements can have three different content types. They can have element-only content, mixed content, or empty content. Element-only content consists entirely of nested elements. Any whitespace separating elements is not considered significant in this case. Mixed content refers to any combination of nested elements and text. All elements in the purchase order example, with the exception of description, have element content. Most elements in the skateboard user guide example earlier in the chapter had mixed content.
- 43. Note that the XML Specification does not define a text-only content model. Outside the letter of the specification, an element that contains only text is often referred to as having data content; but, technically speaking, it has mixed content. This awkwardness comes as a result of XML's roots in SGML and document-oriented applications. However, in most data-oriented applications, you will never see elements whose contents are both nested elements and text. It will typically be one or the other, because limiting the content to be either elements or text makes processing XML much easier. The syntax for elements with empty content is a start tag immediately followed by an end tag, as in <emptyElement></emptyElement>. Because this is simply too much text, the XML Specification also allows the shorthand form <emptyElement/>. For example, because the last item in our purchase order does not have a nested description element, it has empty content. Therefore, we could have written it as follows: <item sku="008-PR" quantity="1000"/> XML elements must be strictly nested. They cannot overlap, as shown here: <!-- This is correct nesting --> <P><B><I>Bold, italicized text in a paragraph</I></B></P> <!--Bad syntax: overlapping I and B tags --> <P><I><B>Bold, italicized text in a paragraph</I></B></P> <!-- Bad syntax: overlapping P and B tags --> <B><P><I>Bold, italicized text in a paragraph</I></B></P> The notion of an XML document root implies that there can be only one element at the very top level of a document. For example, the following would not be a valid XML document: <first>I am the first element</first> <second>I am the second element</second> It is easy to think of nested XML elements as a hierarchy. For example, Figure 2.1 shows a hierarchical tree representation of the XML elements in the purchase order example together with the data (text) associated with them. Figure 2.1. Tree representation of XML elements in a purchase order.
- 44. Unfortunately, it is often difficult to identify XML elements precisely in the hierarchy. To aid this task, the XML community has taken to using genealogy terms such as parent, child, sibling, ancestor, and descendant. Figure 2.2 illustrates the terminology as it applies to the order element of the purchase order: • Its parent is po. • Its ancestor is po. • Its siblings are billTo and shipTo. • Its children are three item elements. • Its descendants are three item elements and two description elements. Figure 2.2. Common terminology for XML element relationships.
- 45. Attributes The start tags for XML elements can have zero or more attributes. An attribute is a name-value pair. The syntax for an attribute is a name (which uses the same character set as an XML element name) followed by an equal sign (=), followed by a quoted value. The XML Specification requires the quoting of values; both single and double quotes can be used, provided they are correctly matched. For example, the po element of our purchase order has two attributes, id and submitted: <po id="43871" submitted="2001-10-05"> ... </po> A family of attributes whose names begin with xml: is reserved for use by the XML Specification. Probably the best example is xml:lang, which is used to identify the language of the text that is the content of the element with that attribute. For example, we could have written the description elements in our purchase order example to identify the description text as English: <description xml:lang="en">Skateboard backpack; five pockets</description> Note that applications processing XML are not required to recognize, process, and act based on the values of these attributes. The key reason why the XML Specification identified these attributes is that they address common use-cases; standardizing them would aid interoperability between applications. Without any meta-information about an XML document, attribute values are considered to be pieces of text. In the previous example, the id might look like a number and the submission date might look like a date, but to an XML processor they will both be just strings. This obviously causes some headaches when processing data-oriented XML, and it is one of the primary reasons most data-oriented XML documents have associated meta-information described in XML Schema (introduced later in this chapter). At the same time, XML applications are free to attach any semantics they choose to XML markup. A common use-case is leveraging attributes to create a basic linking mechanism within an XML document. The typical scenario involves a document having duplicate information in multiple locations. The goal is to eliminate information duplication. The process has three steps: 1. Put the information in the document only once. 2. Mark the information with a unique identifier.
- 46. 3. Refer to this identifier every time you need to refer to the information. The purchase order example offers the opportunity to try this out (see Listing 2.3). As shown in the example, in most cases, the bill-to and ship-to addresses will be the same. Listing 2.3 Duplicate Address Information in a Purchase Order <po id="43871" submitted="2001-10-05"> <billTo> <company>The Skateboard Warehouse</company> <street>One Warehouse Park</street> <street>Building 17</street> <city>Boston</city> <state>MA</state> <postalCode>01775</postalCode> </billTo> <shipTo> <company>The Skateboard Warehouse</company> <street>One Warehouse Park</street> <street>Building 17</street> <city>Boston</city> <state>MA</state> <postalCode>01775</postalCode> </shipTo> ... </po> There is no reason to duplicate this information. Instead, we can use the markup shown in Listing 2.4. Listing 2.4 Using ID/IDREF Attributes to Eliminate Redundancy <po id="43871" submitted="2001-10-05"> <billTo id="addr-1"> <company>The Skateboard Warehouse</company> <street>One Warehouse Park</street> <street>Building 17</street> <city>Boston</city> <state>MA</state> <postalCode>01775</postalCode> </billTo> <shipTo href="addr-1"/> ... </po> We followed the three steps described previously: 1. We put the address information in the document only once, under the billTo element. 2. We uniquely identified the address as "addr-1" and stored that information in the id attribute of the billTo element. We only need
- 47. to worry about the uniqueness of the identifier within the XML document. 3. To refer to the address from the shipTo element we use another attribute, href, whose value is the unique address identifier "addr- 1". The attribute names id and href are not required but nevertheless are commonly used by convention. You might have noticed that now both the po and billTo elements have an attribute called id. This is fine, because attributes are always associated with an element. Elements Versus Attributes Given that information can be stored in both element content and attribute values, sooner or later the question of whether to use an element or an attribute arises. This debate has erupted a few times in the XML community and has claimed many casualties. One common rule is to represent structured information using markup. For example, you should use an address element with nested company, street, city, state, postalCode, and country elements instead of including a whole address as a chunk of text. Even this simple rule is subject to interpretation and the choice of application domain. For example, the choice between <work number="617.219.2000"> and <work> <area>617</area> <number>219.2000</number> <ext/> </work> really depends on whether your application needs to have phone number information in granular form (for example, to perform searches based on the area code only). In other cases, only personal preference and stylistic choice apply. We might ask if SkatesTown should have used <po> <id>43871</id> <submitted>2001-10-05</submitted> ... </po> instead of <po id="43871" submitted="2001-10-05"> ... </pol> There really isn't a good way to answer this question without adding all sorts of stretchy assumptions about extensibility needs, and so on.
- 48. In general, whenever humans design XML documents, you will see more frequent use of attributes. This is true even in data-oriented applications. On the other hand, when XML documents are automatically "designed" and generated by applications, you might see a more prevalent use of elements. The reasons are somewhat complex; Chapter 3 will address some of them. Character Data Attribute values as well as the text and whitespace between tags must follow precisely a small but strict set of rules. Most XML developers tend to think of these as mapping to the string data type in their programming language of choice. Unfortunately, things are not that simple. Encoding First, and most important, all character data in an XML document must comply with the document's encoding. Any characters outside the range of characters that can be included in the document must be escaped and identified as character references . The escape sequence used throughout XML uses the ampersand (&) as its start and the semi-colon (;) as its end. The syntax for character references is an ampersand, followed by a pound/hash sign (#), followed by either a decimal character code or lowercase x followed by a hexadecimal character code, followed by the semicolon. Therefore, the 8- bit character code 128 will be encoded in a UTF-8 XML document as €. Unfortunately, for obscure document-oriented reasons, there is no way to include character codes 0 through 7, 9, 11, 12, or 14 through 31 (typically known as non- whitespace control characters in ASCII) in XML documents. Even a correctly escaped character reference will not do. This situation can cause unexpected problems for programmers whose string data types can sometimes end up with these values. Whitespace Another legacy from the document-centric world that XML came from is the rules for whitespace handling. It is not important to completely define these rules here, but a couple of them are worth mentioning: • An XML processor is required to convert any carriage return (CR) character, as well as the sequence of a carriage return and a line feed (LF) character, it sees in the XML document into a single line feed character. • Whitespace can be treated as either significant or insignificant. The set of rules for how applications are notified about either of these has erupted more than one debate in the XML community. Luckily, most data-oriented XML applications care little about whitespace. Entities In addition to character references, XML documents can define entities as well as references to them (entity references ). Entities are typically not important for data- oriented applications and we will not discuss them in detail here. However, all XML processors must recognize several pre-defined entities that map to characters that can be confused with markup delimiters. These characters are less than (<); greater than
- 49. (>); ampersand (&); apostrophe, a.k.a. single quote ('); and quote, a.k.a. double quote ("). Table 2.1 shows the syntax for escaping these characters. Table 2.1. Pre-defined XML Character Escape Sequences Character Escape sequence < < > > & & ' ' " " For example, to include a chunk of XML as text, not markup, inside an XML document, all special characters should be escaped: <example-to-show> <?xml version="1.0"?> <rootElement> <childElement id="1"> The man said: "Hello, there!". </childElement> </rootElement> </example-to-show> The result is not only reduced readability but also a significant increase in the size of the document, because single characters are mapped to character escape sequences whose length is at least four characters. To address this problem, the XML Specification has a special multi-character escape construct. The name of the construct, CDATA section , refers to the section holding character data. The syntax is <![CDATA[, followed by any sequences of characters allowed by the document encoding that does not include ]]>, followed by ]]>. Therefore, you can write the previous example much more simply as follows: <example-to-show><![CDATA[ <?xml version="1.0"?> <rootElement> <childElement id="1"> The man said: "Hello, there!". </childElement> </rootElement> ]]></example-to-show> A Simpler Purchase Order Based on the information in this section, we can re-write the purchase order document as shown in Listing 2.4. Listing 2.4 Improved Purchase Order Document <?xml version="1.0" encoding="UTF-8"?> <!-- Created by Bob Dister, approved by Mary Jones --> <po id="43871" submitted="2001-10-05"> <billTo id="addr-1"> <company>The Skateboard Warehouse</company> <street>One Warehouse Park</street> <street>Building 17</street>
- 50. <city>Boston</city> <state>MA</state> <postalCode>01775</postalCode> </billTo> <shipTo href="addr-1"/> <order> <item sku="318-BP" quantity="5"> <description>Skateboard backpack; five pockets</description> </item> <item sku="947-TI" quantity="12"> <description>Street-style titanium skateboard.</description> </item> <item sku="008-PR" quantity="1000"/> </order> </po> XML Namespaces An important property of XML documents is that they can be composed to create new documents. This is the most basic mechanism for reusing XML. Unfortunately, simple composition creates the problems of recognition and collision. To illustrate these problems, consider a scenario where SkatesTown wants to receive its purchase orders via the XML messaging system of XCommerce Messaging, Inc. The format of the messages is simple: <message from="..." to="..." sent="..."> <text> This is the text of the message. </text> <!-- A message can have attachments --> <attachment> <description>Brief description of the attachment.</description> <item> <!-- XML of attachment goes here --> </item> </attachment> </message> Listing 2.5 shows a complete message with a purchase order attachment. Listing 2.5 Message with Purchase Order Attachment <message from="bj@bjskates.com" to="orders@skatestown.com" sent="2001-10-05"> <text> Hi, here is what I need this time. Thx, BJ. </text> <attachment> <description>The PO</description> <item> <po id="43871" submitted="2001-10-05"> <billTo id="addr-1">
- 51. <company>The Skateboard Warehouse</company> <street>One Warehouse Park</street> <street>Building 17</street> <city>Boston</city> <state>MA</state> <postalCode>01775</postalCode> </billTo> <shipTo href="addr-1"/> <order> <item sku="318-BP" quantity="5"> <description> Skateboard backpack; five pockets </description> </item> <item sku="947-TI" quantity="12"> <description> Street-style titanium skateboard. </description> </item> <item sku="008-PR" quantity="1000"/> </order> </po> </item> </attachment> </message> It is relatively easy to identify the two problems mentioned earlier in the composed document: • Recognition— How does an XML processing application distinguish between the XML elements that describe the message and the XML elements that are part of the purchase order? • Collision— Does the element description refer to attachment descriptions in messages or order item descriptions? Does the item element refer to an item of attachment or an order item? Very simple applications might not be bothered by these problems. After all, the knowledge of what an element means can reside in the application logic. However, as application complexity increases and the number of applications that need to work with some particular composed document type grows, the need to clearly distinguish between the XML elements becomes paramount. The XML Namespaces specification brings order to the chaos. Namespace Mechanism The problem of collision in composed XML documents arises because of the likelihood of elements with common names (description, item, and so on) to be reused in different document types. This problem can be addressed by qualifying an XML element name with an additional identifier that is much more likely to be unique within the composed document. In other words: Qualified name (a.k.a. QName) = Namespace identifier + Local name
- 52. This approach is similar to how namespaces are used in languages such as C++ and C# and to how package names are used in the Java programming language. The problem of recognition in composed XML documents arises because no good mechanism exists to identify all elements belonging to the same document type. Given namespace qualifiers, the problem is addressed in a simple way—all elements that have the same namespace identifier are considered together. For identifiers, XML Namespaces uses Uniform Resource Identifiers (URIs). URIs are described in RFC 2396. URIs are nothing fancy, but they are very useful. They can be locators, names, or both. URI locators are known as Uniform Resource Locators (URLs), a term familiar to all using the Web. URLs are strings such as http://www.skatestown.com/services/POSubmission and mailto:orders@skatestown.com. Uniform Resource Names (URNs) are URIs that are globally unique and persistent. Universally Unique Identifiers (UUIDs) are perfect for use as URNs. UUIDs are 128-bit identifiers that are designed to be globally unique. Typically, they combine network card (Ethernet) addresses with a high-precision timestamp and an increment counter. An example URN using a UUID is urn:uuid:2FAC1234-31F8-11B4-A222- 08002B34C003. UUIDs are used as unique identifiers in Universal Description Discovery and Integration (UDDI) as detailed in Chapter 7, "Discovering Web Services." Namespace Syntax Because URIs can be rather long and typically contain characters that are not allowed in XML element names, the syntax of including namespaces in XML documents involves two steps: 1. A namespace identifier is associated with a prefix, a name that contains only legal XML element name characters with the exception of the colon (:). 2. Qualified names are obtained as a combination of the prefix, the colon character, and the local element name, as in myPrefix:myElementName. Listing 2.6 shows an example of the composed XML document using namespaces. Listing 2.6 Message with Namespaces <msg:message from="bj@bjskates.com" to="orders@skatestown.com" sent="2001-10-05" xmlns:msg="http://www.xcommercemsg.com/ns/message" xmlns:po="http://www.skatestown.com/ns/po"> <msg:text> Hi, here is what I need this time. Thx, BJ. </msg:text> <msg:attachment> <msg:description>The PO</msg:description> <msg:item> <po:po id="43871" submitted="2001-10-05"> <po:billTo id="addr-1"> <po:company>The Skateboard Warehouse</po:company>
- 53. <po:street>One Warehouse Park</po:street> <po:street>Building 17</po:street> <po:city>Boston</po:city> <po:state>MA</po:state> <po:postalCode>01775</po:postalCode> </po:billTo> <po:shipTo href="addr-1"/> <po:order> <po:item sku="318-BP" quantity="5"> <po:description> Skateboard backpack; five pockets </po:description> </po:item> <po:item sku="947-TI" quantity="12"> <po:description> Street-style titanium skateboard. </po:description> </po:item> <po:item sku="008-PR" quantity="1000"/> </po:order> </po:po> </msg:item> </msg:attachment> </msg:message> In this example, the elements prefixed with msg are associated with a namespace whose identifier is http://www.xcommercemsg.com/ns/message, and those prefixed with po are associated with a namespace whose identifier is http://www.skatestown.com/ns/po. The prefixes are linked to the complete namespace identifiers by the attributes on the top message element beginning with xmlns: (xmlns:msg and xmlns:po). XML processing software will have access to both the prefixed name and to the mapping of prefixes to complete namespace identifiers. Adding a prefix to every single element in the document somewhat decreases readability and increases document size. Therefore, XML Namespaces let you use a default namespace in a document. Elements belonging to the default namespace do not require prefixes. Listing 2.7 makes the msg namespace the default. Listing 2.7 Using Default Namespaces <message from="bj@bjskates.com" to="orders@skatestown.com" sent="2001-10-05" xmlns ="http://www.xcommercemsg.com/ns/message" xmlns:po="http://www.skatestown.com/ns/po"> <text> Hi, here is what I need this time. Thx, BJ. </text> <attachment> <description>The PO</description> <item> <po:po id="43871" submitted="2001-10-05"> ... </po:po> </item>
- 54. </attachment> </message> Default namespaces work because the content of any namespace-prefixed element is considered to belong to the namespace of its parent element unless, of course, the element is explicitly defined to be in another namespace with its own xmlns-type attribute. We can use this to further clean up the composed XML document by moving the PO namespace declaration to the po element (see Listing 2.8). Listing 2.8 Using Nested Namespace Defaulting <message from="bj@bjskates.com" to="orders@skatestown.com" sent="2001-10-05" xmlns="http://www.xcommercemsg.com/ns/message"> <text> Hi, here is what I need this time. Thx, BJ. </text> <attachment> <description>The PO</description> <item> <po:po id="43871" submitted="2001-10-05" xmlns:po="http://www.skatestown.com/ns/po"> <billTo id="addr-1"> ... </billTo> <shipTo href="addr-1"/> <order> ... </order> </po:po> </item> </attachment> </message> This example shows an efficient, readable syntax that completely eliminates the recognition and collision problems. XML processors can identify the namespace of any element in the document. Namespace-Prefixed Attributes Attributes can also have namespaces associated with them. Initially, it might be hard to imagine why a capability like this would be useful for XML applications. The common use- case scenario is the desire to extend the information provided by an XML element without having to make changes directly to its document type. A concrete example might involve SkatesTown wanting to have an indication of the priority of certain items in purchase orders. High-priority items could be shipped immediately, without waiting for any back-ordered items to become available and complete the whole order. Item priorities are not something that SkatesTown's automatic order processing software understands. They are just a hint for the fulfillment system on how it should react in case of back-ordered items. A simple implementation could involve extending the item element with an optional priority attribute. However, this could cause a problem for the order processing software that does not expect to see such an attribute. A better solution is to attach priority information to items using a namespace-prefixed priority attribute. Because the attribute will be in a namespace different from that of the item element, the order processing software will simply ignore it.
- 55. Another Random Document on Scribd Without Any Related Topics
- 56. Specific Character. Above dusky blue, brighter upon the crown, wings, and tail; beneath grey; chin and belly whiteish; ears blackish; tail distinctly rounded. Garrulus sordidus. Swains. Synopsis, No. 66. (Phil. Mag. June 1827.) The Jays, although allied to the Crows, have many peculiar characteristics. While the latter roam about and seek their food in all situations, the Jays confine themselves to thick woods, feeding upon fruits, insects, and eggs, and seldom perch upon the ground. In unison with that symbolical system which pervades all nature, we find a perfect representation of this group in the Bush-Shrikes of the new world. America seems to possess three Jays, closely resembling each other, but each (if they have been described correctly) having some peculiar distinction. As these have not been clearly stated, and as some confusion has consequently crept into the subject, we shall shortly state their distinctions. The Florida Jay of Prince C. Bonaparte, (G. Floridamus) which has been thought the same as ours, is a much smaller bird, being only 11½ in. long, and the back is "yellowish brown," not dusky blue, (See Bon. Am. Orn. 2. p. 61.) The Garrulus ultramarinus of the same noble and learned writer, appears to us from the following account, to be distinct from either. "Its principal characters may be found in its larger dimensions, but especially in the shape of its tail, which is perfectly even, and not in the least cuneiform, as it generally is in all the Jays," (Am. Orn. 2. 62.) Now the tail of our species is decidedly rounded, the outer feather being full one inch shorter than the middle.
- 57. The Garrulus sordidus inhabits the table land of Mexico, from whence our specimen was received. Total length, 11 in.: bill, 1½: wings, 7: tarsi, 17⁄10: tail, 6½ in. Pl. 87. SCAPHELLA maculata. Sw. Olive Volute. S C A P H E L L A maculata. Olive Volute. Family Volutidæ. Sub-family Volutinæ. Nob. Generic Character.
- 58. Shell fusiform, invariably smooth and polished: spiral whorls gradually diminishing in size, the apex obtuse but rarely thickened or distorted: pillar generally gibbous in the middle, with from four to six thick and unequal plaits: margin of the outer lip thickened. Typical Species.—Scaph. undulata. Junonia, maculata, zebra. Aberrant Species.—Scaph. papillaris, elongata (?) Specific Character. Shell small, oval, fulvous, with longitudinal purplish-brown spots, disposed in three transverse bands: spire conical: pillar four plaited, not gibbous. Voluta maculata. Swains. Bligh. Cat. app. p. 11. Of this distinct and very remarkable genus of Volutes, few species have hitherto been discovered: the subordinate divisions cannot therefore be traced; nor do we feel satisfied that all the typical characters have been detected: we consider it nevertheless, as a perfectly natural genus, absolutely essential to mark the connection between the Volutes and the Marginillæ. Lamark, indeed, as if aware of this affinity, actually describes one species as a Marginilla. The union of the three aberrant genera of Scaphella, Volutilithes, and Harpula, into one circle, is effected by the Scap. papillaris and the Harpula Lapponica: the former species conducting us at the same time to the typical Volutes, by means of Voluta fulgetrum of Sowerby. Scaphella maculata is a native of the Australian seas, and is of great rarity. Our drawings were made from one of the beautiful specimens
- 59. in Mr. Broderip's possession, It is probable that the animals of this genus envelope their shells in an ample mantle, since they are almost always enamelled. Pl. 88. ARCAS Imperialis. A R C A S imperialis. Emerald Hair-streak. Tribe, Papiliones. Family, Polyommatidæ. Sub-family, Theclanæ, Nob. Sub-Generic Character.
- 60. Palpi, in both sexes, very long, thick, porrect, twice as long as the head, curved downwards, all the joints entirely covered with close-set scales, posterior wings six-tailed. Specific Character. Above shining blue: beneath emerald-green, marked with minute black waved lines. Papilio imperialis. Cramer, Pl. 75. f. E. F. Hesperia Venus. Fab. Ent. Sys. 3. 1. 268. It is impossible to depicture with correctness, the resplendant blue which ornaments the upper surface, or the vivid emerald green on the under wings, of this rare and splendid insect. It is possessed by few collectors; nor did we capture more than three specimens, during two years devoted to the entomology and ornithology of Brazil. The male is distinguished by a black central spot on the anterior wings. The very remarkable prolongation of the palpi, which are alike in both sexes, induces us to consider this insect as a type of form, or in other words, a sub-genus: but we are at present unprepared to state any thing satisfactory on its true affinities. We have thought it right in this and other instances, to retain the original specific name of Cramer; and we shall do the same in all instances where it will not produce a discordant union of generic and specific names. On this head, as the principle of Linnæus, from the great number of new genera since defined, can no longer be acted upon, we think that specific appellations, derived from some character of the insect, are much better, in every respect, than
- 61. attempting to render the nomenclature of the Lepidoptera a correct index to the mythology of the Ancients. Pl. 89. CHLORISSES Sarpedon. C H L O R I S S E S Sarpedon, Sarpedon Butterfly. NATURAL GROUPS. Tribe, Papiliones. Family, Papilionidæ. Sub-fam. Papilionæ. Genus ——. Sub-Genus, Chlorisses, Nobis.
- 62. Sub-Generic Character. Wings, black, banded or variegated with green: the posterior narrowed, with obsolete acute tails; Head, thick, sessile, the front very hairy; Antennæ, long, the club spatulate, and concave beneath; Posterior feet, with the first joint of the tarsus as long as the tibiæ. Specific Character. Wings black, with a common green band: posterior obsoletely tailed: beneath, marked with a red and black lunated spot at the base. Papilio Sarpedon. Linn. Fab. Entom. Syst. 3. p. 1. p. 14. No. 41. Cramer. Pl. 122. f. D. E. Papilio Sarpedon. Ency. Meth. 9. p. 46. No. 62. Entomologists of the last century classed all day-flying Butterflies in the Genus Papilio. But this denomination has been restricted, of late years, to such as possess six long perfect legs; very short palpi, and the anterior shanks spined near the middle. Now this group is so peculiarly distinct, and comprises within itself such numerous variations of form, that we have always viewed it as pre-eminently calculated to put to the most severe test any arrangement, the principles of which are conceived to be those of Nature. The Papilionæ have consequently, for many years, engaged much of our attention. Baffled in numerous attempts to understand their arrangement, it was only upon applying those principles of the natural system, which we have detailed in Northern Zoology, vol. 2, that their true affinities became apparent. At present we shall only
- 63. apprise the Entomologist that the divisions above named are circular groups, and the result of strict analysis. The sub-genus Chlorisses, in reference to Ornithology, is a scansorial type. The present Insect, figured from the male sex, is one of the most beautiful butterflies of India. General Hardwicke presented us with specimens from Nepaul; and we have since received others from Java. The typical species is Papilio Agamemnon, where the green colour is broken into round spots. The most extraordinary circumstance, however, which belongs to the group, is this; that although a sub-genus, it yet contains within itself subordinate types of form, representing all the higher divisions. The only ornithological group we have yet ascertained as possessing this property, is the sub-genus Parus (proper). Pl. 90. JASIA Athama.
- 64. J A S I A Athama, Athama Butterfly. Tribe, Papiliones. Family, Nymphalidæ. Nobis. Sub-Generic Character. Lower wings, acutely bi-caudate; Antennæ, short, gradually thickening into a lengthened, cylindrical club, the tip nearly truncate; Palpi, projecting, and longer above, than is the head; their tips acute; their joints concealed by compact scales. Type, Papilio Jasius. Auct. Specific Character. Wings above blackish, with a broad, common band, and an anterior spot of straw colour; beneath, having the band greenish, and margined with chesnut. Papilio Athamas. Cramer, Pl. 89. f. C. D. We can communicate but little on this elegant Butterfly, of which our figures represent the female: the other sex is known by having the straw coloured band much narrower; on the under surface this colour is prismatic; changing, in some lights, to a delicate pea green. The great size and thickness of the thorax, intimate a powerful and
- 65. rapid flight. The group is Oriental; but one species, the beautiful and rare Pap. Jasius. Lin. we have captured in the Island of Sicily, the most southern part of Europe. As we have not yet completed the analysis of this family of Butterflies, we know not the rank or true affinities of the present group. It is evidently either one of the lowest types of form, or a sub-genus. We have received both sexes of these insects from Java, where the species appears to be common. The resemblance of this group, to Rhetus and Marius, would seem to indicate points of strong natural analogy. We adopt the original specific name of Cramer: for we cannot, at this moment, trace the species in the voluminous works of Fabricius. Pl. 91. GEOTROCHUS pileus. Cap Land-Trochus.
- 66. G E O T R O C H U S pileus. Cap-shaped Land-trochus. Order Phytophages. Swains. Tribe —— Sub-Generic Character. Shell pyramidical, each volution, reckoning from the base, gradually diminishing and forming a conic spire, basal volution depressed, margin of the outer lip reflected and entire. Specific Character. Shell trochiform, smooth, generally banded with reddish and yellowish bands: volutious convex. Trochus Pileus. Chemnetz. Pl. 122. f. 1046-7-8. Helix pileus. Dillwyn. p. 933. No. 106. Lister. Tab. 14. f. 11. In Mus. Nost. Although this shell, in artificial arrangements, may be very well placed among the sub-divisions of Helix or Bulimus, we feel persuaded that it is, naturally, the type of a Sub-genus: we have no hesitation, therefore, in recording it as such. Another species, sharply carinated, semi-transparent, and of a milky whiteness, we discovered in Brazil: and we are thus led to conclude that the habitat
- 67. of Geotrochus pileus, which no author has yet mentioned, may probably be Tropical America. The figures of this species, given by Chemnitz and Born, represent it as marked by several narrow bands of a rufous brown colour: but the variety here delineated, has only one, of a deep purple; it is almost the only specimen answering to this description, which we have yet seen: both varieties are very rare, and much prized by collectors. GENERAL INDEX OF THE PLATES TO VOL. II. IN THE ORDER OF PUBLICATION. N.B. The number here affixed to the Plates, for convenience of reference, had better be marked in pencil upon the Plates themselves. No. 11. pl. Fluvicola cursoria 46 Macropteryx longipennis 47 Eudamus Agesilaus (F. 1.) 48 —— Doryssus (F. 2.) 48 Mitra episcopalis 49 Tiara Isabella 50 —— sulcata 50
- 68. No. 12. Sylvia Regulus 51 Phœnicornis flammeus 52 Volutilithes muricina 53 —— pertusa (F. 2.) 53 Mitrella fusca (F. l.) 54 —— ocellata (F. 2.) 54 —— olivæformis (F. 3.) 54 Margarita crocata 55 No. 13. Nyctiornis amictus 56 Culicivora atricapilla 57 Olivella purpurata (F. 1.) 58 —— eburnea (F. 2.) 58 Marius Thetys 59 Eurymus Philodice 60 No. 14. Gryllivora Saularis 61 Ptiliogonys cinereus 62 Amynthia Swainsonia 63 Ampullaria fasciata 64 Conus lithoglyphus 65 No. 15. Todus viridis 66 Murex Imperialis 67 Conus fumigatus 68 —— franciscanus (F. 2.) 68
- 69. Pieris Nigrina 69 Eurymus Europome 70 No. 16. Malaconotus Barbarus 71 Donacobius vociferans 72 Murex erythrostomus 73 Euterpe Teria 74 Peleus Æacus (F. 1.) 75 —— Gentius (F. 2.) 75 No. 17. Malaconotus atrococcineus 76 Harpula vexillum 77 Hiatula Lamarci (F. 1.) 78 —— pallida (F. 2.) 78 —— maculosa (F. 3.) 78 Pieris (Melete) Limnobia 79 Crateropus Reinwardii 80 No. 18. Prionites Mexicanus 81 Trogon Mexicanus 82 Cymbiola Vespertilio 83 Voluta Cymbium 84 Endymion regalis 85 No. 19. Garrulus sordidus 86 Scaphella maculata 87 Arcas Imperialis 88
- 70. Chlorisses Sarpedon 89 Jasia Athama 90 No. 20. Geotrochus pileus 91 GENERAL ALPHABETIC INDEX OF LATIN AND ENGLISH NAMES, &c., TO VOL. II. Ampullaria fasciata, 64 Amynthia Swainsonia, 63 Apple Snail, fasciated, 64 Arcas, S. G. Characters of, 88 —— Imperialis, 88 Butterfly, Sarpedon, 89 —— Athama, 90 Chlorisses, S. G. Characters of, 89 —— Sarpedon, 89 Conus fumigatus, 68 —— franciscanus, 68 —— lithoglyphus, 65 Crateropus, G. Characters of, 80 —— Reiwardii, 80 Culicivora, G. Characters of, 57 —— atricapilla, 57
- 71. Cymbiola, G. Characters of, 83 —— Types of form, 83 —— vespertilio, 83 Dial Bird, 62 Donacobius, S. G. Characters of, 72 —— vociferans, 72 Eudamus, G. Characters of, 48 —— Agesilaus, 48 —— Doryssus, 48 Eudymion, S. G. Characters of, 85 —— regalis, 85 Eurymus, S. G. Characters of, 60 —— Philodice, 60 —— Europome, 70 Euterpe, G. Characters of, 74 —— Teria, 74 Fluvicola cursoria, 46 Garrulus sordidus, 86 Geotrochus, S. G. Characters of, 91 —— pileus, 81 Golden crested Warbler, 51 Gryllivora, S. G. Characters of, 61 —— Saularis, 61 Harpula, G. Characters of, 77 —— Types of form, 77 —— vexillum, 77 Hiatula, S. G. Characters of, 78 —— Lamarci, 78 —— pallida, 78 —— maculosa, 78 Jasia Athama, 90 Jay, Dusky, 86 Land-trochus, cap-shaped, 91
- 72. Macropterx, S. G. Characters of, 47 —— longipennis,, 47 Malaconotus atrococcineus, 76 —— barbarus, 71 Marius Thetys, 59 Melete, S. G. Characters of, 79 —— Limnobia, 79 Mitranæ (Pl. 4.), 49 —— (Pl. 5.), 50 —— (Pl. 6.), 54 Mitra episcopalis, 49 Mitrella, G. Characters of, 54 —— fusca, 54 —— ocellata, 54 —— olivæformis, 54 Muricinæ (Pl. 1.), 67 —— (Pl. 2.), 73 Murex crythrostomus, 73 —— Imperialis, 67 Motmot, Mexican, 81 Nyctiornis, G. Characters of, 56 —— amictus, 56 Nightfeeder, Duvaucels, 56 Olivæ (Pl. 2.), 78 —— (Pl. 3.), 78 Olivella, S. G. Characters of, 58 —— eburnea, 58 —— purpurata, 58 Olive, purple mouthed, 58 —— ivory, 58 Olives, the wide mouthed, 78 Pearl Oyster, orange, 55 Peleus, G. Characters of, 75
- 73. —— Æacus, 75 —— Gentius, 75 Phœnicornis, G. Characters of, 52 —— flammeus, 52 Pieris, G. Characters of, 66 —— Nigrina, 69 Ptiliogonys cinereus, fem., 62 Prionites Mexicanus, 81 Redbird, orange, 52 Scaphella, G. Characters of, 87 —— maculata, 87 Shrike, Barbary, 71 —— Burchells, 76 Strombidæ, Ch. of the family, 65 Sylvia G. Characters of, 51 —— Regulus, 51 Thiara, G. Characters of, 50 —— Isabella, 50 —— sulcata, 50 Thrush, babbling, 72 Todinæ, Characters of, 66 Todus, viridis, 66 Tody, Green, 66 Trogon Mexicanus, 82 Trogon Mexican, 82 —— habits of, 82 Voluta, G. Characters of, 84 —— Types of form, 84 —— vespertileo, 84 Volute, clouded melon, 83 —— Bat, 84 —— Orange flag, 77 Volutilithes, G. Characters of, 53
- 74. *** END OF THE PROJECT GUTENBERG EBOOK ZOOLOGICAL ILLUSTRATIONS, SECOND SERIES, VOLUME 2 *** Updated editions will replace the previous one—the old editions will be renamed. Creating the works from print editions not protected by U.S. copyright law means that no one owns a United States copyright in these works, so the Foundation (and you!) can copy and distribute it in the United States without permission and without paying copyright royalties. Special rules, set forth in the General Terms of Use part of this license, apply to copying and distributing Project Gutenberg™ electronic works to protect the PROJECT GUTENBERG™ concept and trademark. Project Gutenberg is a registered trademark, and may not be used if you charge for an eBook, except by following the terms of the trademark license, including paying royalties for use of the Project Gutenberg trademark. If you do not charge anything for copies of this eBook, complying with the trademark license is very easy. You may use this eBook for nearly any purpose such as creation of derivative works, reports, performances and research. Project Gutenberg eBooks may be modified and printed and given away—you may do practically ANYTHING in the United States with eBooks not protected by U.S. copyright law. Redistribution is subject to the trademark license, especially commercial redistribution. START: FULL LICENSE
- 75. THE FULL PROJECT GUTENBERG LICENSE
- 76. PLEASE READ THIS BEFORE YOU DISTRIBUTE OR USE THIS WORK To protect the Project Gutenberg™ mission of promoting the free distribution of electronic works, by using or distributing this work (or any other work associated in any way with the phrase “Project Gutenberg”), you agree to comply with all the terms of the Full Project Gutenberg™ License available with this file or online at www.gutenberg.org/license. Section 1. General Terms of Use and Redistributing Project Gutenberg™ electronic works 1.A. By reading or using any part of this Project Gutenberg™ electronic work, you indicate that you have read, understand, agree to and accept all the terms of this license and intellectual property (trademark/copyright) agreement. If you do not agree to abide by all the terms of this agreement, you must cease using and return or destroy all copies of Project Gutenberg™ electronic works in your possession. If you paid a fee for obtaining a copy of or access to a Project Gutenberg™ electronic work and you do not agree to be bound by the terms of this agreement, you may obtain a refund from the person or entity to whom you paid the fee as set forth in paragraph 1.E.8. 1.B. “Project Gutenberg” is a registered trademark. It may only be used on or associated in any way with an electronic work by people who agree to be bound by the terms of this agreement. There are a few things that you can do with most Project Gutenberg™ electronic works even without complying with the full terms of this agreement. See paragraph 1.C below. There are a lot of things you can do with Project Gutenberg™ electronic works if you follow the terms of this agreement and help preserve free future access to Project Gutenberg™ electronic works. See paragraph 1.E below.
- 77. 1.C. The Project Gutenberg Literary Archive Foundation (“the Foundation” or PGLAF), owns a compilation copyright in the collection of Project Gutenberg™ electronic works. Nearly all the individual works in the collection are in the public domain in the United States. If an individual work is unprotected by copyright law in the United States and you are located in the United States, we do not claim a right to prevent you from copying, distributing, performing, displaying or creating derivative works based on the work as long as all references to Project Gutenberg are removed. Of course, we hope that you will support the Project Gutenberg™ mission of promoting free access to electronic works by freely sharing Project Gutenberg™ works in compliance with the terms of this agreement for keeping the Project Gutenberg™ name associated with the work. You can easily comply with the terms of this agreement by keeping this work in the same format with its attached full Project Gutenberg™ License when you share it without charge with others. 1.D. The copyright laws of the place where you are located also govern what you can do with this work. Copyright laws in most countries are in a constant state of change. If you are outside the United States, check the laws of your country in addition to the terms of this agreement before downloading, copying, displaying, performing, distributing or creating derivative works based on this work or any other Project Gutenberg™ work. The Foundation makes no representations concerning the copyright status of any work in any country other than the United States. 1.E. Unless you have removed all references to Project Gutenberg: 1.E.1. The following sentence, with active links to, or other immediate access to, the full Project Gutenberg™ License must appear prominently whenever any copy of a Project Gutenberg™ work (any work on which the phrase “Project Gutenberg” appears, or with which the phrase “Project Gutenberg” is associated) is accessed, displayed, performed, viewed, copied or distributed:
- 78. This eBook is for the use of anyone anywhere in the United States and most other parts of the world at no cost and with almost no restrictions whatsoever. You may copy it, give it away or re-use it under the terms of the Project Gutenberg License included with this eBook or online at www.gutenberg.org. If you are not located in the United States, you will have to check the laws of the country where you are located before using this eBook. 1.E.2. If an individual Project Gutenberg™ electronic work is derived from texts not protected by U.S. copyright law (does not contain a notice indicating that it is posted with permission of the copyright holder), the work can be copied and distributed to anyone in the United States without paying any fees or charges. If you are redistributing or providing access to a work with the phrase “Project Gutenberg” associated with or appearing on the work, you must comply either with the requirements of paragraphs 1.E.1 through 1.E.7 or obtain permission for the use of the work and the Project Gutenberg™ trademark as set forth in paragraphs 1.E.8 or 1.E.9. 1.E.3. If an individual Project Gutenberg™ electronic work is posted with the permission of the copyright holder, your use and distribution must comply with both paragraphs 1.E.1 through 1.E.7 and any additional terms imposed by the copyright holder. Additional terms will be linked to the Project Gutenberg™ License for all works posted with the permission of the copyright holder found at the beginning of this work. 1.E.4. Do not unlink or detach or remove the full Project Gutenberg™ License terms from this work, or any files containing a part of this work or any other work associated with Project Gutenberg™. 1.E.5. Do not copy, display, perform, distribute or redistribute this electronic work, or any part of this electronic work, without prominently displaying the sentence set forth in paragraph 1.E.1
- 79. with active links or immediate access to the full terms of the Project Gutenberg™ License. 1.E.6. You may convert to and distribute this work in any binary, compressed, marked up, nonproprietary or proprietary form, including any word processing or hypertext form. However, if you provide access to or distribute copies of a Project Gutenberg™ work in a format other than “Plain Vanilla ASCII” or other format used in the official version posted on the official Project Gutenberg™ website (www.gutenberg.org), you must, at no additional cost, fee or expense to the user, provide a copy, a means of exporting a copy, or a means of obtaining a copy upon request, of the work in its original “Plain Vanilla ASCII” or other form. Any alternate format must include the full Project Gutenberg™ License as specified in paragraph 1.E.1. 1.E.7. Do not charge a fee for access to, viewing, displaying, performing, copying or distributing any Project Gutenberg™ works unless you comply with paragraph 1.E.8 or 1.E.9. 1.E.8. You may charge a reasonable fee for copies of or providing access to or distributing Project Gutenberg™ electronic works provided that: • You pay a royalty fee of 20% of the gross profits you derive from the use of Project Gutenberg™ works calculated using the method you already use to calculate your applicable taxes. The fee is owed to the owner of the Project Gutenberg™ trademark, but he has agreed to donate royalties under this paragraph to the Project Gutenberg Literary Archive Foundation. Royalty payments must be paid within 60 days following each date on which you prepare (or are legally required to prepare) your periodic tax returns. Royalty payments should be clearly marked as such and sent to the Project Gutenberg Literary Archive Foundation at the address specified in Section 4, “Information
- 80. about donations to the Project Gutenberg Literary Archive Foundation.” • You provide a full refund of any money paid by a user who notifies you in writing (or by e-mail) within 30 days of receipt that s/he does not agree to the terms of the full Project Gutenberg™ License. You must require such a user to return or destroy all copies of the works possessed in a physical medium and discontinue all use of and all access to other copies of Project Gutenberg™ works. • You provide, in accordance with paragraph 1.F.3, a full refund of any money paid for a work or a replacement copy, if a defect in the electronic work is discovered and reported to you within 90 days of receipt of the work. • You comply with all other terms of this agreement for free distribution of Project Gutenberg™ works. 1.E.9. If you wish to charge a fee or distribute a Project Gutenberg™ electronic work or group of works on different terms than are set forth in this agreement, you must obtain permission in writing from the Project Gutenberg Literary Archive Foundation, the manager of the Project Gutenberg™ trademark. Contact the Foundation as set forth in Section 3 below. 1.F. 1.F.1. Project Gutenberg volunteers and employees expend considerable effort to identify, do copyright research on, transcribe and proofread works not protected by U.S. copyright law in creating the Project Gutenberg™ collection. Despite these efforts, Project Gutenberg™ electronic works, and the medium on which they may be stored, may contain “Defects,” such as, but not limited to, incomplete, inaccurate or corrupt data, transcription errors, a copyright or other intellectual property infringement, a defective or
- 81. damaged disk or other medium, a computer virus, or computer codes that damage or cannot be read by your equipment. 1.F.2. LIMITED WARRANTY, DISCLAIMER OF DAMAGES - Except for the “Right of Replacement or Refund” described in paragraph 1.F.3, the Project Gutenberg Literary Archive Foundation, the owner of the Project Gutenberg™ trademark, and any other party distributing a Project Gutenberg™ electronic work under this agreement, disclaim all liability to you for damages, costs and expenses, including legal fees. YOU AGREE THAT YOU HAVE NO REMEDIES FOR NEGLIGENCE, STRICT LIABILITY, BREACH OF WARRANTY OR BREACH OF CONTRACT EXCEPT THOSE PROVIDED IN PARAGRAPH 1.F.3. YOU AGREE THAT THE FOUNDATION, THE TRADEMARK OWNER, AND ANY DISTRIBUTOR UNDER THIS AGREEMENT WILL NOT BE LIABLE TO YOU FOR ACTUAL, DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE OR INCIDENTAL DAMAGES EVEN IF YOU GIVE NOTICE OF THE POSSIBILITY OF SUCH DAMAGE. 1.F.3. LIMITED RIGHT OF REPLACEMENT OR REFUND - If you discover a defect in this electronic work within 90 days of receiving it, you can receive a refund of the money (if any) you paid for it by sending a written explanation to the person you received the work from. If you received the work on a physical medium, you must return the medium with your written explanation. The person or entity that provided you with the defective work may elect to provide a replacement copy in lieu of a refund. If you received the work electronically, the person or entity providing it to you may choose to give you a second opportunity to receive the work electronically in lieu of a refund. If the second copy is also defective, you may demand a refund in writing without further opportunities to fix the problem. 1.F.4. Except for the limited right of replacement or refund set forth in paragraph 1.F.3, this work is provided to you ‘AS-IS’, WITH NO OTHER WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED,
- 82. INCLUDING BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY OR FITNESS FOR ANY PURPOSE. 1.F.5. Some states do not allow disclaimers of certain implied warranties or the exclusion or limitation of certain types of damages. If any disclaimer or limitation set forth in this agreement violates the law of the state applicable to this agreement, the agreement shall be interpreted to make the maximum disclaimer or limitation permitted by the applicable state law. The invalidity or unenforceability of any provision of this agreement shall not void the remaining provisions. 1.F.6. INDEMNITY - You agree to indemnify and hold the Foundation, the trademark owner, any agent or employee of the Foundation, anyone providing copies of Project Gutenberg™ electronic works in accordance with this agreement, and any volunteers associated with the production, promotion and distribution of Project Gutenberg™ electronic works, harmless from all liability, costs and expenses, including legal fees, that arise directly or indirectly from any of the following which you do or cause to occur: (a) distribution of this or any Project Gutenberg™ work, (b) alteration, modification, or additions or deletions to any Project Gutenberg™ work, and (c) any Defect you cause. Section 2. Information about the Mission of Project Gutenberg™ Project Gutenberg™ is synonymous with the free distribution of electronic works in formats readable by the widest variety of computers including obsolete, old, middle-aged and new computers. It exists because of the efforts of hundreds of volunteers and donations from people in all walks of life. Volunteers and financial support to provide volunteers with the assistance they need are critical to reaching Project Gutenberg™’s goals and ensuring that the Project Gutenberg™ collection will
- 83. remain freely available for generations to come. In 2001, the Project Gutenberg Literary Archive Foundation was created to provide a secure and permanent future for Project Gutenberg™ and future generations. To learn more about the Project Gutenberg Literary Archive Foundation and how your efforts and donations can help, see Sections 3 and 4 and the Foundation information page at www.gutenberg.org. Section 3. Information about the Project Gutenberg Literary Archive Foundation The Project Gutenberg Literary Archive Foundation is a non-profit 501(c)(3) educational corporation organized under the laws of the state of Mississippi and granted tax exempt status by the Internal Revenue Service. The Foundation’s EIN or federal tax identification number is 64-6221541. Contributions to the Project Gutenberg Literary Archive Foundation are tax deductible to the full extent permitted by U.S. federal laws and your state’s laws. The Foundation’s business office is located at 809 North 1500 West, Salt Lake City, UT 84116, (801) 596-1887. Email contact links and up to date contact information can be found at the Foundation’s website and official page at www.gutenberg.org/contact Section 4. Information about Donations to the Project Gutenberg Literary Archive Foundation Project Gutenberg™ depends upon and cannot survive without widespread public support and donations to carry out its mission of increasing the number of public domain and licensed works that can be freely distributed in machine-readable form accessible by the widest array of equipment including outdated equipment. Many
- 84. Welcome to our website – the perfect destination for book lovers and knowledge seekers. We believe that every book holds a new world, offering opportunities for learning, discovery, and personal growth. That’s why we are dedicated to bringing you a diverse collection of books, ranging from classic literature and specialized publications to self-development guides and children's books. More than just a book-buying platform, we strive to be a bridge connecting you with timeless cultural and intellectual values. With an elegant, user-friendly interface and a smart search system, you can quickly find the books that best suit your interests. Additionally, our special promotions and home delivery services help you save time and fully enjoy the joy of reading. Join us on a journey of knowledge exploration, passion nurturing, and personal growth every day! ebookbell.com