Printer Friendly

Concurrent object-oriented programming.

Concurrent object-oriented programming (COOP), once of interest to researchers only, is today one of the hottest goals on the short-term agenda for MIS, telecommunications, and other key segments of the mainstream computing community. Companies developing ambitious applications in all areas, from banking to groupware, networking and scientific computing, have come to realize that comprehensive solutions require combining the flexibility of concurrency and distribution with the power of object-oriented technology. They naturally want to combine the two approaches, but find that the combination is not as easy as it might initially seem. The aim of this issue is to provide a snapshot of some of the most important ongoing work in the area, and help contribute to resolving some of the most pressing problems in this area.

The eight articles in this issue cover various topics in the application of object-oriented methods to the problems of building concurrent and distributed systems. The articles have been divided into three sections. The division is not definitive, as some articles span two categories.

Articles in the distribution section, describe the challenges of building distributed systems. The titles indicate a focus on the operating system facilities in the first article, and on language mechanisms in the second, but the topics are really quite close: how to use classes and objects to build effective distributed systems.

The second section, concurrency mechanisms, addresses a fundamental conceptual problem: what basic facilities should be used to build concurrent object-oriented systems? The variety of answers these articles provide, even though they all start from the same base language, is evidence enough that the problem, fundamental as it may be to the progress of the field, is still wide open. Some solutions rely on extensions of an object-oriented language; others do not touch the language but offer extensions through libraries, which software systems will use in part through inheritance.

The third section describes methodological approaches. The question here is how to approach the construction of a concurrent or distributed object-oriented software system. The object-oriented approach is well known for its powerful modeling capabilities. It is important to explore how well this property carries over to the concurrent and distributed world, and what methods we may use to facilitate the design process. One article addresses a methodology for building distributed systems; another describes the design of an object-oriented operating system and discusses principles derived from that experience.

The Articles

The first article, "COOL: System Support for Distributed Programming" by Rodger Lea and Christian Jacquemot from Chorus Systemes and Eric Pillevesse from the French Telecom, describes the design of a distributed operating system and its applications. The COOL system is the object-oriented layer of the popular Chorus micro-kernel operating system. The article provides a good way to understand the needs that a combination of distribution, concurrency and object orientation places on the fundamental underlying mechanisms.

"The DOWL Distributed Object-Oriented Language" by Bruno Achauer describes another distributed environment, this one based on its own language. The system described runs on various DEC hardware and has been evaluated with several applications, including a distributed resource planning system and a system for computer-supported cooperative work. The base language is Trellis (originally called Trellis/Owl, hence DOWL where the D stands for Distributed), a statically typed object-oriented language with multiple inheritance and genericity. In several respects Trellis is similar to Eiffel, used in some of the other articles in this issue, but Trellis takes a different approach to such questions as iterators, exception handling and subtyping. Achauer and his colleagues took the Trellis environment and explored how to turn it into a distributed system.

"Systematic Concurrent Object-Oriented Programming," by Bertrand Meyer, explores the following problem: how can the object-oriented paradigm be extended in a minimal way to cover concurrent and distributed systems as well as sequential computation? The proposed answer significantly differs from most previous work. There is no distinction between "active" and "passive" objects, and even the notion of process (a staple of almost all concurrency mechanisms, object-oriented or not) is found not to be needed as a primitive construct, although it can be implemented as a simple class in the mechanism proposed. The article examines in detail the constraints that led to its design before presenting the mechanism and a number of various examples.

"Concurrency Annotations for Reusable Software" by Klaus-Peter Lohr from the Freie Universitat Berlin, proposes a quite different solution to essentially the same problem. This work has been implemented as part of the HERON platform for execution of distributed applications. As in the previous article, the mechanism extends an object-oriented language, Eiffel. The extensions are syntactically different: in one case, an extra keyword and some semantic changes; in the second, "annotations" which affect concurrent executions and are treated as comments in the sequential case. More important, however, are the differences that affect the underlying concurrency mechanisms.

The next article, "Toward a Method of Object-Oriented Concurrent Programming," by Denis Caromel, belongs in part to the methodology category although it appears in the section on concurrency mechanisms. Caromel's model of concurrency uses an explicit notion of process. A class becomes a process type (enabling its instances to be processes) by inheriting from a special library class called PROCESS. Since a process, in contrast with a normal "passive" object which simply provides services, has its own control agenda; this immediately raises the question of synchronizing a supplier process when one of its clients calls one of its features. The solution is to raise an exception in the supplier. The article proposes a method for approaching concurrent applications; the method, which starts with an object-oriented design step similar to what would be done for a sequential system, then identifies the processes, implements them, and refines the result to take practical constraints into account.

Murat Karaorman and John Bruno's article "Introducing Concurrency to a Sequential Language" presents work which in its general approach to concurrency shares a common flavor with Caromel's. In their model, an object is active if its generating class inherits from a class called CONCURRENCY. When created, an active object spawns a proxy. In this case, however, the aim of the proxy is not to provide a means of accessing an object independently of the object's physical location, as in the distribution articles, but to manage asynchronous communication of a supplier object with its clients, letting the supplier perform its computations while handling requests that are sent to it and the responses it returns. This makes it possible to have a fine-grained approach to scheduling, implementing any policy that is deemed appropriate for an application.

These two articles, which both include a strong methodological component, provide a good transition to the final section: methodology. "Designing and Implementing Choices: An Object-Oriented System in C++," by Roy H. Campbell, Nayeem Islam, David Raila and Peter Madany describes the design of an object-oriented operating system, which runs on a number of popular workstations, and draws some methodological conclusions. The methodological advice given by the authors addresses a number of topics, not all of them specific to a concurrent environment. They discuss how to use inheritance, in particular abstract classes. The approach they recommend relies on prototyping, supported in their case by a prototyping tool, VirtualChoices, which uses the Unix virtual machine to experiment with the Choices mechanisms--associating for example Unix signals with exceptions and the System V memory-mapped file with the Choices physical memory.

The final article is "DOCASE: A Methodic Approach to Distributed Programming," by Max Muhlhauser, Wolfgang Gerteis, and Lutz Heuser. The DOCASE project is an attempt to provide a method for people who have to design distributed systems (and the article may be viewed as belonging also to the distribution category). The DOCASE approach is illustrated throughout by a sample application: processing travel claims. It is a good indication of the modeling power of the object-oriented approach that the application can be thought of both as a description of a system of humans engaged in this activity, as well as the design for a software system which has been entrusted with it.
COPYRIGHT 1993 Association for Computing Machinery, Inc.
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 1993 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Title Annotation:overview of eight articles
Publication:Communications of the ACM
Date:Sep 1, 1993
Words:1338
Previous Article:Before the Altair: the history of personal computing.
Next Article:Cool: system support for distributed programming.

Terms of use | Privacy policy | Copyright © 2022 Farlex, Inc. | Feedback | For webmasters |