The Information Bus@-An Architecture for Extensible Distributed SystemsBrian Oki, Manfred Pjluegl, Alex Siegel, and Dale SkeenTeknekron Software Systems, Inc.530 Lytton Avenue, Suite 301Palo Alto, California 94301{boki, pfluegl, alexs, skeen}@tss.comAbstractResearch can rarely be performed on large-scale, distributedsystems at the level of thousands of workstations. In thispaper, we describe the motivating constraints, designprinciples, and architecture for an extensible, distributedsystem operating in such an environment. The constraintsinclude continuous operation, dynamic system evolution,and integration with extant systems. The InformationBus, our solution, is a novel synthesis of four designprinciples: core communication protocols have minimalsemantics,objects are self-describing, types can bedynamically defined, and communication is anonymous. Thecurrent implementation provides both flexibility and highperformance, and has been proven in several commercialenvironments, including integrated circuit fabrication plantsand brokerage/trading floors.1 IntroductionInthe 1990s, distributed computing has truly moved outof the laboratory and into the marketplace. This transitionhas illuminated new problems, and in this paper we presentour experience in bringing large-scale, distributed computingto mission-critical applications. We draw from two commer-cial application areas: integrated circuit (IC) fabricationplants and brokerage/trading floors. The system we describein this paper has been installed in over one hundred fifty pro-duction sites and on more than ten thousand workstations.We have had a unique opportunity to observe distributedcomputing within the constraints of commercial installationsand to draw important lessons.This paper concentrates on the problems posed by a “24by 7“ commercial environment, in which a distributed sys-tem must remain operational twenty-four hours a day, sevenPermission to copv without fee all or part of this material isgranted provided that the copies are not made or distributed fordirect commercial advantage, the ACM copyright notice and thetitle of the publication and Its date appear, and notice IS giventhat copying is by permission of the Association for ComputingMachinery. To copy otherwise, or to republlsh, requires a feeand/or specific permission.SIGOPS ‘93/12 /93/N. C., USA~ 1993 ACM 0-89791 -632 -8/93 /0012 ...$l .50days a week. Such a system must tolerate software andhardware crashes; it must continuerunning even duringscheduled maintenan- periods or hardware upgrades; and itmust be able to evolve and scale gracefully without affect-ing existing services. This environment is crucially impor-tant to our customers as they move toward real-timedecision support and event-driven processing in their com-mercial applications.One class of customers manufactures integrated circuitchips. An IC factory represents such an enormous invest-ment in capital that it must run twenty-four hours a day. Anydown time may result in a huge financial penalty from bothlost revenue and wasted materials. Despite the “24 by 7“processing requirement, improvements to software andhardware need to be made frequently.Another class of customers is investment banks, bro-kers, and funds managers that operate large securities trad-ing floors. Such trading floors are very data-intensiveenvironments and require that data be disseminated in atimely fashion to those who need it. A one-minute delay canmean thousands of dollars in lost profits. Since securitiestrading is a hi@J competitive business, it is advantageousto use the latest software and hardware. Upgrades are fre-quent and extensive. The system, therefore, must bedesigned to allow seamless integration of new serviceswithout affecting existing services.In the systems that we have built and installed, dynamicsystem evolution has been the greatest challenge. The sheersize of these systems, which can consist of thousands ofworkstations, requires novel solutions to problems of sys-tem evolution and maintenance. Solving these problems in alarge-scale, “24 by 7“ environment leads to more than justquantitative differences in how systems are built-thesesolutions lead to fundamentally new ways of organizingsystems.The contributions of this paper are two-fold. One is thedescription of a set of system design principles that werecrucial in satisfying the stringent requirements of “24 by 7“environments. The other is the demonstration of the useful-ness and validity of these principles by discussing a body of58software out in the field. This body of software consists ofseveral tools and modules that use a novel communicationsinfrastructure known as the Information Bus. All of the soft-ware components work together to provide a complete dis-tributed system environment.This paper is organized as follows. Section 2 provides adetailed description of the problem domain and summarizesthe requirements for a solution. Section 3 outlines the Infor-mation Bus architecture in detail, states principles thatdrove our design, and discusses some aspects of the imple-mentation. Section 4 describes the notion of adapters, whichmediate between old applications and in the InformationBus. Section 5 describes other software components thatuse the Information Bus and provide a complete applicationenvironment. This section also provides an example to illus-trate the system. Section 6 presents related work. Section 7summarizes the paper and discusses open issues. TheAppendix discusses the performance characteristics of theInformation Bus.2 BackgroundAn IC fabrication plant represents a huge capital invest-ment. This investment, therefore, is cost-effective only if itcan remain operational twenty-four hours a day. To bringdown an entire plant in order to upgrade a key softwarecomponent, such as the” Work-In-Process” tracking system,would result in lost revenue and wasted material. There isno opportunity to “reboot” the entire system. We state thisrequirement as RI:RI Continuous operation. It is unacceptable to bringdown the system for upgrades or maintenance.Despite the need for continuous operation, frequentchanges in hardware and software must also be supported.New applications and new versions of existing applicationsneed to be brought on-line. Business requirements and fac-tory models change, and such changes need to be reflectedin the application behavior. For example, new equipmenttypes could be introduced into the factory. We