®
`
`B
`
`ill Brogden
`
`SOAP Programm
`with Java”
`
`
` PLISI TRANSCEND
`
`TECHNIQUE™
`
`
`
`CineisFenaeOEAopievalidtiger
`
`Zynga Ex. 1011, p. 1
`Zynga v. IGT
`IPR2022-00368
`
`
`
`

`

` rogramn wnb8905670913
`
`8905b70%13¢
`
`Build Innovative Web Services
`
`Java
`
`
`
`Since its emergence in 1998, the Simple Object Access Protocol
`(SOAP) has cometo occupya central place in today’s breed of
`modular applications knownas WebServices. Thanks to SOAP,
`all you needis a basic knowledge of XMLto write programs
`that interact seamlessly with a growing numberof online
`services providing currency conversion,user authentication,
`and more.
`
`-
`
`But for every service that has been implemented,there are
`many more that remain mere ideas. SOAP Programming with
`Java provides the foundation andskills for realizing those ideas
`as fully functionalsolutions. Building on your knowledge
`of XML and XMLtools,you'll create your own SOAP-based
`services that use not only HTTP butalso the services media
`of the future: Java Message Service (JMS), JavaSpaces,
`and JavaMail. You'll also graduate from wired to wireless
`development,learning how Web-enabled devicesfit into the
`world of SOAP-based distributed computing.
`
`All this detailed, practical coverage is presented within the
`framework of Java programming,allowing you to capitalize
`on the advantages Java offers. Whether you use this book as an
`introduction to Web Services developmentoras a toolfor
`mastering particular techniques,it will equip you with a
`sound understanding and hard-to-findskills.
`
`On the CD
`The enclosed CD contains codeforall the book’s examples and
`a collection of programmingtools, including XMLutilities
`and a SOAP debugger that works over HT'TP. Youalso get a
`Java-based WebService and a sample implementationofa
`Java MessageService, both built using SOAP.
`
`About the Author
`
`Bill Brogden has been working with Java
`since version 1.0 was released.His first big
`Java project was an applet that presented
`animated near-real-time Major League
`Baseball games.Bill is employed by
`LANWrights, Inc., where he uses Java
`technology to develop online courseware.
`Hehas written several books aboutJava,
`including Java Developer’s Guide to Servlets
`and JSP and Java Developer’s Guide to
`E-Commerce with XML and JSB, both from
`Sybex. In his spare time,Bill reads science
`fiction andtrains basset hounds. Helives
`in the woodsnear Austin, Texas, with his
`wife, Rebecca, and numerous hounds.
`
`WebInfo
`
`Visit our websites for more information:
`www.sybex.com and www.sybexetrainer.com
`
`
` 97807821 a
`
`5Cls07z1a9281
`
`ISBN 0-7821-2928-5
`
`US $49.99 CAN $79.95 (H'S3
`IPR2022-al
`
`Zynga Ex. 1011, p. 2
`Zynga v. IGT
`IPR2022-00368
`
`

`

`SOAP Programming
`with Java’
`
`Bill Brogden
`
`ay
`
`SYBEX
`
`San Francisco « London
`
`Zynga Ex. 1011, p.3
`Zyngav. IGT
`IPR2022-00368
`
`Zynga Ex. 1011, p. 3
`Zynga v. IGT
`IPR2022-00368
`
`

`

`10987654321iaersit
`
`GraphicIllustrator: Tony Jonick
`Electronic Publishing Specialist: Maureen Forys, Happenstance Type-O-Rama
`Proofreaders: Emily Hsuan, Nelson Kim, Leslie Light, Laurie O’Connell, Yariv Rabinovitch, Nancy Riddiough
`Indexer: Jerilyn Sproston
`Cover Designer: Cary! Gorska, Gorska Design
`Cover Photographer: D. Nonmark/PhotoLink, PhotoDisc
`Copyright © 2002 SYBEX Ine., 1151 Marina Village Parkway, Alameda, CA 94501. World rights reserved. No part ofthis publication may
`be stored in a retrieval system, transmitted, or reproduced in any way, including but notlimited to photocopy, photograph, magnetic, or
`other record, without the prior agreement and written permissionof the publisher.
`“SOAP Version 1.2 Part 1:Messaging Framework" and “SOAP Version 1,2 Part 2: Adjunets” (in Appendix D, “SOAP Specifications”)
`Copyright © 2001 W3C © (MIT, INRIA, Keio), All Rights Reserved. W3Cliability, trademark, documentuse, and softwarelicensing
`rules apply.
`
`Library of Congress Card Number: 2001096978
`
`ISBN:0-7821-2928-5
`SYBEX and the SYBEXlogoare either registered trademarks or trademarks of SYBEXInc.in the United States and/or other countries.
`TRADEMARKS: SYBEX has attempted throughoutthis book to distinguish proprietary trademarks from descriptive terms by following
`thestyle used by the trademark holder wherever possible.
`‘The author and publisher have made their best efforts to prepare this book, and the contentis based uponfinal release software whenever
`possible. Portions ofthe manuscript may be based upon pre-release versions supplied by software manufacturer(s). Theauthor and the pub-
`lisher make no representation orwarranties ofany kind with regard to the completeness or accuracy ofthe contents herein and accept no
`liability of anykind including but notlimited to performance, merchantability, fimess for anyparticular purpose, or any losses or damages
`of any kind causedor alleged to be caused directly orindi rectly from this book,
`Manufactured in the United States of America
`
`Associate Publisher: Richard Mills
`Acquisitions Editor: Peter Arnold
`Developmental Editor: Tom Cirtin
`Editor: Sally Engelfried
`Production Editor: Mae Lum
`
`Technical Editor: Piroz Mohseni
`
`isconsin -
`
`728 State Street
`Madison, WI 53706-1494
`U.S.A.
`
`;
`
`Madison
`
`Zynga Ex. 1011, p. 4
`Zynga v. IGT
`IPR2022-00368
`
`Zynga Ex. 1011, p. 4
`Zynga v. IGT
`IPR2022-00368
`
`

`

`Contents
`
`Introduction
`
`xT
`
`Chapter 1
`Understanding XML Messaging
`1
`
`
`Messaging Architectures
`The Mental Shift
`The Spectrum of Complexity
`The Pioneer: EDI
`Messaging Systems as Applications
`Java Message Service
`Directory Systems
`Communicating Objects
`Another Pioneer: CORBA
`The Component Object Model
`Remote Method Invocation
`RMI and IIOP
`Java Programming and XML
`The Document Object Model
`The Simplified API for XML Processing
`Java Parser Toolkits
`XML Goodies
`XML-Based Messages
`The Forerunner to SOAP: XML-RPC
`The Major Players
`
`2
`3
`3
`3
`4
`4
`4
`5
`5
`6
`6
`7
`8
`9
`10
`10
`11
`12
`13
`15
`
`Chapter 2
`A Survey of SOAP
`17
`
`
`The Status of SOAP
`XMLProtocol Working Group
`The Components of SOAP 1.1
`Implementing SOAP in Java
`
`18
`19
`21
`21
`
`Zynga Ex. 1011, p. 5
`Zyngav. IGT
`IPR2022-00368
`
`Zynga Ex. 1011, p. 5
`Zynga v. IGT
`IPR2022-00368
`
`

`

`Contents
`
`
`21
`Things Left Out of SOAP
`22
`SOAP and Namespaces
`24
`More About Namespaces
`24
`The SOAP Envelope
`25
`The SOAP Header
`26
`The SOAP Body
`26
`Transmission with HTTP
`27
`SOAP HTTP Responses
`27
`SOAP Messages with Attachments
`28
`WSDL, UDDI, and SOAP
`28
`Sun Microsystems and SOAP
`29
`Java API for XML Messaging
`29
`Tracking the Status of SOAP
`31
`A SOAP Server Example
`Chapter 3
`
`Installing the Tomcat Server
`32
`Installing Tomcat
`32
`Web Applications in Tomcat
`34
`Tomcat Server Configuration
`37
`Installing a SOAP Web Application
`37
`What the WAR File Installs
`38
`Additional Libraries Needed
`38
`Testing the Installation
`39
`Deploying a Server Application
`40
`Deploying the AddressBook Service
`41
`What Deployment Created
`43
`Running the Address Client
`43
`How Deployment Works
`43
`Mapping and the SOAP Mapping Registry
`46
`The Actual Deploy Request
`47
`How AddressBook Works
`49
`‘Troubleshooting Server-Side SOAP
`51
`Classpath Problems
`52
`XML Parser Problems
`53
`Mystery Errors
`53
`Debugging Tools
`54
`
`Zynga Ex. 1011, p. 6
`Zyngav. IGT
`IPR2022-00368
`
`Zynga Ex. 1011, p. 6
`Zynga v. IGT
`IPR2022-00368
`
`

`

`
`
`Contents xi
`
`
`Chapter 4
`The Significance of WSDL and UDDI
`55
`
`High-Level Descriptions
`UDDI
`What About ebXML?
`Web Services Description Language (WSDL)
`Overview of WSDL
`Interpreting a WSDL Description
`Automated WSDL
`Creating WSDLfrom a Java Class
`Future Web Services
`
`
`Chapter 5
`How SOAP Encodes Data
`The SOAP Specifications
`Schema Evolution
`Simple Data Types
`A Note About the Examples
`Boolean Data
`Binary Data and Byte Arrays
`Compound Types
`Arrays
`Multiple References
`Apache SOAP Special Encoding
`Literal XML Encoding
`The Bean Serializer
`
`Behind the BeanSerializer
`
`Custom Serializers
`
`56
`56
`57
`58
`58
`62
`65
`65
`68
`
`_ 69
`70
`70
`72
`73
`76
`77
`77
`78
`79
`80
`81
`82
`
`83
`
`84
`
`
`Chapter 6
`Creating a SOAP Server Application
`87
`
`SOAP Server Architecture
`Delivering the SOAP Message
`Server Fault Codes
`
`The Defined Faultcodes
`How Apache SOAP Handles Faults
`Service Architecture
`The Publications Example
`
`88
`89
`94
`
`95
`96
`96
`97
`
`Zynga Ex. 1011, p. 7
`Zyngav. IGT
`IPR2022-00368
`
`Zynga Ex. 1011, p. 7
`Zynga v. IGT
`IPR2022-00368
`
`

`

`Contents
`xil
`
`
`99
`The Server Application Interface
`101
`Example Server Methods
`102
`Roll Your Own Server
`102
`XMLParsers for SOAP
`103
`A Bare Bones Server
`104
`Using SOAP Servers
`105
`SOAP Client Architecture with HTTP
`Chapter 7
`
`Apache SOAP Client Framework
`106
`RPC Client Architecture
`106
`The Call Class
`108
`The Parameter Class
`110
`Controlling HTTP Headers
`111
`The SOAPMappingRegistry Class
`112
`Client Side Debugging
`113
`Watching the Messages
`113
`Using the Exception Information
`113
`Some Common Problems
`114
`A Client for the Publications Server
`115
`Testing and Debugging
`122
`Building SOAP Clients
`124
`SOAPArchitecture Using Messages
`125
`Chapter 8
`
`Messaging Systemsin General
`126
`The Point-to-Point Model
`126
`The Publish/Subscribe Model
`127
`Advantages
`127
`Disadvantages
`127
`Reliability Requirements
`128
`SOAP Standards and Messaging
`128
`Java Message Service
`128
`Message Characteristics
`128
`Types ofJMS Messages
`129
`The SwiftM@Q Implementation
`130
`A Point-to-Point SOAP Messaging Example
`131
`Publish/Subscribe Messaging
`142
`
`Zynga Ex. 1011, p. 8
`Zyngav. IGT
`IPR2022-00368
`
`Zynga Ex. 1011, p. 8
`Zynga v. IGT
`IPR2022-00368
`
`

`

`JavaSpaces
`Operations in a JavaSpaces Space
`What's Different About Spaces?
`Getting Started with JavaSpaces
`Example SOAP Message in a Space
`Alternate SOAP Message Transport
`
`Contents
`
`xiii
`
`149
`150
`151
`152
`156
`162
`
`Chapter 9
`SOAPover E-mail
`163
`
`
`SOAP and E-mail So Far
`E-mail Standards
`The JavaMail API
`JavaMail Architecture
`The Part Interface and the Message Class
`The Role of Sessions
`Message Management
`The JavaBeans Activation Framework
`A JavaMail SOAP Example
`A DataSource for SOAP
`Creating and Sending Mail
`Receiving the Mail Message
`The Potential for SOAP and E-mail
`
`164
`164
`165
`165
`166
`166
`167
`167
`169
`169
`171
`174
`178
`
`
`
`Chapter 10=SOAP and .NET 179
`
`The .NET Vision
`The Problems
`The .NET MyServices Solution
`Microsoft Passport
`The Proposed My Services
`WhoWill Use My Services?
`Show Me the Money
`The .NET Tools
`Visual Studio.NET
`For Current Developer Information
`SOAP Compatibility Problems
`Reported Compatibility Problem Areas
`
`180
`180
`181
`183
`183
`184
`184
`184
`185
`185
`186
`186
`
`Zynga Ex. 1011, p. 9
`Zyngav. IGT
`IPR2022-00368
`
`Zynga Ex. 1011, p. 9
`Zynga v. IGT
`IPR2022-00368
`
`

`

`Contents
`xiv
`
`
`Chapter 11
`
`187
`The .NET Alternatives
`188
`Sun Open Network Environment
`188
`HP WebServices
`188
`IBM WebServices
`189
`Oracle Dynamic Services
`189
`SOAP and Web Services
`191
`SOAP and Database Access
`
`192
`Java and Databases
`JDBC Versions
`192
`JDBC Data Types, SQL, and SOAP
`193
`JDBC Drivers
`195
`Type 1 Drivers
`195
`Type 2 Drivers
`196
`Type 3 Drivers
`196
`Type 4 Drivers
`197
`The DriverManagerClass
`197
`Database Connections
`198
`SQL Statements
`199
`Working with Results
`199
`An Example of SOAP and JDBC
`200
`The Hypersonic SQL Database
`200
`Starting the Hypersonic Server
`201
`The ErrataQuery SOAP Service
`202
`SOAP and JDBC
`208
`SOAP Goes Wireless
`209
`
`
`Architectures for SOAP with Wireless Devices
`210
`SOAP on the Client Device
`210
`The Environmentof Increasing Connectivity
`212
`Does SOAP Belong on Wireless Devices?
`212
`The Organization ofJ2ME
`213
`Configurations and Profiles
`213
`Developing for J2ME
`214
`From Source Code to MIDlet
`215
`The J2ME Wireless Toolkit
`215
`
`Chapter 12
`
`Zynga Ex.1011, p. 10
`Zyngav. IGT
`IPR2022-00368
`
`Zynga Ex. 1011, p. 10
`Zynga v. IGT
`IPR2022-00368
`
`

`

`
`
`Contents XV
`
`SOAP in Small Places
`The kXML Parser
`The kSOAP Classes
`Creating the Project
`Compiling and Building
`Executing in the Phone Emulator
`Executing in the Palm Emulator
`Java Is Ideal for Wireless
`
`216
`217
`220
`222
`223
`224
`224
`226
`
`
`Chapter 13
`Situating SOAP in the Computing Landscape
`227
`SOAP’s Current Status
`228
`The Standards Framework
`228
`Performance Problems
`229
`SOAP and WebServices
`229
`The Future of Web Services
`230
`Standardization Efforts
`230
`The Announced WebServer Projects
`231
`XML Well Established
`231
`The Near Term Competitors for SOAP
`231
`SOAP’s Future
`232
`
`
`Appendix A
`SOAP Resources
`235
`
`Standards
`XML Protocol Working Group
`XML Schema
`Other W3C Resources
`Related Standards
`WebServices Description Language (WSDL)
`Universal Description, Discovery, and Integration (UDDI)
`The Internet Engineering Task Force (ETF)
`Sun, OASIS, UN/CEFACT, and ebXML
`Sun’s JAXM API
`XML Toolkits
`Apache XML
`Sun’s JAXP Package
`JDOM
`
`236
`236
`237
`237
`238
`238
`238
`238
`239
`239
`239
`239
`240
`240
`
`Zynga Ex. 1011, p. 11
`Zyngav. IGT
`IPR2022-00368
`
`Zynga Ex. 1011, p. 11
`Zynga v. IGT
`IPR2022-00368
`
`

`

`Contents
`xvi
`
`
`240
`Perl Language
`240
`Integration with Oracle Database
`241
`General SOAP Articles
`241
`SOAP andRelated Implementations
`242
`UDDIImplementations
`242
`Interoperability Related Sites
`242
`WebServices Development Using SOAP
`242
`Industry News Sources
`245
`SOAPServices Online
`Appendix B
`
`Currency Conversion Service
`246
`Text to Speech Service
`249
`Geographic Information Service
`253
`Debugging SOAP with UtilSnoop
`255
`Appendix C
`
`Using UtilSnoop
`256
`Setting Parameters
`256
`Snooping on Local Client-Server Conversation
`257
`Sending SOAP Messages from UtilSnoop
`257
`Capturing Client Messages
`258
`Limitations
`259
`The UtilSnoop Code
`259
`Updates
`273
`SOAP Specifications
`275
`Appendix D
`
`SOAP Version 1.2 Part 1: Messaging Framework
`276
`W3C Working Draft 2 October 2001
`276
`Abstract
`276
`Status of This Document
`276
`Table of Contents
`277
`1. Introduction
`279
`1.1 Design Goals
`279
`1.2 Notational Conventions
`280
`1.3. Example of SOAP Message
`280
`1.4 SOAP Terminology
`281
`2. SOAP Message Exchange Model
`283
`2.1
`SOAP Nodes
`283
`Zynga Ex. 1011, p. 12
`Zynga v. IGT
`IPR2022-00368
`
`Zynga Ex. 1011, p. 12
`Zynga v. IGT
`IPR2022-00368
`
`

`

`xvii
`Contents
`
`2.2. SOAP Actors and SOAP Nodes
`2.3 Targeting SOAP Header Blocks
`2.4 Understanding SOAP Headers
`2.5 Processing SOAP Messages
`3. Relation to XML
`4. SOAP Envelope
`4.1 Envelope Encoding and Versioning
`4.2 SOAP Header
`4.3
`SOAP Body
`44 SOAP Fault
`5. SOAP Transport Binding Framework
`5.1 Binding to Application-Specific Protocols
`5.2 Security Considerations
`6. References
`6.1 Normative References
`6.2
`Informative References
`Appendix A: Version Transition From SOAP/1.1 to SOAP Version 1.2
`Appendix B: Acknowledgments (Non-Normative)
`Appendix C: Part 1 Change Log (Non-Normative)
`C.1
`SOAP Specification Changes
`C.2. XML Schema Changes
`SOAP Version 1.2 Part 2: Adjuncts
`W3C Working Draft 2 October 2001
`Abstract
`Status of This Document
`‘Table of Contents
`1. Introduction
`1.1 Notational Conventions
`1.2 Examples of SOAP Messages
`1.3.
`SOAP Terminology
`2. Relation to XML
`3. The SOAP Data Model
`4. SOAP Encoding
`4.1 Rules for Encoding Types in XML
`4.2
`Simple Types
`4.3 Polymorphic Accessor
`
`283
`284
`284
`284
`285
`286
`287
`288
`291
`292
`296
`296
`297
`297
`297
`298
`298
`300
`302
`302
`307
`308
`308
`309
`309
`310
`312
`312
`313
`314
`314.
`315
`315
`316
`320
`323
`
`Zynga Ex. 1011, p. 13
`Zyngav. IGT
`IPR2022-00368
`
`Zynga Ex. 1011, p. 13
`Zynga v. IGT
`IPR2022-00368
`
`

`

`
`Contents
`xviii
`
`
`4.4 Compound Types
`4.5 Default Values
`4.6
`SOAP root Attribute
`5. Using SOAP for RPC
`5.1 RPC and SOAP Body
`5.2 RPC and SOAP Header
`5.3. RPC Faults
`6. Using SOAP in HTTP
`6.1
`SOAP HTTP Request
`6.2
`SOAP HTTP Response
`6.3 The HTTP Extension Framework
`6.4 Security Considerations
`6.5
`SOAP HTTP Examples
`7. References
`7.1 Normative References
`7.2
`Informative References
`Appendix A: SOAP Envelope Examples (Non-Normative)
`Al
`Sample Encoding of Call Requests
`A.2
`Sample Encoding of Response
`Appendix B: Acknowledgments (Non-Normative)
`Appendix C: Part 2 Change Log (Non-Normative)
`C.1
`SOAP Specification Changes
`C.2 XML Schema Changes
`
`324
`338
`338
`338
`339
`340
`340
`341
`341
`342
`342
`343
`343
`343
`343
`344
`345
`345
`346
`347
`349
`349
`354
`357
`Glossary
`
`
`Index
`
`378
`
`Zynga Ex. 1011, p. 14
`Zyngav. IGT
`IPR2022-00368
`
`Zynga Ex. 1011, p. 14
`Zynga v. IGT
`IPR2022-00368
`
`

`

`Zynga Ex. 1011, p. 15
`Zynga v. IGT
`IPR2022-00368
`
`
`
`This material may be protected by Copyright law (Title 17 U.S. Code)
`
`

`

`
`
`2 Chapter 1 * Understanding XML Messaging
`
`Tounderstand whypeoplearesoexcitedaboutXML-basedmessaging,youmustfirstcon-
`sider the general state of messaging mechanismsin the network-connected world of dis-
`tributed computing. After a reviewofvarious communication architectures, this chapter
`takes a look at the early history of messaging developmentsleading up to SOAP (Simple
`Object Access Protocol). Keepingtrack ofall ofthe different players in this gameis difficult,
`so [havetried to point out the mostsignificant initiatives,
`
`Messaging Architectures
`The majordistinctions you have to draw on when discussing the exchange of messages
`between communicating entities have to do with addressing and immediacy. With a point-to-
`point design, the creator ofa message addressesit to exactly one recipient. With a publish/
`subscribe design, the creator sends the message to a third-party server. Therecipients, who
`are subscribersto this particular kind ofmessage, copy it from the server. Thus,the recipi-
`ents in a publish/subscribe architecture are identified by their interest in a particular topic,
`notby their address. Figure 1.1 illustrates these different architectures.
`
`LG|
`is
`FIGURE 1.1:
`<——>|F|
`Point-to-point versus
`[mle
`
`publish/subscribe
`
`Al
`
`[F]
`
`[ce] [
`
`[p|
`
`Point-to-Point
`Publish/Subscribe
`Immediacy has to do with the time relationship between sender andrecipient,Ifthe sender
`waits for an immediate response,it is a synchronous relationship. For example, in TCP/IP,
`the base protocolof the Internet, every messageis acknowledged so that sender and recipient
`are synchronized.In a synchronousrelationship,if the sender is waiting for an acknowledge-
`ment and noneis sent, the communication hasfailed.
`In contrast, in an asynchronousrelationship, the sender transmits the message without
`expecting an immediate response. This provides much greater flexibility because the receiv-
`ing agent can pick up the message when processing poweris available. Furthermore, the sys-
`tem does notfail if the receiving agentis temporarily off the network. The drawbackis that
`now the entire system dependsonthe server.
`:
`
`Zynga Ex. 1011, p. 16
`Zyngav. IGT
`IPR2022-00368
`
`Zynga Ex. 1011, p. 16
`Zynga v. IGT
`IPR2022-00368
`
`

`

`
`
`Messaging Architectures 3
`
`The Mental Shift
`For many programmers, changing from an architecture in which you can expectan immedi-
`ate responseto calling a function to an asynchronous system requires a major mentalshift.
`This shift is comparable to that required on going fromastrictly procedural and single-
`threaded program to the event-oriented and multithreaded programs found on modern desk-
`top systems and webservers.
`Sometimes it just doesn’t seem rightthat a collection of processes exchanging asynchro-
`nous messages wheneverthey feellike it can be as fast and as powerfulas a system built
`around immediate responseto requests. The contrastis as strong as that between “free mar-
`ket” and “command”economies.
`
`However, you can expect to encounter this brand of computing more and moreas you
`work with distributed objects. Many softwarearchitects feel that this is the only way to build
`resilient and failsafe systems. For a mind-bending example, considerthe Jini and JavaSpaces
`technology fordistributed systems that Sun is promoting:
`http: //java.sun.com/products/javaspaces/
`
`The Spectrum of Complexity
`Messaging hasa spectrum of complexity ranging from simple messagepassing to creating
`and operating on remote objects. At the simple end ofthe spectrum,the treatmentof the
`message is defined by the protocol in use. For example, with e-mail, the Multipurpose Inter-
`net Mail Extensions (MIME)protocoldefines the treatment of the message content.
`At the complex endof the spectrum,the protocolsimply ensuresdelivery of the message.
`Thereceiving party mustinterpret the message contentin terms of objects, methods,
`resources, and sequenceof operations.It is at this complex end of the messaging spectrum
`that SOAP operates.
`
`The Pioneer: EDI
`Until relatively recently, the great bulk of electronic messages didn’t go throughthe Internet
`at all, but through private networks. In spite of the fact that the format for this Electronic
`Data Interchange (EDP) of messagesis highly industry-specific and notparticularly flexible,
`it is still the primary means of business-to-business (B2B) data exchange. Beforetherise of
`the Internet, communication took place on expensive leased lines or private networks. Now
`it is much cheaperto create a virtual private network (VPN) by sending encrypted data over
`the Internet, but the underlying messagesstill use EDI coding.
`There are many industries that have an extensive investment in EDIand aregoingto be
`slow to change to Internet-based web services. Examples include hospitals, banks, and insur-
`ance companies. However, the advantages to be gained in terms ofgreaterflexibility and
`
`Zynga Ex. 1011, p. 17
`Zyngav. IGT
`IPR2022-00368
`
`Zynga Ex. 1011, p. 17
`Zynga v. IGT
`IPR2022-00368
`
`

`

`Chapter 1 ¢ Understanding XML Messaging
`
`
`lower communication costs appear to makeit inevitable that even these industries will have
`to replace existing EDIapplications.
`
`Messaging Systemsas Applications
`Recentyears have seentherise ofmajor applications for the enterprise that can be called
`Message-Oriented Middleware (MOM)applications. The Lotus company was oneofthe
`first to recognize that unifying the data communications for an enterprise could yield signifi-
`cant benefits and command a premiumprice. The success of the Lotus Notes application
`verified that corporationsrealized the benefits that could stem from this unification.
`As the communication channels used by enterprises have expandedto include e-mail, web-
`sites, fax, voice mail, the short message service on cellular phones, personal digital assistants,
`and the wireless Internet, the scope of messaging systems has expanded to keep up. Lotus
`nowtalks in terms of “Unified Messaging” to encompassall of these channels.
`The wayin which the informationresources of an organization are viewed has shifted from
`emphasis on the giant mainframe database to emphasis on information flowwithin the orga-
`nization, with customers, with suppliers, and with the public.It is widely anticipated that the
`value of B2B transactions ontheInternetwill continue to exceed the value of consumer
`transactions.
`
`Java Message Service
`Just as JDBC (Java Database Connectivity) has becomethe standard interface for communi-
`cation between Java programs and SQL databases, Sun hopes to make Java Message Service
`(JMS) the standard interface betweenJava programms and commercial messaging systems.
`The JMS packageprovides abstractions for message creation and delivery systems and
`encoding for simple data types.
`Although JMS defines several types of message, an XML type is not currently one of these
`types; therefore, vendors ofJMS-compliant messaging systemshave to provide XMLas a
`proprietary type. In view ofthe rapidrise in importance of SOAP it seemsa safe bet that an
`XMLtypewill be in the JMS package soon.
`
`Directory Systems
`An essential part ofmessaging systemsare directories that let a potential client program
`locate the correct way to address a service. Getting these directory services right is not a
`trivial task.
`The Java Naming and Directory Interface is a standard Java language extension that pro-
`vides a standardinterface for addressing a variety of different directory and naming systems,
`such as Novell NetWare NDS, CORBA NamingService, and JMSservices.
`Zynga Ex. 1011, p. 18
`Zyngav. IGT
`IPR2022-00368
`
`Zynga Ex. 1011, p. 18
`Zynga v. IGT
`IPR2022-00368
`
`

`

`
`
`Communicating Objects 5
`
`As the numberof web services increases rapidly, just finding the kind ofservice you need
`requires more and moreeffort. A numberofinitiatives to create these super directory ser-
`vices have been undertaken. For example, IBM, Microsoft, and Sun are involved with estab-
`lishing the Universal Description, Discovery, and Integration (UDDIstandard.
`‘Theobjective of UDDI(see ww.uddi .org) is to create a sort ofweb-based,universal,
`Yellow Pages-type directory for companies, which publishes the existence ofweb services in a
`single registry in order to promote business networking. UDDI represents oneofthe earliest
`uses of SOAP protocols.
`Once you havelocateda service, you have to determine how that service wants to see
`requests formatted and howitwill return results. It appears that the standard for accomplish-
`ing this will be Web Services Description Language (W:SDL). Using XML formatting, a
`WSDLdocumentprovidesall of the information needed to send a message to a SOAP-
`based web service andinterpretthereply.
`
`Communicating Objects
`The most important of the non-XML based schemesfor message passing and remote proce-
`dure calls are CORBA and DCOM.Before lookingat these schemes, let me define some
`important terms:
`Interface Definition Language (IDL) The languageusedto specify the interface an
`object uses to communicate with the outside world.
`Marshalling Theprocess ofturningthe structureofa program object into a stream of
`bytesis called marshalling.
`Serializing Another term for marshalling.
`Unmarshalling The process of turning a stream ofbytes back into the original object
`structure.
`
`Deserializing Another term for unmarshalling.
`Encoding Turningdata items into a form that can be transmitted by a particular proto-
`col. For example, to include the binary data that makes up an image in an XML message,
`the bytes must be encodedas characters compatible with XML tags.
`
`Another Pioneer: CORBA
`A pioneeringeffort to get reliable communicationofobjects between disparate systems was the
`Common Object Request Broker Architecture (CORBA). The Object Management Group
`(OMG;see www. omg. org) wasset up to create a protocol capable ofproviding communication
`
`Zynga Ex. 1011, p. 19
`Zynga v. IGT
`IPR2022-00368
`
`Zynga Ex. 1011, p. 19
`Zynga v. IGT
`IPR2022-00368
`
`

`

`Chapter 1 * Understanding XML Messaging
`
`between objects on completely different operating systems and writtenin different languages.
`An Object Request Broker (ORB) provides the interface neededfora client program to talk to
`a remote object.
`Because the initial CORBAspecification was released in 1992, it has had quite a long time
`for refinement comparedto other technologies. Many software vendors produce CORBA-
`compliant products. In spite of—or perhaps because of—its maturity, CORBAis considered
`a difficult programming technology to master.
`The OMGcreated a standard Interface Definition Language (IDL) that permits definition
`of an object’s interface in a language-independentfashion. OMGalso created a protocol—
`Internet Inter-ORB Protocol (IOP)—for message communication overthe Internet. The
`OMGis currently working on creating a SOAP-CORBAinterface standard.
`
`The Component Object Model
`The Component Object Model (COM)is a Microsoft specification for integrating compo-
`nents within an application. This communicationis low-level but can allow components
`written in different languagesto interact. Distributed COM (DCOM)is a more recent
`developmentthat allows componentsto interact over a network. The form ofinteractionis
`essentially a remote procedurecall similar to Remote Method Invocation (RMI) in Java.
`COM and DCOMare considered mature technologies because COM has been aroundsince
`1995. The specifications for COM and DCOMhavebeenturned over to the Open Group
`for standardization efforts. Although Microsoft Windowssystems are the primary users of
`DCOM,thereis no reason it could notbe extended to use on other operating systems.
`
`Remote Method Invocation
`Thesimplest approach in Java to communication between objects in distributed systemsis
`provided by the RMIclasses. Addedto the standard Java library in JDK 1.1, and subse-
`quently enhanced, RMIis the core technology for Java object to Java object communication.
`The RMIclasses allow programmersto treat a remoteobjectasif it resides within the local
`application. All a programmerhasto dois determinethe public interface to be exposed by the
`remoteobject. The rmic utility program examines the interface and createsclasses called the
`stub and skeleton classes.
`Theresulting architecture is shown in Figure 1.2. On theserverside, the server application
`registers the interface with the rmi registry and waits for a connection.A client application
`uses the rmiregistry, thatlives on the network at a standardport, to obtain an instance of the
`stub class that implementsthe desired interface. Calls made to the stub class instance behave
`as if the remote objectis in the local JVM address space.
`
`Zynga Ex. 1011, p. 20
`Zyngav. IGT
`IPR2022-00368
`
`Zynga Ex. 1011, p. 20
`Zynga v. IGT
`IPR2022-00368
`
`

`

`88
`
`Chapter 6 * Creating a SOAP Server Application
`
`his chapter examines whatis required to create a SOAP serverapplication based on the
`requirementsof the SOAPspecifications. The Apache SOAP architecture for both
`remote procedure calls and messaging is examinedtoillustrate the principles. In conclusion,
`this chapter details the required steps for creating a modestserver application.
`
`SOAP Server Architecture
`
`It is unfortunate that most discussions of SOAP concentrate on remote procedurecall (RPC)
`applications using HTTP. This tends to obscure that the basic componentof SOAP is a
`single XML message thatcan be transported bya variety of mechanisms and mayor may
`not require a return message. Thereis also a tendency to concentrate on examples in which
`a client talks directly to a server. As discussed in Chapter 2, “A Survey of SOAP,”the proto-
`col provides for a SOAP message passing through any numberofintermediary handlers.
`Let’s consider someofthe usage scenariosor use cases from the W3C working group on
`XML Protocols (XP) requirements document. The current version of this document can be
`found at:
`
`http: //www.w3.org/TR/xmlp-reqs/
`
`‘These usage scenarios are intended to provide examples of situations in which XML mes-
`saging might be applicable.
`In this case, the sender creates a SOAP message and
`Fire-and-forget to single receiver
`sendsit to a receiver but does not expect anyformofresponse. For example, a remote
`weather station reporting readings every hour.
`
`In this case, the SOAP messageis sentbya sys-
`Fire-and-forget to multiple receivers
`temthat repeats or duplicates the message to multiple receivers, also knownas
`“publish/subscribe” messaging. For example, stock price updates to multiple websites.
`
`Request-response_In general, a request that expects a response of somesort. For
`example, a purchase order request to which the response might be an order confirmation
`or simplyabid.
`
`Remoteprocedure call A more specific case of request-responsein which the request
`supplies parameters to a known methodand expects a response fromthat method. An
`example wouldbe a requestfor a stock quote.
`
`Request with acknowledgment Message deliverythat reports whetherdelivery was
`accomplished without error. High value messages such as an ordertobuyorsell a stock
`wouldfall in this category.
`
`Zynga Ex. 1011, p. 21
`Zyngav. IGT
`IPR2022-00368
`
`Zynga Ex. 1011, p. 21
`Zynga v. IGT
`IPR2022-00368
`
`

`

`CHAPTER 8
`
`
`SOAP Architecture
`Using Messages
`
`
`
`e Point-to-Point vs. Publish-Subscribe messaging
`
`e The principles ofJava Message Service
`
`e Working SOAP examples with Java Message Service
`
`e The JavaSpaces architecture
`
`© The advantages ofJavaSpaces over Java Message Service
`
`e GettingJavaSpaces running on your system
`
`4 fi
`
`4
`
`e Working SOAP examples with JavaSpaces
`
`Zynga Ex. 1011, p. 22
`Zynga v. IGT
`IPR2022-00368
`
`

`

`Chapter 8 * SOAP Architecture Using Messages
`126
`
`t is importantto stress that SOAP is quiteflexible with transport mechanisms, which is what
`makesit such an attractive technology. Having covered the HITP-basedarchitecture in the
`previous chapters, this chapter reviews two message transport mechanisms, Java Messaging
`and JavaSpaces, with extensive example codefor each.
`
`Messaging Systems in General
`Messaging systems cameinto being with thefirst networks, andavariety of messages are
`exchanged over computer networks. Naturally, one thinks first of the ubiquitous e-mail;
`however, manyothertypesof valuable data are moved over networks, making messaging
`systemsvery importantin enterprise-level computing, even without e-mail.
`There has been a recent trend to recognize messaging systemsas a separateclass of appli-
`cation, frequently called Message-Oriented Middleware (MOM). A MOMsystem takes
`responsibility for transmitting application messages overa network and provides support for
`load balancing,fault tolerance, and transactions.Basically, there are two models for messag-
`ing: point-to-point and publish/subscribe.
`
`The Point-to-Point Model
`In this model, a messageis transmitted from a senderto a single recipient. As shown in
`Figure 8.1, once the sender,client A, dispatches a message to a local router, the message c