tools which filter out OS requirements from the application design. 1. Introduction. The relative costs spent for software development in high-tech products have ...
Customization of System Software for Large-Scale Embedded Applications* J. Nehmer, P. Sturm, M. Baentsch, L. Baum, G. Molter, S. Rothkugel University of Kaiserslautern Department of Computer Science P.O. Box 3049, D-67653 Kaiserslautern Email:{nehmer,sturm,baentsch,lbaum,molter,sroth}@informatik.uni-kl.de Abstract Operating systems are one of the most frequently reused software components: almost every application is sitting on top of an OS which establishes the required runtime platform. It is claimed that bridging the gap between a high level application design and the OS is a costly process, especially in distributed systems. A conceptual framework is presented which aims at supporting the automatic generation of distributed runtime platforms from high-level application designs. It is based on the generic layout of operating system services, their extended description including nonfunctional properties, as well as analysis and development tools which filter out OS requirements from the application design.
1.
The paper is organized as follows: Section 2 introduces the basic terms and concepts of today’s distributed OS technology and exposes the reasons for the increasing costs in the aforementioned mapping process. Section 3 describes the scenario of a generic OS approach integrated into a software development environment which aims at an automatic generation of dedicated runtime platforms. In the following two sections first results in the area of parameterized OS services and tool support at the time of application development are presented. This paper concludes with an overview on related work in the area of customizable system software.
application process
Introduction
The relative costs spent for software development in high-tech products have been growing continuously over the past. In certain products and services of the telecommunications industry the software costs have exceeded the costs for hardware development and equipment. While this trend is going to continue, software development technology will become the key for staying competitive in the high-tech market. These observations are particularly true for large domain-specific embedded systems with functional and non-functional requirements changing from application to application. The paper focuses on the interfacing problem between distributed applications and the distributed OS. The final design step in the development process of a large distributed application requires to map the logical design onto the abstractions and mechanisms provided by the OS. This mapping process may be viewed as a kind of OS reuse. It is increasingly costly, especially in distributed applications. We outline an approach which might lead to a substantial reduction of these costs.
runtime platform runtime library 3 runtime library 2 runtime library 1
standard servers
OS kernel Fig. 1: Kernel-based OS architecture
2.
Problems with present OS Structures
Operating systems have undergone substantial changes in their architecture and functionality over the past. The old-fashioned monolithic OSs offered a fixed set of mechanisms accessible via their call-interface. An application had to use this interface as it was: modifications were virtually impossible and required the expertise of the OS
* This work was funded by the DFG as part of the Sonderforschungsbereich SFB501 „Development of Large Systems with generic Methods“, Research project B5 (GENESYS)
Computer Communications, Vol. 20, Elsevier, June 1997
increase of the size of service interfaces for the development of distributed applications, for example due to the inherent complexity encountered when using group services [5].
search / mapping costs
designers. As a consequence, the abstractions offered by the OS determined the final software structure of the application and not vice versa as one might desire. Conflicts in terms of application requirements which could not be satisfied by the OS mechanisms occurred frequently (e.g. the application would like to assign priorities to processes but the OS doesn’t offer the concept of process priorities). With kernel-based OS architectures as first introduced in UNIX [13] the monolithic structure of OSs was replaced by a highly extensible, open system structure with simple mechanisms for extending/exchanging the existing OS functionality. This was achieved by dividing the operating system in a kernel with a minimal set of universal, elementary mechanisms and a layer composed of a hierarchy of runtime libraries and basic servers as illustrated in figure 1. The needs of distributed systems have pushed this development further leading to today’s microkernels [1,14] or even picokernels [2] with the attempt to minimize the kernel’s functionality and to maximize its universality at the same time. The advantages of kernel-based architectures are obvious: almost any conceivable runtime platform for a given application can be configured by the proper combination of runtime routines running in user space and additional servers each executing in separate address spaces. However, the following train of thought shows that kernel-based OS architectures, although very flexible in their potential of supporting applications with a broad variety of dedicated runtime needs, obey a fundamental problem. Consider the existence of a kernel-based OS with an infinite library for the support of runtime platforms. It would support the composition of any runtime platform with a predefined functionality. Clearly, such a system would not be very useful since finding the right components in the library which make up the runtime platform would take arbitrarily long time either. In figure 2 the software development costs for an application project are represented in terms of mapping and search effort as functions of the library size. For each kernel-based OS technology there exists an optimal size of the library where the total software development costs are minimal. A smaller library size increases the costs due to extensive development and adaptation efforts necessary for bridging the gap between application needs and the existing OS functionality. A larger library size beyond the optimal size increases the costs due to excessive search time. This relationship between total software development costs for a given application and the size of reused libraries has been observed also in [10] and indicates that adding more functions to a library is not always sufficient to lower the software development costs for applications. The C-library under UNIX has already reached a size which is hard to manage for unexperienced programmers writing sequential programs. We expect a tremendous
search costs
mapping costs
reduced search costs
OS library size and complexity Fig. 2: Costs for searching in the OS library and costs for mapping a particular application onto existing kernel-based OS technology as a function of OS library size
3.
The GENESYS Project
The problem of mapping applications to their runtime platform can be addressed by two mutually dependent approaches. First, further specialization of OS interfaces can narrow the gap between the application’s needs and what the OS can offer, thus moving along the x-axis towards reduced mapping costs (figure 2). However, such specialized interfaces lead to the already mentioned increased search and configuration effort. The approach can thus only be applied in combination with a second step: the automation of the mapping process. This can be achieved by extensive employment of tools supporting the search for suitable interface variants and inducing proper configuration of OS services. The effect would be a less dramatical rise of search costs for increasing library sizes (dotted curve in figure 2). The combination of both ideas forms the basis of our work in the GENESYS project. GENESYS (GENEric SYstem Software) is part of the long-term research project SFB 501 “Development of large systems using generic methods“ which has its primary application scope in large distributed embedded systems. Started in 1995, the SFB 501 brings together research groups working on computer networks, operating systems,
Computer Communications, Vol. 20, Elsevier, June 1997
formal methods, software engineering, and expert systems. The GENESYS project is aimed at investigating new operating system structures and adequate application programmers interfaces (API) which ease the development of distributed embedded applications. The project’s objective also is to actively support the selection, configuration and tailoring of operating system infrastructures after the placement of application entities in a distributed execution platform has taken place in an earlier development step. A longterm goal is to generate application-specific OS run-time support automatically. To put these ideas into practice, the GENESYS project is focusing at the following three fundamental concepts and their combination: a) generic design of OS services and models; b) extended formal description techniques for OS service interfaces, abstractions, models, and application’s requirements; c) analysis and development tools supporting the detection of OS requirements and the selection and configuration of appropriate OS models and service interfaces. Generic design of OS services and models is the prerequisite for the reuse of OS components in environments changing with different application’s requirements. Generic designs will allow easy derivation of specialized OS components and interfaces by assigning meta parameters that reflect the application’s requirements. Ideally, these requirements would be extracted mechanically from high level application designs by special analysis tools. Development tools would automatically translate the requirements into parameter settings, and would select and configure appropriate OS components and interfaces. In order to allow such
automated processing, formal descriptions of OS models, interfaces, and requirements are inevitable. Figure 3 outlines this approach for automated reuse of OS technology: In the ideal software development process, the OS kernel, basic servers, and the adaptation layer are generated resp. configured with no intervention from the application designer. A promising basis for the generic design of OS functionality form our investigations in advanced APIs and goaloriented parameters, while the aspect of tool support based on formal descriptions is addressed by our current effort in Interactive Libraries. Advanced APIs are basically objectoriented interfaces to the functionality of operating systems with special emphasis put on the isolation of parameters that distinguish different interface variants. These parameters of an API are defined in terms of structure and semantics of the OS services. Appropriate parameter settings for a given application therefore require in-depth knowledge about the OS services used. Since application programmers are usually no operating systems experts, a second level of parameters called goal-oriented parameters was introduced, defining variants of APIs in terms of application’s requirements. In such a way, goal-oriented parameters are closer to the abstractions the application deals with. They belong to that kind of parameters tools could get as inputs from application designs or directly from application programmers in order to select appropriate values for the Parameterized APIs. Tools supporting the application programmer in configuring and using OS components in the form of libraries obviously need formal descriptions of the APIs they handle. The combination of a conventional library, the description of syntactic and semantic knowledge about the library, and appropriate assistant tools exploiting such descriptions was termed Interactive Library. Besides precise and detailed spe-
application development
requirements
....
application
documents examples experiences interfaces
generate
development and analysis tools
applicationspecific adaption layer
OS configure
operating system technology Fig. 3: Architecture of the system supporting the automated reuse of OS technology
Computer Communications, Vol. 20, Elsevier, June 1997
application domain “embedded systems”
cifications of the functional interface, Interactive Libraries offer common usage scenarios and can automatically prepare complete code fragments needed to make proper use of the library. Together with the corresponding assistant tools, Interactive Libraries are our first generation development tools working on formal interface descriptions and facilitating the selection and configuration of OS services. In the near future, Interactive Libraries will be integrated into a globally distributed software development environment [3,4] which uses the WWW as a document repository and Web server as agents for remote compilation and linking operations.
4.
Parameterized Services
Operating system services must provide sufficient flexibility to be tailorable to specific application needs. In many systems the flexibility is available to application programmers by adding parameters to existing function calls and by providing functions dedicated to configure service behavior (e.g. consider the functions ioctl() and fnctl() in UNIX). Obviously, this approach does not simplify the interface to OS services. On the contrary, it adds to the complexity of the interface, the service’s mere functionality becomes blurred, and there is no clear separation between functional and non-functional properties. Many modern systems provide object-oriented interfaces to their services. However, object-orientation alone is not the solution; it’s only a useful paradigm when applied with care. The advantages when used as a technique for interface description are the provision of abstract data types and the potential to integrate seamlessly application-specific behavior by means of derivation and polymorphism. The disadvantages are the object-oriented decoration (which increases the size of interfaces) and sometimes the exaggeration with derivation hierarchies which both add to the overall complexity. Another interesting candidate technique in the area of object-orientation to be applied to concise interface design are design patterns [7,15]. A design pattern represents conceptual, structural, or behavioral relations between classes explicitly. For example, consider a class that can be instantiated only once. This relation can be expressed explicitly by applying the Singleton design pattern[7]. Typically, in common object-oriented design this relation is expressed implicitly and can be detected only by time-consuming code inspection. Or even worse, the class name is contaminated and tells about this non-functional property. Design patterns may have a positive influence on the re-use of software— especially if only parts of a service are used—since they describe dependencies between classes which are hard to discover otherwise. But at a first glance, they introduce further classes to the interface and they may also enlarge deri-
vation hierarchies. application program advanced API service abstraction 1
service abstraction n
parameterized service variants parameterized classes implementing the service basic mechanisms Fig. 4: Structure of an parameterized service
The approach chosen in the GENESYS project uses object-orientation and design patterns for the definition of OS APIs. As shown in figure 4, the general structure of an operating system service consists of three layers. The two lower layers, typically not visible to the application programmer, provide basic mechanisms and policies necessary to implement the service. They comprise a set of classes and pattern classes which are parameterized in order to provide the maximum flexibility for the adaptation to applicationspecific requirements at implementation time. Among other aspects these parameters influence the quality of service, the amount of control by the application, performance as well as memory usage aspects, and the degree of flexibility on the level of instances1. The upper customization layer defines service abstractions—variants of the service—suitable for different kinds of application areas. In this layer, a second set of parameters enumerates common abstractions of an operating system service as anticipated by the service developer. Each service abstraction is represented by a specific pattern class. In terms of design patterns, these classes are most often mediators. Mediators allow for the encapsulation of a set of interacting objects. Thus, application objects do not necessarily need to refer to objects in the lower layers explicitly. The main purpose of these pattern classes is to reduce the
1. This “degree of flexibility” should not be mixed up with the flexibility required for OS-APIs during the development process. The first one defines the amount of flexibility a given instance of the OS service offers at run-time. The latter characterizes how flexible the OS-API is to be tailored to application-specific requirements
Computer Communications, Vol. 20, Elsevier, June 1997
complexity of the service as presented to the application programmer by means of grouping only the functions that are needed in this abstraction and by providing access functions with a minimal number of parameters. Typically, the class hierarchy of the service abstractions is also decoupled from the derivation hierarchy in the lower layers. By these means, two different ways to incorporate application-specific semantics into an operating system service are provided. In most cases, it may be sufficient for the application programmer to add specific behavior by deriving application classes from service abstractions without changing the semantics of the lower layer by means of polymorphism (due to the decoupling of derivation hierarchies). As a result, application programmers have to deal with a manageable number of classes (namely the service abstractions only) and—most of the time—with a much simpler derivation hierarchy. In case no service abstractions meet the application needs, application-specific semantics have to be incorporated at the level of mechanism and policy classes. Obviously, in this situation the actual structure of the parameterized operating system service is not adequate, leaving a service architecture based on design patterns which might at least ease the task of implementing a further service abstraction which is better suited to the application requirements. Parameterization of operating system services has been applied to several important functional areas of the UNIXAPI such as TCP/IP communication, memory management, and synchronization of UNIX processes. To illustrate the concept, the structure of the TCP/IP communication service is presented in terms of the three layers. The library offers two main service abstractions at the customization layer: connection-oriented communication based on the TCP protocol and connectionless communication using UDP. Derived from the connectionless communication are service abstractions that provide multicast and broadcast communication as well as reliable exchange of UDP packets using a sliding-window protocol. Depending on the selected service abstraction, only the functions needed are available to application programmers. For example, the connection-oriented abstraction provides all the required functions dealing with connection establishment such as listen(), accept(), and connect(), while the connectionless abstraction supports only functions needed for sending and receiving messages. The policy layer defines classes needed to realize the notion of addresses for peer-to-peer as well as group communication. A second group of classes implements the different communication semantics offered by this service. In the mechanisms layer various classes handle technical details, e.g. some classes translate address semantics into a given protocol family such as TCP/IP and other classes realize communication semantics in terms of UNIX sockets. By these means, the communication service can be ported to another
protocol family by simply providing additional classes in the mechanism layer. Design patterns such as abstract factory and bridge are applied to separate interface and implementation in order to ease service adaptations of this type. The current versions of parameterized operating system services are useful as long as the application requirements can be satisfied to a large extent by the service abstraction. Nevertheless, there remains a deficiency observed while implementing application prototypes: setting of parameters in these libraries requires detailed knowledge about the behavior of the requested services. This is due to the bottom-up parameterization which is based on structural and functional considerations. To enable application programmers who are no operating system experts to use parameterized services, another layer of parameters has to be added. These goal-oriented parameters determine service abstractions in terms of application requirements, thus providing a top-down enumeration of available service variants. With the consecutive setting of several high-level parameters, a refinement process takes place. Eventually, this process leads to the parameters already available in advanced APIs. At this stage of application implementation, hopefully only few service abstractions suit well application requirements and the programmer only needs to understand these abstractions. Another problem which has not been addressed yet is the composition of several services within one application. Due to conflicting parameter settings as well as direct and indirect dependencies between instantiated services, various side-effects and all kinds of interferences may be introduced. Thus, the combined usage of several operating system services in one application program might result in a parameter setting that conflicts with the isolated setting for each single service. For example, consider a service offering realtime streams required to communicate audio and video data accurately. This service depends on the scheduler to receive a given amount of computing time periodically. By instantiating this real-time stream multiple times, eventually a situation will arise where the scheduler is not able to satisfy all timing requirements. It is currently discussed, how to augment the interface description of an operating system service to model and quantify non-functional dependencies in order to make these dependencies visible to the application programmer as well as to recognize and resolve static conflicts already at development time.
5.
Interactive Libraries
Normal and advanced APIs represent the functionality operating system services provide. They comprise the complete set of data structures and functions defined for the interaction between services and applications. Besides this, there is much more information needed to apply the service cor-
Computer Communications, Vol. 20, Elsevier, June 1997
rectly, e.g. the required sequence of calls to service primitives to solve a given problem, the proposed application structure especially in the case of upcall techniques, or argument dependencies between separate calls. Typically, this information is available in form of manual pages, tutorials, and—a resource often used—in the source code of other programs. Interactive Libraries (ILs) on the other hand are aimed at using such knowledge for actively guiding developers while implementing application code. Each library implementing services can be seen from two different points of view. The developers primarily need to recognize and specify the functionality they expect the library to perform in their application. From the library developer’s point of view, the library services need to be selected and configured in a semantically correct way to perform the desired task. There is a gap between these two views that is based on a different terminology and different profoundness of knowledge. The guidance Interactive Libraries offer is aimed at bridging this gap. Besides a detailed description of the functional interface of a service, Interactive Libraries incorporate semantic information about how to apply it correctly. This information can for instance be used to construct scenarios illustrating the employment of the library service. The scenarios are adapted dynamically to the actual implementation stage by interacting with the developers. Thus, Interactive Libraries are able to provide stage-specific information, e.g. which calls to the service should be issued next.
bing semantic knowledge about how the service primitives are intended to be used. Each usage rule describes how to accomplish a given task using library primitives. To this end, a usage rule consists of a precondition, a statement part, and information about the side effects associated with the execution of the primitives. The precondition depicts certain requirements on the state of the service instance that have to be met before the associated library primitives are applied. The statement part contains the source code for achieving the task modeled by the usage rule. The ongoing side effects on the state of the service instance affect the alternatives for the task to be performed next. The semantic knowledge represented by the usage rules is exploited during application development by an assistant tool. By interacting with the programmer, it keeps track of the usage state of a library service, i.e., it records which service primitives have been used so far and in what order. Based upon this information, the assistant can make proposals to the programmer about the next steps at employing the library. To this end, the tool determines which rules may be applied in the current state by evaluating their preconditions. All rules whose preconditions are satisfied are presented to the developers as alternatives. The source code associated with these rules represents legal ways of using the library service.
... Development support tools
Semantic information Advanced APIs Library Code Interactive Library Fig. 5: Structure of Interactive Libraries
The structure of an Interactive Library is depicted in figure 5. Besides the library code itself, it comprises one or more advanced APIs for operating system services. In addition to this mere structural information, an Interactive Library also contains the definition of usage rules descri-
Fig. 6: User interface of the assistant program
In figure 6, the user interface of the assistant program is shown. At this stage of the development process, the programmer can decide between two alternatives (top of
Computer Communications, Vol. 20, Elsevier, June 1997
figure). After selecting the first primitive, the programmer is shown more information about its semantics, and the corresponding code fragment. In this prototype implementation, when the selection is accepted by the user, it is simply made ready to be inserted into the application source code. Since there is no further coordination, the state of the implementation process and the state maintained by the assistant program may drift apart; an error only the developer may detect. It is currently discussed how to extend the EMACS editor in order to couple it tightly with the assistant and thus ensure better consistency of the state information. Tight coupling with an editor is also important if the user shall be given the possibility to backtrack the usage history, because otherwise there is no way of supporting the removal of code that was suggested by the assistant. Another extension of the assistant tool consists in integrating an explainer facility for answering, for example, the programmer´s question why a certain service primitive cannot be applied in the current usage state. To this end, the assistant can evaluate the precondition in the different stages of the usage history. In this way, it is possible to check if the precondition was invalidated by a previous state transition, or if it has not been true in any of the usage states within the history. The information stored in Interactive Libraries can also be used for a variety of different purposes. For instance, it is possible to perform a call graph analysis on the application source code and check the resulting sequence of calls to service primitives against the IL description. Similar checks can also be performed at program run-time in order to detect wrong usage of a service. Currently, there is work in progress on extending the concept of Interactive Libraries to a framework comprising authoring tools for service descriptions and tools for extracting structural information from C++ header files. Such generators can produce usage rule templates that can be instantiated and combined by means of direct manipulative authoring tools. A new version of the description language for Interactive Libraries is currently under development. It is intended to offer the full descriptive power of a general-purpose programming language for modeling semantic properties of library services. For this purpose, we chose the object-oriented language JAVA [8], that is extended by classes and mechanisms for IL service descriptions. Its use also remedies the problem that the text-based representation used so far contains no elements for structuring the service description, which is an important prerequisite for easy authoring and maintenance. By building the new description technique on top of Java, the benefits obtainable from object orientation come for free: mechanisms like encapsulation, inheritance and dynamic binding need not be implemented anew.
6.
Related Work
Research results in several areas influence our work on the topic of application-specific system software services. In this paragraph, we broadly categorize them into the realms of object oriented operating system development approaches, ideas based on the specialization of system software to application needs, and general concepts of developmenttime adaptation of runtime environments to applications needs. Therefore, after an introduction to some inherent advantages of object orientation in this area, we are presenting the basic concepts of the Spring, Choices, Panda, and Synthetix operating systems as well as an overview on the— not particularly operating systems specific—RECIPE approach. Most state-of-the-art operating systems boast an object oriented, minimal kernel with highly configurable services running on top of it. In particular, Choices (Class Hierarchical Open Interface for Custom Embedded System) [6] was an early approach to developing a class framework specially suited for the realization of embedded applications. One of the main research interests was the question whether class frameworks are suitable for the realization of higher-level operating system services. The experiences were promising, leading to a successor project, microChoices, which is no longer aiming at providing a system with a UNIX-like semantics as Choices did. In the PANDA system [2], more practical conclusions concerning the necessity for user-level threads, globally shared virtual address spaces, object and thread mobility as well as object persistence as first order mechanisms for the system software support of application development have been put forth. Although PANDA took place in a homogeneous C++ environment not taking the special needs of the embedded systems domain into consideration, those experiences will positively influence our work. Another operating system to be mentioned here is the Sun Spring kernel [9]. Its main contributions to our work lie in its realization of utmost performance for cross-domain calls via the notion of doors, an issue of particular importance as soon as the mapping of application-level activities to physical hosts has to be considered. Another interesting feature of Spring is its built-in facility for secure communications considered to be important in large scale systems. In the area of flexible, dynamically adaptable operating systems, the notion of metaprogramming as put forth by the Apertos OS [17] is important to consider. A similar approach by providing system- or programmer defined policies changing system internal behavior as appropriate for a given application is exemplified by the Kernel Toolkit (KTK) [11]. The Synthetix operating system [12] follows a slightly different path. In order to provide very good performance of particular services, specialized code is inserted
Computer Communications, Vol. 20, Elsevier, June 1997
into an operating system at either compile, load, or run time of the OS. This approach also facilitates dynamic feedback strategies in order to allow operating systems to adapt quickly to changing runtime requirements. However, all these approaches explicitly support run-time adaptation of OS services to application´s needs, whereas GENESYS wants to extend the influence the system software exerts out into the development stages of software. Nevertheless we are going to draw on such experiences in order to enhance our concept of flexible operating system services for embedded applications. The RECIPE (REusable Component Instrumentation and Programming Environment) [16] is a rather high, language level approach to the development, creation, and employment of reusable components in general and the ADA programming language in particular. The concept has a notion of a component library that has been particularly tailored for specific application domains within object-oriented software development. In this respect, it differs on our goals to provide support for the development of system software for embedded systems. The concept of Interactive Libraries as presented in our work has a parallel in RECIPE with its Prolog-based library manager. However, this manager‘s task is primarily to detect appropriate code to be reused in a vast area of reusable components. In this respect, it influences our work, but on the other hand, it does not provide the concrete guidance given by Interactive Libraries, which aim at supporting the development of embedded systems during all stages of the software development lifecycle starting with the design, carried through implementation and ending in maintenance. In summary, several promising ideas to solve the nontrivial problems outlined in this presentation of our work exist. We are planning to extend these results in various directions, the most prominent being the idea to carry the adaptation of system software services as close to the application designer as possible.
infrastructures for these applications as well as generating application-specific runtime support automatically. An approach has been presented, which is based on enhanced structuring of operating system services. The enhancements are founded on modern object-oriented design techniques and on the explicit isolation of parameters that distinguish variants of service abstractions. Parameters refer to different layers of abstraction in order to address the specific needs of different development phases. Based on parameterized services, Interactive Libraries participate actively in the implementation process and provide specific information such as usage scenarios.
References [1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
7.
Summary and Conclusion
In this paper, the influence of operating system APIs on application programming is discussed. Since these interfaces have increasing size and complexity, it is an ever timeconsuming task for application programmers to determine which services may be useful, which abstractions of operating system services are adequate, and how these services can be configured and fine-tuned to satisfy application needs. The goal of the G ENESYS project is to investigate new operating system structures and new application programmer interfaces (API) to operating system services to ease the development of distributed embedded applications. This encompasses configuring and tailoring operating system
[9]
[10] [11]
[12]
[13]
M. Acetta, R. Baron, D. Golub, R. Rashid, A. Tevanian, M. Young: Mach: A New Kernel Foundation for UNIX Development, Proc. Summer 1986 USENIX Conference, pp. 93-112, 1986 H. Assenmacher, T. Breitbach, P. Buhler, V. Hübsch, R. Schwarz: The PANDA System Architecture -- A PicoKernel Approach, Proc. 4th Workshop on Future Trends of Distributed Computing Systems, Lisboa, Portugal, pp. 470476, 1993 M. Baentsch, G. Molter, P. Sturm: WebMake - Integrating Distributed Software Development in a Structure-Enhanced Web, Computer Networks and ISDN Systems, Vol. 27, No. 6, pp. 789-800, 1995 M. Baentsch, G. Molter, P. Sturm: Booster - A WWW-based Prototype for the Global Software Highway, Proc. 2nd Intl. IEEE Workshop on Services in Distributed and Networked Environments (SDNE), Whistler, Canada, 1995 K.P. Birman, T.A. Joseph: Lightweight Causal and Atomic Group Multicast, ACM Transactions on Computer Systems, Vol. 9, No. 3, pp. 272-314, 1991 R. Campbell, G. Johnston, V. Russo: Choices (Class Hierarchical Interfaces for Open Embedded Systems), Operating Systems Review, Vol.21, No.3, pp.9-17, 1987 E. Gamma, R. Helm, R. Johnson, J. Vlissides: Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1994 J. Gosling, H. McGilton: The Java Language Environment: A White Paper, Sun Microsystems, May 1995 G. Hamilton, P. Kougiouris: The Spring Nucleus: A Microkernel for Objects, Technical Report SMLI TR-93-14, Sun Microsystems, 1993 S. Henninger: Using Iterative Refinement to Find Reusable Software, IEEE Software, Vol. 11, No. 5, pp. 48-59, 1994 B. Mukherjee, D. Silva, K. Schwan: KTK : kernel support for configurable objects and invocations, Distributed Systems Engineering, Vol. 1, No. 5, pp. 259-270, 1994 C. Pu, T. Autrey, A. Black, C. Consel, C. Cowan, J. Inouye, L. Kethana, J. Walpole, K. Zhang: Optimistic Incremental Specialization: Streamlining a Commercial Operating System, Proc. 15th ACM Symposium on Operating Systems Principles (SOSP'95), 1995 D.M. Ritchie: The Evolution of the UNIX Time-Sharing System, AT&T Bell Laboratories Technical Journal 63(8), pp. 1577-1593, 1984
Computer Communications, Vol. 20, Elsevier, June 1997
[14]
[15] [16]
[17]
M. Rozier, V. Abrossimov, F. Armand, I. Boule, M. Gien, M. Guillemont, F. Herrman, C. Kaiser, S. Langlois, P. Leonard, W. Neuhauser: Chorus Distributed Operating Systems, Computing Systems Journal, Vol. 1, No. 4, pp. 305-370, 1988 J. Soukup: Taming C++: Pattern Classes and Persistence for Large Projects, Addison-Wesley, 1994 W. Tracz: RECIPE: a reusable software paradigm, Proc. 20. Hawaii Intl. Conf. on System Sciences, pp. 546-555, 1987 Y. Yokote: The Apertos reflective operating system: the concept and its implementation, SIGPLAN Notices, Vol. 27, No. 10, pp. 414-434, 1992
Computer Communications, Vol. 20, Elsevier, June 1997
