Piero Baraldi
email: piero.baraldi@polimi.it

Francesco Di Maio

Francesca Mangili

Enrico Zio

A Belief Function Theory Method for Prognostics in Clogging Filters

This paper presents a similarity-based approach for the prediction of the Remaining Useful Life (RUL) of sea water filters placed upstream the heat exchangers of a nuclear reactor condenser. The prognostic approach is developed considering a library of reference degradation trajectories containing parameter observations taken from a set of similar equipments until their failures. The prediction of the RUL of the a filter is obtained by comparing its degradation trajectory to the reference trajectories and by properly aggregating the RULs of thetraining trajectories using a weighted sum which takes into account the similarity within test and training trajectories. In order to provide a measure of confidence in the RUL prediction in the form of a prediction interval, we place our work within the framework of belief function theory and we assign to each reference trajectory a belief proportional to its similarity to the test trajectory.

A prediction interval is then obtained by properly combining these belief assignments using the Dempster's rule.

Introduction

We consider the problem of predicting the Remaining Useful Life (RUL) of filters subjected to clogging, having available few sequences of clogging-related observation collected on similar filters. The real industrial data used in this study are taken from the filters used in the Boiling Water Reactor (BWR) of a Swedish nuclear power plant to clean the sea water pumped through the condenser.

Several data-driven methods have been proposed for predicting the RUL of degrading equipment [START_REF] Vachtsevanos | Intelligent Fault Diagnosis and Prognosis for Engineering Systems[END_REF][START_REF] Sikorska | Prognostic modeling options for remaining useful life estimation by industry[END_REF], i.e., the time left before the equipment will stop fulfilling its functions. Data-driven methods rely on the availability of observations collected during the degradation of one or more similar equipments. Due to the scarcity of information typically available and the different sources of uncertainty to which the RUL estimate is subject, data-driven models can commit large errors in the RUL estimate and uncertainty management becomes a fundamental task in prognostics [START_REF] Baraldi | Investigation of uncertainty treatment capability of model-based and data-driven prognostic methods using simulated data[END_REF]: its goal is to provide the maintenance planner with an assessment of the expected mismatch between the real and predicted equipment failure times which allowsto confidently plan maintenance actions according to the maximum acceptable failure probability.

In this context, the objective of the present work is to properly represent the uncertainty on the filter RUL predictionprovided by a data-driven prognostic model. In practice, the maintenance planner defines the maximum acceptable failure probability, and is informed by the prognostic method of the time at which this probability is exceeded.To this purpose, we consider the similarity-based prognostic model proposed in [START_REF] Zio | A data-driven fuzzy approach for predicting the remaining useful life in dynamic failure scenarios of a nuclear system[END_REF] which uses a set of reference degradation trajectories collected in a reference library and performs a data-driven similarity analysis for predicting the RUL of a newly developing degradation trajectory (hereafter called test trajectory). The matching process is based on the evaluation of the distance between the reference and test trajectories. This prognostic model is here extended in order to provide a measure of confidence in the RUL prediction based on the belief function theory (BFT) (also called Dempster-Shafer or evidence theory) [START_REF] Smets | What is Dempster-Shafer model?[END_REF]. The BFT allows combining different pieces of (uncertain) evidence, based on the assignment of basic belief masses to subsets of the space of all possible events, which are, in this case, the possible values that the filter RUL can assume. In practice, the proposed method considers each reference trajectory as a piece of evidence regarding the value of the RUL of the test trajectory. These pieces of evidence are discounted based on their similarity to the test trajectory and pooled using the Dempster's rule of combination [START_REF] Petit-Renaud | Nonparametric regression analysis of uncertain and imprecise data using belief functions[END_REF]. The result is a basic belief assignment (BBA) that quantifies one's belief about the value of the RUL for the test trajectory given the reference trajectories. From the BBA, the total belief (i.e., the amount of evidence) supporting the hypothesis that the RUL will fall in any specific interval can be computed. The interval to which a sufficiently large total belief is assigned is retained as prediction interval for theRUL value.

In the remainderof this paper wepresent the problem of RUL prediction in clogging filters (Section 2), describe the methodology for the similarity-based RUL prediction and the belief function theory-based uncertainty treatment (Section 3), present the results of the numerical application (Section 4) and draw the appropriate conclusions (Section 5).

Clogging of BWR condenser filters

We consider the problem of optimizing the maintenance of heat exchanger filters used to clean the sea water entering the condenser of the BWR reactor of a Swedish nuclear power plant. During operations, filters undergo clogging and, once clogged, can cumulate particles, seaweed, and mussels from the cooling water in the heat exchanger. For this reason, prompt and effective cleaning of the filter is desirable; predictive maintenance can help achieving this result, keeping maintenance costs reasonably low.

The clogging process is affected by large uncertainties, due to the variable conditions of the sea water; in this context, the challenge is to provide reliable confidence intervals for the RUL prediction. We are interested in predicting the RUL ofa filter𝑞 at the present time 𝜏 𝐼 𝑞 , have available the observation sequences 𝐳 1:𝑛 𝑟 𝑟 , 𝑟 = 1: 7, for the remaining 𝑅 = 7reference trajectories, and the sequence of observations 𝐳 1:𝐼 𝑞 , from 𝜏 1 𝑞 to the present time𝜏 𝐼 𝑞 and for the test trajectory 𝑞.

Methodology

The idea underpinning the RUL estimation method is to evaluate the similarity between the testtrajectory and the 𝑅reference trajectories, and to use the RULs of these latter to estimate the RUL of the test equipment, taking into account the similarities between the trajectories [START_REF] Petit-Renaud | Nonparametric regression analysis of uncertain and imprecise data using belief functions[END_REF][START_REF] Zio | A data-driven fuzzy approach for predicting the remaining useful life in dynamic failure scenarios of a nuclear system[END_REF].

The approach requires defining a measure of similarity between trajectories. This is done by considering the pointwise difference between 𝑛-long sequences of observations. At the present time 𝜏 𝐼 𝑞 , the distance 𝑑 𝑖 𝑟 between the sequence of the 𝑛latest observations 𝐳 𝐼-𝑛+1:𝐼 𝑞 of the test trajectory, and all 𝑛-long segments 𝐳 𝑖-𝑛+1:𝑖 𝑟 , 𝑗 = 𝑛: 𝑛 𝑟 , of all reference trajectories 𝑟 = 1: 𝑅is computed as:

        n j r j n i q j n I r i d 1 2 z z (1)
Where 𝐱 -𝐲 𝟐 is the square Euclidean distance between vectors 𝐱and 𝐲.

           2 ) ( exp r i r i d s (2)
The arbitrary parameter 𝜆 can be set by the analyst to shape the desired interpretation of similarity: the smaller is the value of 𝜆, the stronger the definition of similarity. A strong definition of similarity implies that the two segments under comparison have to be very close in order to receive a similarity value 𝑠 𝑖 𝑟 significantly larger than zero.

r i r F r i l u r * * ˆ    (3)
Then, the prediction 𝑟𝑢𝑙 𝐼 𝑆𝐵,𝑞 of the test equipment RUL at time 𝜏 𝐼 𝑞 is given by the similarity weighted sum of

the values 𝑟𝑢 𝑙 𝑖 * 𝑟 .      R r r i R r r i r i q SB I s l u r s L U R 1 * 1 * * , ˆ (4)
The ideas behind the weighting of the predictions 𝑟𝑢 𝑙 𝑖 * 𝑟 supplied by the individual trajectories is that: i) all failure trajectories in the reference library can, in principle, bring useful information for determining the RUL of the trajectory currently developing; ii) those segments of the reference trajectories which are most similar to the latest part of the test trajectory should be more informative about the value of its RUL.

Credible RUL intervals based on belief function theory

Given the uncertainty to which the RUL estimate is subject, maintenance plans cannot usually be based only on the RUL prediction in eq. ( 4). In this Section, we assume that the maintenance planner is able to specify a maximum acceptable failure probability,𝛼, and we propose a method to identify the latest time at which, according to the available information, we can guarantee that the probability to have a failure is lower than 𝛼. To this aim, we resort to the Belief Function Theory. For the ease of clarity, only the notions of BFT necessary for the understanding of the proposed method will be now presented. For further details about the mathematical developments and the possible interpretations of the theory, the interested reader is referred to the woks of [START_REF] Dempster | Upper and lower probabilities induced by a multivariate mapping[END_REF], [START_REF] Shafer | A mathematical theory of evidence[END_REF] and [START_REF] Smets | What is Dempster-Shafer model?[END_REF].

The belief of an agent about the value of an uncertain variable, in this case 𝑟𝑢𝑙 𝐼 𝑞 , is represented by a basic belief assignment (BBA), which assigns to subsets 𝑌 𝑗 , of the domain of Ω 𝑟𝑢𝑙 𝐼 𝑞 (called frame of discernment in the BFT jargon) a mass𝑚 𝑟𝑢𝑙 𝐼 𝑞 (𝑌 𝑗 )based on the available information. The frame of discernment Ω 𝑟𝑢𝑙 𝐼 𝑞 is defined as the interval [0, 𝜏 𝐹 max -𝜏 𝐼 𝑞 ], where 𝜏 𝐹 max is the maximum possible life duration of the equipment.

All the subsets of Ω 𝑟𝑢𝑙 𝐼 𝑞 with associated a mass 𝑚 𝑟𝑢𝑙 𝐼 𝑞 > 0 are referred to as focal sets. The BBA should verify the condition that the sum of the masses of all its focal sets is 1.

In our application of the BFT, we assume that each reference trajectory

0 ) ( , , ) ( ) ( 1 ) ( 2 1 ' ' 2 ' 1 2 1 ' ' '              q I q I j j j q I q I q I rul j rul j Y Y Y j rul j rul j rul m Y Y Y m Y m K Y m (6)
where the mass 𝑚 𝑟𝑢𝑙 𝐼 𝑞 1 ⨁ 2 ∅ = 0 is imposed to convert a possibly subnormal BBA (i.e., a BBA assigning a finite mass to the empty set∅) into a normal one and where 𝐾 is a normalization factor introduced to make the masses 𝑚 𝑟𝑢𝑙 𝐼 𝑞 1 ⨁ 2 𝑌 𝑗 assigned to all focal elements sum up to 1. Then, by aggregating through eq. ( 5) the 𝑅 discounted BBAs 𝑚 𝑟𝑢𝑙 𝐼 𝑞 𝑟 in eq. ( 4) one obtains the aggregated BBA 𝑚 𝑟𝑢 𝑙 𝐼 𝑞 . The information conveyed by a BBA can be represented by a belief𝐵𝑒𝑙 𝑟𝑢 𝑙 𝐼 𝑞 𝑌 𝑗 or by a plausibility function 𝑃𝑙 𝑟𝑢 𝑙 𝐼 𝑞 𝑌 𝑗 defined, respectively, as

   j j q I q I Y Y j rul j rul Y m Y ' ) ( ) ( Bel ' ,      j j I q I Y Y j RUL j rul Y m Y ' ) ( ) ( Pl ' (7)
The belief associated to an interval [𝑟𝑢𝑙 𝐼 inf , 𝑟𝑢𝑙 𝐼 sup ] represents the amount of belief that directly supports the hypothesis 𝑟𝑢𝑙 𝐼 𝑞 ∈ [𝑟𝑢𝑙 𝐼 inf , 𝑟𝑢𝑙 𝐼 sup ], whereas the plausibility represent the maximum belief that could be committed to this hypothesis if further information became available. Then, belief and plausibility can be seen as lower and upper bounds on the probability that hypothesis 𝑟𝑢𝑙 𝐼 𝑞 ∈ [𝑟𝑢𝑙 𝐼 inf , 𝑟𝑢𝑙 𝐼 sup ] is true. Let us consider a left bounded interval [𝑟𝑢𝑙 𝐼 inf , +∞]; the belief assigned to such interval is a lower bound for the probability that the RUL of the test equipment is larger than 𝑟𝑢𝑙 𝐼 inf . Thus, if the maintenance planner defines the maximum acceptable failure probability 𝛼, the method can provide a value 𝑟𝑢𝑙 𝐼 inf (1 -𝛼)which guarantees that the test equipment will fail before𝑟𝑢𝑙 𝐼 inf (1 -𝛼) with a probability lower than𝛼. The interval

𝐶𝐼 𝐼 𝑞 (1 -𝛼) ∈ [𝑟𝑢𝑙 𝐼 inf (1 -𝛼)
, +∞] will be referred to as left bounded prediction interval with belief 1 -𝛼.

To set parameters𝜆and 𝛾 one should take into account the precision of the prediction, which can be evaluated as the meanamplitude 𝑀𝐴 1-𝛼 of the interval 𝑟𝑢𝑙 𝐼 inf 1 -𝛼 , 𝑟𝑢𝑙 𝐼 𝑆𝐵,𝑞 , its coverage 𝐶𝑜𝑣 1-𝛼 , defined as the percentage of times the condition 𝑟𝑢𝑙 𝐼 𝑞 > 𝑟𝑢𝑙 𝐼 inf (1 -𝛼) is verified, and its accuracy, measured by the Mean Square prediction Error (𝑀𝑆𝐸). In practice one is interested in two conflicting desiderata: small prediction intervals (𝑀𝐴 1-𝛼 ) and high coverage values (𝐶𝑜𝑣 1-𝛼 ). Notice that a coverage lower than (1 -𝛼)

is not acceptable since it would indicate that a too large belief mass has been assigned to the predictions provided by the reference trajectories, and, thus, that the belief (1 -𝛼) assigned to the prediction interval is not justified by the experimental evidence.

The following procedure for setting the parameters 𝜆 and 𝛾 is here adopted: 1) we identify a set of plausible values of𝜆; 2) for each value of 𝜆 in 1), we derive a condition for parameter 𝛾 by imposing a coverage𝐶𝑜𝑣 1-𝛼 greater than (1 -𝛼); 3) since the precisiontends to monotonically increase as 𝛾 increases, we choose, for each value of𝜆, the maximum 𝛾 value which satisfies the condition in 2; 4) within the identified couples of values of 𝜆 and 𝛾 in 3), we choose the couple with the most satisfactory prediction accuracy (low 𝑀𝑆𝐸) and precision (low 𝑀𝐴 1-𝛼 ) trade-off.

According to the procedure proposed in Section 3.1, we have set the method parameters 𝜆 and 𝛾to the values of 0.05 and 1, respectively. The prognostic method has then been applied to each available trajectory 𝑞at the three life fractions using the remaining 𝑅 = 7 trajectories as reference trajectories.Figure 1 shows the predicted RUL and RUL confidence boundwith 1 -𝛼 = 0.8.

From the point of view of the maintenance planner, the on-line application of the method to trajectory 4 would suggest to perform maintenance on the filters after few days of operation, since the 80% confidence bound reaches the value of zero at time𝜏 3 = 3 working days. This is due to the fact that the similarity of this trajectory with all reference trajectories is rather low, and thus the prediction is very uncertain. Notice that this filter is actually characterized by a very short life since it is going to fail at time 𝜏 12 = 12working days, and, thus, the anticipation of the maintenance action can be acceptable.

On the other side, the application of the method to trajectory 6 would inform the maintenance planner at time 15 working daysthat the filter life is still long since the 80% RUL confidence bound is 21 working days when actually the filter is going to fail in 10 working days. This incorrect outcome of the method can be ascribed to the fact that trajectory 8 receives a very high belief assignment 𝑚 𝑟𝑢 𝑙 𝐼 𝑞 𝑟𝑢 𝑙 𝑖 * 8 = 0.937 due to its high similarity with trajectory 6 around time 𝜏 15 = 15 although after few working days the parameter evolutions become very different.

Figure 1:predictions obtained for the 𝑄 = 8 filter clogging trajectories available using parameters𝜆 = 0.05and 𝛾 = 1.

Conclusions

In this work, we have considered the problem of predicting the RUL of clogging filters and providing a measure of confidence in the prediction. The information available to perform the prediction is a set of reference degradation trajectories followed by similar filters which have failed in the past. We resorted to a method based on the use of a similarity-based approach for the prediction of equipment RUL and of the belief function theory for the assessment of the RUL uncertainty. Considering the large uncertainties affecting the clogging process and the limited number of available reference degradation trajectories, the obtained results seem to be satisfactory in terms of accuracy, precision and coverage. Key elements to be considered for the application of the method are the setting of the parameter 𝜆used by the similarity algorithm to define how strong is the interpretation of similarity, and the parameter 𝛾 of the BFT discounting operation which defines the degree of trust to be given to the reference trajectories.

A limit of the method is the presence of possibly large oscillations in the provided confidence bound which can be confusing for the maintenance planner. We have shown that such oscillations can be reduced by conveniently setting the parameter values which, however, tends to reduce the precision of the prediction.

From

  data collected on field, we have available sequences of 𝑛 𝑞 observations 𝐳 1:𝑛 𝑞 𝑞 , 𝑞 = 1: 8, taken during the clogging process of 𝑄 = 8 historical filtersup to the last measurement time 𝜏 𝑛 𝑞 𝑞 before the failure time,𝜏 𝐹 𝑞 . Each observation𝐳 𝑖 𝑞 = [Δ𝑃 𝑖 𝑞 , 𝑀 𝑖 𝑞 , 𝑇 𝑖 𝑞 ]contains the measurements of the pressure dropΔ𝑃 𝑖 𝑞 , the flow across the filter𝑀 𝑖 𝑞 , and the sea water temperature𝑇 𝑖 𝑞 collected at time 𝜏 𝑖 𝑞 during the clogging process of the 𝑞-th filter.

  For the prediction of the test equipment RUL, a RUL value 𝑟𝑢 𝑙 𝑖 * 𝑟 is assigned to each training trajectory 𝑟 = 1: 𝑅by considering the difference between the trajectory failure time 𝜏 𝐹 𝑟 and the last time instant 𝜏 𝑖 * 𝑟 of the trajectory segment 𝐳 𝑖 * -𝑛+1:𝑖 * 𝑟 which has the maximum similarity with the test trajectory:

  𝐳 1:𝑛 𝑟 𝑟 , 𝑟 = 1: 7, corresponds to a different agent and that each agent provides a BBA assignment defined by only one focal set𝑌 1 = {𝑟𝑢 𝑙 𝑖 * 𝑟 },made of the single element 𝑟𝑢 𝑙 𝑖 * 𝑟 , with associated mass𝑚 𝑟𝑢𝑙 The similarity measure 𝑠 𝑖 * 𝑟 defined in eq. (9) is interpreted as a measure about the relevance of the source of information inducing the BBA𝑚 𝑟𝑢𝑙 𝐼 𝑞 𝑟 and the discounting operation is used to reduce the belief assigned by the 𝑟-th agent to {𝑟𝑢 𝑙 𝑖 * 𝑟 }by a factor (1 -𝛾𝑠 𝑖 * 𝑟 ), with 𝛾 ∈ [0,1] representing the dissimilarity between the test and the 𝑟-th training trajectory. The discounted BBAs 𝑚 𝑟𝑢𝑙 Dempster's rule of combination, two distinct sources of information inducing two BBAs, combined to give the aggregated BBA 𝑚 𝑟𝑢𝑙 𝐼 𝑞 1⨁2 (Petit-Renaud &Denoeux, 2004):

Acknowledgments

The work of Francesca Mangili has been supported by a PhD grant of the InstituttForEnergiteknikk (IFE),OECD Halden Reactor Project.


Mauro Caporuscio
email: mauro.caporuscio@polimi.it

Marco Funaro
email: funaro@elet.polimi.it

Carlo Ghezzi
email: carlo.ghezzi@polimi.it

Valérie Issarny
email: valerie.issarny@inria.fr

ubiREST: A RESTful Service-oriented Middleware for Ubiquitous Networking

come   L'archive ouverte pluridisciplinaire

Introduction

With network connectivity being embedded in most computing devices, any device may seamlessly consume, but also provide, software applications over the network. Service-Oriented Computing (SOC) is a natural design abstraction to deal with ubiquitous networking environments [START_REF] Bellur | Towards service orientation in pervasive computing systems[END_REF]. Applications may conveniently be abstracted as autonomous loosely-coupled services, which may be composed to accomplish complex tasks. A service composition forms into a network-based application, which relies on the explicit distribution of services interacting by means of message passing. Network-based applications differ from distributed applications because the involved networked resources are independent and autonomous, rather than viewed as integral part of a conceptually monolithic system [START_REF] Tanenbaum | Distributed operating systems[END_REF].

Issues related to the design/development of network-based systems have been largely discussed in literature, and several middleware solutions, providing different types of resource's abstraction (e.g., remote procedure, object, component, service), have been proposed to deal with them. However, such middleware solutions rely on the assumption that the underlying network is stable. Whereas, concerning ubiquitous networking, such assumption is no longer valid due to the intrinsic dynamism and resource mobility (both physical and logical) [START_REF] Roman | Software engineering for mobility: a roadmap[END_REF]. Indeed, ubiquitous applications emerge from the spontaneous aggregation of the resources available (within the environment) at a given time, and thus are characterized by a highly dynamic software architecture where both the resources that are part of the architecture and their interconnections may change dynamically, while applications are running. In these settings, two main problems must be faced: (i) achieving the ubiquitous networking environment on top of heterogeneous communication media, and (ii) providing a flexible architectural style, which allows for designing and developing applications resilient to such an extreme variability.

In ubiquitous networking environments applications run on devices (e.g., tablets and smartphones), which are usually interconnected through one or more heterogeneous wireless links, which are characterized by lower bandwidth, higher error rates, and frequent disconnections. Hence, key feature of ubiquitous networking environments is the diversity of radio links available on portable devices, which may be exploited towards ubiquitous connectivity. While computationally suitable for ubiquitous applications, such devices usually have serious issues with battery life when the computational burden grows. Thus, the middleware should be able to energetically optimize the communication through scheduling and handover across different radio links [START_REF] Qureshi | Horde: separating network striping policy from mechanism[END_REF][START_REF] Sorber | Turducken: hierarchical power management for mobile devices[END_REF]. This requires services to be network-agnostic [START_REF] Su | Haggle: seamless networking for mobile applications[END_REF], while the underlying middleware is in charge of exchanging messages over the network links that best matches Quality of Service (QoS) requirements [START_REF] Charlet | Energy-efficient middleware-layer multi-radio networking: an assessment in the area of service discovery[END_REF], and further ensuring service continuity through vertical handover (handover between different protocols) [START_REF] Huang | Improving TCP performance during soft vertical handoff[END_REF]. In this setting, a primary requirement for supporting service-oriented middleware is to provide a comprehensive networking abstraction that allows applications to be unaware of the actual underlying networks while exploiting their diversities in terms of both functional and extra-functional properties.

As for the architectural layer, applications should support adaptive and evolutionary situation-aware behaviors. Adaptation refers to the ability to react to environmental changes to keep satisfying the requirements, whereas evolution refers to the ability of satisfying new or different requirements [START_REF] Caporuscio | Architectural issues of adaptive pervasive systems[END_REF]. In order to be selfadaptable and easily evolvable, applications should exploit design models able to: (i) deal with the run-time growth of the application in terms of involved resources (flexibility), (ii) accommodate heterogeneous and unforeseen functionalities into the running application (genericity), and (iii) discover new functionalities at run time and rearrange the application accordingly (dynamism).

This chapter presents the ubiREST middleware, which enhances the ubiSOAP approach [START_REF] Caporuscio | ubiSOAP: A service-oriented middleware for ubiquitous networking[END_REF] by providing RESTful access to services. Specifically, ubiREST adopts the P-REST architectural style [START_REF] Caporuscio | RESTful service architectures for pervasive networking environments[END_REF], a refinement of the REST style [START_REF] Fielding | REST: Architectural styles and the design of network-based software architectures[END_REF] that we have introduced to fulfill the aforementioned requirements, namely flexibility, genericity, and dynamism.

The chapter is organized as follows: Section 2 summarizes related work. Section 3 discusses the design rationale for ubiREST, whereas Sections 4, 5, and 6 detail the core functionalities of ubiREST, namely network-agnostic connectivity, ubiREST communication, and ubiREST programming model, respectively. Session 7 presents an example showing how to develop a simple RESTfull ubiquitous application. Finally, Section 8 concludes the chapter, and sketches our perspectives for future work.

Related Work

Work related to ubiREST ranges different research areas from multi-radio networks integration to ubiquitous computing and service technologies.

ubiREST aims at providing a communication layer enabling RESTful services within ubiquitous networking environments. To effectively enable mobile RESTful services, ubiREST comprehensively exploits the ubiquitous networking environment by dealing with multi-radio networking on the mobile device. Concerning this issue, the Third Generation Partnership Project (3GPP) defines a standard layered architectures (decomposing into the network, control and service layers) enabling service-oriented applications in the B3G network [START_REF] Asprino | A layered architecture to manage complex multimedia services[END_REF]. In that direction, recent proposal that aims at interconnecting various networks at once, has been published by the ITU under the name of IMT-Advanced (also known as 4G) [START_REF](ITU): Global standard for International Mobile Telecommunications -IMT-Advanced[END_REF]. Main goal of IMT-Advanced is to achieve "Always Best Connected" property by embedding broadband in all types of consumer devices. Interactions among networks include horizontal (intra network) and vertical (inter network) handover for service continuity, and encompass complex functions such as billing and QoS. This de-facto eliminates the need for the user to know anything about the network (e.g., topology, radio). However, both systems require the network operator to deploy new entities within the network that allow the native infrastructures to work together. Contrary to this closed, network-controlled approach, ubiREST provides a set of abstractions enabling clients to autonomously adapt to the available networks, and to benefit from networks characteristics. This requires neither to modify the network infrastructure nor to establish contracts with a predetermined network operator.

Concerning ubiquitous computing at large, the literature proposes different middleware classes, each addressing a specific issue: (i) Context-aware middleware [START_REF] Ellebaek | A survey of context-aware middleware[END_REF] deal with leveraging context information to provide user-centric computation, (ii) Mobile computing middleware [START_REF] Mascolo | Middleware for mobile computing (a survey)[END_REF] aim at providing communication and coordination of distributed mobile-components, (iii) Adaptive middleware [START_REF] Mckinley | Composing adaptive software[END_REF] enable software to adapt its structure and behavior dynamically in response to changes in its execution environment. However, each middleware provides an ad hoc approach, whereas standards-compliant solutions are still missing.

Moreover, many middleware proposals aim at supporting the development of ubiquitous applications through the provision of different abstractions -e.g., objects, components, and services. The Obje framework [START_REF] Edwards | Experiences with recombinant computing: Exploring ad hoc interoperability in evolving digital networks[END_REF] is an object-oriented framework where networked devices appear to applications as objects that implement specific "meta-interfaces". Such "meta-interfaces" are further used by applications to exchange the behaviors needed to achieve compatibility at run time. The methods of such interfaces make use and return objects that themselves implement well-known interfaces. Hence, the loading of objects is made transparent to user applications, which simply see them as new implementations of already-known interfaces. The framework described in [START_REF] Hoareau | Middleware support for the deployment of ubiquitous software components[END_REF], addresses the distribution and deployment of components throughout the ubiquitous networking environment. It provides developers with an architecture description language to specify constrains on components, which can be considered at deploy time to find a distribution scheme satisfying all constraints. Service-Oriented Computing (SOC) provides natural design abstractions to deal with ubiquitous environments. Networked applications are abstracted as autonomous loosely-coupled services, which may be dynamically combined to accomplish complex tasks [START_REF] Bellur | Towards service orientation in pervasive computing systems[END_REF]. ReMMoC [START_REF] Grace | A reflective framework for discovery and interaction in heterogeneous mobile environments[END_REF] and ubiSOAP [START_REF] Caporuscio | ubiSOAP: A service-oriented middleware for ubiquitous networking[END_REF] provide middleware functionalities supporting service provision over ubiquitous networks.

In particular, focusing on Service-Oriented Computing, the widespread adoption of WS technologies combined with mobile networking has led to investigating the definition of architectures dedicated to mobile Web services [START_REF] Issarny | Developing ambient intelligence systems: A solution based on web services[END_REF][START_REF] Hirsch | Mobile Web Services: Architecture and Implementation[END_REF]. Overall, existing efforts towards enabling mobile Web services platforms address the development of service-oriented applications on mobile, wireless devices that act mostly as Web service clients. However, todays device technologies enable mobile devices to act as Web services providers. To this extent, many optimizations for SOAP have been proposed to improve memory and CPU usage [START_REF] Van Engelen | The gSOAP toolkit for web services and peer-to-peer computing networks[END_REF], as well as to improve the bandwidth requirement of SOAP communication [START_REF] Sakr | Xml compression techniques: A survey and comparison[END_REF][START_REF]XML Protocol Working Group: SOAP message transmission optimization mechanism[END_REF][START_REF] Wolff | Network-centric middleware for service oriented architectures across heterogeneous embedded systems[END_REF].

The idea of exploiting RESTful principles beyond the Wed is not new, and some research projects have been investigating how to apply the REST architectural style to different fields -e.g., ubiquitous computing and web of things. For example, [START_REF] Mancinelli | Leveraging the web platform for ambient computing: An experience[END_REF][START_REF] Kindberg | A web-based nomadic computing system[END_REF] leverage RESTfulness in the context of Ambient Computing, whereas [START_REF] Guinard | A resource oriented architecture for the Web of Things[END_REF][START_REF] Gupta | A network architecture for the web of things[END_REF] exploit REST principles to achieve the Internet of Things. However, these approaches rely on Web standards to achieve interoperation, and therefore they suffer from the Web's limitations, e.g., lack of mobility management, point-to-point communication, and client-server interaction style. To this end, the XWeb [START_REF] Olsen | Cross-modal interaction using xweb[END_REF] project presents a web-oriented architecture relying on a new transport protocol, called XTP, which provides mechanisms for finding, browsing, and modifying information.

Furthermore, in [START_REF] Bonetta | An architectural style for liquid web services[END_REF] RESTfulness has been exploited to achieve scalability, by means of replication of resources, in the context of Web Services. In particular, the REactor (RESTful Actor) framework provides a RESTful Web service interface and a composable architecture which is capable of delivering scalability and high performance independently from the underlying deployment infrastructure. Moreover, due to its scalability and the flexibility, REST architectural style has been employed also for monitoring and controlling data-and computationally-intensive tasks, such as in the context of Grid [START_REF] Lelli | Controlling and monitoring devices with REST[END_REF].

However, even thought REST has been gaining wide popularity as well suited solution for a large class of problems, to the best of our knowledge, ubiREST is the first attempt to design and develop a resource-oriented middleware, which specifically supports the development of ubiquitous RESTful services by addressing all the above aspects together.

3 ubiREST design rationale ubiREST has been conceived and designed to provide RESTful access to services over ubiquitous-networking environments. To this extent, ubiREST aims at effectively exploiting all the diverse network technologies at once to create an integrated multi-radio networking environment, hence offering network-agnostic connectivity to services. On the other hand, ubiREST aims to provide proper programming abstractions enabling service-oriented applications to adapt and evolve at run time.

Achieving the network-agnostic connectivity requires addressing a number of critical issues such as network availability, user and application QoS requirements and vertical handover. Vertical handover [START_REF] Wang | Policy-enabled handoffs across heterogeneous wireless networks[END_REF] is particularly important with respect to the service continuity requirement. Indeed, when a host changes its point of attachment (vertical handover between two networks), the IP address is modified accordingly in order to route packets to the new network. Hence, since the IP address is the base of any Internet transmission [START_REF]RFC675 -Specification of Internet Transmission Control Program[END_REF], all the ongoing connections break. Moreover, as devices can bind various networks at the same time, two interacting parties might communicate through multiple paths. Hence, choosing the best connection to serve a given interaction is a key issue to deal with in ubiquitous networks, as this significantly affects the QoS at large (e.g., availability, performance with respect to both resource consumption and response time, security) [START_REF] Caporuscio | Energetic performance of serviceoriented multi-radio networks: issues and perspectives[END_REF].

Pervasive applications are composed as composition of (heterogeneous) independent services, forming into a network-based application. Since mobility makes services available/unavailable suddenly, ubiquitous applications emerge de-facto from the spontaneous aggregation of the services available (within the environment) at a given time. As result, ubiquitous applications are characterized by a highly dynamic software architecture where both the services that are part of the architecture and their interconnections may change dynamically, while applications are running.

Issues related to the design/development of ubiquitous systems have been largely discussed in literature, and many middleware, providing different types of abstraction -e.g., objects [START_REF] Edwards | Experiences with recombinant computing: Exploring ad hoc interoperability in evolving digital networks[END_REF], components [START_REF] Hoareau | Middleware support for the deployment of ubiquitous software components[END_REF], and services [START_REF] Caporuscio | ubiSOAP: A service-oriented middleware for ubiquitous networking[END_REF] -have been proposed to deal with them. Departing from these approaches, ubiREST tackles the problem by adhering to REST principles [START_REF] Fielding | REST: Architectural styles and the design of network-based software architectures[END_REF]: addressability, statelessness, connectedness, and uniformity. However, due to the inherent complexity of ubiquitous environments, the REST architectural style cannot be directly applied to them. Hence, we enhanced it by creating the P-REST (Pervasive REST) architectural style, which refines REST to specifically address ubiquitous networking environments, while keeping REST principles unaltered. P-REST (see Figure 1) promotes the use of Resource as first-class object that plays the role of "prosumer" [START_REF] Papadimitriou | Future Internet -the Cross-ETP Vision Document[END_REF], i.e., fulfilling both roles of producer and consumer. To support coordination among resources, P-REST extends REST with a set of new facilities: (i) a Lookup service enabling the run-time discovery of new resources, (ii) a distributed Domain Name System (DNS) service mapping resource URIs to actual location in case of mobility, and (iii) a coordination model based on the Observer pattern [START_REF] Khare | Extending the representational state transfer (rest) architectural style for decentralized systems[END_REF] allowing a resource to express its interest in a given resource and to be notified whenever changes occur in it.

Following the P-REST style, resources interact with each other by exchanging their representations. Referring to Figure 1, both Resource 1 and Resource 2 observe Resource 3 (messages 1 ). When a change occurs in Resource 3 , it notifies (message 2 ) the observer resources. Upon receipt of such notification, Resource 1 issues a request for the Resource 3 and obtains as a result the representation ρ 3 (message 3 ). Note that, while observe/notify interactions take place through the point-tomultipoint connector (represented as a cube), REST operations exploit point-topoint connector (represented as a cylinder). All the resources exploit both the lookup operation to discover the needed resources, and the DNS service to translate URIs into physical addresses.

P-RESTful applications are built following the P-REST conceptual model [START_REF] Caporuscio | RESTful service architectures for pervasive networking environments[END_REF], which defines: (1) a environment as a resource container providing infrastructural facilities (i.e., lookup and observe/notify); (2) a resource as a first-class object that, according to the REST uniformity [START_REF] Fielding | REST: Architectural styles and the design of network-based software architectures[END_REF], implements a fixed set of well-defined operations (i.e., PUT, DELETE, POST, GET, and INSPECT); (3) a semantics-aware description specifying both functional and non-functional properties of resources with respect to given ontologies.

Resources interact with each other by exchanging their representations, which capture the current state of a resource. Furthermore, every Resource is bound to at Network-agnostic connectivity Fig. 2 ubiREST software architecture least one concrete URI (CURI). P-REST enhances the concept of URI by introducing abstract URIs (AURI). An AURI is a URI identifying a group of resources. Indeed, a CURI allows for point-to-point communication, whereas an AURI allows for group communication. Resources can be used as building-blocks for composing complex functionalities. A composition is a resource that can, in turn, be used as a building-block by another composition. Resources involved in a composition are handled by means of a composition logic.

Run-time support

The ubiREST middleware provides the run-time support for the development of P-RESTful service-oriented applications by realizing P-REST at the infrastructure level, and providing developers with effective P-RESTful abstractions. Note that ubiREST cannot enforce REST principles at the application level, which is totally entrusted to the designer. Referring to Figure 2, the ubiREST architecture exploits a three-layer design where each layer deals with a specific issue: Network-agnostic connectivity -Providing network-agnostic connectivity within ubiquitous networks relates to abstracting the rich and heterogeneous networking environment for reasoning about the networks characteristics and seamlessly manage them. To this extent, ubiREST goal is to support: (i) network abstractions to provide connectivity regardless of the actual underlying network technology, (ii) the selection of the best possible network matching the QoS needs expressed by the end user, and (iii) the unique identification and addressing of users applications within the networking environment irrespectively of their physical location. Communication layer -To deal with the inherent instability of ubiquitous networking environments, ubiREST arranges devices in an Multi-network overlay built on top of Network-agnostic connectivity layer. Such an overlay is then exploited to provide two basic communication facilities, namely point-to-point and group transport. Point-to-point transport grants a given node direct access to a remote node, whereas group transport allows a given node to interact with many different nodes at the

Bluetooth UMTS GPRS WLAN LAN Network-agnostic connectivity ubiLET MRN-Api

MRN-Daemon

Multi-radio networking Fig. 3 Network-agnostic connectivity layer software architecture same time. Furthermore, the ubiREST communication layer provides facilities for managing code mobility [START_REF] Roman | Software engineering for mobility: a roadmap[END_REF]. Programming model -ubiREST provides the programming abstractions to implement P-RESTful applications by leveraging the functional programming features of the Scala language [START_REF]The Scala language[END_REF] and the Actor Model [START_REF] Agha | Actors: a model of concurrent computation in distributed systems[END_REF]. In particular, ubiREST defines two main abstractions and a set of operations to be performed on them. Resource represents the computation unit, whereas Container handles both the life-cycle and the provision of resources. The set of operations allowed on resources defines the message-based ubiREST interaction protocol and includes: (i) Access, which gathers the set of messages to access and manipulate resources, (ii) Observe/Notify, which allows resources to declare interest in a given resource and to be notified whenever changes occur, (iii) Create, which provides the mechanism for creating a new resource at a given location, and Move, which provides the mechanism to relocate an existing resource to a new location, and (iv) Lookup, which allows for discovering new resources on the basis of a given semantics-aware description.

ubiREST fulfills the set of requirements introduced above. Flexibility is achieved by exploiting the Actor Model, which in turn relies on the ubiREST communication to provide message-passing interaction among actors. Genericity arises from the uniformity principle exploited in conjunction with both code mobility and functional programming capabilities (e.g., high-order functions). Dynamism is provided by means of semantic lookup, uniformity and resource composition. The following sections clarify these aspects, and detail network-agnostic connectivity (Section 4), ubiREST communication (Section 5), and ubiREST programming model (Section 6), respectively.

Network-agnostic connectivity

In this section, for the sake of self-containment, we report an excerpt of the networkagnostic connectivity layer implementation [START_REF] Caporuscio | ubiSOAP: A service-oriented middleware for ubiquitous networking[END_REF].

The network-agnostic connectivity layer offers the core functionalities to effectively manage the underlying multi-radio environment through: (i) a networkagnostic addressing scheme together with (ii) QoS-aware network link selection and (iii) base unicast and multicast communication schemes. Such Multi-Radio Networking (MRN) functionality are provided by means of two modules (see Figure 3): (i) a Multi-Radio Networking Daemon (MRN-Daemon) that implements the provided features, and (ii) a Multi-Radio Networking API (MRN-Api) that allows for an easy and transparent access to the functionalities offered by MRN-Daemon. Furthermore, a ubiLET is any entity (e.g., application) that exploits the network-agnostic connectivity layer by accessing the functionalities provided by MRN-Daemon through MRN-Api.

In particular, MRN-Daemon is in charge of managing the entire communication between two devices through the underlying radio networks. It runs on each device and is accessible by many applications at the same time. It is also in charge of managing the ubiREST addressing scheme as well as its mapping to the actual set of IP addresses. On the other hand, MRN-Api is a component, embedded in the application, used to interact with the MRN-Daemon. It offers a set of high-level API allowing for an easy and transparent access to the services offered by he MRN-Daemon. Indeed, in order to communicate with each other, services deployed on ubiRESTenabled devices must use the functionalities provided by the MRN-Daemon through the MRN-Api.

Since ubiREST aims at running on resources-scarce platforms (e.g., PDA and mobile phones), which have limited CPU power, memory, and battery life, to best fit the resources available on the hosting device, ubiREST provides two different (but equivalent and fully compatible) implementations of the network-agnostic connectivity layer, namely shared and embedded.

A shared network-agnostic connectivity layer is implemented as a "shared" instance of MRN-Daemon, which is simultaneously accessed by multiple ubiLETs (through the API provided by MRN-Api). Since all the ubiLETs access the same instance, possible conflicts can be solved in an automated way (i.e., two ubiLETs expressing conflictual QoS requirements over the interface activation).

On the other hand, an embedded network-agnostic connectivity layer is implemented by "embedding" the MRN-Daemon into the MRN-Api. In this case, each ubiLET accesses a different, and standalone, instance of MRN-Daemon. This solution is lighter than the shared one, and is obviously appropriate when there exists only one ubiLET per device. In fact, the shared MRN-Daemon interacts with MRN-Api by means of a TCP socket bound to the loopback interface. This requires for having a synchronized thread-pool managing the incoming concurrent requests. It thus implies both larger memory footprint and computational needs. However, embedded MRN-Daemons cannot communicate with each other and then, they cannot synchronize to solve possible conflicts. Network-agnostic addressing -Devices embedding multiple network interfaces (e.g., WLAN and Bluetooth) may have multiple IP addresses, at least one for each active interface. Thus, in order to identify uniquely a given ubiLET in the network we associate it with a Multi-Radio Networking Address (MRN@). The MRN@ of a ubiLET instance is specifically the application's Unique ID, which maps into the actual set of IP addresses (precisely, network ID⊕IP addresses) bound to the device (at a given time) that runs the given instance. Referring to Figure 4, the MRN@ associated to the ubiLET j running on Alice's device is:

MRN@ ubiLET j → {net a ⊕ IP a 1 , net i ⊕ IP i 1 , net n ⊕ IP n 1 }
where ∀ j ∈ {1, 2}, MRN@ ubiLET j is the ID of ubiLET j and, {net a ⊕ IP a 1 , net i ⊕ IP i 1 , net n ⊕ IP n 1 } is the set of network ID ⊕ IP addresses denoting the actual location of the device 1 . Then, upper layers shall use MRN@ as part of their ad-dressing scheme (e.g., through WS-addressing in the case of Web services), which replaces the traditional IP-based addressing scheme. MRN@s are automatically generated and managed by multi-radio networking. Furthermore, multi-radio net-working allows for performing a lookup operation that, starting from an MRN@, returns the set of IP addresses actually bound to it. The basic operations provided by networkagnostic connectivity are as follows. First, Registration allows the ubiLET to register within the network-agnostic connectivity layer and generates the MRN@ that uniquely identifies it. In particular, the ubiLET (i.e., user application) provides as input an identifier (locally unique), which is used to generate the MRN@ to be returned. Then, Lookup allows user applications to retrieve the actual set of IP addresses related to a given MRN@. If the resolution of MRN@ is not cached or needs to be updated, a request is multicasted to all the networks currently accessible and, if the device related to such MRN@ is reached, it will directly reply to the requester by supplying the actual set of IP addresses. QoS-aware network link selection -Next to MRN@ addressing, it is crucial to activate and select the best possible networks (among those available) with respect to required QoS, which is defined as a set of pairs < QoS attr , QoS value >. Attributes are grouped in two subsets: (i) quantitative attributes that describe the performance provided by the networks -e.g., bitrate, packet loss transfer delay and signal strength -and allows for networks ranking, and (ii) qualitative attributes that describe those characteristics of the network that do not affect the network performance but should be considered -e.g., power consumption, price, coverage area. Departing from WSoriented approaches (e.g., WS-Policy) that are "asymmetric" and they do not allow service consumers to specify their requirements, ubiREST strives to enable network QoS negotiation by trying to meet both provider and consumer requirements (expressed in terms of network QoS). To this extent, ubiREST provides two functionality, namely interface activation and network selection. Interface activation allows the user application to activate the best possible interfaces (among those available) with respect to the required QoS. In particular, the application submits its QoS requirement (a set of pairs < QoS attribute , QoS value >) to multi-radio networking, which in turn compares it with the QoS of each available interface (Network-side QoS and Context). In this case, since the interface is switched off, QoS refers to the theoretic values of a network interface declared by the manufacturer (e.g., GPRS maximum bitrate = 171.2Kb/s). If the interface satisfies the requirement posed by the application, within a given approximation expressed in percentage, it is activated. It is also possible to define priorities upon the various quantitative parameters, in order to specify if a given parameter is more important than the others. On the other hand, network selection is performed during the establishment of the communication and takes into account the QoS attributes required by the client application that is initiating the connection, as well as the networks active on the server listening for incoming connections, as given by the servers MRN@. If the client and the server share only one network that satisfies the requirements, it is used to carry on the interaction. On the other hand, when the two parties share more than one network, the selection algorithm selects the one that best meets the required QoS. Multi-radio unicast and multicast -Once defined the MRN@ addressing scheme and the operations enabling the network link selection, the network-agnostic connectivity layer provides two base communication facilities: synchronous unicast and asynchronous multicast2 . ubiREST synchronous unicast allows for messaging communication between two ubiLETs sharing at least one network. Specifically, it is provided by means of a logical stream channel that is used by the ubiLETs to read-/write the packets belonging to the ongoing communication. Whereas, ubiREST asynchronous multicast allows for multicast messaging communication within a group of ubiLETs sharing at least one network. Specifically, it is provided by means of multicast packets that are sent to all members of a given group.

ubiREST communication layer

Providing communication within ubiquitous networks relates to comprehensively exploiting the rich, heterogeneous networking environment for message handling. In particular, ubiREST goal is to support: (1) Mobility so that active connections are maintained transparently to the application layer despite the mobility of nodes, as long as a network path exists, (2) efficient messages routing in multi-paths configurations (i.e., when multiple network paths exist between the consumer and the provider), (3) both point-to-point and group communications using the same ab-stractions (i.e., MRN@), and (4) multi-network routing so that access to resources in distant networks is enabled as long as there exists a path bridging the heterogeneous networks between the consumer and target resource provider.

To meet the above, ubiREST arranges devices in a multi-network overlay, a virtual network of nodes and logical links built on top of existing actual networks [START_REF] Doval | Overlay networks: A scalable alternative for P2P[END_REF] and meant to augment the native network with new services. The ubiREST overlay network manages the logical links between nodes (i.e., resources) and enables message exchange. In particular, ubiREST embeds (i) the protocols that keep the overlay network connected when the topology of the underlying native network changes (e.g., as a consequence of mobility), and (ii) the routing algorithms that regulate the message flow between nodes according to the specific coordination model used, namely point-to-point communication and group communication. In pervasive environments, a key requirement for the overlay is the ability to self-organize itself into a flexible topology, as well as to maintain it. To this extent, ubiREST defines a custom transport layer that leverages network-agnostic connectivity and provides: (i) the multi-network overlay in charge of forwarding messages across independent networks, and (ii) two transports for point-to-point and group communication in ubiquitous networking. Multi-network overlay Thanks to the ubiREST network-agnostic connectivity layer, communication among nodes exploits the various network links that the nodes have in common by selecting the links that provide the required QoS. However, in some cases, it might also be desirable for nodes to be able to access resources that are hosted in distant networks to which the requesting node is not directly connected to (e.g., to provide continuity of service despite node mobility). For example, in Figure 4, the device of Alice is connected to networks a, i, and n, through its various network interfaces. Clearly, the device can trivially access resources hosted in these networks. However, it cannot access resources hosted by Bob's device that is located in the distant networks x, y, and z. In fact, the network-agnostic connectivity layer does not provide neither an overlay IP network nor multi-network routing.

However, relying on the MRN@, together with both unicast and multicast communication schemes, ubiREST introduces an overlay network that is able to bridge heterogeneous networks, thus enhancing overall connectivity. In particular: (i) MRN@ addressing provides a two-layer identification scheme (i.e., network ID⊕ IP) allowing for uniquely identifying a device irrespectively of the network it belongs to, and (ii) unicast and multicast communication support allows for MRN@ management across the networks. Specifically, nodes that are connected to two (or more) different networks through their network interfaces can assume the role of bridge nodes. Bridge nodes quite literally "bridge" between two separate networks, relaying ubiREST point-to-point and group messages across those networks. Still, we assume that nodes will not access resources that would require the consecutive traversal of more than five wireless networks (see [START_REF] Gupta | The capacity of wireless networks[END_REF][START_REF] Li | Capacity of ad hoc wireless networks[END_REF] for a detailed analysis on wireless communication) in order to access them. Hence, still referring to Figure 4, Alice has to route its request through an appropriate bridge node (i.e., bridges A, B and C, noting that each bridge node is displayed in each network it is part of). Specifically, bridges are in charge of routing messages within the multi-network overlay by determining the best route to reach a distant network. To achieve these tasks, bridges nodes run an instance of OLSR [START_REF] Jacquet | Optimized link state routing protocol for ad hoc networks[END_REF] among each other, and exchange routing messages using the specific asynchronous multicast transport provided by the network-agnostic connectivity layer. Instead of concrete node addresses, however, bridges store as destinations the identifiers of the various present networks (i.e., network ID) and as next hop the bridge that needs to be contacted next to eventually reach the target network. The, whenever a non-bridge node wants to access a resource outside one of the networks it is itself connected to, it simply routes the request to any bridge of choice that will then forward the request accordingly. Point-to-point transport -The ubiREST point-to-point transport is a connectionoriented transport for supporting resource access. The ubiREST point-to-point transport: (i) leverages the network-agnostic connectivity layer to send and receive messages relying on the MRN@ addressing scheme, and (ii) delivers the message to the appropriate resource. When the CURI of the destination resource is specified (e.g., mrna://dd3ef7e3-5f50-3800-982d-62095c6e8075/cart), ubiREST selects point-to-point as transport layer and extracts the MRN@ from the CURI. Note that, when both the consumer and the provider simultaneously change the complete set of IP addresses associated to their MRN@ (and no direct link exists) the session will break and the consumer needs to perform a resource discovery to find the same resource again and reestablish the communication. Group transport -In ubiquitous networking environments, it is crucial to support point-to-multipoint interactions since it is central to advanced middleware services like dynamic discovery [START_REF] Zhu | Service discovery in pervasive computing environments[END_REF]. We thus introduce the ubiREST group transport over multi-network overlay, building upon the asynchronous multicast facilities provided by network-agnostic connectivity layer. Specifically, the ubiREST group transport is a connectionless transport for one-way communication between multiple peers in multi-network configurations. The ubiREST group transport interacts with the network-agnostic connectivity layer to send multicast messages based on an MRN@ identifying the group (i.e., AURI), and to deliver messages to the registered resources.

Code mobility

Concerning the genericity requirement, ubiREST is able to accommodate heterogeneous and unforeseen functionalities into the running application. Unknown Java classes can be dynamically deployed in the overlay by leveraging code mobility [START_REF] Roman | Software engineering for mobility: a roadmap[END_REF]. ubiREST code mobility mechanism directly relies on the ubiREST communication facilities, then different coordination mechanisms impose different code mobility approaches. For point-to-point communication, ubiREST implements an end-to-end strategy that enables two ubiREST nodes to exchange executable code, whereas for group communication, ubiREST adopts a hop-by-hop strategy that, Independently of the specific strategy, ubiREST implements an ad-hoc classloader hierarchy to cope with the "missing class" problem. In fact, when sending a message containing a Java object, such an object is serialized into a byte array and delivered towards the destination, which in turn deserializes the object before using it. However, if the object is unknown to the destination (i.e., the destination node does not hold the class bytecode for the received object), the object cannot be deserialized. To this extent, ubiREST implements a custom classloader, which is in charge of retrieving the bytecode for the missing classes, and loading them at run time in the local JVM to allow for a correct deserialization. The JVM specification [START_REF] Lindholm | Java virtual machine specification[END_REF] allows for creating a tree-like hierarchy of classloaders to load classes from different sources. When a classloader in the hierarchy is asked to load a class, it asks its parent classloader to load it. If the parent classloader cannot find the class, the child classloader then tries to load it itself. If also the child classloader fails, an exception is thrown. ubiREST exploits such a feature by defining a custom ubiREST classloader as child of the standard Java Bootstrap classloader. When loading classes, the ubiREST classloader delegates its parent classloader (i.e., Bootstrap). If the Bootstrap classloader fails, then the bytecode is not available within the node and should be retrieved remotely. Thus, the ubiREST classloader contacts the origin ubiREST node asking for the missing bytecode. The origin side retrieves the bytecode from its classpath and sends it back to the requesting node. At this point, the ubiREST classloader holds the needed bytecode and can load the class and deserialize the incoming object. If other classes are missing, then such a procedure is iterated until the entire class closure is retrieved.

ubiREST implements an end-to-end strategy to achieve point-to-point code mobility among nodes. Referring to Figure 5, let A be an ubiLET sending a message to an ubiLET B, and let CL a , CL b be the classloader of A and B, respectively. Whenever B receives a message containing an object of an unknown type from A, an Exception is thrown, and the control is passed to CL b , which in turn asks for the missing class to CL a . CL a processes the request, encapsulates the needed bytecode into a message, and sends it back to B. Once the bytecode is available at CL b , it can be loaded into the JVM. The whole procedure is recursively applied until the whole closure of the original class is available on B. The retrieved bytecode is now stored on B and made available for further instantiations.

As for the group communication, this solution is not applicable. In fact, ubiREST group communication relies on the underlying Multi-radio multicast where message sender and receiver are completely decoupled, and do not have any knowledge about each other. Moreover, applying the end-to-end strategy to group communication would flood the overlay network with requests for bytecode retrieval towards the origin node, which become overloaded. To prevent this problems, ubiREST communication adopts a hop-by-hop strategy, which spreads the bytecode across the Multi-network overlay towards all the destinations: ubiREST applies the end-to-end strategy at each bridge along the path between the origin node and each recipient.

The ubiREST programming model

As already introduced, P-REST defines systems that comply with the "networkbased" paradigm, which rely on the explicit distribution of resources interacting by means of (asynchronous) message passing. Network-based applications can be easily modeled and developed as a set of interacting actors [START_REF] Kuuskeri | On actors and the rest[END_REF], a computational resource reacting to external stimuli (e.g., messages) by either (i) sending messages to other actors, or (ii) creating new actors, or (iii) designating the behavior for the next stimulus.

The ubiREST programming model exploits the Scala [START_REF]The Scala language[END_REF] programming language, which (i) natively provides the Actor system, (ii) provides functional features (e.g., high-order functions), and (iii) is a JVM language, then allowing for Java libraries reuse (e.g., Multi-radio Networking), and for benefiting from JVM facilities (e.g., security manager for sandboxing). According to both the P-REST model and the ubiREST software architecture ( §3), the ubiREST programming model revolves around the resource and container abstractions. A resource represents the computational unit, whereas container handles both the life-cycle and the provision of resources. The ubiREST programming model exploits the Scala Actor System [START_REF] Agha | Actors: a model of concurrent computation in distributed systems[END_REF] by benefiting from its intrinsic qualities: i.e., functional programming paradigm, eventbased computation and shared-nothing concurrency, as well as Java interoperability. Hence, the set of ubiREST's abstractions is fully implemented in Scala and exploits the actor model. Resource -The resource abstraction is directly mapped to a Scala actor. A Resource actor is defined as a Scala abstract class, which is further extended by any resource to be deployed within ubiREST. When extended and instantiated, a Resource object is initialized by specifying: (i) the CURI address, (ii) the set of operations available for the specific resource, and (iii) the resource's Description specifying the actual semantic concept implemented by a resource, defined as AURI.

According to the Scala Actor Model, Resource implements the act() method, which defines the resource's passive behavior, i.e., how the resource responds to external stimuli encoded as received messages. act() removes messages from its mailbox and, processes them accordingly. To prevent overriding, and then enforcing resources to conform to the REST uniformity principle, act() is defined as final, and accepts only messages defined by the P-REST uniform interface. Moreover, PUT, DELETE, and GET methods are declared as final and implement the well known semantics defined by HTTP. Further, ubiREST defines a new method INSPECT, which allows for retrieving meta-information about the resource (e.g., Description). Rather, the POST method is declared as abstract to allow developers to implement their own semantics. Furthermore, according to the Observer pattern defined by P-REST, a resource notifies the observers whenever its internal state changes. That is, when executing either a PUT, a DELETE or a POST operation, the resource actor exploits the underlying ubiREST communication to send a group message notifying the occurred changes.

According to P-REST, a resource plays a prosumer role, i.e., it is able to fulfill both roles of producer and consumer. In order to access external resources and consume their artifacts, a given resource sends request messages to the resources of interest and receives response messages. To this extent, ubiREST defines a workflowEngine function to be instantiated with the desired behavior by any Resource that wants to consume external resources. Indeed, the active behavior is specified by a workflow implementing the composition logic defined by P-REST. Specifically, ubiREST defines workflowEngine as a Scala higher-order function, which takes a workflow as input and executes it:

workflowEngine : (workflow : Unit ⇒ Unit) ⇒ Unit
The definition of workflowEngine as a higher-order function provides ubiREST with the ability of accomplishing hot deployment of new active behaviors at run time. This feature, in turn, supports dynamic situation-aware evolution.

Furthermore, also ubiREST provides developers with a high-level domain specific data-flow language for coordinating resources, namely the PaCE (ubiREST Coordination languagE) [START_REF] Caporuscio | PaCE: A Data-Flow Coordination Language for Asynchronous Network-Based Applications[END_REF]. Specifically, PaCE (i) allows developers to specify the active behavior (composition logic) of a composite resource in terms of the set of operations defined by the ubiREST programming model, and (ii) achieves both adaptation and evolution of compositions in terms of resource addition, resource removal, resource substitution, and resource rewiring [START_REF] Oreizy | Architecture-based runtime software evolution[END_REF]. Representation -Resources interact with each other by exchanging their representations. ubiREST provides a resource representation by serializing the resource instance into a byte array. All the fields specifying the internal state of a resource are serialized into the array. However, since a ubiREST resource is implemented as a actor, it is not directly serializable. In fact, actors inherit from threads, which are not serializable as well. To cope with this issue ubiREST exploits the trait mechanism provided by the Scala language. In Scala, traits are used to define object types by specifying the signature of the supported methods, similarly to interfaces in Java. However, unlike Java interfaces, traits can be partially implemented, i.e., it is possible to define default implementations for some methods. Thus, ubiREST defines a special Scala trait, which implements custom serialization/deserialization mechanisms through two methods, namely writeExternal and readExternal.

Both methods are automatically invoked by the JVM when the object is serialized and deserialized, respectively.

The writeExternal method makes use of the Java reflection mechanism to (i) discover the names and the values of the attributes of a class extending Resource, (ii) filter out the attributes inherited by Actor3 , and (iii) serialize the remaining attributes using standard serialization. On the other hand, when the JVM deserializes a Resource, it instantiates an empty object and invokes the readExternal method, which in turn reads serialized attributes from the input stream, and makes use of the reflection mechanism to properly assign values to resource's attributes. This mechanism allows for the automatic generation of resource representations. Representation stores the byte array generated by the writeExternal method.

It is important to note that, designers are entrusted with preserving information hiding in Representation, i.e., avoiding the serialization of internal state information. For example, given a resource abstracting an algorithm, it should not return the representation of the algorithm. Rather, it should return the representation of the resource abstracting the results computed by the algorithm. Description -As introduced in Section 3, resource descriptions are semanticsaware and play a key role in ubiREST. In fact, since all resources implement the same interface, descriptions result to be the only discriminant. To this extent, ubiREST provides developers with a Resource Description Language (RDL) defined by means of a XML Schema (see Figure 6 and Figure 7). In particular, a Description is composed of two entities: (i) the functional description, which describes the functionalities provided by the given resource, and (ii) the SURI and CURI attributes, which define the semantic concept implemented by the given resource and its concrete identifier (i.e., the actual resource URI), respectively. The functional description aims at specifying "what" capabilities are actually provided through the uniform interface. To this end, it describes, for each implemented operation, the semantic concept it refers to (i.e., semanticRef), the data expected as output, and the input parameters if required (e.g., POST and PUT operations require for an input parameter, whereas the others do not). Container -ubiREST handles resources' life-cycle and provisioning through the Container actor, which is implemented as an ubiLET. Indeed, the Container stores references to the hosted resources into a resource repository built as a mapping from resources CURI to the respective Resource instance. Since a container is an active party in ubiREST, it also holds a CURI address, which is used to access a container's services. Hence, the container is in charge of handling three classes of incoming messages: (i) messages addressed to a specific resource hosted by the container, (ii) messages directly addressed to the container itself, and (iii) broadcast messages. In the first case, the container simply forwards the message payload to the right Resource actor. Messages addressed to the container are directly handled and processed. Finally, broadcast messages are received by the ubiREST node As already pointed out, the container is in charge of managing resources' lifecycles and provision. In particular, a container creates and moves resources, provides support for resource lookup, as well as grants for resource access. While resource access is managed by the resource itself through its interface, creation, relocation and lookup operations are managed by containers.

To create a resource, the container must be provided with information concerning (i) the Representation of the resource to be created, and (ii) an optional CURI to be assigned to the resource. When creating a new resource, the container checks <?xml version="1.0" encoding="UTF-8"?> <rdl:description aURI="presenter" cURI="dd3ef7e3-5f50-3800-982d-62095c6e8075/Projector"> <functional> <put semanticRef="display"> <output xsi:type="rdl:simpleData" name="ack" type="bool" semanticRef="response"/> <input xsi:type="rdl:simpleData" name="PNG" type="bin" semanticRef="slide"/> </put> </functional> </rdl:description> Fig. 7 A resource description example using RDL whether the CURI has been specified or not (if not a CURI is automatically generated), and extracts the Resource instance from the provided Representation. The newly created Resource is then deployed within the container and a new entry is added to the resource repository. Finally, the new Resource is initialized and started.

When moving a resource r from a container C A to a container C B , ubiREST needs to coordinate the two containers in order to guarantee both the correct deployment of r within the container C B , and the delivery of messages to the r's new location (to avoid packet loss). Specifically, C A buffers all the incoming messages addressed to r. ubiREST performs the move operation in three steps: (i) C A waits until r consumes all the messages already in its mailbox and reaches a quiescent state [START_REF] Kramer | The evolving philosophers problem: Dynamic change management[END_REF]; (ii) C A generates a representation ρ for r; (iii) C A invokes a Create operation on C B by passing both ρ and the CURI of r; r is then created in C B and kept quiescent. Once these steps are successfully accomplished, ubiREST updates the naming system with the new location of r, and activates it. Finally, C A removes r from its resource repository, and forwards all the buffered messages towards C B , where r is now able to consume old messages, as well as the new ones that are directly delivered to the new location.

Finally, a lookup operation is used to query the ubiREST overlay for resources of interest on the basis of their descriptions. In particular, lookup takes advantage of Scala functional features by allowing developers to specify their own lookup strategy as a filter function, which is used to filter out results to be returned to requesters:

lookup: (filter: RDL ⇒ Boolean, d : RDL) ⇒ cURI[ ]
Lookup is a high-order function that evaluates the function filter with all the RDL descriptions stored by the resource repository, and returns the list of CURI identifying those resources evaluated true. ubiREST provides a default implementation for filter, which exploits well known signature matching algorithm [START_REF] Sycara | Automated discovery, interaction and composition of semantic web services[END_REF][START_REF] Paolucci | Semantic matching of web services capabilities[END_REF]. Indeed, the lookup function matches a requested AURI, against the set of AURI implemented by the resources stored within the resource repository. Then, filter checks if provided and required AURIs, specified by means of ontology concepts, satisfy one of the following subsumption relationships: (i) the concepts are equivalent (exact matching), (ii) the provided concept subsumes the required one (plugin matching), (iii) the required concept subsumes the provided one (subsume matching), and (iv) there does not exist any subsumption relation between the two concepts (fail). If the result is not fail, then CURI of the matching resource(s) is returned to the requesting node.

ubiREST in action: an example

This section shows how ubiREST abstractions can be easily and intuitively exploited to develop a ubiquitous application, namely Ubiquitous Slide Show (USS).

To this extent, we introduce a simple scenario describing a USS use case: Carl, a university professor, is going to give a talk at the conference room, and carries his laptop storing both the slides and related handouts. The conference room provides speakers with a smart-screen available on the local wireless network, whereas the audience is supposed to be equipped with devices (e.g., laptop, smartphone, tablet), which can be used for displaying either the slide currently projected on the screen or the related handouts. The audience and the speaker always refer to the same slide, and to the same page of the handouts. All the devices are supposed to have a ubiREST instance running on them.

USS conforms to the P-REST conceptual-model and specifies the following resources: CurrentSlide and CurrentPage represent the slide currently projected, and the corresponding handout page, respectively; Remote models the remote controller used by Carl to browse the slide show represented as an ordered list of slides; PresReader and HoReader visualize the slide show and the handout on the audience's devices, respectively; Projector handles the smartscreen of the conference room. The Projector resource is deployed within the smart-screen ubiREST container. CurrentSlide, CurrentPage, Remote, PresReader and HoReader are initially deployed on Carl's container, and made available to the devices in the audience which join the slide show.

Figure 8 shows a sequence diagram defining how such resources interact with each other to implement USS. Remote broadcasts a Lookup messages searching for a resource that implements the presenter concept, as defined by the Projector RDL description (see Figure 7). As a result, it obtains the projector CURI that, in our example, matches the lookup request. Once the projector CURI's has been retrieved, Carl starts the slide show: Remote sends a PUT message, containing the representation of the first slide, to the projector, and then creates the CurrentSlide resource also initialized with the representation of the first slide.

On the other side, when a participant (say, Bob) enters the conference room, he uses the ubiREST resource finder built-in tool, which lists all the resources available within the overlay, to explore the environment and find the PresReader resource. Hence, selecting PresReader from the list, the ubiREST node issues a GET operation to retrieve a representation of PresReader, which, in turn, is used to create When Carl needs to show the next slide of his presentation, he generates a next event that is handled by the Remote's workflowEngine by performing a PUT operation on both Projector and CurrSlide. Modifying the Projector resource causes the projected slide to change, whereas modifying CurrSlide generates notifications towards all the resources that are observing CurrSlide. Then, PresReaderBob receives such a notification and retrieves the new CurrentSlide representation, which is then visualized on his devices.

This case study demonstrates that Resource is a natural abstraction for designing and implementing ubiquitous applications. Besides, they are simple and intuitive, as proven by the fact that USS consist of only 13 classes, among which the largest one required about 150 lines of code. However, evaluating the ubiREST against competitors is a hard task because of the lack of common test-beds. Hence, we are currently involving students in a Beta-Test phase, where a set of case studies will be developed by means of different middlewares.

Conclusion

Service-oriented computing appears as a promising paradigm for ubiquitous computing systems that shall seamlessly integrate the functionalities offered by networked resources, both mobile and stationary, both resource-rich and resourceconstrained. In particular, the loose coupling of services makes the paradigm much appropriate for wireless, mobile environments that are highly dynamic. However, enabling service-oriented computing in ubiquitous networking environments raises two key challenges: (i) achieving the ubiquitous networking environment on top of multi-radio connectivity, and (ii) providing a flexible architectural style, which allows for designing and developing applications resilient to the extreme instability inherent to ubiquitous networking environments.

Exploiting multi-radio connectivity has led to the definition of various algorithms for optimizing the scheduling of communications over multiple radio interfaces, e.g., [START_REF] Qureshi | Horde: separating network striping policy from mechanism[END_REF][START_REF] Klasing | Cost minimisation in wireless networks with bounded and unbounded number of interfaces[END_REF][START_REF] Charlet | Energy-efficient middleware-layer multi-radio networking: an assessment in the area of service discovery[END_REF]. Building on this effort, this paper has introduced a networkagnostic connectivity layer, which leverages multi-radio networking by means of a special addressing scheme for networked services, namely MRN@, a QoS-aware network selection mechanism and both unicast and multicast communication facilities. In particular, this layer is in charge of managing the low-level heterogeneity inherent to multi-radio networking environments, by allowing for the exploitation of different application-level communication protocols. Building upon these functionalities, the ubiREST communication layer implements two different transports, namely ubiREST point-to-point and ubiREST group, which leverage networkagnostic connectivity to enable the ubiquitous networking of RESTful services deployed on various devices -e.g., Tablets and smartphones -embedding multiple radio interfaces.

On the other hand, ubiREST strives to satisfies the flexibility, genericity and dynamism requirements by adhering to the P-REST principles and exploiting both functional programming and code mobility. Specifically, (i) ubiREST achieves flexibility by exploiting the Actor Model and relying on the ubiREST overlay network to provide message-passing interaction, (ii) ubiREST provides genericity through the exploitation of a uniform interface in conjunction with both code mobility and functional programming capabilities (i.e., high-order functions), and (iii) ubiREST provides dynamism by allowing resource composition.

Ongoing and future work is manyfold and proceed towards different lines of research. First of all, we are currently defining an high-level composition language allowing developers to specify their own resource compositions in an agile and asynchronous way. Further evolution of ubiREST is towards the satisfaction of extrafunctional requirements. In particular, we want extend the Resource Description Language, and the lookup service as well, to consider extra-functional concerns (e.g., quality of service, security), and contextual information (e.g., physical location) while specifying and search for resources of interest, as well as when composing them. Concurrently, we aim at improving ubiREST performances in terms of network load by investigating different types of overlay networks (e.g., peer-to-peer and hybrid).

Fig. 1 P

 1 Fig. 1 P-REST architectural style

Fig. 4

 4 Fig. 4 Network-agnostic addressing over Multi-network overlay

Fig. 5

 5 Fig. 5 Sequence diagram for point-to-point code mobility

Fig. 6

 6 Fig. 6 Resource Description Language

Fig. 8

 8 Fig. 8 Behavioral specification of the USS application

For the sake of simplicity we refer to IP address, but it is actually implemented as IP address and port number, e.g., 128.131.10.1:90.

The interested reader is referred to[START_REF] Caporuscio | ubiSOAP: A service-oriented middleware for ubiquitous networking[END_REF] for further details.

Scala Actors are not serializable and do not contain information regarding the resource internal state.

Acknowledgements

This research has been partially funded by the European Commission, Programme IDEAS-ERC, Project 227077-SMScom (http://www.erc-smscom.org), and by European Community's Seventh Framework Programme FP7/2007-2013 under grant agreement number 257178 project CHOReOS -Large Scale Choreographies for the Future Internethttp://www.choreos.eu).