Luc Courtrai

Frédéric Guidec

Nicolas Le Sommer

Yves Mahéo

Resource Management for Parallel Adaptive Components

This paper reports the development of the Concerto platform, which is dedicated to supporting the deployment of parallel adaptive components on clusters of workstations. The current work aims at proposing a basic model of a parallel component, together with mechanisms and tools for managing the deployment of such a component. Another objective of this work is to define and implement a scheme that makes it possible for components to perceive their runtime environment. This environment is modelled as a set of resources. Any component can discover and monitor resources, using the services offered by the platform.

Introduction

Clusters of computers are now found in an increasing number of laboratories and companies where they take on various forms. They may for instance play the role of lowcost supercomputers. A group of workstations connected via a high performance network may also be used as a cluster, even though these workstations are still exploited for common purposes. Such clusters can make interesting resources for Grid Computing. In this perspective, the objective may be to deploy parallel applications on computing infrastructures that contains several clusters. However, proposing a software solution that allows the development of applications that take benefit from these architectures is still a challenge.

Several approaches can be envisaged for designing and deploying an application that exploit one or several clusters. Among them, the component approach is worth being studied. It allows complex applications to be designed by assembling available components. We consider in this paper the case where each component is designed as a "parallel code" that is to be deployed on a cluster Even if it is possible to design a component in an ad hoc manner so that it exploits at best a specific architecture, it is preferable to favour the component's portability. Each component should ideally be deployable on a large range of clusters. To achieve this goal, one may think of extending the notion of virtual machine to the entire cluster in order to hide the specificities of the underlying hardware platforms. Another approach, that we explore, consists in enforcing the adaptability of the component so it can allow for the hardware and software specificities of the platforms on which it is deployed.

Component adaptation has several facets.

Autoadaptation occurs when the component itself is responsible for deciding to adapt its behaviour to external conditions. Such a component can be referred to as an adaptive component. In other cases, it is the environment, especially the hosting platform, that enforces an adaptation strategy by imposing that a component modify its behaviour according to explicit directives. In this case, the component, must have been designed so as to be able to receive such directives from the platform. Such a component can be referred to as an adaptable component. The difference between these two forms of adaptation is not discussed any further in this paper. Instead, we focus on the basic mechanisms that are necessary in both cases to provide information that makes possible the decision process and leads to adaptation.

If the adaptive component has the possibility to obtain information on the target architecture, it will be able to choose an appropriate configuration when it is deployed. The state of the platform can be expressed in the form of qualitative and quantitative information covering aspects such as the number of nodes in the cluster, the computation power of these nodes, the bandwidth offered by the communication links, the availability of a given peripheral device, or that of a specific software library. However, an initial configuration of the component may not always be sufficient. Whenever a component cannot be deployed on a dedicated platform, it may have to share resources with other components, and even with other applications. In such circumstances new conditions may arise at runtime, requiring that components change their behaviour accordingly. A component should thus have means to dynamically gather information pertaining to its environment, so that it can adapt itself, for example by redistributing data, by balancing its load differently, or by choosing a new algorithm. The kind of information that can help take such decisions is for instance the CPU load observed on a given node, or the bandwidth available on a link. This paper describes the Concerto software platform. This platform supports the deployment of parallel components on a cluster, and it provides these components with means to adapt themselves. The platform is dedicated to the deployment and the support of parallel components written in Java. Information that feeds adaptation decisions comes from the observation of resources. In this particular context the term "resource" has a broad meaning. We thus envisage to deal with:

"system" resources such as the memory or the CPU of each cluster node, or a scientific computing library; "conceptual" resources related to the application itself, such as the sockets or threads used by a component.

Our aim is to develop mechanisms that make it possible to collect information related to a non-limited set of such resources. The infrastructure we propose is extensible, as it is designed in such a way that new types of resources may be easily allowed for when needed. The Concerto platform can thus evolve so as to take into account new hardware and software specificities of clusters.

The remaining of this paper is organized as follows. Section 2 introduces the basic model of parallel components we propose, and it describes the implementation of the deployment mechanisms. The modelling of resources within the platform and the tools that permit the observation of their state are presented in section 3. Section 4 concludes the paper.

Parallel Components

Component-based application development is already possible through the use of component technologies proposed by industry, such as Microsoft COM [START_REF]The Component Object Model Specification[END_REF] or Sun's Enterprise Java Beans. OMG (Object Management Group) also develops its own solution with CORBA Component Model [START_REF] Omg | CORBA Components[END_REF]. However theses technologies have not been designed to support parallel components, that is, components that involve parallel activities. Some preliminary work has been carried out on models or platforms that target parallel components [START_REF] Amstrong | Towards a Common Component Architecture for High-Performance Scientific Computing[END_REF][START_REF] Denis | Towards High Performance CORBA and MPI Middleware for Grid Computing[END_REF]. In this work the main objective is to reuse large scientific code relying on data parallelism.

The Concerto platform is dedicated to adaptive parallel components. Although the concept of parallel component is central to our project, our aim is not to propose a new component model, but to provide an infrastructure that enforces the adaptability of components. In this perspective, we propose below a minimal definition of what we mean by parallel component in Concerto.

A programmer who wishes to develop a parallel component for Concerto must design his component as a set of cooperating threads. He must also define the factory part of the component (name, interface, implementation). The platform offers facilities for managing non-functional aspects of the component.

Component interface

A parallel component hosted by the Concerto platform has three interfaces.

Factory interface:

No constraints are put on the type of the factory interface. The programmer may for example propose an interface based on Java RMI. The component is then an object implementing the Remote interface, whose methods will be called remotely by the clients of the component. The component may also be a server listening to a port of the machine on which a client must open a socket. One may also design a distributed interface (that is to say, an interface associated with several objects that each implement a part of the interface) in order to be connected in parallel with another parallel component.

Life cycle interface:

Through this interface, the different steps of the life of the component can be controlled. To date, this mainly covers deploying the component on the cluster, and stopping this component. In the future it should be possible to distinguish between several phases within the deployment process, and to propose persistence services.

Resource interface. The component exhibits a resource interface through which the user accesses information related to the resources used by the component. More precisely, the component itself is considered as a resource in the Concerto platform. Hence Concerto components are required to implement an observe() method that returns an observation report (see Section 3 for more details). By default, the observation report generated by a component aggregates the observation reports on all the resources it uses. If the component programmer finds it useful (for example for security reasons), he may restrict the amount of information disclosed to the component's client by defining a particular type of observation report.

Internal structure of a component

When building a parallel component, the programmer develops a set of Java threads (actually a set of classes implementing the Runnable interface). These threads cooperate to perform the methods of the component's factory interface.

Threads are gathered into placement (or entities called fragments. A fragment is a set of threads that belong to a single component, and that are bound to run within the same virtual machine on the same cluster node. These threads will thus be able to share a common object space. Communication and synchronization between the threads of a fragment are performed just like in any other multi-threaded Java program. On the other hand, threads that belong to different fragments must rely on external communication and synchronization mechanisms, such as sockets and RMI.

Component deployment

In order to deploy a component on a cluster, one must provide a description file for this deployment. This file describes: the component's structure (expressed in terms of the fragments and threads to be deployed); placement directives for the fragments. One can for example duplicate some fragments on all cluster nodes, or assign a fragment to a specific node. constraints imposed by the component in order for its deployment to be feasible (availability of a specific version of the JVM, of a RMI registry, etc.)

We have developed an XML dialect that permits the specification of such directives. The Concerto platform can parse this dialect so as to ensure the deployment of components on a cluster.

Resource Modelling and Control

Motivation and main principles

The main objective of project Concerto is to provide software components with means to perceive their runtime environment so that they can adapt their behaviour to the state of this environment, and to its variations. We are developing in Java a software platform in which the runtime environment of a component is modelled using objects that reify the various resources offered.

As a general rule, we qualify as "resource" any hardware or software entity a software component may use during its execution. The resources considered to date in the Concerto platform include system resources (CPU, system memory, swap, graphical user interface, network interface, etc.) that characterize chiefly the underlying hardware platform, as well as "conceptual resources" (sockets, processes, threads, directories, files, RMI server, etc.) that rather pertain to the applicative environment considered.

Since a software component is liable to use all or some of the resources available in its environment, the Concerto platform must provide mechanisms that make it possible for the component:

to check the availability of any resource (or kind of resource) in its environment; to discover the existence of a specific resource (or kind of resource); to ask for the status of a specific resource; to ask that the platform notifies the component when a given condition is reached regarding the status of a specific resource.

Since the Concerto platform is dedicated to the deployment of parallel software components on a cluster of machines, the dissemination of resources over the nodes of this cluster must be allowed for. The above-mentioned mechanisms must thus make the distribution of resources transparent for components. A thread belonging to a component must be able to gather information not only about the resources available on the node it runs on but also about distant resources and resources distributed over whole cluster.

Modelling of system and conceptual resources

Any kind of resource liable to be used by components deployed on the Concerto platform must be reified as Java objects. We have thus started the development of a class hierarchy in order to model these resources. This hierarchy is partially reproduced in Figure 1. It is meant to be extended as new resource types are allowed for in the platform. Some of the classes shown in Figure 1 model resources that pertain to the hardware level. Classes CPU, Memory, and NetworkInterface belong to this category. The class ClusterNode is used to aggregate the three former classes, so that any cluster node can be modelled as a single resource object.

Other classes shown in Figure 1, such as classes Socket and Thread, are standard classes defined in the JDK (Java Development Kit). Their implementation was revised in project Concerto in such a way that the state of the conceptual resources they model can be observed at runtime.

Classes Fragment and Component were introduced in order to define functionalities that are specific to project Concerto. With these classes, a parallel component and a component fragment can be perceived as resources in the cluster they are deployed on. One can therefore benefit from the services implemented in Concerto to manage the components deployed on a cluster, as well as the fragments deployed on any cluster node.

Observation reports

Observation reports make it possible to gather information about the state of the many kinds of resources distributed in a cluster in a homogeneous way. A hierarchy of Java classes was developed in order to allow the generation, the collection, and the management of such reports (see Figure 2). Any Java object that models a resource in the Concerto platform implements method observe(), which returns a report about the current state of the resource considered. A report is modelled as a Java object that implements the ObservationReport interface. Of course the actual content of the report depends on the type of the resource considered. Hence, when method observe() is called on a Thread object, this object returns a report of type ThreadReport. The class ThreadReport provides pieces of information that characterize the state of the thread object considered (current priority level, amount of CPU and memory consumed since this thread was started, etc.). Likewise, calling method observe() on a Memory object returns a MemoryReport, which provides information about the current state of the system memory.

Resource identification and tracking

In the Concerto platform, all resources are modelled as Java objects that can be created and destroyed at any time. Nevertheless, any resource object must be identified unambiguously. Therefore, the platform implements mechanisms for identifying and tracking resources at runtime. These mechanisms rely on a naming system that gives any resource a unique name. Whenever a resource object is created on a cluster node, this object is given a unique identifier (object of type ResourceId, see Figure 1). Moreover, the resource object created is immediately registered within a resource manager (object of type ResourceManager), whose function is to identify and to keep track of any existing resource object.

An instance of class ResourceManager is created on each cluster node whenever a new component is deployed. This resource manager permits the identification, location, and collection of observation reports for:

the conceptual resources used by the component it is associated with;

the system resources of the cluster (which are considered as global resources shared by all components); the other components that have been deployed on the cluster (remember that each component is perceived as a resource, and can therefore produce an observation report on demand).

Search patterns make it possible to search for resources, and to collect observation reports from these resources selectively. They model search strategies as Java objects. For example, one can create a search pattern object that describes a local search strategy (i.e. search limited to a specific node of the cluster), and another object that describes a global search strategy (i.e. search performed on all the nodes of the cluster). The interface SearchPattern serves as the root of a hierarchy of classes that each describe a specific search strategy (Figure 3). The following segment of code shows how a resource manager can be called when looking for specific resources. In this example several kinds of search patterns are used in order to specify that the search should apply (1) to local resources only; (2) to the resources located on a remote node whose identity is specified as an argument; (3) to the whole cluster. turns an observation report concerning this object. Whether the resource object considered is local or remote remains transparent for the caller.

The segment of code shown below is a continuation of the former example. The caller calls the resource manager and ask for an observation report on a specific resource object (assuming that the value of resId was extracted from one of the three id sets collected in the former example).

[...]

ObservationReport report = manager.observe(resId);

In the current implementation of the Concerto platform, resource managers rely on the RMI mechanism for exchanging information. The objects modelling search patterns and observation reports are all serializable, so they can be transmitted between two nodes using the RMI mechanism. This characteristic shows in the class hierarchies reproduced in Figures 2 and3.

Resource classification and selection.

The resources registered within a resource manager can be of various types (eg CPU, Memory, Socket, Thread, File, etc.). The Concerto platform implements mechanisms for classifying and selecting resources based on the notion of "resource pattern".

The interface ResourcePattern (see Figure 3) defines a function isMatchedBy(), which takes a resource object as a parameter, and returns a boolean whose value depends on whether this object satisfies the considered selection criterion or not. In a simple case resource selection can rely on the actual type of the resource object which is submitted to the test. Hence, in the class CPU_Pattern (which implements interface ResourcePattern), the method isMatchedBy() simply checks that the object passed as a parameter is a CPU object. But one can also implement more sophisticated selection mechanisms. For example the class SocketPattern is implemented so as to achieve the selection of socket objects based on criteria that take into account not only the type of the resource (this object must be of type Socket), but also the local and remote IP address and ports associated with this socket, as well as the number of bytes sent and received via this socket.

The following example shows the creation of three resource patterns. The first pattern permits the search for and selection of parallel components. The second pattern permits to select specifically resource objects that model the CPUs in a cluster. The third pattern makes it possible to select only those resource objects that model sockets resources, and that additionally satisfy the following selection criteria: the IP address of the remote host must belong to the 195.83.160/24 network, and the remote port must be in the range 0 to 1023. On the other hand, the local IP address and port the socket is bound to can take any value. The resource manager can handle requests that take a ResourcePattern object as a parameter. One can thus request that the resource manager locate a specific set of resources, or collect and return observation reports from these resources. For example, assume that the resource manager receives a search request with the componentPattern de- fined in the former example. It will thus search for those resources that match this pattern, and return only the identities of component resources. On the other hand, if the resource manager is required to search for those resources that match the socket pattern, it will only consider the sockets created by the calling component, and will select among these sockets those whose characteristics (IP addresses, port numbers, etc.) match the SocketPattern.

Implementation details

The mechanisms we use in Concerto for modelling resources and allowing their observation have a larger scope than that of adaptive parallel components. These mechanisms have been gathered in an environment called RAJE (Resource-Aware Java Environment). RAJE permits the reification and the observation of system resources. Moreover, it defines the main schemes for identifying, localizing and observing resources. The Concerto platform is based on the RAJE environment which is extended in order to allow for specific notions such as parallel components or fragments.

The RAJE environment and the Concerto platform are presently implemented on Linux and rely on a variant of the Kaffe 1.0.6 JVM. Details on RAJE can be found in [START_REF] Guidec | Towards Resource Consumption Accounting and Control in Java: a Practical Experience[END_REF]. This paper describes how resource observation is implemented and how consumption shares are imputed to Java threads. Article [START_REF] Sommer | A Contract-Based Approach of Resource-Constrained Software Deployment[END_REF] presents also RAJE (and the JAMUS platform built upon RAJE). Namely, the services provided by RAJE are compared to those offered by others tools such as JRes [START_REF] Czajkowski | JRes: a Resource Accounting Interface for Java[END_REF], GVM [START_REF] Back | Techniques for the Design of Java Operating Systems[END_REF], KaffeOS [START_REF] Back | Processes in KaffeOS: Isolation, Resource Management, and Sharing in Java[END_REF]. Naccio [START_REF] Evans | Flexible Policy-Directed Code Safety[END_REF] Ariel [START_REF] Jones | Modular Real-Time Resource Management in the Rialto Operating System[END_REF], etc.

Conclusion

This article presents the Concerto platform, which aims at allowing the deployment and the support of parallel components on clusters of workstations. Ongoing work focuses on proposing a basic parallel component model, as well as tools for the deployment of such components. Our objective is, in a first stage, to adopt as simple and versatile a model as possible. We rather put the emphasis on the development of mechanisms useful to adaptation. Indeed, the clusters targeted by the Concerto platform are mainly nondedicated clusters composed for example of several workstations that are shared by several components, and even several applications and users. The runtime environment of parallel components is heterogeneous and may vary along the component's execution. So we have designed tools that provide the components with means to perceive their execution environment and its variations. The components' environment is likened to a set of resources. Each component can discover the existence of a particular resource and observe its state thanks to the services the platform offers.

The development of the Concerto platform is still in progress. The deployment tool, that includes a graphical frontend, should be extended. Besides, we intend to make interaction mechanisms available to the components so that they can command the platform to inform them on changes in the state of resources. This implies the definition of a formalism that can be used by components to describe interesting events and to implement a notification scheme that allows for the distributed aspects of the components.

Figure 1 .

 1 Figure 1. Object-based modelling of a few resource types.

Figure 2 .

 2 Figure 2. Observation reports modelling.

  ResourcePattern componentPattern = new ComponentPattern(); ResourcePattern cpuPattern = new CPU_Pattern(); ResourcePattern socketPattern = new SocketPattern(InetAddress.AnyAddress, "195.83.160/24", PortRange.AnyPort, new PortRange(0, 1023)); [...]

Figure 3 .

 3 Figure 3. Modelling of the patterns that can be used to select resources (left-hand side of the hierarchy) and to describe search strategies (right-hand side of the hierarchy).

ResourceManager manager = ResourceManager.getManager(); Set localIds = manager.getResourceIds(new LocalSearch()); // (1) Set remoteIds = manager.getResourceIds(new LocalSearch(remoteNodeId)); // (2) Set allIds = manager.getResourceIds(new GlobalSearch()); // (3)Once the identity of a resource object has been obtained, one can require that the resource manager collects and re-

Acknowledgment

This work is supported by the French Ministry of Research in the framework of the ACI GRID program.


Nicolas Le Sommer

Frédéric Guidec

A Contract-Based Approach of Resource-Constrained Software Deployment

Software deployment can turn into a baffling problem when the components being deployed exhibit non-functional requirements. If the platform on which such components are deployed cannot satisfy their non-functional requirements, then they may in turn fail to perform satisfactorily. In this paper we propose a contract-based approach of resource-constrained software deployment. We thus focus on a specific category of non-functional requirements: those that pertain to the resources software components need to use at runtime. Ultimately, our objective is to provide software components with means to specify their requirements regarding hardware and/or software resources, and to design methods and models for utilising this kind of information at any stage of a component's life-cycle. The paper reports the design of JAMUS, an experimental platform we develop in order to support the deployment of mobile software components, while providing these components with guaranteed access to the resources they need. JAMUS implements a contract-based model so as to recognise and to allow for the requirements of components regarding resource access and consumption.

Introduction

When deploying software components on a target platform, one can wonder whether the requirements of these components can be satisfied by the runtime environment offered by the platform. Almost any software component exhibits specific non-functional requirements. Such requirements can in turn be categorised, depending on whether they refer to properties such as persistence, fault-tolerance, reliability, performance, security, etc. As observed in [START_REF] Szyperski | Component Software: Beyond Object-Oriented Programming[END_REF], 'it is obvious that in most practical examples a violation of non-functional requirements can break [components] just as easily as a violation of functional requirements'. Hence, if the platform on which a component is deployed fails to meet its non-functional requirements, then the component may in turn fail to fulfil its mission, which usually consists in providing a clearly defined set of services with a certain level of quality of service (QoS). The question of deciding whether the nonfunctional requirements of components can be satisfied is even more crucial on an open platform, for new components can be deployed on -or removed from -such a platform while other components are running. Dynamically loading or removing a single software component on such a platform may impact dramatically on all the components that share the same runtime environment.

In this paper we focus on a specific category of non-functional requirements, that is, those that pertain to the resources a software component needs to use at runtime. All software components are not equivalent as far as resource access and consumption are concerned. Some components can do very well with sparse or even missing resources, while others require guaranteed access to the resources they need. In order to deal with non-functional requirements pertaining to resource utilisation we propose a contractual approach of resource management and access control. This idea is being investigated in the context of project RASC1 (Resource-Aware Software Components). This project aims at providing software components with means to specify their requirements regarding hardware and/or software resources, and to design methods and models for utilising this kind of information at any stage of a component's life-cycle. This paper mostly reports the design of JAMUS, an experimental platform whose development is in progress within project RASC. The JAMUS platform supports the deployment of software components, provided that these components can specify their requirements regarding resource utilisation in both qualitative (eg access rights to parts of the file system) and quantitative terms (eg read and write quotas). JAMUS is actually most specifically dedicated to hosting simple mobile Java components, such as application programs and applets. These could be downloaded from remote Internet sites or received as Email attachments before being deployed on the platform. As a consequence, emphasis is put in JAMUS on providing a safe and guaranteed runtime environment for components of such dubious origin. ("JAMUS" is actually an acronym for Java Accommodation of Mobile Untrusted Software. Any mobile component deployed on this platform is considered as a potential threat throughout its execution.)

The remaining of this paper is organised as follows. Section 2 presents the general architecture of the JAMUS platform. It also gives an overview of RAJE, the runtime environment this platform relies on, and whose development is also carried out within project RASC. Section 3 introduces the notion of resource utilisation profile, and it shows how this notion is implemented and used in JAMUS. Resource utilisation profiles are important elements in the platform, as they make it possible to set restrictions on the resources it offers, while specifying the requirements of hosted components regarding these resources. The notion of resource usage profile is thus the key to resource contracting in JAMUS. This specific mission is under the responsibility of a resource broker, whose role and main features are detailed in Section 4. Since the mobile components deployed on the platform are perceived as inherently non-trustworthy, their execution is submitted to a constant monitoring, so that resource access violations can be readily detected and dealt with. Section 5 details the mechanisms that permit this monitoring in JAMUS. Related work is mentioned in Section 6. As a conclusion, Section 7 discusses some of the current limitations of the JAMUS platform, and gives an overview of the lines we plan to work along in the future.

Overview of the JAMUS Platform

The general architecture of the platform is shown in Figure 1. The platform is implemented over RAJE, a Resource-Aware Java Environment whose development is also carried out in our laboratory.

Middleware support for resource monitoring and control

RAJE can be perceived as an extension of the traditional runtime environment of the Java 2 platform. This extension provides various facilities for monitoring the resources of a hardware platform, as well as for monitoring and controlling the resources used by Java application programs at runtime. It includes classes that reify system resources (CPU, network interfaces, etc.) as well as classes that model conceptual resources (sockets, files, etc.). Some of these classes are specific to RAJE, while others simply provide alternative implementations for classes of the standard Java API. For example, standard Java classes Socket and File are given specific implementations in RAJE, so that any access to the conceptual resources they model can be monitored and controlled at runtime. Most of the code included in RAJE is pure Java and, as such, is readily portable. However, part of this code consists of C functions that permit the extraction of information from the underlying OS, and the interaction with inner parts of the JVM (Java Virtual Machine). To date RAJE is implemented under Linux, and the JVM it relies on is a variant of TransVirtual Technology's Kaffe 1.0.6. System resources are monitored by polling various files in the /proc pseudo file-system of the Linux OS. The JVM is modified in such a way that Java threads are implemented as standard Linux native threads. This approach gives us better control over the CPU resource. For example, it makes it possible to monitor the amount of CPU consumed by each Java thread, since this information is readily available under /proc for any Linux thread.

RAJE is dedicated to supporting high-level resource-aware applications, such as adaptive systems, security-oriented systems, or QoS-oriented systems. The JAMUS platform lies at the frontier between the two latter categories. It controls the resources used by Java application programs in order to ensure a secure runtime environment for these programs, as well as guaranteed QoS as far as resource availability is concerned.

Resource contracting in JAMUS

As mentioned in Section 1, resource control in JAMUS is based on a contractual approach. A four-level classification of the various kinds of contracts encountered in object-oriented programming has been proposed in [START_REF] Beugnard | Making components contract-aware[END_REF]. According to this classification, the contracts we consider in JAMUS fall into the fourth level, which is that of contracts pertaining to non-functional properties and requirements.

Whenever a software component applies for being deployed on the platform, this component must specify explicitly what resources it will need at runtime, and in what conditions. Moreover access conditions can be specified in both a qualitative way (eg access permissions) and a quantitative way (eg access quotas). By specifying its requirements regarding resource access privileges and quotas, the candidate component requests a specific service from the JAMUS platform. At the same time it promises to use no other resource than those mentioned explicitly. Likewise, when the platform accepts a candidate component it promises to provide the component with all the resources it requires. At the same time it reserves the right to sanction any component that would try to access other resources than those it required.

The main originality of our approach with respect to related works (such as those mentioned in Section 6) lies in the fact that a specific contract must be subscribed between the JAMUS platform and each software component it accommodates. Based on these contracts, JAMUS provides some level of quality of service regarding resource availability. It also provides components with a relatively safe runtime environment, since no component can access or monopolise resources to the detriment of other components.

Contract subscription. Contract subscription in JAMUS relies on a two-step procedure. Any software component that applies for being deployed on the JAMUS platform must first pass an admission control examination. The requirements of a candidate component regarding resource utilisation must be expressed as a set of so-called resource utilisation profiles. Section 3 gives a detailed description of these profiles. The requirements of a candidate component are examined by a resource broker in order to decide if this component can be admitted on the platform. Admission control is based on a resource reservation scheme: a component is admissible only if the resources it requires are available on the platform in sufficient quality and quantity. When a component is declared admissible, the resource broker reserves the required resources for this component. The role and features of the resource broker are further detailed in Section 4.

When the admission control step and the resource reservation step are complete, a candidate component can start running on the platform. However the platform and the component are bound by a contract: the platform expects that the component will not attempt to access other resources than those it required, and the component expects that the platform will provide the resources it required.

Contract monitoring. Contract monitoring would not be necessary if the components deployed on the JAMUS platform could all be considered as trustworthy. If that was the case, any component could reasonably be expected to behave exactly as promised, and to use only those resources it required. Indeed, works are in progress that aim at providing so-called "trusted components" [START_REF] Meyer | Providing Trusted Components to the Industry[END_REF][START_REF] Jézéquel | Reliable Objects: a Lightweight Approach applied to Java[END_REF][START_REF] Lindqvist | An Analysis of a Secure System Based on Trusted Components[END_REF]. Hence, there is hope that, in the future, contract monitoring will not necessarily be required in all circumstances.

JAMUS is being developed in order to provide a safe and guaranteed runtime environment for components of dubious origin, such as application programs or applets downloaded from remote Internet sites. Consequently, any component deployed on the platform is considered as a potential threat throughout its execution.

Once a component has been accepted on the JAMUS platform, this does not necessarily mean that at runtime this component will respect the contract it subscribed with the platform. A component designed in a clumsy way -or in a malevolent perspectivemay attempt to misbehave by accessing resources it did not explicitly ask for. In order to prevent such problems any component deployed on JAMUS is considered as nontrustworthy. Its execution is monitored so as to to check that it never attempts to access resources in a way that would violate the contract it subscribed with the platform during the admission control step. The mechanisms that permit the supervision of a component at runtime are presented in Section 5.

Describing Restrictions and Requirements: the Key to Contracts

At startup the JAMUS platform is given a description of the resources it can make available to hosted components, as well as instructions on how these resources should be used by components. RAJE and JAMUS together provide a series of interfaces and classes that permit to model resources and access conditions as so-called "resource utilisation profiles". Such profiles can thus be defined as Java code, and handled at runtime as standard Java objects.

Setting restrictions on the platform. The piece of code reproduced in Figure 2 shows how resource usage profiles can be defined in order to describe and to set restrictions on the resources available on the platform. In this example the platform is provided with three distinct profiles.

An instance of class ResourceUtilisationProfile basically aggregates three objects, which implement the ResourcePattern, ResourcePermission, and ResourceQuota interfaces respectively (see Figure 3).

JAMUS provides specific implementations of these interfaces for each resource type. For example, some of the classes that implement the ResourcePattern interface are shown in Figure 4. By including a given type of ResourcePattern in a ResourceUtil-isationProfile one indicates that this profile is only relevant for those resources whose characteristics match the pattern, and that the ResourcePermission and ResourceQuota objects defined in this profile only pertain to this particular set of resources.

For example, the SocketPattern defined in profile C1 (see Figure 2) specifies that this profile only concerns socket resources. The access permissions and transmission quotas defined in C1 should thus be enforced only on sockets. The FilePattern defined in profile C2 specifies that this profile concerns only file resources, and more precisely those files that are located under the /tmp directory. The permissions and quotas defined in C2 should thus be enforced only on runtime components attempting to accessing files in /tmp. Profile C3 sets further restrictions on directory /tmp/jamus, imposing smaller quota values on this specific directory.

Specifying hosted components' requirements. Whenever a candidate component is submitted to the admission control step, it must specify its own requirements with respect to the resources offered by the platform. These requirements can also be modelled as instances of the class ResourceUtilisationProfile.

Figure 5 shows how a component can specify its requirements by defining the static method getResourceRequirements(), which returns a set of ResourceUtilisationProfiles. This method is systematically called by the platform's launcher in order to ask candidate programs for their requirements.

Checking requirements against restrictions. The interfaces ResourcePattern, Re-sourcePermission and ResourceQuota all define a boolean function conformsTo(), which can be used to check the conformity between two objects that implement the same interface (as shown in Figure 4 in the case of interface ResourcePattern). Conformity between patterns, permissions, and quotas is defined as follows:

-A pattern Sa is said to conform to another pattern Sb if any resource object whose characteristics satisfy the selection criterion defined in Sa also satisfy that of Sb. -A permission Pa is said to conform to another permission Pb if any operation allowed in Pa is also allowed in Pb. -A quota Qa is said to conform to another quota Qb if any amount (or rate) specified in Qa is smaller than (or equal to) that specified in Qb.

The function conformsTo() can thus be used at runtime to check a program's requirements against the restrictions imposed on the platform. With this function one can readily identify the requirements and restrictions that concern the same category of resources, and then verify that these requirements are compatible with those restrictions.

Admission Control and Resource Reservation: Contract Subscription

The resource broker implemented in JAMUS is inspired from that described in [START_REF] Kim | A Resource Broker Model with Integrated Reservation Scheme[END_REF]. It implements a reservation mechanism in order to guarantee the availability of resources for hosted components.

Initialisation of the resource broker. At startup, the broker receives the set of resource utilisation profiles that describe the restrictions imposed on the platform's resources. This information is used by the broker to build its own "perception" of the resources initially available on the platform, and of the conditions set on any access to these resources. Admission of a candidate component. Whenever a candidate component is submitted to the admission control test, the resource broker examines the requirements of this component. For each basic requirement, the broker must decide if this requirement is admissible. A requirement is declared admissible if it violates none of the restrictions imposed on the platform. The candidate component itself is declared admissible if all its requirements are admissible. A component can be hosted on the JAMUS platform only after it has been declared admissible by the resource broker.

Consider the requirements R2 and R3 expressed by the candidate component reproduced in Figure 5, and assume that the broker is checking these requirements against the platform's restrictions defined in Figure 2. Since the pattern defined in R2 only conforms to that of C1, the permission and quota conditions required in R2 should only be checked against those imposed in C1. The broker must thus check that the access permissions (resp. quotas) required in R2 do not violate the restrictions imposed in C1. In the present case, R2 can be declared admissible by the broker.

The pattern defined in R3 conforms to those defined in both C2 and C3. Access to the part of the file-system considered in R3 should thus be performed according to the restrictions imposed in both C2 and C3. Analysis of the access permissions required in R3 shows that they contradict neither the restrictions imposed in C2, nor those imposed in C3. On the other hand, although the access quotas required in R3 are compatible with those imposed in C2, they do not conform to those imposed in C3. Requirement R3 should thus be declared as non-admissible by the resource broker: the requirement expressed in R3 could not be satisfied by JAMUS without violating at least one of the restrictions imposed on the platform. As a consequence, the candidate component shown in Figure 5 should be declared as non-admissible by the platform, assuming that this platform is bound by the restrictions shown in Figure 2.

Resource reservation and release. When a candidate component has successfully passed the admission control test, it can start running on the platform. However, JAMUS commits itself to providing hosted components with the resources they require. The resource broker is responsible for this commitment on behalf of the entire platform. Resource reservation is achieved by dynamically updating the broker's "perception" of the resources available on the platform.

Once a component has been declared admissible by the broker, and before this component actually starts running, the broker updates the quota values in the platform's restrictions, based on the component's requirements. Hence, whenever the requirements of a new candidate component are examined by the broker, these requirements are actually checked against a set of profiles that model the currently available resources, rather than the resources that were available when the broker was first initialised.

Likewise, when a component reaches completion the broker updates the quota values in the platform's restrictions accordingly, so as to account for the release of the resources that were reserved for this component.

Resource Access Supervision: Contract Monitoring

Monitoring entities

Every component hosted by the JAMUS platform runs under the control of a component monitor. This monitor uses the resource utilisation profiles provided by the component to instantiate as many resource monitors.

A resource monitor admits a ResourceUtilisationProfile as a construction parameter. Its mission is to monitor the resources whose characteristics match the pattern defined in this profile, and to enforce the profile's access permissions and quotas on these resources.

JAMUS includes different kinds of resource monitors. For example, the class Socket-Monitor implements a resource monitor dedicated to socket resources. When monitoring the resources used by a hosted component, the role of a SocketMonitor is to check that the socket resources that satisfy the selection criterion defined in its SocketPattern are used according to the conditions specified in its SocketPermission and SocketQuota.

As an example, consider the component shown in Figure 5, and assume that this component has been admitted by the JAMUS platform. When loading this component, the platform creates a component monitor. This monitor examines the requirements of the component, and since these requirements are expressed as four resource utilisation profiles, it creates four resource monitors. Two of these resource monitors are Socket-Monitors, and the other two are FileMonitors. The first SocketMonitor receives profile R1 as a construction parameter. From this time on it is thus dedicated to monitoring the use of all the Socket resources the hosted component may create at runtime, while enforcing the global quotas specified in R1 (no more than 20 MBytes sent, no more than 80 MBytes received) on these sockets. The second SocketMonitor receives R2 as a construction parameter: it will thus have to monitor only sockets connected to hosts of the remote Internet domain "univ-ubs.fr", enforcing the quotas specified in R2 (no more than 5 MBytes sent, no more than 12 MBytes received) on these sockets.

Notice that at runtime any socket monitored by the second SocketMonitor shall be also monitored by the first one, as its characteristics will match the patterns defined in both R1 and R2. A resource may thus be supervised by several monitors, just like a single monitor may have to supervise several resources simultaneously.

The remaining of this section gives an overview of the mechanisms component monitors and resource monitors rely on.

Resource tracking

In JAMUS all resources are modelled as Java objects (instances of classes Socket, File, CPU, etc.), which can be created and destroyed (or, more precisely, de-referenced) dynamically by a hosted component. As a consequence, the component monitor that is responsible for monitoring a given hosted component must be informed about any creation or destruction of a resource object by this component. The JAMUS platform implements a resource register, whose role is to identify and to keep track of all resource objects used by a hosted component.

In the current implementation of the platform a distinct resource register is associated with each hosted component. Moreover, each component is loaded using a distinct ClassLoader. This approach ensures that resource objects used by different components are registered separately. It also guarantees that two hosted components do not share the same name-space, hence preventing resource capture and corruption between concurrent components.

Monitoring models

Resource monitoring is said to be achieved synchronously when any attempt to access a given resource can be intercepted and checked immediately by the monitors associated with this kind of resource. Synchronous monitoring can be obtained quite easily when a resource is modelled by an accessor object, that is, when accessing a resource comes down to calling a method on a Java object that represents this resource in the Java environment. Classes Socket, DatagramSocket, File, etc. are accessor classes: they model conceptual resources, and as such they define accessor objects that can be submitted to synchronous monitoring.

All resources cannot be monitored using the synchronous approach, though. For example, although all Java components (or, more precisely, all Java threads) consume shares of the CPU resource, they do not do so explicitly by calling methods on an object that would model the underlying hardware CPU. Instead, access to the CPU is controlled exclusively by the scheduler of the Java Virtual Machine, or by that of the underlying operating system [START_REF] Veners | Inside the Java 2 Virtual Machine[END_REF]. In order to deal with resources that cannot be monitored synchronously, such as the CPU, we propose to do with asynchronous monitoring. Monitoring a resource asynchronously consists in consulting the state of this resource every now and then, in such a way that the time of the observation does not necessarily coincide with the time of an attempt to use the resource.

RAJE provides abstractions and implementation alternatives for performing both kinds of monitoring. Some of these facilities are used in JAMUS to put resources under the control of resource monitors.

Implementation of the synchronous model. Synchronous monitoring is obtained in RAJE by implementing a call-back mechanism in resource classes. Any resource object admits a set of listeners. Whenever a method is called on a resource object by an application component, the resource object informs all its registered listeners that an attempt is being made to access the resource it models. A listener can refuse that a certain operation be performed on a resource by returning a ResourceAccessException signal to the corresponding resource object. In such a case the resource object must abort the operation considered, and return the appropriate exception signal to the application component.

With this approach a resource monitor that implements the synchronous model can keep informed about any operation attempted on the resource objects it monitors.

Implementation of the asynchronous model. In order to be observable asynchronously, an object that models a resource must be able to produce an observation report on demand. In RAJE, an observation report is an object that implements the Observa-tionReport interface. RAJE provides a specific implementation of this interface for each type of resource considered to date. Moreover, each resource class defines a method observe() that returns the appropriate kind of ObservationReport.

For example, a Thread object (threads are considered as resources in JAMUS) can produce a ThreadReport, which reports the current priority level of this thread, as well as the amount of CPU it consumed during the last observation period. Likewise, the method observe() implemented in class Socket returns a SocketReport, which reports the current characteristics of the corresponding socket (remote address and port, number of bytes sent and received since this socket was opened, etc.).

RAJE also provides mechanisms for controlling resources. For example many resource classes defined in RAJE implement interface Lockable. When a resource object is locked, utilisation of this object by an application component is denied, and any attempt to access the associated resource raises an exception signal.

Notice that observation and locking facilities have been kept separate in RAJE. The reason for this separation is that although all resources can be observed quite easily, there are resources (such as the system CPU) that can hardly be locked.

Dealing with Faulty Components

Resource monitors in JAMUS rely on either the asynchronous or the synchronous facilities implemented in RAJE in order to monitor the resources whose characteristics match their pattern. Each monitor enforces the access permissions and quotas defined in its profile on the resource objects it monitors. Whenever a transgression is observed, the monitor notifies the resource broker. The broker then terminates the faulty component. Release of the resources this component used is accounted by the broker, so that these resources can later be reassigned to new candidate components.

Related Work

The Java Runtime Environment (JRE) implements the so-called sandbox security model. In the first versions of the JRE, this security model gave local code -considered as safe code-full access to system resources, while code downloaded from the Internet (for example under the form of an applet) was considered as untrusted, and was therefore only granted access to a limited subset of resources [START_REF] Gong | Java Security: Present and Near Future[END_REF]. With the Java 2 platform this restrictive security model was abandoned for a new model that relies on the concept of protection domain [START_REF] Gong | Java Security: Present and Near Future[END_REF][START_REF] Gong | Implementing Protection Domains in the Java Development Kit 1.2[END_REF][START_REF] Veners | Inside the Java 2 Virtual Machine[END_REF]. A protection domain is a runtime environment whose security policy can be specified as a set of permissions. An access controller is associated with each protection domain. It checks any resource access performed from this domain, and it implements the security policy as defined by the permissions associated with the domain.

J-Kernel extends this approach by permitting communication and data sharing between protection domains [START_REF] Hawblitzel | Implementing Multiple Protection Domains in Java[END_REF]. Communication between domains is however limited to method calls on so-called capability objects.

The security models implemented in J-Kernel and in the JRE rely on stateless mechanisms. Access to a specific resource cannot be conditioned by whether the very same resource was accessed previously, or by how much of this resource was consumed previously. Hence, quantitative constraints (amount of CPU, I/O quotas, etc.) cannot be set on the resources accessed from protection domains. As a consequence, the security mechanisms implemented in J-Kernel and in the JRE cannot prevent abnormal operations resulting from an abusive consumption of resources (denial of service attacks, etc.).

Environments such as JRes [START_REF] Bagaratnan | Resource Access Control for an Internet UserAgent[END_REF][START_REF] Czajkowski | JRes: a Resource Accounting Interface for Java[END_REF], GVM [START_REF] Back | Techniques for the Design of Java Operating Systems[END_REF], and KaffeOS [START_REF] Back | Processes in KaffeOS: Isolation, Resource Management, and Sharing in Java[END_REF] partially solve the above-mentioned problem. They include mechanisms that permit to count and to limit the amounts of resources used by an active entity (a thread for JRes, a process for GVM and KaffeOS). However, resource accounting is only achieved at coarse grain. For example it is possible to count the number of bytes sent and received by a thread (or by a process) through the network, but it is not possible to count the number of bytes exchanged with a given remote host, or with a specific remote port number. Similarly, it is possible to count how many bytes have been written to (or read from) the file system, but it is not possible to set particular constraints on the use of specific directories or files.

Projects Naccio [START_REF] Evans | Flexible Policy-Directed Code Safety[END_REF][START_REF] Evans | Policy-Directed Code Safety[END_REF] and Ariel [START_REF] Pandey | Providing Fine-Grained Access Control for Java Programs[END_REF] are dedicated to security. Both provide a language for defining a security policy, as well as mechanisms for enforcing this policy while an application program is running. Security policy enforcement is carried out statically, by rewriting the application program byte-code as well as that of the Java API. An advantage of this approach is that the cost of the supervision of a program is kept at a minimum, for code segments that check the access to a particular kind of resource are inserted in Java API classes only if the selected security policy requires it. However, the generation of an API dedicated to a specific security policy is a quite expensive procedure. The approach proposed in Naccio and Ariel is thus mostly dedicated to the generation of predefined Java APIs that each enforce a generic security policy. Unlike the JAMUS platform, though, Naccio and Ariel can hardly ensure the supervision of an application program, when the security policy must be derived from the resource requirements specified by the application program itself.

[8] presents a resource-constrained sandboxing approach that shows much similitude with ours. The sandbox described in this paper can enforce qualitative and quantitative restrictions on the system resources used by application programs, while providing these programs with soft guarantees of and fairness of resources. It monitors the application's interactions with the underlying operating system, pro-actively controlling these interactions in order to enforce the desired behaviour. The paper distinguishes between implicit and explicit requests to the OS, and it shows that resource utilisation can be constrained either by intercepting explicit requests to the OS, or by monitoring the frequency of implicit requests. This distinction obviously compares with our observation that resource monitoring should be performed either synchronously or asynchronously, depending on the kind of resource considered, and on the desired level of control. Unlike the other works reported in this section, and unlike JAMUS, the sandbox described in [START_REF] Chang | User-level Resource-constrained Sandboxing[END_REF] is not object-oriented. It relies on standard shared system libraries available in Windows NT and in Linux, in order to provide sandboxing for executable programs.

The development of the JAMUS platform (and of the underlying environment RAJE) is still in progress. As a consequence, JAMUS is obviously still limited and quite perfectible. In the following we list some of the problems we should address shortly, as well as some of the lines we plan to work along in the future.

In the current implementation, resource usage profiles must be expressed as Java source code (as shown in Section 3). This is a rather crude, and sometimes not-soconvenient creation procedure. We should soon raise this limitation, though, as it would be most interesting if profile objects could be stored in files, and retrieved from these files at startup. An approach to achieve this goal would be that all ResourceUtilisation-Profile objects implement the standard Java interface Externalizable. Another interesting approach would be to define a dedicated XML-based language, so that profiles can be defined and edited using some of the tools developed around the XML technology.

The current syntax, grammar, and semantics associated with resource utilisation profiles have not been formerly defined. Besides, they could certainly be improved so as to gain expressiveness and flexibility. For example it would be interesting if resources could be reserved for groups of components, rather than for individual components. Another possibility would be to complement the mechanism of resource reservation with alternative access schemes (such as best effort, priority-based access, etc.).

Resource contracting in JAMUS relies on a quite simplistic model: the requirements of a component must all be known and fully expressed before this component can be admitted on the platform. In many cases, though, the requirements of a component can hardly be defined statically, because they depend on parameters the component should only discover at runtime, or because they are likely to change dynamically while the component is running. The architecture of JAMUS gives provision for more flexible contract-management mechanisms. New facilities should be included in the platform in the near future so as to permit that contracts be subscripted, cancelled, or modified dynamically throughout a component's lifetime.

Since the development of the platform is not complete, no performance evaluation has been performed so far. However, the fact that JAMUS relies on fully dynamic mechanisms suggests that the cost of monitoring Java components at runtime might be rather high. In compensation, we believe that this cost could eventually be considered as acceptable, considering that the platform makes it possible to control resources at a very fine grain, and considering it should soon be possible for a component to negotiate contracts dynamically.

JAMUS constitutes a demonstrator platform, with which we experiment with the idea of resource-constrained software deployment. It is our conviction that many other application domains and systems (such as agent-based systems, or adaptive systems) could benefit of -or take inspiration from -the models and mechanisms we develop in this particular context.

Figure 1 .

 1 Figure 1. Overview of the platform's architecture

FilePattern

Figure 4 .

 4 Figure 4. Excerpt from the resource pattern hierarchy, as defined in JAMUS.

Figure 5 .

 5 Figure 5. Example of an simple application program that specifies its own requirements regarding the resources it plans to use at runtime.

ResourcePattern ResourcePermission ResourceQuota Figure 3. Object

  -oriented modelling of resource utilisation profiles.

	int MB = 1024*1024;
	ResourceUtilisationProfile C1, C2, C3;
	// Global restrictions set on all socket-based
	// communications: 200 MB sent, 500 MB received.
	C1 = new ResourceUtilisationProfile(
	new SocketPattern(),
	new SocketPermission(SocketPermission.all),
	new SocketQuota(200*MB, 500*MB));
	// Global restrictions set on any access
	// to directory /tmp: 100 MB written, 100 MB read.
		ResourceUtilisationProfile
		ResourcePattern
	+conformsTo(other:ResourcePattern): boolean
	+isMatchedBy(res:Resource): boolean
		SocketPattern
	ThreadPattern	+remoteDomain: InetDomain
	+parentId: int	+minPort: int +maxPort: int

C2 = new ResourceUtilisationProfile( new FilePattern("/tmp"), new FilePermission(FilePermission.all), new FileQuota(100*MB, 100*MB)); // Selective restriction set on any access // to directory /tmp/jamus: 15 MB written, 40 MB read. C3 = new ResourceUtilisationProfile( new FilePattern("/tmp/jamus"), new FilePermission(FilePermission.all), new FileQuota(15*MB, 40*MB)); Figure 2. Example of restrictions imposed on the JAMUS platform.

http://www.univ-ubs.fr/valoria/Orcade/RASC


Frédéric Guidec

Nicolas Le Sommer

Towards resource consumption accounting and control in Java: a practical experience

Introduction

All software components are not equivalent as far as resource access and consumption are concerned. Some components can do very well with sparse or even missing resources, while others require guaranteed access to the resources they need. In order to deal with non-functional requirements pertaining to resource utilisation we propose a contractual approach of resource management and access control. This idea is being investigated in the context of project RASC1 (Resource-Aware Software Components). In this project our objective is to provide software components with means to specify their requirements regarding hardware and/or software resources, and to design methods and models for utilising this kind of information at any stage of a component's life-cycle.

This short paper reports the design of two software products called RAJE and JAMUS, whose development is in progress in the context of project RASC. RAJE is an extension of the standard Java 2 platform. It reifies system resources as well as "conceptual" resources so that they can be observed -and, in some cases, controlled -by Java application programs. RAJE also provides facilities for implementing resource monitors, using either a synchronous or an asynchronous model. JAMUS (the acronym stands for Java Accommodation of Mobile Untrusted Software) is an experimental platform we develop on top of RAJE. It supports the deployment of "untrusted" software components, provided that these components can specify their requirements regarding resource utilisation in both qualitative (eg access rights to parts of the file system) and quantitative terms (eg read and write quotas). Emphasis is put on providing a safe and guaranteed runtime environment for such components.

RAJE: a Resource-Aware Java Environment

Motivation

The architecture of the Java 2 platform implements a security architecture that relies on the notions of protection domain and access controller [START_REF] Gong | Java Security: Present and Near Future[END_REF][START_REF] Gong | Implementing Protection Domains in the Java Development Kit 1.2[END_REF]. A protection domain is a runtime environment whose security policy can be specified as a set of permissions. An access controller can be associated with each protection domain. Its role is to check any resource access performed from this domain. This security model relies on stateless mechanisms. Access to a specific resource cannot be conditioned by whether the very same resource was accessed previously, or by how much of this resource was consumed previously. Hence, quantitative constraints (amount of CPU time, I/O quotas, etc.) cannot be set on the resources accessed from protection domains. As a consequence, although the security mechanisms implemented in the JRE are appropriate for achieving qualitative control over resource usage, they can hardly be used to achieve quantitative control over resource consumption.

RAJE aims at providing means to monitor both resource access and resource consumption at middleware level. Moreover it makes it possible to monitor the usage of "global" resources (CPU, system memory and swap, etc.), as well as that of the resources used specifically by Java programs (TCP and UDP sockets, CPU time and memory consumed by each Java thread, etc.). RAJE can actually be perceived as an extension of the traditional runtime environment of the Java 2 platform. This extension provides various facilities for monitoring the resources of the underlying OS and hardware platform, as well as for monitoring and controlling the resources used by Java application programs at runtime.

Resource modelling: system resources vs conceptual resources

In RAJE all resources are modelled as first-class Java objects. From this viewpoint it compares with other resource-awaenvironments, such as JRes [START_REF] Czajkowski | JRes: a Resource Accounting Interface for Java[END_REF] and KaffeOS [START_REF] Back | Processes in KaffeOS: Isolation, Resource Management, and Sharing in Java[END_REF]. RAJE includes classes that reify system resources (CPU, memory, swap, etc.) as well as classes that model "conceptual" resources, that is, resources that mostly make sense at application level (sockets, files, threads, etc.). Some of these classes are specific to RAJE, while others simply provide alternative implementations for classes of the standard Java API. For example, standard Java classes Socket and File were given specific implementations in RAJE, so that any access to the conceptual resources they model can be monitored and controlled at runtime. More generally, information about any system or conceptual resource can be gathered by calling appropriate methods on the Java object modelling this resource in RAJE. Of course the nature of the information hence obtained depends on the type of resource considered. Below is a list of the types of resources RAJE currently allows for. For each resource type the information that can be collected is specified in brackets: System CPU (processor type, speed and cache size) System memory and swap (available size, current consumption) System processes and threads (CPU and memory consumption) Java threads (CPU and memory consumption for each thread or group of threads, priority level, scheduling policy) Java TCP and UDP sockets (local and remote addresses and ports, number of bytes sent and received, number of UDP datagrams sent and received through each socket) Java files (number of bytes written/read to/from each file) RAJE was designed so as to be highly extensible. Hence new classes should be included in the distribution in the near future in order to model network interfaces (including wireless interfaces), as well as the battery of a laptop.

Extending the standard JRE: trading portability for control

Most of the code included in RAJE is pure Java and, as such, is readily portable. However, part of this code consists of C functions that permit the extraction of information from the underlying OS, and the interaction with inner parts of the JVM (Java Virtual Machine). To date RAJE is implemented under Linux, and the JVM it relies on is a variant of TransVirtual Technology's Kaffe 1.0.6. System resources such as the CPU and system memory are monitored by polling various files in the /proc pseudo file-system of the Linux OS.

The JVM was modified in such a way that memory consumption can be traced on a per thread basis. Whenever a new Java object is created, the amount of memory hence consumed is put on the currently active thread's account. Likewise, whenever an object is collected by the JVM's garbage collector, the amount of memory hence freed is deducted from the account of the thread that was active when the object was created.

The JVM was also modified so that Java threads are implemented as standard Linux native threads. This approach gives us better control over the CPU resource. For example, it makes it possible to monitor the amount of CPU consumed by each Java thread, since this information is readily available under /proc for any Linux thread

The standard API for Java threads was extended so that the amount of memory and CPU time (in user time and system time) consumed by any thread can be observed by simply calling a method on the thread considered. The amount of memory and CPU time consumed by a group of threads can be observed similarly.

Since Linux threads are actually POSIX threads, the API for Java threads was extended so that Java threads can take benefit of the three scheduling strategies defined in the POSIX standard (FIFO, Round-Robin, and a third strategy referred to as SCHED_OTHER). However in Linux the FIFO and Round-Robin strategies are reserved for processes and threads that run with superuser privileges. "Normal" processes and threads must do with the default SCHED_OTHER strategy, which in Linux implements a time-sharing policy with dynamic priority. All three strategies are thus available for Java threads in RAJE, but only if the JVM itself is started with superuser privileges. Otherwise all Java threads are submitted to the standard SCHED_OTHER policy.

Resource tracking and protection

In RAJE all resources are modelled as Java objects (instances of classes Socket, File, Thread, CPU, Memory, etc.). Since such objects can be created and destroyed -or, more precisely, de-referenced -dynamically by Java programs, RAJE implements a resource register, whose role is to identify and to keep track of resource objects at runtime. By consulting the resource register a program can locate all the objects that model system or conceptual resources in its name space.

With the current security model of the Java 2 architecture, several "protection domains" can be created within a single virtual machine by loading distinct application programs using as many ClassLoader objects. In RAJE a distinct resource register can similarly be associated with each protection domain, so that the resource objects used by different programs running in the same JVM will be registered separately. On the one hand this approach helps preventing resource capture and corruption between concurrent programs: a program will not be able to locate and gain access to the resource objects used by another program. On the other hand, some kind of collaboration between resource registers could sometimes be desirable (for example to locate and to keep track of shared resources). Although we have not tackled this problem yet, we think that it should be possible to build a hierarchy of resource registers, so that these registers can somehow collaborate and share part of their knowledge about resources in a controlled and safe way.

Support for consumption accounting: asynchronous vs synchronous monitoring

RAJE provides abstractions and implementation alternatives for performing resource consumption monitoring in either a synchronous or asynchronous way.

Resource monitoring is said to be achieved synchronously when any attempt to access a given resource can be intercepted and checked immediately. This approach can be implemented quite easily for conceptual resources, for any access to such resources implies that a method be called on a Java object (such as an instance of classes Socket, DatagramSocket, or File).

Synchronous monitoring is obtained by implementing a call-back mechanism in resource classes. Any resource object can admit one or several listeners. Whenever a method is called on a resource object by an application program, the resource object informs all its registered listeners that an attempt is being made to access the resource it models. This approach makes it possible to design dedicated resource monitors, that will be able to register as listeners of a specific set of resource objects in order to keep informed about the usage of these resources.

All resources cannot be monitored using the synchronous approach, though. For example, in most current implementations of the JVM Java threads are implemented as native threads. Access to the CPU is not achieved by calling methods explicitly. Instead it is controlled directly by the scheduler of the underlying operating system. In order to deal with system resources such as the CPU (system memory, network interfaces, etc.), which can hardly be monitored synchronously, we propose to do with asynchronous monitoring. Monitoring a resource asynchronously consists in consulting the state of this resource explicitly every now and then, in such a way that the time of the observation does not necessarily coincide with the time of an attempt to use the resource.

In order to be observable asynchronously, an object that models a resource in RAJE must be able to produce an observation report on demand. For example, a Thread object (threads are considered as resources in RAJE) can produce a ThreadReport, which reports the current priority level and scheduling policy for this thread, as well as the amount of CPU it consumed during the last observation period.

Both monitoring models are indeed complementary models. Dedicated monitors can be designed in order to trace any kind of resource usage, using either the asynchronous or synchronous facilities offered by RAJE. In any case deciding which model should be applied comes down to making a tradeoff between the precision of monitoring, and the cost of monitoring.

Indeed synchronous monitoring can be quite costly, especially when the actions being monitored require very little time (eg imagine that a network monitor requires to be notified synchronously whenever a single byte is being sent through a TCP socket). In return, synchronous monitoring makes it possible to monitor resource access and consumption at a very fine grain, since any access to a given resource object can be traced and accounted for.

Conversely, asynchronous monitoring permits resource objects to be polled periodically in order to consult their status. Of course, the longer the period, the less intrusive the monitoring. But in return, there is a risk that interesting or critical events be either detected too late, or even ignored because they fell in between two consecutive observations of the resources considered.

Support for resource access control: object locking

RAJE provides mechanisms for controlling the usage of resources. For example all conceptual resource classes implement interface Lockable. Any conceptual resource object can thus be locked and unlocked explicitly. When a resource object is locked, utilisation of this object by an application program is denied until the object is unlocked. Any attempt to access a locked resource by calling a method on the associated object raises an exception signal. This mechanism makes provision for the implementation of high-level Java-based scheduling and policy enforcement strategies. In the current implementation, though, any application program that wishes to access a locked resource object can unlock this resource on its own authority. The methods defined in interface Lockable should somehow be "protected" (for example using an authentication procedure) so that resource locking and unlocking can only be achieved by authorised Java components or programs.

Towards a contract-based approach of resource consumption

Motivation

RAJE is dedicated to supporting high-level resource-aware environments and applications, such as adaptive systems, security-oriented systems, or QoS-oriented systems. Adaptive software components could take advantage of the monitoring facilities implemented in RAJE in order to "discover" at startup the resources offered by their runtime environment, and to keep informed about the status of these resources at runtime. Security-oriented systems could rely on the same facilities to enforce security policies regarding resource access and consumption. As for QoS-oriented systems, they could rely on these facilities to manage resources in such a way that resource consumers (that is, software components) can get a level of service that goes far beyond the traditional "best effort" policy.

JAMUS is an experimental platform that lies at the frontier between the two latter categories. It is dedicated to supporting the deployment of "untrusted" software components (such as application programs and applets), provided that these components can specify their requirements regarding resource utilisation in both qualitative (eg access rights to parts of the file system) and quantitative terms (eg read and write quotas). These components could be downloaded from remote Internet sites or received as Email attachments before being deployed on the platform. As a consequence, emphasis is put in JAMUS on providing a safe and guaranteed runtime environment for components of such dubious origin (the acronym JAMUS actually stands for Java Accommodation of Mobile Untrusted Software), as well as guaranteed QoS as far as resource availability is concerned.

Overview

Resource control in JAMUS is based on a contractual approach. Whenever a software component applies for being deployed on the platform, it must specify explicitly what resources it will need at runtime, and in what conditions. Moreover access conditions can be specified in both a qualitative way (eg access permissions) and a quantitative way (eg access quotas). By specifying its requirements regarding resource access privileges and quotas, the candidate component requests a specific service from the JAMUS platform. At the same time it promises to use no other resource than those mentioned explicitly. In return, whenever the platform accepts a candidate component, it promises to provide this component with all the resources it requires. At the same time it reserves the right to sanction any component that would try to access other resources than those it required.

The main originality of our approach with respect to related works (see for example [START_REF] Evans | Flexible Policy-Directed Code Safety[END_REF][START_REF] Bagaratnan | Resource Access Control for an Internet UserAgent[END_REF][START_REF] Chang | User-level Resource-constrained Sandboxing[END_REF]) lies in the fact that a specific contract must be subscribed between the JAMUS platform and each software component it accommodates. Based on these contracts, JAMUS provides some quality of service regarding resource availability. It also provides components with a relatively safe runtime environment, since no component can access or monopolise resources to the detriment of other components.

Implementation details

JAMUS implements a resource broker, whose role is to guarantee the availability of resources for hosted components. At startup, the broker is given a description of the available resources, as well as instructions on how these resources should be used by components. JAMUS provides a series of interfaces and classes that enable the specification of resource access conditions as "resource utilisation profiles" (see [START_REF] Le | JAMUS: Java Accommodation of Mobile Untrusted Software[END_REF][START_REF] Le | A Contract-Based Approach of Resource-Constrained Software Deployment[END_REF] for details). Such profiles can thus be defined as Java code, and handled at runtime as standard Java objects.

Contract subscription is achieved as a two-step procedure. Any software component that applies for being deployed on the JAMUS platform must first pass an admission control examination. The requirements of this component must also be expressed as a set of resource utilisation profiles. These requirements are examined by the resource broker in order to decide if the component can be admitted on the platform. Admission control is based on a simple, yet effective resource reservation scheme: a component is admissible only if the resources it requires are available on the platform in sufficient quality and quantity. Moreover when a component is admitted the resources it required are "reserved" for its sole usage until it reaches completion.

When a candidate component has successfully passed the admission control test, it can start running on the platform. However, once a component has been accepted, it is still considered as non-trustworthy. A component designed in a clumsy way -or in a malevolent perspective -may attempt to misbehave by accessing resources it did not explicitly ask for. In order to prevent such problems every component hosted by the JAMUS platform runs under the control of a dedicated component monitor, whose implementation relies on the monitoring and control facilities offered by RAJE (see [START_REF] Le | JAMUS: Java Accommodation of Mobile Untrusted Software[END_REF][START_REF] Le | A Contract-Based Approach of Resource-Constrained Software Deployment[END_REF] for details). Whenever a monitor observes that the component it is in charge of is misbehaving, it can sanction the component. Sanctioning a component is done either by locking the resources considered, or by killing the component itself.

Discussion and perspectives

The development of both RAJE and JAMUS is still in progress. As a consequence, both products are obviously still limited and quite perfectible. In the following we list some of the problems we should address shortly, as well as some of the questions we'd like to answer in the future.

No extensive performance evaluation has been performed so far. However, preliminary experiments have shown that the overhead of resource monitoring in JAMUS remains quite low. For example, in order to evaluate the specific overhead of network activity monitoring, measurements have been realized with a Java-based FTP server 2 run as a component hosted (and constantly monitored) by JAMUS. During this experiment, file uploads and downloads realized by the server in these conditions showed no detectable degradation of performance.

Resource contracting in JAMUS relies on a quite simplistic model: the requirements of a component must all be known and fully expressed before this component can be admitted on the platform. In many cases, though, the requirements of a component can hardly be defined statically, because they depend on parameters the component should only discover at runtime, or because they are likely to change dynamically while the component is running. The architecture of JAMUS makes provision for more flexible contract-management mechanisms. New facilities should be included in the platform in the near future so as to permit that contracts be subscripted, cancelled, or modified dynamically throughout a component's lifetime.

JAMUS constitutes a demonstrator platform, with which we experiment with the idea of resourceconstrained software deployment. It is our conviction that many other application domains and systems (such as agent-based systems, or adaptive systems) could benefit of -or take inspiration from -the models and mechanisms we develop in this particular context.

http://www.univ-ubs.fr/valoria/Orcade/RASC

JFTPd server developed by the MIT (http://jftpd.prominic.org/index.html). Experiment achieved using two workstations (with PII processors) directly connected by a point-to-point 100 Mbps Fast Ethernet link.