`
`imven?
`
`CEEERERSF
`
`Seaeaeee
`ROSccicaan
`
`Zynga Ex. 1024, p. 1
`Zynga v. IGT
`IPR2022-00368
`
`;
`=
`Foreword by David Bunnell
`,
`Personal Computing Pioneer, CEO of Upside Magazine, Founder of PC Alagazine,
`an)OEMAAUeneR LOMOCRONIOMNGUNValieald
`.
`=
`
`Zynga Ex. 1024, p. 1
`Zynga v. IGT
`IPR2022-00368
`
`Zynga Ex. 1024, p. 1
`Zynga v. IGT
`IPR2022-00368
`
`
`
`Library of Congress Cataloging-in-Publication Data
`
`A CIP catalog recordforthis book can be obtained tromthe Library of Congress.
`
`He
`
`s*
`
`ff
`
`__
`
`
`CONTENTS
`
`
`
`2
`
`
`<
`, !
`ae
`ES
`BN
`M
`4
`5
`“|
`bare
`
`
`
`Loc
`ontrol Number
`| | | |
`||
`| |
`
`
`
`
`2004
`
`272165
`
`vil
`
`Zynga Ex. 1024, p. 2
`Zynga v. IGT
`IPR2022-00368
`
`
`
`
`
`xvii
`Foreword by David Bunnell
` }
`°
`q cknowledgments—xxiEditorial/production supervision: Mary Sudul ~ —
`
`
`
`Ackn
`i
`vee
`|
`Oe)
`Chapter 1
`Coverdesign director: Jerry Votta
`iM,
`;
`vet design: DesignSource
`—_
`7
`Introduction
`1
`
`‘|
`anufacturing manager: Maura Zaldivai
`5/0 Z
`;
`Fy
`Acquisitions editor: Jill Harry
`What Are WebServices?
`GA
`Editorial assistant: Brenda Mulligan
`nase?
`SOAP 6
`Marketing manager: Dan DePasquale
`Oo o 13
`a
`Publisher, HP Books: Mark Stouse
`WSDL 7
`.
`Manager and Associate Publisher, HP Books: Victoria Brandow
`( Lfgo
`.
`UDDI
`7
`Y,
`«At
`8
`f
`© 2004 Hewlett-Packard Corp.
`“7DLS /
`Why WebServices Are Important
`8
`r
`N Published by Prentice Hall PTR
`A YoY f
`The Evolution ofWeb Applications
`partic Pearson Education,Inc.
`wee
`Not Just Another Distributed Computing Platform 10
`
`PTR
`WebServices and Enterprises
`11
`HALL”
`Upper Saddle River, New Jersey 07458
`ot
`.
`Moving Forward
`12
`This material may be distributed only subject to the terms and conditions set forth in the Open
`Summary
`13
`Publication License, v1.0 orlater(the latest version is presently available at
`14
`Architect’s Note
`<http://www.opencontent.org/openpub/>).
`
`Prentice Hall books are widely usedby corporations and government agenciesfortraining, marketing,
`andresale.
`The publisher offers discounts on this book whenorderedin 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 trademarksor registered trademarksoftheir
`respective owners.
`Printed in the United States ofAmerica
`Ist Printing
`ISBN 0-13-140160-2
`Pearson Education LTD.
`Pearson Education Australia PTY, Limited
`PearsonEducationSingapore,Pte.Ltd.
`Pearson Education Canada, Ltd.
`Pearson Education North Asia Ltd.
`Pearson Educacién de Mexico, S.A. de C.V.
`Pearson Education — Japan
`Pearson Education Malaysia, Pte. Ltd.
`
`Basic Web Services Standards, Technologies, and
`Part1
`
`Concepts 15
`
`Chapter 2
`
`17
`
`17
`XML Fundamentals
`XML:The Lingua Franca ofWeb Services
`ML Nan 19
`amespaces
`21
`Explicit and Default Namespaces
`Inheriting Namespaces
`24
`And Not Inheriting Namespaces
`.
`Attributes and Namespaces
`25
`XMLSchema
`26
`chema and Namespaces
`XML Sch
`
`23
`24
`a
`
`27
`
`Zynga Ex. 1024, p. 2
`Zynga v. IGT
`IPR2022-00368
`
`
`
`
`viii
`Contents
`
`
`Contents
`
`28
`A First Schema
`Implementing XML Schema Types
`The any Element
`44
`Inheritance
`48
`50
`Substitution Groups
`Global and Local Type Declarations
`Managing Schemas
`54
`Schemas and Instance Documents
`
`XML Schema Best Practices
`
`59
`
`30
`
`52
`
`WSDL 98
`
`WSDLStructure 98
`
`The Stock Quote WSDL Interface
`Definitions
`100
`
`100
`
`The Types Element
`Bindings
`104
`Services
`107
`
`101
`
`58
`
`108
`
`
`
`4
`
`\) r
`‘
`
`:
`
`
`
`“a
`?,
`
`iW?
`ry
`ast
`re
`.-
`v)
`r,
`Ny
`WS
`:
`
`_
`Y%
`
`:
`oa
`B
`ay
`
`f
`
`Managing WSDL Descriptions
`Extending WSDL 110
`Using SOAP and WSDL 111
`Processing XML_60
`Service Implementation and Deployment
`112
`SAX: Simple API for XML 61
`Binding to and Invoking Web Services
`113
`64
`DOM:Document Object Model
`Where’s the Hard Work?
`117
`Extensible Stylesheet Transformation (XSLT) and XML Path Language (XPATH)
`Summary
`68
`Architect’s Note
`4
`Tk
`Chapter 3
`RS
`Chapter 4
`UDDI—Universal Description, Discovery, and
`
`YF SOAP and WSDL_69
`Integration
`119
`.
`The SOAP Model
`69
`UDDI ata Glance
`119
`SOAP
`73
`
`68
`
`66
`
`118
`Summary
`Architect’s Note
`
`118
`
`75
`
`75
`79
`79
`
`83
`
`89
`92
`
`74
`SOAP Messages
`SOAP Envelope
`SOAP Header
`SOAP Body
`SOAP Faults
`SOAP Encoding
`SOAP RPC 85
`Using Alternative SOAP Encodings
`Document, RPC, Literal, Encoded
`Document
`92
`RPC 92
`Literal
`93
`Encoded
`93
`SOAP RPC and SOAP Document-Literal
`SOAP, WebServices, and the REST Architecture
`Looking Back to SOAP 1.1
`95
`Syntactic Differences between SOAP 1.2 and SOAP 1,1
`Changes to SOAP-RPC_
`97
`SOAP Encoding
`97
`
`93
`
`93
`
`Analogies with Telephone Directories
`The UDDI Business Registry
`124
`UDDI Underthe Covers
`127
`
`120
`
`127
`The UDDI Specification
`UDDI Core Data Structures
`
`127
`
`130
`Accessing UDDI
`134
`How UDDIIs Playing Out
`135
`UDDI and Lifecycle Management
`UDDI and Dynamic Access Point Management
`Summary
`139
`Architect’s Note
`
`140
`
`137
`
`96
`
`Zynga Ex. 1024, p. 3
`Zynga v. IGT
`IPR2022-00368
`
`
`
`
`
`Zynga Ex. 1024, p. 3
`Zynga v. IGT
`IPR2022-00368
`
`
`
`
`
`
`
`Contents
`
`xi
`
` x
`
`Contents
`
`Chapter5
`Conversations
`
`145
`
`Conversations Overview 145
`Conversational Requirements for B2B Interactions
`WebServices Conversation Language
`148
`Consuming WSCLInterfaces
`149
`WSCLInterface Components
`151
`Interactions
`151
`
`147
`
`Transitions
`
`158
`
`Conversations
`
`162
`
`164
`The Bar Scenario Conversation
`Relationship Between WSCL and WSDL_
`What WSCL Doesn’t Do
`173
`
`169
`
`173
`Summary
`Architect’s Note
`
`174
`
`Chapter 6
`Workflow 175
`
`175
`Business Process Management
`Workflows and Workflow Management Systems
`Workflows
`178
`Workflow Management Systems Drawbacks
`WebServices and Workflow 181
`Business Process Execution Language for Web Services (BPEL)
`The BPEL Stack
`182
`
`180
`
`178
`
`255
`
`The Two-Phase Commit Approach
`Dealing with Heuristic Outcomes
`263
`Advanced Topics: Nesting and Interposition
`Scaling Transactions to Web Services
`269
`OASIS Business Transaction Protocol
`271
`The BTP Model
`271
`
`266
`
`Implementing with BTP 276
`Consuming Transactional Web Services
`Client API
`278
`
`277
`
`280
`
`Underthe Covers: BTP’s Two-Pipe Model
`Transactionalizing Web Services
`284
`Supporting Infrastructure
`286
`Participants
`287
`Compensating Actions: A Strategy for Participant Implementation
`Integrating Participants and Services
`291
`The Transaction Manager
`293
`Bringing It All Together: A Cohesive Example
`BTP: Ina Nutshel!
`297
`
`294
`
`290
`
`181
`
`Other Web Services Transaction Protocols
`Microsoft .Net
`297
`
`297
`
`299
`J2EE and Enterprise Java Beans
`WS-Coordination and WS-Transaction
`
`300
`
`303
`Summary
`Architect’s Note
`
`303
`
`183
`Activities
`Service Linking, Partners, and Service References
`Message Properties and Property Aliases
`209
`Correlating Messages
`210
`218
`Containers and Data Handling
`Workflow Example: Online Shop
`222
`BPEL 1.1 and OASIS WSBPEL 246
`BPELandIts Relation to BPML, WSCI, WSEFL,Xlang, and Others
`
`205
`
`246
`
`247
`Summary
`Architect’s Note
`
`248
`
`Chapter 8
`305
`Security
`306
`Everyday Security Basics
`Security Is An End-to-End Process
`Data Handling and Forwarding
`Data Storage
`309
`310
`Errors in Identity
`310
`WebService Security Issues
`Data Protection and Encryption
`
`308 °.,
`309
`
`311
`
`Zynga Ex. 1024, p. 4
`Zynga v. IGT
`IPR2022-00368
`
`
`
`
`
`a &i
`
`e
`
`
`
`Chapter 7
`Transactions
`
`249
`
`a P
`
`art2 Advanced Web Services Technologies and
`Standards
`143
`ACID Transactions
`249
`IIaa
`Distributed Transactions and Two-Phase Commit
`254
`
`Zynga Ex. 1024, p. 4
`Zynga v. IGT
`IPR2022-00368
`
`
`
`e
`
`Oi
`
`a
`ty
`
`r
`
`7
`
`iY
`ye
`.
`+
`Oy
`:
`my
`mS
`
`&
`}
`
`'
`
`
`xii
`Contents
`
`
`Contents
`xiii
`
`Authentication and Authorization
`Non-Repudiation and Signatures
`Types of Security Attacks and Threats
`Malicious Attacks
`323
`
`315
`317
`323
`
`Denial of Service Attacks
`
`324
`
`331
`
`361
`
`362
`
`357
`Use Resources Efficiently
`Building QoS into Web Services and Applications
`QoS-Enabled Web Services
`362
`Communicating QoS to Client Applications
`Lifecycle Management
`366
`QoS-Enabled Applications
`367
`367
`Monitoring QoS Performance
`370
`Discovering the Right Service
`Recovering from Service Failures
`371
`Summary
`372
`Architect’s Note
`
`372
`
`Chapter 10
`Mobile and Wireless
`
`375
`
`Mobile Web Services
`
`377
`
`379
`Challenges with Mobile
`The Wireless Network
`
`379
`
`Limited Computing Resources
`User Interfaces
`383
`
`382
`
`385
`Proxy-Based Mobile Systems
`Mobile Messaging Platform 386
`399
`Flash ActionScript Mobile Application UserInterface
`Invoking Web Services Directly Through a Proxy Server
`402
`Direct Mobile Web Service Access
`406
`
`J2ME WebServices
`
`411
`
`412
`Supported APIs
`Programming Model
`Summary
`413
`Architect’s Notes
`
`414
`
`413
`
`Chapter 11
`Portals and Services Management
`Portals
`415
`Programmatic and Interactive Web Service Interfaces
`The WSRPand WSIASpecifications
`421
`Building Portlets and Portals with WSRP 422
`Restrictions
`425
`
`415
`
`417
`
`Deploying and Locating Services
`Putting It All Together
`426
`
`426
`
`
`
`Zynga Ex. 1024, p. 5
`Zynga v. IGT
`IPR2022-00368
`
`
`
`325
`Dictionary Attacks
`Internal Threats
`325
`WebServices Security Roadmap
`WS-Security
`328
`The Security Header Element
`329
`The UsernameToken Element
`330
`331
`The BinarySecurityToken Element
`The SecurityTokenReference Element
`The KeyInfo Element
`332
`The Signature Element
`332
`The ReferenceList Element
`The EncryptedKey Element
`The EncryptedData Element
`Putting It All Together
`336
`Preventing Replay Attacks
`Summary
`341
`Architect’s Notes
`
`326
`
`333
`334
`335
`
`338
`
`341
`
`343
`
`Chapter 9
`Quality of Service
`WhatIs QoS?
`343
`346
`WhyIs QoS Important for Web Services?
`Full Control versus Predictable Worst-Case Performance
`QoS Metrics for Web Services
`347
`Where Are the Holes?
`349
`XML 349
`HTTP 349
`
`346
`
`349
`Communication Networks
`350
`Server-Side Infrastructure
`351
`Design Patterns and Best Practices
`Use Coarse-Grained Web Services
`Build the Right Client Application
`Cache WebService Results
`356
`
`352
`355
`
`Zynga Ex. 1024, p. 5
`Zynga v. IGT
`IPR2022-00368
`
`
`
`
`xiv
`Contents
`
`
`Contents
`xv
`
`=
`
`478
`Augmenting Remote WSDLInterfaces
`Implementing the BPEL Workflow Script
`479
`Deploying and Executing BPEL Workflows
`495
`Adding Transaction Support
`499
`501
`Changes to the Back End Systems
`Transaction-Aware Service Implementation
`Implementing Participants
`511
`Consuming Transactional Web Services
`Programming for Mobility
`522
`Securing the Application
`531
`HTTP Security
`531
`Summary
`536
`Architect’s Notes
`
`504
`
`518
`
`537
`
`Chapter 14
`539
`Epilogue
`Current Standards and Future Trends
`XML 539
`
`539
`
`SOAP and WSDL 540
`
`UDDI
`
`541
`
`Transactions
`
`541
`
`541
`Security
`Conversations
`
`542
`
`Workflow 542
`
`Quality of Service
`Mobile and Wireless
`
`543
`543
`
`Standards Organizations
`W3C 544
`
`544
`
`OASIS
`
`545
`
`WS-I
`
`545
`
`Vendor Specifications
`Platforms
`547
`
`546
`
`Microsoft .Net
`J2EE 547
`
`547
`
`A Single Web Services Platform?
`Summary
`548
`
`om
`
`548
`
`Index 551
`
`
`
`Zynga Ex. 1024, p. 6
`Zynga v. IGT
`IPR2022-00368
`
`
`
`429
`Summary
`429
`Web Services Management
`The Objectives of Web Services Management
`WebServices Management Modules
`43]
`WebServices Distributed Management
`434
`
`430
`
`434
`Summary
`435
`Architect’s Notes
`ce
`Part3
`Putting It All Together—Building Real World
`Enterprise Web Services and Applications
`437
`
`a C
`
`hapter 12
`Real World Web Service Application Development—
`Foundations
`439
`Enterprise Procurement
`439
`System Functionality and Architecture
`Running the EPS Application
`443
`System Implementation
`445
`VendorAOrdering.java 446
`VendorAProcurement.wsdl
`
`441
`
`449
`
`EPS.html
`
`452
`
`453
`EPSCatalog.html
`453
`ServiceServlet.java
`Client-Side Binding Stubs
`OutputServlet.java
`461
`462
`Deploying the Application
`465
`Running the Application
`Direct Web Service Invocations (without Binding Stubs)
`Where Are the Holes?
`471
`
`460
`
`469
`
`471
`Summary
`Architect’s Notes
`
`472
`
`Chapter 13
`Real World Web Service Application Development—
`Advanced Technologies
`473
`Introduction
`473
`Building Evolvable and Composable Workflows
`Automating the Procurement Process
`476
`
`475
`
`we+. *
`
`Levz
`
`Zynga Ex. 1024, p. 6
`Zynga v. IGT
`IPR2022-00368
`
`
`
`
`
`CHAPTER
`
`1
`
`Introduction
`
`
`
`eb services technologies are fundamentally changing the software industry, making the
`
`WW. of enterprise IT organizations more strategic, and recasting the software vendor-
`
`consumerrelationship. Web services are also being hailed by CEOs, CIOs, and CTOsas 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. Webservices 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 notget 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 beingrefined, andstill others are being discarded. The
`platform is essentially a movingtarget.
`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.
`How 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 Webser-
`vices or applications that consume Web services, you have to know where the platform is today,
`and whereit 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.
`
`Zynga Ex. 1024, p. 7
`Zynga v. IGT
`IPR2022-00368
`
`
`
`Zynga Ex. 1024, p. 7
`Zynga v. IGT
`IPR2022-00368
`
`
`
`Pe
`
`
`What Are Web Services?
`3
`
` 2
`
`« Introduction
`
`Chapter 1
`
`Application
`
`
`
`Capability A
`
`Capability B
`
`Capability C
`
`e
`oF“S
`
`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 numberofdifferent standards and technolo-
`gies, and more importantly,their inter-relationships as well as best practices for their use.
`Consideran 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 mustthe 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 Webservices from a growinglist of strategic partner 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
`guaranteesor atomic coordination between multiple, independent Web services be supported by
`applications? And, how canall of this be done securely so that corporate and individual informa-
`tion and intellectual property are safeguarded?
`In this book, we focus on how to develop Webservices andapplications within real world
`enterprise environments. We describe not only the vanilla Web services platform consisting of
`Client
`_
`Capability B=|———_|_Application
`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.
`Wediscuss the opportunities represented by Web services and, more importantly, describe
`best practices and architectural patterns for building enterprise systemsthat position you and
`your organization to mostfully 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 Webservices technologies, not on summarizing
`standards.
`Let’s get started by reviewing what Webservices are and whythey are important.
`
`(a) Monolithic application with integrated capabilities A,B, and C.
`
`URL Addresses
`
`Network
`
`Capability A
`
`Capability C
`
`(b) Client application invoking remote Webservices for capabilities A, B, and C.
`
`Figure 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:
`
`What Are Web Services?
`
`Webservices 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 andapplication 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 I-1.
`
`¢ 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.
`
`Someof these 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 andstill be
`compatible with all client applications.
`
`Zynga Ex. 1024, p. 8
`Zynga v. IGT
`IPR2022-00368
`
`
`
`
`
`
`Zynga Ex. 1024, p. 8
`Zynga v. IGT
`IPR2022-00368
`
`
`
`
`
`
`
`
`¢ Determine the stock ticker symbol for the company based on the company name.
`* Determinethe 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 between the 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 haveto build a database with the namesofall the companies in the coun-
`try and their associated stock ticker symbol. More importantly, we must maintain this database
`as companies are newly listed, become delisted, change their namesor their ticker symbol, or
`merge. To accessthe 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 theIT infrastructure that must also be putinto place.
`Unless you work for a brokeragefirm orare in the business of maintaining stock informa-
`the time and costs necessary to build the infrastructure necessary to support the stock
`tion,
`appreciation calculator are enormousand,in mostcases, prohibitively so. Until a brokerage firm
`itself decided to provide such a calculator, customers would have to make do withoutit.
`Webservices simplify and in many ways eliminate the need to build for yourself the sup-
`port infrastructure—both legal and technical. The calculator can be developed by simply passing
`messagesbetweenthe calculator application and the appropriate set of Web services. Figure 1-2
`graphically depicts the flow of messages, and the fundamentalarchitecture of a Webservices-
`based stock price appreciation calculator.
`Messagesare sent betweenthe calculator application and the following three Web services:
`
`* StockTickerNameToSymbolConverter, which accepts a company’s name and
`providesthe ticker tape symbol.
`* Real TimeStockQuoteLookup, which providesthe latest price of a stock based on
`its ticker tape symbol.
`
`c
`
`.Re
`ooCk
`
`o
`
`“Ss
`aeeT
`
`=
`
`"HPQ", "August 15, 2002"
`
`"15.00"
`
`Historical Stock Quote
`Look Up WebService
`
`Figure 1-2 Sending and receiving Web service messagesto build a stock price appreciation
`
`calculator.
`
`* HistoricalStockQuoteLookup, which provides the historical price of a stock
`based onits ticker tape symbolandthe desired date.
`
`Since each of these three Web services is provided, hosted, and managed by another com-
`pany, the developer of 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 HWPand only recently became HPQare (or 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 Webservices, 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-addedpiece andutilize third-party Web services for the remainderof
`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.
`
`Zynga Ex. 1024, p. 9
`Zynga v. IGT
`IPR2022-00368
`
`
`
`
`
`ae
`
`
`What Are Web Services?
`5
`
` 4
`
`¢ Introduction
`
`Chapter 1
`
`Each building block (Webservice) 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 thatis accessi-
`"Hewlett-Packard"
`EE
`ble by other applications through a network. Theclient application simply invokes the function-
`—SSS———aaa Stock Ticker Name
`ality of a Web service by sending it messages, receives return messages from the Web service
`and then usesthe 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 and testing times,
`maintenance costs, and overall errors are thereby reduced.
`Assumeyou wantto build a simple calculator application that determines the appreciation
`Real Time Stock Quote
`Business
`User
`in stock price for any company givenits corporate name and the date the stock was originally
`Look Up WebService
`"17,51"
`Logic
`Interface
`3—S$
`purchased. The application must do the following:
`
`Stock Price Appreciation
`Calculator Application
`
`To Symbol Converter ee WebService
`
`"HPQ"
`
`Zynga Ex. 1024, p. 9
`Zynga v. IGT
`IPR2022-00368
`
`
`
`
`What Are Web Services?
`
`.
`
`
`Taxi Booking
`Company
`
`
`Figure 1-3 Composing together services exposed by multiple corporati
`
`coving offering.
`
`p
`
`y
`
`p
`
`porations to create a separate
`
`
`
`
`
`WSDL
`
`WebServices Description Language (WSDL) is an XML-based language for describing Web
`services. Through a WSDLdescription, a client application can determine the location of the
`remote Webservice, the functions it 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 dispatchit to the location of the Webservice.
`WSDLdescriptions go hand-in-hand with the development of a new Webservice 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 (UDDIJ) is a specification for a registry of
`information for Web services. UDDI defines a means to publish and, more importantly, discover
`(or search for) information about Webservices, including WSDLfiles.
`
`Zynga Ex. 1024, p. 10
`Zynga v. IGT
`IPR2022-00368
`
` 6
`
`© Introduction
`
`Chapter 1
`
`* 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 ofits consumed Web services.
`* Significantly reduce time-to-market.
`
`As wetake this idea further, and more and more companies expose some of their internal
`capabilities as Web services, the real value of Web services lies in the composition of a set of
`Web services. Considerthe following two companies. Oneisa traffic service company that mon-
`‘tors automobile traffic on major roads and highways and predicts expected travel times. The
`second is a taxi reservation service companythat allows customersto 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 composedtogetherinto a single, more compelling and useful service—either by
`one of these two companies themselvesor by a third company.
`As an example, considertaking a taxito the airport before catching a flight for a meeting.
`Byleveraging the capabilities of both companiesthrough 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 her travel time, the taxi reservation can be held and an alert 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 individualservices of the two companies, we
`are able to create a more compelling and useful service fortravelers. 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 UDDI.
`
`SOAP
`Simple Object Access Protocol (SOAP) is an XML-based mechanism for exchanging informa-
`tion betweenapplications within a distributed environment. This information exchange mecha-
`nism canbe used to send messages between applications and, more specifically, can be used to
`implement remote procedure calls (RPCs). RPCsallow one application to invoke and use a pro-
`cedure(or capability) of another, possibly remote, application.
`SOAPdoesnot specify any application implementation 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. SOAPis typically used in conjunction with HTTP, which supports easy
`traversal of firewalls andis sufficiently lightweight to be used within mobile and wireless envi-
`ronments.
`
`&
`
`Ee
`
`*oeo
`
`Zynga Ex. 1024, p. 10
`Zynga v. IGT
`IPR2022-00368
`
`
`
`tfarrola
`WebeeUserInterfaceeattors
`eaService Ea
`
`sinessea Application=[rs|
`
`Why WebServices Are Important
`Webservicesrepresent a new paradigmin application architecture and development. The impor-
`tance of Web services is not that they are new, butthat 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-——Webapplications.
`
`The Evolution of Web Applications
`
`Webapplications are applications that are available via the World Wide Web (Web) and allow
`any user anywherein the world access to its capabilities. This is in contrast to olderclient-server
`applications in which only dedicated clients could access the applicationsresiding on the server.
`Webapplications grew the user base fromjust a few hundred client machines accessinga client-
`serverapplication, to millions of users across the Web accessing a Web application.
`The Web opened up 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 knowledgeofthe applica-
`tion’s communication requirements or underlying systems. Industry standard technologies such
`
`I
`
`j
`
`an
`
`Standard
`
`Another Web
`Service
`
`%,
`
`(b) Webservices architecture
`
`Figure 1-5 Evolution of Web applications to Web services and key architectural differences.
`
`
`
`
`
`8
`
`Chapter 1
`
`© Introduction
`
`
`Why WebServices Are Important
`9
`
`WSDL
`
`UDDI
`
`WSDL
`
`Publish
`
`Discover
`
`Web Service
`Producer
`
`\
`
`Invoke
`
`SOAP
`
`Consuming
`Application
`
`/
`
`Figure 1-4 The relationships between SOAP, WSDL, and UDDI.
`
`as HTTP and HTMLwereused to 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 Webapplication.
`Webservices build on and extend the Web application model. Web applications allow any
`Web browserto accessits functionality, with the application userinterface presented through the
`browser. Webservices take this a step further and allow anyclient application to access and use
`its capabilities.
`A Webapplication allows universal user accessto its capabilities by supporting industry
`standard interfaces to 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. Webser-
`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 Webservicesis
`shown in Figure 1-5.
`
`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.
`End
`WebApplication
`WebApplication
`——|User Interface |=_users
`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.
`
`Proprietary Interfaces &
`Custom Development
`
`Industry Standard
`Interfaces
`
`eae
`
`(a) Web application architecture
`
`i
`*
`
`Zynga Ex. 1024, p. 11
`Zynga v. IGT
`IPR2022-00368
`
`
`
`Zynga Ex. 1024, p. 11
`Zynga v. IGT
`IPR2022-00368
`
`
`
`al
`
`*fe
`
`als
`
`
`
`
`
`10
`
`Chapter 1
`
`« Introduction
`
`Web Services and Enterprises
`
`11
`
`S_
`
`Webservices advocate a services-oriented architecture for applications in whicha soft-
`ware componentprovidesits functionality as a service that can be leveraged by other software
`components. Such a service modelabstracts away many complex issues that 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-any communications. Web service stan-
`dards build on previous standards for communications and data representation, such as HTTP
`and HTML.
`The key enabler for Web services is XML. Although HTML and XMLaresimilarin that
`both are human-readable markup languages, HTMLis for presentation markup while XMLis
`for semantic markup. Thiscritical attribute of XML supports expressing application and func-
`tional semantics in a platform-independent manner
`that enables any-to-any information
`exchange.
`Someargue that Webservices are nothing new; they are simply the latest incarnation of
`distributed computing. In some sense that maybetrue, but whatis it about Web services that is
`driving the incredible buzz? Why are entrepreneurs, CEOsof established companies, and indus-
`try analysts excit