The Comandos Distributed Application Platform

The Comandos Distributed ApplicationPlatform

VINNY CAHILL*, ROLAND BALTER' , DAVID HARPER*, NEVILLE HARRIS*,XAVIER ROUSSET DE PINAT AND PEDRO SOUSAS

* Department of Computer Science, Trinity College Dublin, Ireland'Unite mixte BULL-IMAG, Gieres, France

Robert Gordon University, St Andrew Street, Aberdeen AB1 1HG, UK§INESC, R. Alves Redol 9, 1000 Lisboa, Portugal

This paper presents an overview of the Comandos distributed application platform. It begins bypresenting the scope and objectives of the platform before introducing its main concepts, design choicesand overall architecture. An overview of the various prototype implementations of the platformundertaken within the Comandos project is also presented. In addition, the paper provides an introduction

to the other papers on Comandos in this issue and sets the context for the research reported therein.

Received April, 1994

1. INTRODUCTION

The development and integration of application softwareis currently a labour and cost-intensive proposition,particularly for cooperative applications in which largevolumes of distributed structured data are shared bycooperative users. Methodologies and tools are neededto master the complexity inherent in the use ofheterogeneous distributed environments and in newapplication requirements.

The overall objective of the Comandos project1 (Cahillet al., 1993) which ran from 1986 to 1993 was to specifyand construct an integrated platform for programmingand managing multi-vendor distributed systems. Theplatform was to be targeted at application programmersand system administrators with the aim of reducing theoverall cost of the development, maintenance, andevolution of large distributed applications, as well asthe reuse of old-style (UNIX2) applications. The platformwas expected to be a basis for integrated informationsystems in application domains such as office andbusiness systems, computer aided design and softwareengineering.

Comandos was to support the development of inte-grated (also described as tightly-coupled) distributedapplications within a cell which constitutes the basicorganizational and administrative component within anenterprise computing system. A cell is typically com-posed of a set of cooperating workstations, servers andprocessor pools connected through a high-speed localarea network. The goal of Comandos was to present thedistributed system to its users as a coherent entity despitethe variety of its components.

This paper gives an overview of the main concepts,

1 This work was partially supported by the Commission of theEuropean Community under ESPRIT contracts 834 and 2071.

2 UNIX is a trademark of UNIX Systems Laboratories, Inc.

design choices and overall architecture of the resultingdistributed application platform as well as introducingits various prototype implementations. The paper alsoserves as an introduction to the other papers on aspectsof Comandos to be found in this issue.

The paper is structured as follows. Section 2 intro-duces the Comandos model which describes thefunctionality provided to application developers andsystem administrators. Section 3 describes the architec-ture of the platform and introduces its variousimplementations. Section 4 introduces the other papersin this issue, while Section 5 contains a summary andsome conclusions.

2. THE COMANDOS MODEL

The Comandos project adopted an innovative approachbased on the integration of operating system, program-ming language and database technologies. A unified viewof the platform is provided by a model and systemarchitecture based on object-oriented technologycoupled with distributed persistent storage in whichobjects are the units of programming and data model-ling, as well as the units of distribution and storage.

This conceptual model of a distributed environment,encompassing both computation and data management,presents the functionality of the Comandos platform toapplication programmers and system administrators.The model is abstract in the sense that it does not requirethe use of any particular programming language.Technically it consists of two major components:

• A computational model which allows distributedprograms to be defined. This model provides theapplication designer with a multi-node multiprocessorvirtual machine, in which parallelism is apparent anddistribution is hidden.

• Common and extensible type and data models. The

THE COMPUTER JOURNAL, V O L . 3 7 , No. 6, 1994

Dow

nloaded from https://academ

ic.oup.com/com

jnl/article/37/6/477/518741 by guest on 27 August 2022

478 V. CAHILL et al.

type model captures the type systems of variousobject-oriented programming languages and providesa basis for supporting cross-language invocation. Thedata model provides abstractions for modellingcollections of objects, relationships between suchcollections and classification structures.

2.1. Functionality of the platform

The fundamental goal of Comandos was to makeavailable a platform providing the functionality neces-sary for the construction and management of sophisti-cated distributed applications. Thus, the Comandosplatform includes infrastructure supporting:

• Transparent access to distributed resources andservices.Transparent access to persistent data.Concurrent distributed computations.Fault tolerance.Controlled sharing of resources.Data management.Security and protection of data.On-line system management, monitoring and control.

In the following sections, the approach taken tosupporting each of these features is presented.

2.1.1. Transparency

One of the main requirements on the Comandosplatform was transparency, i.e. the provision of acoherent and uniform view of all the resources(including data) and services provided by the distributedsystem. In Comandos, all resources and services aremodelled as objects. Transparency implies that theplatform provided to the user hides the distribution ofobjects and processing, as well as the possible hetero-geneity of the underlying hardware. In addition, theplatform should provide user mobility, i.e. the ability fora user to access objects independently of being logged onto a specific workstation.

Transparency has many aspects: access transparency,in which both local and remote objects are accessed inthe same way; location transparency, in which thelocation of an object is not apparent from its name;execution transparency, in which the execution site of aprogram may be easily changed, possibly in a dynamicway; environment transparency, in which the sameprogram has the same effect independently of the siteon which it is executed; failure transparency, in which apartial failure may be bypassed, so allowing programs tobe fault-tolerant; and, finally, performance transparency,in which the costs of remote access are not generallydegraded over those of local access.

Comandos supports access, location, execution andenvironment transparency. Although full failure trans-parency was not supported, a transaction mechanism(see Section 2.1.4) is provided which allows an applica-tion to ensure that the data which it is accessing remains

consistent even if the execution of the application isinterrupted by a failure. Comandos also supports fulluser mobility.

In some cases, transparency is not desirable and someapplications may elect to be aware of the distribution ofthe objects which they manipulate. For such cases, theplatform primitives which allow the management ofobject location are made visible to the applicationprogrammer.

The central execution mechanism of the Comandosplatform is object invocation, i.e. the execution of aspecified method of an object by a process executing atsome node. If the object happens to be present in virtualmemory at the node, e.g. as a consequence of a previousinvocation, the invocation is performed locally. If theobject is not present in local virtual memory, it may bepresent in virtual memory at some other node, again as aresult of a previous invocation. In this case a remoteinvocation would be carried out. Finally, it may happenthat no node currently has an image of the object invirtual memory. In that case, the object must be locatedin secondary storage and would be mapped (loaded) intovirtual memory at some node where the invocationwould then be carried out. The choice of the node isdetermined by the execution policy in force and coulddepend, for example, on the load on the distributedsystem.

Note that each object resides entirely on a single node(either mapped in virtual memory or stored in secondarystorage). Comandos does not support fragmentation ofindividual objects. This design choice resulted directlyfrom the granularity of objects expected (usually small)and from the general approach in which large compoundstructures can be built out of object components. InComandos, a complex compound object and its variousobject components may reside on different nodes.

2.1.2. Persistence

In conventional programming languages, the life-timesof most entities are bound by the duration of a programrun. External files are usually the sole exception, withthe consequence that if a particular entity is to survive aprogram run, it must be inserted into a file (possiblyrequiring a change in its representation) and explicitlyretrieved (and possibly rebuilt) at a later time. The dis-advantages of this approach are well known (Atkinsonet al., 1983). In systems providing persistence, pro-grammers can manipulate persistent entities withoutexplicit I/O.

In Comandos, persistence is defined via the reach-ability property of objects, i.e. every object reachable byrecursively enumerating the constituent objects fromsome specified set of root objects is guaranteed by theplatform to persist. Thus, there can be no danglingreferences to objects.

When not in use, persistent objects are stored onsecondary storage. When an attempt to access such an

THE COMPUTER JOURNAL, VOL. 37, No. 6, 1994

Dow


ic.oup.com/com


THE COMANDOS DISTRIBUTED APPLICATION PLATFORM 479

object is made, the object is automatically fetched fromstorage by the platform and made available in virtualmemory at an appropriate node. Hence it is unnecessaryfor the programmer to write code either to explicitlyfetch the object from storage or to convert between thepossibly different secondary storage and virtual memoryrepresentations of the object since this is handledautomatically by the platform. Likewise, when theobject is no longer required by any running applica-tion, the platform automatically returns the object tosecondary storage—there is no need for the programmerto explicitly store the object.

When an object is retrieved from storage other relatedobjects may be retrieved at the same time and in the sameI/O operation so that they are available for use shouldthey be required. Such a group of related objects isknown as a cluster. Such prefetching of objects improvesperformance by reducing the number of mapping andI/O operations required when related objects are usedtogether.

The paper by Sousa and others in this issue discussesthe approach to persistence in the IK implementation ofthe Comandos platform (see Section 3.1.1).

2.1.3. Concurrency

An important design decision was how to relate objectsto processes. Two possible solutions were available:

1. Associate processes with objects, i.e. define activeobjects, in which every object contains a fixed orvariable number of processes. This solution was usedin previous systems such as Argus (Liskov andScheifler, 1983) and Eden (Almes et al., 1985).

2. Separate objects from processes, i.e. define passiveobjects which can be operated on by independentlydefined processes. This is the solution adopted inClouds (Dasgupta et al., 1988), Amoeba (Mullender,1985) and SOS (Shapiro et al., 1989).

The active object solution is conceptually simpler sincea single abstraction encompasses the concepts of resourceand process. On the other hand passive objects containless context information than active objects. Thereforeobject creation, invocation and migration can be imple-mented more efficiently than for active objects. More-over, since the classes of application that Comandos wasintended to support typically involve creating many(usually small) objects, and building large compoundstructures out of object components, the passive objectsolution was chosen as being the more appropriate.

In Comandos, a job represents the processing (possiblyin parallel) of objects and consists of one or moresequential threads of control, called activities. A job iscreated by an activity of another job to invoke a specifiedmethod on some object. A new job initially consists of asingle activity.

The execution of an activity consists of nestedinvocations of methods on objects. Each invocation

may take place on any node in the system. At eachinvocation the referenced object is located and, ifnecessary, loaded into virtual memory at some node. Aremote invocation takes place if the node selected forexecution is different from the node on which theinvocation was requested.

An activity may, at any time, create one or moreparallel activities within the same job. Therefore theplatform provides two levels of concurrency: betweenactivities belonging to the same job (i.e. relatedcomputations within the same application); andbetween activities running in different jobs (i.e. indepen-dent applications). Asynchronous invocation can beimplemented by creating a new activity (or job) to invokea designated object.

2.1.4. Atomicity

Atomic transactions (Bernstein et al., 1987) provide ameans of ensuring the consistency of data in the presenceof concurrency and partial failure. In particular,transactions classically guarantee certain properties—atomicity, consistency, isolation and durability—foroperations carried out within the transaction (Grayand Reuter, 1992).

In fault tolerant distributed systems it is commonsense that the atomicity property of computations shouldbe provided. For some applications consistency of data isalso required. However, providing the atomicity prop-erty of computations and ensuring the consistency of theaffected data are, at least in principle, orthogonal to eachother. Consequently, a general backward error recoverymechanism which makes no assumptions about thesynchronization mechanism used should be provided.This enables the use of different and even no synchro-nization mechanisms in the future without having tochange the underlying recovery mechanism. As a firststep in this direction Comandos provides a generalizedtransaction mechanism. This mechanism is based on arecovery layer which is able to manage dependenciesbetween transactions. Thus, in contrast to traditionaltransactional systems, ensuring consistency of transac-tions becomes possible without having to enforce theusual restrictive failure isolation property.

The Comandos transaction model is derived from thatprovided in RelaX (Schumann et al., 1989). RelaXprovides generalized distributed transactions, extendingthe classical transaction model by supporting optionaluse of uncommitted data, extended nesting (allowingthe differentiation between recovery and synchronizationlevels), and the separation of transaction commitmentfrom completion. A transaction consists of a set of opera-tions on objects which has the properties of atomicity,consistency and durability.

Since transaction mechanisms involve a certain over-head which should not be incurred by all objects, thesemechanisms apply only to a subset of objects known asatomic objects. An object may be created as an atomic

THE COMPUTER JOURNAL, VOL.37 , No. 6, 1994

Dow


ic.oup.com/com



object or a non-atomic object can be promoted to be anatomic object (the reverse not being permitted). Hencethe transaction properties are only guaranteed foroperations on atomic objects carried out within atransaction. A transaction is contained entirely withina single job.

In addition to accessing atomic objects, transactionsmay also access other (transactional) resource types suchas external (to Comandos) files or database records. Thisis achieved by structuring the implementation accordingto the X/Open model (X/Open Company, 1991): theComandos platform acts as a collection of X/OpenApplication Programs and Resource Managers thatinteract with the RelaX Transaction Manager (Krogeret al., 1990) which is responsible for distributed trans-action management via an interface which extends theX/Open XA-interface. Pure XA-compliant ResourceManagers can still be used.

The paper by Taylor and others in this issue discusses anumber of issues related to the design of the transactionsupport in the Amadeus/RelaX implementation of theplatform in detail.

2.1.5. Sharing

There is no explicit communication through messagepassing between activities. Instead communication andsynchronization between activities (within the same job,or belonging to different jobs) is achieved by invoking onshared objects.

Object sharing may be controlled in a number of waysdepending on the consistency requirements for concur-rent usage. Atomic objects are guaranteed to remainconsistent despite concurrent access and partial failure ofthe underlying system.

Comandos makes no guarantees about the consistencyof objects which are not atomic. Other objects (i.e. theirclass code) can maintain their own consistency in thepresence of concurrent accesses by making use ofprimitive concurrency control mechanisms—such assemaphores—provided by the platform.

2.1.6. Data management

Comandos provides services for the management oflarge collections of objects (including associative accessto objects belonging to collections), based on a datamodel which provides a set of constructs that enablesapplication programmers to model real world entitiesand the relationships between them with relative ease.The Comandos data model, the Binary RelationalObject-Oriented Model (BROOM) (Harper et al,1991), provides four kinds of collections which mightbe considered to be special forms of sets, sequences,bags and binary relations. These collections areprovided through a number of generic bulk typeconstructors.

The inclusion of binary relations as collections is noveland therefore requires some comment. In recent years,

the various forms of entity-relationship data models havebeen popular for data modelling. The basis of thisapproach is to model the real world in terms of entitysets and relationships between entity sets. Support forthe direct representation of relationships is extremelybeneficial in data modelling. A deficiency of the object-oriented approach is its inability to do just that. There-fore, the usual notions of the object-oriented data modelhave been extended to include direct representation ofrelationships between entity sets: this is achieved byintroducing the binary relation as a kind of collection inthe Comandos data model.

A further limitation of many existing object-orienteddata models is that they allow only one collection ofobjects of a particular type. Thus, associated with a typethere may be a collection which comprises the set of allcurrent instances of that type. In BROOM, the notionsof typing and classification have been separated. Thispermits several collections of objects to be associatedwith a given type. Collections are related by means of aclassification structure. This approach provides a muchmore flexible modelling capability.

The classification structure is represented by means ofstructural constraints among collections. For example,an IS-A relationship between two set collections C and Dsays that every object that belongs to collection C mustalso belong to D and this may be represented by a subsetconstraint between C and D. Other forms of structuralconstraints supported correspond to partitions ofcollections, the intersection of collections, and cardin-ality and dependence constraints on relations.

2.1.7. Security

The Comandos platform provides distributed applica-tions with facilities to keep objects secure (Medina andMoreno, 1991). The ultimate goal of security in an object-oriented environment is to enforce the constraint that anobject can only ever be manipulated by authorized,authenticated and secure invocations of type-specificoperations on that object.3 The mechanisms providedtowards achieving this goal in Comandos are:

• Secure transmission of the arguments and results ofeach (remote) object invocation, by the use ofencryption techniques to prevent playback, copyingor modification of messages.

• Authorization checks on object invocations which areachieved through the use of access control listsassociated with each protected object. The access-rights can specify the set of operations that a user (or agroup of users) can perform on the object.

• Isolation of objects at run time so as to protect againstdamage to an object by code of another objectexecuting in the same address space.

In addition an audit service is provided which allows the

3 Where direct access to the data of an object, if supported, isconsidered as a special form of operation invocation.

THE COMPUTER JOURNAL, VOL.37, No. 6, 1994

Dow


ic.oup.com/com



Running InformationSystem

ProductiveInterface

Results

tA

Generated ^ ^ ^ ^ ~

FIGURE 1. Adaptive framework for system design and management.

InputSubmitted

system administrator to detect intrusion into or misuseof the system (Weiss and Baur, 1990).

These facilities are implemented by low-level mechan-isms within the platform. High-level management toolsfor the overall administration of the security policies andprocedures (e.g. user and group management, etc.) arealso provided.

Note that while no authentication service wasprovided, it was expected that an authentication servicesuch as Kerberos (Steiner et al., 1988) could be integratedwith the platform.

2.1.8. Management view of the platform

Most approaches to organizational (Grochla, 1982) andsystems design (Lockemann and Mayr, 1986) areoriented towards a life-cycle model and a projectorganization with phases for action. These approachesput most emphasis on the early stages of the life-cycle.However, they tend to neglect the use and operation ofan information system, or an organization, afterimplementation. This is certainly not the appropriateway of viewing an information system when one isconcerned with its continuing performance over a longperiod of operation. Generally, a system is built withinseveral weeks or months and used for many years.

The assumptions made about an information systemand its environment during its implementation cannot beconsidered valid throughout its operation. For instance,the throughput can vary with the season or with markettrends; new products may emerge, and the size of thesystem may change. New technology is emerging at arapid rate, causing changes to the way systems are beingbuilt. Communication and networking are becoming

more important, causing systems to grow dynamicallyand to become far more complex.

Hence, for the design and operation of a distributedsystem a new management method should be followed.This calls for design and management approaches thatexplicitly surrender the assumptions underlying a phase-oriented approach (Floyd, 1981). Comandos thus adoptsan evolutionary approach to system management.

The adaptive framework for the management ofComandos systems, described in Figure 1, can bemapped onto three generic types of activities. Obser-vation activities are concerned with collecting infor-mation while the system is running. Decision activitiessupport the actual design, configuration and securitymanagement decisions. They are carried out by a humandesigner or manager using an interactive adminis-tration or management tool specific to the task. Controlactivities realize a design or configuration decision, i.e.implement a change. These activities are supported inComandos by a set of cooperating management tools(see Section 3.2).

2.2. Programming with the Comandos model

To both facilitate the use of the Comandos model and toencourage its adoption, the model is provided toapplication developers through one or more program-ming languages. The uniformity of the Comandos modelresults in programming languages in which a uniformtreatment of both transient and persistent data, are ofboth local and remote services are all potentiallyavailable.

This strategy differs from more classical approaches inwhich tight coupling of a programming language with

T H E COMPUTER JOURNAL, V O L . 3 7 , No. 6, 1994

Dow


ic.oup.com/com



support for persistence and distribution is not supported.Typically, in the classical approach, a set of languagesis used for building programs where one language isused to describe the computation to be carried out, adifferent language is used to define storage types, and afurther language is used for interface definition andcommunication.

While the Comandos model describes the supportprovided by the platform in an abstract way, it isimportant to realise that the interface to the platformused by an application developer is typically providedthrough one of a number of supported programminglanguages. The Comandos platform was designed to beindependent of the use of any specific programminglanguage for the development of distributed applicationsand to allow a range of different languages to besupported simultaneously. Indeed, a single applicationmay be composed from parts written in differentprogramming languages. Of course the features of themodel are particularly exploitable by object-orientedlanguages. In any case, the model seen by a programmermay differ from the model implemented by the platform.For example, a particular language may restrict thevisibility of certain features of the platform or, alter-natively, enhance the functionality of the basic platformby adding extra support in its run-time system.

Two approaches to the provision of language supportwere followed: supporting existing languages, andproviding a new language environment.

The two existing object-oriented languages supportedwithin the project were C++ (Ellis and Stroustrup, 1990)and Eiffel (Meyer, 1988). The overall strategy was toenhance each host language with features of theComandos computational model (mainly concurrency,persistence, distribution and atomicity). Languageextensions are supported using appropriate pre-proces-sing which generates necessary supplementary informa-tion. In some cases, restrictions are imposed on the use ofstandard features of the languages due to the distributednature of the environment. However, in order to beconsistent with the definition of each language, as well asto be able to support existing code, the number of suchrestrictions has been minimized. The paper by Tangneyand others in this issue reports on experience withprogramming parallel distributed applications in theversion of C++ supported by the Amadeus/RelaXimplementation of the Comandos platform (see Section3.1.1).

The experience drawn from the early phase ofComandos made it clear that it was useful to provide anew language in which all the concepts of the Comandosmodel are directly reflected. The Comandos object-oriented programming language is known as Guideand is described in the paper by Baiter and others inthis issue. The viability and usefulness of this newlanguage have already been demonstrated by program-ming basic system services and a number of distributedapplications.

Object-OrientedDistributed Applications

Comandos Platform

Security ) p m l n k > r a t i ° ' ] ObjectDataMngtJ

Service

Application Servicesand

I Management ToolsManager

Application Interface

Comandos System

Language-specific run-times

Comandoslanguage

C++ Eiffel

Virtual Machine Interface

generic run-time

kernel

Environment Interface

Mach 3.0 CHORUS UNIX HostEnvironments

FIGURE 2. The structure of the Comandos platform.

3. STRUCTURE OF THE COMANDOSPLATFORM

The overall structure of the Comandos platform ispresented in Figure 2. Essentially the platform consists oftwo main components:

• The Comandos system, which is itself structured in twolayers: the virtual machine, which is independent ofany supported programming language, and a set ofone or more language-specific run-time systems.

• A set of application services and management tools,which extend the functionality of the basic Comandossystem but are built as normal applications.

A language-specific run-time system implements a specificextension of the basic Comandos virtual machine for aparticular programming language. A given Comandossystem provides at least one language-specific run-time inorder to support objects programmed in the correspond-ing language; several language-specific run-times can co-exist in the same system, thus allowing several languagesto be used simultaneously.

3.1. The Comandos virtual machine

The Comandos virtual machine (see Figure 2) providesthe basic mechanisms which are necessary for an object-oriented distributed system supporting multiple lan-guage environments. This includes transparent accessto distributed and persistent objects; the control of


Dow


ic.oup.com/com



distributed computations; transaction management; shar-ing; and low-level security mechanisms.

The virtual machine provides a unified framework forthe management of objects, which supports the view-points of both databases and general purpose program-ming languages. Programming languages frequently dealwith transient entities—objects whose lifetime is limitedto the execution of a program—while databaselanguages deal with persistent ones, i.e. objects whoselifetime is independent from that of the programs whichuse them. The virtual machine supports both viewpointsin a uniform way.

At the upper level of the virtual machine in the genericrun-time (GRT) (see Figure 2) which provides a languageindependent layer implementing distributed objectinvocation. The GRT is itself provided above thekernel layer which includes those components of thevirtual machine which must be implemented in aprotected way, and which interfaces directly with theunderlying host environment.

The virtual machine consists of a number of functionalcomponents, which should be present in every Coman-dos implementation. These components are as follows:

• Virtual object memory. This is responsible forimplementing transparent access to distributed per-sistent objects and for all aspects of object manage-ment including object creation, low-level objectnaming, object location, remote invocation and themapping and unmapping of objects to and fromsecondary storage.

• Execution sub-system. This implements distributedconcurrent processing and is responsible for job andactivity creation and management, load balancingand low-level synchronization mechanisms.

• Storage sub-system. This provides distributed persis-tent storage.

• Transaction sub-system. This implements the mechan-isms necessary to support atomic objects and thetransaction model.

• Protection sub-system. This provides low-level secur-ity services including authorization, secure transmis-sion and generation of audit data.

• Communication sub-system. This provides networkcommunication services.

The Comandos Virtual Machine Interface (VMI) (i.e. theinterface between the GRT and the various language-specific run-times, see Figure 2) is intended to be used bycompiler builders and basic service implementors. Itprovides a set of primitives which allow the interactionbetween application objects and the virtual machine.

The VMI is the uniform view presented by theComandos virtual machine to each of the varioussupported languages. As different languages have dif-ferent calling semantics, a language-specific run-timemust adapt the GRT primitives to the language-specificformat. Moreover, as most of these primitives are basedon manipulation of objects whose format and model

differ in each of the different languages, each language-specific run-time must also hide these language depen-dencies from the GRT.

To provide this flexibility and to make a minimumnumber of impositions on any language, Comandosadopted a general model in which the language maymake calls to the GRT which depend on language-specific information. To handle such a call the GRTmakes heavy use of up-calls, where an up-call is a callfrom a lower level to a higher one, to obtain thenecessary information from the language-specific run-time.

This two-way interface between a language-specificrun-time and the GRT allows objects from heteroge-neous languages to be handled uniformly by the GRT.

3.1.1. Implementation of the virtual machine

The definition of the virtual machine is independent ofany underlying system, and can be mapped onto varioushost environments. Two approaches have been used toimplement prototypes of the Comandos virtual machine.

• The first approach consisted of implementing thesystem as a guest layer on top of UNIX. One suchimplementation, Amadeux/RelaX, was designated asthe reference platform for the project. Therefore it wasthe basis for the integration of the numerous systemcomponents, application services and managementtools developed throughout the project. This imple-mentation is detailed in Cahill et al. (1993). The othermajor UNix-based implementation of the virtualmachine, IK, is described in Sousa et al. (1993).

• The other approach followed was to implement thevirtual machine directly on top of a micro-kernel. Themotivation of this approach stemmed from the beliefthat the microkernel technology would be better ableto support the Comandos abstractions, especially asfar as distributed shared objects and protection wereconcerned. Two prototypes have been implementedusing micro-kernel technology: one, Chorus/COOLv2., is hosted on top of the Chorus micro-kernel whileanother, Guide-2, runs on top of OSF/l-MK. Theseimplementations are described and the resultingconclusions about the use of micro-kernel technologyto support the Comandos platform are reported inLea et al. (1993) and Baiter et al. (1993), respectively.

Each of these prototypes implements a different (if notdistinct) subset of the VMI. The existence of severalprototype implementations results from a deliberatestrategy of investigating different approaches andtechniques in the implementation of the core function-ality of the virtual machine. In addition each of theimplementations focused on different areas. For example,the focus of the Amadeus/RelaX platform was on multiplelanguage support; on support for atomic objects andtransactions; and on low level mechanisms to supportassociative access to objects. In contrast the focus of the


Dow


ic.oup.com/com



IK implementation was on the support of orthogonalpersistence in a distributed UNIX environment; on theexploration of on-line replacement of classes as a mech-anism to support dynamic configuration and debuggingof applications; and on the combination of clusteringand naming mechanisms in order to achieve betterorganization and structuring of information in thepersistent store. It should also be noted that full inter-working of the various prototypes was not possiblewithin the timescale of the project.

3.2. Application services and management tools

The services and tools provided by the platform fallbroadly into two categories: application services whichare used in the development of distributed applicationsor which are required at run-time by a range of distri-buted applications, and management tools which areprovided to assist in the management and administrationof the system. Application services provided within theproject include the following.

• Development tools to aid application designers in thedesign, construction and debugging of distributedapplications. These development facilities includecompilation tools, a distributed debugger and toolsfor the development of user interfaces.

• A Type Manager (TpM) which can be used by thelanguages available on a Comandos platform as arepository for type information. During the process ofapplication development or configuration, types canbe created and registered in the TpM. Type informa-tion may be read for the purpose of semantic checkingeither at build time or at run time. The TpM's clientsare thus compilers, pre-processors, language run-timesystems and query processors.

• An Object Data Management Service (ODMS) for themanagement of and associative access to collectionsof objects (Glasgow, 1992). The ODMS is thecomponent of the platform that performs database-like functions. The ODMS basically implements theBROOM data model facilities (see Section 2.1.6). Toachieve this goal the ODMS provides various forms ofrepresentation of collections, built-in operations onthe pre-defined bulk data types of BROOM, andimplements mechanisms for the efficient retrieval ofobjects from collections (e.g. indexing, part-of andinheritance hierarchy scanning, etc.) and optimizationof queries on collections.

The management tools provided include:

• A Distributed Directory Service (DDS) for symbolicobject naming. The DDS is an implementation of theISO/CCITT X.500-IS9594 standards integrated intothe Comandos platform.

• A distributed System Observation Facility (SOF)which supports the observation activities of theadaptive framework for system managementdescribed in Section 2.1.8. Information collected by

the SOF is passed to high-level management tools forprocessing (see below).

• A distributed System Control Facility (SCF) whichsupports the control activities of the adaptive frame-work for system management. Administration andreconfiguration decisions stemming from high-levelmanagement tools can be implemented using the SCF.

• A system configuration and administration tool whichis bound to the SOF and SCF. System administratorsare provided with graphical output showing statisticsconcerning system behaviour and can initiate config-uration changes.

• Security tools for risk management and analysis ofaudit data generated by the virtual machine. Riskswith respect to the integrity, availability, and con-fidentiality of information can be estimated on thebasis of data provided by system observation andauditing as well as by simulation of system failures.

• A tool for the design of a distributed office system.Organizational designers are supported in the logicaldesign of business processes and of the distributedinformation system used to execute these processes.

Several of these tools are discussed further in the paperby Kerber and others in this issue.

In addition, existing tools can also be used, whereappropriate, in a given Comandos environment. If thetools exist in a UNIX environment, then recoding ofthe tool is not required because of the coexistence of theComandos and UNIX environments.

4. INTRODUCTION TO THE PAPERS

As will be appreciated, Comandos was a large andambitious project covering a number of differentresearch topics in areas including (distributed) operatingsystems, programming language design, fault toleranceand data management. The breadth of the project isreflected in the collection of papers appearing in thisissue which cover a cross-section of the work carried outin the project.

The paper by Tangney and others takes an applicationprogrammer's view of one implementation of theplatform and reports on experience—both positive andnegative—with programming parallel distributed appli-cations in the version of C++ supported by Amadeus/RelaX (see Section 3.1.1). The paper presents a list ofrequirements on a platform supporting such applicationsbased on the experience gained—not all of which aresupported by the existing implementation.

The Guide object-oriented programming language isdescribed in the paper by Baiter and others in which theauthors outline the main features of the languageincluding separation between types and classes, theapproach to sub-typing, the synchronization mechan-ism for shared objects, and the exception handlingmechanism. In addition, the authors report on theirexperiences in using the Guide language for theconstruction of distributed applications.


Dow


ic.oup.com/com



The Comandos approach to distributed systemsmanagement as well as some of the available tools arediscussed in the paper by Kerber and others. In par-ticular the authors discuss the adaptive managementapproach and its integration into the Comandos model.The system observation and control facilities integratedwith the platform are described as well as the tools fordistributed information system design, risk management,and user and host administration.

The paper by Sousa and others discusses theimplementation of persistence in IK (see Section 3.1.1)and discusses the interaction between clustering, objectnaming and persistence. In addition the authors reporton their experience with persistence in a number ofapplications.

The paper by Taylor and others discusses the design ofthe two major interfaces concerned with transactionmanagement in Amadeus/RelaX: the (subset of) theVMI concerned with support for atomic objects andtransactions, and the Transaction Manager interface.The authors discuss the separation between generic andlanguage-specific aspects of atomic object managementand describe a Transaction Manager interface suitablefor the requirements of object-oriented systems. Inaddition, the authors show how an existing XA-compliant resource manager—the Informix relationaldatabase system—has been integrated with Amadeus/RelaX.

5. SUMMARY AND CONCLUSIONS

The Comandos project has integrated operating system,programming language and database technologies inorder to design an integrated platform for the con-struction of object-oriented distributed applications.Along the way Comandos has contributed to the stateof the art in (distributed) operating systems, program-ming languages, data management, and security andadministration tools. This claim is supported by the largenumber of theses and published papers originating fromthe project.

More importantly, the project has provided prototypeimplementations of all of the components of theplatform—many of which are now available in thepublic domain—providing the opportunity for realexperience to be gained with the technologies developedwithin the project. Moreover, by adopting a strategywhereby different approaches were taken to theimplementation of the key components, the project hasprovided an opportunity for these different approachesto be compared and the trade-offs between them to beunderstood in practice. The detailed results of this workare documented in Cahill et al. (1993), in the other paperson Comandos in this issue and in the many otherpublications originating from the project. Cahill et al.(1993) contains a full list of these publications and also ofthe available software components (as of the time of itspublication).

To conclude, some of the specific achievements of theproject are noted:

• The definition of a conceptual model of, and anarchitecture for, an integrated application supportenvironment supporting the construction of distri-buted, persistent object-oriented applications.

• A demonstration that the construction of such anenvironment is feasible both on UNIX systems andusing micro-kernel technology.

• The implementation of a generic run-time systemwhich facilitates the use of existing and new object-oriented languages, for the development of distributedand persistent applications, without requiring eachlanguage to adopt a common object model orinvocation mechanism.

• The implementation of a new language specificallyaimed at the construction of distributed applicationsinvolving shared persistent data.

• The definition and implementation of a novel object-oriented data model including binary relations ascollections.

• The definition of a canonical type model suitable forcapturing the type models of object-oriented pro-gramming languages and the implementation of atype manager to support cross-language invocation.

• The implementation and integration of a collection ofsophisticated tools for distributed application devel-opment and system administration.

Currently no vendor independent infrastructure incor-porating all of the features of the Comandos platformexists in the marketplace. The availability of such anintegrated platform, operating in an environment ofheterogeneous machines, would be a significant advanceover current practice and offer significant advantages toapplication programmers and system administratorsalike.

ACKNOWLEDGEMENTS

The authors gratefully acknowledge the efforts of allthose who contributed to the Comandos project duringits 7 years.

REFERENCES

Almes, G., Black, A., Lazowska, E. and Noe, J. (1985) TheEden system: a technical review. IEEE Trans. Software Eng.,SE-11, 43-58.

Atkinson, M., Bailey, P., Chisholm, K., Cockshott, W. andMorrison, R. (1983) An approach to persistent program-ming. Comp. J., 26, 360-365.

Baiter, R., Chevalier, P. Y., Freyssinet, A., Hagimont, D.,Lacourte, S. and Rousset de Pina, X. (1993) Is themicrokernel technology well suited for the support ofobject-oriented operating systems: the Guide experience. InProc. Symp. on Microkernels and Other Kernel Architectures,pp. 1-11, USENIX Association.

Bernstein, P., Hadzilacos, V. and Goodman, N. (1987)Concurrency Control and Recovery in Database Systems.Addison-Wesley, Reading, MA.

Cahill, V., Baiter, R., Harris, N. and Rousset de Pina, X. (eds)

THE COMPUTER JOURNAL, V O L . 3 7 , No. 6, 1994

Dow


ic.oup.com/com



(1993) The Comandos Distributed Application Platform.Springer-Verlag, Berlin.

Dasgupta, P., LeBlanc, R. and Appelba, W. (1988) The Cloudsdistributed operating system. In Proc. 8th Int. Conf. onDistributed Computing Systems, pp. 2-9, San-Jose, CA.

Ellis, M. A. and Stroustrup, B. (1990) The Annotated C++Reference Manual. Addison-Wesley, Reading, MA.

Floyd, C. (1981) A process-oriented approach to softwaredevelopment. In Proc. 6th ACM Eur. Regional Conf,pp. 285-294, ACM, New York.

Glasgow Comandos ODMS Group (1992) The ComandosODMS Portable Toolkit. Technical Report DB-92-4,Department of Computing Science, University of Glasgow.

Gray, J. and Reuter, A. (1992) Transaction Processing Systems:Concepts and Techniques. Morgan Kaufman, San Mateo,CA.

Grochla, E. (1982) Grundlagen der Organisatorischen Gestal-tung. C.E. Poeschel Verlag, Location?

Harper, D. J., Norrie, M. C. and Walker, A. D. M. (1991) Bulktypes for data modelling in persistent object systems. J.Control Syst. Machines, 9.

Kroger, R., Mock, M. Schumann, R., and Lange, F. (1990)RelaX—an extensible architecture supporting reliable distri-buted applications. In Proc. 9th Symp. on Reliable DistributedSystems, pp. 156-164, Huntsville, AL.

Lea, R., Jacquemot, C. and Pillevesse, E. (1983) COOL: Systemsupport for distributed programming. Commun. ACM, 36,37-46.

Liskov, B. and Scheifler, R. (1983) Guardians and actions:Linguistic support for robust, distributed programs. A CMTrans. Programming Languages Syst., 5, 371-404.

Lockemann, P. and Mayr, H. (1986) Information systemdesign: techniques and software support. In Kugler, H.-J.(ed.), Proc. 1FIP 10th World Computer Congress, pp. 617-634, Elsevier Science Publishers, Amsterdam.

Medina, M. and Moreno, A. (1991) Security levels supportedby the Comandos security architecture. In Proc. 1991ESPRIT Conf, pp. 421-426, Commission of the EuropeanCommunities, Luxembourg.

Meyer, B. (1988) Object Oriented Software Construction.Prentice-Hall, Englewood Cliffs, NJ.

Mullender, S. (1985) Principles of Distributed Operating SystemDesign. PhD thesis, Mathematisch Centrum, Vrije Universi-teit.

Popek, G. and Walker, B. (eds) (1985) The LOCUS DistributedSystem Architecture. MIT Press, Cambridge, MA.

Schumann, R., Kroeger, R., Mock, M. and Nett, E. (1989)Recovery management in the RelaX distributed transactionlayer. In Proc. 8th Symp. on Reliable Distributed Systems, 21-28, IEEE, Los Alamitos.

Shapiro, M., Gourhant, Y., Habert, S., Mosseri, L., Ruffin, M.and Valot, C. (1989) SOS: An object oriented operatingsystem—assessment and perspectives. Comput. Syst., 2,287-338.

Sousa, P., Sequeira, M., Ziiquete, A., Ferreira, P., Lopez, C,Pereira, J., Guedes, P. and Alves Marques, J. (1993)Distribution and persistence in the IK platform: overviewand evaluation. Comput. Syst., 6, 391-424.

Steiner, J., Neumann, C. and Schiller, J. (1988) Kerberos,an authentication service for open network systems. InProc. USENIX Winter Conf, pp. 191-202, USENIX,Berkeley.

Weiss, W. and Baur, A. (1990) Analysis of audit and protocoldata using methods from artificial intelligence. In Proc. 13thNat. Computer Security Conf, pp. 109-114, NationalInstitute of Standards and Technology/National ComputerSecurity Center.

X/Open Company Limited (1991) Distributed TransactionProcessing Reference Model: The XA Specification. Berk-shire.


Dow


ic.oup.com/com


The Comandos Distributed Application Platform

Documents

Transcript of The Comandos Distributed Application Platform