Distributed Processing: Requirements for an ... - IEEE Computer Society

Distributed Processing: Requirements for an Object-Oriented Approach Dianne M. Marsh and Linda M. Ott Michigan Technological University Houghton, Michigan 49931 [email protected], [email protected] Abstract Substantial benefits, such as increased code reusability, simplified maintainability, and improved reliability can be attained through the proper use of object-oriented languages. Often, languages which claim to offer concurrency and object-oriented features have exhibited significant inadequacies which impose limitations on the benefits. In addition, it is evident that there is no existing standard used by the designers of these languages. The lack of this consistency presents difficulty for programmers who would like to take advantage of an object-oriented approach to distributed processing. Therefore, we combine the requirements for object-oriented programming with those for distributed processing. Several solutions which have been proposed in the literature for advertised problems in the combination of distributed processing and object-oriented programming languages are discussed and evaluated with respect to the paradigm which we present. These solutions are used to extend an existing language (ABCL/R3) to demonstrate that these features are compatible.

1. Introduction An object-oriented paradigm has been established for the sequential model. While there is not universal acceptance, the majority agree on a definition, and this has led to increased uniformity in languages which claim to be objectoriented. The same degree of uniformity, however, is not present in languages which claim to offer concurrency in addition to object-oriented behavior. The inclusion of concurrency requires such substantial changes that a new paradigm is required. The availability of both features is not enough. It is essential that this combination does not sacrifice either the benefits of object-oriented programming or the parallelism which might be extracted from an application. Several languages which have sacrificed object-oriented benefits in order to incorporate parallelism have cited the impossibility of their inclusion or the

lack of a need. We identify the essential characteristics which must be provided in languages in order to support a distributed object-oriented paradigm. Existing work has provided information about limitations and possible solutions to subproblems in the combination of concurrency and objectoriented techniques. These solutions are analyzed with respect to the requirements for this paradigm in [1]. The integration of the solutions with an existing language is described in a manner which preserves the integrity of concurrency and object-oriented behavior. The specification of a definition for distributed objectoriented languages is beneficial to both designers of such languages and programmers who are considering their use. The inclusion of the identified features is necessary in order to provide the benefits of object-oriented languages, such as reusable code, to the parallel programmer. Their omission risks the loss of such benefits. This definition also provides the software developer with the ability to make an informed choice about the languages that are available. Through the development and use of languages that contain these features, it is hoped that the process of writing parallel programs will be simplified. 1.1. Why Incorporate Concurrency Object-Oriented Programming?

and

Parallel programming is difficult. The coordination of processes and communication between these processes is complicated. Parallel processes often communicate by passing messages which contain data structures. When these structures change, modifications and recompilation are required to processes on both the sending and receiving side since they must agree upon the internal format of these structures. With object-oriented programming, messages can be sent to and from objects, without requiring that the internal structures remain the same. Agreement is required only on the interface. This minimizes the need for modifications to unrelated source code, and also increases

Proceedings of The Thirtieth Annual Hawwaii International Conference on System Sciences ISBN 0-8186-7862-3/97 $17.00 © 1997 IEEE

1060-3425/97 $10.00 (c) 1997 IEEE

the flexibility and reusability of the software. Distributed processing adds even more complexity to the parallel programming process. Shared memory is not available and typically users work in a heterogeneous (hardware) environment. Also complicating the process of developing software for a distributed environment is the fact that those who understand the intricacies of message passing and synchronization often do not understand the problem that needs to be solved, while those who understand the problem do not understand the requirements of message passing and synchronization. If the message passing and synchronization details could be separated from the application, the scientist (who understands the problem) could more easily design a program to solve it. Object-oriented programming can be used to hide these details. 1.2. Why Establish a Paradigm? Substantial benefits, such as increased code reusability, simplified maintainability, and improved reliability, can be attained through the proper use of object-oriented languages. Often, current languages which claim to offer concurrency and object-oriented features have exhibited significant inadequacies which limit the benefits. Requiring that encapsulation be violated in order to provide concurrency is such a case. Another problem which results from the lack of an established paradigm is in confusion (by programmers) about what such a language should provide. This presents two separate problems.

A programmer who is fairly well-acquainted with object-oriented techniques does not expect to have to violate the principles of object-oriented programming, such as encapsulation, in order to develop a working program. These convictions stand in the way of successfully implementing an application when the language requires that these principles be violated in order to obtain a working program. A programmer who is not acquainted with objectoriented techniques may be led to believe that the language provides object-oriented behavior. This may lead to problems later, when the programmer is faced with a language which requires that these principles be followed or is using a language with different “objectoriented behavior”. Our research was motivated by the first problem, where the programmer refuses to violate object-oriented principles[1]. The first step in resolving such problems is through the specification of requirements for a paradigm. Language designers can use this specification when determining what

should be included in a language in this particular class. In addition, application programmers can use this specification in order to determine if a language under consideration meets the requirements for concurrent object-oriented languages. We specify these requirements. The next step is to carefully integrate these requirements into a language such that object-oriented principles are not violated and concurrency is provided. We describe how such an integration can be achieved. Furthermore, we argue that it is possible to incorporate these features transparently to the application, achieving a high degree of encapsulation.

2. Requirements for Object-Oriented Languages

Concurrent

The requirements for object-oriented programming are combined with those required for concurrency and those which were identified as necessary for the types of applications that are well suited to a distibuted implementation [1]. The following represents the essential features for distributed object-oriented programming languages.

Distributed object-oriented programming languages cannot require that the programmer violate encapsulation in order to provide concurrency. If information about how member functions behave is necessary, it must be obtained by the compiler or the runtime environment. For example, if the compiler chooses to schedule the methods of an object concurrently, then it must ensure that this execution does not change the flow of the program. Distributed object-oriented programming languages must provide inheritance without requiring a loss of encapsulation. Languages which implement inheritance by requiring that synchronization constraints are considered separately (either not inheritable or those which require modification when a subclass is developed) do not fit this definition. Delegation (or a similar method which provides a means for code sharing among classes) may be implemented in addition to, or in place of inheritance, but this implementation must follow the same guidelines. This requires that the implementation be efficient so that performance is not seriously affected. An efficient implementation of delegation has not yet been described in the literature, so it will not be discussed further. Distributed object-oriented languages must provide a mechanism for scheduling through which objects can defer the processing of a message, based on both the object’s internal state and the content of the message [2]. Protection of internal consistency in the presence


1060-3425/97 $10.00 (c) 1997 IEEE

of multiple threads must be provided. Interleaving is also necessary, whereby internal behavior of an object should not be constrained by its external behavior. [3].

Distributed object-oriented programming languages must provide the availability of both active and passive objects. Active objects have their own thread of control, while passive objects do not. Active objects are useful for modeling objects which naturally exist in a concurrent state, while passive objects are those which are, by definition, sequential in nature. It is beneficial to be able to specify when an object should not be analyzed for concurrency (i.e. it is passive), because this increases the efficiency of the system.

objects should be allowed to migrate to lightly-loaded processors. This will help to spread the work over multiple processors, and requires no intervention by the programmer. In order to provide acceptable performance, a distributed object-oriented language must implement load balancing. An idea borrowed from the developers of Mentat is to allow instantiation hints. This allows the programmer to convey information about an object to the compiler. By providing this information, the programmer can help to improve the performance of the system, without risking loss of any object-oriented benefits. For example, the Mentat system provides the following choices [5]:

Temporal consistency must be maintained for events in a distributed object-oriented language. This implies the need for a synchronization mechanism. Because the hardware and memory configuration are required to be abstracted, the implementation must not require the availability of a global clock.

– Locate the new object close to the specified object so that communication between the two is inexpensive.

A significant advantage results when synchronization and an application program are hidden from each other. Watanabe and Yonezawa showed that it is possible to completely conceal the synchronization information from the application [4]. This permits the application programmer to concentrate on the algorithm, and the details of synchronization are not relevant. If the synchronization method were to change, the source code for the application would be unaffected. This simplifies the process of writing parallel programs.

– Locate the new object on a lightly loaded or powerful processor, which may be distant, because it will perform a large amount of computation.

Objects must be able to communicate with other objects through some means. In order to abstract the hardware and memory configuration of the system, it should be transparent whether this communication (via message passing) passes over processor boundaries or is local. If objects are moved in the process of load balancing, the object’s address should remain available to others who would like to communicate. Programmers who understand the communication patterns of their programs should be able (but not required) to provide the compiler with this information, in order to improve performance. With the compiler responsible for abstracting the hardware processor configuration, the programmer is free to concentrate on the problem, and ignore requirements for efficient distribution of messages along the network. The source code, which remains free of architectural-dependent information, will certainly be more reusable.

Dynamic allocation of objects to processors (migration) is necessary. In order to attain good performance,

– Locate the new object far away from any object in the list so that they can execute in parallel on different processors.

While it seems that encapsulation may be in violation with the idea of location hints, this specification is voluntary, not mandatory. This allows programmers who have specific knowledge about the behavior of objects to provide this information to the compiler. It does not require that this is done, and its omission does not result in a program which does not work.

Heterogeneous distributed processing must be supported. Environments which take advantage of distributed processing often include machines of different architectures and this should not be overlooked. Objects should be able to communicate with machines of different architectures in a manner transparent to the programmer. Persistent information is required because many applications require that an object maintain some state information, and it is not cost-effective to regenerate this information. Most languages seem to provide this feature. It is included here only for completeness. The look and feel of a sequential programming environment should be maintained. An example of this requirement might be that each object should be able to perform I/O. Another example is a mechanism by which a global construct can be shared among objects in a system as if it were available in shared memory. This should be provided in a transparent fashion, even


1060-3425/97 $10.00 (c) 1997 IEEE

on systems which do not have any available shared memory. This is not to say that it is necessary (or even desirable) to mimic a sequential programming language.

3. Proposed Strategies for Integrating Concurrency and Object-Oriented Programming There are many solutions in the literature which are promising for solving the problems of providing inheritance and encapsulation in a concurrent environment. However, the potential for combining these features into a single solution has not previously been explored. This section proposes an integration of these solutions, and discusses the hypothetical result with respect to the necessary features for concurrent object-oriented languages. An existing language is extended to meet the requirements. These extensions are done modularly. The order of construction is not important. Once a feature has been successfully added to the existing model, that model will be given a name, in order to simplify the discussion. In [4], the use of meta-objects is described to encapsulate a method of synchronization. The method of synchronization used in the research was the optimistic method known as Time Warp [6], but that implementation is completely transparent to the application programmer, who can use the synchronization code as a library routine. The language ABCL/R3 [7], provides the ability to completely separate the synchronization constraints from the application through the use of the meta-object. It does not, however, provide synchronization based on message content. This is a useful feature, as described in [8]. We use ABCL/R3 as our basis and describe how to incorporate parameterized message acceptance into the language. 3.1. Adding Parameterized Synchronization Synchronization based on message content follows the same general methodology as the modularization of the Time Warp mechanism (described in [4]). In both cases, a state variable needs to be examined to decide the course of action. The following is an example of how synchronization based on message content could be implemented using the meta-object of ABCL/R3. Any messages which match the parameter specified are enqueued on the active queue (i.e. the queue that is consistent with the definition of ABCL/R3), and cause the object to be sent a :begin message if the object is currently dormant. A separate queue is kept of messages that are not accepted, based on message content. This queue is examined for appropriate messages whenever the parameter is

explicitly changed via a :setparam message. In order to implement parameterized message synchronization in an actor language which uses meta-objects in a fashion consistent with ABCL/R3 it is necessary only to add a separate Metaobject generator which will handle this functionality. The implementation of this additional generator is similar to the Time Warp object which was defined in [4], and is similarly encapsulated from the application source code. The result is merely a superset of the language as it currently existed since a default value (e.g. null) could be used to disable parameterization. 3.2. Effect on Inheritance The arrival of messages in the input queue has changed with the availability of parameterized messages. These messages are held until they can be executed. This does not affect inheritance, since any subclasses which use this method would obtain their own copy of the parameter on which to match, and could modify it (or disable the feature) as desired. It has been shown that, with enabled-sets, inheritance is unaffected by the inclusion of parameterized messages [8]. It is also important that the object retain first class status. As described in [8], first class objects are able to send and receive messages. For a meta-object to be first-class it must retain this functionality. Since, in this definition, there exists a hierarchical construct of meta-objects, the first class status is retained. Efficiency is critical. [9] demonstrates the use of partial evaluation in order to provide an efficient compilation technique for meta-level programming. This section has provided an example of how an actor language can encapsulate the synchronization constraints based on methods such as Time Warp and parameterized messaging, yet still provide inheritance and reflection. This extended language will be used as a basis for adding additional extensions. It will be referred to as DOOP1 for simplicity. 3.3. Adding Load Balancing An additional requirement in order to simplify the process of writing parallel programs is the provisionof load balancing. Ideas from the Muse Object Architecture [10] are combined with DOOP1 in order to provide this functionality. The use of meta-objects is extended to provide an environment in which the object resides. This follows from the description of meta-objects for the Muse Operating System. This new combination is examined to ensure that it continues to meet the needs of our paradigm. An extension to DOOP1 to provide object migration is also a matter of creating a meta-object generator, as was re-


1060-3425/97 $10.00 (c) 1997 IEEE

quired in order to attain synchronization based on message content. Actor languages provide the capability for communication with other actors with whom they have become acquainted (i.e. know the mail address) [11]. Actors who create new actors know the addresses of those that they created, and are able to pass these addresses along in subsequent mail messages. Since the entire system is comprised of actors, all of the addresses will be known. Because it is possible to send messages to the meta-object of an object while that object is busy (:active), the system can change while it is running. This is precisely what is required for the proposed combination. To implement load balancing it is necessary that actors obtain load information, via the Decision Maker metaobject, and base their migration information on the Computational Field Model, as was done in [10]. The difference is that it was not applied to a language which implemented parameterized message synchronization. This does not matter, however, since the object migration can exist without modification to the application program. The key is that the addresses used to reference the actors before the migration remain valid. In a reflective model, this is done by including a Mailer meta-object, which traces the paths of communication between objects[10]. Since it can modify itself by sending a message to its meta-object, it can update the current address of the object when necessary. In addition to load balancing, it is often advantageous to migrate tasks based on the computation required, as described in [12]. Kim and Agha describe one method for implementing dynamic load balancing using location transparency and migration [13]. Since these additions to DOOP1 are provided by metaobjects, and thus are transparent to the application, the paradigm is not violated. In this manner, load balancing has been established, and the new combination will be further referred to as DOOP2. A final requirement is efficient access to distributed objects, as if they were local. This serves to isolate the programmer from concerns about the programming environment, and allow the parallel program to be ported across architectures and re-used in different configurations. The Fragmented objects method has been chosen for this evaluation, and the new combination is now examined with respect to its adherence to the paradigm. 3.4. Adding Virtual Shared Objects Fragmented objects can be provided in a distributed environment in order to simulate the availability of shared memory. This allows the application programmer to decompose objects naturally, without concern for the granularity of the system on which the program will run. This allows the program to be written in an object-oriented manner, without

requiring objects to be decomposed into sizes that will make the program dependent on an architecture, and thus, less likely to be re-used. The concept of decomposing objects unnaturally into objects (e.g. an array into subgrids) leads to false-sharing because the neighboring sub-grids must participate in the computation[14]. Fragmented objects have been described as a feature of Multi-Versioned Immutable Objects[14]. Copies of these objects can be locally cached in many different processors, providingthe illusion of locality from a programming standpoint. The application-defined class inherits a generic superclass which handles fragmented object allocation and reference, which hides the need to know the current version number of the object. 3.5. An Efficient Means for Shared Memory Simulation When simulating shared memory using fragmented objects, updates require that messages are sent to all nodes who have a copy of the object. Inefficiencies may result from this indiscriminate messaging. It is possible that changes to a fragmented object were interesting to another object only for a short time. Even when its interest has waned, this implementation requires that updates continue to be sent. In addition, if the updates are occurring at a faster rate than the object requires, the additional traffic is unnecessary. In combination with the Subscription and Notification method, described next, the traffic can be reduced. A technique which uses many of the theories behind immutable objects has been developed at AEG-Mictron for use in a factory control system[15]. The intention was to limit messages sent to applications from a database which was being updated in real time. Here, it is described for objects, who are trying to get information about other (changing) objects. Two types of update mechanisms are provided, including Changed Data Notification (CDN) and Changed Data Packet (CDP). Message passing is used to subscribe, desubscribe, and to obtain updated information. Independent, active objects are used, where each object handles its own messaging. Changed Data Notification (CDN) When an object (A) is interested in the state of another object (B), A sends a subscription request to B. Upon receipt of that message, B adds the object A to its list of subscribers. Whenever a change is applied to B, B sends a message to all of the objects on its subscription list, to tell them that it has changed. B also marks the subscription list entry so that it knows that each subscriber has been notified. This disables further notification from B to each subscriber about changes to its state. When B receives a request for updated information


1060-3425/97 $10.00 (c) 1997 IEEE

from a subscriber (C), it unmarks the appropriate entry, and any subsequent change results in further notification. With this approach, the significant events, which determine update intervals[16], are defined individually, for each object in the subscription list. This reduces the traffic to objects, if updates occur at a rate faster than they can process the information. This is typical in a real-time environment. The objects are responsible for requesting updated information when they require it. An additional advantage is that objects which are no longer interested (or momentarily disinterested) in the updated information only receive one message that the object has been changed. If they require the information at a later time, they are free to retrieve it. If they are permanently disinterested, the desubscribe option is recommended. Changed Data Packet (CDP) A companion subscription method is available for applications which require updated data for every change of an object. The Changed Data Packet (CDP) type of subscription sends the data in each message to the object. The object is not disabled from further notification, and there is no need to retrieve the data separately. In practice, this method was not used, as it resulted in an overwhelming amount of information sent to the requesting objects. The Subscription and Notification method relies on the timely receipt of all messages. This cannot be guaranteed in theory. However, this method is used in practice and has not demonstrated a loss of packets. This method could, however, be made more robust by the replacement of the disable flag by a timer, which could reactivate the notification flag after a specified time period. This has not been implemented. It must be noted that the description of this technique does not include a discussion of how to update information. The actual implementation which is in use actually includes such policies, but the intent here is to show the Subscription and Notification method as a means for achieving a reduction of traffic when objects change. As described above, it may be beneficial to combine Fragmented Objects with the Subscription and Notification idea in order to provide a more efficient mechanism for updates. With this addition, objects are permitted to signify their lack of interest in an object. For momentary disinterest (as is common when updates are generated too quickly), the object merely ignores the CDN until it can process the updated information or until it requires the information again. For longer-term disinterest, the object is permitted to desubscribe to changes, preventing subsequent updates until it decides to subscribe again, if ever.

The simulation of locally available fragmented objects can be provided using DOOP2 as a basis. Once again, a meta-object is created to handle the fragmented object allocation and reference. This implementation is consistent with its specification as a superclass in [14], and does not adversely affect any object-oriented principles. Moreover, the problem can be more naturally decomposed, which actually increases its ease of implementation using an objectoriented language. The object consistency is maintained by the version control meta-object, and performance is not adversely affected because blocking only occurs when two objects attempt to modify the same fragmented object. In addition, the inclusion of Subscription and Notification reduces the network traffic required in this implementation over what was originally proposed. 3.6. Adding Heterogeneous Support Transportable objects[17] in a heterogeneous environment require a machine-independent format for data storage and transfer. In order to preserve encapsulation, this must be transparent to the programmer. XDR (eXternal Data Representation) is a Sun Microsystems standard which is provided by many vendors. In the scenario described here, a meta-object for communication could be defined to use XDR in a manner consistent with these requirements. Process migration and load balancing in a heterogeneous environment should also be handled with a meta-object. 3.7. Summary We have shown that it is possible to incorporate the benefits of object-oriented programming and concurrency in a single language without incurring a loss of benefits. In order to provide such a combination, extensive use of the meta-object features of actor languages has been incorporated to encapsulate the implementation from the application. A possible performance improvement over a potential solution for providing local access to distributed objects has been described.

4. Conclusions The advantages of object-oriented programming are significant. Concurrency adds additional complexity for both the programmer (apparent from the features required by applications) and language designers. This implies that, if these complexities could be abstracted, the world of concurrent programming could reap even greater benefits than the sequential world currently does, including simplified portability. These additional requirements necessitate the development of a paradigm which will provide a consistent view


1060-3425/97 $10.00 (c) 1997 IEEE

of concurrent object-oriented programming so that these advantages can be enjoyed. We observe that the designers of concurrent objectoriented languages have not provided a standard set of features. Therefore, we identify a list of essential features which must be included in concurrent object-oriented languages. We argue that it is both necessary and possible to integrate these features into one language without violating the principles of object-oriented programming or sacrificing concurrency. This lossless combination is required in order to avoid sacrificing benefits. The omission of features not only cripples the language, but also fails to meet the expectations of users who are acquainted with the object-oriented paradigm. Languages which do not meet the criteria which we have established should follow the convention of being described as object-based, rather than object-oriented languages in order to avoid confusion. Several of the solutions which had been previously proposed in the literature are used to extend an existing language in order to demonstrate that these features are compatible. Furthermore, we argue that it is possible to incorporate these features transparently to the application, achieving a high degree of encapsulation. This permits the implementation of the solutions (e.g. synchronization, load balancing) to change without affecting the application. This also permits the application programmer to concentrate on the application without “tripping over” synchronization, communication, and load balancing code. We believe that the encapsulation of parallel programming techniques is critical to the successful use of parallel programming by researchers in areas other than Computer Science. 4.1. Future Work We have proposed a strategy for combining concurrency and object-oriented programming in such a way that neither concurrency nor object-oriented principles are violated. By extending an existing language through the use of metaobjects, we are confident that the features of the original language remain intact. In order to strengthen this claim, the progression of languages which we have described as DOOP1 through DOOP2 could be developed and analyzed. This analysis should include performance comparisons, to determine the cost of adding these features. It should also include a comparison based on ease of use for this new language, in order to determine if the resulting language is more understandable. The extension that we described was based on an actor language. A non-actor language should be similarly extended and compared. Paradigms other than the imperative model have been discussed as appropriate for implementing concurrent object-oriented languages. These should be pursued

and compared to determine if any advantages or disadvantages are apparent.

References [1] Dianne M. Marsh, Parallel Programming: Requirements for an Object-Oriented Approach, Michigan Technological University, 1992. [2] Gul Agha, Peter Wegner, and Akinori Yonezawa, Eds., Abstraction and Modularity Mechanisms for Concurrent Computing, MIT Press, Cambridge, Mass., 1993. [3] Oscar Nierstrasz and Michael Papathomas, ““Viewing Objects as Patterns of Communicating Agents”,” in Proceedings ECOOP/OOPSLA ’90, October 1990, pp. 38–43, ACM SIGPLAN Notices, 25(10), October 1990. [4] T. Wantanabe and A. Yonezawa, ““Reflection in an Object-Oriented Concurrent Language”,” in Proceedings OOPSLA ’88, September 1988, pp. 306–315, ACM SIGPLAN Notices, 23(11), November 1988. [5] A. Grimshaw, ““An Introduction to Parallel ObjectOriented Programming with Mentat”,” Tech. Rep. TR-91-97, University of Virginia, April 1991. [6] D. R. Jefferson, ““Virtual Time”,” ACM Transactions on Programming Languages and Systems, vol. 7, no. 3, pp. 404–425, 1985. [7] Hidehikp Masuhara, Satoshi Matsuoka, and Akinori Yonezawa, ““Implementing Parallel Language Constructs Using a Reflective Object-Oriented Language”,” in Reflection 96, April 1996. [8] C. Tomlinson and V. Singh, “Inheritance and Synchronization with Enabled Sets,” in Proceedings of Object-Oriented Programming Systems, Languages and Applications Conference, 1989, pp. 103–112. [9] Hidehiko Masuhara, Satoshi Matsuoka, Kenichi Asai, and Akinori Yonezawa, “Compiling away the meta-level in object-oriented concurrent reflective languages using partial evaluation,” in Proceedings OOPSLA ’95, pp. 300–315, ACM Sigplan Notices, 30(10), October 1995. [10] Yasuhiko Yokote, Fumi Teraoka, Atsushi Mitsuzawa, et al., ““The Muse Object Architecture: A New Operating System Structuring Concept”,” Operating Systems Review, vol. 25, no. 2, pp. 22–46, February 1991. [11] Gul Agha, “Concurrent Object-Oriented Programming,” Journal of the ACM, vol. 33, no. 9, pp. 125– 141, September 1990.


1060-3425/97 $10.00 (c) 1997 IEEE

[12] Gul Agha, Wooyoung Kim, and Rajendra Panwar, “Actor Languages for Specification of Parallel Computations,” in DIMACS Series in Discrete Mathematics and Theoretical Computer Science, vol. 18, pp. 239–258. American Mathematical Society, 1994, Proceedings of DIMACS ’94 Workshop. [13] WooYoung Kim and Gul Agha, “Efficient support of location transparency in concurrent object-oriented programming languages,” in Proceedings Supercomputing ’95, 1995. [14] Michael J. Feeley and Henry M. Levy, ““Distributed Shared Memory with Versioned Objects”,” in Proceedings OOPSLA ’92, 1992, pp. 247–262, ACM SIGPLAN Notices, 27(10), October 1992. [15] Chuck Conrad, ,” 1988, Work Cell Controller Platform Specification. [16] John R. Nestor, ““Evolving Persistent Objects in a Distributed Environment”,” Tech. Rep. CMU/SEI-87TR-46, Software Engineering Institute, Carnegie Mellon University, November 1987. [17] Dianne Marsh, John Hartman, and Linda Ott, ““Distributed Object-Oriented Programming: Interfacing an Application with the Development Tools”,” Computational Biosciences, Inc. Technical Report in progress, 1996.


1060-3425/97 $10.00 (c) 1997 IEEE