Distributed Application Engineering:
An Integrated Model, Language and Tool Approach
Alexander Schill
University of Karlsruhe, Institute of Telematics,
Zirkel2, D-7500 Karlsruhe, W. Germany, Tel. (+49)(721)608-4022
Abstract
In the distributed systems area, great advances have been
achieved during the last decade. However, the development of
distributed applications is still not adequately supported by cur-
rent software engineering methods.
Therefore, a new approach based on the object-oriented para-
digm is presented. Its major characteristics are an extended
object-oriented model of computation, communication and
structure, linguistic support for distributed programming, and
tool support for application development. The approach is
based on existing facilities from the areas of distributed appli-
cation configuration management, distributed object-oriented
systems, remote procedure call, and object-oriented develop-
ment methods. Finally, the paper also disusses advanced issues
and requirements resulting from specific problems of distribu-
tion. Examples are dependability support, heterogeneity, mul-
tiparadigm approaches, and software engineering data manage-
ment.
1. Introduction
In the distributed systems area, great advances have been
achieved during the last decade. Especially in the area of com-
munication networks and transport-oriented communication
protocols, a rapid technological deployment has taken place.
From the application point of view, a growing demand for dis-
tributed programming can be observed. Important example ar-
eas are computer-integrated manufacturing and office automa-
tion. However, the development of distributed applications is
still not adequately supported by current software engineering
methods.
Therefore, a new approach based on the object-oriented para-
digm is presented. Its major characteristics are an extended
object-oriented model of computation, communication and
structure, linguistic support for distributed programming, and
tool support for application development. As opposed to other
approaches, models, languages and tools are completely inte-
grated, i.e. different language aspects are combined into a sin-
gle language, different models are combined by object-oriented
technology, and different tools are providing a common inter-
face and are using a common data representation. The approach
is based on existing facilities from the areas of distributed ap-
plication configuration management, distributed object-oriented
CH2867-0/90/0000/0391$01.OO 0 1990 IEEE
systems, remote procedure call, and object-oriented develop-
ment methods.
Finally, the paper also disusses advanced issues and require-
ments resulting from specific problems of distribution. Exam-
ples are dependability support, heterogeneity, multiparadigm
approaches, and software engineering data management. As a
foundation, the next section first presents distributed system
and application characteristics, resulting requirements, and ex-
isting approaches from the areas of distributed configuration
management, distributed object-oriented techniques, remote
procedure call, and object-orienteddevelopment methods.
2. Foundations and Related Work
2.1. Distributed System Characteristics
A distributed system basically comprises a set of physical
nodes which are interconnected via a communication network.
Typical networks used in the application domains named above
are Ethemet and Token Ring with a communication speed of
several Mbit/s. Moreover, several networks can be intercon-
nected via intermediate gateways or even via high-capacity
backbone networks like FDDI.
Current trends in the distributed systems area are leading to
very large networks with thousands of nodes. Distributed sys-
tems are often heterogeneous, i.e. they consist of nodes of dif-
ferent vendors with different data representations and instruc-
tion sets. The basic communication facilities offered by a
distributed system tend to become more and more high-level in
order to hide problems of distribution from the application de-
veloper.
2.2. Distributed Application Characteristics
A distributed application consists of several communicating
components located at different nodes of the underlying distrib-
uted system. Distributed applications are often more complex
than conventional ones due to their size and due to their large
number of communicating components. The administration of a
distributed application is complicated by the large degree of de-
centralizationfound in current application domains.
At runtime, intensive communication between application com-
391
 Figure 1: Structure of the example application
ponents can occur. This makes analysis and debugging of an
application more difficult. In addition, a large degree of inde-
terminism is present; this is caused by concurrent or even paral-
lel activities at different nodes of the underlying system. In
real-world applications running for a long time, dynamic
changes of an application structure are often desirable. Exam-
ples are the adaptation to changing environment structures in
computer-integrated manufacturing systems or support for de-
pendability based on the dynamic integration of redundant
stand-by components.
2.3. Examde Amlication
To illustrate the issues discussed above, the structure of a dis-
tributed example application is shown in fig. 1. The example
application emulates a computer-integrated manufacturing en-
vironment which has been designed in an object-oriented way
[6].It consists of a production control component, a file server,
a production monitor, a global stock, and several machines with
associated local stocks (cf. fig. 1).
The production control component receives production requests
via a user interface, gathers associated production plans from a
remote file server, and then delegates the described production
schedules to suitable machines. During production, production
parts are fetched remotely from the global stock using transpor-
tation carriages, and are finally moved back there again. More-
over, a production monitor analyzes all activities within the
production plant.
The described application has been implemented in a prototypi-
cal way. The implementation comprises more than 30 object
classes not shown in the figure. The rectangular elements
shown above are implemented by so-called configured objects
with intermediate configured object references and are man-
aged by a separate distributed configuration tool. The coarse-
grained structure of the application is built from these elements.
Within the machine object, a hierarchy of stock objects is
shown in order to illustrate the need for structural abstraction
392
facilities in distributed applications. The objects are allocated
explicitly to the underlying network using specific language
primitives of a configuration language. Basically, each config-
ured object shown in the figure is allocated to a different node.
However, other configured objects not shown are allocated to-
gether with these objects at the same node.
The production plans, the production parts, and the transporta-
tion carriages are implemented by so-called global objects
which are volatile and mobile. Global objects are only managed
by the runtime system and not by a global configuration man-
agement tool. Their dynamic allocation is controlled by so-
called colocations which describe sets of objects to be allocated
to the same node during specific time intervals. The basic moti-
vation for that is to reduce remote expensive communication
costs.
With each object, a set of operations is associated. For exam-
ple, the hle server provides operations to open, to access, and
to close files representing production plans. The body of the
operations are implemented using an object-oriented h p l e -
mentation language emulating major distribution aspects. Dy-
namic application changes include the integration of new ma-
chines with associated local stocks, and the use of altemative
file servers for production plans.
2.4. &en Issues and Reauirements
With distributed application development, a number of open is-
sues and requirements arise which are not found in conven-
tional applications:
Communication support: The intensive communication be-
tween the components of a distributed application should be
supported by efficient and easy-to-use communication
mechanisms.
Structure support: Adequate structuring mechanisms
should be available in order to manage the complexity of a
distributed application. Important requirements are hierar-

chical abstraction facilities, typing of components, and typ-
ing and explicit specification and management of compo-
nent interconnections.
Allocation support: An explicit specification of the alloca-
tion of coarse-grained application components to system
nodes should be possible.
Change support: Dynamic changes of the structure and of
the allocation of application components should be enabled.
This is especially important for very large distributed appli-
cations and systems of the near future.
Flexible degree of distribution transparency: To facilitate
application development, a high degree of distribution
transparency concerning allocation and communication is
desirable. However, to increase the efficiency of an applica-
tion or to take specific informal, application-dependent re-
quirements into consideration, distribution transparency
should be reducible, e.g. by the provision of explicit alloca-
tion facilities as mentioned above.
Computer-aided development and tool support: Distributed
application development should be computer-assisted even
in its early phases. During detailed design, all information
which is related to distribution aspects should be repre-
sented explicitly rather than be hidden in implementation
code. This way, the use of distributed application develop-
ment tools, e.g. of animation or distributed debugging tools
[20] is enabled.
To satisfy these requirements to a sufficient degree, we present
an integrated approach which is based on a number of existing
techniques discussed below.
2.5.Models, Languages and Tools for Distributed Amlications
Distributed application development can best be supported by
an integrated model, language and tool approach. As opposed
to non-distributed programming, specific kinds of languages
and tools are required. From the model point of view, we can
distinguish between coexisting structural and computational
models. The structural model describes the coarse-grained
structure of an application and of an underlying system. In the
example presented above, it is reflected by the configured ob-
jects. The structural application part consists of the application
components and of their logical interconnections. These inter-
connections serve as a base for intercomponent referencing and
communication.The structural system part comprises the nodes
of the underlying network; in general, a logically fully-
connected network is assumed. The computational model con-
sists of a basic model of computation and communication. The
basic model of computation represents distribution-independent
parts of an application and is based on conventional procedural
language elements in our approach. The basic model of com-
munication comprises the communication primitives offered by
the underlying distributed system. Examples are message pass-
393
ing, remote procedure call, and distributed object-oriented in-
vocation [3].
From the language point of view, distributed programming lan-
guages and distributed configuration languages can be identi-
fied. These languages correspond with the models of computa-
tion and structure, respectively. A typical distributed
programming language offers a procedural (possibly object-
based) style of programming augmented with communication
and synchronization primitives. A distributed configuration lan-
guage is ideally of declarative style and describes the structure
of the application and system elements. In addition, most con-
figuration approaches offer a dynamic change notation to re-
quest dynamic configuration changes at runtime.
From the tool point of view, a distinction between development
tools (e.g. simulation and animation tools, language-sensitive
editors, and compilers) and runtime tools (e.g. distributed
monitors, distributed configuration management tools, and
tools for object placement control) can be made. Moreover, a
distinction can be made between management tools (managing
the application execution by using semantic information about
the application), analysis tools (observing the application and
generating anlysis data about it), synthsis tools (supporting the
interactive creation and modification of an application), and
auxiliary tools (providing tool integration interface shells).
The approach described below considers all of these three as-
pects (models, languages and tools) and integrates them in an
object-oriented way. The next sections briefly discuss existing
approaches from different relevant areas.
2.6. Distributed Application Configuration Management
Existing distributed application configuration management
mechanisms support the management of the coarse-grained
structure and placement of an application, i.e. distributed
programming-in-the-large aspects. In particular, modular struc-
turing with hierarchical abstraction and module interconnection
management is enabled. Existing systems like CONIC [15]of-
fer declarative languages to describe an initial configuration
and to request dynamic configuration changes. Other systems
also based on a process-oriented (vs. object-oriented) model of
distribution are PCL [18], HPC [ 5 ] , and PRONET [16]. Besides
the language support, associated tools for initial configuration
generation and for dynamic configuration changes are offered
by these systems.
2.7. Distributed Object-Oriented Systems and RPC
Distributed object-oriented systems support distributed
programming-in-the-small. They provide a uniform model of
communication and computation and achieve a high degree of
distribution transparency [3,2]; this way, distributed application
development and maintenance is facilitated. Object invocations
are location independent and objects can move between nodes
dynamically, e.g. to reduce remote communication. Examples
of existing systems are Distributed Smalltalk [Z,91, Amber
(based on C++) [7], Emerald [3,14], and COMANDOS [13].
They offer a similar model of distribution based on objects of
arbitrarily fine grain but differ in several aspects (e.g. intemal
object addressing, mobility of invoked objects, and object per-
sistency) [25].
Existing remote procedure call (RPC) facilities [4,26] provide
easy-to-use mechanisms for remote communication. Moreover,
new approaches extend this paradigm by asynchronous, non-
blocking calls, by efficient mass data transfer, and by heteroge-
neity support [1,17]. These facilities can be integrated with dis-
tributed object-oriented systems.
2.8. Object-Oriented Develoument Methods
Object-oriented development [6] is based on the identification
of real-world objects mapped to the objects of a computer sys-
tem. In further steps, classes, operations and object attributes
are introduced and combined. This rather simple approach en-
ables a well-structured application design; therefore, we adopt
its basic ideas. In addition, extensions of the basic design ap-
proach are relevant to our work. Most important, hierarchical
design support is essential for complex distributed applications.
The HOOD [12] method enables this kind of abstraction, for
example.
3. Extension and Integration of Current Technolom
To provide fully-integrated support for distributed application
development, an architecture of a complete software engineer-
ing environment has been defined [21]. In particular, a design
language and a set of design and runtime tools are part of it.
3.1. Environment Architecture
The architecture of the environment is shown in fig. 2. The ba-
sic design principles of this environment are:
Object-orientation conceming the models of computation,
communication and structure
Widespectrumlifecycle support during design
Explicit representation of semantics conceming
distribution-related issues like communication, integration
of computation and configuration mechanisms
Integration of distributed object-oriented computation and
extended remote procedure call facilities
The environment consists of three major layers, the human in-
teraction layer, the functional layer and the data layer. A
widespectrum design language is the base to develop a distrib-
uted application. A design with this language is generated using
tools of the human interaction layer (e.g. graphical editors). It is
then transformed into the data layer representation by language
394
manipulation tools residing at the functional layer. A target
runtime system also present at this layer is executing an appli-
cation at the different stages of design. In addition, a number of
tool sets are plugged into the design language representation.
Each of them is offering a consistent set of tools to handle a
specific problem related to distribution.
ce
I ion
I II I Tools
b
Lifecycle phases
Figure 2: Architecture of the distributed application support
environment
The language as well as the tools shall provide lifecycle-
spanning functionality. This is achieved by facilities for incom-
plete specification combined with runthe mechanisms to exe-
cute incomplete application designs. The language and the tools
are described in closer detail below.
3.2. Design Language Support
The design language consists of a declarative part describing
structural configuration aspects and a procedural part describ-
ing computation. It is based on a toplevel object class hierarchy
offering generic classes relevant for distributed applications
(fig. 3). The three major categories are configured objects, gen-
erated objects and relation objects. Configured objects are
separately managed by configuration support mechanisms
while generated objects are managed by the runtime system
only. The language elements associated with these kinds of ob-
jects represent a configuration notation and a distributed pro-
gramming notation, respectively. The configured object class is
further specialized into subsystems (means of modular structur-
ing), independent objects (active objects with independent flow
of control), servers (objects offering chargeable and abortable
services with delegation mechanisms), permanent data objects
(representing non-volatile data like name tables), and event
generators (objects generating event objects to trigger tool acti-
vations and to simulate stimulation by extemal sources). The
generated object class is divided into data objects (basic vola-
tile data), threads (lightweight processes with invocations
which are potentially distributed among different nodes), and
event objects (representing typed events produced by event
generators).
The relation objects represent semantic relations explicitly. Our
current approach includes three kinds of relation classes, colo-
cations (describing objects to be moved to a common location
during specific time intervals to reduce expensive remote com-
munication [23]), communication relations (describing com-
plex n-party interactions between objects similar to [lo]) and
cooperation relations (describing dependable distributed algo-
rithm executions).
Figure 3: Toplevel object class hierarchy of the
design language
The computational part of the language is reflected by the gen-
erated objects and by an object-oriented model of computation
similar to [3]. In particular, the language offers methods, loca-
tion independent method invocation facilities, and conventional
control structures. A specific feature is the ability of incomplete
specifcation. That is, a method can already be partially exe-
cuted if its body is even not complete. For example, an anima-
tion of the invocation of the involved objects can be performed
without having detailed information about the exact invocation
sequences.
The structural part of the language is reflected by the config-
ured objects with associated configuration management sup-
port. These objects provide facilities for hierarchical abstrac-
tion (by nested subsystems), for explicit object allocation (by
specific placement instructions), for explicit specification of
395
logical interobject communication connections, and for dy-
namic structural changes (e.g. by creating new nested subsys-
tems and integrating them into the existing structure).
The relation part of the language is used to integrate
distribution-specific tools. In particular, these relations repre-
sent explicit semantic information used by dedicated work-
benches. For example, the communication relations are ex-
ploited by communication control tools managing interactions
among object groups. The colocation relations are used by mo-
bility control tools which move communication objects to a
common location dynamically.
The design language approach achieves two major goals: the
explicit representation of semantics and the integration of com- .
putation and configuration. The basic mechanisms conform to
existing approaches mentioned in section 2.
3.3. Basic Runtime S u ~ ~ o r t
An interpreter of the design language and a target runtime sys-
tem of the environment provide basic runtime support. The in-
terpreter has the task to execute an even incomplete design. As
efficiency is not essential in early design phases, an interpreter
approach is suitable due to its flexibility. It will be combined
with an animation tool to provide graphical feedback to the de-
veloper. A specific feature of the interpreter is the ability for
explicit interaction with the developer in case of incomplete
specifications.This way, the developer can decide dynamically
which actions should be performed when reaching an incom-
plete method body (e.g. ignore it, perform modest animation, or
request explicit specification of objects to be invoked).
To increase the efficiency of a relatively complete design, a
compiler will translate it into an object-oriented target lan-
guage. A prerequisite for that is the availability of complete
method bodies. The additional semantic information provided
by the relation classes is then translated into dedicated data
structures which are addressed by objects of the target language
and which are still exploited by runtime tools.
3.4. Tool Su~uort
Different tools of the environment can be integrated into tool
sets [25]. A tool set is oriented towards a common goal, uses a
common internal data representation and should provide a
common look and feel at its human computer interface [20]. Ex-
amples of tool sets in our environment are:
Distributed confguration management: This tool set is sup-
porting coarse-grained structure and allocation control of a
distributed application. It consists of a language compiler,
an initial configuration manager generating an initial con-
figuration based on a placement heuristics, and a configura-
tion change manager performing dynamic configuration
changes.
Mobility control: The goal of this tool set is to colocate
communicating objects during intervals of intensive com-
 munication. It is based on the colocation relations men-
tioned above. It consists of a compiler component to d e f i e
colocations, a distributed runtime protocol implementing a
policy to move objects together including a heuristic valu-
ation, and a monitor component to generate and modify co-
locations [23,24].
Communication abstraction: This tool set is providing
means for explicit specification, for animation and for
analysis of n-party interactions. It comprises a compiler
component, a graphical animator and an interactive debug-
ging facility.
Cooperation management: This tool set is supporting the
specification and management of dependable distributed al-
gorithms. It also comprises a compiler component, and a
runtime manager performing algorithm execution and
checkpointing and a monitor analyzing algorithm execu-
tion, e.g. to generate information about communication fre-
quencies.
Animation tools: These tools are of auxiliary nature and do
not treat a specific problem of distribution like the tools
mentioned above. The animation of a design can be divided
into a structural, static part (based on configured objects),
and into a computational, dynamic part (based on method
executions on configured and generated objects). The im-
plementation of the animation will be based on X windows.
The tool sets are plugged into the design language via specific
relation classes representing major semantic information used
by its tools. As discussed above, the different tools can be clas-
sified into management tools using semantic information to
control application execution, analysis tools generating seman-
tic information, e.g. using monitor approaches, synthesis tools
performing syntactical and semantical transformations, and
auxiliary tools providing tool integration facilities.
3.5. Stevwise Development Support
As opposed to other approaches, stepwise development is per-
formed in a seamless way using the design environment. This
is achieved by the widespectrum approach, i.e. the offered de-
sign objects cover a wide range of semantic design information
ranging from very coarse-grained structural descriptions to a
detailed executable specification. An example of a stepwise
top-down design method using the apporach can be described
as follows:
e Toplevel subsystem design: In this step, the toplevel sub-
systems of an application together with their interfaces are
designed. This is of purely declarative nature; the result can
only be animated in a static way.
Detailed subsystem design: In this step, the hierarchical ab-
straction facilities of subsystems are applied. That is, the
detailed nested structure of all subsystems is specified. As a
396
result, a static animation as well as the animation of dy-
namic structural changes can be performed.
Subsystem functionality: During this step, basic objects
(servers, independent objects, event generators, and perma-
nent data objects) are introduced into the bottom-level sub-
systems. This way, the subsystem functionality is detailed
from an abstract interface specification to a concrete inter-
nal structure with dedicated objects. In addition, required
types of generated objects (but no instances) should be de-
f i e d now.
Specification of object methods: Now the methods of the
basic and generated objects can be specified. Even if their
implementation is not given during this step, means for ab-
stract specification of their functionality can be exploited.
For example, the set of related invoked objects can be de-
scribed declaratively.
Specification of semantic relations: To exploit the special
tool functionality described above, semantic relations
among the design objects have to be specified. This step,
however, is relatively independent from the other steps. Its
only prerequisite is the existence of a declarative specifica-
tion of the objects to be related (but not their implementa-
tion).
Method implementation: Finally, the implementation of the
defined methods has to be performed. Even during this
step, a stepwise design is possible. In particular, detailed in-
vocation specifications can be replaced by more vague in-
vocation intensity descriptions or by non-deterministic se-
lection of invoked objects.
These steps can be applied in an iterating way and can also be
exchanged by each other. In addition, more formal design
methods based on the environment will be investigated in order
to provide rule-based design transformation support with ex-
plicit developer interaction.
4.Advanced Issues and Requirements
Besides the problems covered by the distributed application de-
sign approach, a number of advanced issues and requirements
can be identified and could be covered in the future by specific
workbenches.
4.1. Devendabilitv Support and Distribution
For several years, dependability has been recognized as an im-
portant issue in the face of distribution. First, additional kinds
of faults are present in such an environment; nodes can fail in-
dependently and intemode communication can fail, too. Sec-
ondly, independent redundant components can be introduced
into a distributed environment relatively easily. Existing ap-
proaches towards dependability can again be divided into
structural and computational ones.
Structural support for dependability can be provided by struc-
tural reconfigurations based on dynamic configuration manage-
ment [15]. In particular, altemative modules providing the
same service as a module running on a faulty node can be in-
troduced. This can be performed by switching all logical mod-
ule interconnections from an old module to the new one replac-
ing it. Moreover, structural redundancy can be introduced by
establishing l:n interconnections from client modules to associ-
ated server modules. In addition, announced failures can be
handled by migrating modules to different physical nodes if the
underlying operating system is supporting module mobility [3].
Computational dependability support is provided by atomic
distributed operations (which can be rolled back without effects
in the case of failure) [22], by replicated remote procedure calls
and distributed recovery blocks (guaranteeing success if at least
one operation execution succeeds) [27], and by data replication
facilities (guaranteeing data accessibility in the case of node
failures) [8]. In addition, support can also be given at system
level by secure transport communication protocols, by fault-
tolerant routing, and by reliable broadcast operations.
As opposed to the computational mechanisms, structural fault
tolerance support can help to avoid future application errors but
can hardly be used to handle and correct current failures.
Therefore, a combination of computational and structural
mechanisms is required. In addition, none of the existing sys-
tems is supporting an automatic structural handling of failures.
That is, the described mechanisms can only serve as a base for
a higher-level approach. Related important requirements are
the system-based analysis of a failure, the derivation of appro-
priate configuration change operations, and the following exe-
cution of these changes.
4.2. Heterogeneitv Issues
The presence of heterogeneity in most current distributed envi-
ronments leads to additional requirements concerning distrib-
uted application support. First, application entities cannot be al-
located to each arbitrary node due to different resource
availabilities. For example, a file server component requiring
direct disk access cannot work on a diskless system. Therefore,
the configuration language has to support the specification of
static placement restrictions for configured objects.
Secondly, heterogeneous nodes usually have different intemal
data representations. Therefore, intemal object data have to be
converted transparently by the system when an object moves
between different heterogeneous nodes. Thirdly, the set of ap-
plication object types offered by different nodes can vary sig-
nificantly. This leads to mobility restrictions, i.e. an object can
only move to nodes where its type and the associated binary
implementation code is available. In addition, systems like Em-
erald [3] allow the dynamic installation of object types after
object migrations at runtime. However, this is also hardly feasi-
ble when different implementations of the same application
391
type shall coexist in a heterogeneous system. In summary, het-
erogeneity is associated with several additional requirements
conceming the configuration language and conceming the run-
time environment.
4.3.Multiparadigm Apuroaches
The approach presented above is based on a uniform object-
oriented model of computation and communication. However,
in special cases, this uniformity seems not adequate. For exam-
ple, bulk data transmission is hardly supported by distributed
object-oriented approaches. As opposed to that, RPC exten-
sions supporting efficient bulk data transfer have already been
developed [ll]. A combination of such an approach with the
object-oriented techniques seems desirable. A direct mapping
of bulk data transfer at application level onto underlying trans-
port protocols would be possible by this multiparadigm com-
munication approach.
An additional example of a multiparadigm facility is the multi-
language approach. While purely object-based languages like
Distributed Smalltalk or Emerald provide uniformity, other im-
plementation languages (e.g. C++) are even more optimized
for efficiency but do not focus on distribution. A combination
of such languages in large applications seems desirable. For ex-
ample, the intemal implementation of a stock manager of the
presented application could be done in C++ while all code rele-
vant to distribution aspects (e.g. remote access to production
plans) should be implemented in a distribution-oriented lan-
guage. This requires sound interface specificationsbetween the
coexisting languages, an issue which is still open.
A very different requirement associated with our approach is
the management of software engineering data. W e our cur-
rent prototype is based on a conventional file approach, more
advanced mechanisms using databases are required. Important
issues are versioning of design data, concurrent access to these
data with long-durating transactions, and even distribution of
design data among cooperating workstations.
While the fist two requirements are covered by current data-
base technology to a large degree, the third issue is important
for our work. A simple data distribution can be performed by
remote database access facilities. However, a full approach to-
wards cooperative distributed work is stating additional re-
quirements conceming the direct exchange of design data and
conceming the synchronization of different design activities.
An advanced group coordination approach has to be developed
and has to be integrated into a design environment as described
above. Additional difficulties are associated with the considera-
tion of node faults during software engineering activities. Only
few approaches focussing onto this direction have been pre-
sented until now. This will be an interesting research area of
the future.

5. Conclusion
The paper has given an overview of an integrated model, lan-
guage and tool approach to support distributed application de-
velopment. Based on the distributed object paradigm, powerful
support can be provided to the application developer this way.
The presented environment facilitates tool integration and shall
provide a common human computer interface for a l l different
services offered by it. A prototype implementation of some tool
sets has already been completed; the language support is cur-
rently under development as part of the joint project DOCASE
of the University of Karlsruhe and Digital Muipment Corpora-
tion [20]. Additional important requirements concerning dis-
tributed application support have been summarized. An inte-
grated treatment of these issues within a design environment
seems desirable.
Future work will focus on the implementation of the environ-
ment. In addition, further conceptual work will be concemed
with extensions of the communication abstraction approach,
e.g. with stepwise development, animation and reuse of com-
plex communication patterns. Detailed analyses of mobility
control policies are also part of our future work. The issues
summarized in the last section will be part of more distant fu-
ture work.
References
B.N. Bershad, D.T. Ching, E.D. Lazowska, J. Sanislo, M. Schwa&
A Remote Procedure Call Facilityfor Interconnecting
Heterogeneous Computer Systems
IEEE Trans. on Software Engineering, Aug. 1987
J.K. Bennett
The Design and Implementation of DistributedSmalltalk
OOPSLA ‘87 Promedings, ACM 1987
A. Bladc, N. Hutchinson, E. Jul. H. Levy, L. Carter
Distributionand Abstract Types in Emerald
lEEE Trans. on Software Engineering, Jan. 1987
A.D. Birrell. B.J. Nelson
Implementing Remote Procedure Calls
ACM Transactions on Computer Systems, Feb. 1984
T.J. Le Blanc, S.A. Friedberg
HPC: A Model of Structure and Change in DistributedSystems
IEEE Trans. on Computers, Vol. c-34, No. 12, Dec. 1985
G. Booch
Object-OrientedDevelopment
IEEE Trans. on Software Enginering, Vol. SE-12, No. 2, Feb. 1986
J.S. Chase, F.G. Amador. E.D. Larowska, H.M. Levy, R.J. Littlefield
The Amber System: Parallel Programmingon a
Network of Multiprocessors
lnternalReport, University of Washington, Seattle, 1989
Cornafion
DistributedComputing Systems
Elsevier SciencePublishers, Amsterdam 1985
P.L. McCullough
Transparent Fomanling: First Steps
OOPSLA ‘87 Proceedings, ACM 1987
N. Francez. B. Hailpern
Script: A Communication Abstraction Mechanism
OperatingSystems Review, No. 2. Apr. 1985.pp. 53-67
D.K. Gfford, N. Glasser
398
Remote Pipes and Procedures for Efficient
DistributedCommunication
ACM Trans. on Computer Systems, Vol. 6,No. 3, Aug. 1988
HOOD ReferenceManual
CRl lntemationaleMatra. 1987
C. Horn
An Object Oriented Modelfor DistributedProcessing
Workshop on Research into Networks and Distributed mlications,
Wim 1988, North Holland, 1988
E. Jul, H. Levy, N. Hutchinson, A. Bladc
Fine-Grained Mobility in the Emerald System
ACM Transadions on Computer Systems, Vd. 6, No. 1, Feb. 1988
J. Kramer, J. Magee
Dynamic Configuration for DistrbutedSystems
lEEE Trans. on Software Engineering. SE-11(4). April 1985
R.J. LeBlanc, A.B. Maccaix
The Design of a Programming Language Based on
Connectivity Networks
Proc. IEEE 3rd Inif. Conf. on DiWbutsd Computing Systems,
Ft.. Lauderdale, Florida, Oct. 1982
B. Liskov, L. Shrira
Promises: LinguisticSupport for Elfiaent Asynchronous
Procadure Calls in DistributedSystems
ACM Sigplan ‘88 Conference on Programming Language Design
and Implementation,June 1988
V.R. Lesser, D. Serrain, J. Bonnar
PCL A Process-OrientedJob Control Language
Proc. 1st lnt. Conf. on Distnluted Computer Systems, 1979
J. Magee, J. Kramer, M. Sloman
Constructing DistributedSystems in Conic
lEEE Trans. on Software Engineering, Yd. 15, No. 6, June 1989
M. MOhlh5user. A. Schill, L. Heuser
Project DOCASE: Software Engineering for Distributed Applications:
An Object-OrientedApproach
Int. Workshop Software Engineeringand its Applications:
Toulouse, 1988
M. MUhlhSuser,A. Schill. J. Kienh6fer, H. Frank, L. Heuser
A Software Engineering Environment for DistributedApplications
Euromicro, Kdln 1989
D.P. Reed
Implementing Atomic Actions on Decentrdied Data
ACM Transactions on Computer Systems, Vd. 1, No. 1, Feb. 1983
A. Schill
MobilityContrd in DistributedObject-Oriented Applications
/E€€ Int. Phoenk Conf. on Computers and Communications,
Scottsdale, Arizona, March 1989
A. Schill
Support for Mobility Control and Configuration Management
in DistributedObject-OrientedApplications
2nd Int. Workshop on Objects and Distribution, DECUS Symposium.
Kar/sruhe. April 1989
A. Schill
Objects and Distribution:Advantages, Problems and Solutions
Int. TOOLS Conf., Paris, Nov. 1989
AS. Tanenbaum, R. van Renesse
A Critique of the Remote Procedure Call Paradigm
Workshop on Research into Networks and Distributed apPlications,
Wien, April 1988. North Holland1988
K.S. Yap, P. Jalote. S. Tripathi
Fault Tolerant Remote P r d u r e Call
10th Int. Conferencs on SoRware Engineering, Singspore 1988