Daniel Romero

Romain Rouvoy

Lionel Seinturier

Pierre Carton

Service Discovery in Ubiquitous Feedback Control Loops

Nowadays, context-aware applications can discovery and interact with services in ubiquitous environments in order to customize their behavior. In general, these providers use diverse discovery and interaction protocols. Furthermore, they can join and leave the environment at anytime, making difficult the utilization of services. Therefore, this mobility and variability in terms of protocols impose a low coupling between the interacting entities and the need for spontaneous communications. Unfortunately, the existing works in literature fail to deal with these needs in a simple and flexible way. In this paper we face this problem by defining ubiquitous bindings for SCA (Service Component Architecture) applications. These bindings modularize the discovery concerns promoting sharing of common discovery functionalities and simplifying the integration of discovery protocols. In this way, these bindings enable the transparent advertisement, discovery, filter, and access of services available in the environment. Our ubiquitous bindings are integrated into the FraSCAti platform and their benefits are demonstrated by building ubiquitous feedback control loops.

Introduction

In ubiquitous environments, different computational entities (mobile devices, laptops, sensors, etc.), both providinga n dc o n s u m i n gs e r v i c e s ,a r r i v ea n dl e a v e routinely [START_REF] Kindberg | System software for ubiquitous computing[END_REF]. The different applications executing in these environments exploit this richness to adapt and improve their behavior. However, in ubiquitous environments, because there is no standard discovery protocol, the service providers are used to select the most suitable according to their capabilities. This results in ac o l l e c t i o no fa d v e r t i s e ds ervices using heterogeneous discovery and interaction protocols, and characterized by their dynamism, that cannot always be discovered and accessed by clients. Therefore, spontaneous communications become an important issue to deal with dynamicity and unpredictability of ubiquitous environments [START_REF] Kindberg | System software for ubiquitous computing[END_REF]. Unfortunately, the works in the literature to deal with this issue tend to be complex, not flexible enough or do not consider the needs of consumers in terms of interaction mechanism [START_REF] Bromberg | Indiss: interoperable discovery system for networked services[END_REF][START_REF] Nakazawa | A bridging framework for universal interoperability in pervasive systems[END_REF][START_REF] Grace | A reflective framework for discovery and interaction in heterogeneous mobile environments[END_REF].

In this paper, we extend the SCA (Service Component Architecture) model [START_REF] Beisiegel | Service Component Architecture[END_REF] with the notion of ubiquitous bindings in order to support service discovery in ubiquitous environments. These bindings enable applications to discover and filter SCA services available in the environment, which are then accessed using the supported SCA bindings. We claim that SCA extensibility and independence from communication and implementation technologies allow the transparent management of service discovery. Furthermore, by encapsulating spontaneous communications in SCA bindings, we provide the flexibility required for choosing the most suitable discovery and communication mechanism between consumers and providers. We illustrate the utilization of our bindings by designing ubiquitous feedback control loops (FCLs) [START_REF] Hariri | The Autonomic Computing Paradigm[END_REF]. This kind of FCLs allows us to deal with runtime adaption of context-aware applications supporting the mobility of the participating entities. The ubiquitous bindings are implemented as SCA components for promoting reuse and integration into the FraSCAti platform [START_REF] Seinturier | Reconfigurable sca applications with the frascati platform[END_REF].

The rest of this paper is organized as follows. We start by introducing the motivations for discovery and adaptation in the landscape of context-aware applications (cf. section 2). We continue with the foundation of our proposal (cf. section 3) before introducing our ubiquitous FCLs (cf. section 4). Then, we present our lightweight solution for supporting discovery in SCA applications (cf. section 5) and the evaluation of our implementation (cf. section 6). In section 7, we compare our approach with existing solutions for service discovery in ubiquitous environments. Finally, we summarize the conclusions of this work and the promising research directions in section 8.

2M o t i v a t i o n s a n d C h a l l e n g e s

This section highlights the challenges for context-aware applications in ubiquitous environments. We start by describing a motivating scenario (cf. section 2.1) before introducing the challenges it exhibits (cf. section 2.2).

Motivating Scenario

As m a r th o m eg e n e r a l l yr e f e r st oah o u s ee n v i r o n m e n te q u i p p e dw i t hv a r i o u s types of sensor nodes, which collect information about the current temperature, occupancy (movement detection), noise level, and light states. In addition to that, actuators are also deployed within rooms to physically control appliances, such as lights, air conditioning, blinds, television, and stereo. In this environment, both sensors and actuators can be accessed from mobile devices owned by the family. Furthermore, the control system deployed in such a smart home is able to retrieve preferences about room configuration from mobile devices and change the room state according to them. For example, preferences can describ e the temperature and light levels accepted by each family member. When several people share the same room, the decision is based on merged preferences. In case of conflict, the decision prioritizes the first person that enters the room. The mobile devices also have an application that enables users to control the appliances in home. This application has several modules (one for each appliance) that are activated or deactivated according to the current battery level,t h ebattery saving preference and activation of modules preference (this information is also provided by the mobile device). The modules also are installed/uninstalled regarding the changes in the appliance configurations. The following paragraphs describe two concrete situations of the scenario.

Alice listens to music in the living room. The temperature conforms to her preferences. When Bob enters the living room, the controller detects his device and retrieves the preferences (related to the room configuration as well as for the application allowing the access to appliances). Let assume that there is no conflict with the temperature level. However, the light level is too low for Bob's tolerance. The light range specified by Alice includes the level accepted by Bob. Hence, the system decides to modify the light level of the room according to Bob's preferences. On the other hand, the system analyses battery level and decides that it must deactivate the multimedia module allowing downloads from am u l t i m e d i as e r v e ra v a i l a b l ea th o m e .

In another situation, Alice installs a new TV. The system detects the new device and retrieves the required modulet oc o n t r o li t .W h e nB o ba r r i v e sh o m e , the system detects his device and installs the module as well.

Key Challenges

According to our scenario, we can identify three key challenges for contextaware applications in ubiquitous environments: i) heterogeneity, ii) mobility and iii) runtime adaptation.T h efi r s to n er e f e r st ot h ev a r i a b i l i t yi nt e r m so fd e v i c e s (that differ in their processing capabilities), services (implemented with several technologies) and context information (that has different syntax and semantic) present in the environment. This requires a flexible solution in terms of communication (e.g.,p r o t o c o l sa n dd a t ar e p r e s e n t a t i o n )t h a ta l l o w sa p p l i c a t i o n st o access the context and services. The mobility is concerned with the dynamicity of services and context providers, which can spontaneously join and leave (e.g., mobile devices in the scenario). Hence, the applications should keep working even if some providers are gone as well as they should have the possibility to discover new services. Finally, the adaptation of context-aware applications requires the retrieval and processing of the context information for deciding the needed reconfigurations. In this adaptation should be considered the variable capabilities of the different devices that execute the context-aware applications.

As presented in this paper, we face the mobility and heterogeneity issues using our RESTful (cf. section 3.3) and ubiquitous bindings (cf. section 5). We also provide some highlights for dealing with the adaptation at runtime by defining ubiquitous feedback control loops (cf. section 4).

3B a c k g r o u n d

In this section, we present the foundation of our proposal-i.e.,t h ef e e d b a c k control loops (cf. section 3.1) and SCA (cf. section 3.2). We also introduce the FraSCAti platform (cf. section 3.2) and RESTful bindings (cf. section 3.3), which we use for implementing ubiquitous FCLs.

Feedback Control Loops for Autonomic Computing

The Autonomic computing enables the development of applications that exhibit properties such as self-configuration, self-optimization, self-healing and self-optimization [START_REF] Hariri | The Autonomic Computing Paradigm[END_REF][START_REF] Parashar | Autonomic Computing: An Overview[END_REF]. These properties are generally achieved by means of the MAPE-K model, which is composed by the followings phases: i) Monitoring phase to collect, aggregate, and filter events from a managed resource, ii) Analysis phase that consist in the processing of the information recollected in the previous step, iii) Planning phase that defines the actions needed to achieve goals and objectives determined in the analysis, and iv) Execution phase for executing the plan determined in the previous step and using the adaptability capabilities of the system. All the different phases share the Knowledge base that includes historical logs, configuration information, metrics and policies.

The Service Component Architecture (SCA)

The Service Component Architecture [START_REF] Beisiegel | Service Component Architecture[END_REF] is asetofspecificationsforbuildingdistributed application based on SOA and Component-Based Software Engineering (CBSE) principles. In SCA, the basic construction blocks are the software components,w h i c hh a v eservices (or provided interfaces), references (or required interfaces) and expose properties. The references and services are connected by means of wires.S C As p e c i fi e sah i e r a r c h i c a lc o m p o n e n tm od e l .T h i sm e a n st h a t components can be implemented either by primitive language entities or by subcomponents. In the latter case the components are called composites.

SCA is designed to be independent from programming languages, Interface Definition Languages (IDLs), communication protocols and non-functional properties. In this way an SCA-based application can be built, for example, using components in Java, PHP and COBOL. Furthermore, several IDLs are supported, such as WSDL and Java Interfaces. In order to support interaction via different communication protocols, SCA provides the notion of binding.F orSCA references, bindings describe the access mechanism used to call a service. In the case of services, the bindings describe the access mechanism that clients have to use to invoke the service. Finally, an SCA component may be associated with policy sets or intents that declare the set of non-functional services that it depends upon. The SCA specification includes security and transactions policies [START_REF]SOA: SCA Transaction Policy[END_REF], but the model may be extended with new ones if required.

The FraSCAti Platform. This platform [START_REF] Seinturier | Reconfigurable sca applications with the frascati platform[END_REF] allows the development and execution of SCA based distributed applications. The platform itself is built as an SCA application, i.e.,i t sd i ff e r e n ts u b s y s t e m sa r ei m p l e m e n t e da sS C Ac o m p o n e n t s . FraSCAti extends the SCA component model to add reflective capabilities in the application level as well as in the platform. Furthermore, the platform applies interception techniques for extending SCA components with non-functional services, such as confidentiality, integrity and authentication.

REpresentational State Transfer (REST)

REST [START_REF] Fielding | Architectural Styles and the Design of Network-based Software Architectures[END_REF] is an architectural style to define distributed applications. Typically, REST defines the principles for encoding (content types ), addressing (nouns)and accessing (verbs)r e s o u r c e su s i n gI nternet standards (e.g.,U R I s ,H T T P ,X M L and mime-types). Resources, which are key to REST, are addressable using a universal syntax (e.g.,aURLinHTTP)andshareauniformin terfaceforthetransfer of application states between client and server (e.g., GET/POST/PUT/DELETE in HTTP). REST resources may typically exhibit multiple typed representations using-for example-XML, JSON, YAML, or plain text documents. Therefore, the simplicity, lightness, reusability, extensibility and flexibility properties that characterized REST make it a suitable option for exchanging context information in ubiquitous environments.

RESTful Bindings

The REST bindings [START_REF] Romero | Enabling Context-Aware Web Services: A Middleware Approach for Ubiquitous Environments[END_REF] follow the REpresentational State Transfer Principles. In this way, these bindings supp ort multiple context representations (e.g.,XML,JSONandJa v aObjectSerialization)andcomm unication protocols (HTTP, XMPP, FTP, etc.). This flexibility allows us to deal with the heterogeneous context managers and context-aware applications as well as with the different capabilities of the devices that execute them. Details about the architecture of these bindings are presented in [START_REF] Romero | Enabling Context-Aware Web Services: A Middleware Approach for Ubiquitous Environments[END_REF].

Synthesis :SCAprovidesaflexibleandextensiblecomponen tmodelthatcanbe used in ubiquitous environments to deal with heterogeneity and mobility. In particular, as we present in section 5, we benefit from the protocol independence for defining ubiquitous bindings that enable spontaneous communications. Furthermore, the FraSCAti capabilities in terms of runtime adaptation for applications and the platform itself make it a good option for dealing with autonomic FCL in ubiquitous environments.

4U b i q u i t o u s F e e d b a c k C o n t r o l L o o p s

In order to face the adaptation challenge in ubiquitous environments, we propose the architecture presented in Figure 1 to implement our ubiquitous FCLs [START_REF] Romero | Enabling Context-Aware Web Services: A Middleware Approach for Ubiquitous Environments[END_REF]. We choose FCLs to support dynamic reconfigurations because they provide a clear isolation of the different steps of the adaptation process. This feature allows us to distribute the concerns in several entities and reduce the coupling between them. We give the "ubiquitous" adjective to these FCLs b ecause they have the capacity to configure themselves at execution time. This means that some parts of the loop can dynamically join and leave, such as the applications running on mobile devices in our smart home scenario. Furthermore, the low coupling between the FCL parts promotes their integration at runtime with others ubiquitous FCLs.

In our FCL (cf. Figure 1), the Controller encapsulates the functionalities required for monitoring, analyzing and planning. This means that the Controller detects the presence of new services, collects the information from the mobile devices (that join and leave the environment), processes the retrieved information and decides the required reconfigurations of the context-aware applications. These applications can be either deployed on the mobile devices or be one of the available services in the environment (e.g., Multimedia Server). Consequently, the Controller requires to dynamically locate thes e r v i c et h a to p e r a t e sr e c o n fi gurations of the context-aware applications. In particular, the mobile device and Multimedia Server enclose the execution part of our FCL. Moreover, the mobile device also hosts monitoring responsibilities since it notifies the Controller when changes in the provided context information occur (e.g.,t h eb a t t e r yl e v e l decreases or increases). Thus, the mobility of the different elements (mobile devices and services) in the FLC makes necessary the definition of ubiquitous FCL. The next section introduces the requiredb i n d i n g si nS C Ai no r d e rt od e a lw i t h this mobility.

Multimedia Server

5D i s c o v e r y o f U b i q u i t o u s S e r v i c e s

As already mentioned, one of the challenges for context-aware applications is the mobility. In this paper, we tackle this issue by defining a new type of binding for the SCA component model: ubiquitous bindings.Thesebindingsprovideasimple and lightweight mechanism for communications and promote a low coupling between the interacting entities. Furthermore, following the SCA principles, the ubiquitous bindings enable the management of the SCA service discovery in at r a n s p a r e n tw a y .T h e s ea d v a n t a g e sm a k et h eu b i q u i t o u sb i n d i n g sas u i t a b l e solution to deal with dynamicity in our ubiquitous FCL. In the rest of this section we present the design (cf. section 5.1) and implementation (cf. section 5.2) of ubiquitous bindings enabling the discovery of SCA services.

Ubiquitous Bindings

In ubiquitous environments, services constantly join and leave. For this reason, we need to provide our SCA-based FCLs with the functionality required to deal with this dynamicity. In order to introduce spontaneous interoperable communications [START_REF] Kindberg | System software for ubiquitous computing[END_REF][START_REF] Zhu | Service discovery in pervasive computing environments[END_REF] in SCA, we define the concept of ubiquitous binding. This new type of binding integrates state-of-the-art Service Discovery Protocols (SDPs) and enable the establishment of communication wires at runtime. To do that, we consider three design aspects of the SDPs [START_REF] Zhu | Service discovery in pervasive computing environments[END_REF]: i) provider invocation, ii) description and attribute definition,a n diii) provider selection.R e g a r d i n gt h e invocation, some SDPs (e.g.,U P n P[ 1 3 ] )d e fi n et h ec o m m u n i c a t i o nm e c h a n i s m . However, this mechanism is not always the most suitable. Therefore, an ubiquitous binding advertises a service provided by the SCA component as being accessible via the different SCA bindings associated with it. On the other hand, we are interested in the service description and provider selection because we need to choose the service provider accordingt ot h ec o s t u m e rr e q u i r e m e n t s .H e n c e , we benefit from the discovery protocol flexibility to define properties associated with the QoS (Quality of Service)o rQ o C( Quality of Context)a t t r i b u t e s( i n the case of context-aware applications) [START_REF] Krause | Challenges in Modelling and Using Quality of Context (QoC)[END_REF] in the service advertisements. For defining the filters allowing provider matching, we use LDAP filters [START_REF] Smith | RFC 4515 -Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters[END_REF]. Figure 2 depicts the definition of the ubiquitous bindings for services (left side) and references (right side). The Discovery Protocol is the name of the discovery protocol associated to the binding. The definition of an ubiquitous binding has the filter attribute in the client-side. This attribute specifies an LDAP filter that expresses restrictions of the required service in terms of its properties. In the server-side, the ubiquitous binding can have properties that provide additional information about the service, such as QoC attributes. Each property is described by the property element. By defining the ubiquitous bindings in this way, we can support the discovery of SCA context services via different discovery protocols and then access the services using the most suitable communication protocol according to the application needs. The lower part of Figure 2 shows examples of an ubiquitous binding with the SLP [START_REF] Guttman | Service Location Protocol, Version 2[END_REF] protocol. The precision and probabilityOfCorrection are QoC attributes [START_REF] Dey | A conceptual framework and a toolkit for supporting the rapid prototyping of context-aware applications[END_REF] that describe the context provided by the service. These attributes and the contextType properties are used in the definition of the LDAP filter in the reference. The bindings in the service side correspond to the different communication that can be used to access the context information.

Implementation of the Ubiquitous Bindings in the FraSCAti platform

We have integrated our ubiquitous bindings into the FraSCAti [START_REF] Seinturier | Reconfigurable sca applications with the frascati platform[END_REF] platform. The FraSCAti selection is motived by two main reasons: i) the reflective capabilities that it introduces in the SCA programming model to allow dynamic introspection and reconfiguration of SCA based context consumers and producers, and ii) we can run the light version of platform (FraSCAme)onthemobile devices with limited capabilities [START_REF] Romero | Enabling Context-Aware Web Services: A Middleware Approach for Ubiquitous Environments[END_REF]. Figure 3 depicts the integration of our ubiquitous bindings into FraSCAti. As it can be seen, an ubiquitous binding is composed of the Discoverer and Advertiser components. The Discoverer plays the role of a stub in a traditional FraSCAti binding [18]. In other words, a reference of the client component is connected to the Discoverer and is responsible for providing access to the remote SCA services. In addition to that, the Discoverer enables SCA components to search the required services at runtime. When the service is detected and selected, the Discoverer component provides access to it. At the server side, the Advertiser (or the skeleton in the FraSCAti terminology) publishes the services whose bindings are declared as ubiquitous. Both of them, the Discoverer and the Advertiser,a r ea s s oc i a t e dw i t has pe c i fi cd i s c o v e r yp r o t oc o l( e.g.,U P n P or SLP). The proposed architecture for these components modularizes different concerns of service discovery (i.e.,s e a r c h ,s e l e c t i o n ,a n dp r o v i d e rm o n i t o r i n g ) and introduces some optional optimizations (in the Discoverer case). In this way we foster the reuse of the different components (in particular for the selection of providers), the flexibility to use different implementations and choose the required components (not all the components are mandatory). In the following sections, we present the detailed architecture of the Discoverer and Advertiser components.

Discoverer Component. This component is associated with a specific SCA reference. In order to reduce the memory footprint, we externalize the compo- nents providing common functionality to different discoverers. In particular, different implementations of the discoverer can share the components for provider selection, the active stubs (that encapsulate the communication with the remote service) and the stub registry (that keeps a list of the stubs already instantiated).

The Discoverer Component (left side in Figure 4) has a Discoverer Orchestrator that coordinates the discovery of the requested SCA service. The Finder component sends the requests to detect the potential providers in the environment.

If the filters with attributes are supported (e.g.,S L P ) ,t h eFinder translates the LDAP filters to the protocol scheme. If the SDP does not support automatic service selection and it is needed (e.g.,U P n P ) ,t h eFinder uses a provider selector for choosing the service. When the provider is selected, the Discovery Orchestrator disables the Finder and uses the Provider Monitor for monitoring the service availability. When the service is invoked the first time, the Discovery Orchestrator verifies in the stubs registry if there is a stub for the service provider. When this happens, the Discovery Orchestrator selects the registered stub as Active Stub.

Otherwise, the Orchestrator uses the FraSCAti binding factory [START_REF] Romero | Enabling Context-Aware Web Services: A Middleware Approach for Ubiquitous Environments[END_REF] (which is used to create wires and binding in the platform) in order to instantiate and configure the Active Stub.W h e nt h ep r o v i d e rb e c o m e su n a v a i l a b l e ,t h eProvider Monitor notifies the Orchestrator that actives again the Finder and asks it to find an e wp r o v i d e r .

Advertiser Component. The Advertiser (right side in Figure 4) contains a component Promoter with the following responsibilities:

1. Advertise the available SCA services in the Service Registry. Each entry in the Service Registry contains the required information for the published service (e.g.,n a m e ,t y p e )t h a ti sr e q u i r e dt oa d v e r t i s et h es e r v i c e .T h i si nformation can be updated at runtime. 2. Listen and process search requests. 3. Notify events associated with the SCA component state. Ag i v e nS C Ac o m p o n e n tc o n t a i n so n eAdvertiser of an ubiquitous binding type. This means that all the services with a same ubiquitous binding type may be exported using the same advertiser instance.

Implementation Details. We have implemented ubiquitous bindings for SLP and UPnP. For the discovery via UPnP, we use Cyberlink for Java1 version 1.7 and for SLP the jSLP library2 .O u rR E S T f u lb i n d i n g sa r eb a s e di nt h e Comanche3 web server [START_REF] Bruneton | The Fractal component model and its support in Java[END_REF]. Both FraSCAti zand Comanche are based on the Fractal component model and use the Julia4 implementation of the Fractal runtime environment [START_REF] Bruneton | The Fractal component model and its support in Java[END_REF].

Synthesis:

The ubiquitous bindings provide a flexible and simple mechanism that allows a transparent management of mobility in our ubiquitous FCLs. These bindings leverage on the clear separation of concerns promoted by the SCA component model to avoid impact the business logic. On the other hand, the modularity of the SCA architecture of our bindings promotes their reuse and the flexibility to select the more suitable implementations of the different components.

6E m p i r i c a l V a l i d a t i o n

To evaluate the p erformance of ubiquitous bindings, we implemented the scene 1 of the smart home scenario (cf. section 2.1). We tested several configurations of the scenario using two Dell Latitude 430 laptops, with the following software and hardware configurations: 1.33 GHz processor, 2 GB of RAM, Intel Pro wireless 3945ABG card, WIndows XP SP3, Java Virtual Machine 1.6.0 14, Julia 2.5.2and FraSCAti 1.2. The mobile clients are two Nokia N800 Internet Table with 400 Mhz, 128 MB of RAM, interface WLAN 802.11 b/e/g, Linux Maemo (kernel 2.6.21), CACAOVM Java Virtual Machine 0.99.4, Julia 2.5.2a n dFraSCAti 1.2. We also evaluate the RESTful bindings using XML, JSON and the Java Object Serialization for context representations. We used the library Xerces2 Java Parser 2.9.1 5 for XML, and JSON-lib 2.2.346 to serialize the information as JSON documents. We used SCA services to simulate the home sensors and actuators. These services are always executed on the same Dell Latitude hosting the server part of the scenario. 1 summarizes the overhead observedf o rd i s c o v e r yv i at h eu b i q u i t o u s bindings. This time includes the discovery, instantiation, and configuration of the SCA wires. The given measures are the average of 10.000 successful tests, of which the first 100 were considered as part of the warm-up. We have reduced the UPnP execution time avoiding the recovery of the service description file. We do not need this file b ecause the advertisement messages already contain the properties required to select the provider. Regarding the discovery cost, we observe that it is possible to integrate the ubiquitous bindings in the feedback control loops with a reasonable overhead (68ms per message). We also notice that the network increments the discovery latency approximately 25%, comparing the tests with a local provider (configuration a)a n dt h el a p t o pa sp r o v i d e r (configuration b). Although the measures with mobile devices (configuration c, d and e)d e m o n s t r a t et h a tw ec a nd i s c o v e r yservices in a rational time, their use as providers considerably increase the discovery latency. This additional cost is mainly due to the limited processing capacity of these devices. As expected, SLP is more efficient than UPnP, as it is a higher-level protocol.

Table 1 also rep orts the costs of interactions once the services are discovered in the feedback control loop. In these tests, we use our RESTful bindings (cf. section 3.3) and three different representations for information retrieval (Java Object Serialization, JSON and XML) for the communication. As it can be seen, the exchange the information costs 244ms per message (configuration a). In the case of configurations including the mobile device (c, d and e), we again observe the additional overhead.

7R e l a t e d W o r k

In this section we present some works thatd e a lw i t hs e r v i c ed i s c o v e r yi nu b i quitous environments. INDISS [START_REF] Bromberg | Indiss: interoperable discovery system for networked services[END_REF] (INteroperable DIscovery System for network Services)i sas y s t e mb a s e do ne v e n t -b a s e dp a r s i n gt e c h n i q u e st op r o v i d ef u l l service discovery interoperability. The authors claim that this interoperability is achieved without altering existing applications and services. INDISS exploits the multicast groups used by different discovered protocols to detect the protocols being used in the environment. Then, INDISS transforms the SDP messages to events that will be transformed again into messages that correspond to the SDP supported by the client application. Although interoperability between discovery protocols is an interesting solution for the mobility problem, the applications have yet to use always the same communication protocols defined by the SDP even if it is not suitable. Our SCA-based solution provides the required flexibility for client (resp. server) applications cansearch(resp.advertiser)therequired (resp. provided) services using the more suitable discovery and interaction protocols. In this way, the devices only deploy the required functionality.

In [START_REF] Flores-Cortés | A multi-protocol framework for ad-hoc service discovery[END_REF], authors propose a framework for the development of an adaptive multi-personality service discovery middleware, which operate in fixed and adhoc networks. According to authors, the framework promotes component re-use and simplifies configuration and dynamic reconfiguration of multiple concurrent protocols. With our ubiquitous bindings we also foster re-use and dynamic reconfiguration capabilities thanks to the combination of the SCA component model and the FraSCAti platform.

ReMMoC (Reflective Middleware for Mobile Computing) [START_REF] Grace | A reflective framework for discovery and interaction in heterogeneous mobile environments[END_REF] is an adaptive middleware for discovery and access of services in mobile clients. According to authors, ReMMoC reconfigures itself to use the current discovery protocols present in the environment. Furthermoret h em i d d l e w a r ei n t e r o p e r a t ew i t hs e rvices implemented upon different interaction types. Although in our approach we do not deal with the adaptation issue in the communication level, by using the reconfigurability capabilities offered by FraSCAti and our ubiquitous feedback control loops, we could identify situations where new discovery or interaction bindings are required and deploy them on the clients. Furthermore, the integration of ubiquitous bindings in SCA promotes the use of these bindings in any SCA application not only mobile clients.

8C o n c l u s i o n s a n d P e r s p e c t i v e s

In order to deal with the mobility issue in ubiquitous environments, we have enabled spontaneous communications in the SCA-based applications. To do it, in this paper, we define ubiquitous bindings, a new kind of binding for the SCA standard that allows the integration at runtime of service providers and consumers. Our ubiquitous bindings advertise and discover services via different discovery protocols and select them applying LDAP filters. The flexibility of the ubiquitous bindings allows the service access using the SCA traditional bindings associated with the services. Furthermore, the design of the ubiquitous bindings is based on SCA to enable their integration in any SCA runtime platform. By benefiting from SCA extensibility and its clear separation of concerns, we integrate in applications discovery management in a transparent way. Thus, the originality of our solution rests on its simplicity and efficiency achieved by the combination of well defined and accepted standards and protocols.

To illustrate the use of ubiquitous bindings, we define ubiquitous FCLs enabling adaptation of context-aware applications. The exchange of context information in these FCLs is achieved via RESTful bindings that allow us to face heterogeneity in ubiquitous environments. The ubiquitous bindings have been integrated into the FraSCAti platform, following an architecture that promotes the sharing of common functionality of service discovery. The suitability of our ubiquitous bindings was confirmed with tests executed using a smart home scenario.

Future work includes further tests using different kinds of mobile devices, protocols and service providers. In the particular case of ubiquitous FCLs, we plan to improve the performance of our solution by introducing a cache mechanism that enables the temporal storing of the retrieved context information. In this way, when all the required information is gathered, it can be processed even if any of the context providers is not available (or the connection was lost). Finally, we will exploit the introspection and reconfiguration capabilities brought into SCA by the FraSCAti platform in order to instrument the adaptation process in the mobile devices via our RESTful bindings.

Fig. 1 .

 1 Fig. 1. Ubiquitous Feedback Control Loop for the smart home scenario.

Fig. 2 .

 2 Fig. 2. SCA definition of the ubiquitous bindings.

Fig. 3 .

 3 Fig. 3. Integration of ubiquitous bindings into FraSCAti.

Fig. 4 .

 4 Fig. 4. Discoverer and Advertiser Architecture.

Table 1 .

 1 Performances of RESTful bindings

			Discovery Latency	Retrieval Latency
			SLP (ms)	UPnP (ms)	Object (ms)	JSON (ms)	XML (ms)
	a) 1 Local Providers	N/A	68	73	244	304	315
			91	111	292	252	261
			216	284	513	817	818
			507	547	576	839	845
			736	769	641	989	1046
	Table

Cyberlink for Java: http://cgupnpjava.sourceforge.net/

jSLP: http://jslp.sourceforge.net/

Comanche web server: http://fractal.ow2.org/tutorials/comanche.html

Julia: http://fractal.ow2.org/julia

Xerces2 Java Parser: http://xerces.apache.org/xerces2-j/

JSON-lib: http://json-lib.sourceforge.net


Daniel Romero

Gabriel Hermosillo

Amirhosein Taherkordi

Russel Nzekwa

Romain Rouvoy

Frank Eliassen

RESTful Integration of Heterogeneous Devices in Pervasive Environments

More and more home devices are equipped with advanced computational capabilities to improve the user satisfaction (e.g., programmable heating system, Internet TV). Although these devices exhibit communication capabilities, their integration into a larger home monitoring system remains a challenging task, partly due to the strong heterogeneity of technologies and protocols. In this paper, we therefore propose to reconsider the architecture of home monitoring systems by focusing on data and events that are produced and triggered by home devices. In particular, our middleware platform, named DIGIHOME, applies i) the REST (REpresentational State Transfer) architectural style to leverage on the integration of multi-scale systems-of-systems (from Wireless Sensor Networks to the Internet) and ii) a CEP (Complex Event Processing) engine to collect information from heterogeneous sources and detect application-specific situations. The benefits of the DIGIHOME platform are demonstrated on smart home scenarios covering home automation, emergency detection, and energy saving situations.

Introduction

Pervasive environments support context-aware applications that adapt their behavior by reasoning dynamically over the user and the surrounding information. This contextual information generally comes from diverse and heterogeneous sources, such as physical devices, Wireless Sensors Networks (WSNs), and smartphones. In order to exploit the information provided by these sources, an integration middleware is required to collect, process, and distribute the contextual information efficiently. However, the heterogeneity of systems in terms of technology capabilities and communication protocols, the mobility of the different interacting entities and the identification of adaptation situations makes this integration difficult. Thus, we need to provide a flexible solution in terms of communication and context processing to leverage context-aware applications on the integration of heterogeneous context providers.

In particular, a solution dealing with context information and control environments must be able to connect with a wide range of device types. However, the resource scarceness in WSNs and mobile devices makes the development of such a solution very challenging. In this paper, we propose the DIGIHOME platform, a simple but efficient middleware solution to facilitate context-awareness in pervasive environments. Specifically, DIGIHOME provides support for the integration, processing and adaptation of the context-aware applications. Our solution enables the integration of heterogeneous computational entities by relying on the REST (REpresentational State Transfer) principles [START_REF] Roy | Architectural Styles and the Design of Network-based Software Architectures[END_REF], standard discovery and communication protocols, and resource representation formats. We believe that the REST concepts of simplicity (in terms of interaction protocols) and flexibility (regarding the supported representation formats) make it a suitable architecture style for integration in pervasive environments. Furthermore, while our solution also benefits from WSNs to operate simple event reasoning on the sensor nodes, we rely on Complex Event Processing [START_REF] David | The Power of Events: An Introduction to Complex Event Processing in Distributed Enterprise Systems[END_REF] for analyzing in real-time the relationships between the different collected events and trigger rule-based adaptations.

The rest of this paper is organized as follows. We start by describing a smart home scenario in which we identify the key challenges in pervasive environments that motivate this work (cf. section 2). We continue by the description of DIGIHOME, our middleware platform to support the integration of systems-of-systems in pervasive environments (cf. section 3). Then, we discuss the benefits of our approach (cf. section 4) before discussing the related work (cf. section 5). Finally, we conclude by presenting some promising perspectives for this work (cf. section 6).

Background and Motivations

This section introduces the application and architectural foundations of our work in sections 2.1 and 2.3, respectively.

Motivating Scenario

A smart home generally refers to a house environment equipped with several types of computing entities, such as sensors, which collect physical information (temperature, movement detection, noise level, light, etc.), and actuators, which change the state of the environment. In this scenario, we consider a smart home equipped with occupancy, smoke detection, and temperature sensors. These tiny devices have the ability of collecting context information and communicating wirelessly with each other, in order to identify the context situation of the environment. In addition to that, we can also find actuators to physically control lights, TV, and air conditioning. Figure 1 illustrates the integration of these sensors and actuators in our scenario. As appreciated in this figure, the different entities use heterogenous protocols to interact. In the scenario, the smart phones provide information about user preferences for home configuration. Conflicts between the user preferences are resolved by giving priority to the person who arrived first to the room. The mobile devices also have an application that enables the control of the actuators present in the different rooms. This application can be adapted when there are changes in the actuator's configuration. Finally, there is a Set-Top Box (STB) which is able to gather information, and interact with the other co-located devices. ?-@-,1 M(+'<4&#$'(-@'3<"0 !"#3&#'< Fig. 1. Interactions between the smart home devices.

Situation 1: Alice arrives to the living room. The occupancy sensor detects her presence and triggers the temperature sensors to decrease the sampling rate of data. It also notifies the STB that the room is occupied by somebody, which in turn tries to identify the occupant by looking for a profile in her mobile device. When Alice's profile is found, the STB loads it and adjusts the temperature and lightening level of the room according to Alice's preferences.

Situation 2:

The sensors detect smoke and notify the STB, which using the occupancy sensor, detects that the house is empty. The STB therefore notifies Alice via an SMS, and includes a picture of the room, captured using the surveillance camera. After checking the picture, Alice decides to remotely trigger the sprinklers using her mobile device. She also tells the system to alert the fire department about the problem. If Alice does not reply to the STB within 5 minutes, the system activates automatically the sprinklers and alerts the fire department. Situation 3: Alice installs a new TV in the bedroom. The STB detects the presence of the new device, identifies it, and downloads the corresponding control software from an Internet repository. The platform tries to locate the available mobile devices and finds Alice's mobile device. The STB propose to update the mobile device with the components for controlling the new TV.

Key Challenges

The above described situations allow us to identify several key challenges in terms of:

1. Integration of multi-scale entities: The mobiles devices and sensors have different hardware and software capabilities, which make some devices more powerful than others. Therefore, this heterogeneity requires a flexible and simple solution that supports multiple interaction mechanisms and considers the restricted capabilities of some devices. In particular, regarding sensor nodes, the immaturity of high-level communication protocols, as well as the inherent resource scarceness, bring two critical challenges to our work: 1) how to connect sensor nodes to mobile devices and actuators through a standard high-level communication protocol, and 2) the framework which runs over sensor nodes for supporting context-awareness and adaptation should not impose high resource demands. 2. Entities mobility: In our scenario, computational entities appear and disappear constantly. In particular, mobile devices providing user profiles are not always accessible (they can be turned off or the owner can leave the house with them). In a similar way, the actuators can be replaced or new ones can be added. Thus, we need to provide the functionality to discover new entities dynamically and to support device disconnections.

Information processing and adaptation:

In order to support adaptation, we first need to identify the situations in which the adaptation is required. We have a lot of information that is generated by the different devices in the environment and we need to define which part of this information is useful in order to identify relevant situations and react accordingly. In our scenario, those situations include the load of Alice's profile and the adjustment of the temperature, the sending of an alert via SMS in case of an emergency, and the adaptation of Alice's mobile device to control the new TV in her bedroom.

REST: REpresentational State Transfer

REpresentational State Transfer (REST) is a resource-oriented software architecture style identified by R. Fielding for building Internet-scale distributed applications [START_REF] Roy | Architectural Styles and the Design of Network-based Software Architectures[END_REF].

Typically, the REST triangle defines the principles for encoding (content types), addressing (nouns), and accessing (verbs) a collection of resources using Internet standards. Resources, which are central to REST, are uniquely addressable using a universal syntax (e.g., a URL in HTTP) and share a uniform interface for the transfer of application states between client and server (e.g., GET/POST/PUT/DELETE in HTTP). REST resources may typically exhibit multiple typed representations usingfor example-XML, JSON, YAML, or plain text documents. Thus, RESTful systems are loosely-coupled systems which follow these principles to exchange application states as resource representations. This kind of stateless interactions improves the resources consumption and the scalability of the system. According to R. Fielding [START_REF] Roy | Architectural Styles and the Design of Network-based Software Architectures[END_REF],

"REST's client-server separation of concerns simplifies component implementation, reduces the complexity of connector semantics, improves the effectiveness of performance tuning, and increases the scalability of pure server components. Layered system constraints allow intermediaries-proxies, gateways, and firewalls-to be introduced at various points in the communication without changing the interfaces between components, thus allowing them to assist in communication translation or improve performance via large-scale, shared caching. REST enables intermediate processing by constraining messages to be self-descriptive: interaction is stateless between requests, standard methods and media types are used to indicate semantics and exchange information, and responses explicitly indicate cacheability."

Synthesis. REST identifies an efficient architectural style for disseminating resources, which can be encoded under various representations. Therefore, we believe that REST provides a suitable framework for mediating and processing context information in an efficient and scalable manner.

The DIGIHOME Platform

In order to address the challenges introduced in section 2.2, we propose the DIGIHOME middleware platform for pervasive environments. The main objective of DIGIHOME is to provide a comprehensive and simple solution for dealing with context processing in this kind of environments. To do that, the platform offers services for integration of context information and the detection of adaptation situations based on this information. DIGIHOME also benefits from the WSNs capabilities to process simple events and make local decisions when possible. With DIGIHOME, we can support variants of the platform for resource-constrained devices (sensor nodes or mobile devices in our scenario) that interact with powerful variants running on more powerful devices (e.g., the STB in the smart scenario).

Figure 2 depicts the general architecture of DIGIHOME. In this architecture, the Event Collector retrieves and stores the recent information produced by context collectors, such as mobile devices or sensors. The CEP Engine is responsible for event processing and uses the Decision Executor to perform actions specified by the Adaptation Rules. In DIGIHOME, the integration of the heterogenous entities is achieved via the RESTful Communication middleware framework that provides software connectors following the REST principles. In the rest of this section, we give more details about the integration of the information via REST (cf. section 3.1), the complex event processing (cf. section 3.2) and the distribution of DIGIHOME platforms in WSNs (cf. section 3.3). Finally, section 3.4 reports optimizations that are applied to the platform in order to control the reactivity and the stability of the system.

RESTful Communication Middleware

The integration challenge identified in section 2.2 requires a flexible infrastructure enabling communication and discovery between all the participants (i.e., mobile devices, sensor nodes, actuators, and the set-top box). To address this issue, we classify the heterogeneity in terms of resources and different interaction mechanisms. This communication middleware that we define in DIGIHOME therefore follows the REST principles. The simplicity, lightness, reusability, extensibility, and flexibility properties that characterize REST make it a suitable option for context dissemination in pervasive environments. The DIGIHOME communication middleware defines ubiquitous connectors encapsulating the distribution concerns. Software connectors [START_REF] Crnkovic | Building Reliable Component-Based Software Systems[END_REF][START_REF] Taylor | Software Architecture: Foundations, Theory, and Practice[END_REF] isolate interactions between components-i.e., they support the transfer of control and data. The connectors can also provide non-functional services, such as persistency, messaging, and invocation helping to keep the component functionality focused on the domain specific concerns. In this way, the connectors foster the separation of concerns [START_REF] Taylor | Software Architecture: Foundations, Theory, and Practice[END_REF]. In the context of DIGIHOME, software connectors do not impact the event processing and support multiple implementations of the communication mechanism. Figure 2 depicts several examples of connectors for supporting protocols such as ZigBee [START_REF]Zigbee Protocol[END_REF], SOAP, and ACN [START_REF]Architecture for Control Networks (ACN)[END_REF]. For purposes of our scenario, we choose HTTP as the default interaction protocol for the middleware platform and the mobile devices. The choice of HTTP is motivated by its simplicity and the possibility to have mobile devices not only as consumer but also as service providers [START_REF]Mobile Web Server[END_REF][START_REF]OSGi-The Dynamic Module System for Java[END_REF][START_REF]HTTP Server Project[END_REF]. Our RESTful communication middleware supports additional protocols, such as XMPP [START_REF] Saint-Andre | RFC 3920 -Extensible Messaging and Presence Protocol (XMPP): Core[END_REF] and Twitter [START_REF] Makice | Twitter API: Up and Running Learn How to Build Applications with the Twitter API[END_REF] that can be more suitable in other situations.

The connectors also support spontaneous interoperability [START_REF] Kindberg | System software for ubiquitous computing[END_REF] to deal with the volatility of pervasive environments. As already mentioned in section 2, mobile devices, sensors, and actuators can continuously appear or disappear from the landscape. Therefore, the DIGIHOME connectors deal with this volatility by means of standard discovery protocols. By exploiting the extension capabilities of these discovery protocols, we can, for example, improve the context information advertisements with Quality of Context (QoC) [START_REF] Krause | Challenges in Modelling and Using Quality of Context (QoC)[END_REF] attributes for provider selection purposes. In particular, in our scenario we use UPnP [START_REF][END_REF] to discover mobile devices and actuators. We have selected this protocol as several available electronics devices already support UPnP. Furthermore, although UPnP is an XML-based protocol, its application in WSNs does not impact the energy consumption because we do not need to process XML descriptions in sensor nodes (this is the responsibility of CEP Engine in DIGIHOME), just provide them.

Complex Event Processing

Complex Event Processing (CEP) is a technology for detecting relationships, in realtime, between series of simple and independent events from different sources, using predefined rules [START_REF] Wang | Research and Design of RFID Data Processing Model Based on Complex Event Processing[END_REF]. In our scenario, we consider a lot of heterogeneous devices (sensors, mobile devices, etc.) that generate isolated events, which can be used to obtain valuable information and to make decisions accordingly. We can see some examples of this in the scenario, like activating the sprinklers in case of detecting a fire or like updating the mobile device in order to control the new TV.

To manage those events, we need a decision-making engine that can process them and that can create relations to identify special situations, using predefined rules. In order to identify the desired events, the CEP Engine requires to communicate with an Event Collector, which is in charge of dealing with the subscriptions to the event sources. When an adaptation situation is detected, a corresponding action is triggered, which can go from an instruction to an actuator, to the adaptation of the system by adding or removing functionality. These actions are received by the Decision Executor, which has the responsibility of communicating with the different actuators in the environment.

In DIGIHOME, for the event processing in the set-top box, we use ESPER [START_REF] Espertech | [END_REF], a java open source stream event processing engine, to deal with the event management and decision making process. We chose ESPER for our platform because is the most supported open source project for CEP and is very stable, efficient, and fairly easy to use. The following code excerpt shows an example of an ESPER rule: s e l e c t sum ( movement ) from Mo v em en tSen so r Ev en t . win : t i m e ( 6 0 s e c ) This is a rule related to the scenario presented in section 2.1. Here we can see the use of a time window, which is a moving interval of time. The rule collects all the events from the movement sensor from the last 60 seconds.

Support for Wireless Sensor Networks

In DIGIHOME, there are two scopes for event processing: local event processing, and global event processing. To improve the efficiency of the system, the sensor nodes in our configuration can be considered as sensor networks in order to avoid assigning local decisions to the STB, responsible for global concerns. Specifically, the event generated by a sensor node may be of interest to a node within the sensor network. Therefore, instead of going through the centralized server framework for making decisions, the WSN itself takes the responsibility of processing events in a more efficient way. The architecture of DIGIHOME in sensor nodes supports both local event processing and global event forwarding. The latter delegates the decision of global event processing to the STB. In the former case, the layered framework on the sensor node has the ability to connect directly to other sensor nodes in the environment and to deliver an event to the nodes subscribed to that type of event. Furthermore, the framework provides a lightweight mechanism for event processing in order to keep resource usage at a very low level. The execution layer also benefits from our unified communication protocol to send the configuration and adaptation instructions across the WSN. The event manager layer of our framework enables in-WSN decisions, whenever an event should be processed with other relevant events generated by other sensor nodes. As an example, when a temperature sensor senses a high degree, for deducing on fire detection, it needs to become aware of the smoke density in the room. Thus, the collaboration at network management layer becomes an essential need.

Platform Optimizations

Stabilization Algorithms. When system events are gathered from different sensors, they are forwarded to the CEP Engine, which analyses them before deciding which actions should the system perform. This decision-making task is often a costly procedure for the system and thus requires optimization techniques in order to optimize this task. One of these technics can consist in stabilizing the data flow, for example between the Event Collector and the CEP Engine. The role of the stabilization mechanism is therefore to filter events, preventing useless triggering of the decision-making task.

In [START_REF] Nzekwa | Towards a Stable Decision-Making Middleware for Very-Large-Scale Self-Adaptive Systems[END_REF], stabilization mechanisms are defined as algorithms and techniques that operate the system reconfigurations or adaptations only when relevant changes occur. In the smart home scenario (cf. section 2.1) the stabilization mechanism can be useful at several levels of our architecture. Typically, we can aggregate context information (e.g., the user's preferences) or compute the average of some data (e.g., the temperature). We also have the possibility of introducing stabilization mechanisms between the CEP Engine and the Decision Executor in order to avoid the recurrent triggering of unnecessary adaptations (cf. Figure 2).

Concerning the implementation of the stabilization mechanisms in our framework, we use the flexible approach proposed in [START_REF] Nzekwa | A Flexible Context Stabilization Approach for Self-Adaptive Application[END_REF]. This approach suggests a composition model, which consists of two modalities: horizontal composition and vertical composition. Horizontal composition consists in executing several stabilization algorithms concurrently, while the vertical composition refers to the sequential application of two or more algorithms on the same data sample.

Web Intermediaries. REST enables Web Intermediaries (WBI) to exploit the requests exchanged by the participants in the communication process. WBI are computational entities that are positioned between interacting entities on a network to tailor, customize, personalize, or enhance data as they flow along the stream [START_REF]Web Intermediaries[END_REF]. Therefore, we can benefit from this opportunity to improve the performance of DIGIHOME. When the provided context information does not change much in time, the messages containing this information can be marked as cacheable within the communication protocol. This kind of annotation enables WBI caches to quickly analyze and intercept context requests always returning the same document. A similar optimization applies to security issues and the filtering of context requests. Indeed, by using proxy servers as WBI, we can control the requested context resources and decide whether the incoming (or outgoing) context requests need to be propagated to the web server publishing the context resource. Other kinds of WBI can also be integrated in the system to operate, for example, resource transcoding, enrichment, or encryption.

Empirical Validation

Although the contribution of this paper lies in the adoption of a versatile architecture style for integrating the diversity of device appliances available in the pervasive environments, we have also made a performance evaluation of a prototype, implementing the proposed platform. This experimentation demonstrates the reasonable overhead imposed by the DIGIHOME platform.

Implementation Details

We built a prototype of the DIGIHOME platform based on the FRACTAL component model and we used the JULIA3 implementation of the FRACTAL runtime environment [START_REF] Bruneton | The FRACTAL component model and its support in Java. Software: Practice and Experience -Special issue on Experiences with Auto-adaptive and Reconfigurable Systems[END_REF]. In order to test our system, we measured the communication and discovery overheads using our RESTful approach as well as the event processing cost when using ESPER. To obtain these results, we have implemented the scene 1 of the smart home scenario (described in section 2.1).

Discovery and Communication Overhead

Table 1 reports the average latency for the context dissemination via REST. In this setup, we retrieve the user preferences from multiple providers (Nokia N800 Internet Tables and MacBook Pro) and use multiple formats for the context information (i.e., XML, JSON, and Java Object Serialization). To do that, we have installed a lightweight version of the DIGIHOME platform that includes only the RESTful Communication Middleware as well as the Event Collector. We also measured the delay for discovering the information provided by the sources. For discovery, we selected the UPnP and SLP [START_REF] Guttman | Service Location Protocol, Version 2[END_REF] protocols. In the tests, the platform aggregates the user's preferences to reduce the number of messages exchanged between the provider and the consumer. The measured time corresponds to exchange of REST messages as well as the marshalling/unmarshalling of the information. The cost of executing others protocols, such as ACN and ZigBee was not considered in this paper. The reader can find more information about the overhead introduced by these protocols in [START_REF] Eliassen | ZigBee and Wireless Radio Frequency Coexistence[END_REF]. Furthermore, in this experimentation, the preferences retrieval from mobile devices via XML was not possible due to a limitation of the Java Virtual Machines used on the mobile device (CACAOVM & JamVM). Nevertheless, this is not a problem for our approach since several representations are available for the same preference. A;8A: @:-@:,899 @;A EE8-; 7987@ C>('3456 F(G('3456 BC.+'3456 D!>'3456

Table 1. Performance of the RESTful connectors.

Event Processing Overhead

The time for context dissemination as well as for discovery confirms that DIGIHOME can integrate heterogeneous entities with a reasonable performance overhead. Furthermore, according to the documentation provided by ESPER [START_REF] Espertech | [END_REF], the efficiency of the engine to process the events is such that it exceeds over 500,000 events per second on a workstation and between 70,000 and 200,000 events per second running on an average laptop. The efficiency of the engine makes that the use of event processing in our system can be done at a low cost and given the modularity of our architecture, the ESPER engine can be installed in the device that provides the highest processing power. In the context of the DIGIHOME platform, we observed that ESPER took 1ms on average to process the adaptation rules.

5 Related Work

Context Dissemination

In literature, it is possible to find two kinds of solutions to deal with context integration: centralized and decentralized. In the centralized category we can find middleware, such as PACE [START_REF] Henricksen | Middleware for Distributed Context-Aware Systems[END_REF] and Context Distribution and Reasoning (ConDoR) [START_REF] Paganelli | A Context Model for Context-Aware System Design Towards the Ambient Intelligence Vision: Experiences in the eTourism Domain[END_REF]. PACE proposes a centralized context management system based on repositories. The contextaware clients can interact with the repositories using protocols, such as Java RMI or HTTP. For its part, ConDoR takes advantage of the object-oriented model and ontologybased models to deal with context distribution and context reasoning, respectively. In ConDoR, the integration of the information using different protocols is not considered as an important issue. The problem with this kind of approach is the introduction of a single point of failure into the architecture, which limits its applicability to ubiquitous computing environments.

On the other hand, in decentralized approaches we can find solutions like COR-TEX [START_REF] Sorensen | A context-aware middleware for applications in mobile Ad Hoc environments[END_REF] and MUSIC [START_REF] Hu | A Peer-to-Peer based infrastructure for Context Distribution in Mobile and Ubiquitous Environments[END_REF][START_REF] Kirsch-Pinheiro | Context Grouping Mechanism for Context Distribution in Ubiquitous Environments[END_REF]. CORTEX defines sentient objects as autonomous entities that have the capacity of retrieving, processing, and sharing context information using HTTP and SOAP. MUSIC middleware is another decentralized solution that proposes a peer-to-peer infrastructure dealing with context mediation. The decentralized approaches face the problem of fault tolerance by distributing the information across several machines. However, as well as some centralized solutions, the lack of flexibility in terms of the communication protocols remains a key limitation for these approaches.

In addition to that, peer-to-peer approaches have performance and security problems. In DIGIHOME, we provide a decentralized solution, where the different interacting devices can process the events retrieved from the environment. Furthermore, in DIGIHOME we provide flexibility in terms the interaction by supporting different kinds of communication protocols and we also allow spontaneous interoperability.

Complex Event Processing

Given the increasing interest to integrate the flow of data into the existing systems, CEP has gained some attention as it can help to provide that integration transforming isolated data into valuable information. In this context we can find some works similar to ours in [START_REF] Churcher | Applying and extending sensor web enablement to a telecare sensor network architecture[END_REF] and [START_REF] Wang | Complex event processing in epc sensor network middleware for both rfid and wsn[END_REF]. In [START_REF] Churcher | Applying and extending sensor web enablement to a telecare sensor network architecture[END_REF], the authors integrate CEP into their existing project called SAPHE (Smart and Aware Pervasive Healthcare), and also use ESPER as their CEP engine. As the project name shows, the project is applied to healthcare and use sensors to monitor a patient's activity and vital signs. They use CEP to correlate and analyze the sensor data in order to calculate critical factors of the patient locally in their set-top box, without having to send all the events to an external server. In their approach they lack a way to discover new services and they never mention how, if possible, would they interact with actuators in order to adapt to the context and respond to a specific situation.

An Event-Driven Architecture (EDA) that combines the advantages of WSN with CEP is presented in [START_REF] Wang | Complex event processing in epc sensor network middleware for both rfid and wsn[END_REF]. They use an extension of the RFID EPCglobal architecture which allows the interaction of RFID and WSN events. Once the events are collected, they use CEP to detect specific situations. They use a smart shelf application as their scenario to show how the events from both sources can be combined. Even though both technologies seem to interact in their project, their specification is somehow limited because they do not specify how the information obtained could be used, other than generating a report that will be logged in the EPCIS server.

Wireless Sensor Networks

In [START_REF] Tilak | Dynamic Resource Discovery for Wireless Sensor Networks[END_REF], the authors describe a WSN-specialized resource discovery protocol, called DRD. In this approach, each node sends a binary XML description to another node that has the role of Cluster Head (CH). The CH is selected among all the nodes based on their remaining energy. Therefore, it is necessary to give all the nodes the capacity of being a CH. Consequently, all nodes need an SQLlite database, libxml2 and a binary XML parser in order to implement the CH functionalities. In DIGIHOME, with our modular architecture, we consider the resource constraint of sensors nodes and provide a lightweight version of the platform that delegates complex processing to more powerful devices. Therefore, not all the nodes have to be CH. Furthermore we benefit from the advertisement capacities of sensor nodes to identify adaptation situations.

In CoBIs [START_REF]Cobis. fp strep project ist 004270[END_REF], business applications are able to access functionalities provided by the sensor nodes via web services. The major aim of the CoBIs middleware is to mediate service requests between the application layer and the device layer. The focus lies thereby on deployment and discovery of required services. AGIMONE [START_REF] Hackmann | Agimone: Middleware support for seamless integration of sensor and ip networks[END_REF] is a middleware solution supporting the integration of WSNs and IP networks. It focuses on the distribution and coordination of WSN applications across WSN boundaries. AGIMONE integrates the AGILLA [START_REF] Fok | Mobile agent middleware for sensor networks: An application case study[END_REF] and LIMONE [START_REF] Fok | A lightweight coordination middleware for mobile computing[END_REF] middleware platforms. AGIMONE is a general-purpose middleware with a uniform programming model for applications, that integrates multiple WSNs and the IP network. In our approach, we also promote the integration of sensor nodes via software connectors. Moreover, we enable spontaneous communications with some sensor nodes that execute a lightweight version of DIGIHOME.

Enterprise Service Bus

Enterprise Service Bus (ESB) is an architectural style that leverages on the integration of business infrastructures. In particular, platforms conforming to the Java Business Integration (JBI) specification [START_REF] Vinoski | Java Business Integration[END_REF] define the concept of Binding Component to deal with the heterogeneity of communication standards by exposing the integrated services as WSDL interfaces. The DIGIHOME platform rather exploits the concept of software connector to expose the information available in the surrounding environment as REST resources. This data orientation leverages on the integration of smart home devices and contributes to the reactivity of the system by introducing a reasonable overhead compared to more traditional RPC-based protocols.

Conclusions and Future Work

In this paper we have presented DIGIHOME, a platform to deal with the mobility, heterogeneity, and adaptation issues in smart homes. In particular, DIGIHOME enables the integration of context information by defining intermediaries that follow REST principles and identifies adaptation situations using this information. The simplicity and data orientation promoted by REST makes it an attractive alternative solution to deal with heterogeneity in terms of interactions. The software connectors of DIGIHOME also enable spontaneous communications by supporting standard protocols (e.g., UPnP and SLP) and furnishing context provider selection (based on QoC attributes). On the other hand, the modularized architecture of DIGIHOME allows the definition of variants for the platform that can be deployed on resource-constrained devices. Furthermore, the clear separation of concerns in the DIGIHOME architecture encourages the exploitation of WSNs for simple processing and local decision making. The suitability of our platform for context integration was evaluated with different discovery and context representations.

Future work includes the integration of our platform with FraSCAti [START_REF] Seinturier | Reconfigurable sca applications with the frascati platform[END_REF], a platform conforming to the SCA specification [START_REF]Service Component Architecture Specifications[END_REF]. By integrating our approach with SCA, we foster the reuse of the different components of DIGIHOME's architecture and support the use of different technologies for the implementation of its components. Furthermore, we can benefit from FraSCAti's reconfiguration capabilities and the separation of concerns of SCA to integrate new communication and discovery protocols at runtime.

Fig. 2 .

 2 Fig. 2. Description of the DIGIHOME architecture.

!

  "#$%&'()*+,#-$*./0 !"#$%%&'()%*'!"#$%%&'()% !"#$%%&'()%*'+,--

JULIA: http://fractal.ow2.org/julia

Acknowledgement. This work is partly funded by the EGIDE Aurora and INRIA SeaS research initiatives.


Jeremy Bell

Issa Samb

Patrick Y Toullec

Olivier Mongin

Mireille Blanchard-Desce
email: mireille.blanchard-desce@u-bordeaux1.fr

Veronique Michelet
email: veronique.michelet@chimie-paristech.fr

Isabelle Leray
email: isabelle.leray@ppsm.ens-cachan.fr

Jérémy Bell

Véronique Michelet

Ultra-sensitive and selective Hg2+ chemosensors derived from substituted 8-hydroxyquinoline analogues

de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

The design of sensors for the detection of heavy-metal ions has been a field of continuing research since the control of water resources and natural environments has become a worldwide major challenge. 1 Among heavy metal ions, lead, nickel, cadmium and mercury salts specifically need to be detected, 2 the last two being classified among "priority hazardous substances", toxic, persistent and bioaccumulative chemicals. Hg 2+ ion is considered as highly toxic causing environmental and health problems. 1,2 The level of this ion is therefore subjected to strict regulations and should presently not exceed 1 µg L -1 . 2 Apart from analytical techniques (atomic absorption or emission, inductively coupled plasma spectroscopy), the methodology based on fluorescent molecular sensors has attracted considerable interest due to the superior sensing sensitivity and selectivity they offer. 3 Some examples described the use of chemodosimeter which have some drawbacks because of their irreversibility. 4 However, among fluorescent molecular sensors currently available, only a few are competitive in terms of sensitivity, selectivity, while direct measurements in aqueous medium remain a crucial issue. 5 The development of sensitive and selective fluorescent sensors is thus a subject of constant interest. In the course of our recent ongoing program directed toward the synthesis of novel fluorophores 6 and on the basis of recent work on 8-hydroxyquinoline (8-HQ) analogues, [START_REF] Zhang | For the synthesis of 8-HQ analogues and their use in the detection of mercury salts[END_REF] we designed novel sensors for the detection of Hg 2+ and wish to describe therein the synthesis, photophysical and complexing properties.

Results and discussion

Synthesis

We chose the 8-hydroxyquinoline moiety as one of the most important chelators for metal ions 8 and anticipated that the introduction of a phosphane oxide or thiophosphinate moiety would enhance the selectivity towards mercury ions. We therefore engaged in the synthesis of thiophosphinate 8-HQ-4-St-PS 4 and 8-HQ-4-St-PO 3 (Scheme 1), the arylvinylidene side chain being selected in order to shift the fluorescence emission in the visible region (as well as excitation in the near UV) for easier implementation in on-field devices.

N O N O 8HQ-CO 1 8HQ-PO 2 N O 8HQ-4St-PO 3 8HQ-4St

Scheme 1 Hydroxyquinoline fluorescent sensors

The synthesis of model 8HQ-PO 2 was straightforward starting from 8HQ in the presence of sodium hydride and diphenylphosphanoyl chloride at 0°C in THF. 9 The introduction of the donating vinylidene groups required a multistep synthesis starting from the known aldehydesubstituted 8-hydroxyquinoline 5 (Scheme 2). 10 The aldehyde 5 was phosphorylated with diphenylthiophosphanyl chloride 11 in good yield. The corresponding phosphorous derivative 6 was then engaged in a Wittig reaction in the presence of the phosphonium salt 8. 12 The Z isomer 13 8-HQ-4-St-PS 3 was isolated in 64% yield after an isomerization reaction in the presence of iodine. A similar synthesis was accomplished for the preparation of 8-HQ-4-St-PO 4 and led to the desired sensor in 38% yield over two steps.

Photophysical properties of the ligands

The absorption and fluorescence properties of the quinoline derivatives are collected in Table 1, and their absorption and emission spectra are shown in Figure 1a) and b), respectively. The fluorophores show an absorption band in the UV region. The phosphane oxide derivative and the carbonyl compound have comparable extinction coefficient. As expected the introduction of a styryl derivative on the para position of the quinoline derivative induces a noticeable red-shift of the absorption and the emission spectra due to the intramolecular charge transfer character of the transition. As previously described for the carbonyl derivatives, 7a the proximity of the phosphoryl oxygen (sulfur) lone pair to the acceptor nitrogen of the fluorophores induces a radiationless deactivation process through a 3 (n-π)* state. [a] ref 7a

Cation-induced photophysical changes:

The complexation of the phosphane oxide and the phosphane sulfide derivatives was investigated in the presence of heavy metal ions in acetonitrile. The complexation of mercury salts by the phosphane oxide derivative 8HQ-PO 2 (figure 2) was studied in acetonitrile with a ligand concentration of 22 µM upon addition of increasing aliquots of mercury perchlorates. As expected, a red shift of the absorption band from 332 nm to 380 nm occurred, confirming the role of the quinoline nitrogen atom in the coordination of the metal ion. Thereby, when using an excitation wavelength of 337 nm, an emission band appears at 490 nm and a decrease of the fluorescence is observed for the higher concentrations. The analysis of the evolution of the spectra using SPECFIT software revealed that different complexes are formed with the following different stoichiometries 1:1 and 1:2 (ML and ML 2 ). The decrease of the fluorescence intensity for larger concentration of mercury can be explained by stronger interaction between the fluorophore and the mercury and by a possible electron transfer process. The stability constants derived for the phosphane oxide derivatives and the phosphane sulfide derivatives are given on table 2. For the 8HQ-4St-PO 3, the addition of mercury induces a larger photophysical effect in relation with an efficient photoinduced intramolecular charge transfer phenomenon. The absorption band shifts from 345 nm to 410 nm in the presence of mercury. In emission direct emission of the complex at 420 nm induces the formation of a non structured band at 560 nm. For the phosphane sulfide derivative 8HQ-4St-PS 4, similar photophysical effects have been observed upon complexation of heavy metal ions. In comparison to the results obtained by Jiang's group, 7a the higher stability constants obtained here confirms that the introduction of a phosphane oxide or a phosphane sulfide function increases the ability of the probe to coordinate heavy metal ions. Because of the high affinity of the phosphane sulfide derivative for mercury, the highest complexation constant was observed for the 8HQ-4St-PS 4. It should be noticed that for the compound 3 and 4 only the 1-1 stoichiometry complex is observed because of the steric hindrance due to the incorporation of the styryl conjugated group.

Two-photon absorption

In addition to standard one-photon excitation, we also investigated the potential use of two-photon excitation (TPE) for selective excitation of the probe. There has been a lot of efforts in designing bright biphotonic fluorescent probes 14,15 in the last decade mainly driven by the advantages TPE provides for biological imaging. 16 In the field of fluorescent probes, TPE could offer an additional benefit by allowing selective excitation in the presence of fluorescent contaminants. We have investigated the TPE response of the thiophosphinate 8-HQ-4-St-PS 4 for mercury detection, expecting that only the complex would have significant TPE response in the particular spectral range of interest. This indeed proved to be the case (Figure 2a), as pure 8-HQ-4-St-PS 4 did not show detectable fluorescence when two-photon excited in the same range. Taking advantage of the large contrast between the TPE response of 8-HQ-4-St-PS 4 and of its mercury complex and of the high sensitivity and affinity for mercury of the 8-HQ-4-St-PS 4, we further demonstrated that monitoring fluorescence by two-photon excitation at optimum wavelength (typically in the 800-900 nm range) indeed allowed monitoring Hg 2+ concentration (Figure 2b).

Practical determination of mercury in water

In view of practical applications, complexation studies were then carried out in a partially aqueous medium CH 3 CN/H 2 O 40/60. Titration experiments show that 8-HQ-4St-PS 4 was able to coordinate mercury in aqueous medium (see supporting information). Analysis of the spectra revealed that under these conditions a 1:1 complex is formed with mercury with a log K 11 = 3.8 ± 0.1. In CH 3 CN:H 2 O (40 : 60 : v:v), [START_REF]For mercury detection by compound 8-HQ-4St-PS 1, we found that the proportion of water must be 60 %, plus 40 % of acetonitrile for solubility reasons[END_REF] the pKa of 8-HQ-4St-PS 4 was measured to be 3.23 ± 0.02, which is lower than the complexation constant of 8-HQ-4St-PS 4 with mercury. In addition, the quantum yield of the protonated form 4.H + being 10 fold higher than the mercury complex 4.Hg 2+ , we optimized the sensing experimental conditions (pH = 3) to exploit the replacement of a proton by mercury to ensure larger fluorescence variations, and consequently improved sensitivity (Scheme 3). 18

Scheme 3 Involved equilibrium upon complexation with Hg 2+

As previously observed, the addition of mercury induced a bathochromic shift of the absorption band, and a quenching of the fluorescence was observed in relation with the replacement of the proton by mercury (Figure 3a). Scheme 2 outlines the involved equilibrium upon complexation with mercury in these operating conditions. Taking advantage of this highly efficient quenching process, a calibration curve can be established. The measured detection limit was found to be 0.5 nanomol per liter, and the theoretical detection limit, calculated as three times the standard deviation of the background/noise ratio, was found to be 0.075 nanomol per liter (15 ppt). The selectivity of the probe was also tackled. As shown in Figure 4, no significant change of the fluorescence were observed upon addition of high concentrations of interfering cations such as Li + , Na + , Mg 2+ , K + , Ca 2+ , Mn 2+ , Fe 2+ , Co 2+ , Ni + , Cu 2+ , Zn 2+ , Ag + , Cd 2+ and Pb 2+ at 1 or 0.1 mM. Moreover, after addition of 1 equiv. of Hg 2+ , the fluorescence was still quenched immediately, indicating that the presence of other cations does not affect the sensing process and its sensitivity.

Conclusion

In conclusion, we have synthesized a series of fluorescent chemosensors based on hydroxyquinoline bearing chalcogenic phosphanes such as phosphane oxide and sulfide derivatives. This original derivative showed an intense absorption band in the near-UV region and a fluorescence emission in the visible region. The large Stokes shift value and the unresolved vibronic structure of the fluorescence spectra strongly support the intramolecular charge transfer (ICT) character of the low-energy transition, which is thus expected to be highly sensitive to complexation by a cationic species. Indeed, addition of a heavy metal cation such as Hg 2+ induced a bathochromic shift of the absorption and emission spectra thanks to the increase of electronwithdrawing character of the complexed quinoline moiety. In view of practical application, the cation complexation was studied in a mixture CH 3 CN/H 2 O under optimized pH conditions (pH=3) and the presence of mercury cations induced a major fluorescence quenching which allowed reaching a detection limit in the picomolar range (75 pM-15 ppt). This outstandingly low detection limit does therefore meets the requirements defined by the World Health Organization for drinking water. Further efforts will be dedicated to insert the fluorescent sensor in microfluidic chip.

Experimental

General informations: all reactions were performed under a dry argon atmosphere by using standard Schlenk techniques. Column chromatography was performed with E. Merck 0.040-0.063 mm Geduran silica gel. 1 H NMR, [START_REF] Lipunova | The Z stereochemistry of the isolated styryl derivatives was assigned based on J 1 H coupling constants of the alkenes and is in agreement with literature[END_REF] C NMR and 31 P NMR were recorded on Bruker AV 300 and 400 instruments. All signals were expressed as ppm (δ) and internally referenced to residual protio solvent signals. Coupling constants (J) are reported in Hz and refer to apparent peak multiplicities. Mass spectrometry analyses were performed at IMAGIF/ICSN and at the University P. et M. Curie. Compounds 5 10 and 8 11 were prepared according to published procedures. The preparation of diphenylthiophosphanyl chloride was realized according to literature. 11

Syntheses of 8-hydroxyquinoline analogues

Thiophosphinate 6. To a solution of 4-formyl-8-hydroxyquinoline 5 (300 mg, 1.7 mmol) in tetrahydrofuran (10 mL) at 0°C was added 60% w/w NaH in mineral oil (69 mg, 1.7 mmol). The resulting mixture was stirred for 15 minutes at 0°C, then diphenylthiophosphinic chloride (429 mg, 1.7 mmol) was added dropwise. The mixture was stirred 3 h at room temperature. The mixture was quenched with water and extracted with dichloromethane (2×20 mL). The organic phase was dried over MgSO 4 and the volatiles removed under vacuum. 192.6, 150.0, 147.3, 136.5, 135.2, 133.7, 132.1, 131.4 (d, J = 11.7 Hz), 129.0, 128.4 (d, J = 13.8 Hz) Thiophosphinate 4. To a solution of thiophosphinate 6 (100 mg, 0.25 mmol) and phosphonium salt 8 (154 mg, 0275 mmol) in tetrahydrofuran (1 mL) at 0°C was added 60% w/w NaH in mineral oil (20 mg, 0.50 mmol) and 18-crown-6 (13.2 mg, 0.05 mmol). The resulting mixture was stirred at room temperature for 2 hours, then quenched with water and extracted with dichloromethane (2×10 mL). The organic phase was dried over MgSO 4 and the volatiles removed under vacuum. The crude product was redissolved in dichloromethane (5 mL), a catalytic amount of iodine was added. The solution was stirred at room temperature for 3 h under light exposure then washed with saturated aqueous Na 2 S 2 O 3 and dried over MgSO 4 . The residue was purified by flash silica gel chromatography (cyclohexane/ethyl acetate 80/20 then 70/30) to give 94 mg (64%) of the product. 1 H NMR (300 MHz, CDCl 3 ): δ = 8.79 (d, 1H, J = 3Hz), 8.20-8.27 (m, 4H), 7.80 (d, 1H, J = 6.2Hz), 7.64 (d, 1H, J = 6.2Hz), 7.40-7.55 (m, 7H), 7.35-7.27 (m, 3H), 6.91 (d, 1H, J = 9Hz), 6.85 (d, 2H, J = 12.4Hz), 6.76 (d, 2H, J = 12.4Hz), 6.60 (d, 1H, J = 9Hz), 3.85 (t, 2H, J = 6.6Hz) 1.65-1.72 (m, 2H), 1.25-1.43 (m, 10H), 0.87 (t, 3H, J = 6.7Hz). [START_REF] Lipunova | The Z stereochemistry of the isolated styryl derivatives was assigned based on J 1 H coupling constants of the alkenes and is in agreement with literature[END_REF] C NMR (75 MHz, CDCl 3 ): δ = 159.8, 149. 9,147.4,144.4,135.5,133.8,131.8 (d,J = 11.4Hz),130.4,128.3 (d,J = 13.9Hz),128.0,125.6,123.2,121.4,120.1,114.1,67.9,31.8,29.3,29.2,26.0,22.6,14.1. 31 Phosphinate 7. To a solution of 4-formyl-8-hydroxyquinoline 5 (300 mg, 1.7 mmol) in tetrahydrofuran (10 mL) at 0°C was added 60% w/w NaH in mineral oil (69 mg, 1.7 mmol). The resulting mixture was stirred for 15 minutes at 0°C, then diphenylphosphinic chloride (402 g, 1.7 mmol) was added dropwise. The mixture was stirred 3 h at room temperature. The mixture was quenched with water and extracted with dichloromethane (2×20 mL). The organic phase was dried over MgSO 4 and the volatiles removed under vacuum. The residue was purified by flash silica gel chromatography (cyclohexane/ethyl acetate 80/20) to give 450 mg (71%) of the product.

1 H NMR (300 MHz, CDCl 3 ): δ = 10.49 (s, 1H), 9.27 (d, 1H, J = 4.1Hz), 8.72 (d, 1H, J = 8.7Hz), 8.06-8.14 (m, 4H), 7.92 (dt, 1H, J = 7.7Hz, J = 1.3Hz), 7.82 (d, 1H, J = 4.1Hz), 7.57 (t, 1H, J = 8.5Hz), 7.53-7.38 (m, 6H). [START_REF] Lipunova | The Z stereochemistry of the isolated styryl derivatives was assigned based on J 1 H coupling constants of the alkenes and is in agreement with literature[END_REF] C NMR (75 MHz, CDCl 3 ): = 192.6,150.3,132.5,132.1 (d,J = 10.6Hz),129.4,128.5 (d,J = 13.5Hz),126.1,120.6. 31 Spectroscopic measurements: UV/Vis absorption spectra were recorded on a Varian Cary5000 spectrophotometer and corrected emission spectra were obtained on a Jobin-Yvon Spex Fluorolog-3 spectrofluorimeter. The fluorescence quantum yields were determined by using quinine sulfate dihydrate in sulfuric acid (0.5 N;  F = 0.546 19 ) as standards. For the emission measurements, the absorbance at the excitation wavelengths were below 0.1 and so the concentrations were below 10 5 molL -1 . The complexation constants were determined by global analysis of the evolution of all absorption and/or emission spectra by using the Specfit Global Analysis System V3.0 for 32-bit Windows system. This software uses singular value decomposition and non-linear regression modelling by the Levenberg-Marquardt method. 20

δ
Two-photon excited fluorescence spectroscopy: Two-photon excited fluorescence spectroscopy was performed using a modelocked Ti:sapphire laser generating 150 fs wide pulses at a 76 MHz rate, with a time-averaged power of several hundreds of mW (Coherent Mira 900 pumped by a 5 W Verdi). The laser light is attenuated using a combination of half-wave plates and a Glan-laser polariser and the excitation power is further controlled using neutral density filters of varying optical density mounted in a computercontrolled filter wheel. After five-fold expansion through two achromatic doublets, the laser beam is focused by a microscope objective (10x, NA 0.25, Olympus, Japan) into a standard 1 cm absorption cuvette containing the sample. The applied average laser power arriving at the sample was between 0.5 and 15 mW, leading to a time-averaged light flux in the focal volume on the order of 0.1 -1 mW/µm 2 . The generated fluorescence is collected in epi-fluorescence mode, through the microscope objective, and reflected by a dichroic mirror (675dcxru, Chroma Technology Corporation, USA). Residual excitation light is removed using a barrier filter (e650-2p, Chroma) and the fluorescence is coupled into a 600 µm multimode fiber by an achromatic doublet. The fiber is connected to a compact CCD-based spectrometer (BTC112-E, B&WTek, USA), which measures the two-photon excited emission spectrum. The emission spectra are corrected for the wavelength-dependence of the detection efficiency using correction factors established through the measurement of reference compounds having known fluorescence emission spectra. Briefly, the set-up allows for the recording of corrected fluorescence emission spectra under multiphoton excitation at variable excitation power and wavelength. Absolute values for the two-photon excitation action cross sections σ 2 Φ were obtained according to the method described by Xu & Webb, using 10 -4 M fluorescein in 0.01M as a reference. 21 4 was dissolved in CH 3 CN at a concentration of 3.8 10 -5 M. The complexation studies were performed by using different concentrations of mercury.

Solvents and salts: Acetonitrile from Aldrich (spectrometric grade) and millipore filtered water (conductivity <6 x10 8  -1 cm -1 at 20°C) were employed as solvent for absorption and fluorescence measurements. Sodium thiocyanate, potassium thiocyanate, lithium perchlorate, magnesium perchlorate, calcium perchlorate, manganese perchlorate, iron perchlorate, cobalt perchlorate, nickel perchlorate, copper perchlorate, zinc perchlorate, silver perchlorate, cadmium perchlorate and lead(II) thiocyanate, from Aldrich or Alfa Aesar, were of the highest quality available and vacuum dried over P 2 O 5 prior to use.

  Scheme 2 Synthesis of chemosensors 8-HQ-4-St-PS 3 and 8-HQ-4-St-PO 4.

Figure 1 :

 1 Figure 1: a) Absorption of quinoline derivatives in CH 3 CN. b) Corrected normalised emission spectra of the quinoline derivatives in CH 3 CN.

Figure 2 :

 2 Figure 2: (a) Absorption and (b) corrected emission spectra of 8HQ-PO 2 in the presence of increasing concentration of Hg 2+ in CH 3 CN (C L = 22 µM, λ exc = 335 nm)

Figure 3 :

 3 Figure 3: (a) Absorption and (b) corrected emission spectra of 8HQ-4St-PO 3 in the presence of increasing concentration of Hg 2+ in CH 3 CN (C L = 22 µM, λ exc = 420 nm)

Figure 4 :

 4 Figure 4: (a) Absorption and (b) corrected emission spectra of 8HQ-4St-PS 4 in the presence of Hg 2+ in CH 3 CN (C L = 15 µM, λ exc = 350 nm)

Figure 2 .

 2 Figure 2. (a) Two-photon absorption of 8-HQ-4-St-PS 4 in the presence of an excess of Hg 2+ in CH 3 CN (C L = 10 -4 M, C Hg(ClO4)2 = 10 -3 M). No TPEF signal is observed in the absence of Hg 2+ . (b) Fluorescence signal of 8-HQ-4St-PS 4 in the presence of increasing concentration of Hg 2+ in CH 3 CN (two-photon excitation at 840 nm) C L = 10 -4 M.

Figure 3 .

 3 Figure 3. Corrected emission spectra of 8-HQ-4-St-PS 4 in the presence of increasing concentration of Hg 2+ in CH 3 CN/H 2 O 40:60 v/v, (C L = 13 µM, λ exc = 420 nm).

Figure 4

 4 Figure 4 Light gray) Response I F /I 0 of 8-HQ-4-St-PS 4 (13 µM) in CH 3 CN/H 2 O (40:60 v/v) at pH = 3 plus interfering ions Li + , Mg 2+ , Ca 2+ , Co 2+ , Zn 2+ and Cd 2+ at 1 mM, and Na + , K + , Mn 2+ , Fe 2+ , Ni + , Cu 2+ , Ag + and Pb 2+ at 0.1 mM (λ exc = 420 nm, λ em = 565 nm). (Dark gray) idem in the presence of Hg 2+ (13 µM).

Table 1 .

 1 Photophysical properties of quinoline derivatives in CH 3 CN. Maxima of the one-photon absorption labs [nm] and of steady-state emission λem (nm), molar absorption coefficient ε (M -1 cm -1 ), fluorescence quantum yield ΦF .`

	Product	λ abs max (nm) ε max (M -1 cm -1 ) λ em max (nm)	Φ F
	8HQ	308	2400	393	3.8.10 -3
	8HQ-CO [a]	275	4700	385	7.6.10 -4
	8HQ-PO	290	5000	396	2.7.10 -3
	8HQ-4St-PO	332	7600	461	2.6.10 -3
	8HQ-4St-PS	342	7600	459	2.6.10 -3

Table 2 .

 2 Stability constants of quinoline derivatives with Pb 2+ , Cd 2+ and Hg 2+ in CH 3 CN

		8HQ-CO [a]	8HQ-PO	8HQ-4St-PO	8HQ-4St-PS
		log βM L log ß ML log ß ML log ß ML2	log ß ML	log ß ML log ß ML2
	Hg 2+ 4.5 ± 0.7 7.0 ± 0.2	12.6 ± 0.2	5.8 ± 0.5	7.5 ± 0.5	13.5 ± 0.7
	Pb 2+ 1.2 ± 0.2 6.7 ± 0.2	12.0 ± 0.3	6.3 ± 0.2	4.7 ± 0.1	11.2 ± 0.3
	Cd 2+	-	-	-	6.6 ± 0.2	5.2 ± 0.2	-
	[a] ref 7a

  The residue was purified by flash silica gel chromatography (cyclohexane/ethyl acetate 80/20) to give 450 mg (71%) of the product.

1

H NMR (300 MHz, CDCl 3 ): δ = 10.47 (s, 1H), 9.18

(d, 1H

, J = 4.2Hz), 8.76

(d, 1H

, J = 7.3Hz), 8.22-8.14 (m, 4H), 7.79

(d, 1H, J = 4.2Hz), 7.65-7.56 (m, 1H,), 7.51-7.46 (m, 7H)

[START_REF] Lipunova | The Z stereochemistry of the isolated styryl derivatives was assigned based on J 1 H coupling constants of the alkenes and is in agreement with literature[END_REF]

C NMR (75.5 MHz, CDCl 3 ): δ =

  The resulting mixture was stirred at room temperature for 2 hours, then quenched with water and extracted with dichloromethane (2×10 mL). The organic phase was dried over MgSO 4 and the volatiles removed under vacuum. The crude product was redissolved in dichloromethane (5 mL), a catalytic amount of iodine was added. The solution was stirred at room temperature for 3 h under light exposure then washed with saturated aqueous Na 2 S 2 O 3 and dried over MgSO 4 . The residue was purified by flash silica gel chromatography (cyclohexane/ethyl acetate 80/20 then 70/30) to give 80 mg (53%) of the product. 1 H NMR (300 MHz, CDCl 3 ):

	P (121.5 MHz, CDCl 3 ): δ = 32.1. HRMS (ESI+): m/z: calcd for C 90 H 94 O 4 P: 1269.6884; found: 1269.6937 [M+H] + .
	Phosphinate 3. To a solution of phosphinate 7 (100 mg, 0.26 mmol) and phosphonium salt 8 (160 mg,
	0286 mmol) in tetrahydrofuran (1 mL) at 0°C was added 60% w/w NaH in mineral oil (21 mg, 0.52
	mmol) and 18-crown-6 (13.7 mg, 0.052 mmol). δ = 8.88 (d, 1H, J = 3Hz),
	8.11-8.19 (m, 4H), 7.83 (d, 1H, J = 7.7Hz), 7.77 (d, 1H, J = 8.3Hz), 7.40-7.65 (m, 8H), 6.89 (d, 2H, J =
	8.6Hz), 6.84 (d, 1H, J = 12.0Hz), 6.74 (d, 1H, J = 12.0Hz), 6.59 (d, 2H, J = 8.7Hz), 3.85 (t, 2H, J =
	6.6Hz) 1.69-1.76 (m, 2H), 1.25-1.44 (m, 10H), 0.87 (t, 3H, J = 6.8Hz). 13 C NMR (75 MHz, CDCl 3 ): δ =
	158.8, 149.9, 144.7, 133.9, 132.2 (d, J = 10.6Hz), 130.4, 128.4 (d, J = 13.5Hz), 127.9, 126.2, 123.1, 121.4
	(d, J = 14.9Hz), 119.9, 114.1, 67.9, 31.8, 29.3, 29.2, 26.0, 22.6, 14.1. 31 P (121.5 MHz, CDCl 3 ): δ = 31.8.
	HRMS (ESI+): m/z: calcd for C 25 H 30 NO 2 : 376.2277; found: 376.2272 [M-C 12 H 8 OP]+. (ESI-): m/z: calcd for C 12 H 10 O 2 P: 217.0418; found: 217.0423 [M-C 25 H 28 NO] -.

Acknowledgements

This work was supported by the National Research Agency program CP2D "FLUOSENSIL". I.S. and J.B. are grateful to the National Research Agency for their grants (2009-2011) and (2009-2012), respectively.

Notes and references

a PPSM, ENS Cachan,CNRS, 61, avenue du Président Wilson 94230 Cachan, France. Fax: (+33)147402454; E-mail: isabelle.leray@ppsm.ens-cachan.fr.