tion systems and describe three designs of an accident management system called FRIEND developed at Carnegie Mellon University. We concentrate on how ...
In Proceedings of the Second International Conference on Cooperative Information Systems, Toronto Press, May 1994.
Design Considerations for an Accident Management System Research Paper Bernd Bruegge, Kevin O’Toole, and David Rothenberger Carnegie Mellon University School of Computer Science Pittsburgh, PA 15213
Abstract Effective accident management requires the organization of large amounts of information. This information consists of reference information which rarely changes during an accident and decision support information which changes very rapidly. Much of the rapidly changing information is a result of collaboration between accident response personnel. In this paper we discuss accident management systems as instances of cooperative information systems and describe three designs of an accident management system called FRIEND developed at Carnegie Mellon University. We concentrate on how each design handles the rapidly changing information with different notification mechanisms to support the collaboration between end users. We identify two specific types of architectures, distributed state and stateless, and conclude with a general discussion of architectures supporting cooperative information systems.
1
Introduction
The wealth of information government service providers possess is invaluable during emergencies. Our communities deserve the best possible use of this information to ensure safety or reduce risk to the population. Unfortunately most local government procedures are established on “normal” or expected call loads. When an unusual event or multiple events occur the procedure quickly becomes overloaded. Information held by individual service providers is not adequately disseminated for informed decision making. City planning, fire, This project was sponsored in part by the Division of Undergraduate Education, National Science Foundation Grant Number USE-92511836 and in part by a research grant from Bell Communications Research to Carnegie Mellon University's Information Networking Institute
police, emergency medical services (EMS), administrative, public works, and building inspection departments compile seemingly unlimited amounts of information. This information is usually stored on paper or in a specialized computer application. This combination of volume and lack of organization makes the information extremely hard to use during an emergency. Consequently, it is rarely used. The First Responder Interactive Emergency Navigational Database (FRIEND) system is being developed to help manage the enormous amounts of information involved with accident management [1]. FRIEND supports several classes of users including first responders (workers in the field), field supervisors, dispatchers, and resource allocators. These users collaborate with the help of FRIEND to manage the information associated with an accident or accidents, including resource information, tasks and actions taken in response to an accident, geographical information, Emergency Operations Plan (EOP) information, and hazardous materials information. This paper motivates, develops, and describes architectures for the provision of distributed, shared information, which is an important component of accident management. Section 2 presents our assumptions about Cooperative Information Systems (CIS) and explains why FRIEND is an example of a CIS, highlighting those aspects of FRIEND which make its design and implementation challenging. Section 3 classifies the information managed by FRIEND and Section 4 compares the requirements of information management in FRIEND with those of distributed files systems. Section 5 contains a discussion of three existing design alternatives, concentrating on the notification mechanisms used to implement active databases. A general discussion of notification mechanisms appears in Section 6. Section 7 presents our plans for future work and Section 8 describes our conclusions.
2
FRIEND as a Cooperative Information System
FRIEND has several requirements in common with traditional information systems like WorldWide Web [2] and Gopher [14]. FRIEND provides lookup services for information about emergency and standard operating procedures and hazardous materials. There are, however, several kinds of information services which FRIEND provides that distinguish it from these more traditional systems. During an accident, decisions about resource allocations must be made quickly and correctly. These decisions are made in response to the rapidly changing needs of current accidents and they require a large amount of collaboration between accident management personnel. Workers at the scene of the accident and resource allocators located at an Emergency Operations Center must work together to identify the needs of each accident and ensure that the available resources are allocated efficiently. This cooperative decision making requires a large amount of communication and shared information. In a cooperative information system, multiple users view and modify a shared set of data. The users may access the data simultaneously or serially. We believe this shared use of a common set of data by multiple users or systems is a defining feature of CISs. Furthermore, in some CIS applications it is important that all users view the most recent data in the shared set at all times. The large amount of collaboration between FRIEND users, who view and modify a common set of rapidly changing data, distinguishes FRIEND as a cooperative information system and makes its design and implementation challenging. Several other factors specific to the domain of accident management further complicate the design problem. It is the nature of accidents that the collaborative communication often occurs in bursts of activity. Large amounts of communication occur at the beginning of an accident and at other crucial points during its management. Once resource needs have been identified and the situation of the accident has stabilized, communication slows as workers concentrate on performing their tasks rather than planning them. The mobility required by accident management personnel requires FRIEND to employ state-of-theart wireless communication technology. Current wireless networks have bandwidth limitations which are very restrictive when compared to modern local area networks. Wireless networks are generally at least an order of magnitude slower than
their wired counterparts. Further, wireless connections are subject to signal degradation caused by tunnels and other environmental factors. This combination of communication characteristics and unreliable communication medium makes FRIEND an extremely challenging shared information problem at many different levels. The characteristics mentioned above require FRIEND to utilize results from five different research areas: information management, communication protocol research, resource allocation and scheduling under real-time constraints, and disconnected operation. Many research efforts in these areas are currently underway [5][16][23][24]. Disconnected operation, for example, is investigated in the CODA project [13][20] at Carnegie Mellon University. Some of the scheduling issues in crisis management systems are described in [4]. This paper concentrates on the information management aspect, specifically distribution and maintenance of dynamic, shared information.
3
Data Classification for Cooperative Information Systems
The primary purpose of FRIEND is to provide users concurrent access to a set of shared information. In this way, it is similar to ordinary information systems. One requirement that separates FRIEND from traditional information systems is that concurrent users must see changes to the data as quickly as possible. This requirement is further complicated by the fact that information about active accidents changes very rapidly. A final consideration is that the data utilized by FRIEND is often owned by geographically distributed organizations, each maintaining its own databases on site. The first two requirements, rapid change in the data and user awareness of the change, necessitate an understanding of the types of data which FRIEND must manage. Towards this end, we have classified the data according to two criteria: whether it is critical that all users view the most recent changes at all times and whether the data will change rapidly. Figure 1 shows this classification in OMT notation [17]. Examples of dynamic, time-critical information include information about current accidents being managed, resource information such as available resources, resources allocated to accidents, and current location of resources, and task information such as requests made and the actions taken to satisfy those requests. Examples of stable, time-critical information are contact information such as the phone numbers of
Data
Time-critical
Dynamic
Non-time-critical
Stable
Figure 1 : Classification of Data in the FRIEND system important people involved with the management of the accident and building contents including hazardous materials and people. Changes to non-timecritical data are not critical to the management of the accident. It is permissible for users to (temporarily) view out-of-date information. Examples include street names, certain hazardous material information and some information about emergency and standard operating procedures.
4
Comparisons to Distributed File Systems
We have argued that an important component of FRIEND is the sharing of a dynamic data structure. The management of this data structure requires any design of FRIEND to address many of the same issues that are addressed in the design of a multiuser distributed file system [9][18]. These common issues include: • File system clients must maintain a consistent view of the file system and dynamic data clients must maintain a consistent view of the dynamic data. • A change by one client must be made available to other clients as soon as possible given communications delays. • Two clients accessing the same data must have some exclusion rules. In the case of a distributed file system, the exclusion rule may be as simple as “last write wins.” • Small changes to large data files or objects must be propagated to clients efficiently. For example, this might be done by communicating a proper subset of the file or object containing the change. While these similarities to shared file provision
allow us to draw on knowledge gained from the exploration of distributed filesystems, there are significant differences which separate dynamic data structures from distributed files. The first is that the objects in a dynamic data structure must be rapidly traversable. For instance, information displayed in the user interface must be traversable in rapid succession for updates. Files are not intended to be traversed rapidly, so the delay incurred by going across a network to fetch the data is annoying, but not mission critical. The delay incurred in waiting to access a data structure can endanger the application’s ability to function. For example, if FRIEND’s dynamic data provision is too slow, an incident added to the system may take too long to be displayed. This delay will surface in the application as a failure to meet client specifications. A further issue is that most distributed file systems are built around data similar to those presented in studies by Satyanarayanan [19] and Ousterhout [15]. These studies show that most file system access patterns contain many more reads than writes. This may not be true in the case of dynamic data. Data in an emergency management application may be written with greater frequency. This has implications for the effectiveness of caching. If the number of reads and writes are closer to being equal, the client will be retrieving information from the server more often, thus raising overhead. Changes to a file system do not affect the view the user has of the data until the user queries the file system for the data again. In an application domain like accident management, however, the user must be aware of changes to the data as they occur. This demands a faster response on the part of the system and means that the underlying architecture must be able to notify the application when something has changed. The application must be able to update the user’s display quickly. In a large dynamic data structure, the message “Something changed” is not very useful. The change notice must specify what object has changed and in what way, otherwise the data retrieval burden of all the clients retraversing the data structures will most likely overwhelm both the wireless network and the server.
5
Design Alternatives for Notification
The focus of this paper is on architectures for the support of distributed shared data. Specifically, three alternative designs are addressed. Each design addresses the notification issues of active databases with respect to the design goals presented above. Each design was created as an academic effort by undergraduate and graduate students at Carnegie Mellon University. A more complete description of
the FRIEND system can be found in [6][6][11]. 5.1 The Design of FRIEND I The FRIEND I subsystem decomposition includes an application domain subsystem, a user interface subsystem, an application control subsystem, a database subsystem, and a communication subsystem. Figure 2 shows these subsystems and the communication between them. Each arrow in the figure represents one or more procedure calls or messages. Application Domain
User Interface
Application Control Object Store
Communication
Database Figure 2 : FRIEND I Subsystem Decomposition The Application Domain subsystem consists of several modules such as an interface to the Emergency Operations Plan (EOP), an interface to a digitized street map, a “whiteboard” maintaining the active incidents, a regional information module providing information about building floor plans and building contents, and a book information module providing access to textual information such as hazardous material safety information and important phone numbers. The Database subsystem consists of multiple database servers which provide a persistent store for the application domain subsystem. Each object stored in the database is assigned an identifier which is unique throughout the entire system. In addition to providing data management services, the database subsystem also actively notifies its clients when data changes. Each database server maintains a list of its clients and the objects they have requested. Whenever an object is changed, the database notifies these clients that a change occurred. The Communication subsystem encapsulates the
network communication. In addition to encapsulating physical channels, it provides naming services for database servers. Servers are named by the set of objects they contain, allowing the database subsystem to route queries to the appropriate servers transparently. This mapping is dynamic; at start-up time each server indicates the names of all the sets of objects it serves. The Application Control subsystem provides an interface between the application domain, user interface, and database subsystems. It is responsible for maintaining a mapping between the information displayed in the user interface and the objects in the database and for updating the user interface in response to change notifications from the database. It also manages a client-side cache of the data from the database subsystem. The application domain subsystem interacts with the database subsystem through the Object Store. The application domain subsystem passes the identifier of an object to the Object Store and is returned a memory pointer to the requested object. If the Object Store does not have the requested object cached or if the database subsystem has sent a notification that the object has been changed since it was cached, it is retrieved from the appropriate database server. The application control subsystem integrates the database subsystem with the notification mechanism to provide an active database. This has good and bad results. It succeeds in freeing the application domain subsystem from explicitly propagating notifications. However, it causes two problems. The first is that we had to design and implement our own database subsystem in order to encapsulate it. The design and implementation used is not complete; specifically, it lacks concurrency control and transaction management. The second problem is related to the Object Store. Application modules are required to distinguish between distributed objects which come from a database server and locally owned objects which do not. To manipulate a distributed object, an application module has to acquire a memory pointer to the object using the Object Store, manipulate the object through the memory pointer, and return the pointer to the changed object to the Object Store so that the changes can be sent to the database. If an application module either forgets to notify the Object Store of changes made to an object or uses an out-of-data memory pointer to an object in the database, the state of the client and the database servers can become inconsistent. This is even worse because the manipulation of local objects (such as computation results) is done as usual; this requires the application modules to distinguish between locally
owned objects and objects which come from a database server. The application control subsystem also provides a centralized mechanism for updating the user interface in response to a change in the database. Although this frees the application modules from handling change notifications, the generality of this mechanism greatly complicates its design and implementation. We learned one important lesson from our experience with FRIEND I, namely that providing a centralized mechanism for user interface updates in response to changes in the database can over-complicate the design and implementation of the system. 5.2 The Design of FRIEND II The FRIEND II design was heavily influenced by the Distributed Objects facility in the NeXTSTEP programming environment [8]. This facility provides access to objects located in another address space in a transparent manner through Remote Procedure Calls (RPC). This facility eased the implementation of FRIEND II [11][12]. The decomposition of FRIEND II differs from the FRIEND I decomposition described above. The system is decomposed into a set of applications and
Whiteboard Server
database servers organized in a series of clientserver architectures. The client applications of FRIEND II are essentially the modules in the application domain subsystem from the FRIEND I design. Each of these clients has an associated server process which maintains the related data. Figure 3 shows the interaction between the clients applications and the database servers. Each arrow represents data flow. In FRIEND II, most computation is done at the servers. Objects at the server are manipulated through RPC-based proxies. Each server-based object has a local proxy object which encapsulates the client-server communication. The proxy has the same interface as its server-based counterpart but does not do any computation. Instead, it forwards all operations to the object at the server using RPC. This use of proxy objects allows developers to treat distributed and local objects identically. Change notification is handled much differently in FRIEND II than it was in FRIEND I. In FRIEND II, no data is cached in the client processes. Objects are only maintained at the server which is responsible for that given type of data. When an object at the server changes, the client processes are simply notified that “some object” has changed in the data structure at which time each client redraws the
Resource Location Information
Map Client
IRA and Resource Information
Whiteboard Client
Map Server
Building and Floor Information
Map Client
Report Server
Report Information
Report Client
EOP Server
EOP Information
EOP Client
Book Server
Book entries, Book indices
Book Client
FRIENDgram Server
FRIENDgrams
FRIENDgram Client
Figure 3 : FRIEND II Client-Server IPC screen
to
reflect
the
new
state
of
the
distributed,
shared
objects.
It should be noted that FRIEND II makes use of the data classifications shown in Figure 1. The active notification process takes place only in the Whiteboard Server where time-critical, dynamic data resides. The other server processes treat data as static and do not propagate change notices to the client processes. Given the high volume of data stored at these other servers and the infrequency of change, it is believed that the risk of someone viewing incorrect information is so minimal that supporting a notification mechanism is not justified. This has the benefit of lowering network traffic to clients across the slow wireless network and reducing the overall complexity of the system. We believe the FRIEND II design is simpler than the FRIEND I design because of its use of distributed objects. For example, the server-based computation approach allows the centralization of control, and by making the server processes single threaded, there are no mutual exclusion issues. Also, the ability for programmers to use local and remote objects identically simplifies the decomposition of the system and allows the concurrent development of the individual subsystems. The FRIEND II design also reveals many problems with server-based computation. Despite attempts to limit network traffic and server accesses, servers quickly become over-run with requests; the system can only handle seven clients before delays become unacceptable. Also, the extensive use of servers makes the system less robust as the failure of one server can prevent all clients from doing any useful work. While both the performance and reliability problems could be addressed by replicating servers, doing so would destroy the simplicity of the design, which is its major advantage over that of FRIEND I. 5.3 The Design of FRIEND III FRIEND III is our third and most recent design [6]. The FRIEND III design consists of an application subsystem, a user interface subsystem, an input subsystem, a communications subsystem, a database subsystem, and a notification subsystem and is shown in Figure 4. The FRIEND III Application subsystem is similar to the one from the FRIEND I design and the FRIEND II design and will not, therefore, be detailed. The Input subsystem is a new component providing multi-modal user input facilities such as speech and gesture recognition. The Communication subsystem of FRIEND III is very similar to that of the FRIEND I design, using a name server to provide a mapping between users’ names and their host machines. Unlike the FRIEND
User Interface
Input
Application
Notification
Communication
Database
Figure 4 : FRIEND III Subsystem Decomposition I design, however, this name server is not used to provide location-transparent access to a collection of database servers; the FRIEND III design provides for only one database server which is shared by all users. The Database subsystem provides access to a single database server. In the current implementation of FRIEND III, this service is provided by the object-oriented database management system (OODBMS) EXODUS [3]. EXODUS is tightly coupled with the C++ language, making it difficult to encapsulate or integrate the database subsystem with the notification subsystem. Therefore, it must be left to the application subsystem to register for the notifications necessary to keep the user interface up-to-date and to inform the notification subsystem when a change is made to the database. The design of FRIEND III has both advantages and disadvantages compared to that of FRIEND I. A major advantage of the FRIEND III design is the decentralization of the consistency maintenance mechanism for the user interface. In the FRIEND I design, this mechanism is centralized in the application control subsystem and is, therefore, too general and over-complicated (because it must meet the needs of all the application modules). In FRIEND III, each individual application module is responsible for keeping its part of the user interface up-todate with respect to the database. While this increases the dependencies between the notification mechanism and the application subsystem, it also simplifies the consistency maintenance mechanism. A major disadvantage of the FRIEND III design is the separation of the database subsystem and the
notification mechanism. Ideally, these would be combined in a robust active database system. Our solution, combining EXODUS, a non-active OODBMS, with a separate notification mechanism, requires the individual application modules to explicitly indicate to the notification mechanism when they change an object in the database.
6
Towards a General Topology for Notification Systems
We have discussed three existing software architectures for the FRIEND system. The presentation of each design has concentrated on how changes in the database are propagated to all interested parties. This section will attempt to generalize the approaches used as well as some other design alternatives that were not employed. In comparing the different architectures, the notation shown in Figure 5 will be used. There are two types of associations
A Process
A Data Source or Sink
Static association
One-directional dynamic association Bidirectional dynamic association Figure 5 : Legend for Architecture Comparisons between objects (processes or data sources): Associations denoting static relationships and associations denoting dynamic relationships. Static associations are relations that exist over a longer period between two objects. Two examples are the acquaintance association, in which an object holds a reference to another object, and the consists-of association, in which an object is composed of one or more other objects. Dynamic associations are relations between two objects which merely send messages and data to each other [10].
6.1 Distributed Information Architectures There are several architectures that can be used to support the distribution and maintenance of dynamic data. The basis of dynamic data provision is that processes accessing the data must have a way of discovering changes to the data structure in a predictable manner. Simply traversing the data structure continually is not desirable. Figure 6 shows a class hierarchy of architectures for data distribution using the OMT notation. The rightmost branch of the hierarchy (Look Up Architectures) is for stable data distribution. The leftmost branch, the focus of this paper, deals with dynamic data distribution. A Subscription Architecture involves a client registering for access to a set of changing data. The two main subclasses of subscription architectures are Polling, where clients query servers at regular intervals to obtain any changes to the shared data, and Notification, where clients register with servers to receive notifications about changes to shared data. Figure 6 depicts two subclasses of the notificashared dynamic data at the server. Clients keep local copies of the data used in their computations. When a change is made to the data the server notifies the clients of the change. The server may include the changed data with the notification or it may simply notify the client of a change to the data structure, and the client will fetch the changed data as need demands. Figure 7 depicts the distributed state approach. In the stateless architecture, the clients do not maintain local copies of the data. All the data is stored only at the server. An important aspect of stateless architectures is the location of computation, which may be done at the server, at the client, or may be distributed between them both. If the computation is done at the client, the client must fetch the data from the server, manipulate it, and then discard it. If the client changes the data in the course of the computation, the client must transmit clients are stateless they cannot simply retrieve the piece of data which has changed. The client must be intelligent enough to know if the changed data will affect it. Another alternative is that the client retraverses the data structure to update locally owned information which is impacted by the new state of the shared data. For example, the shared data may affect the display which the user of the client is seeing [21]. A stateless architecture is depicted in Figure 8. Alternatively, computation in a stateless architecture may be done at the server. This has several advantages. First, if the servers are single-threaded, there are no mutual exclusion issues. Second, such
Distributed Information Architectures
Subscription Architectures
Notification Architectures
Distributed State Architecture
Look Up Architectures
Polling Architectures
Stateless Architectures
Figure 6 : Hierarchy of Dynamic Data Architectures
tion architecture, Distributed State and Stateless. The distributed state architecture stores the entire set of the Data List B =2 Client 1 C =3
Server Data List A =1 B=2
Data List A =1 B =2 C =3
Client 2
Figure 7 : Distributed State Architecture
these changes back to the server, which generates a notification initial from implementation the server to all andofsubsequent its clients. maintenance Because the Client 1 arises not from maintaining the consistency of the distributed state, but instead from the interaction Data List between the application subsystem, the notification A =1 subsystem, and the client-side cache. For example, B =2 Server in the FRIEND I design, developers must remember C =3 to request objects from the Object Store, explicitly return changed objects to the server, and respond to Client 2 the notification of changes in the proper way. A further difficulty may arise if the mechanisms Figure 8 : Stateless Architecture for acquiring and manipulating local objects differ an architecture can be easily implemented via RPC
significantly from those for objects which are part of the shared distributed state. In this case, it may be difficult to encapsulate these mechanisms inside the objects themselves, forcing the developers to be aware of the distributed nature of some objects. This difficulty was encountered in the FRIEND I design. 6.3 The Stateless Architecture The benefit of a stateless architecture is that no client can find itself in an inconsistent state. All clients view the same data, so the chance for error is reduced. If the stateless architecture uses serverbased computation implemented through RPC, there are additional benefits. If the RPC are available transparently, programming is much easier. Transparency means that the programmer does not need to know whether the data being accessed is local or remote. This encapsulation improves maintainability by limiting the code changes necessary in the use of the objects being distributed by the system. Drawbacks of the architecture include increased network usage from clients needing to contact the server for any use of the data. This continual contact also places more stringent requirements on the server. The server will be responding to many client requests for data, which hinders scalability. The problem is made worse by server-side computation because the server is not only sending data out to the clients, it is also doing processing on the data. This means that the server must be able to do fast IO and have processing capability to keep up with the client requests. A further problem with the use of server-based computation implemented through RPC is that a disconnection requires clean up of many more objects in the system. A stateless system which does computation on the client requests and transmits data to and from the server through a single pipe, leaving only one connection to clean up during a disconnected period. An RPC implementation which does computation at the server can have an arbitrarily large number of outstanding connections
open to objects at the server. This means increased clean up and increased overhead. 6.4 Lesson learned: Successes and Failures We have learned many lessons from the successes and failures of our three FRIEND designs. Our experiences with FRIEND II have shown that stateless architectures are not well suited to accident management systems. The large amount of network traffic generated by these architectures can not be supported by the current crop of wireless networks, which provide only limited bandwidth. Furthermore, these architectures require servers to be fault-tolerant and highly available. Our success with the stateless architecture of FRIEND II stemmed from its simplicity, a simplicity which would be destroyed by modifying the design to provide fault-tolerant, highly available servers. FRIEND I and FRIEND III provided us with several lessons about distributed architectures. The most important one is that the integration of the database subsystem and the notification mechanism in an active database is very desirable because it allows the application modules to ignore notification propagation. FRIEND I showed that relying on the application modules to explicitly propagate notifications can be problematic. Another important lesson is that the mechanism for maintaining consistency between the user interface and the database should be distributed among the individual application modules instead of being centralized. This distribution allows each application module to concentrate on its own needs. In a centralized approach, the mechanism must be general enough to support the needs of all application modules. While each module must provide its own mechanism in the distributed approach, the mechanism required by each module is usually much simpler than the centralized one because it must only satisfy the needs of the individual module instead of the needs of all modules.
7
Future Work
Stateless architectures have proven effective for such that clients can reference the objects at the server as if they were local. There is no explicit transfer of data from the server to the client. The server’s memory space is effectively mapped into the client’s remotely [22]. 6.2 The Distributed State Architecture There are two primary benefits to the distributed state approach, speed and availability during disconnection. Systems utilizing distributed state are less server and network intensive because clients need only to request data from the server when the data is not already cached at the client. The second benefit is that if a client becomes disconnected due to network failure, the client will have some data locally available. While the client will not be able to modify data at the server, it will be able to read the information already stored. The problem with the distributed state architecture is that is difficult to properly implement, and difficult to maintain. The difficulty in the
small subsystems, but it is unclear that they can be scaled for use in applications like accident management. There are several possible options for scaling stateless architectures that were not explored in any of the FRIEND designs. The most obvious modification is to include the location of the change occurring when notifying the clients. In this way, any subscriber that is not currently displaying the area of the data structure that has changed would not have to refetch the data. Unfortunately, this requires the subscribers to maintain some local state about the user’s current context in the data structure. It is unclear just how to do this without caching or references to the server-based objects. A further research question involves smooth reconnection of a remote client after a disconnected period (which is common with wireless architectures). During disconnected periods, messages to and from the remote client must be queued for later delivery. In an accident management system, it is often the case that one request in a queue will be canceled by a later item in the queue. For instance, during a disconnected period a resource request that is sent to all remote stations may be balanced by an answer which appears later in the queue. Since the resource request has been fulfilled, transmission of that request to a remote station upon reconnection is a waste of bandwidth and time. Given the supposition that the link may go down again in a short time, it is important to avoid transmission of this essentially useless information. Interfaces that will allow developers to specify rules for determining queue maintenance and queue element removal would be invaluable for improving distributed accident management systems. Such an interface should allow the state of the remote system to be synchronized with the state of the local system in a selective manner, so that the out of date information is not transmitted across the wireless link. Our future research efforts will therefore concentrate on issues in wireless architectures such as disconnected operation and the interaction between active databases and wireless networks.
8
Conclusions
In this paper we have looked at three architectures to support accident management systems, an important class of cooperative information systems. Although these three designs do not represent a progression towards a better design, they did provide useful insights into dynamic data provision. The sharing of dynamic data in a situation where all clients must be ensured that they have the most accurate information has very different requirements than that of traditional stable data search and
retrieval mechanisms. We have found a large area of intersection between the problems found in architectures supporting accident management and in distributed filesystems. While one can utilize knowledge gained from the years of study of distributed filesystems, distributed dynamic data has different requirements which require different implementation strategies. The biggest of these requirements is speed of access to mission critical data that changes rapidly. A second major difference is that shared dynamic data often has direct impact on a user’s display, and thus will be accessed extremely regularly. The stateless architecture and the distributed state caching architecture offer different benefits and drawbacks and should be used only where each is strongest. The stateless architecture is more appropriate for large data structures where only a few of the data objects are used in the user display. The distributed state architecture is more suitable for a changing display and a smaller more stable data structure. A second order benefit of stateless architectures is that they can be implemented to be transparent to the developer (using RPC) and therefore may increase developer productivity.
9
Acknowledgements
We would like to thank several generations of participants in the Software Engineering Course at Carnegie Mellon University who contributed to the analysis and the design of the three FRIEND systems described in this paper. We would also like to acknowledge the contributions and help from Steve Gemma, David Pascua, and Ed Liu. Robert Coyne from the Engineering Design Research Center, Marvin Sirbu and Ben Bennington from the Information Networking Institute and Alex Hills from the Department of Engineering and Public Policy at Carnegie Mellon University provided insightful comments and stimulated many aspects of the designs. We would also like to extend our special thanks to our client, Chief Bookser from the Police Department at the Bellevue Borough.
10 Bibliography [1]
M. Bookser and B. Bruegge. “Information, Technology and Police Management: The FRIEND system,” Proceedings of the 1993 Society of Police Futurists International Symposium, Baltimore, Maryland, May 1993.
[2]
T. Berners-Lee et al., “World-Wide Web: The Information Universe,” Electronics Networking: Research, Applications, and Policy, Vol. 2, No. 1, Spring 1992, pp. 30-37.
[3]
[4]
M. Carey, D. DeWitt, G. Graefe, D. Haight, J. Richardson, D. Schuh, E. Shekita, and S. Vandenberg, “The EXODUS Extensible DBMS Project: An Overview,” Readings in Object-Oriented Databases, S. Zdonik and D. Maier, eds., Morgan-Kaufman, 1990. S. Cross and E. Walker, “DART - Applying Knowledge Based Planning and Scheduling to Crisis Action Planning” in Intelligent Scheduling, Zweben, M. and Fox, M. (eds), Morgan-Kaufmann Publishers, Inc. 1994
[5]
U. Dayal et. al., “The HiPAC Project: Combining Active Database and Timing Constraints,” SIGMOD Record, March 1988.
[6]
“FRIEND System Documentation,” 15-413 course documentation, Carnegie Mellon University, December 1992.
[7]
[8]
[9]
“FRIEND Fall ‘93, System Documentation,” 15413 course documentation, Carnegie Mellon University, December 1993. S. Garfinkel and M.Mahoney, NeXTSTEP Programming: Step One: Object-oriented Applications, Springer Verlag, 1993. J. H. Howard, M.L. Kaza, S.G. Menees, D.A.Nichols, M. Satyanarayanan and R. N. Sidebotham, “Scale and Performance in a Distributed File System,” ACM Transactions on Computer Systems, Vol. 6, No. 1, February 1988, pp. 55-81.
[10] I. Jacobson, M. Christerson, P. Jonsson and G. Overgaard, Object-Oriented Software Engineering: A Use Case Driven Approach, Addison-Wesley 1992. [11] S. Gemma, K. O’Toole, E. Liu, D. Pascua, “The FRIEND Project,” Master Thesis, Tech. Reports #1993-13, #1993-14, #1993-15, Information Networking Institute, Carnegie Mellon University, 1993. [12] K. O’Toole, “Dynamic Data Handling and the FRIEND System,” in [11], Information Networking Institute, Carnegie Mellon University, 1993. [13] J. Kistler, “Disconnected Operation in a Distributed File System,” Tech. Report #156, Carnegie Mellon University, 1993. [14] M. McCahill, “The Internet Gopher: A Distributed Server Information System,” Connexions - The Interoperability Report, Vol. 6, No. 7, July 1992, pp. 10-14. [15] J. K. Ousterhout et. al., “A Trace-Driven Analysis of the Unix 4.2 BSD File System,” Communications of the ACM, 1985. [16] K. Ramamritham and J. Stankovic, “Scheduling Strategies Adopted in Spring: An Overview,” Tech. Report #45, University of Massachusetts at Amherst, 1991.
[17] J. Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, William Lorenson, Object-oriented Modeling and Design, Prentice Hall, 1991. [18] R. Sandberg, G. Goldberg, S. Kleiman, D. Walsh and B. Lyon, “Design and Implementation of the Sun Network Filesystem,” Proceedings of the 1985 USENIX Summer Conference, June 1985, pp. 119130. [19] M. Satyanarayanan, “A Study of File Sizes and Functional Lifetimes,” Communications of the ACM, 96-108, 1981. [20] M. Satyanarayanan, “Experience with Disconnected Operation in a Mobile Computing Environment,” Tech. Report #168, Carnegie Mellon University, 1993. [21] A. Silberschatz, J. L. Peterson, and P. Galvin, Operating System Concepts. 3rd Edition, Addison-Wesley, 1991, pp. 505-508 [22] W. E. Weihl, “Chapter 4: Remote Procedure Call,” Distributed Systems, ed. S.J. Mullender, ACM Press, 1989, pp. 65 - 85. [23] Wolfson, Ouri, et. al., “Active Databases for Communication Network Management,” Tech. Report #059, Columbia University, 1990. [24] S. T. Wong, “Messages and Protocols for Cooperative Systems Communication,” Tech. Report #829, Shin Sedai Konpyuta Gijutsu Kaihatsu Kiko, 1993.
