throbber
publishing partner @ 7
`
`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

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket