Proceedings of the
`Fourteenth ACM Symposium
`
`on
`
`Operating Systems Principles
`
`December 5-8, 1993
`The Grove Park Inn and Country Club
`Asheville, NC
`
`
`
`Sponsored by
`Association for Computing Machinery (ACM)
`Special Interest Group on Operating Systems (SIGOPS)
`
`Zynga Ex. 1016, p. 1
`Zynga v. IGT
`IPR2022-00368
`
`Zynga Ex. 1016, p. 1
`Zynga v. IGT
`IPR2022-00368
`
`

`

`The Association for Computing Machinery
`1515 Broadway
`New York, N.Y. 10036
`
`Copyright © 1993 by the Association for Computing Machinery, Inc. Copying without fee
`is permitted provided that the copies are not madeordistributed for direct commercial
`advantage,andcredit to the source is given. Abstracting with credit is permitted. For other
`copying ofarticles that carry a codeat the bottom ofthefirst page, copying is permitted
`provided that the per-copy fee indicated in the codeis paid through the Copyright Clearance
`Center, 222 Rosewood Drive, Danvers, MA 01923. For permission to republish write to:
`Director of Publications, Association for Computing Machinery. To copy otherwise or
`republish, requires a fee and/or specific permission.
`
`Additional copies may be ordered prepaid from:
`
`ACM ISBN:0-89791-632-8
`
`ACM Order Department
`P.O. Box 12114
`Church Street Station
`New York, N.Y. 10257
`
`Phone: 1-800-342-6626
`(U.S.A. and Canada)
`1-212-626-0500
`(All other countries)
`Fax: 1-212-944-1318
`E-mail: acmpubs@acm. org
`
`ACM Order Number: 534930
`
`Printed in the U.S.A.
`
`Zynga Ex. 1016, p. 2
`Zynga v. IGT
`IPR2022-00368
`
`Zynga Ex. 1016, p. 2
`Zynga v. IGT
`IPR2022-00368
`
`

`

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

`

`software out in the field. This body of software consists of
`several tools and modules that use a novel communications
`infrastructure known as the Information Bus. Allof the soft-
`ware components work together to provide a complete dis-
`tributed system environment.
`
`This paperis organized as follows. Section 2 providesa
`detailed description of the problem domain and summarizes
`the requirements for a solution. Section 3 outlines the Infor-
`mation Bus architecture in detail, states principles that
`drove our design, and discusses some aspects of the imple-
`mentation. Section 4 describes the notion of adapters, which
`mediate between old applications and in the Information
`Bus. Section 5 describes other software components that
`use the Information Bus and provide a complete application
`environment. This section also provides an exampletoillus-
`trate the system. Section 6 presents related work. Section 7
`summarizes the paper and discusses open issues. The
`Appendix discusses the performance characteristics of the
`Information Bus.
`
`2 Background
`An ICfabrication plant represents a hugecapital invest-
`ment. This investment, therefore, is cost-effective only if it
`can remain operational twenty-four hours a day. To bring
`down an entire plant in order to upgrade a key software
`component, such asthe ““Work-In-Process”tracking system,
`would result in lost revenue and wasted material. There is
`no opportunity to “reboot”the entire system. We state this
`requirementas R1:
`
`Rl Continuous operation. It is unacceptableto bring
`down the system for upgrades or maintenance.
`
`Despite the need for continuous operation, frequent
`changes in hardware and software must also be supported.
`New applications and new versions of existing applications
`need to be brought on-line. Business requirements and fac-
`tory models change, and such changes need tobe reflected
`in the application behavior. For example, new equipment
`types could be introduced into the factory. We state this
`requirement as R2:
`
`R2 Dynamic system evolution. The system must be
`capable of adapting to changesin application ar-
`chitecture and in the type of information ex-
`changed. It should also support
`the dynamic
`integration of new services and information.
`
`In the systems that we have built and installed, this
`requirementhas posed the greatest challenge. The sheer size
`of these systems, typically ranging from one hundred to a
`thousand workstations, makes changes expensive or even
`impossible, unless change is planned from the beginning.
`
`Businesses often have huge outlays in existing hard-
`ware, software, and data. To be accepted by the business
`
`community, a new system must be capable of leveraging
`existing technology; an organization will not throw away
`the product of an earlier costly investment. We state this
`requirementas R3:
`
`R3_ Legacy systems. New software must be able to
`interact smoothly with existing software, regard-
`less of the age of that software.
`
`Other important requirements are fault-tolerance, scal-
`ability, and performance. The system mustbe fault-tolerant;
`in particular it must not have a single point of failure. The
`system must scale in terms of both hardware and data.
`Finally, our installations must meet stringent performance
`standards. In this paper, we focus on requirements R1, R2,
`and R3 because they represent“real-world” constraints that
`have beenless studiedin research settings.
`
`The typical customer environmentconsists of a distrib-
`uted collection of independent processors, nodes, that com-
`municate with each other by passing messages over the
`network. Nodes and the network mayfail, and it is assumed
`that these failures are fail-stop [Schneider83] and not Byz-
`antine [Lamport82].! The network may lose, delay, and
`duplicate messages, or deliver messages out of order. Link
`failures may cause the network to partition into subnet-
`works that are unable to communicate with each other. We
`assumethat nodes eventually recover from crashes. For any
`pair of nodes, there will eventually be a time when they can
`communicate directly with each other after each crash.
`
`3 Information Bus Architecture
`
`The requirements of a "24 by 7" environmentdictated
`numerous design decisions that ultimately resulted in the
`Information Bus that we have today. We havedistilled those
`decisions into several design principles, which are high-
`lighted as they becomeapparentin this section.
`
`Because it is impossible to anticipate or dictate the
`semantics of future applications, it is inadvisable to hard-
`code application semantics into the core communications
`software—for performance reasons and because there is no
`“right” answer for every application [Cheriton93]. For
`example, complex ordering semantics on message delivery
`are not supported directly. Atomic transactions are also not
`supported: in our experience most applications do not need
`the strong consistency requirements of transactions. Instead,
`we provide tools and higher-level services to cover the
`range of requirements. This allows us to keep the communi-
`cations software efficient, while still allowing us to adapt to
`the specific needs of each class of customers. The following
`principle is motivated by requirements R2 and R3.
`
`
`1. Failures in our customer environments closely approximate
`fail-stop behavior; furthermore, protecting against the rare Byzan-
`tine failure is generally too costly.
`
`59
`
`Zynga Ex. 1016, p. 4
`Zyngav. IGT
`IPR2022-00368
`
`Zynga Ex. 1016, p. 4
`Zynga v. IGT
`IPR2022-00368
`
`

`

`FIGURE 1. Model of computation
`
`Service object
`
`Service object
`
`
`
` subscribe—_request
`
`local data
`
`
`Client appl.
`
`Client appl.
`
`Pl Minimal core semantics. The core communica-
`tion system and tools can make few assumptions
`about the semantics of application programs.
`
`Our model of computation consists of objects, both
`data objects and service objects, and two styles of distrib-
`uted communication:
`traditional
`request/reply
`(using
`remote procedure call [Birrell84]) and publish/subscribe,
`the hallmark of the Information Bus architecture. This is
`depicted in Figure 1. Publish/subscribe supports an event-
`driven communication style and permits data to be dissemi-
`nated on the bus, whereas request/reply supports a demand-
`driven communication style reminiscent of client/server
`architectures. For each communication style, there are dif-
`ferent levels of quality of service, which reflect different
`design trade-offs between performance andfault-tolerance.
`The next section elaborates on these mechanisms.
`
`An objectis an instance ofa class, and eachclassis an
`implementation of a type”. Our system modeldistinguishes
`between twodifferent kinds of objects: service objects that
`control access to system resources and data objects that
`contain information and that can easily be transmitted. A
`service object encapsulates and controls access
`to
`resources such as databases or devices and its local data
`objects. Service objects typically contain extensive state
`and maybe fault-tolerant. Because they tend to be large-
`grained, they are not easily marshalled into a wire format
`and transmitted. Instead of migrating to another node, they
`are invoked where they reside, using a form of remote pro-
`cedure call. Examples of service objects include network
`
`
`
`2. A type is an abstraction whose behavioris defined byan inter-
`face that is completely specified by a set of operations. Types are
`organized into a supertype/subtype hierarchy. A class is an imple-
`mentation of a type. Specifically, a class defines methods that
`implementthe operations defined in a type’s interface.
`
`file systems, database systems, print services, and nameser-
`vices.
`
`A data object, on the other hand, can be easily copied,
`marshalled, and transmitted. Such objects are at the granular-
`ity of typical C++ objects or database records. They abstract
`and encapsulate application-level concepts such as docu-
`ments, bank accounts, CAD designs, and employee records.
`They run the gamutfrom abstracting simple data records to
`defining complex behaviors, such as “recipes” for control-
`ling IC processing equipment.
`
`Each data objectis labelled with a swbject string. Sub-
`jects are hierarchically structured, as illustrated by the fol-
`lowing well-formed subject “fab5S.cc.litho8.thick.” This
`subject might translate to plant “‘fabS,” cell controller, lithog-
`raphystation “litho8,” and wafer thickness. Subjects are cho-
`sen by applications or users.
`
`The secondprinciple, P2, is motivated by requirements
`R2 and R3, and together with data abstraction, allows appli-
`cations to adapt automatically to changes in an object’s
`implementation and data representation.
`
`P2 Self-describing objects. Objects, both service and
`data objects, are “self-describing.” Each supports
`a meta-object protocol
`[Kiczales91], allowing
`queries aboutits type, attribute names,attribute
`types, and operation signatures.
`
`P2 enables our systems and applications to support
`introspective access
`to their
`services, operations,
`and
`attributes. In traditional environments, introspection is used
`to develop program analysis tools, such as class browsers
`and debuggers. In the Information Bus environment,intro-
`spection is used by applications to adapt their behaviors to
`change. This is key to building systems that can adapt to
`changeat run-time.
`
`60
`
`Zynga Ex. 1016, p. 5
`Zynga v. IGT
`IPR2022-00368
`
`Zynga Ex. 1016, p. 5
`Zynga v. IGT
`IPR2022-00368
`
`

`

`Introspection enables programmers to write generic
`software that can operate on a wide range of types. For
`example, consider a “print” utility. Our implementation of
`this utility can accept any object of any type and produce a
`text description of the object. It examines the object to
`determine its type, and then generates appropriate output. In
`the case of a complex object, the utility will recursively
`descend into the components of the object. Theprintutility
`only needs to understand the fundamental types, such as
`integer orstring, but it can print an object of any type com-
`posed of those types.
`
`The third principle, P3, enables new concepts and
`abstractions to be introduced into the system.
`
`P3 Dynamic classing. New classes implementing
`either existing or new types can be dynamically
`defined and usedto create instances. This is sup-
`ported for both service and data objects.
`
`P3 enables new types to be defined, on-the-fly. Note
`that P2 enables existing applications to make use of these
`new types without re-programmingorre-linking.
`
`To support dynamic classing, we have implemented
`TDL, a small,
`interpreted language based on CLOS
`[Keene89]. We have chosen a subset of CLOSthat supports
`a full object model, but that could be supported in a small,
`efficient run-time environment.
`
`3.1 Publish/Subscribe Communication
`
`To disseminate data objects, data producers generate
`them, label them with an appropriate subject, and publish
`them on the Information Bus. To receive such objects, data
`consumers swbscribe to the same subject. Consumers need
`not know whoproducesthe objects, and producers need not
`know whoconsumesor processes the objects. This property
`is expressed in principle P4. We call this model’ Subject-
`Based Addressing™,andit is a variant of a generative
`communication model [Carriero89]. This principle is moti-
`vated by requirements R1 and R2,andit allows applications
`to tolerate architectural changesonthefly.
`P4 Anonymous communication. Data objects are
`sent and received based on a subject, indepen-
`dent of the identities and location of data pro-
`ducers and data consumers.
`
`Subjects can be partially specified or “wildcarded” by
`the consumer, which permits accessto a large collection of
`data from multiple producers with a single request. The
`Information Busitself enforces no policy on the interpreta-
`tion of subjects. Instead, the system designers and develop-
`ers have the freedom and responsibility to establish
`conventions on the use of subjects.
`
`Anonymous communication is a powerful mechanism
`for adapting to software changes that occur at run-time. A
`
`new subscriber can be introduced at any time and will start
`receiving immediately new objects that are being published
`under the subjects to which it has subscribed. Similarly, a
`new publisher can be introduced into the system, and exist-
`ing subscribers will receive objects from it. Our model of
`computation does not require a traditional nameservicelike
`Sun’s NIS or Xerox’s Clearinghouse [Oppen83].
`
`In a traditional distributed system, whenever newser-
`vices are added to the system, or a service is being replaced
`with a new implementation,
`the name service must be
`updated with the new information. To use that information,
`all applications must be aware that the new services exist,
`must contact the nameservice to obtain the location of the
`new service, and then bindto the service. In our model, the
`new implementation need only use the same subjects as the
`old implementation; neither publishers nor subscribers must
`be aware of the change. Subject names can be reboundat
`any time to a new address, a facility that is more general
`than traditional late-binding.
`
`The semantics of publish/subscribe communication
`depends on the requirements of the application. The usual
`semantics we provide is reliable message delivery. Under
`normaloperation, if a sender and receiver do not crash and
`the network does not suffer a long-term partition, then mes-
`sages are delivered exactly once in the order sent by the
`same sender; messages from different senders are not
`ordered. If the sender or receiver crashes, or there is a net-
`work partition,
`then messages will be delivered at most
`once.
`
`A stronger semantics is guaranteed messagedelivery.
`In this case, the message is logged to non-volatile storage
`before it is sent. The message is guaranteed to be delivered
`at least once, regardless of failures. The publisher will
`retransmit the message at appropriate times until a reply is
`received. If there is no failure, then the message will be
`delivered exactly once. Guaranteed delivery is particularly
`useful when sending data to a database over an unreliable
`network.
`
`For local area networks, reliable publication is imple-
`mented with Ethemet broadcast. This choice allows the
`same data to be delivered to a large numberofdestinations
`without a performance penalty. Moreover, Ethernet broad-
`cast eliminates the need for a central communicationserver.
`Our current implementation uses UDPpackets in combina-
`tion with a retransmission protocol to implementreliable
`delivery semantics.
`
`In our implementation of subject-based addressing, we
`use a daemononevery host. Each application registers with
`its local daemon,and tells the daemon to which subjects it
`has subscribed. The daemon forwards each message to each
`application that has subscribed.It uses the subject contained
`in the message to decide which application receives which
`message.
`
`61
`
`Zynga Ex. 1016, p. 6
`Zynga v. IGT
`IPR2022-00368
`
`Zynga Ex. 1016, p. 6
`Zynga v. IGT
`IPR2022-00368
`
`

`

`Given the high traffic rates, Ethernet broadcast across
`wide area networks is undesirable. We could use IP multi-
`cast [Cheriton85], but unfortunately, commercial implemen-
`tations are not mature enough for mission-critical use.
`Therefore, wide area networks require additional communi-
`cation tools.
`
`Our implementation uses application-level “informa-
`tion routers” to solve the problem posed by wide area net-
`works. To the Information Bus,
`these routers look like
`ordinary applications, but they actually integrate multiple
`instances of the bus. Messages are received by one router
`using a subscription, transmitted to another router, and then
`re-published on another bus. Therouter is intelligent about
`which messages are sent to which routers: messages are
`only re-published on buses for which there exists a sub-
`scription on that subject; the router can also perform other
`functions, such as transforming subjects or logging mes-
`sages to non-volatile storage. Thus, the overall effect is to
`create the illusion of a single, large bus that is capable of
`publishing over any network.
`
`3.2 Dynamic Discovery
`
`In a distributed system, it is often necessary for an
`application to discover the identify of the participants in a
`protocol. For example, a new client needs to determine the
`set of servers that serve a subject; a new server needs to
`determine if any clients have pending requests; a replicated
`server needs to find the other servers that maintain the repli-
`cated data. Specifically, in Xerox’s corporate email service,
`a traditional distributed system, client mail applications find
`a mail service for posting mail messages by using an
`expanding ring broadcast technique, a kind of discovery
`protocol [Xerox88].
`
`In the Information Bus, the discovery protocolis in the
`form of two publications. One participant publishes “Who’s
`out there?” under a subject. The other participants publish “I
`am” and other information describing their state, if they
`serve the subject in question. Section 3.3 provides a specific
`example of this exchange. This approach preserves P4
`(anonymous communication). The subject alone is enough
`for one participant to make contact with its cohorts.
`
`The publish/subscribe communication model is well-
`suited to supporting a discovery protocol. Since publication
`does not require any boot-strapping or nameresolution,it
`can be the first step in a protocol. We are effectively using
`the networkitself as a name service. A subject is mapped to
`a specific set of servers by allowing the servers to choose
`themselves. The ““Who’s out there?” publication can contain
`service-specific information, so further refinements are pos-
`sible when selecting servers.
`
`3.3 Remote Method Invocation
`
`Remote method invocation (RMI), or remote procedure
`call, is the second means of performing distributed compu-
`tations. This paired request/reply satisfies the demand-
`driven style of interaction. Clients invoke a method on a
`remote server object without regard to that server object’s
`location, the server object executes the method, and the
`serverreplies to the client. Servers are named with subjects.
`
`Standard RMI provide exactly-once semantics under
`normal operation and at-most-once semantics in the pres-
`ence of failures. Customer-specific requirements such as
`exactly-once semantics, which guarantees that the method
`will be executed exactly once, even in the presence offail-
`ures, can be built on the a layer above standard RMI.
`
`There are two parts to RMI: discovering the server
`object for a client, and establishing a connection to that
`server over which requests and replies will flow. The dis-
`covery algorithm in our implementation employs publish/
`subscribe communication as described in Section 3.2. In
`this algorithm, the client searches for all servers by publish-
`ing a query message on a subject specific to that service.
`The servers receive this message, and then they publish
`their point-to-point address to all clients on the same sub-
`ject. Finally, the client invokes a service request on a server
`object using the point-to-point address. The point-to-point
`address can refer to any simple, connection mechanism,
`such as a TCP/IP connection [Postel81]. Figure 2 illustrates
`this protocol.
`
`FIGURE 2. RMI Protocol
`
`Client
`
`Server
`
`publish
`
`oint-to-point request
`
` ss
`
`More than one server can respond to requests on a sub-
`ject. Several server objects can be used to provide load bal-
`ancing orfault-tolerance. Our system allows an application
`to choose between several different policies. The servers
`can decide among themselves which one will respond to a
`request from the client. Alternatively, the client can receive
`every response from all of the servers and then decide
`whichserver the client wants to use.
`
`4 Adapters
`
`The Information Bus must allow for interaction with
`existing systems, as dictated by requirement R3. To inte-
`grate existing applications into the Information Bus we use
`
`62
`
`Zynga Ex. 1016, p. 7
`Zynga v. IGT
`IPR2022-00368
`
`Zynga Ex. 1016, p. 7
`Zynga v. IGT
`IPR2022-00368
`
`

`

`software modules called adapters. These adapters convert
`information from the data objects of the Information Bus
`into data understood by the applications, and vice versa.
`Adapters mustlive in two worlds at once,translating com-
`munication mechanisms and data schemas. Adapters often
`require P1 in order to be feasible.
`Adapters are essential for integrating the Information
`Bus into a commercial environment. In the factory floor
`example, our customer already had a Work In Progress
`(WIP) system with its own data schemas. We designed an
`adapterthat allowsthe existing WIP software to communi-
`cate with the Information Bus. This achievement demon-
`strates the flexibility of the Information Bus model:
`the
`existing WIP system is written in Cobol, and there is only a
`primitive terminalinterface. The adapter mustact as a vir-
`tual user to the terminal interface.
`
`The Object Repository is an exampleof a sophisticated
`adapter that integrates a commercially available relational
`database system into the Information Busarchitecture. The
`Object Repository maps Information Bus objects into data
`base relations for storage or retrieval. This mapping is
`driven by the meta-data of each object. Besides satisfying
`requirement R3 as an adapter, the design of the repository
`also supports dynamic system evolution, which satisfies
`requirement R2. Users may work freely in the object model
`without concerning themselves with the relational data
`model? [Codd70]. Using P2, the repository can automati-
`cally adaptthe relational model to the type structure of the
`data objects.
`
`The repository behaves as a kind of schema converter
`from objects to database tables, and vice versa. Users are
`thus insulated from any changes implementors may wish to
`make to the database representation of objects. For exam-
`ple, our conversion algorithm decomposes a complex object
`into one or more database tables and reconstructs a complex
`object from one or more database tables to answer a query
`from a user. This conversion respects the type hierarchy,
`enabling queries to return all objects that satisfy a con-
`straint, including objects that are instancesof a subtype. Old
`queries will still work even as new subtypesare introduced,
`which helpsto satisfy R2. This operation can be fully auto-
`mated; only the type information is necessary to do the
`transformation. When the repository needs to store an
`instance of a previously unknowntype,it is capable of gen-
`erating one or more new database tables to represent the
`new type.
`
`
`
`3. Our object modeldiffers significantly from the relational data
`model in the following way. A database table is a flat structure
`composed of simple data types and has little semantics, while an
`object may contain other objects, may have subtypes or super-
`types, and may have methods to manipulate instances ofthe type.
`
`The repository may be configured in any number of
`ways, dependingonthe application. For example, it may be
`configured as a capture server that captures all objects for a
`given set of subjects and inserts those objects automatically
`into the repository underthose subjects; it may also be con-
`figured as a query server to receive requests from clients
`andreturn replies.
`
`5 Example Application
`In the previous section, we discussed the Information
`Bus architecture primarily in terms of an abstract object
`model and two communication styles, and we espoused sev-
`eral principles of system design. To make the architecture
`more concrete, we present an example that shows how the
`various components fit together into a single application and
`that illustrates how an application can adapt to changes in
`the environment.In particular, we show howtheprinciples
`are applied in the context of the example, and discuss some
`software components that have been built on top of the
`Information Busandthatare installed at customersites.
`
`Figure 3 shows an example taken from a financial trad-
`ing floor, where traders must receive newsstories in near
`real-time. Two news adapters receive news stories from
`communication feeds connected to outside news services,
`such as Dow Jones and Reuters. Each raw newsservice
`defines its own news format. Each adapter parses the
`received data into an appropriate vendor-specific subtype of
`a commonStory supertype, and publishes each story on the
`Information Bus under a subject describing the story’s pri-
`mary topic (for example,“news.equity.gmc” for stories on
`General Motors). P1 ensuresthat the raw feeds do not have
`to support complex semantics.
`
`The figure depicts two applications that consume the
`Story objects: the Object Repository and the News Monitor.
`The News Monitor subscribes to and displays all stories of
`interest to its user. Incomingstories are first displayed in a
`“headline summary list.” This list format is defined by a
`“view”that specifies a set of named attributes? from incom-
`ing objects and formatting information. When the user
`selects a story in the summary list, the entire story is dis-
`played. This is accomplished by using the object’s meta-
`data to iterate through all ofits attributes and display them,
`as provided by P2.
`The Object Repository subscribes to all newsstories
`and inserts theminto a relational database. The repository
`converts Story objects into a database table format. This
`conversion is nontrivial because a story is a highly struc-
`tured object containing other objects suchaslists of “indus-
`try groups,” “sources,” and “country codes.” Every object
`
`4. “Attributes” of an object are often referred to as “instance vari-
`ables”or “fields.”
`
`63
`
`Zynga Ex. 1016, p. 8
`Zyngav. IGT
`IPR2022-00368
`
`Zynga Ex. 1016, p. 8
`Zynga v. IGT
`IPR2022-00368
`
`

`

`FIGURE 3. Brokerage Trading Floor
`
`Dow Jones
`
`Reuters
`
`NewsMonitor
`
`
`
`
`
`Information Bus
`
`
`
`
`
`Repository
`
`must be mapped into collections of simple database rela-
`tions.
`
`5.1 Graphical Application Builder
`
`mation Bus (P3). The Object Repository can dynamically
`generate extensions to the database schema to accommo-
`date such new types. Such generation may entail creating
`one or more new database tables for each new type,
`depending on the particular database representation. When
`We needed a simple, general way to access information
`instances of the new type are received, they are dynami-
`on the Information Bus and in the databasein a pleasing,
`cally converted to the new database schema. P2 implies that
`graphical form. It was notsatisfactory to buildasingle,
`the repository will be able to recognize and process objects
`Static solution, since each customerhasdifferent needs, and
`that have a new type.
`they change frequently. Instead, webuilt a graphical appli-
`cation builder, designed for applications with a graphical
`user interface builder. We have used it for several applica-
`tions, including the News Monitor example and the front-
`end to a Factory Configuration System, which is the system
`for storing factory control information.
`
`The application builder is an interpreter-driven, user
`interface toolkit. It combines the ability to construct sophis-
`ticated user interfaces with a simple, object-oriented lan-
`guage. All high-level application behavioris encodedin the
`interpreted language; only low-level behaviorthat is com-
`mon to manyapplications is actually compiled.
`The resulting applications are fully integrated into the
`Information Bus, providing access to all subjects and ser-
`vices.It is possible to examinethelist of available services
`on the Information Bus by using various nameservices.
`Services are self-describing, so users can inspect the inter-
`face description for each service. Using that information, a
`user can quickly constructa basic user interface for any ser-
`vice. This whole process requires only a few minutes, and
`typically no compilation is involved. Sometimes, a single
`user interface can be used to access several services, further
`reducing the amount of work involved.
`
`5.2 Dynamic System Evolution
`
`In this section weillustrate how our design principles
`support the requirementof dynamic system evolution.First,
`we consider the introduction of a new type into the Infor-
`
`Second, we consider what happens if a newservice of a
`completely different nature is introduced. Consider a Key-
`word Generator, as illustrated in Figure 4. The Keyword
`Generator subscribes to stories on major subjects and
`searches the text of each story for “keywords” that have
`been designated under several major“categories.” For each
`Story object, a list of keywords is constructed as a named
`Property? object of the Story object and published underthe
`same subject. It also supports an interactive interface that
`allows clients to browse categories and associated key-
`words.
`
`When the Keyword Generator comes on-line, the News
`Monitor will start receiving Property objects on the same
`subjects on whichit is receiving Story objects. According to
`P4, the News Monitor will be able to receive the new data
`immediately. Since properties are a general conceptin the
`architecture, it can reasonably be assumed the News Moni-
`tor is configured to accept Property objects, to associate
`them with the objects they reference, and to display them
`along with the attributes of an object when the object is
`selected. This capability can be set up using the scripting
`language of the Graphical Application Builder,
`
`
`5. The Object Management Group’s “Object Services Architec-
`ture” is the basis for the nomenclature used here. Accordingly, a
`“property” is a name-value pair that can be dynamically defined
`and associated with an object. In this example, the property name
`is “keywords” and the valueis the set of keywords found.
`
`64
`
`Zynga Ex. 1016, p. 9
`Zynga v. IGT
`IPR2022-00368
`
`Zynga Ex. 1016, p. 9
`Zynga v. IGT
`IPR2022-00368
`
`

`

`FIGURE 4. Adding a Key Word Generatorto the Brokerage TradingFloor.
`
`Dow Jones__
`
`Reuters
`
`News Monitor
`
`Information Bus
`
`
`
`
`The interactive interface of the Keyword Generator is
`an instance of a new service type. Using introspection, the
`News Monitor can enable the user to interact with this new
`type: menuslisting the operations in the interface can be
`poppedup, and dialogue boxes that are based onthe opera-
`tions’ signatures can lead the user through interactions with
`the new service.
`
`Hence, as soon as the Keyword Generator service
`comes on-line, the user’s world becomes muchricher, both
`in terms of information and of services. As seen by theuser,
`the new service and information is dynamically integrated
`into the environment. This showsthe adaptive flexibility of
`the overall approach. Note that the example requires only
`that the News Monitor support Property objects, but it does
`not require knowledge of how properties are generated, in
`compliance with P4.
`
`6 Related Work
`
`The Linda system, developed at Yale University, was
`the first system to support a generative communication
`model [Carriero89]. In Linda, processes generate tuples,
`which are lists of typed data fields. These generated tuples
`are stored in tuple space and persist until explicitly
`deleted. Other Linda processes may invoke operations to
`remove or read a tuple from tuple