Z25 Adaptive and Mobile Systems Dr. Cecilia Mascolo

Transcription

1 Z25 Adaptive and Mobile Systems Dr. Cecilia Mascolo : Interoperable Discovery System for ed Services Yérom-David Bromberg and Valérie Issarny INRIA-Rocquencourt Today s open network environment => Middleware heterogeneity 1

2 Middleware heterogeneity Two base middleware functions for pervasive computing Service discovery (SDP) Broker for communication between services 1. Which services are present 2. May I interact with it Service Discovery Protocols There are many service discovery protocols (Jini,,, etc) Some rely on a central repository (which could however be dynamic, ie change identity in time) Some do not rely on central repository (nodes discover each others) Passive discovery: client listens for advertisements Active discovery: client sends probes asking for info 2

3 SDP heterogeneity Active model Service Service Request Passive model Service Service Advertisement Solutions to interoperability Reflective middleware E.g., ReMMoC at U. Lancaster Software architectures Component & connector abstractions for system modeling 3

4 ReMMoC ReMMoC [Grace, Blair & Samuel, ICDCS MCM 03] Dynamic integration of SDP-specific plug-ins, according to context Applications Common Interface Quality of SDP detection dependent upon embedded plug-ins High latency Significant resource consumption (bandwidth, memory & CPU) Introduces specific/proprietary SDP for client applications JINI Requests Requests Requests Requests Interaction with the environment Salutation Service Software architectures (SA) Decouple applications from interaction protocols / middleware SA & interoperability Component port Dynamic matching of component and connector through adaptation of port & role behavior Component Events-based interoperability Inspired by SA concepts [Ryan & Wolf, ICSE'04] Events to solve syntactic and semantic mismatches among SDPs Interaction is possible only if component port and connector role match. Connector Connector role Component 4

5 : An open solution to SDP interoperability Application services developed using existing middleware Middleware-layer interoperability that is transparent to applications Event-based interoperability Applications Legacy SDP - Dynamic interoperability Interaction with the environment The system Mobile B Mobile A Advertisements or 1 Requests 6 2 SDP Detection 4 Reconfiguration of SDP System 3 SDP Interoperability 5 Application 5

6 SDP detection : : 1847 : : 1900 SDP3: Group-Multicast-3 : Port Z Component The monitor component Maintains the table of identification tags Listens on all the ports provided by the table Null cost in terms of bandwidth consumption as the monitor passively listens on SDP ports SDP interoperability 1 2 Instantiator Events Parser Composer 9 8 Parser 7 Component Composer Parser Communication between parser & composer: Independent of the SDPs syntactic details Done at the semantic level using events There exists a set of events common to all SDPs Control events (system configuration), network events (network-level messaging), service events (service discovery), request events (request content), response events (response content) 6

7 Example to/from forwards an req to parser Parser generates a stream of events for composer Exemple of translation from to Host A Host B Service Request Generated Events Composed request Search SDP_C_START. SDP_NET_MULTICAST SDP_NET_SOURCE_ADDR SDP_SERVICE_REQUEST SDP_REQ_VERSION SDP_REQ_SCOPE SDP_REQ_PREDICATE SDP_REQ_ID SDP_ SERVICE_TYPE: SDP_C_STOP From the previous events the unit multicast a search request to discover services in its vicinity: M-SEARCH * HTTP/1.1 SERVER: :1900 ST: urn:schemas-upnp org:device:clock MAN: ssdp:discover MX: 0 7

8 configurability System specification at design time System SDP = { Component ={ ScanPort = { 1900; 1846; 4160 ; 427 } } Component (port=1846,427) ; Component (port=1900); Component JINI(port=4160); } Instanciation a) Jini Jini b) c) d) Dynamic Composition & Instanciation Jini Jini Message Streams Event Streams Overhead and Size and interoperability without 514KB client + 598KB client + 352KB However when more services are added 2 new libraries are added if is not used. 8

9 Evaluation Native case Service -> 0.7 ms UPNP Service -> 40 ms Java Open Slp Cyberlink Stack Evaluation On client Host A Local 1 Host B Service Server side side a) search request to a service Host A Host B UPNP Service Local side Server side b) search request to a service 2 [Slp-]-> 80 ms [-Slp]->Slp 1.2 ms =>Translation processes of are negligible 9

10 Evaluation On server Host A Local side Server side a) search request to a service Host A Host B Local Host B Service Service Server side side b) search request to a service 1 2 Slp->[Slp-] 65 ms ->[-Slp] 40 ms =>Translation processes of are negligible Conclusion An approach to interoperability Transparent interoperability Dynamic translation of one SDP to another Solution based on service-oriented architecture Interoperable service discovery at the network layer Questions about interoperability in other cases 10