Achieving Middleware Customization in a Configuration-Based Development Environment: Experience with the Aster Prototype Valérie Issarny, Christophe Bidan, Titos Saridakis IRISA / INRIA Campus de Beaulieu, 35042 Rennes Cédex, FRANCE fissarny, bidan,
[email protected]
Abstract Middleware configurations provide a means to make accessible a wide range of applications on a (possibly large) distributed heterogeneous platform. However, as new application areas appear, middlewareconfigurations will have to evolve to accommodate those new applications’ needs. This paper discusses the implementation of the Aster development environment that realizes automatic configuration of middleware which are customized to the applications’ needs from the standpoint of provided non-functional properties (e.g., fault-tolerance, security). The environment relies on two main tools. The first tool retrieves the software constituting the middleware that meets application requirements, by means of software specification matching. The second tool implements the interfacing of the application’s software components with the customized middleware. Interfacing is discussed in the framework of the CORBA environment, hence addressing construction of customized middleware on top of an ORB, possibly using common object services specified by the OMG.
puting, groupware and multimedia), middleware 1 will have to evolve to meet these applications’ requirements such as those relating to non-functional properties. This raises the issue of easing the construction of new middleware configurations with respect to the integration of new types of applications within the information network. Our research is aimed at providing a development environment easing both the specification of non-functional requirements within distributed applications, and the construction of corresponding customized middleware. Furthermore, we seek solutions that promote software reuse from the perspective of both application- and middlewarelevel software. Towards that goal, we have proposed the Aster configuration-based development environment [7], which is composed of:
1. Introduction The computing facilities of large-scale enterprises are evolving into a network of information services, including applications and databases on local- and wide-area networks. In order to make all these services accessible, software systems interconnecting distributed, heterogeneous services should be provided. To meet that goal, vendors have been building middleware that are implemented in a layer above the operating system and network software and below industry-specific applications [1]. Among other features, middleware configurations should run on multiple platforms, and offer standard programming interfaces and protocols so as to support the widest range of applications. However, as new application areas appear (e.g., mobile com-
A declarative language for describing a distributed application in terms of interconnection of possibly heterogeneous software components at the level of their interfaces, together with the application’s nonfunctional requirements upon the underlying middleware, and A set of tools generating stub code for the application, based on the automatic selection and/or configuration of a middleware, customized to the applications’ needs (e.g. security on exchanged data, availability of application modules, characteristics of the communication channels, etc).
The Aster environment further relies on the use of existing, possibly standard, software platforms for base distribution management. In particular, as discussed in our previous paper [6], the Aster environment is designed so as to ease the construction of applications that can run on top of any platform complying to the CORBA architecture [13]. This allows Aster developers to exploit implementations of Common 1 Using the terminology of [1], this concerns more precisely frameworks rather than middleware. However, we will keep the term middleware in this paper.
Object Services (COS) specified by the OMG for achieving middleware customization. This paper reports on our experience with the implementation of the Aster prototype, addressing in particular the implementation of the key parts exhibited in the Aster design ([6, 7]). The next section gives an overview of Aster and introduces the structure of the Aster prototype. Sections 3 and 4 then concentrate on the two main tools of the prototype: the selector that implements automatic middleware customization by retrieving the software constituting the middleware with respect to application requirements, and the tool that implements the interfacing of the application’s components with the customized middleware. The latter tool is discussed in the framework of CORBA, hence addressing actual construction of customized middleware on top of an ORB. Finally, we conclude in section 5, summarizing the paper and referring to related work.
2. The Aster Environment The Aster environment belongs to the category of software interconnection environments and it adopts the model of configuration-based distributed programming (e.g., see [15, 11]) that decouples the interconnection of the application modules from their implementations. An overview of the Aster environment is provided hereafter, followed by the description of middleware construction using Aster.
2.1. Overview As mentioned in the introduction, the Aster environment consists of: (i) the Aster language and (ii) a set of tools for constructing the middleware. The Aster language combines the functionality of the Interface Definition Language (IDL) of OMG [13] for declaring component interfaces with the flexibility of a Module Interconnection Language (MIL) (e.g., see [15]) in specifying interconnections between application modules. Moreover, it provides the ability to express the non-functional properties required/provided by software modules. The set of recognized properties is expandable since this set is defined by a database of properties, which may be updated as needed. Middleware built by Aster consists of a base middleware providing basic communication mechanisms (e.g., an RPC system such as the ORB) and a number of middleware components responsible for customizing the interconnection environment to meet the needs of a given application. A fundamental goal of our work is to determine a formal way for specifying the functionality of a middleware component and the way it interacts with its environment 2 2 This environment may consist of application components, a number of middleware components and the base middleware.
so as to allow automatic configuration of the middleware according to the required properties. The underpinning formal framework has been introduced in [7]. It relies on the formal specification of non-functional properties in terms of the first order logic. Then, given the description of required non-functional properties within the components of an application and dually that of provided properties within middleware components, software specification matching (e.g., see [21]) is used to retrieve the components of the middleware, customized to the application needs. In our framework, software specification matching consists of verifying that the conjunction of the non-functional properties provided by the middleware components and the base middleware used for customization satisfies the properties required by the application.
2.2. Application Construction Using the Aster environment, the construction of an application relies on the five following phases: (1) The specification phase that consists of describing the application’s components using the Aster language (i.e., the components’ interfaces and corresponding source code files, and the connections among them). (2) The type checking phase that implements static type checking on Aster modules and that produces module descriptions for further processing. (3) The customization phase that consists of identifying components of the middleware customized to the application needs. (4) The generation phase that takes as input the description of an Aster application together with the associated middleware and produces (i) a set of source code files interfacing with the Aster underlying platforms, and (ii) a makefile. (5) The production phase that is done by the standard compilers using the makefile. As depicted in figure 1, phases 2-4 are implemented by three basic tools (i.e., the type checker, selector, and generator) that use data bases providing the description of application and middleware components. The Aster type checker implements type checking and produces the information to be used by the selector and generator. This includes the description of the requirements for the interactions between the application’s components, i.e., the non-functional properties that must be provided by the underlying middleware. Given an application description, the selector selects the middleware components to be used for handling the interactions between the application’s components according to the interactions’ requirements. This consists of retrieving a base middleware and possibly complementary middleware components such that the conjunction of the properties
interface comp1 { op1(p1, p2, p3) provide P1, P2 require P3, P4, P5 }
interface comp1 { op1(p1, p2, p3) provide P1, P2 require P3, P4, P5 }
Properties Repository
}
interface comp1 { op1(p1, p2, p3) provide P1, P2 require P3, P4, P5 }
ASTER Type checker
Middleware Components Interfaces
Interface declarations
#include .... main() { .... printf("Hi\n"); .... exit(0); }
#include .... main() { .... printf("Hi\n"); .... exit(0); }
Properties
#include .... main() { .... printf("Hi\n"); .... exit(0); }
ASTER Selector
}
Middleware Components Repository
Middleware Components Source Code
Application Source Code ASTER Generator
Base Middleware Repository
#include
#include
... main() { ... call-Aster(...) ... exit(0); }
... main() { ... call-Aster(...) ... exit(0); }
Aster Files + Makefile
HTTP
ORBIX
}
#include
... main() { ... call-Aster(...) ... exit(0); }
...
M R e idd po lew sit a or re ie s
from selector
ASTER Type checker
3. Automatic Customization
A
pp
In
te
lic
at
rfa
io
ce
n
D
So
ec
ur
la
ce
ra
tio
Co
n
de
Figure 1. The Aster environment
phase then consists of mapping (both application and middleware) components making up A to execution units of the underlying execution platform. Several algorithms can be considered for implementing partitioning. In a first step, we undertake a straightforward solution that is to implement a one-to-one mapping. A more complex solution would be to group together components according to their compatibility and communication patterns where compatibility refers in particular to non-functional properties required and provided by components. Another approach to partitioning can also be found in [3] that discusses an implementation of the Polylith configuration-based development environment. The third phase assembles together the application components and the middleware components, including the base middleware. This phase depends upon the interfacing requirements of the base middleware, and is further detailed in section 4 in the framework of a CORBA-compliant base middleware.
ASTER Selector
Phase I: Check for executability Phase II: Partition / Clustering
ASTER Generator
Phase III: Stub code generation Aster Files & Makefile
Figure 2. The Aster generator
they implement satisfies the interactions’ requirements. For instance, in a CORBA framework, a transactional application will use a customized middleware made of the ORB and of the following additional COSs: OTS, POS and CCS for management of transactional objects, persistence and concurrency control, respectively. The selector is further described in section 3. The Aster generator produces a set of source code files interfacing with a base middleware (e.g. an ORB), from the description of a given application and of the associated customized middleware computed by the selector. This is achieved in three phases (see fig. 2), which are described hereafter assuming the treatment of an application, named A. First, A is checked for executability, which mainly amounts to verifying that all the components from which A is built correspond to implementation files. Should some sub-component of A be an interface, the selection of the corresponding implementation can be achieved either statically or dynamically by means of trading. The partition
The Aster approach to automatic customization relies upon the definition of non-functional properties in terms of formulas of the first order predicate calculus; application requirements and behaviors of middleware components are specified as conjunctions of non-functional properties. Identifying the constituents of a middleware M that is customized to the needs of an application A then consists of demonstrating the following formula (see [7]), called plug-in j 2 P j P j ) P i , where P match: 8PAi 2 PA : 9PM M M A A and PM denote the set of requirements of A and the set of behaviors implemented by M, respectively. Since a customized middleware M may be built from a set of middleware components Si enriching a base middleware B , PM is defined as: [8P 2PB P ^i=1::n ^j=1::mPSji , where PB specifies the set of behaviors implemented by B , PSi specifies the set of non-functional properties implemented by the middleware component S i and PSji is one of these properties. The Aster selector implements a software retrieval that demonstrates the plug-in match formula for any application A. In its most general form, this subdivides into the selection of a base middleware followed by the one of complementary middleware components. The informal description of the corresponding algorithms is given in the following, after a brief introduction of the data structures used as input by the selector. An evaluation of the selector is then presented.
3.1. Middleware Selection and Customization The selector takes as input the following data: (i) the set of non-functional properties recognized by Aster, (ii) the set of available base middleware, including the specification
of the behaviors they implement in terms of provided nonfunctional properties, (iii) the set of available middleware components for each base middleware, including the specification of the non-functional properties they provide, and (iv) the specification of the application’s non-functional requirements. The three first sets of data are available through the form of databases. Furthermore, as indicated previously, non-functional properties are defined as formulas of the first order predicate calculus. For simplifying the programmer’s task, logical formulas are associated names which are used in the Aster description of applications. More precisely, non-functional properties are organized into an expandable lattice structure whose elements are pairs of the form "". The selector implements software selection so as to identify the components of the middleware that are required by the processed application. This selection starts by searching a matching middleware among existing base middleware. If there is no such base middleware, the selector tries to build a customized middleware from the selection of a base middleware and complementary middleware components. Ideally, the latter selection should be carried out so as to deliver a customized middleware that is as close as possible to the application’s non-functional requirements in order to have the lowest distribution management overhead. In particular, assuming that base middleware are efficient, the number of middleware components should be minimized. The above selection processes fall into three categories:
Exact match selection: the selected middleware must implement behaviors that match exactly the application’s requirements. Plug-in match selection: the selected middleware must implement behaviors that satisfy the application’s requirements (i.e., the selection is made with respect to the plug-in match formula). Closest match selection: the selected middleware needs to be customized through complementary components.
The algorithms for the two first selection processes are as follows: for an application specifying a set of requirements fR1; :::; Rl g and a middleware specifying a set of behaviors fB1; :::; Bm g, it is checked whether for each Ri there is a Bj that either is equivalent to Ri (exact match) or implies Ri (plug-in match). The closest match selection consists of retrieving the base middleware whose behaviors are the closest to the application requirements. In our framework, the behavior that is the closest to a requirement is the one that specifies the most of the non-functional properties that belong to the requirement. Given the set of base middleware that are equally close to an application’s requirements, it is sequentially processed for customization, i.e., for finding the middleware
components providing the complementary non-functional properties needed to meet the application’s requirements. This process stops when the customization either succeeds for one base middleware or fails for all the base middleware. In the latter case, the customization process will be applied recursively on some less close base middleware. If this step fails too, the missing non-functional properties are notified to the programmer. The implementation of the above algorithms relies on a basic theorem prover that is based on the work of [4] and [14]. The theorem prover together with the selection and customization algorithms have been implemented in Prolog using the Prolog/Mali compiler [16]. The choice of Prolog was initially motivated by the fact that it was successfully used for implementing a tool dedicated to software retrieval [17].
3.2. Evaluation The complexity of middleware customization calls for enhancement of the selector. Let N , M and i be the number of available base middleware, available middleware components and required non-functional properties, respectively. In the worst case, the customization complexity is equal to O(N M i ): the execution of the exact match and plug-in match selections take (2N ) and the closest match selection together with customization take (N M i ). Furthermore, experiment with the selector shows that more than 80 % of CPU consumption is due to the theorem prover. Therefore, one step towards the tool’s enhancement has been to minimize the use of the theorem prover. This is achieved by encoding the stronger-than relationship among the Aster non-functional properties, hence avoiding proving these relationships on each selection process. Another enhancement has been the implementation of a complementary tool for storing and retrieving customized middleware built by the selector. With those enhancements, we observed an improvement of the time taken for customization, by a factor of 15. We are still working on the improvement of the selector. We are focusing more specifically on organizing the storage of base middleware and middleware components according to the non-functional properties they provide. Concerning both base and previously computed customized middleware, we are considering a lattice structure similar to the one proposed in [12] for optimizing the selection process. Briefly stated, the lattice structure encodes the plug-in match relationship among the middleware. From the standpoint of middleware components, we intend to relate them to the Aster property lattice structure so as to encode a classification of middleware components with respect to the provided non-functional properties. The Aster selector belongs to the family of tools for soft-
Application process (server object)
Application process (client object)
11111111 00000000 00000000 11111111 00000000 11111111
Customized middleware
Middleware comp.
111111111 000000000 000000000 111111111 000000000 111111111 Middleware comp.
ORBIX library
ORBIX library
1111111 0000000 0000000 1111111 00000000 11111111 0000000 1111111 0000000 00000000 00000001111111 1111111 0000000 11111111 1111111 00000000 11111111 Middleware comp.
Middleware comp.
...
Middleware comp.
ORBIX ORB (IPC management)
Figure 3. Structure of an Aster application ware retrieval using software specification matching. Examples of such tools can be found in [12, 21]. Compared to our tool, these proposals differ in that they implement software retrieval with respect to the specification of required operations in terms of pre- and post-conditions (i.e. functional properties) while we are concerned with software retrieval with respect to the expected non-functional behavior. Furthermore, to our knowledge, these tools implement only software selection. The issue of software customization, i.e., combining a set of software components to meet the search key, is not addressed.
either in the address space of application components or in a separate address space. For instance, middleware components implementing encryption shall execute in the address space of the application component requiring it while a trader component will execute in a separate process. The above execution requirement of middleware components is stated in their interface declarations through corresponding attributes. Middleware components that execute in the address space of the application components do not use the base communication middleware and hence are not further considered in the remainder. On the other hand, middleware components executing in separate processes interact with other components through the base middleware (i.e., the ORB). There are two ways of interfacing with an ORB: statically by using the Static Invocation Interface (SII) and dynamically through the Dynamic Invocation Interface (DII). In the former case, client objects use client stubs generated by the ORBIX IDL compiler, while in the latter client objects explicitly call the ORB primitives for issuing RPC requests (e.g., invoke for the emission of the call message). The set of behaviors implemented by the ORB using the DII is a superset of the one offered through the SII. The SII allows RPCs with either synchronous, at-most-once semantics or asynchronous, best-effort semantics. The DII further provides asynchronous calls with synchronization on result reception, and multicast RPC with unsorted delivery. This richer set of behaviors has led us to use the DII for interfacing components.
4. Interfacing with Base Middleware 4.2. Implementation The previous section has introduced the Aster selector that is used to identify the components of the middleware that meets the requirements of an application to be executed. We now concentrate on the Aster generator that interfaces the middleware components with the application’s components. From the perspective of the Aster prototype, we currently deal with two base middleware: the ORBIX implementation of the ORB [5] and a middleware built on top of the HTTP protocol. Furthermore, the prototype handles components implemented in the C++ programming language. The remainder of this section details the interfacing tool developed for CORBA-compliant middleware. First, we outline how customization of an ORB is realized. Then, we detail the implementation of the interfacing tool on top of ORBIX. Finally, we present an evaluation of the tool through the implementation of a distributed file system.
4.1. Interfacing with CORBA The general structure of Aster applications running above an ORB is depicted in figure 3. Middleware components (i.e. object services using the CORBA terminology) reside
Let us now detail the implementation of customized middleware using the ORBIX ORB3 . First, the Aster type checker generates IDL descriptions of components from their Aster descriptions, which is straightforwardly achieved by removing declarations that are specific to the Aster language. The IDL descriptions are then compiled using the ORBIX compiler. As shown in figure 3, a customized interconnection is achieved by substituting the RPC between the application’s client and server objects by a chain of RPCs among the client, some middleware components, and the server. Middleware interfacing then relies upon the following points: (1) The automatic implementation of a chain of calls for achieving the customized interconnections that meet application requirements. (2) The execution of the operations implementing nonfunctional properties for calls processed within middleware components. 3 We use the following versions of ORBIX: v1.3.5 for SunPro SPARCompiler C++ 4.0, Solaris 2.3 and v1.3.5 for SunPro SPARCompiler C++ 4.0, Solaris 2.3 x86.
Client object
111111111111111111 000000000000000000 000000000000000000 111111111111111111 000000000000000000 111111111111111111 000000000000000000 111111111111111111 000000000000000000 111111111111111111 000000000000000000 111111111111111111 000000000000000000 111111111111111111 000000000000000000 111111111111111111 000000000000000000 111111111111111111 000000000000000000 111111111111111111 Middleware component
Service request CallORB: Request over a customized interaction
Server object
Pre-actions for achieving the provided non-functional properties Call forwarding Post-actions for achieving the provided non-functional properties
customized(service, prop)
Request to the actual service
4.3. Evaluation Service execution
CallORB
To evaluate our implementation of middleware interfacing in a CORBA framework, we have implemented a Distributed File System (DFS) from a set of Local File Servers (LFSs). A brief description of the DFS is provided hereafter; details about its design can be found in [8].
customized(service, null)
ORB
Figure 4. Interfacing with CORBA
(3) The automatic interfacing of the application and middleware components with the base middleware. The above issues are dealt with through: (i) The implementation of the callORB operation within each (both application and middleware) client component. This operation carries out a chain of RPCs to the customized operation among components involved in a customized interaction. (ii) The generation of client and server stubs where servers stubs implement the customized operation. Figure 4 depicts the implementation of the interfacing with CORBA when there is only one middleware component used for ORB customization. Any request to a server object leads to the execution of callORB within the calling component, which calls the customized operation of the next component (i.e. either a middleware component or the actual server) among the ones of the call chain. The parameters of customized include a description of the called service together with the sequence of (remaining) middleware components and associated non-functional properties used for customization. This allows middleware components (resp. the server component) to execute the operation implementing the requested property (resp. the called service). Up to this point, we have mentioned that the called application service was specified in the parameters of customized without going into details. Since middleware components are application-independent, it cannot be considered that the service signatures are known within middleware components. We thus had to find a generic way for passing actual parameters of the service call along the chain of middleware components. The undertaken solution consists of using the following IDL type: sequence Vect Any that allows to pass the actual parameters through a generic vector.
Application description. Implementation of the DFS requires to customize the ORB so as to allow dynamic binding of a DFS client with one of the constituent LFSs when a file is newly accessed (e.g. when the client executes an open operation). The corresponding non-functional property specializes the well known trading property by selecting the server not solely in terms of its interface (i.e. LFS interface) but also in terms of its state (i.e. existence of the requested file within the LFS server). The resulting non-functional property is called dynamic and is formally defined as:
dynamic(C; IC ; F ) send(C; null;m =< IC ; F; contents >) ^ (9S 2 RS j I (S ) = IC + ^ F (S ) = true ^ receive (C; S; contents)) where RS is the set of registered servers, C is a component (i.e. the one requesting dynamic binding with a server), IC is an interface type, and F is a specific property that is defined by a function belonging to I C . A sample of interface declarations of the DFS in the Aster language is provided below.
f
interface clt-DFS client typeFD open(typeSTR fn) client typeBOOL exist(typeSTR fn) client typeINT write(typeFD fd, typeBUF buf) interface LFS typeFD open(typeSTR fn) typeBOOL exist(typeSTR fn) typeINT write(typeFD fd, typeBUF buf) typeINT load() implementation ImplemClt-DFS client.c implements clt-DFS configuration DFS constituents ImplemClt-DFS; LFS; binds (ImplemClt-DFS)open : (LFS)open; (ImplemClt-DFS)exist : (LFS)exist; (ImplemClt-DFS)write : (LFS)write; requires all : At-Most-Once, Synchronous; (ImplemClt-DFS)open(arg1) : dynamic(ImplemClt-DFS, LFS, exist); interface I locate typeAddrSet locate(typeIF X, typeP Y); placement autonomous; provides dynamic(client, X, Y);
g
f
g
f
g
f
f
g
g
First, the client interface is declared. The client keyword denotes that the specific component will issue requests for
the declared operation. The declaration of the LFS’s interface follows, and then a declaration specifying the file which contains the source code for a client. The fourth block contains the construction of the DFS application based on the declared interfaces, and it is divided in three regions: (i) the components that participate, (ii) the bindings between requests and services, and (iii) the requirements for establishing those bindings. The last block is the declaration of the interface of the middleware component responsible for locating the requested file. It starts by declaring the offered services (i.e. locate) and then specifies the provided properties (i.e. dynamic). Based on the DFS description, Aster can automatically configure a run-time environment by reusing existing software (i.e locator), and verify its correct behavior as discussed in Section 3. Assessing Aster benefits. Let us compare the proposed description of the DFS application using Aster with the DFS implementation in a base CORBA environment. In a CORBA environment, the application programmer is obliged to hard-code the interconnections among the participating components (i.e. client, LFSs and locator) within the component implementations; this step is automatically done by the Aster generator. Another noteworthy difference lies in the support for application evolution. For instance, modification of the DFS so as to integrate a richer set of nonfunctional properties (e.g requirements relating to access control or availability) is straightforward. It suffices to specify the corresponding properties in the Aster description of the DFS. Aster takes care of the deployment of the application provided there exist middleware components providing the requested properties. On the other hand, such a modification in a CORBA environment requires revision of the application source code. The most important point lies in the Aster contribution to software correctness. By promoting formal specifications of non-functional properties, the developer is provided with an adequate basis for reasoning about the behavior of the application from the standpoint of non-functional properties. Another comparison between Aster and a base CORBA environment relates to execution performance. Early experiments with the DFS implementation show that the Aster implementation causes an average execution overhead of 5% compared to a direct CORBA implementation (i.e. without using Vect Any IDL type). We are currently working on the enhancement of the interfacing tool so as to lower this execution overhead.
5. Conclusion This paper has discussed the implementation of the Aster development environment that is aimed at easing the con-
struction of applications having various non-functional requirements (e.g., availability, security, etc.). Our approach relies on the formal specifications of non-functional requirements within applications and on the automatic configuration of the corresponding middleware. Briefly stated, a customized middleware is built from the interconnection of a base middleware with complementary middleware components such that the conjunction of the non-functional properties they provide meets application requirements. The two main tools used to achieve such a customization are:
A selector tool that retrieves the software constituting a customized middleware given the formal specifications of application requirements and of behaviors implemented by middleware components (including base middleware). An interfacing tool realizing the interfacing of the application components with the customized middleware. In this paper, we have detailed the implementation of interfacing when using an ORB as the base middleware.
The Aster prototype has been operational since summer 1996. Our first experience shows that we are able to achieve automatic customization when dealing with basic RPC distribution management semantics as well as more complex non-functional requirements relating to security, interoperability and fault tolerance [2, 18, 19]. We are now working on the enhancement of the Aster prototype so to achieve efficient customization from the standpoint of both identifying components of the middleware and the application execution performance. The first issue that relates to the Aster selector is addressed by organizing the storage of the middleware components according to the properties they provide, in a way similar to the proposal of [12]. The second issue will be dealt with by first designing a base middleware dedicated to Aster so as to clearly identify basic features that are required for achieving efficient customization. From that perspective, we intend to exploit existing work on customization at the level of operating systems (e.g., see [9]). Our proposal relates to the current research effort on system customization. In addition to the work on operating systems referenced above, results in that area include the one done in the programming language community in order to simplify construction of customized communication services (e.g., see [20, 10]). However, to our knowledge, existing proposals do not consider correctness of the customization with respect to application requirements. More generally, they do not address automatic configuration of a customized middleware from the formal specifications of application non-functional requirements. This paper has exemplified our approach when only one type of non-functional properties is required by the application. The suitability of our proposal for real applications
raises the issue of scalability, i.e., the number of properties that need to be associated to components. This number, which depends upon the application classes developed in the Aster framework, impacts upon the time taken by the customization process. However, we do not see this as a major concern given the performance of the Aster selector implementing specification matching. Furthermore, it is our belief that application requirements will correspond to high-level non-functional properties provided by complex services (i.e., services built out of primitive services through inner customization). Since the selector stores computed customization, it is expected that the time taken for a given customization will be shortened. Another consequence is that a small set of properties will be attached to one component although this may recursively lead to a large set of such. Most importantly, we assert that the complexity of non-functional property specifications is balanced with the benefits of automatic customization in the development process: the application developer has no longer to be concerned with the use of low-level middleware components and is only asked to specify abstract non-functional properties. This further results in a support contributing to software correctness. Another issue that is raised by the use of the Aster environment for real applications relates to the conjunction of different types of non-functional properties that may interfere. For instance, this is illustrated by an application that have requirements relating to both availability and security where satisfying the former suggests replication while satisfying the latter implies minimizing redundancy. We have not yet examined detailed consequences of such interferences upon our approach and this is an open issue for future work. Our premise is that the interdependency among non-functional properties can be made explicit through the definition of a relation over properties.
References [1] P. A. Bernstein. Middleware: A model for distributed system services. Communications of the ACM, 39(2):86–98, 1996. [2] C. Bidan and V. Issarny. Security benefits from software architecture. In Proceedings of Coordination’97, pages 64– 80, 1997. URL: http://www.irisa.fr/solidor/work/aster. [3] J. R. Callahan and J. M. Purtilo. A packaging system for heterogenous execution environments. IEEE Transactions on Software Engineering, 17(6):626–635, 1991. [4] A. Felty and D. Miller. Specifying theorem provers in a higher-order logic programming language. In Proceedings of the Ninth International Conference on Automated Deduction, pages 61–80, 1988. [5] IONA. The Orbix Architecture. Technical report, IONA Technologies Ltd., 1995. [6] V. Issarny and C. Bidan. Aster: A CORBA-based software interconnection system supporting distributed system customization. In Proceedings of the Third International Con-
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14] [15]
[16]
[17]
[18]
[19]
[20]
[21]
ference on Configurable Distributed Systems, pages 194– 201, 1996. URL: http://www.irisa.fr/solidor/work/aster. V. Issarny and C. Bidan. Aster: A framework for sound customization of distributed runtime systems. In Proceedings of the Sixteenth IEEE International Conference on Distributed Computing Systems, pages 586–593, 1996. URL: http://www.irisa.fr/solidor/work/aster. V. Issarny, C. Bidan, and T. Saridakis. Designing an openended distributed file system in Aster. In Proceedings of the 9th International Conference on Parallel and Distributed Computing Systems, pages 163–168, 1996. URL: http://www.irisa.fr/solidor/work/aster. M. F. Kaashoek, D. R. Engler, G. R. Ganger, H. Briceno, R. Hunt, D. Mazieres, T. Pinckney, R. Grimm, and J. J. znf K. Mackenzie. Application performance and flexibility on exokernel systems. In Proceedings of the Sixteenth ACM Symposium on Operating Systems Principles, pages 52–65, 1997. T. H. Kim and J. M. Purtilo. Configuration-level optimization of RPC-based distributed programs. In Proceedings of the Fifteenth IEEE International Conference on Distributed Computing Systems, pages 307–316, 1995. J. Magee, N. Dulay, and J. Kramer. Structuring parallel and distributed programs. Software Engineering Journal, 8(2):73–82, 1993. A. Mili, R. Mili, and R. Mittermeir. Storing and retrieving software components: A refinement based system. In Proceedings of the Sixteenth International Conference on Software Engineering, pages 255–262, 1994. OMG. The Common Object Request Broker: Architecture and Specification – Revision 2.0. Technical report, OMG Document, 1995. L. C. Paulson. The foundation of generic theorem prover. Journal of Automated Reasoning, 5:363–397, 1989. J. M. Purtilo. The Polylith software bus. ACM Transactions on Programming Languages and Systems, 16(1):151–174, 1994. O. Ridoux, S. L. Huitouze, and P. Brisset. Prolog/Mali Reference Manual. Technical report, IRISA, Rennes, France, 1996. E. J. Rollins and J. M. Wing. Specifications as search keys for software libraries. In Proceedings of the Eighth International Conference on Logic Programming, pages 173–187, 1991. T. Saridakis, C. Bidan, and V. Issarny. A programming system for the development of TINA services. In Proceedings of the International Conference on Open Distributed Processing, pages 3–14, 1997. URL: http://www.irisa.fr/solidor/work/aster. T. Saridakis and V. Issarny. Fault Tolerant Software Architectures. Research Report 3350, INRIA, Rennes, France, 1998. URL: http://www.irisa.fr/solidor/work/aster. D. C. Sturman and G. A. Agha. A protocol description language for customizing failure semantics. In Proceedings of the Thirteenth IEEE Symposium on Reliable Distributed Systems, pages 148–157, 1994. A. M. Zaremski and J. M. Wing. Specification matching of software components. In Proceedings of the ACM SIGSOFT’95 Symposium on Foundations of Software Engineering, pages 6–17, 1995.
