invent
`publishing partner Oy
`
`osta
`yee a 7a)
`—byDavidBunnell
`
`agazine, Founder of PC Magazine,
`Personal Computing Pioneer, CEOof Upsi
`d
`PC World, MacWorld, Pérsonal Computing, and New Media
`
`
`
`
`
`
`
`
`
`_':7=7s
`
`Page 1 of 150
`
`GOOGLEEXHIBIT 1027
`
`Page 1 of 150
`
`GOOGLE EXHIBIT 1027
`
`

`

`Developing Enterprise
`Web Services
`
`An Architect's Guide
`
`Sandeep Chatterjee, Ph.D.
`James Webber, Ph.D.
`
`www.hp.conv/hpbooks
`
`PEARSON EDUCATION
`PRENTICE HALL PROFESSIONAL TECHNICAL REFERENCE
`
`igyyce UPPER SADDLE River, NJ 07458
`PTR WWW.PHPTR.COM
`
`Page 2 of 150
`
`Page 2 of 150
`
`

`

`Library of Congress Cataioging-in-Publication Data
`
`A CIP catalog record for this book can be obtained from the Library of Congress.
`
`Editorial/production supervision: Mary Sudul
`Cover design director: Jerry Votta
`Cover design: DesignSource
`Manufacturing manager: Maura Zaldivar
`Acquisitions editor: Jil! Harry
`Editorial assistant: Brenda Mulligan
`Marketing manager: Dan DePasquale
`Publisher, HP Books: Mark Stouse
`Manager and Associate Publisher, HP Books: Victoria Brandow
`
`© 2004 Hewlett-Packard Corp.
`Published by Prentice Hall PTR
`eo Pearson Education, Inc.
`PTR Upper Saddle River, New Jersey 07458
`This material maybe distributed only subject to the terms and conditions set forth in the Open
`Publication License, v1.0 or later (the latest version is presently available at
`<hitp://www.opencontent.org/openpub/>).
`
`Prentice Hall books are widely used by corporations and governmentagenciesfor training, marketing,
`andresale.
`The publisher offers discounts on this book when ordered in bulk quantities. For more information,
`contact Corporate Sales Department, Phone: 800-382-3419; FAX: 201-236-7141;
`E-mail: corpsales@ prenhall.com
`Or write: Prentice Hall PTR, Corporate Sales Dept., One Lake Street, Upper Saddle River, NJ 07458.
`
`Otherproduct or company names mentioned herein are the trademarksorregistered trademarks oftheir
`respective owners.
`
`Printed in the United States of America
`2nd Printing
`
`ISBN 0-13-140160-2
`
`Pearson Education LTD.
`Pearson Education Australia PTY, Limited
`Pearson Education Singapore, Pte, Ltd.
`Pearson Education North Asia Ltd.
`Pearson Education Canada, Ltd.
`Pearson Educacién de Mexico, 5.A. de CV.
`Pearson Education — Japan
`Pearson Education Malaysia, Pte. Ltd.
`
`Page 3 of 150
`
`Page 3 of 150
`
`

`

`
`
`FOREWORD
`
`The singing workmen shape and set andjoin
`Theirfrail new mansion’s stuccoed cove and quoin
`With no apparent sense that years abrade...
`—Thomas Hardy, Rome: Building a New Street in the Ancient Quarter, 1887
`
`K, Rome wasn’t built in a day, but once they got the sucker up and running, it was mag-
`nificent and, hey, it’s still there and functioning quite nicely. Having first heard about
`Web services toward the end ofthe last century, I would have thought by now they would be
`ubiquitous. Atthis pointin time, I should be able to replace My Yahoo with a personalized Web
`services portal uniquely suited to my quixotic needs and desires. Years ago, I started planning
`this portal when I heard Bill Gates waxing poetically about Hurricane-—a.k.a, “My Services”—
`which was Microsoft’s vision of creating a suite of personalized Web services for early adopters
`like me. Unfortunately, Microsoft abandonedthis effort when critics complainedit was really an
`insidious plot to own people’s personal information.
`Mostly by pure dumbluck,I’ve beenatthe forefront of technology for most of mylife. As
`a young man just out of college, I was working in Albuquerque, New Mexico, at a small com-
`pany called MITS which,with a little help from a then 19-year old Bili Gates andhis buddy Paul
`Allen, started the personal computing revolution. Taking advantage of this happysituation, J
`leveraged my background in media to launch a magazine called Personal Computing. These
`experiences led me to found a numberof other magazines including PC Magazine, PC World,
`Macworld, Publish, NewMedia, and BioWorld. Most recently I was CEO and Editor of Upside
`Media, inc.
`Throughout the years, T have been fortunate’to have had a first-band involvementin the
`evolution of maay revolutionary new innovations, including the first personal computer (Altair,
`
`xvi
`
`Page 4 of 150
`
`Page 4 of 150
`
`

`

`RERRAAi
`xviii
`Foreword
`
`the first portal computer (Osborne), the first spreadsheet (VisiCalc), the Macintosh Computer,
`Multi-Media, the Internet, and even Biotechnology.
`To say that I have seen my share of “paradigm shifts” is an understatement. Technology
`innovation has been all around me. Who would have thought that a couple of guys in a small
`company in Albuquerque would start what would later become the PC revolution? Shouldn'tit
`have comeout of IBM or Xerox or someother big technology company? That’s exactly the rub.
`Innovative ideas don’t always come from the big companies, sometimes they spring out from the
`big guys andat other times they spring out from thelittle guys,
`;
`Basedonall the above, I am completely convinced that Web services will level the playing
`field betweenthelittle guy and the big guy as no technology has ever done before. Thanksto this
`new revolution, the mom-and-pop company downthe street can market their innovative software
`and services to the neighborhood,to the global masses, as well as to the largest companiesin the
`world. But, we're not only talking about the new and interesting. Even the most mundane and
`boring is supported. The procurement system of the mom-and-pop company can seamlessly
`interface with the billing system of a global multinational company and here’s where things get
`really interesting. The systemsof the multinational can also interface with the systems of the
`mom-and-pop company. The most innovative new systems to the most boring, existing tasks are
`all available on an anybody-to-anybody basis. This will ultimately happen but like many great
`technologies,it will require a lot of work and patience before the dream is truly realized.
`As Sandeep Chatterjee and James Webber so eloquently and clearly explain in this book,
`real world Web services and Web services-based applications can’t simply be put together in a
`haphazard manner by merely reading through one of the Web services technology specifications.
`You need to be familiar with these standards and they are extremely important, but they only
`represent the basic building blocks. To “architect” and construct world-class enterprise services,
`developers need a much deeper knowledge of a numberof different standards and tools plus
`their “inter-relationships” and best practices for use.
`Web services are small segments of larger applications and as such, quality-of-service
`issues loom large if they are to be truly useful and scalable. When building them, you have to
`factor in such considerations as: Availability (how often is the service available for consump-
`tion); Accessibility (can it serve a client’s request now); Performance (how long doesit take to
`respond); Compliance(is it really “standard”); Security (is it safe to interact with this service);
`Energy (suitable for mobile apps); and Reliability (how often doesitfail). Like building Rome,
`building Web services gets complicated fast.
`So how do you architect an application to be reliable if some of the Web services you are
`depending on become unavailable? Can an application be written to seamlessly scale to support
`new Web services from an expanding group ofstrategic partners? What about transactional
`guarantees or atomic coordination between multiple, independent services? And can you accom-
`plish your design goal andstill provide adequate safeguards for corporate and individual infor-
`mation and intellectual property?
`Tiumagine that the software world would have given up in disgust by now, moved on to some
`new paradigm, except for two factors. Thefirst is that all the major software companies are com-
`
`Page 5 of 150
`
`Page 5 of 150
`
`

`

`
`xix
`
`mitted to Web services to the tune of several billion dollars, and the second is that Web services
`are, gosh darn-it, actually revolutionary. They are so revolutionary they represent a whole new
`amazing way of doing business, which will transform the software industry forever and change
`the very nature of the corporate IT department, thrusting it into the heart of strategic thinking.
`Web services buiid on and extend the Web application model by allowing any client appli-
`cation to access and useits capabilities. By implementing capabilities that are available to other
`applications (or even other Web services) via industry standard network and application inter-
`faces and protocols, Web services represent reusable software building blocks that are URL
`addressable. We're talking here about a concept called “anybody-to-anybody” communica-
`tions—quoting from this book, “a person who implements a Web service can be almost one hun-
`dred percentcertain that anybody else can communicate with and use the service.”
`Chatterjee and Webber aren’t so concemed, however, about Web services for the masses.
`They tackle a much more difficult topic, which is Web services for enterprises. These are ser-
`vices that have to be totally reliable, absolutely secure and extremely functional, Referring back
`to the “building Rome” analogy, these guys aren’t really talking about building foot paths or
`neighborhood streets, rather they are more interested in the avenues, aqueducts, and other major
`arteries that seamlessly and safely interconnect the Porticus of Gaius to the Forum of Caesar—
`the House of the Vestal Virgins to the Temple of Saturn, and back again. They are talking about
`the communication and transportation systems that made Rome the most magnificent function-
`ing city of the Ancient World.
`In today’s global marketplace, world class enterprises need to interconnect with their cus-
`tomers and partners internationally using legacy systems that are mostly incompatible with each
`other, and they need to do this relatively fast and as inexpensive as possible. Web services pro-
`vide the solution but not without overcoming some fairly difficult obstacles.
`In the Web services world, nothing is as simple as it may seem. Take transactions, for
`example. Transactions are the bedrock on which B2B interactionsrise or fall, they are a funda-
`mental abstraction or requirement for what we sometimes refer to as “fault-tolerant computing.”
`In a lucid and detailed styic, the authors point out that the choices fortransactions are scarce
`and, in fact, the OASIS Business Transaction Protocol (or simply BYP) is the “only Web ser-
`vices transaction protocol with implementation we can use today.” They explain BTP and how to
`implementit, but just in case you get in over your head, they also suggest that unless you have
`specialist knowledge in this area, you should give “serious consideration” to buying or outsoure-
`ingit,
`
`As with transactions, this book goes into great detail to describe the Web services technol-
`ogies and standards that can be used in the real world today. These address the most challenging
`enterprise requirements including conversations, workflow, security, the challenges inherent in
`the development of mobile systems, how io build user-facing portals by aggregating back-end
`Web services, and how to manage an ever growing number and type of Web services within the
`enterprise. But more than this, the authors tell you in a concluding section filled with source
`‘code and a step-by-step guide how to put this together. Youll leam how to actually develop a
`
`Page 6 of 150
`
`Page 6 of 150
`
`

`

`
`xx
`Foreword
`
`Web service application and deploy it onto the ‘Tomcat application server and the Axis SOAP
`server (both freely available).
`The ambitious goal of Developing Enterprise Web Services: An Architect’s Guide is to
`give readers a “thoroughunderstanding”of the steps necessary to build and deploy Web services
`and client applications that meet enterprise requirements. This is a lofty goal indeed, and you’ll
`want fo spend some serious time going through all the clear and concise contentthat the authors
`have spent weil over a year developing.I foundit really amazing.
`Fortunately, with the publication of this book, the Web services vision is about to take a
`giant leap forward. We are building our “Rome” and the endis finally in sight. Chatterjee and
`Webber, drawing on their own impressive experiences building Webservices, painstakingly pro-
`vide their readers with concise, yet thorough understanding of the most important issues and
`their solutions. They uslabashedly recommendbest practices in application architectures, put key
`technologies together and show their readers step-by-step how to build world-class, enterprise
`Webservices-based e-business applications. And darnit, it’s about time we had a booklike this!
`
`David Bunnell
`Berkeley, California
`September 2003
`
`Page 7 of 150
`
`Page 7 of 150
`
`

`

`CHAPTER.
`
`1
`
`Introduction
`
`eb services technologies are fundamentally changing the software industry, making the
`
`Ws. of enterprise IT organizations more strategic, and recasting the software vendor-
`
`consumer relationship. Web services are also being hailed by CEOs, ClOs, and CTOs as the
`next-generation vehicle for driving topline growth and controlling bottom lines. But, simply
`jumping on the Web services bandwagon won't lead to corporate success. Web services are sim-
`ply a platform; how companies implementa solution using this new technology determinestheir
`success and ultimately their return on investment (ROI). In this book, we take a no-nonsense,
`strategic view of developing enterprise Web services and applications: looking at where the
`technologies are, where they are going and how companies needto architect their own Web ser-
`vices solutions to not get left behind.
`Web services platforms provide the functionality to build and interact with distributed
`applications by sending eXtensible Markup Language (XML) messages. Additional technology
`layers are constantly emerging, others are being refined, andstill others are being discarded. The
`platform is essentially a moving target.
`To stay on the leading edge, companies are building and deploying their applications
`while work on the underlying platform continues. And, as with any industry standard initia-
`tives which require building consensus, the Web services platform will remain a work in
`progress for sometime,
`Hew can you build any meaningful application, let alone mission-critical enterprise applica-
`tions, on such a platform? If you are a developer or an architect.charged with building Web ser-
`vices or applications that consume Web services, you have to know where the platform is today,
`and where it is going. Otherwise, the endless pit of application rewrite and maintenance overhead
`will far outweigh any benefits that can be garnered from this promising new technology.
`
`Page 8 of 150
`
`Page 8 of 150
`
`

`

` 2
`
`Chapter 4 » Introduction
`
`Real world, enterprise Web services and applications cannot be developed by simply reading
`through the Simple Object Access Protocol (SOAP) or the Web Services Description Language
`(WSDL)specifications. Developers must understand a numberof different standards and technolo-
`gies, and more importantly,their inter-relationships as well as best practices for their use.
`Consider an e-business application that requires interaction between multiple partner Web
`services. Understanding SOAP and WSDLgives developers the ability to write Web services
`and consume them within their application, But, how must the application be architected to be
`reliable in case some Web services become unavailable? How can an application be written to
`seamlessly scale and support new Web services from a growinglist ofstrategic pattner compa-
`nies? What are the best practices for developing mobile Web service applications, and how can
`individual Web services be created to support quality-of-service (QoS)? How can transactional
`guarantees or atomic coordination between multiple, independent Web services be supported by
`applications? And, how can all of this be done securely so that corporate and individual informa-
`tion and intellectual property are safepuarded?
`Tn this book, we focus on how to develop Webservices and applications within real world
`enterprise environments. We describe not only the vanilla Web services platform consisting of
`SOAP, WSDL, and UDDI (Universal Description, Discovery and Integration), but also build on
`this to include the other technologies, standards, and emerging standards that provide support for
`transactions, security and authentication, mobile and wireless, quality-of-service, conversations,
`workflow, interactive applications and portals, as well as systems management.
`We discuss the opportunities represented by Web services and, more importantly, describe
`best practices and architectural patterns for building enterprise systems that position you and
`your organization to most fully leverage those opportunities. We do not summarize any one Web
`services standard, but instead provide a sufficiently thorough discussion of all of the critical
`technologies and standards, as well as their inter-relationships, that are necessary for building
`enterprise Web services and applications. Our focus is on developing enterprise Web services
`and applications based on industry standard Web services technologies, not on summarizing
`standards.
`
`Let's get started by reviewing what Web services are and why they are important.
`
`What Are Web Services?
`
`Web services represent a new architectural paradigm for applications. Web services implement
`capabilities that are available to other applications (or even other Web services) via industry
`standard network and application interfaces and protocols. An application can use the capabili-
`ties of a Web service by simply invoking it across a network without having to integrate it. As
`such, Web services represent reusable software building blocks that are URL addressable. The
`architectural differences between monolithic, integrated applications and Web services-based
`applications are depicted in Figure 1-1.
`
`Page 9 of 150
`
`Page 9 of 150
`
`

`

`
`
`What Are Web Services?
`
`3
`
`
`
` Application
`
`
`
`Capability A
`
`(a) Monolithic application with integrated capabilities A,B, and C.
`
`|
`Capability A
`
`Capability B
`
`Capabllity ¢
`
`URL Addresses
`
`
`Application
`
` Client
`
`(b) Client application Invoking remote Web services for capabilities A, B, and C,
`
`Figure 1-1 The architectural differences between (a) a monolithic application with integrated
`capabilities, and (b) a distributed application using Web services-based capabilities.
`
`The capabilities provided by a Web service can fall into a variety of categories, including:
`
`* Functions, such as a routine for calculating the integral square root of a number.
`* Data, such as fetching the quantity of a particular widget a vendor has on hand.
`* Business processes, such as accepting an order for a widget, shipping the desired
`quantity of widgets and sending an invoice,
`
`Someofthese capabilities are difficult or impractical to integrate within third-party applications.
`When these capabilities are exposed as Web services, they can be loosely coupled together,
`thereby achieving the benefits of integration without incurring the difficulties thereof.
`Web services expose their capabilities to client applications, not their implementations.
`This allows Web services to be implemented in any language and on any platform and still be
`compatible with all client applications.
`
`Page 10 of 150
`
`Page 10 of 150
`
`

`

`
`
`4
`
`Chapter 1 + introduction
`
`Eachbuilding block (Web service)is self-contained. It describes its own capabilities, pub-
`lishes its own programmatic interface and implements its own functionality thatis available as a
`hosted service. The business logic of the Web service runs on a remote machine that is accessi-
`ble by other applications through a network. Theclient application simply invokes the function-
`ality of a Web service by sending it messages, receives return messages from the Web service
`and then uses the results within the application. Since there is no need to integrate the Web ser-
`vice within the client application into a single monolithic block, development andtesting times,
`maintenance costs, and overall errors are thereby reduced.
`Assume you want to build a simple calculator application that determines the appreciation
`in stock price for any company given its corporate name and the date the stock was originally
`purchased. The application must do the following:
`
`* Determinethe stock ticker symbol for the company based on the company name.
`+ Determine the latest price of the stock based on the ticker symbol.
`« Determine the historical price of the stock for the given date based on the ticker
`symbol.
`* Calculate the difference betweenthe two stock prices and presentit to the user.
`
`This seemingly trivial application is in fact enormously complex. Right from the get go
`there are problems. We have to build a database with the namesofall the companiesin the coun-
`iry and their associated stock ticker symbol. More importantly, we must maintain this database
`as companies are newly listed, become delisted, change their names or their ticker symbol, or
`merge. To access the real-time price of a stock, we must have a relationship with a financial or
`brokerage firm. The legal complexities and hassles in architecting such a relationship is bad
`enough,not to mention the IT infrastructure that must also be put into place.
`Unless you work for a brokerage firm or are in the business of maintaining stock informa-
`tion, the time and costs necessary to build the infrastructure necessary to support the stock
`appreciation calculator are enormous and, in most cases, prohibitively so. Until a brokerage firm
`itself decided to provide such a caleulator, customers would have to make do withoutit.
`Webservices simplify and in many ways eliminate the need to build for yourself the sup-
`port infrastructure—bothlegal and technical. The calculator can be developed by simply passing
`messages between the calculator application and the appropriate set of Web services, Figure 1-2
`graphically depicts the ow of messages, and the fundamental architecture of a Web services-
`based stock price appreciation calculator,
`Messages are sent between the calculator application and the following three Web services:
`
`* StockTickerNameToSymbolCenverter, which accepts a company’s name and
`provides the ticker tape symbol.
`*RealTimesS tockQuot eLookup, which providesthe latest price of a stock based on
`its ticker tape symbol.
`
`Page 11 of 150
`
`Page 11 of 150
`
`

`

`
`
`What Are Web Services?
`
`5
`
`Stock Price Appreciation
`
`"Hewlett-Packard"
`i Stock Ticker Name
`suorn
`.
`To Symbol Converter
`ee Web Service
`
`Calculator Application
`
`
`lp "45,00"
`
`
`
`
`Real Time Stock Quote
`Look Up Web Service
`
`“HPQ*
`
`Business
`Logic
`
`"47.51"
`—_—_—_—<
`
`"HPQ", “August 15, 2002"
`
`Historical Stock Quote
`Look Up Web Service
`
`
`
`Figure 1-2 Sending and receiving Web service messages to build a stock price appreciation
`calcutator.
`
`* Historical stockQuoteLookup, which provides the historical price of a stock
`basedon its ticker tape symbol and the desired date.
`
`Since eachof these three Web services is provided, hosted, and managed by another com-
`pany, the developerof the calculator application has only to focus on his key insight or contribu-
`tion alone. Complex, domain-specific issues such as the fact that Hewlett-Packard’s ticker tape
`symbol was HWP and only recently became HPQ are (cr should be) handled by the Web ser-
`vices directly. Using these three Web services, the application can easily determine the stock
`price appreciation for Hewlett-Packard from August 15, 2002, to be $17.51 - $15.00 = $2.51.
`Based onthe data from the Web services, the calculator application can provide further analysis,
`such as the percentage appreciation, and presentall of the information in an easy-to-understand,
`graphical manner.
`.
`Assuming the required capabilities exist and are available as Web services, developers can
`focus on their unique value-added piece and utilize third-party Web services for the remainder of
`the functionality. The benefits of using Web services are clear:
`
`* Dramatically cut application development costs by focusing on your own value-added
`contribution and using third-party Web services for everythingelse.
`
`Page 12 of 150
`
`Page 12 of 150
`
`

`

`6
`
`Chapter 1
`
`* introduction
`
`* Integrate both data and business processes with market constituents and business
`partners that have desired domain expertise or capabilities.
`*Reduce or eliminate many errors born out of complex and large monolithic
`applications.
`* Simplify application maintenance and customization by segmenting an application into
`the client application and each of its consumed Web services.
`* Significantly reduce time-to-market.
`
`As wetake this idea further, and more and more companies expose someof their internal
`capabilities as Web services, the real value of Web services lies in the composition of a set of
`Web services. Consider the following two companies, Oneis a traffic service company that mon-
`itors automobile traffic on major roads and highways and predicts expected travel times. The
`secondis a taxi reservation service company that allows customers to reserve taxis for pickup at
`a specified location and time, Each of these companies and their products are compelling in and
`of themselves. However, if these companies exposed their capabilities as Web services, these
`services can be composed together into a single, more compelling and useful service——cither by
`one of these two companies themselves or by a third company.
`As an example, consider taking a taxi to the airport before catching a flight for a meeting.
`By leveraging the capabilities of both companies through their respective Web services,a trav-
`eler can reserve a taxi and rest assured that if an accident or other traffic conditions cause an
`unexpected increase in hertravel time, the taxi reservation can be held and analert sent to the
`traveler advising her of the updated taxi schedule as well as the traffic situation that caused the
`change. By simply andintelligently combining the individual services of the two companies, we
`are able to create a more compelling and useful service for travelers. The composition of Web
`services from different enterprises is depicted in Figure 1-3. The technologies that form the
`foundations of Web services are SOAP, WSDL, and UDDL
`
`SOAP
`
`Simple Object Access Protocol (SOAP) is an XML-based mechanism for exchanging informa-
`tion between applications within a distributed environment. This information exchange mecha-
`nism can be used te send messages between applications and, more specifically, can be used to
`implement remote procedure calls (RPCs). RPCs allow one application to invoke and use a pro-
`cedure (or capability) of another, possibly remote, application.
`SOAP does not specify any application iraplementation or programming model. Instead,it
`provides a mechanism for expressing application semantics that can be understood by applica-
`tions no matter how they are implemented. Accordingly, SOAP is application language- and
`platform-independent. SOAP is typically used in conjunction with HFTP, which supports easy
`traversal of firewalls and is sufficiently lightweight to be used within mobile and wireless envi-
`ronments.
`
`Page 13 of 150
`
`Page 13 of 150
`
`

`

`
`
`What Are Web Services?
`
`7
`
` Taxi Booking
`
`
`
`Figure 1-3 Composing together services exposed by multiple corporations to create a separate
`service offering.
`
`Company
`
`WSDL
`
`Web Services Description Language (WSDL) is an XML-based language for describing Web
`services. Through a WSDL description, a client application can determine the location of the
`remote Web service, the functionsit implements, as well as how to access and use each function.
`After parsing a WSDL description,a client application can appropriately format a SOAP request
`and dispatch it to the location of the Web service.
`WSDL descriptions go hand-in-hand with the development of a new Web service and are
`created by the producerof the service. WSDLfiles (or pointers thereto) are typically stored in
`registries that can be searched by potential users to locate Web service implementations of
`desired capabilities.
`
`UDDI
`
`Universal Description, Discovery, and Integration (UDDD is a specification for a registry of
`information for Web services. UDDI defines a meansto publish and, more importantly, discover
`(or search for) information about Web services, including WSDL. files,
`
`Page 14 of 150
`
`Page 14 of 150
`
`

`

`a
`
`Chapter 1
`
`* introduction
`
`WSDL
`
`UDDI
`
`WSDL
`
`Publish
`
`Discover
`
`Web Service
`Producer
`
`\
`
`Invoke
`
`SOAP
`
`Consuming
`Application
`
`/
`
`Figure 1-4 The relationships between SOAP, WSDL, and UDDI.
`
`After browsing through an UDDIregistry for information about available Web services,
`the WSDLforthe selected service can be parsed, and an appropriate SOAP message can be sent
`to the service. Figure 1-4 graphically illustrates the relationships between SOAP, WSDL, and
`UDDI.
`
`Now that we have a glimpse into what Web services are and how they can be used to build
`interesting applications and systems, we next discuss why this new technology is important.
`
`Why Web Services Are Important
`
`Webservices represent a new paradigm in application architecture and development. The impor-
`tance of Web services is not that they are new, but that this new technology addresses the needs
`of application development. To understand this new paradigm,let us first look at the application
`paradigm that preceded Web services-—Web applications.
`
`The Evolution of Web Applications
`
`Web applications are applications that are available via the World Wide Web (Web) and allow
`any user anywhere in the world accessto its capabilities. This is in contrast to older client-server
`applications in which only dedicated clients could access the applications residing on the server.
`Web applications grew the user base from just a few hundred client machines accessing a client-
`server application, to millions of users across the Web accessing a Web application.
`The Web openedup the floodgates to Web applications by allowing users to simply spec-
`ify a URL within a Web browser. Web applications also increased the difficulty of developing
`applications because a Web application client (a PC browser) has no knowledge of the applica-
`tion’s communication requirements or underlying systems. Industry standard technologies such
`
`Page 15 of 150
`
`Page 15 of 150
`
`

`

`
`
`Why Web Services Are Important
`
`a
`
`as HTTP and HTML were usedto bridge this gap between Web application clients and the Web
`applications themselves, Application servers and other middleware emerged to reduce the com-
`plexities of building Web ‘apps whilestill allowing pervasive access to each Web application.
`Webservices build on and extend the Web application model. Web applications allow any
`Webbrowserto accessits functionality, with the application user interface presented through the
`browser. Web services take this a step further and allow any client application to access and use
`its capabilities.
`,
`A Webapplication allows universal user access to its capabilities by supporting industry
`standard interfacesto its user interface. They do not allow extending or adding to their capabili-
`ties through programmatic access. To leverage the functionality of a Web application and build
`on it, complex and often unreliable techniques, such as screen scraping, must be used. Web ser-
`vices address this issue by allowing programmatic access to the Web services’ capabilities using
`industry standard interfaces and protocols. The evolution of Web applications to Web servicesis
`shown in Figure 1-5.
`
`Proprietary Interfaces &
`Custom Development
`
`Industry Standard
`Interfaces
`
`Users
`
`Web Application
`User Interface
`
`End
`
`(a) Web application architecture
`
`IndustryStandard
`es
`
`
`:
`
`Web Service
`Business Logic
`
`Web Application
`UserInterface Ney End
`Standard rr
`Appilcation
`
`-
`
`Users
`
`Another Web
`Service
`
`(b) Web services architecture
`
`Figure 1-5 Evolution of Web applications to Web services and key architectural differences.
`
`Page 16 of 150
`
`Page 16 of 150
`
`

`

`
`
`10
`
`Chapter 1 © introduction
`
`Web services advocate a services-oriented architecture for applications in which a soft-
`ware component provides its functionality as a service that can be leveraged by other software
`components. Such a service model abstracts away many complexissuesthat arise from software
`componentintegration, including platform compatibility, testing, and maintenance,
`Since Web service clients do not have information necessary to communicate with a Web
`service, a set of standards is necessary to allow any-to-amy communications. Web service stan-
`dards build on previous standards for communicati