Association for Information SystemsAIS Electronic Library (AISeL)

ICIS 1990 Proceedings International Conference on Information Systems(ICIS)

1990

ISSUES IN DISTRIBUTED MODELMANAGEMENT SYSTEMSWaleed A. MuhannaThe Ohio State University

Follow this and additional works at: http://aisel.aisnet.org/icis1990

This material is brought to you by the International Conference on Information Systems (ICIS) at AIS Electronic Library (AISeL). It has been acceptedfor inclusion in ICIS 1990 Proceedings by an authorized administrator of AIS Electronic Library (AISeL). For more information, please contactelibrary@aisnet.org.

Recommended CitationMuhanna, Waleed A., "ISSUES IN DISTRIBUTED MODEL MANAGEMENT SYSTEMS" (1990). ICIS 1990 Proceedings. 27.http://aisel.aisnet.org/icis1990/27

ISSUES IN DISTRIBUTED MODEL MANAGEMENT SYSTEMSWaleed A. Muhanna

Faculty of Accounting and Management Information SystemsThe Ohio State University

ABSTRACT

Within the decision support system area of research, there is a growing body of work focusing on thetopic of Model Management (MM). This paper proposes extending the concept of a ModelManagement System (MMS) to function within and exploit the capabilities of a distributed computingenvironment. A framework for research in Distributed MMS (DMMS) is discussed. In thisframework, distribution of MMS functions can occur along two principal dimensions: distributedmodel-base management and distributed model building and execution. A variety of design andimplementation issues which are relevant to each dimension are examined. It is also argued that thestructuring principles and concepts of the systems framework for model management (as implementedin a prototype system called SYMMS) are particularly appropriate and ideally suited for a distributedenvironment. An architecture for a prototype distributed MMS is also presented.

1. INTRODUCTION The advantages of distributed computing systems are well-known and widely acclaimed (Enslow 1978), the most

Within the field of decision support systems, Model important of which are enhanced system performanceManagement Systems (MMS) (Will 1975) have emerged through parallel processing, high availability and increasedas an important area of research. An MMS is a software reliability, case of modular and incremental growth, andsystem which provides for the creation, storage, manipula- automatic load and resource sharing. While there seemstion, use, and control of models. The primary goal of an to be considerable experience in the development ofMMS is to facilitate the development, maintenance, and distributed applications and the design of distributedutilization of quantitative models, forming the foundation database systems (DDBMS), it remains unclear how Modelof an integrated environment for the support of modeling- Management Systems (MMS) could be designed to operaterelated activities in an organization. Various MMS issues in and benefit from a distributed computing environment.have been investigated in the literature, including modelformulation, model representation, model selection, model As distributed computing systems become even moreintegration, and prototype development. (For a survey and popular, we should rethink the model managementanalysis of the MM literature, the reader is referred to the approaches that were developed for the mainframe-basedwork by Applegate et al. [1985], Holsapple and Whinston modeling environment and develop Distributed MMSs[1988], and Muhanna [1987].) which allow modelers and decision makers to work freely

in a networked distributed computing environment andreap its full advantages whenever possible. This paper

Meanwhile, interest in the development and implementa- investigates some of the challenging issues and problemstion of distributed computing systems has been growing at involved in the design and implementation of DMMS. Ita remarkable rate. The advent of VLSI technology and outlines an agenda for research in DMMS and describeslow-cost microprocessors combined with major advances the progress we have made thus far.in networking technology have made distributed computingan economic reality in today's computing environments. A One of the frameworks proposed for model managementtypical configuration, which is becoming increasingly is the systems framework (Muhanna 1987; Muhanna andpopular, consists of a local network of high performance Pick 1988). Inspired by concepts from systems theory, theworkstations and server machines. The server machines framework provides a rich and intuitively satisfying view ofprovide specific services to the network community, such models, together with a collection of structuring principlesas printing or file storage. The workstations are autono- that are fundamental for capturing the semantics andmous processing units, consisting of a powerful micropro- structural relationships in a modeling environment. Thecessor, reasonable amount of semiconductor memory (two framework compares favorably with other proposals forto ten megabyte), graphics display with frame buffer, local model management, since it addresses important MMhard disk (ten to seventy megabyte), and a network problems, such as model-model linkage, model-datainterface (ten megabit Ethernet). These workstations run linkage, and model reusability. In this framework, modelsmulti-tasking operating systems and are used for are defined and constructed to present a well-definedwordprocessing, office automation, engineering design, and interface, consisting of a set of input ports and a set ofdecision support. output ports. Instances of these models can be used in

231

isolation or interconnected to configure a new, more The notions of model types, versions, and coupling endowcomplex, composite model. This view suggests a graph- an MMS with the qualities of modularity and extensibility.oriented, nonprocedural, and hierarchical approach for In particular, models can be composed hierarchically inmodel composition. terms of (independently developed) component models by

interconnecting the output ports of one model with theWe begin by illustrating some of the systems framework input ports of another. Model versions built in this wayconcepts in Section 2 in order to provide context and to are called composite, whilemodelswithout components areshow how these concepts are particularly appropriate and called atomic. An atomic model-version explicitly de-ideally suited for a distributed environment. Two principal scribes relationships between inputs and outputs anddimensions along which MMS distribution can occur are specifies the solution (transformation) process algorith-identified: model-base (centralized/distributed) and model mically. A composite model-version, on the other hand, iscompilation, loading, and execution (local/distributed). specified by means of a conviguration scheme.Sections 3 and 4 examine the design and implementationissues that are relevant to each dimension. An architecture A configuration scheme specifies how instances (copies)for a prototype DMMS, which is being implemented, is of component models are coupled to form a higher-levelalso presented. Finally, the status of our current research composite model. InstanNation allows multiple copies ofand conclusions are presented in Section 5. the same model to be used in the construction of a new

higher-level model. Each instance is a distinct replica thathas its own set of input ports, output ports, and (possibly)internal state variables associated with its implementation.2. SYSTEMS FRAMEWORK CONCEPTS: Both model types and model versions can be instantiated.A SUMMARY Figure 1 shows a specific production-mix model which wasconstructed by coupling a generic Prod-Mix-LP modelUnderlying the Systems Framework for Model Manage- solver with a forecasting model (Forecast) and other

ment (Muhanna 1987) is a simple premise suggested by components to get the remaining data from a database orthe very definition of the term "model." We define a the user. The model solves the following LPmodel of a reference system as being itself a system problem:expressed in a formal language and synthesized fromrepresentations of selected elements of the reference MAX z = 04 subject to Ax <b, Ix <s, and x 20.system and the inter-relationships between them. Indeed, Xthe essence of a model is that it is an analogue that can beused to reason about the reference system it represents. The vector of product demand, s, is computed by the

forecast model.In the systems framework, a model is defined and con-structed to mirror (as much as possible) the reference _ -system it represents. A model presents to the environment

PMIXa well-defined interface, consisting of a set of input ports Gc[-Mai

and a set of output ports, corresponding to its input ma[variables and output variables, respectively, There is aclear separation between model interface specifications

Aand its implementation details. The former defines an Gct-Vcc voc : babstraction called a model Ope, while the latter is captured xX-in the concept of a model version. Both model types andmodel versions may have specific assumptions associatedwith them. A single model type may be realized by more y- 7

Gct-vcc

than one model ve,sion, each implementing a differentProd-Mix-LPrelationship, employing a different solution algorithm, or

Zmaking different assumptions.Forccas[Demand S-S

Decomposition and the use of hierarchy are two strategiesthat humans use to cope with complexity. Both are _fundamental to the analysis, design, and implementation ofcomplex systems. The systems view of models brings thesestructuring principles to bear on the problem of model Flgure 1. A Composite Model Configurationconstruction. It suggests a modular and hierarchical viewof models which reflect and fully exploit the parallelstructures in the systems being modeled. This permits top- We have defined a formalism for specifying compositedown model construction by step-wise refinement as well models and developed a Model Description Languageas bottom-up construction by coupling existing reusable (MDL) which embodies this formalism (Muhanna and Pickmodel components. 1988). MDL provides a high-level, non-procedural textual

232

means that facilitates both top-down and bottom-up which model-related information can be shared andhierarchical construction of models. Much of MDL's maintained. The MKB is managed by the MKBMS just asutility, as implemented under a prototype model manage- a database is managed by a DBMS. The MKBMS pri-ment system, called SYMMS (Muhanna 1989c), derives marily consists of two layers of software. The bottom layerfrom the ability to piece together individual models to is the storage management components (SMC), which pro-construct new composite models which can be executed vides for reliable storage, retrieval, and update of allwithout writing a single line of program code. model-related information. It provides for version storage

management at two levels: the level of model source codeA prototype model management system, called SYMMS, and the level of MDL version modules. Built on top of thewas developed in order to demonstrate the feasibility and SMC is the Model Librarian, which serves as a directory/utility of the concepts and structuring principles suggested dictionary for available models, maintains integrity andby the systems framework for model management. inter-module consistency, and furnishes a model-orientedConsisting of approximately 12,000 lines of code (mostly in interface (through check-out and check-in operations) toModula-2 with some routines written in C), the prototype other MM subsystems (Muhanna 1989b).runs under the Berkeley UNIX 4.3 operating system.SYMMS furnishes an integrated and coherent environmentfor model management. Users submit MDL modules for The Model Consultation Subsystem (MCS) is comprisedregistration. The system verifies the completeness and of two major components: a model selection componentcorrectness of these modules and provides facilities for and a model construction and maintenance component.their management and subsequent usage. The model selection component provides high-level query

facilities to help various MMS users in locating andUscr selecting models that could meet their needs. The second

component of the MCS is called the model constructionand maintenance component and is intended for use byboth model developers and model implementors forDiatogue M@nagment

Subsystem defining new model types, creating new composite oratomic model-versions, and for updating existing types andversions.

The Model Experimentation Subsystem (MES) is focusedMode[ Coasu[Bation Modd Experimentation

Subsystem Subsystem on supporting decision makers, who utilize models toimprove their decision-making process. Once an appropri-ate model has been selected (perhaps by using the MCS),the decision maker can utilize the MES to run the model.The MES provides for the loading, instantiation, para-meterization, sequencing, and execution of models. Itfurnishes a run-time environment to instantiate models andModct Knowtedge-Base

Management Subsystem provides for their synchronization (scheduling) andcommunication via links.

In the next two sections, we study the major issues involvedFigure 1 SYMMS Architecture in extending SYMMS architecture and implementation to

function within and exploit the capabilities of a distributedcomputingenvironment. Distributingthe MKB component

Figure 2 shows the overall architecture for the MMS is first examined in Section 3. Section 4 then looks at theSYMMS. SYMMS has four major subsystems: the Model issue of extending the MES component to support distri-Knowledge Base Management Subsystem (MKBMS), buted compilation and execution of (composite) models.Model Consultation Subsystem (MCS), Model Experimen-tation Subsystem (MES), and a Dialogue ManagementSubsystem (DS). The MKBMS has overall custodial 3. DISTRIBUTED MODEL BASE ARCHITECTUREfunctions over model-related information and it providesfacilities for use by two other subsystems - the MCS and Central to the MMS architecture is the MKBMS, whichthe MES. A Dialogue Management Subsystem mediates provides for the storage and manipulation of model-relatedinteractions between the user and the system; it provides knowledge. The MKBMS is perhaps the most obviousthe user with an integrated view of the system and hides area where distribution can occur. Three principal relatedthe complicated internal structure. issues are involved here: the physical location, the logical

organization, and managerial control and administration ofCentral to this architecture is the idea that an integrated the MKB. Before presenting our proposed approach, it isModel Knowledge-Base (MKB) serves as the basis by useful to examine the alternatives available to us.

233

003.1 Physical Location Issues database design and file location problems, which are

known to be generally NP-complete (Eswaran 1974).The MKBMS (the MKB and supporting software) could Heuristic techniques have been developed for solvingbe located centrally on one machine but made available to special cases of the file assignment problem (Morgan andall through remote manipulation over the network. The Levin 1978; Dowdy and Foster 1982; Wah 1984) and theyidea is to implement the MKBMS as a server rendering can be adapted to the context of model bases.services to multiple clients. The clients in this case areinstances of other MMS components, namely, the MCS nodc 1 mt i (li;In) nodc n

and MES. A client requests that a service (e.g., check-ins,MKOMS

check-outs, retrieval) be performed by sending a message ,  , ,to the server. The MKB server receives a request forservice from a client, performs that service, and returns a MERMS #MKOMA tDMKOMS\

completion message if necessary. Needless to say, the C Client ) 1 server J   Server j -23

15223MKBclients and the server may be running on the same or

si,lisc' 51,11SC 

different machines in the network. Figure 3 depicts thisThc NI.Iaphysical arrangement.

Figure 4. A Physically Distributed MKBMSnode 1 nod...[ lidIn

MARMSCt, , (  Beyond these design problems, there are also difficultimplementation issues that must be addressed. To achieve

MKBMS c». a reliable and robust distributed MKBMS would requireC e, (  

TI1E addressing problems similar to those encountered in adistributed database context, e.g., maintaining the integrityThe Nclwork MKBMS of replicated data and performing consistent atomic

) updates (Bernstein and Goodman 1981; Reed 1983). In adistributed system, an update operation may affect data

Figure 3. Centrally Lacated MKBMS stored at several nodes in the network. Thus, it is neces-sary to provide some mechanism for coordinating suchupdates so that an action performed at one node is

Many distributed systems have been successfully imple- successfully committed if and only if the related actions inmented using this client/server paradigm. For example, other nodes can also be committed. The atomic updatedistributed file systems such as Sun's NFS (Walsh, Lyon, problem is part of the larger problem of transactionand Sager 1985) supports transparent access to shared files management in distributed systems, which has been theamong heterogeneous workstations, allowing application focus of much research. Solutions to these problems existprograms to operate on remote files exactly as if they were and have been successfully used in distributed databasestored on a local disk. systems such as SDD-1 (Hammer and Shipman 1980),

distributed INGRES (Stonebraker 1979), and R' (LindsayCompared to a single MKB server arrangement, a more et al. 1984).advantageous but more expensive solution is to have (atthe extreme) a fully partitioned and replicated distributed In deciding on an appropriate physical arrangement, oneMKB. This arrangement, illustrated in Figure 4, involves must consider the trade-offs involved. Centralizing thehaving multiple, closely coordinated, MKB servers, each MKB under the control of a single server simplifies therunning on (possibly) a different host and managing one design and implementation and helps keep the data consis-or more partition replica. There are complex design and tent, but when the MKB is large, there may not be enoughimplementation issues to consider here. Important design disk space on a particular host to store all the modelsquestions include (1) how the MKB should be partitioned, together. Even if there is enough disk space, this arrange-(2) how many copies of each partition should be main- ment tends to induce network and disk contention prob-tained, and (3) on which network node should these copies lems when many client users access the single server.be stored.

Distributing the MKB over several machines in theFor management and control purposes, a good way to network has the advantage of significantly reducing the diskpartition the MKB might be along the lines of organiza- and (if set up correctly) the network contention problems.tional function, by organizational level, model class, or a In addition, partitioning the MKB enhances the overallcombination of these. For performance purposes, one efficiency by bringing information closer to the personwould have to consider different criteria, including access requiring it, thus making queries and updates proceedpatterns, size, and network topology. This is clearly a hard more rapidly. The replication of the entire MKB (ordesign-optimization problem, not unlike the distributed partitions thereof) on separate machines on the network

234

overcomes the problem of single points of failure, thereby of this implementation complexity is removed when thisenhancing the overall availability and reliability of the logical partitioning defines independent MKBs or domainssystem. Moreover, since the load could now be spread of integrity management.among the machines where copies are stored, replicationcould also result in enhancing efficiency of MKB accessoperations. However, when there are considerable update 33 Control and Administration Issuesactivities, the high overhead involved in the complexprotocols required to maintain the mutual consistency of Beyond the issues of physical location and logical view,multiple copies could thwart the efficiency gains promised there are also control and administrative concerns thatby such a scheme. must be resolved. Regardless of the logical and physical

arrangement adopted, a central question remains. Thequestion revolves around the issue of control over the

3.2 Logical Organizations of the MKB modeling activities in an organization: who does modeling,how they do it, and what they do with it? An important

Orthogonal to the issue of physical location is the question role, which is critical for the success of an MMS system, isof the logical organization of the MKB: Should the MKB that of a MKB administrator. This role is analogous tobe viewed as a single logical unit or as multiple logical that of a database administrator, and it entails broadunits? If the latter, should these multiple logical units be responsibilities that include setting and enforcing standardsmaintained independently? Regardless of the alternative for model documentation, coding validation, security, andchosen for the physical location, the choice of a particular integrity. Given the complexity of the MM domain,logical view impacts on the nature of the implementation however, it is more likely that the role of model-baseand is influenced by the decisions relating to the division administrator be played by a committee or a group ofof administrative and managerial responsibilities. individuals as opposed to a single person. The issue here

is whether thejiinction of model-base administration oughtWhen viewed as a single logical unit, a MKB could be to be centralized or decentralized.spread over many machines in a network or storedcentrally on one large server, but this remains transparent These fundamental managerial considerations persist,to the user, i.e., as far as he/she is concerned, all the irrespective of the physical location decision or the logicalinformation appears to be part of a single unit resident view chosen. Centralization of modeling control and thelocally. This view is consistent with the philosophy MKB administration function allows close monitoring andunderlying the concept of MM, namely, that models enforcement of protocols and standards to preserveconstitute an organizational resource that should be organizational integrity of modeling activities. The majormanaged as such and that models should be viewed from drawback of this arrangement is that a bureaucratic barrieran organization-wide perspective and not within the context could emerge stifling innovation and discouraging experi-of a specific function or activity. Despite its conceptual mentation. A decentralized arrangement may thereforesimplicity, however, supporting the single logical MKB view prove better if the desire to preserve the autonomy ofis difficult when the MKB is physically distributed through organizational units is more important than maintainingpartitioning, replication, or both. The problems of transac- organization-wide integrity of modeling activities. Theretion management and integrity maintenance become ex- does not seem to be a clear cut choice that is appropriatetremely complicated. A central or fully replicated catalog for every situation. The decision whether to centralize oris needed to locate desired information, greatly complicat- decentralize control must be based not only on the choiceing the query processing operations. The cost of data of the logical view, but also on the organization's size,communication now becomes a new factor in determining norms, and oNectives.an optimal query processing strategy. Furthermore, asindicated in the previous section, complex protocols are The question of where control ought to reside and whetherrequired to perform atomic updates and maintain the con- the administration function should be centralized orsistency and referential integrity of replicated data. decentralized are not unique to the MM context. Indeed,

these questions are aspects of the broader, classic MISOne alternative is to view the MKB as an integrated issue and long-standing debate of whether to centralize orcollection of logical units. This view permits the logical decentralize computing in an organization. In the contextpartitioning of the MKB (e.g., by level, function, project, of general computing King (1983) suggested that while themodel class) in a manner independent of its physical economics of the deployment decisions are important, theorganization, thereby providing a way to cope with the driving force behind this ongoing debate centers aroundcomplexity of the MKB and to provide a more focused the issue of control. In the MM context, the argumentssearch. However, if by integrating this collection of logical are similar but there are clear differences. One suchunits we mean enforcing referential integrity constraints difference is that we assume an environment in which abetween models across the logical units, then the physical networked, as opposed to stand-alone, decentralizationimplementation issues are just as difficult as they would be decision with regard to the hardware infrastructure hashad the MKB been viewed as a single logical unit. Much already been made. Hence, the economics of deployment

235

decisions revolve around the one-time cost of the imple- since it fails to address the need for some discipline in thementation needed to support a given physical and logical storage, sharing, and management of models as an organi-view. Moreover, compared to a stand-alone decentraliza- zational resource.tion, this networked arrangement permits organization-wide control and model administration, thereby preserving An intermediate arrangement appears to bea promisingsome of the benefits of centralization. compromise solution that takes into account organization-

wide management concerns while allowing individuals andgroups sufficient autonomy in their modeling activities.

3.4 Design of Distributed MKBMS The basic idea is to partition the MKB into a collection ofloosely-coupled logical MKBs, each defining a distinct

The previous sections have outlined the pros and cons of administrative domain. There are three types of logicalalternative arrangements with regard to the physical MKBs: main, group, and private. These types differ inlocation, logical view, and control and administration of a terms of their access and manipulation rights and theMKBMS in a networked computing environment. In this extent to which integrity constraints are enforced. Ansection, an architecture for a distributed MKBMS capable organization's MKB would consist of a single instant of theof delivering the desired modeling support is presented and main logical MKB type and one or more instances of thethe rationale behind its design decisions are discussed. group and private logical MKB types.

The challenge is to find an arrangement for MKBMS that The main MKB is a centrally administered, organization-benefits from the networked computing environment, wide repository containing a relatively stable collection ofmeets user needs and provides them with an opportunity validated and verified models. While access limitationsto experiment, all without creating problems for manage- might be required, the main MKB has the least restrictivement control and modeling operations. Since these seem retrieval and execution rights and the most restrictive andto be conflicting objectives, there is no universal "best" elaborate storage and update procedures. Instances ofchoice among the combination of alternatives outlined models in the main MKB may be used as components inabove. Some alternatives, however, appear more attractive new composite models or executed by virtually any autho-than others. Since the actual physical location of the MKB rized user. A set of privileged users, perhaps through thecould be made transparent to the user, the choice among main MKB librarian, may check out model versions foralternative physical location arrangements could be update. Before the new version is checked back in, itchanged as needed based on performance and implementa- would undergo a rigorous sequence of validation andtion cost considerations. On the other hand, the choice of verification tests. Integrity constraints, particularly referen-a logical view and decisions on the control and administra- tial integrity, are strictly enforced by the system at alltion of the MKB must be informed by an understanding of times.the nature of the modeling environment, users' needs, andmanagement requirements. The issue of control and A group MKB provides a mechanism through which aadministration must be recognized as the most important collection of users (e.g., members of a functional area orone because of its influence over other issues; hence it will a project team) can share highly specialized, experimentalbe examined first. partially verified, or incomplete models. A group member

may deposit such models in the MKB, which can beCentralized administration of an MKB works fine for a executed or checked out by other members for browsingsingle user or a small group of users. Such an arrange- or update as authorized. An individual user may belongment, however, does not seem to be appropriate for large, to more than one group, each of which has a distinguisheddiverse groups of users. The reason stems from the fact member, called the group owner, who plays the role of thethat the process of modeling tends to be iterative and administrator for that group's MKB. Referential integritytentative in nature (Muhanna 1989b). This stands in sharp constraints are optionally enforced in group MKBs.contrast with database management, where only stablehistorical data are stored and later updated in response to A pn'vate MKB is created for an individual user whoevents. Furthermore, modeling tends to be an individual assumes complete administrative and control responsibi-or team activity that is function or project specific. lities over it. A private MKB contains private experimentalCentralized administration of the MKB may, because of models and/or copies of models checked out from thelack of flexibility or responsiveness, place a premium on main or a group MKB. The contents of a private MKBmodeling innovation and experimentation. Also, for are accessible only to its owner. Model types or versionspolitical reasons or security concerns, users may not be deposited in a private MKB need not be verified and mayinclined to share some of their models, particularly when reference instances that do not exist in the private MKB.they are experimental in nature. These conditions maycause users to avoid using the system at all or at least to Each user may define an ordered sequence of logicalcircumvent it by copying all of the required information to MKBs to be searched to satisfy his/her requests (e.g.,their local machines and then making the required changes. select models, resolve references in composite models toExtreme decentralization of control is no panacea either, their components). This sequence defines an aspect of the

236

run-time environment, called search path, for that user. provide support for distributed transaction managementFor example, a default search path might specify looking and distributed version management. Our decision to viewup the user'sprivate MKB first and, if the desired instance the MKB as a collection of independently managed logicalof a model type or version is not found, then an attempt MKBs may actually simplify these problems, particularlyis made to find it in the main MKB. A user can customize when we avoid replication. The reason is that the parti-his search path to be any desired sequence of MKBs tions of the physically distributed MKB are now loosely-he/she is authorized to access. The search path can coupled, since each of these partitions corresponds to aspecify the physical location of the various MKBs so that logical MKB.client programs running on behalf of the user can connectto the servers at those locations. Alternatively, the path The physical distribution of the various logical MKBs couldcould specify only the globally unique names of the various parallel the physical design of the underlying network.MKBs, whose location can be determined dynamically Many local·area networks today are designed around ausing a variety of means (e.g., global name server, broad- high-bandwidth backbone to which departmental subnetscast). Figure 5 illustrates the proposed architecture. are attached using bridges, gateways, or routers. Such

design is intended to provide for better traffic and failureNciw  blkbonc isolation. It also suggests a simple way for distributing the

MKB (Figure 5). The main logical MKB could be storedR.,cr/ Routed physically on a machine directly attached to the networkGatc-4 Gi.uy plin backbone, while servers for group and private MKBs could

     |  be placed on machines on the appropriate group subnets.MKO   ts/ %"Mh--- Sub,/1 1 C Sc. . ) Sut,%,2 T«-/1I l l 1 - (1

3.5 Other Issues

, 111] 1"mi hl   11'C=h'LEss=/ L=22=v Vfs Problems which are not particularly unique to distributedI n.MI* I

MKBproblems can be addressed in a manner similar to thoseMMSs include security and query optimization. These

I. .'. employed in distributed DBMSs. One problem, which isPri</ MKBs prie, MKBs perhaps more unique to model management, concerns

Figure i Distributed MKBMS Architecture change notification. Changes made to an MKB may havea ripple effect, requiring many actions. For example,updating a model version may affect the validity of other

The above arrangement attempts to strike a balance models that use an instance of it as a component. Suchbetween innovation and autonomy on the one hand and changes must be monitored and propagated in a controlleddiscipline and control on the other. Central control and manner. The creation of a new model version or theadministration are maintained over the main MKB, which deletion of an existing one are actions that could becontains models that are used and depended upon by the deemed worthy of announcement to interested parties.organization as a whole. Meanwhile, users are allowed tofully utilize the system facilities to manage their own sets In small Broups where members are in close proximity,of experimental models. The proliferation of private notification can occur during regular verbal communica-MKBs could be controlled by assigning the privilege of tion. In large groups whose members are spread outcreating a private MKB to the administrator of the main throughout the organization, some notification mechanismMKB. That administrator should also take an active role must be put in place to facilitate this process. A rule-in establishing codes for good modeling practices, promul- based notification mechanism has been proposed as partgating these codes, and coordinating the modeling activities of the activity manager in SYMMS and is describedthroughout the organization. elsewhere (Muhanna 1989c).

Having decided on an appropriate arrangement for control In the next section, we examine another dimension alongand on a logical view of the MKB, the choice of a physical which MMS distribution can occur.location can (and should) remain flexible since it can bemade transparent. Initially, the entire collection of logicalMKBs and the MKBMS server could both reside on some 4. DISTRIBUTED MODEL BUILDING ANDcentral machine. As the size of this collection grows or EXECUTIONwhen disk and network contention reach a certain thresh-old, the collection could be spread physically on multiple A principal objective of an MMS is to increase the produc-disks or partitioned and/or replicated across machines on tivity in organizational modeling and decision-makingthe network. activities. It must therefore provide concepts and tech-

niques to enhance the efficiency of both model develop-As described in Section 3.1, physical distribution of the ment and model experimentation processes. As describedMKB greatly complicates the implementation since it must in Section 2, the systems framework for model manage-

237

ment supports the notions of reusable components and by first identifying and then exploiting inherent parallelismsuggests agraphical, non-procedural, hierarchical approach (i. e, potential for concurrent execution) in the activities ofto the construction of composite models, both of which can model compilation and execution. To this end, the systemssignificantly reduce the time it takes to develop a model. framework for model management as implemented in

SYMMS is particularly appropriate for a distributedOnce developed and validated, however, a model is then computing environment. There are two basic reasonsused to support decision making. This process of model behind this.experimentation is invariably time-consuming because it isoften repetitive (when there are multiple scenarios to be First, the framework draws a clear distinction betweentested) and computationally intensive, particularly when "modeling in the small" and "modeling in the large,"large simulation or combinatorial (e.g., integer or non- (Muhanna 1987), which allows both small-grain as well aslinear programming) models are involved. Speeding up the large-grain parallelism to be identified and exploited.model experimentation process can contribute to meeting Atomic models are implemented using a conventionalan important objective of MMSs, namely, increasing the programming language (e.g., Modula-2) augmented withproductivity of model builders and users. A distributed message passing primitives. Special programming lan-computing environment has the potential of making such guages and/or parallelizing compilers can also be used tospeedups a reality. exploit small-grain parallelism (i.e., at the level of the

instruction or function) in atomic models or their solversOne obvious virtue of networking in a distributed comput- whenever SIMD (vector) or shared-memory MIMD pro-ing environment is that applications are no longer re- cessors are available. The configuration component ofstricted to using only those resources located on the local MDL is used to hierarchically structure instances of atomicsystem. Now they can, in principle, transparently use models into composite models. When expressed directlyresources located throughout the network. These re- in terms of its constituent instances of atomic models (i.e.,sources can be centralized MKBMS servers, as described when the composition hierarchy is flattened), the configu-in Section 3, as well as raw computing power available on ration of a composite model is basically a graph, whosethe various machines on the network. This means that nodes represent the instances of the atomic models andcomputationally intensive tasks, such as model compilation, arcs represent the inter-communication (dependency)linking, and execution, could be done in parallel by structure between them. This graph defines a partialdistributing the work across multiple machines on the ordering of the atomic instances (assuming it is acyclic)network. and displays large-grain parallelism (i.e., at the level of one

or more component instances of atomic models) that canA common computing environment consists of many work- be exploited. These grains can be downloaded to multiplestations connected together by a high-speed local area remote machines for concurrent execution, providingnetwork. When viewed as an aggregate, these workstations higher performance for users and better utilization ofrepresent a significant computing resource. This resource, computing resources throughout the network.however, is often underutilized because the workstationsusually serve as personal computers and are frequently A second reason why the systems framework for MM isidle. The ability to distribute computational tasks could particularly suited to a distributed environment lies in thegreatly enhance the utilization of such systems. An data-flow paradigm it embodies at the macro level.effective DMMS should allow users to tap into the enor- Instances of atomic models are highly encapsulated entitiesmous computing power available on the network. Users which communicate by making references to local portsshould be able to develop models locally and compile and and not to other instances, machines, or communicationexecute them on remote machines (whether they are channels. Furthermore, communication between instancesworkstations, mainframes, or supercomputers) that offer running on the same or on different machines is effectedthe optimal performance and characteristic for the models. un(fonnly via message passing. Message passing is theTo make this transparent to the user, the DMMS should natural mechanism for communication across a network.hide the details of the network communication and remote Techniques for exchanging data (e.g., common blocks andexecution and offer seamless integration of the (hetero- standard procedure calls) which have been developed forgeneous) distributed computing environment. Model single or multiprocessor systems are not suitable for thisdevelopers would therefore concentrate on the task of environment because they are based on the notion ofmodel conceptualization and formulation, not on writing shared-memory, which is not readily available in a distrib-distributed programs or keeping track of the static and uted computing system.dynamic characteristics of the machines and the network.This translates into better utilization of the network-wide The notions of encapsulation, composition via couplingresources, increased portability of models' codes, and and message passing are very useful concepts to capitalizeenhanced modeler/decision-maker productivity. on in achieving distributed model execution. A task is an

execution of an instance of atomic model, i.e., it is the run-A major goal in developing DMMS is therefore to benefit time realization of that instance. When a request tofrom the availability of multiple processors on the network execute a composite model is submitted to SYMMS, the

238

system first flattens the model's composition hierarchy. A two-phased scheduling heuristic proposed in MuhannaThe flattened composition represents the composite model and Pirkul suggests an intermediate approach in which thein terms of its ultimate components, i.e., as a network of first phase, which depends only on the characteristics of theinteracting instances of atomic models. This network is task graph and not on those of underlying computingrealized by means of an isomorphic network (called a task systems, can be done statically, while the second phase isgraph) of communicating tasks, where one-way communi- performed dynamically on demand. In addition, a dynami-cation channels interconnect those tasks and buffer their cally generated schedule can be cached and discarded whenoutput. the system conditions assumed during its generation

change.In a distributed implementation of SYMMS, a critical issueis how to efectived exploit inherent parallelism in a given Executing a given task graph schedule requires the imple-task graph and benefit from the availability of parallel mentation of mechanisms to (1) locate and allocatehardware. In particular, four broad problems must be physical processors, (2) compile, link, and load executableaddressed: images, and (3) effect communication and synchronization

between tasks executing on the same or different machines.(1) Task Graph Characterization - determining execution SYMMS already has these mechanisms implemented for

times of each task as well as the frequency and amount a computing system consisting of a single machine. Aof communication between tasks in a task graph. description of these mechanisms can be found in Muhanna

(1989c). What is needed is an extension on these mecha-(2) Task Graph Sched,iling - assignment of tasks to nisms to permit distributed compilation and execution.

(logical) processors and local CPU scheduling of Such extensions should be made in such a way so as toindividual tasks for maximum global performance. insulate the user from distributed application design. From

the user's point of view, the distributed environment should(3) Ii,ipkilieittation - building mechanisms to (a) locate be transparent, appearing as uniform as a traditional

and allocate physical processors, (b) build and load uniprocessor.executable images, and (c) effect communication andsynchronization between tasks executing on the sameor on different machines. It turns out that making the extensions necessary to realize

the above objective is, while complicated and laborious,(4) Support for heterogeneous machines - a new dimen- made technically possible by (1) the latest advances in

sion of complexity to the above problems. networking standards, tools, and utilities and (2) thefeatures inherent in the systems framework for model

Of the above four problems, the last two will be examined management. A brief description of these extensions isnext. The first two issues are investigated in Muhanna provided next.(1989a) and Muhanna and Pirkul (1990), respectively, andwill not be addressed here. Suffice it to say, however, thatone can obtain estimates for parameters of the task graph To keep track of the status of machines on the network,through sample executions and under certain assumptions coordinate the allocation of processors, and enforce accessthrough basic syntactic analysis. Also, the problem of task privileges, a reservation executive is needed. This reserva-graph scheduling turns out to be NP-hard, if one insists on tion agent is not necessarily part of the distributed MMS,an optimal assignment. Surprisingly, very little research since applications other than the MMS compete for thehas been done to solve this particular class of scheduling same resources. Various facts about machines on theproblems. A heuristic scheduling algorithm has been network are kept by the reservation executive. Machinesdeveloped, a description of which is presented in Muhanna could then be chosen on the basis of a number of criteriaand Pirkul. such as idle time percentage over a certain time interval,

hardware and software configuration, and even administra-4.1 Implementation Issues tive factors such as ownership and cost accounting.

Periodically, machines broadcast their status to update theAn effective distributed MMS must exploit the availability dynamic portion of the information maintained about themof parallel hardware to speed up the compilation, linking, by the reservation executive. This part should be relativelyand execution of composite models. To this end, a number easy to implement. The difficulty lies in providing reliableof implementation issues must be addressed. First, a and efficient coordinated allocation of processors acrossdecision must be made as to whether scheduling task the network. For a lightly loaded environment, coordina-graphs should be done statically (perhaps when the model tion is not critical and independent allocation could beis stored) or dynamically (on the fly just before execution). made at each node on the basis of recent status informa-Early static scheduling is more efficient but less flexible. tion broadcasted by other nodes. We have opted for thisLate dynamic scheduling can yield schedules that reflect latter approach for the time being, since a network-widebetter the dynamic nature of the computing environment coordinated reservationsmechanismmay notbesufficiently(e.g., processors' availability and load). efficient for it to be useful in this context.

239

Also planned is a mechanism to compile, link, and load 4.2 Support for a Heterogeneous Environmentexecutable images to run on the assigned processors.Under the current implementation of SYMMS, when given Most networked computing environments contain a varietya task graph (generated by an automatic flattening process of machines (with different hardware architecture orof the composition scheme) to run, the system first speed) and operating systems types. It is also often thesearches an Object Code Cache for object modules case that certain model solvers are constrained to run oncorresponding to each atomic component. If none is a particular hardware and software configuration forfound, the relevant source code modules are extracted technical, licensing, or availability reasons. A distributedfrom the MKB, compiled, stored in the cache, linked, and MMS must therefore provide support for such heteroge-dynamically loaded as coroutines in a single UNIX process. neous environments in order to maximize the network-Finally, each task is instantiated from its corresponding wide sharing and utilization of resources.coroutine template as a lightweight process. Run-timescheduling and inter-task communication are supported by Invariably, the problems described earlier are intensifieda run-time kernel. by the presence of dissimilar machines on the network.

Both the formulation and solution of the task graphscheduling problem are more difficult in this context. Also,

In a distributed environment where multiple machines are the difficulty of the system implementation is increased byavailable, parallelism can occur not just at execution time at least an order of magnitude. In fact, the implementationbut also at the compilation and loading time. Concurrent would be prohibitively expensive had it not been for thecompilation and loading of modules can dramaticallyspeed availability of a common set of standard communicationup the start of model execution and thus greatly improve protocols, tools, and utilities which can be used to build athe user's productivity. To support this capability, the messagingplatform that transparently integrates the myriadMES of SYMMS is being modified to run as a server on of multi-vendor machines.each of the nodes on the network. An MES server runningon one machine becomes a client to other MES serversrunning on remote machines, accepting requests to However, a common communication protocol is notcompile, link, and load subsets of task graphs on their enough to support inter-task communication acrossbehalf. The basic idea is that once a schedule for a task different machines. The reason is that different machinegraph is generated by the local MES, requests to load (and families (e.g., VAX versus Sun) have different bytecompile if necessary) subsets of that task graph are sent to ordering and data representation schemes. Hence, onethe machines to which those subsets were assigned. The problem, which is unique to a heterogeneous environment,task graph subset is loaded as a single process with distinct is that messages between machines must conform to thethreads of control for each task. Each process (task graph way data is represented on the destination machine. To dosubset) registers its unconnected ports with a connection this, we plan to use the External Data Representationserver. The connection server allows two independently (XDR) (Sun Microsystems 198D as a common scheme.started processes to connect their ports (i.e., rendezvous) Before sending a message across the network, the sendusing mutually agreed upon names. The run-time kernel routines, which are part of the run-time kernel, encode thein each process establishes connections to remote counter- message data using XDR as the common data representa-parts with which it needs to communicate. tion standard. The destination run-time kernel then

transforms the message to its local data representationscheme. These transformations are to be made only if the

Finally, the SYMMS run-time kernel is being extended to send and receive machines use different data representa-support inter-task communication between tasks running tion schemes.(1) on the same machine and (2) on different machines.The former is already supported in SYMMS throughshared-memory and semaphores. Messages destined for 5. CONCLUSION AND IMPLEMENTATION STATUSremote tasks are trapped by the kernel, framed, and passedto the operating system's IPC mechanism (e.g., Berkeley In this paper, we proposed extending the concept of anUNIX sockets) for network delivery. No modification to MMS to function within and exploit the capabilities of athe task source code is needed for communication with networked distributed computing environment. A numberremote tasks to occur. The reason is that tasks perform of MMS research issues are either peculiar to or intensi-read and write operations to their own ports; there is no fied by the presence of multiple machines. To facilitatedirect naming to communication channels or reference to their examination, a framework for research in Distributedother tasks. The complexity of the communication MMS (DMMS) was discussed. In this framework, distribu-mechanism is hidden by the software in the kernel layer, tion of MMS functions can occur along two principalwhich furnishes a uniform interface for communication dimensions: distributed model-base management andbetween local as well as remote tasks. distributed model building and execution.

NO

Along the first dimension, we examined issues related to BSD UNIX, whose basic IPC and networking primitivesthe physical location, logical view, control, and administra- are being extensively used in the implementation. Concur-tion of the MKB in a distributed computing environment. rently being developed is a graphical interface for browsingAn architecture which centers around the issue of adminis- and composite-model construction. The goal is to obtaintration and control was presented. In it, the distributed a distributed MMS which forms a coherent MM environ-MKB consists of one main MKB and a collection ofgroup ment in which the entire network and its resources act asand private logical MKBs. This arrangement attempts to a simple and powerful extension of the user's personalstrike a balance between innovation and autonomy on the workstation. This should translate into better utilization ofone hand and discipline and control on the other. Actual the network-wide resources and enhanced modeler/deci-physical distribution (through partitioning, replication, or sion-maker productivity.both) of each logical MKB could occur by carefullybalancing the cost of implementation and the benefit of 6. REFERENCESincreased performance and availability. Each logical MKBis managed by an MKB server, which provides access and Applegate, L. M.; Klien, G.; Konsynski, B. R.; and Nuna-manipulation services to local and remote MCS and MES maker, J. F. "Model Management Systems: Proposedclients. Model Representations and Future Designs." Proceedings

of the Sixth International Conference on InformationThe second dimension of research concerns the develop- Systems, San Diego, December 1985, pp. 1-16.ment of techniques to exploit the networked environmentby using multiple processors to speed up the compilation, Bernstein, P. A., and Goodman, N. "Concurrency Controlloading, and execution of models. To this end, we have in Distributed Database Systems.' ACM Computing Sur-found that the systems framework for MM is particularly veys, Volume 13, Number 2, June 1981, pp. 185-221.appropriate, making our prototype MMS, SYMMS, ideallysuited for extension to support distributed model building Dowdy, L. W., and Foster, D. V. "Comparative Models ofand execution. Modularity, loose coupling, and message the File Assignment Problem." ACM Computing Surveys,passing are salient characteristics of a distributed system. Volume 14, Number 2, June 1982, pp. 287-313.These characteristics are basic to the systems frameworkthrough the notions of model types, composite and atomic Enslow, P. H. "What is a Distributed Data Processingversions, and coupling ports through links. System?" IEEE Computer, Volume 11, Number 1, January

1978, pp. 13-21.In supporting distributed execution, a critical issue is howto effectively exploit inherent parallelism in a given task Eswaran, K P. "Placement of Records in a File and Filegraph representing a configuration of a composite model. Allocation in a Computer Network." Infomiation Pio-Three problems were identified: task graph characteriza- cessing 74, IFIPS, August 1974, pp. 304-307.tion, task graph scheduling, and implementation. Wefound that we can obtain estimates for parameters of the Hammer, M. M., and Shipman, D. W. "Reliability Mecha-task graph through sample executions and, under certain nism for SDD-1: A System for Distributed Databases."assumptions, through basic syntactic analysis. The problem ACM Transactions on Database Systems, Volume 5,of task graph scheduling turns out to be NP-hard, if one Number 4, December 1980, pp. 431-466.insists on an optimal assignment. It was noted that verylittle research has been done to solve this particular class Holsapple, C. W., and Whinston, A. B. "Model Manage-of scheduling problems. A heuristic scheduling algorithm ment Issues and Directions." Working Paper No. 7,has been developed, details of which are presented in Department of Decision Science and Information Systems,Muhanna and Pirkul (1990). Finally, a number of imple- University of Kentucky, November 1988.mentation problems and solutions were described forsupporting distributed build and execution in both homoge- King, J. L. "Centralized Versus Decentralized Computing:ncous and heterogeneous computing environments. Organizational Considerations and Management Options."

ACM Computing Surveys, Volume 15, Number 4, Decem-The list of problems described in this paper is by no means ber 1983, pp. 319-349.exhaustive. Much work remains to be done in identifyingnew issues and enhancing proposed solutions to existing Lindsay, B. G.; Hass, L. M.; Mohan, C.; Wilms; P.F.; andones. Much insight could also be obtained through further Yost, R. A. "Computation and Communication in R': Aanalysis and user input to see how a DMMS could be Distributed Database Manager: ACM Transactions ondesigned to more effectively support modeling activities in Computer Systems, Volume 2, Number 1, February 1984.an organization. A prototype system provides the meansto test these ideas in practice. To this end, we are imple- Morgan, H. L., and Levin, K. D. "A Dynamic Optimiza-menting the ideas by extending SYMMS to run in an tion Model for Distributed Databases." Operationsenvironment consisting of a number of VAX and SUN Reseamh, Volume26, Number 5, September-October 1978,workstations. All machines run derivatives of Berkeley pp. 824-835.

241

Muhanna, W. A. A Systems Framework for Model Reed, D. P. "Implementing Atomic Actions on Decentral-Manageme,it in O,ganizations. Unpublished Ph.D. Thesis, ized Data.- ACM Transactions on Computer Systems,University of Wisconsin-Madison, December 1987. Volume 1, Number 1, February 1983, pp. 3-23.

Muhanna, W. A. "Composite Programs: Hierarchical Stonebraker, M. "Concurrency Control and Consistency ofConstruction, Circularity, and Deadlocks: IEEE Multiple Copies of Data in Distributed INGRES." IEEETransactions on Software Engineering, 1989a. Transactions on Software Engineering, Volume SE-5,

Number 3, May 1979, pp. 188-194.Muhanna, W. A. "On the Organization of Large SharedModel Bases." Working Paper, The Ohio State University, Sun Microsystems, Inc. "XDR: External Data Representa-1989b. tion Standard." RFC-1014, June 1987.

Muhanna, W. A. "SYMMS: Design and Implementation Wah, B. J. "File Placement on Distributed ComputerNotes." Working Paper, The Ohio State University, 1989c. Systems." IEEE Computer, Volume 17, Number 1,

January 1984, pp. 23-32.Muhanna, W. A., and Pick, R. A. 'Composite Models inSYMMS: Proceedings oftile Twenty-First Annual Hawaii Walsh, D.; Lyon, R.; and Sager, G. "Overview of the SunInternational Conference on System Sciences, January Network File System: Proceedings of the Winter Usenir1988, pp. 418-427. Conference, 1985, pp. 117-124.

Muhanna, W. A., and Pirkul, H. "Heuristic Algorithms for Will, H. J. "Model Management Systems." In E. GrochlaScheduling Task Graphs in Distributed Systems." and N. Szyperski (eds.), Infonnation Systems and Omani-Working Paper (in preparation), The Ohio State Univer- zation Stmcmre, Berlin: Walter de Gruyter, 1975, pp.467-sity, 1990. 482.

242