Hervé Roussain

Frédéric Guidec

A Peer-to-Peer Approach to Asynchronous Data Dissemination in Ad Hoc Networks

Keywords: ubiquitous computing, peer-to-peer computing, ad hoc networking, data dissemination

This paper presents a model for the dissemination of information in highly dynamic ad hoc networks, such as those composed of mobile communicating devices. This model relies on an asynchronous, peer-to-peer propagation scheme. This approach is expected to help do with station volatility, as it allows communication between devices that are never -or only rarely-active simultaneously in the network. It is also expected to help transport information in a fragmented network, as a station roaming between network islands can provide its neighbors with information it has gathered previously while visiting another part of the network.

I. INTRODUCTION

Nowadays we observe a multiplication of commercial offers for portable digital devices such as laptops and personal digital assistants (PDAs), which can be equipped -or are equipped nativelywith Bluetooth or IEEE 802.11 wireless interfaces. For the owners of such devices, the prospect of exchanging information and services with other people without systematically resorting to some infrastructure network should obviously appear as an attractive one. Yet, although many devices are nowadays capable of ad hoc communication, this possibility is still rarely used. There are actually several reasons for this apparent lack of interest in ad hoc communication. Among these reasons is the fact that most of the application software we are nowadays familiar with (electronic mail, discussion forums, file transfer and file sharing, etc.) was designed and implemented so as to be used on traditional workstations connected to infrastructure networks. As a consequence most of the above-mentioned applications are usually implemented based on the client-server paradigm, with which services are actually offered by servers whose accessibility must be guaranteed to client programs. Moreover these applications often rely on chatty protocols, and they require synchronous interactions between clients and servers (a thorough analysis of these problems can be found in [START_REF] Fall | A Delay-Tolerant Architecture for Challenged Internets[END_REF]).

Mobile communicating devices usually show characteristics that are quite different from those of standard workstations (slower processors, less memory, smaller or no hard disk, "exotic" user interfaces, low power-budget, etc.). In the same time, ad hoc networking distinguishes itself from infrastructure networking by (usually) lower transmission rates, unstable network topology, transient -and often unpredictable-connectivity, etc. A piece of application code that has been originally designed to run on powerful workstations, and to communicate through a stable, almost fully reliable infrastructure network, can usually not be ported and used as is on a heterogeneous set of mobile devices participating in an ad hoc network.

Our work aims at fostering the design, the implementation, and the deployment of new application services capable of running on mobile, ad hoc communicating devices. In this work we address problems pertaining to the definition of such application services, to their deployment on mobile devices, and to their execution on these devices.

In this paper we present one of the services we have developed along this line. This service is meant to serve as one of the basic building blocks with which higher-level services can later be developed. It is dedicated to the dissemination of pieces of information in a dynamic ad hoc network, that is, a network composed of portable devices that are highly mobile and volatile. Such a network is illustrated in Figure 1, which shows a population of users that own portable devices capable of ad hoc communication. The devices in this net- work are mobile because the users themselves are mobile. Since the transmission range of a wireless interface is quite limited, the neighborhood of each device is limited (the circles in Figure 1 show the limited transmission range of each device). The neighborhood of a device can be loosely defined as the set of devices it can communicate with. Many current works aim at enlarging this neighborhood by implementing algorithms for dynamic data routing [START_REF] Royer | A Review of Current Routing Protocols for Ad-Hoc Mobile Wireless Networks[END_REF] and flooding [START_REF] Poupyrev | Analysis of Wireless Message Broadcast in Large Ad Hoc Networks of PDAs[END_REF], [START_REF] Qayyum | Multipoint Relaying; an Efficient Technique for Flooding in Mobile Wireless Networks[END_REF], [START_REF] Sasson | Probabilistic Broadcast for Flooding in Mobile Ad Hoc Networks[END_REF] in ad hoc networks. However, these algorithms rely on the assumption that a connected-path can be established between the sender and the receiver(s) at transmission time. When the density and the geographical distribution of devices is not favorable, the multi-hop network thus obtained usually remains a non-connected one. Figure 1 shows such a fragmented network. Devices that are close enough to communicate together (possibly with multi-hop transmissions) are said to reside on the same "island", while the distances separating two islands prevent any communication between devices located in distinct islands.

Another major characteristic of portable mobile devices is that they are quite volatile, that is, they are frequently switched off and on by their owners (if only to preserve their power-budget). Yet, traditional routing and flooding schemes only allow synchronous interactions between senders and receivers, as they require that the devices sending and receiving data are available simultaneously.

The service discussed in the remainder of this paper permits asynchronous information dissemination in a fragmented ad hoc network whose devices are highly mobile and volatile. This service is both application-oriented and documentoriented. Basically, we propose that any document sent in the network be maintained as long as possible in a local cache by as many devices as possible, so it can remain available for those devices that could not receive it at the time it was sent originally. The underlying idea is that the dissemination of multiple copies of the same document may help do with the volatility of devices, while the mobility of these devices can itself help transport information between islands in a fragmented network.

This propagation model is inherently a stochastic one, as eventual document delivery cannot be guaranteed. Interestingly, though, theoretical studies based on simulations (on variants of this model [START_REF] Vahdat | Epidemic Routing for Partially-Connected Ad Hoc Networks[END_REF], [START_REF] Lindgren | Probabilistic Routing in Intermittently Connected Networks[END_REF]) show that in many realistic scenarios, the probability that documents actually reach their destination can be quite high.

In any case, in our opinion the main interest of this model is that it makes it possible to disseminate documents among devices that would not have had a chance to receive these documents otherwise. For example, assume that device F in Figure 1 has sent information to device D before leaving the island where devices A to E currently reside. Device D has not received this document since it is presently in suspend mode. However, some of its neighbors may have accepted to store temporarily this document, and D will thus have a chance to obtain the document when it wakes up. Similarly, before leaving the island where devices A to E reside, F may have collected some documents that will be of interest to devices H and I when it reaches their island (and provided F is reactivated when reaching this island, since Figure 1 shows that it is in suspend mode during this transfer).

II. SERVICE DEFINITION

Our service for document dissemination relies on the general principle of peer-to-peer interaction: each device in the network can benefit from this service, while contributing itself to supplying this service.

Document addressing.

We intentionally adopted a highly flexible, high-level addressing scheme. This scheme makes it possible to address a document equally to a user, to a device, to a group of users, to a group of devices, to a specific service running on a specific device, etc. The underlying idea is that, since a user may for example own several devices, it should be possible to send a document to a user, without imposing that this document be received on one or another device. Similarly, it should be possible to send a document to a group of users (such as all members of a laboratory) without having to specify the identity of each of these users.

Document caching.

A cache must be implemented on each device, so that documents can be maintained in this cache when needed. The capacity of the cache can of course be adjusted on each device, depending on the resources available on this device. Moreover local strategies can be defined on each device in order to specify caching modalities for documents. Possible criteria for defining such strategies are document size, type, origin, destination, etc. Any high-level service that is liable to use the caching service -since this service is application-oriented-should be able to specify its own requirements regarding document caching.

Document flow.

Each device that participates in the dissemination of documents can play several distinct roles with respect to these documents.

• A device can be considered as the provider of a document if this document is stored locally (in its cache), and if it can send this document in the network.

• A device can be considered as the consumer of a document if it can receive this document from the network, and either use this document immediately or store this document in its cache (or both). Depending on circumstances, a device may play only one of these two roles, or both roles simultaneously. The behavior of a device may actually not be the same for all types of documents. For example the caching service may be configured so as to accept and receive only a certain category of documents from the network. Moreover these documents may be received and stored in the cache only for the benefit of other local application ser-vices. The device would thus behave as a consumer for certain documents, while refusing to disseminate these documents further. Conversely a device may be configured so as to provide its neighbors with documents produced locally, while refusing to consume similar documents received from the network.

Besides playing the role of a producer or consumer for a category of documents, a device can behave either proactively or reactively (or both) with respect to each of these roles.

A device that plays the role of a document provider can behave proactively by sending spontaneously this document in the network. Spontaneous transmission can for example occur when a document has just been produced locally, or when a document in the cache must be sent several times (periodically or sporadically). The latter strategy may help reach recipients that are suspected not to have received the document during former transmissions.

A document provider may also behave reactively by sending a document in the network after this document has been explicitly requested. It can of course show a mixed behavior, sending for example one document periodically (with a rather long period so as not to load the network too much), and replying immediately to explicit requests for this document.

Similarly, a device that plays the role of a document consumer can behave either proactively or reactively, or show both kinds of behavior simultaneously. A document consumer can behave proactively by sending requests for this document in the network (thus soliciting a reactive behavior from devices that possess a copy of this document). It can also behave reactively by receiving a document from the network, and consuming this document even if it has not been explicitly requested before.

The document caching service is not itself responsible for deciding how it should behave with respect to one or another category of documents. Instead, any higher-level service that requires that certain documents be sent, received, and forwarded through the ad hoc network is expected to interact directly with the caching service in order to specify its own requirements with respect to these documents. Document structure. Each document can be associated a document descriptor. The descriptor of a document is meant to provide information about the document (type, author name, keywords, content, etc.). A document may encapsulate its own descriptor, but the descriptor can also be handled separately (which means it can for example be transmitted, edited, stored, and displayed separately).

When an application-level document must be sent in the network, it must be encapsulated in a transfer document, whose descriptor specifies transmission parameters for this document.

<transfer-descriptor document-id="fb0097820f0b371" origin="principal:Pierre Dupont" destination="principal:VALORIA Team" type="service/email" number-of-hops="5" date="Jan 30 08:26:32 CET 2004" lifetime="12:00:00" advertisement-period="00:20:00" /> Figure 2 shows a typical XML-formatted transfer descriptor. The value of attribute document-id in a descriptor should be unique. This condition makes it possible for a device receiving a document from the network to verify if a copy of this document is already available in its local cache (in which case the document received is a duplicate that can be silently discarded).

The document descriptor in Figure 2 also specifies that this document has been sent by user Pierre Dupont (attribute origin) and that it is addressed to all members of the VALORIA laboratory (attribute destination). The attribute type specifies that the document was sent -and should thus be received and consumed-by an email service agent. The attribute number-of-hops plays approximately the same role as the field TTL (Time-To-Live) in IP packets. It helps preventing that a document propagates eternally in the network. The attribute date specifies the date when the document was originally sent in the network, and the attribute lifetime specifies that this document should be considered as being valid for only twelve hours after this date. The last attribute advertisement-period indicates that once the document has been put in the local cache of a device, this device may periodically announce that this document is available, with a periodicity of 20 minutes.

It is worth mentioning that a device that considers that its cache needs to be cleaned up has no obligation to maintain a document in this cache until it becomes obsolete. Likewise, a device has no obligation to announce that it owns a document, even if the descriptor of the document suggests an announcement period. In any case, attributes specifying a document's lifetime or suggesting a period for announcing the availability of this document are meant to serve as guidelines about how this document should be handled by devices. The actual behavior of each device with respect to the documents it maintains in its cache can be guided by such suggestions, but it can also conform to default strategies defined by higher-level services, or according to user-defined global strategies applying equally to all documents.

Advertisement and request documents. Specific kinds of documents are meant to contribute to document dissemination in the network, by allowing interactions between neighboring devices.

An "advertisement document" can be sent by a device to announce that it owns one or several documents in its cache, and that it can provide any of these documents on demand. An advertisement document is thus a transfer document in which attribute type in the descriptor characterizes a document sent by the caching service implemented on a device. Its payload is composed of one or several document descriptors, corresponding to the descriptors of the documents whose availability is being announced.

<transfer-descriptor document-id="fb55271h0f03hg5" destination="principal:VALORIA Team" number-of-hops="1" type="service/cache/descriptor/advertisement" origin="device:rama" /> <descriptor-list> <transfer-descriptor ... /> <transfer-descriptor ... /> </descriptor-list> An example of an advertisement document is shown in Figure 3. In this example a device called rama informs its neighbors that it owns a number of documents. In this particular case all neighbors are not supposed to pay attention to this advertisement, but only those that are interested in documents pertaining to the VALORIA laboratory (see attribute destination). Moreover this advertisement concerns two distinct documents, whose descriptors (not detailed in the figure) are encapsulated in the advertisement document.

A "request document" can be used by a device to ask for the transmission of a document, or that of several documents. A device can send a request after receiving an advertisement indicating that a specific document is available in the neighborhood. A request can also be sent spontaneously by a device that wishes to discover if a certain document is indeed available somewhere in the neighborhood. A request can be addressed specifically to a given device (for example after an advertisement has been received from this device), or it can be sent to all or part of the devices in the neighborhood. A request can ask for the direct transmission of a document, or it can ask that only the descriptor of this document be transmitted.

A request document is thus a transfer document in which attribute type in the descriptor characterizes a request addressed to the caching service implemented on the destination device(s). This attribute additionally specifies if this document requests that full documents be transmitted, or only their descriptors. The payload of a request document is composed of one or several descriptor patterns. The structure of a descriptor pattern compares with that of a descriptor, but for all or part of the attributes that can appear in a document descriptor, it specifies a regular expression to be applied to the corresponding attribute. A device receiving a descriptor pattern can thus use this pattern to examine the descriptors of the documents it maintains in its cache, and to decide which of these descriptors match the pattern. The device can then either send the selected documents, or only the descriptors of these documents, depending on the kind of reply requested.

An example of a request document is shown in Figure 4. In this example the request has been sent by the device called rama, and it has been ad-<transfer-descriptor document-id="fb56971h0f0b455" destination="device:*" number-of-hops="1" type="service/cache/descriptor-request" origin="device:rama" reply-to="principal:Pierre Dupont" /> <descriptor-pattern destination="principal:Pierre Dupont" after="Jan 30 08:00:00" /> dressed to all other devices in its close neighborhood (the number of hops is here set to 1, which precludes any propagation of the request beyond the devices that are direct neighbors of rama). The request asks that devices receiving this request send in return the descriptors of the documents they maintain in their cache, but only if these documents are addressed to user Pierre Dupont, and only if they were originally sent in the network after the date specified. Moreover, the attribute reply-to indicates that replies to this request should be addressed to all devices that take an interest in traffic pertaining to user Pierre Dupont, rather than being addressed to device rama only (remember that Pierre Dupont may own several devices, and that other users may have configured their devices so that they relay and forward documents addressed to Pierre Dupont). This example shows that a device behaving as a proactive consumer for some kind of document can formulate requests in such a way that its neighborhood can benefit from the transmission of documents it will itself have solicited.

As a general rule, advertisement and request documents make it possible to implement on each device some procedures ensuring the proactive and reactive behaviors mentioned earlier in this section. A device behaving as a proactive consumer can send its neighbors requests in order to ask for the direct transmission of specific documents, or in order to discover that some of its neighbors own documents it may be interested in. After receiving an advertisement for a document it is interested in, a reactive consumer can ask for the immediate transmission of this document. Similarly, a device behaving as a proactive producer can send advertisement documents in order to provide its neighbors with descriptors of the documents it can send them on demand.

III. IMPLEMENTATION DETAILS

The model presented in the former section has been implemented in Java. Documents and document descriptors are thus reified as standard Java objects, which can be sent in the network either as serialized Java objects, or as XML-formatted documents. In the current implementation, document dissemination is performed by broadcasting UDP datagrams. We thus assume, for the time being, that each document is small enough to fit in a single datagram. In the future we consider implementing a complementary service for document segmentation and reassembly.

The code we developed can be deployed equally on a multi-hop or single-hop network. It simply requires that a device can send a document to neighboring devices. In a multi-hop network (with data flooding), the neighborhood of a device is composed of all devices that reside on the same island. In a single-hop network, it is composed of those devices that can interact at link level with the sending device.

Several application-level services are also being developed in our laboratory. These services are designed in such a way that they can rely on the asynchronous document dissemination service discussed in this article. One of these services is a general messenging service, which features functionalities that are traditionally offered separately in the electronic mail service and in the newsgroup (or discussion forum) service. Indeed, messenging with this service can be performed either userwise or group-wise (that is, a message can be sent equally to a certain user, or to a certain community of users).

Another application-level service under development is a presence announcement service. It relies on the dissemination of specific documents announcing periodically or sporadically the presence of a person, or that of a device. With this service a device can provide its owner with an up-to-date graphical representation of all neighboring entities (users and devices) that have announced their presence.

Since documents exchanged in an ad hoc network are not necessarily meant to be received and consulted by all users of the network, we have also designed a cryptographic service that makes it possible to encrypt and to sign any kind of transfer documents. This service can be used liberally by higher-level services, such as the above-mentioned messenging and presence announcement services, whenever confidentiality or trust are needed during document dissemination.

IV. RELATED WORK

Our approach to document dissemination in ad hoc networks obviously compares with that proposed by Vahdat and Becker in [START_REF] Vahdat | Epidemic Routing for Partially-Connected Ad Hoc Networks[END_REF], where they introduce the concept of Epidemic Routing. In their model messages are buffered in mobile hosts, and random pair-wise exchanges of messages among these hosts allow eventual message delivery in partially-connected ad hoc networks. Although Vahdat and Becker are mostly concerned with unicast transmissions in their paper, they suggest that Epidemic Routing is appropriate for supporting multicast traffic as well. A variation of Epidemic Routing has been presented in [START_REF] Lindgren | Probabilistic Routing in Intermittently Connected Networks[END_REF], where the authors introduce probabilistic heuristics in order to augment the chances that a message is indeed routed toward its actual destination.

Our approach also compares with that of IRTF1 's group working on delay-tolerant networks (DTNRG: Delay-Tolerant Network Research Group2 ). This group focuses on the deployment of networks in extreme environments in which end-to-end data connectivity cannot be guaranteed. It has defined a new network architecture relying on the general principle of message switching in store-and-forward mode. This architecture can itself be implemented above standard protocol stacks. The approach fostered by the DTNRG consists in transporting pieces of information as so-called bundles, and implementing bundle forwarders that are capable of storing messages (or bundles) before they can be sent again [START_REF] Fall | A Delay-Tolerant Architecture for Challenged Internets[END_REF].

The mechanisms we propose for announcing the availability of a document, for requesting a document, and for seeking a document obviously show similitudes with those that have otherwise been proposed to perform service advertisement and discovery in ad hoc networks (a good survey of discovery protocols can be found in [START_REF] Rakotonirainy | Resource Discovery for Pervasive Environments[END_REF]). Indeed, we consider that the description of a service (offered or desired) simply constitutes a particular kind of information, which can therefore be encapsulated in some type of document. In our opinion, service advertisement and discovery should thus be perceived as particular applications whose implementation could rely on the more general document dissemination service we have designed.

V. CONCLUSION

The model presented in this paper permits the asynchronous dissemination of documents in highly dynamic ad hoc networks, such as those composed of mobile communicating devices. This model proposes an asynchronous, peer-to-peer, document-oriented propagation scheme. It requires that each document received by a device be maintained in a local cache, so it can be sent again in the network either spontaneously, or after a request for this document has been received from another device. This approach helps do with the volatility of devices, since it permits asynchronous communications between devices that are neveror only rarely-active simultaneously in the network. It also permits information dissemination in a fragmented network, by taking advantage of the mobility of devices.

A Java-based implementation of this model is now available. The asynchronous document dissemination service thus obtained is expected to serve as a building block during the development of higher-level application services. A messenging service and a service for presence announcement are two such high-level services, whose implementation is now in progress in our laboratory.

Figure 1 .

 1 Figure 1. Illustration of a typical dynamic ad hoc network whose nodes are volatile (D and F are here shown in standby mode) and mobile (F is shown "travelling" in the network), which yields transient or chronic network fragmentation ({A, B, C, E}, {G}, and {H, I} constitute -perhaps temporarily-three distinct islands in this example).

Figure 2 .

 2 Figure 2. Descriptor of a document exchanged within the context of an email messenging service.

Figure 3 .

 3 Figure 3. Example of a document announcing the availability of two documents (whose descriptors are not detailed here).

Figure 4 .

 4 Figure 4. Example of a request asking for the advertisement of all documents addressed to user Pierre Dupont after the specified date and time.

IRTF: Internet Research Task Force (http://www.irtf.org).

http://www.dtnrg.org

Acknowledgements. This work is supported by the French "Conseil Régional de Bretagne" under contract B/1042/2002/012/MASC.


Nicolas Le Sommer
email: nicolas.le-sommer@univ-ubs.fr

Frédéric Guidec
email: frederic.guidec@univ-ubs.fr

Middleware Support for Resource-Constrained Software Deployment

The JAMUS platform is dedicated to providing a safe runtime environment for untrusted Java application programs, while offering each of these programs access to the resources it needs to use at runtime. To achieve this goal, JAMUS implements a contractual approach of resource utilisation and control, together with a reservation-based resource management scheme, and a monitoring model. When getting deployed on the platform, a candidate program must first subscribe a contract with the resource manager of the platform. This contract describes the resources the program requires to be able to access at runtime, and how it plans to behave when accessing these resources. Based on this information, the platform can monitor programs at runtime, so that any violation of the contracts they subscribed can be detected and sanctioned. Moreover, since the specific needs of a program are liable to change (or to be refined) dynamically while this program is running, any program hosted by the platform can ask that its contract be re-negotiated at any time.

Introduction

The growing popularity of mobile and network-dependent Java application programs leads to an increased demand for deployment platforms that permit to launch and run potentially dangerous Java application programs (such as programs downloaded from untrusted remote Internet sites) in a restrained environment. Sun Microsystem's platform Java Web Start was designed in order to meet this demand. Yet, because this platform relies on the security model of the standard Java Runtime Environment (JRE) platform, it shows a number of limitations. For example, security in Java Web Start can only be obtained by restraining the access to a strictly pre-defined set of system resource types (namely, network sockets and files). Moreover, security is based solely on access permissions. In our opinion, this approach does not permit sufficient control over the behaviour of application programs.

With JAMUS (Java Accommodation of Mobile Untrusted Software) we give some solution to the above-mentioned. Resource access control in JAMUS can be applied to a larger (and easily extensible) variety of resource types (including the CPU and memory), and this control can be performed at a finer grain (for example, restrictions can be imposed of the amount of CPU time or memory consumed by each Java thread).

JAMUS implements a contractual approach of resource management and access control. Application programs are expected to evaluate and specify their own needs regarding the resources they wish to use at runtime. Based on this information, the platform can decide whether a candidate program should be accepted or rejected. Moreover, when a program has been accepted for running on the platform, its behaviour is monitored, so that any violation of the contract it subscribed with the platform can be readily detected and dealt with.

It is worth mentioning that JAMUS is not exclusively dedicated to enforcing a security policy. It also strives to meet the specific requirements of each of these programs. To achieve this goal the platform implements a resource-reservation scheme. Whenever a program subscribes a contract with the platform, resources are actually reserved for this program from the platform's viewpoint.

The remainder of this paper is organised as follows. Related work is presented in Section 2, which also discusses some of the limitations we observed in other securityoriented projects and middleware platforms. Section 3 presents the general architecture of the JAMUS platform. Section 4 focuses on resource contracting. It shows how contracts can be defined by application programs, and subscribed with the platform. It also shows how the information contained in contracts is used by a resource broker, which implements a reservation scheme in order to satisfy the programs' requirements. Section 5 shows how JAMUS was implemented on top of RAJE (Resource-Aware Java Environment), an object-oriented framework we designed, and which provides many facilities for resource monitoring and control in Java. Section 7 concludes this paper, enumerating some of the topics we plan to address in the near future.

Lessons learned from related work

Security in the Java Runtime Environment (JRE) relies on the so-called "sandbox" model. With this model, any program runs in a restrained environment, whose boundaries somehow define the evolution space of this program. In the first versions of the standard JRE (as proposed by Sun Microsystems), two alternative configurations were defined. On the one hand, plain Java applications were considered as safe code, and were therefore granted full access to system resources (such as network sockets and files). On the other hand, Java applets (ie code downloaded from remote Internet sites) were considered as potentially malicious pieces of code, and were only granted access to a strictly limited subset of resources [START_REF] Gong | Java Security: Present and Near Future[END_REF]. With later releases of the Java platform (up to the current Java 2 platform), this simplistic security model was extended in order to implement the concept of protection domain [START_REF] Gong | Implementing Protection Domains in the Java Development Kit 1.2[END_REF][START_REF] Gong | Java Security: Present and Near Future[END_REF]. A protection domain is a runtime environment whose security policy can be specified as a set of permissions.

The security model implemented in the traditional JRE relies on stateless mechanisms. A major limitation of this approach is that access to a specific resource cannot be conditioned by whether the same resource was accessed previously, or by how much of this resource has already been consumed. As a consequence, quantitative restrictions (such as shares of CPU time, or I/O quotas) cannot be set on the resources accessed from protection domains. With this limitation, the security mechanisms implemented in the JRE cannot prevent an over-consumption of resources, such as that observed in denial of service attacks, or with many faulty program codes.

In our opinion, a safe deployment environment for programs of dubious origin should allow that access restrictions be specified in both qualitative and quantitative terms (ie access permissions and access quotas). Environments 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] and KaffeOS [START_REF] Back | Processes in KaffeOS: Isolation, Resource Management, and Sharing in Java[END_REF] extend the traditional JRE along this line. They implement mechanisms that make it possible to evaluate how much memory and CPU time is used by an active entity (a thread for JRes, a process for GVM and KaffeOS). With JRes, one can additionally count the number of bytes sent and received through the network.

Although JRes, GVM, and KaffeOS provide advanced facilities for resource consumption accounting, this accounting is only possible at a rather coarse grain. For example, network access accounting in JRes is performed on a per thread basis. Consequently, JRes cannot count the number of bytes exchanged with a given remote host, or with a specific remote port number. Yet, we consider that such fine-grain accounting would be an advantage when deploying untrusted programs, as it would permit the definition and the enforcement of very precise security policies.

Naccio [START_REF] Evans | Flexible Policy-Directed Code Safety[END_REF] and Ariel [START_REF] Pandey | Providing Fine-Grained Access Control for Java Programs[END_REF] are projects that permit such fine-grain resource access accounting. They both define a language for defining a security policy, together with mechanisms for enforcing this policy while an application program is running. Security policy enforcement is carried out statically, by rewriting the application program bytecode, as well as that of the standard Java API. An advantage of this approach is that the cost of the supervision of a program is kept at a minimum since 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.

In contrast, our work aims at providing each application program with a runtime environment that fits its needs perfectly. In other words, we wish to launch each program in a sandbox whose boundaries are defined based on information provided by the program itself. Moreover, it must be possible to modify the boundaries of this sandbox dynamically, thus altering the restrictions imposed on the program's behaviour. This condition is motivated by the observation that, in some circumstances, the exact needs of a program can hardly be defined statically (consider for example a program that is meant to read a file whose name will only be discovered at runtime). Another reason is that the needs of a program are often liable to change at runtime, especially if this program must run for a long time.

Overview of the JAMUS platform

The architecture of the JAMUS platform is shown in Figure 1. This figure shows many elements, which cannot all be described in details in this paper for the sake of brevity. Indeed, this paper most specifically focuses on those elements of the figure that directly pertain to contract negotiation and contract monitoring. These topics are discussed further in the remainder of this section, and details about their implementation are given in the next sections.

A contract-based approach of resource control

JAMUS implements a contractual approach of resource utilisation and control. Before getting launched on the platform, a candidate program must first subscribe a contract with the contract manager of the platform, thus informing this manager about the resources it plans to use at runtime. The contract manager is responsible for binding contracts with candidate programs, and for the registration of all running contracts. It itself relies on a resource broker, whose role is to keep track of the resources available on the platform at any time, to perform some admission control on behalf of the contract manager (eg examining submitted contracts and deciding if they can be accepted), and to reserve resources for admitted programs. The implementation of the contract manager and that of the resource broker are detailed in Section 4, which also gives examples of typical interactions between these elements at runtime. Since the exact needs of a program are liable to change at runtime, any program running on the platform can ask that its contract be re-negotiated as and when needed. Of course, in such a case the contract manager and resource broker are involved again, as they must decide if the modified contract can still be supported by the platform.

Security through contract monitoring

The contract a program subscribes with the platform effectively defines the boundaries of the sandbox in which this program should be launched and allowed to run. It also implicitly defines how this program should be expected to behave with respect to the resources offered by the platform. The information contained in a program's contract can thus be used at runtime to monitor this program, and to detect any violation of its contract.

Notice that contract monitoring would not be necessary if the programs deployed on the JAMUS platform could all be considered as trustworthy. If that was the case, then any program could reasonably be expected to behave exactly as promised, that is, to access only those resources it required explicitly when subscribing a contract with the platform. However, JAMUS is dedicated to accommodating application programs of dubious origin, such as programs downloaded from untrustable remote Internet sites. Consequently, any application program deployed on the platform must be considered as a potential threat throughout its execution. Once a program has been accepted by the contract manager of the platform, the behaviour of this program must be monitored, so that any violation of its contract can be detected and sanctioned.

Contract monitoring in JAMUS relies on facilities we implemented and assembled in RAJE (Resource-Aware Java Environment), an open and extensible Java-based framework for resource consumption monitoring and control. RAJE is discussed further in Section 5.

Resource contracting

Specification of resource access conditions

JAMUS implements an object model that makes it possible to reify a program's basic requirements or a platform's restrictions as so-called "resource utilisation profiles". In this model, an instance of class ResourceUtilisationProfile is meant to define specific access conditions to a particular resource -or collection of resources-in both qualitative and quantitative terms (eg access permissions and quotas). Basically, a ResourceUtil-isationProfile object simply aggregates three objects that implement the ResourcePattern, ResourcePermission, and ResourceQuota interfaces respectively. JAMUS provides specific implementations of these interfaces for each basic resource type (Socket, Data-gramSocket, File, Thread, CPU, etc.). Figure 2 shows how resource utilisation profiles can be defined in Java. By including a given type of ResourcePattern in a ResourceUtilisationProfile, one indicates that the access conditions defined in this profile are only relevant for those resources whose characteristics match the pattern. For example, the SocketPattern in profile P1 (see Figure 2) indicates that this profile defines conditions for accessing the specified Internet site through a socket-based connection. The SocketPermission and SocketQuota objects combined in profile P1 bring additional information: they indicate that once a connection has been established with the remote site, the amounts of bytes sent and received through this connection should remain below the limits specified. The other two profiles similarly specify conditions for accessing a given directory in the filesystem (P2), and for consuming memory (P3).

By defining profiles such as those shown in Figure 2, an application program can specify its own requirements regarding the resources it plans to use at runtime. For example, by inserting profiles P1, P2 and P3 in a contract, a program may simultaneously require access to a remote Internet site (with specific access permissions and quotas) and to a given part of the filesystem (again with specific access permissions and quotas), while requiring a certain amount of memory for its sole usage.

Besides serving as a way to describe application programs' requirements, resource utilisation profiles are also used in JAMUS to set limitations on the resources the platform must offer. At startup the resource broker of the platform is given a collection of resource utilisation profiles, that describe which resources should be made available to hosted programs, and in what conditions.

Since JAMUS must be able to negotiate contracts dynamically with Java application programs, we decided that contracts and resource utilisation profiles (which actually serve as contract clauses) should be considered as first-class objects in our model (as suggested in [START_REF] Beugnard | Making components contract-aware[END_REF]). This is the reason why JAMUS relies on an object model in which contracts and profiles can be defined and managed directly as Java objects. Yet, we also defined an XML dialect for specifying profiles in a more human-readable form, and for storing this kind of information in files. JAMUS implements routines for parsing an XML file, and for instantiating profiles contracts based on the information found in this file. The administrator of a JAMUS platform can thus configure and manage this platform, without ever writing any source code.

Contract definition

Any resource utilisation profile defined by a program can be considered as expressing either a real requirement of the program (meaning, the program actually requests guarantees about the accessibility of the resource considered in the profile), or as a simple indication that the program may attempt to access the resource considered at runtime (meaning, the program simply provides information about the boundaries of the sandbox in which it wishes to be launched).

Since the resource broker of the platform implements a reservation scheme, we decided to distinguish between a program's true requirements (those that call for both resource reservation and access monitoring), and simple indications of the program's planned behaviour (that call for monitoring only).

Contracts in JAMUS are thus defined as collections of resource utilisation profiles, but these profiles are assembled in two distinct sets. Profiles in the first set call explicitely for resource reservation, whereas profiles in the second set do not.

Figure 3 shows the definition of two alternative contracts, that each combine several profiles. The first contract in this figure combines profiles P1, P2 and P3, but only the first two profiles should be considered as real requirements (meaning, they call for resource reservation, whereas P3 does not). The second contract combines profiles P1, P4, and P5, but only P1 calls for resource reservation.

A candidate program can thus instantiate one or several alternative Contract objects, and submit these contracts to the platform. If one of the contracts is declared admissible by the resource broker, then this contract can be subscribed by the program. If several of the contracts are declared admissible by the resource broker, then the application program can additionally choose which of these contracts it wishes to subscribe.

Contract negotiation

Contract negotiation in JAMUS is performed as a two-step process. In the first step, several alternative contracts can be submitted to the platform by the same program. In the second step, one of the contracts the platform has approved (assuming there is at least one) must be selected by the program, and subscribed with the platform. Each contract is examined by the resource broker, whose role it is to decide whether a contract is acceptable or not, and to reserve resources when needed. Resource reservation is only achieved (if and where needed) by the resource broker when a contract is subscribed by a program. By reserving resources (or shares of a resource) a program obtains guarantees that its requirements will be satisfied at runtime.

Figure 4 shows a possible sequence of interactions between a program and the platform's contract manager. It also shows that the resource broker is consulted whenever the contract manager receives a contract submitted by the program. In this example the first contract submitted by the program is rejected by the platform. Such a negative reply might be justified by the detection of a conflict between one of the program's requirement and one (or several) of the platform's restrictions. Notice that whenever a contract is rejected by the resource broker, the candidate program is returned a detailed report that specifies which profiles in the contract could not be accepted by the platform. This kind of information is expected to be useful for candidate programs that are capable of choosing between several behavioural scenarios, or for programs that can adjust their demand about resources based on information returned by the platform.

In Figure 4 the second contract submitted to the platform is accepted by the resource broker. The candidate program can try to subscribe this contract. However, since the platform may be carrying out several negotiations concurrently with as many candidate programs, the status of available resources may change between the time a submitted contract is declared acceptable by the resource broker, and the time this contract is subscribed. Consequently, whenever a program subscribes a contract, the terms of this contract are examined again by the resource broker in order to check whether they are still valid. If so, then the resources required by the candidate program are reserved for this program, as explained in the next section.

The reason why contract submission and contract subscription have been differentiated in the JAMUS platform is that it makes it possible for a candidate program to request that the platform examine several possible contracts (corresponding to different alternative combinations of resource requirements), before the program eventually decides which of these contracts it actually wishes to subscribe with the platform. This approach is meant to foster the development of application programs that can adjust their behaviour (at launch time or dynamically), depending on the resources the platform can offer.

Contract Monitoring

Security through resource monitoring

As mentioned in Section 3, any program hosted by the JAMUS platform is considered as not being trustworthy. As a consequence, the platform must monitor all running contracts in order to detect and to sanction any violation of a contract. Since contracts all pertain to the utilisation of resources, monitoring contracts actually comes down to monitoring the way resources are accessed and used by hosted programs.

JAMUS is dedicated to hosting Java programs, which run in a virtual machine. In this context, resource monitoring implies that all resources are reified as objects in the JVM. To achieve this goal, JAMUS relies on the facilities offered by RAJE, an open and extensible framework we designed in order to support the reification and the control of any kind of resource using objects in Java (see Figure 1). RAJE can be perceived as an extension of the traditional runtime environment of the Java 2 platform. It relies on a modified version of the standard JVM Kaffe (version 1.0.7), which allows the accounting of memory consumption and CPU time consumed by each Java thread. Some classes of the standard Java API (such as Socket, Data-gramSocket, File, and Thread) were augmented so that any access to the resources they model can be monitored at runtime. New classes were defined in order to model system resources, such as the CPU, system memory, and system swap. Part of the code implemented in RAJE thus consists of native code that permits the extraction of information from the underlying OS, and the interaction with inner parts of the JVM.

More details about the facilities implemented in RAJE (including implementation details) can be found in [START_REF] Guidec | Towards Resource Consumption Accounting and Control in Java: a Practical Experience[END_REF].

By implementing JAMUS on top of RAJE, resource monitoring and control can be performed in JAMUS at a very fine grain. For example any socket or file opened by a Java program can be considered as a specific resource, and any access to such a resource can be accounted for, and restrained if needed. Any Java thread can likewise be considered as a specific resource, and the amounts of CPU time or memory space consumed by each Java thread can be monitored as well. RAJE also makes it possible to set locks on resources, thus preventing any further utilisation of these resources by application programs.

Component monitors and resource monitors

Every application program hosted by the JAMUS platform runs under the control of a dedicated component monitor. This monitor uses the resource utilisation profiles contained in the contract subscribed by the program in order to instantiate many resource monitors. Their mission is to monitor the utilisation of the resource -or collection of resources-considered in this profile, and to ensure that this utilisation conforms to the access permissions and quotas defined in the profile.

JAMUS provides a specific implementation of a resource monitor for each basic resource type considered to date in RAJE. Each resource monitor admits a resource utilisation profile as a creation parameter. The role of a resource monitor is to supervise the utilisation of the resource -or collection of resources-considered in this profile, and to ensure that this utilisation conforms to the access permissions and quotas defined in the profile.

The figure 5 shows how the resource monitors, the component monitors, the contract manager and the resource broker interact.

When a resource monitor detects a contract violation, it reports to the component monitor, which in turn applies the sanction defined in the platform's configuration. In the current implementation of the platform, several kinds of sanctions are actually applicable to faulty programs. These sanctions range from a simple warning addressed to a faulty program (using an event based model), up to the immediate termination of this program.

Container Application program

ResourceBroker ContractManager

Performance results

When designing a deployment platform such as JAMUS, one can legitimately worry about the overhead imposed by dynamic sandboxing and contract monitoring.

In order to evaluate how these mechanisms can impact on the performances of the application programs launched on the platform, we recently initiated an evaluation process. This process consists in running a series of demanding programs (that is, programs that use resources extensively), while measuring their performances in different conditions.

For example we launched an FTP server (written in pure Java code) in JAMUS, and we measured the network throughput observed while downloading large files from this server. This experiment was conducted using two workstations (2.4 GHz Pentium 4 processor, 512 MB RAM) connected by a Fast Ethernet link (100 Mbps, Full Duplex). The throughput observed during file transfers was measured when running the FTP server with two standard JVMs (IBM's and Kaffe), and with JAMUS (which relies on a modified version of Kaffe). Moreover, in the latter case the FTP server was launched with a varying number of requirements, so that at runtime its behaviour was observed by a varying number of resource monitors (typically one monitor for filesystem access, and one or several monitors for network access). The throughputs we observed are reported in Table 1. In this table the throughput observed with the standard JVM Kaffe is used as a reference value.

We consider that these results are quite satisfactory. Obviously the monitoring infrastructure implemented in JAMUS significantly alters the performances of the application programs launched in this platform. Yet, in our opinion the degradation of performances observed while running the FTP server (which is a quite demanding program as far as filesystem and network resources are concerned) remain acceptable.

Besides, it is worth mentioning that the source code pertaining to resource consumption accounting in RAJE, and to contract monitoring in JAMUS, was primarily developed so as to be readable and flexible. Parts of this code could probably be written differently, though, in order to reduce the overhead imposed on the programs launched on the JAMUS platform.

Conclusion

In this paper we have presented the architecture and the implementation of the JAMUS platform, which is dedicated to hosting untrusted Java application programs, provided that these programs can specify their own needs regarding the resources they plan to use at runtime. JAMUS actually constitutes a demonstrator platform, with which we experiment with the idea of "resource-aware" programs and deployment platforms, that is, programs that can identify and specify their own needs regarding resource utilisation, and platforms that can use this kind of information in order to provide such programs with differentiated services. Although JAMUS is specifically dedicated to hosting nontrustable application programs, it is our conviction that many other application domains and systems (such as agent-based systems, or adaptive systems) could benefit ofor take inspiration from-the models and mechanisms we develop in this particular context.

Figure 1 .

 1 Figure 1. Architecture of the JAMUS platform.

int

  MB = 1024*1024; ResourceUtilisationProfile P1, P2, P3,; P1 = new ResourceUtilisationProfile( new SocketPattern("http://www.music.com"), new SocketPermission(SocketPermission.ALL), new SocketQuota(15*MB, 1*MB)); P2 = new ResourceUtilisationProfile( new FilePattern("/opt/music"), new FilePermission(FilePermission.WRITE_ONLY), new FileQuota(0, 40*MB)); P3 = new ResourceUtilisationProfile new MemoryPattern(), new MemoryPermission(MemoryPermission.ALL), new MemoryQuota(2*MB));

Figure 2 .

 2 Figure 2. Definition of resource utilisation profiles.

  Contract contract1 = new Contract ({P1, P2}, {P3}); Contract contract2 = new Contract ({P1}, {P2, P3});

Figure 3 .

 3 Figure 3. Definition of two possible contracts that each combine several resource utilisation profiles.

Figure 4 .

 4 Figure 4. Sequence of interactions between a candidate program and the platform's contract manager and resource broker.

Figure 5 .

 5 Figure 5. Monitoring of applications

Table 1 .

 1 Performances observed with an FTP server running either in a standard JVM or in JAMUS (with a varying number of monitors).

	JVM	Throughput (Mbps)
	Kaffe (version 1.0.7)	89.5 (100 %)
	IBM JVM (version 1.4.1) 89.3 (99.8 %)
	JAMUS (no monitor)	88.9 (99.3 %)
	JAMUS (2 monitors)	86.3 (96.4 %)
	JAMUS (3 monitors)	84.6 (94.5 %)
	JAMUS (5 monitors)	81.9 (91.5 %)


Frédéric Guidec

Yves Mahéo

Luc Courtrai Valoria

A Java Middleware Platform for Resource-Aware Distributed Applications

Keywords: Java, resource awareness, support for adaptation, distributed environments and applications

This paper reports the development of D-RAJE (Distributed Resource-Aware Java Environment), a Java-based middleware platform that makes it possible to model and to monitor resources in a distributed environment. With this middleware, any kind of hardware or software resource can be modelled using standard Java objects, and services allow to discover local as well as remote resources, and to observe the state of these resources either locally or remotely. D-RAJE is meant to ease the development of adaptive, security-oriented, or QoS-oriented Java applications, as well as the development of platforms capable of supporting such demanding applications.

Introduction

Nowadays distributed applications must face an evergrowing diversity of runtime conditions. For many such applications, the hardware devices on which application components are liable to be deployed cover a wide spectrum, ranging from embedded or portable devices with limited capabilities, up to full-featured, powerful workstations.

It is our conviction that the development of platforms capable of supporting adaptive programs should significantly contribute to alleviate the burden of application programmers, when they strive to design portable, yet efficient distributed applications for heterogeneous distributed systems. The services offered by operating systems or at middlewarelevel on such a variety of devices are unfortunately quite disparate. In such conditions, ensuring the portability of a distributed application and supporting the interoperability of its many components become crucial objectives. Any application component should be able to allow for the nature and characteristics of the resources available on the plat-form it has been deployed on.

Java has proved to be an interesting approach for hiding heterogeneity in distributed systems. The JVM provides a standard runtime environment for Java applications. The characteristics of the underlying hardware platform and the operating system are either masked or perceived through standard programming interfaces. However, although it is clearly an advantage for developing portable code, the level of abstraction offered becomes a drawback when it comes to developing adaptive application, since such applications should be allowed to take benefit from information pertaining to the resources provided by the execution environment: the execution environment is hidden so well that collecting information on this environment becomes quite difficult. Indeed, operating systems usually provide tools for collecting information about the resources they manage. Unfortunately, all types of resources are not managed the same way. The picture is even less favorable when considering a distributed system, where all nodes do not necessarily run the same operating system. There is thus a need for mechanisms that permit an homogeneous access, at the Java level, to resource information across a distributed platform.

The perception of the execution environment forms the basis of adaptation decisions. This perception is usually achieved at a coarse grain: for example, load balancing relies on the CPU load on each node, or persistence functions are conditioned by free disk space. We believe that fine grain perception could also be useful: a multi-threaded application could for instance take benefit from information on the memory consumption of a specific thread instead of allowing only for the system free memory amount. Similarly, knowing the number of bytes sent on each individual socket could give a better insight on network utilization than the overall amount of data sent through a network interface. We believe that both kind of information should be obtained through a unique framework.

This paper presents an overview of D-RAJE (Distributed Resource-Aware Java Environment), an open, object-oriented middleware platform with which a dis-tributed system can be modelled and monitored using Java objects that reify the various resources offered in this system. Our main objective is to develop some middleware that makes it possible for higher-level pieces of software (eg application programs) to perceive their runtime environment, so that they can adapt their behaviour to the characteristics of this environment, and to possible dynamic variations in these characteristics. 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 platform include system resources (CPU, system memory, swap, network interfaces, etc.) that chiefly characterize the underlying hardware platform, as well as other resources (sockets, processes, threads, directories, files, RMI servers, etc.) that rather pertain to the applicative environment considered. Besides allowing that resources be modelled and handled as Java object, D-RAJE implemements mechanisms that make it possible for applications to discover the existence of a specific resource (or kind of resource) in their environment; to search for a specific resource (or kind of resource) in their environment; to ask for the condition (ie state) of a specific resource or to be notified when changes occur in the state of a resource.

Since D-RAJE is dedicated to resource modelling and monitoring in a distributed system, the dissemination of resources in this kind of environment must be allowed for. The above-mentioned mechanisms are thus implemented in such a way that all resources can be identified and monitored in a homogeneous way, regardless of where they are located.

The remaining of this paper is organized as follows. Related work is discussed in Section 2. Section 3 explains how resources are modelled in D-RAJE. Mechanisms offered for the distributed management of resources are described in Section 4. Section 5 details some implementation choices. Lastly, Section 6 summarizes the paper and mentions cases of D-RAJE utilization.

Related work

Resource modelling and monitoring has justified much effort in the past few years. Considering only fine-grain resources on a per host basis, some of the services D-RAJE offers for modelling and monitoring resources compare with those offered by JRes [START_REF] Czajkowski | JRes: a Resource Accounting Interface for Java[END_REF], GVM [2], and Kaf-feOS [START_REF] Back | Processes in KaffeOS: Isolation, Resource Management, and Sharing in Java[END_REF]. These works are mostly devoted to providing a secure environment for application programs based on variations -or extensions-of the traditional sandbox security model (as implemented for example in the standard Java Runtime Environment). However monitoring is limited to a pre-defined set of general resource categories (such as the network and the filesystem). Our approach differs in that D-RAJE primarily defines a framework for resource modelling and monitoring, and provides a number of generic tools and facilities in order to ease the integration and the support of resources of any kind.

As far as the distribution of resources is concerned, several works have been -or are being-carried out in the context of network computing or grid computing. D-RAJE generally does not share the same overall objective and differs in the granularity of the resources handled. In the industrial area, the Data Management Task Force proposes a Common Information Model [START_REF][END_REF], a set of object oriented models that form the basis of several products for managing systems and networks across multiple organizations. In the context of grid computing, many projects propose tools for modelling and monitoring the resources scattered in a large scale distributed environment [START_REF] Krauter | A Taxonomy and Survey of Grid Resource Management Systems for Distributed Computing[END_REF]. They often rely on distributed directory services (eg. Globus [START_REF] Czajkowski | Grid information services for distributed re-source sharing[END_REF], Condor [START_REF] Raman | Matchmaking: Distributed Resource Management for High Throughput Computing[END_REF]) or follow an object-oriented approach (eg. Legion [START_REF] Chapin | The Legion Resource Management System[END_REF], Javalin [START_REF] Neary | Javalin 2.0: Java-based Parallel Computing on the Internet[END_REF]) to store and retrieve resource information. The resources considered in these environments are mainly coarse-grain resources, such as computing nodes or storage units. The objective is to be able to collect information about disseminated resources in order to manage the allocation of some of these resources for the execution of a given set of computational-intensive jobs. The distributed operating system 2K [START_REF] Kon | 2K: A Distributed Operating System for Dynamic Heterogeneous Environments[END_REF] aims at providing an adaptable architecture for developing and deploying distributed services across heterogeneous platforms. Resource management in 2K relies on Corba and resource allocation based on the needs of application components is considered as a part of the resource management process. The scope of D-RAJE is somehow more restricted, as its purpose is to serve only for distributed resource modelling and monitoring. Services specifically dedicated to resource allocation, resource reservation or QoS provision can be built on top of D-RAJE, but their definition and their implementation remain outside the scope of this project [START_REF] Sommer | A Contract-Based Approach of Resource-Constrained Software Deployment[END_REF].

Our work with D-RAJE is thus focused on providing an easy-to-use, extensible Java framework for resource modelling and monitoring in a distributed environment. Its main purpose is to support distributed Java applications that can adapt themselves to -possibly fine-grain-resource information.

Resource modelling

The architecture of D-RAJE is organised around a class hierarchy in which a Java class is defined for each resource type. Figure 1 shows some of the classes we have defined so far. The classes shown in this figure either reify typical system or hardware resources (CPU, memory, etc.), as well as other resources that are not necessarily identifiable as hardware or system parts (such as an RMI registry, or an RMI server). By modelling all kinds of resources in D-RAJE, our prime objective is to provide Java programs with means to perceive their runtime environment. We also permit that programs identify, locate, and monitor these resources using the generic facilities implemented in D-RAJE.

The class hierarchy used for modelling resources in D-RAJE was designed so as to be easily extensible. As a consequence, any new kind of resource can be included in the hierarchy at any time and with minimal effort. D-RAJE should actually be perceived as a design framework, rather than on a pre-defined toolkit or Java package. Similarly, the classes we have developed so far should simply be considered as examples, as they are meant to demonstrate how resources can be reified and then handled as Java objects in D-RAJE.

As shown if Figure 1, a class meant to reify a resource type in D-RAJE must implement the Resource interface. This interface serves as the root of the hierarchy of resource classes, but it also specifies that any resource object should have a unique identifier, and that it should be capable of producing an observation report on demand. Resource identification and observation reporting are important topics in D-RAJE. They are discussed in details in sections 3.2 and 4.1.

Reification of resources

Detailed information about low-level resources is usually not available to programmers of Java applications. One of our objectives in this project is to bring forth such information through the boundaries of the JVM, so that Java programmers can take benefit from this kind of information.

Each of the classes reifying system resources in D-RAJE defines methods for consulting the state of the actual resource it models. For example, by calling appropriate methods on an instance of class Memory one can consult the amounts of free and used physical memory in the system. The abstract class NetworkInterface similarly defines a set of methods for consulting the state of any kind of network interface, and descendants of this class provide additional methods for consulting attributes that only make sense for specific kinds of interfaces (such as the number of collisions registered by an Ethernet interface, or the radio channel currently used by a wireless interface).

The notion of "resource" can actually be extended far beyond that of basic hardware or system parts. Many software elements can also be considered as resources. Indeed, as soon as a piece of software provides a specific service that can be used by other elements (such as entire application programs, or other pieces of software), then it too can be considered as a "resource". For example, an RMI server is a resource for potential RMI clients. Similarly, when considering a deployment platform where transmissions through a network can somehow be restricted (based for example on the range of accessible remote IP addresses and ports), each transmission socket can in turn be perceived as a resource. We sometimes use the terms "conceptual resource" or "applicative resource" to denote those resources that cannot be directly or systematically identified as hardware or system parts, but that definitely provide a service that may be of interest to application programs.

Observation reports

Any object that implements the Resource interface defines specific methods that allow the consultation of the current state of the resource it models. However each resource type defines a very specific set of methods. This approach makes it difficult to monitor heterogeneous sets of resources using a single, generic scheme. Observation reports were defined in D-RAJE so as to circumvent this constraint. An observation report is meant to capture and to preserve information about the state reached by a given resource at a given time. A hierarchy of Java classes was developed (see Figure 2) so as to define different kinds of observation reports, and facilities implemented in D-RAJE allow the generation, the collection, and the management of such reports.

A specific kind of report must be defined for each resource type. As a consequence the hierarchy of observation report classes somehow mirrors that of resource classes, and most of the methods defined in resource classes in order to consult the state of the resources they model have a counterpart in the corresponding observation report classes. The method observe() declared in interface Resource (see Figure 1) provides a generic access point for requesting observation reports from resources of any kind. Any resource class defined in D-RAJE must implement this method. This approach makes it possible for application programs to request reports about resources using a generic scheme (by calling method observe()), regardless of the actual type of the resources considered, and regardless of the type of the reports thus obtained.

Sporadic system resources

Any kind of resource can be modelled as a Java object in D-RAJE. To achieve this goal the first condition is that a Java class be defined for this kind of resource. The second condition is that one or several instances of this class be created at runtime in order to model the resources that actually exist in the system.

Fulfilling the second condition may in some cases be quite difficult for system resources. Consider an application programmer who wishes to monitor the state of each network interface in the system. If this system is a workstation with a permanent connection to a LAN infrastructure, then there is probably no ambiguity as to which network interface must be modelled as a Java object. The programmer simply needs to know the name of the device associated with this interface at system level (such as "eth0", see line 1 in the example below), and create a resource object accordingly (all NetworkInterface classes take the name of a network device as a construction parameter). Now, if the system is actually a mobile laptop, then this system may show a highly dynamic behavior as far as network connectivity is concerned. In such a case where system resources can appear and disappear dynamically, there is a need for tools that can help the programmer discover system resources and keep informed about the creation and deletion of sporadic system resources. A few such tools have already been implemented in D-RAJE for specific resource types. For example a monitor was implemented, whose role is to poll the system periodically in order to keep informed about network interfaces. This monitor maintains a population of NetworkInterface objects, and whenever a network interface appears or disappears in the system the monitor updates this population accordingly. Line 2 and 3 in the example below illustrates the use of this kind of monitor. As a general rule, similar monitors can be designed to monitor any kind of resource whose persistence in the system is not guaranteed (eg PCMCIA or USB devices). In the future we plan to design specific tools for interacting with plug-and-play mechanisms, such as the Linux HotPlug package.

Dealing with distributed resources

D-RAJE handles every Resource object created on any host of the distributed platform. This handling is performed by the main component of D-RAJE called the "resource manager". This component is spread over the distributed system and is accessible to the user through an instance of the ResourceManager class. The resource manager provides several services across the distributed platform: it registers every creation or destruction of a resource object, identifies and locates every resource object and offers some facilities for obtaining information about resources.

The current implementation of the resource manager is fully distributed. Each of the ResourceManager objects that contribute to the resource manager function maintains a registry of the resources created locally and cooperates with its counterparts using RMI.

Resource identification and registration

Resource objects can be created "manually" in an application program, or a pool of resource objects can be handled automatically or semi-automatically thanks to resource discovery facilities such as those described in Section 3.3. The mechanisms we designed can help identifying and tracking resources at runtime. They rely on a naming system that gives any resource a unique identity. Whenever a resource object is created, the constructor requests a unique identifier (object of type ResourceId, see Figure 1) from a ResourceI-dGenerator. It then registers with the resource manager. D-RAJE mostly proposes a framework for dealing with resource objects at runtime. Various implementations can fit in this framework, so that quite complex resource identification and registration systems (such as hierarchical ones) could very well be deployed. As a first step, the current implementation provides a flat naming scheme.

When a resource becomes of no interest for an application, it is likely that the application eventually maintains no reference to the resource object. As it desirable that this kind of object be garbage collected, the resource manager only uses weak references to resources objects so garbage collecting is possible.

Resource tracking

The number of resources in a distributed system may be quite high. We defined a collection of patterns that make it possible to look for resources, or to collect observation reports from resources, selectively. The interface Search-Pattern serves as the root of a hierarchy of classes that each describes a specific search strategy (Figure 3). Search patterns are meant to help focus on the resources located on a fraction of a distributed system.

The following segment of code shows how a resource manager can be requested to look for resources using different search patterns. In this example several patterns are used in order to specify that the search should apply (line 1) to local resources only; (line 2) to the resources located on a remote node whose identity is specified as an argument; (line 3) to all resources, wherever they are. In this example, the method getResourceIds() is invoked on the resource manager. This method returns a set of identifiers of all known resources. One can then require that the resource manager collect and return an observation report concerning one of these resources (line 4, assuming that the value of resId was extracted from one of the three id sets).

Resource classification and selection.

The resources registered within a resource manager can be of various types (eg CPU, Memory, Swap, etc.). D-RAJE 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 the most simple scenario resource selection can simply be based on the actual type of the resource object which is submitted to the test. More sophisticated selection mechanisms can also be implemented using the resource pattern mechanism. For example the class Network-InterfacePattern permits the selection of network interfaces based on various criteria. Of course this pattern will only select NetworkInterface objects, but it can also be used more selectively so as to match, for example, only those network interfaces that are multicast capable, or those that currently run in promiscuous mode.

The following example shows the creation of two resource patterns. The first pattern permits the selection of any EthernetInterface object. In this example the constructor of the pattern is called with no parameter, which means that any EthernetInterface object should be selected by this pattern. The second 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 or a SearchPattern object (or both) as a parameter. One can thus request that the resource manager identify a specific set of resources, or collect observation reports from these resources according to a specific location specification.

Event notification

In addition to direct observation that shows in the form of requests for observation reports sent to resources, D-RAJE allows observation to be delegated to parameterizable monitors. Indeed, The implementation of a simple -yet flexible -event model makes it possible to ask monitor objects to periodically observe some resources so as to be notified when specific events occur regarding the state of these resources.

The description of a set of interesting events is modelled by an ObservationProfile object which comprises a set of resource ids and an object implementing the Observation-ReportPattern interface. Observation report patterns are to observation reports what resource patterns are to resources. Interface ObservationReportPattern is the root of a hierarchy of classes that serve as event filters. Each of these classes provides a boolean method isMatchedBy that implements a predicate on an obervation report passed as a parameter. A the top level of the hierarchy we have report patterns that are used to filter events according to resource types (for example method IsMatchedby of class SocketPattern only verifies that its parameter is of type SocketReport). Under this level, we have defined more precise patterns that covers usual events. For example, the class LowFreeMem-oryPattern makes it possible to detect that the free memory attribute value of a memory report is under a given threshold. The hierarchy can be easily extended by defining specific patterns for other events as long as they each pertain to one resource.

Event publishing is performed by an object implement-ing the ResourceMonitor interface that handles a set of observation profiles. It is in charge of observing, at a given period, the resources cited in all its observation profiles and notifying the corresponding event sinks (an object implementing interface Notifiable is stored in each observation profile). Two classes currently implement the Resource-Monitor interface, offerring distinct monitoring schemes. In the first one, a resource monitor creates only one periodic observer (mainly a thread) that fetches possibly distant observation reports. Notification is thus performed locally. In the second scheme, periodic observers are dispatched close to resources and event notifications are transferred through the network. Event subscription is done by instanciating a monitor and passing it a set of observation profiles. Moreover, after a monitor has been created, its behaviour can be dynamically modified by changing its observation period or by adding/removing observation profiles. Event notification is achieved by calling the notify method on the event sink object. The call holds a reference to an ObservationEvent object that contains a local timestamp as well as the information necessary to identify the origin of the event (a resource id) and the corresponding subscription (a reference to a resource monitor and an observation profile).

The following piece of code illustrates how a simple subscription is performed. In this case the user is interested in being notified whenever the free memory level of any node in the network goes either below 5 Mo or beyond 100 Mo. First the ids of all the memory objects are gathered (line 1); then two observation profiles are built, corresponding to the two kind of desired events (lines 2 and 3); and lastly the observation profiles are passed to a dispatched monitor constructor (line 4). The state of the memories will be observed locally with a period of 1000 ms. Notice that the object performing these calls is specified as the event sink for all the events generated (parameter this in lines 2 and 3).

Implementation details

Obtaining in Java some information about hardware or system parts implies that the objects reifying these resources in D-RAJE interact with the underlying operating system in order to collect the pieces of information requested by the calling program. The implementation of the classes modelling system resources in D-RAJE relies on native C code, whose role is to get information from the OS. So far D-RAJE was only implemented over Linux; though, the architecture of D-RAJE was carefully designed so that it can be ported at low cost on a variety of operating systems.

The approach we have chosen for implementing conceptual resources is to change the definition and implementation of standard JDK classes when necessary. Only minor modifications were required in the source code of classes like Socket, DatagramSocket, and File. The problem was more complex for the class Thread, though, since our objective was to permit that the CPU time and the memory space consumed by each Java thread be observable at runtime. To achieve this goal the actual implementation of Java threads in the JVM (Kaffe 1.07) had to be altered significantly and the memory allocator had too be also modified. It is worth mentioning that the signatures of the methods defined originally in the JDK were left untouched, and the semantics of these methods was preserved as well.

Although performance was not our prior concern in the initial implementation, a set of preliminary measurements have been conducted, mainly to obtain the order of magnitude of observation timings, especially as far as distant access to resource information is concerned. A few partial results are presented in the following table. In this experiment, a client asks a server for an observation report concerning four different resources: the CPU, the physical memory, an Ethernet interface and a user-defined dummy resource that produces empty observation reports. The client and the server run on 2.5 GHz Pentium 4 machines (with Linux 2.4) linked by an Ethernet network (100 Mb/s and 10 Mb/s). The last line of the table reports analogous resource observations using RAJE, the version of D-RAJE that restricts observation to the local host. The results show that although performances vary according to the type of resource, timings remain acceptable. Several ways of improvement are clearly possible, namely by replacing RMI by a more efficient transmission mode for cooperation between resource managers and by optimizing the management of the internal data structures of D-RAJE.

CPU

Conclusion

This paper has presented an overview of D-RAJE (Distributed Resource-Aware Java Environment), an open, object-oriented Java middleware architecture that makes it possible to model and to monitor resources in a distributed environment. The types of resources considered goes beyond classical system resources such as memory or CPU. With D-RAJE, the user may model resources that are not directly associated with hardware devices. For example, applicative entities like a socket, a file, a RMI registry or a user thread may also be considered as resources.

D-RAJE permits the identification of resources and the consultation of their state across a distributed system. The objective is to provide homogeneous access to resource information. A distributed resource manager offers services to search for resources based on possibly complex selection criteria, and to obtain observation reports from the resources thus selected. Mechanisms for notification of events concerning resources' states are also available. D-RAJE defines and implements an extensible framework that may be used to ease the development of adaptive, security-oriented, or QoS-oriented Java applications. It is not intended directly for end-users but could rather form a basis for higher level middleware. In this perspective, D-RAJE has been used in two projects that are being carried out in our laboratory. The first one is project Concerto which aims at allowing the deployment and the support of parallel adaptive software components on non-dedicated clusters of workstations [START_REF] Courtrai | Resource Management for Parallel Adaptive Components[END_REF]. Concerto uses the facilities offered by D-RAJE to permit the definition of dynamic adaptation strategies, based on the observation of resources of any kind. The extensibility of D-RAJE was exploited in project Concerto, as new types of resources were defined specifically for this project. JAMUS is another middleware architecture built on top of D-RAJE in order to experiment with the idea of resource contracting [START_REF] Sommer | A Contract-Based Approach of Resource-Constrained Software Deployment[END_REF]. JAMUS is a platform that supports the deployment of so-called "untrusted" software components, provided that these components can specify their requirements regarding resource utilisation in both qualitative and quantitative terms (eg acces permissions and access quotas). Emphasis is put on providing a safe and guaranteed runtime environment for such components. 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. Thanks to the resource observation services of D-RAJE, JAMUS can provide 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.

The D-RAJE platform is still under construction. In a near future, we plan to augment the set of resources modelled (laptop battery, USB devices,...) and to extend the event model so that compound events, pertaining to several resources at the same time, could be handled.

Aknowledment

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

Figure 1 .

 1 Figure 1. Object-based modelling of common system and non-system resources.

// ( 1 )

 1 Create a known resource Resource r = new EthernetInterface("eth0"); // (2) Create a monitor ResourceDiscovery rd = new EthernetDiscovery(); // (3) Get the set of current network interfaces Set s = rd.getResources();

Figure 2 .

 2 Figure 2. Observation reports modelling.

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).

ResourcePattern ethPattern = new EthernetInterfacePattern(); ResourcePattern socketPattern = new SocketPattern(InetAddress.AnyAddress, "195.83.160/24", PortRange.AnyPort, new PortRange(0, 1023));