A Multi-Protocol Approach to Service Discovery and Access in Pervasive Environments Pierre-Guillaume Raverdy, Valérie Issarny, Rafik Chibout, Agnès de La Chapelle INRIA-Rocquencourt, Domaine de Voluceau, 78153 Le Chesnay, France,
[email protected] Abstract
time (often a single one), many services may not be accessible (i.e., not IP reachable). Second, the use of various middleware platforms (e.g., UPnP, Jini, Web services) results in the concurrent use of discovery and access protocols that do not directly interoperate with each other, further limiting the number of accessible services. To address the above issues, we have developed the MUlti-protocol Service Discovery and ACcess (MUSDAC) middleware platform that enables users to truly benefit from pervasive environments, as it enables clients to interact with services built on top of different discovery and access protocols, and to interact with services hosted on different networks that are not directly visible or reachable. MUSDAC is itself provided as a service through existing discovery protocols, and clients explicitly use the platform's APIs and formats. Providing such an explicit interface enables us to extend existing protocols with new functionalities such as context-awareness [13]. In this paper, we present the design of the MUSDAC platform as well as an initial evaluation of its implementation. Many projects, as presented in Section 2, now focus on the interoperability issues raised by the heterogeneity of middleware platforms and networks, although separately. We argue that these two aspects should instead be handled in concert, and in Section 3 we present the system architecture, components and modus operandi of MUSDAC. Section 4 provides performance results of the prototype implementation that validates our approach. Finally Section 5 summarizes our contribution and discusses future work.
Pervasive computing environments bring new challenges for client/service interactions due to the heterogeneity of both the interconnected networks and the middleware platforms used. In order for clients to truly benefit from all the networked services embedded into the environment, an innovative solution is required that overcomes both the lack of interoperability of the existing discovery and access protocols, and the limited interconnectivity between the different networks available at a location. This paper introduces the MUSDAC middleware platform that interoperates with existing middleware protocols, and manages the dissemination of service information in dynamic multi-network environments. A generic service is thus provided that enables clients to discover and interact with services in the entire environment A prototype implementation of our platform is further presented, enabling us to demonstrate the flexibility of our approach
1. Introduction The pervasive/ubiquitous computing vision [18] can now be realized, thanks to the deployment of wirelessly accessible services (i.e., software components that can be accessed remotely through a published interface) into the environment to support mobile users in their daily life [5], and the mobile devices that are powerful enough not only to access these services, but also to host applications providing similar services to their environment [16]. Unfortunately, pervasive computing environments are highly heterogeneous, thus limiting actual interactions between users and services. First, the use of various wireless technologies (e.g., cellular networks, WiFi, or Bluetooth) and network management models (e.g., ad hoc or infrastructurebased) results in many independent networks being available to users at a location. As users can only be connected to a limited number of networks at the same
2. Related Work Over the years, many academic and industrysupported Service Discovery Protocols (SDPs) have been proposed. In [19], a classification of discovery protocols is proposed based on their infrastructure (i.e., centralized vs. decentralized vs. hierarchical), methods (announcements vs. requests vs. symmetric), or discovery scope (network vs. user role vs. context).
1
Leading SDPs use a pull-based approach (i.e., discovery requests), and relies on centralized repositories (e.g., Jini, Salutation), the broadcast functionality provided by the network (e.g., SSDP), or a combination of both (e.g., SLP). One common characteristic of these protocols is that they have been designed based on specific assumptions about the underlying network (e.g., Internet, home networks), the users' behavior, or the applications' needs. As a result, they do not directly interoperate with each other's as they employ incompatible formats and protocols for service description, service advertisements, or discovery requests. Furthermore, these SDPs are often integrated in middleware platforms (e.g., SSDP and UPnP), thus complicating interoperability due to incompatible data types or communication models. In fact, the diverse environment constraints and the de-facto standard status of some of the existing SDPs, make it unlikely for a unique SDP to emerge. Several projects are thus investigating interoperability solutions for SDP [1][4][9][12], as requiring clients and services to support multiple SDPs is not realistic. SDP interoperability is typically achieved using intermediate representations of SDP paradigms (e.g., service description, discovery request) [4], and using either a transparent or explicit approach. In the transparent approach, the interoperability layer is located close to the network and directly translates SDPs messages to/from the various SDPs [1][4]. Clients and services are unaware of the translation process. In the explicit approach, the interoperability layer is located on top of the existing SDPs, and provides an explicit discovery API to clients [8] While the transparent approach facilitates interoperability with legacy clients, the explicit approach enables the extension of existing SDPs with advanced features. MUSDAC sits on top of existing protocols and is explicitly accessed by clients to discover and access services in the environment. This approach enables us to enrich the service descriptions provided by SDPs, with context information, which is crucial in servicerich environments [7]. All the projects investigating SDP interoperability only consider interoperability within the same IP network. To enable multi-networks service discovery and access, several projects have investigated peering (gateways) or application-level routing, but are either extensions to a single SDP (e.g., UDDI v3), or new discovery protocols targeted at P2P networks [2][3][10]. These solutions do not interoperate with existing protocols and usually provide little control on the service information exchanged between the physical networks. In MUSDAC, we focus on the
dynamic composition of independent heterogeneous networks, where each network autonomously filters the service information that is disseminated not only based on administrative rules but also on network status and service profile.
3. The Multi-Protocols Service Discovery and Access Middleware Platform In MUSDAC, we consider an all-IP networking environment (i.e., all components use IP protocols to provide transport) composed of loosely connected, highly heterogeneous networks. Network heterogeneity arises from: (i) the use of different networking technologies, (ii) variations in the sets of IP-level configuration and communication functionality provided to devices by the network (e.g., IP multicast support, DHCP), and (iii) networks belonging to different administrative domains (e.g., public/open vs. restricted/secure) and management models (infrastructure-based vs. ad hoc). We further consider that the Internet and cellular networks are conduits enabling the interconnection of the various networks. UDDI
Music Store Location Hotspot1
Jini
Jini Intranet
Internet/Cellular
SLP JXTA AdHoc
Hotspot2
UPnP
OSGi
UPnP
Home Network
Figure 1: Global network example Figure 1 illustrates a composition of heterogeneous networks, with a user in a music store able to access an ad hoc network and two hotspots. Some devices in the ad hoc and hotspot networks are connected through cellular networks and the Internet to their intranets and home networks.
3.1. Architecture Overview MUSDAC is designed around the following architectural principles: Network composition: MUSDAC operates independently in each network of the pervasive environment, and each instance of MUSDAC selects with which other instances (in nearby/distant networks) to interact with. Interconnected instances communicate
with each other in order to disseminate discovery requests and provide remote service access. Such partitioning enables each MUSDAC instance to process requests based on the local networking and processing resources. Middleware interface: MUSDAC registers as a service in each active SDP within the local network. Client applications explicitly interact with the MUSDAC Service using their preferred discovery and access protocol (e.g., SSDP and SOAP for UPnP clients). Indeed, providing access to the platform through a protocol that the client already supports eases its integration into client applications. Platform components deployment: One or more devices in a network can be configured by their administrator to participate to the local instance of MUSDAC. Depending on its capabilities, the device registers to potentially host some or all of the instance components. It is not required to deploy MUSDAC on all the network's devices, and clients are only required to know the interface of the MUSDAC Service as well as the MUSDAC-specific formats for service description and discovery requests. MUSDAC
Manager SDA Plugin
MUSDAC (UPnP ) Service Transformer Transformer
UPnP
C
Bridge SDA Plugin
MUSDAC (SLP) Service Transformer
Bridge
SLP
S2
S1
Figure 2:MUSDAC platform overview Specifically, the MUSDAC platform is composed of the following components (see Figure 2): • A Manager that handles discovery and access requests within the network for local and remote clients; • Service Discovery and Access (SDA) Plugins that interact with specific SDPs to collect service information, register the MUSDAC service to be used by local clients, and perform service access on behalf of remote clients; • Transformers that extend the initial service descriptions generated by the SDA Plugin with context information; • Bridges that assist the Manager in expanding the service discovery and service access to other networks in the whole pervasive environment.
A key aspect of the MUSDAC explicit approach to SDP interoperability is that it enables the extension of SD-specific service descriptions with context information. In MUSDAC, we consider context information of the networking environment, the interacting users, and the service instances. Such enhancement enables to reason about the client's request and to provide better matching by also taking into account the environment. We model context information for these entities as the combination of context parameters and context rules. Context parameters correspond to static and dynamic attributes characterizing the entity. Context rules correspond to control policies expressing preferences, choices, and filters for the control of the discovery process in terms of resources to be used, level of security to be applied, type of services to be selected, and so forth. Context information is stored in MUSDAC service descriptions and requests, and is processed by Bridges to control their dissemination, and by Managers to filter the results of a request. The interested reader is referred to [14] for a complete description and evaluation of context management in MUSDAC. Security and trustworthiness is another important concern when deploying middleware platforms in open multi-networks environment. Our main goal is to enable MUSDAC components to establish and validate trust relationships between them, to communicate securely, and to guarantee the integrity of the information being transmitted. In the context of the UBISEC project (http://www.ubisec.org/), we identified the different security threats faced by the MUSDAC platform [17] and provided an initial design for secure group communication in MUSDAC [6] as well as data integrity verification.
3.2. Service Discovery in MUSDAC Services in the MUSDAC platform are described using the MUSDAC Description format, which is a generic and modular service description format. Indeed, each SDP defines its own representation for the functional and nun-functional characteristics of services. Some SDPs such as SLP have a minimal approach (i.e., one URI per service) while others such as SSDP or UDDI enable complex service descriptions. MUSDAC Descriptions consist of: (i) creation information that details the components that generated the description and where it was generated (i.e., IDs of Manager, SDA plugin and Transformers); (ii) service information that specifies the service properties as provided by the original SD protocol (e.g., service name, methods names and input/output parameters if available); (iii) service context information that
specifies context properties and admission control policies associated to the service instance; and (iv) propagation information that describes the path (in terms of networks and Bridges) between the client and the service. The MUSDAC Request format includes: (i) service information in which the client specifies the functional properties of the service to be discovered (e.g., service name or interface); (ii) user context information in which the client specifies the characteristics/status of the device and its owner, along with filters/preferences regarding how to carry out the service discovery; (iii) processing information, which defines how Managers must process the request and return the results (e.g., partial results returned or all at once); and (iv) propagation information that records the networks so far traversed by the request. A client looking for a service in the pervasive environment first discovers the MUSDAC Service using its preferred SDP and sends its request. Once received, the MUSDAC Service forwards the discovery request to the local Manager that sends it in parallel to the local SDA Plugins (for discovering suitable services in the local network), and to the local Bridges (for propagation to nearby networks). A Manager receiving a remote discovery request processes it as a local one (i.e., forwards it to its own SDA Plugins and Bridges) but returns the results to the originating Bridge. Finally, the client's Manager collects local and remote results and returns them. A Bridge disseminates discovery (and access) requests between networks based on context information. Indeed, a client can restrict its request to a specific context, such as services advertised with a specific SD protocol (e.g., UPnP), hosted on a specific network (e.g., Hotspot 1), or to remote services that can be accessed from the client's location (e.g., the networks between the client and the service fulfills the bandwidth requirements). The target network can also restrict the requests that can be forwarded. Different Bridges in the same network may therefore not propagate the same service information (e.g., if the destination networks do not have the same bandwidth or the same privacy policies). Each SDA Plugin collects service information in a specific discovery domain (e.g., SLP, UPnP) on behalf of the Manager. Depending on the SDP, the SDA Plugin either registers for service advertisements (i.e., push-based protocol), or directly performs service discovery (i.e., pull-based protocol). In the case of push-based protocols, the service description created by the SDA Plugin after a service announcement is sent to the Manager that records it in its local repository. For these push-based protocols, the Manager directly
evaluates incoming requests against the repository (i.e., without forwarding it to the SDA plugins), and returns the previously generated service descriptions. Initial MUSDAC service descriptions are generated by the SDA Plugin based on the SD-specific service descriptions that it collects and basic transformation rules. This initial MUSDAC Description contains all the information available in the SD-specific description, and is forwarded to each Transformer associated with the SDA plugin for further processing. Transformers are external components, potentially provided by companies, consortiums, or interest groups that extend the initial MUSDAC Description created by the SDA Plugin with service-specific context information. For example, a Transformer may be provided that dynamically communicates with the service being described in order to collect status information (e.g., service available or overloaded) and adds it into the service description. The description is then forwarded to the Manager that adds networkspecific context information. SDA Plugins could intercept all service discovery requests directly and, transparently to the requesting clients, convert them into the MUSDAC request format, thus achieving transparent interoperability. This would however prevent the extension of discovery requests and service descriptions with context information.
3.3. Remote Service Access in MUSDAC To access a networked service, a client application instantiates a service stub that implements the service interface (See Figure 3.a). The service stub encapsulates the invocation details for the client and interacts with the service provider. When the client calls a method on the service stub, a message is generated in a specific format and sent over the network to the entry point (e.g., URL, IP address and port number) of the service that decodes it, performs the required method, and returns the response back to the service stub and the client. In some middleware platforms (e.g., Jini/RMI), the client only knows the interface of the service, and the actual code of the service stub is dynamically loaded after the service has been discovered. In other middleware platforms (e.g., UPnP) the client already has the code of the service stub, or directly generates the message to be sent to the service. Service access across different protocols can be achieved by (i) providing specific service stubs and proxies that use a common representation for service calls/returns and translate this common format to the native format of the client/service (See Figure 3.b); (ii)
dynamically changing the code of the service stub depending on the service's protocols (See Figure 3.b); or (iii) providing a message translator that intercepts network messages between the client and the service and translate their content (See Figure 3.d). The intermediate representation solution (3.b) requires the deployment of specific components for both the client and the service and cannot be considered for pervasive environments. On the other hand, the dynamic generation of stubs (3.c) is simple to implement but requires some functionality from the environment such as dynamic code generation and code mobility. Finally, while a translator (3.d) is complex to implement, it achieves interoperability of service access transparently to both the client and the service (it is only necessary to update the service definition so that the entry point of the translator is used). C
St
S
C
a) Service stub C
St St St
St
S
b) Intermediate representation S
S
c) Dynamic service stubs
S
C
St
S
d) Access message translation
Figure 3: Service access interoperability To solve the network interoperability issue (i.e., when the service is not IP reachable), a local entry point for the service is necessary, as well as a mechanism for transmitting messages between the local and service entry points. Service descriptions, as well as the messages exchanged between the service and the client, must be processed and potentially updated to reflect the change in addresses. MUSDAC facilitates client access to services hosted in remote networks and/or that use different access protocols. In the current prototype implementation, we focused first on supporting remote service access (i.e., network interoperability), and assume that both use SOAP as access protocol (e.g., UPnP, Web services). In this case, the message translator is simplified, as transcoding of the content of the access message is not required (i.e., only the header). Accessing a remote service via MUSDAC includes two steps. First the communication channel setup, and then the actual service access. These two steps are transparent to the client, as the communication channel setup is done when accessing the remote service for the first time. When the client initializes its service stub with the destination entry point, it uses the local entry point added to the service description by the local MUSDAC Service (i.e., the client’s SDA Plugin). The MUSDAC Service maintains the association between
this entry point, the local client, the remote service, and the service description. When the first message is received on an entry point, the communication channel is created. The local MUSDAC Service communicates with the service’s SDA Plugin based on the propagation list from the service description, and all the Bridges in between. Once initialized, messages from the client are translated (i.e., change in the header of the SOAP message) and encapsulated in a message sent over the communication channel. Each Bridge that receives an access message checks the unique identifier of the communication channel for this message and forwards it until it reaches the final SDA Plugin. The SOAP content is then extracted and sent directly to the service. The result is returned in a similar way to the client’s MUSDAC Service that returns the response to the client. In case the communication channel fails (e.g., a Bridge leaves), the service stub needs to be restarted, potentially involving a new service discovery through MUSDAC in order to find a new path (i.e., propagation list) to the service. It is therefore important to select stable devices as Bridges. We assume that in most cases a few stable Bridges can be selected.
4. Prototype Evaluation We implemented a first prototype of the MUSDAC middleware platform in Java and released it as Open Source Software (http://www-rocq.inria.fr/arles/ download/ubisec/). Although our prototype is not yet optimized, it is robust enough to assess the performance of our approach in different use cases. We first describe the prototype and discuss implementation choices (§4.1), and then evaluate service discovery and access within a single network (§4.2) and in multinetworks (§4.3).
4.1. Prototype Implementation While the Manager component may be implemented in a centralized or distributed manner, it is logically centralized, as the size of a local network is limited by nature (i.e., its number of devices and services is limited). In the centralized implementation, one manager is dynamically elected to control the network. MUSDAC-aware devices exchange their profile information and then use a multi-criteria algorithm to elect their Manager (benefit value based on number of SDPs supported, device expected lifetime, device processing capabilities). Once elected, the manager periodically sends presence beacons so that other MUSDAC-aware devices in the network can detect its absence (i.e., no presence beacon received after a given time) as well as duplicates, and elect a new manager.
Once elected, the manager selects and activates the Bridges for the network based on their profile information, and provides them the network context information. In the current prototype, network and user/device context information is static and initialized at the platform's startup. A Bridge must be activated by the Managers on both sides in order to propagate service information between two networks. Several SDA Plugins have been implemented that enable us to experiment with both repository-based (Ariadne [15], OSGi) and broadcast-based (SLP, UPnP) protocols. Adding a new SD protocol in the MUSDAC middleware platform is indeed straightforward, as no modifications needs to be made to the Manager or Bridge components. In the current implementation, SDA Plugins are dynamically loaded by the Manager (i.e., collocated with the manager) to reduce communication costs. As this represents a bottleneck when many clients perform frequent service discovery requests or for devices with limited capabilities, we plan to extend our prototype to access SDA Plugins located on different devices in the network. We also plan to investigate code mobility solutions in order to update or add SDA plugins and Transformers. The size of MUSDAC service descriptions is slightly more compact than UPnP descriptions (when taking into account both the device and service descriptions). The current prototype implementation of MUSDAC enables accessing SOAP-based services (i.e., UPnP services, Web services) in remote networks, without requiring global IP routing. In case a service uses the same access protocol as the client and is also in the same network also, the MUSDAC platform directly returns the service endpoint for performing service access, thus bypassing the MUSDAC intermediation and providing more efficient service access.
4.2. Local Service Discovery and Access We first evaluated MUSDAC performance for discovering and accessing services in a single network, and compared it with native protocols. The test methodology is as follows. For each test, we conducted 5 runs of 50 service discovery (access) requests; removing each time the 2 lowest and highest values to cater for skewed results. The median of the 5 runs is provided. For the tests described in this paper, we used the publicly available OpenSLP and Siemens UPnP stack (v1.01) that provide Java implementations of the SLP and SSDP protocols. We conducted the tests on three types of desktops/notebooks: (i) a Sony Vaio C1XS with a Mobile Pentium II processor rated at 400 MHz to represent limited devices such as current
PDAs, mobile devices and home appliances; (ii) a desktop with an AMD Athlon XP 1800+ to represent average devices such as home servers, and (iii) a desktop with an Intel Pentium IV rated at 2.8 GHz to represent powerful devices. The Sony Vaio C1XS runs Windows 98 with 128 MB of memory while the 2 other configurations respectively runs Windows XP and Linux with 512 MB of memory. For our tests, we used a simple test service providing a get and a set method with one (string) parameter. No context information was added to the service description. Table 1 presents the measurements for discovering a UPnP and an SLP service, directly and via MUSDAC (response time for the first service description to be returned). It is clear that native SLP is the fastest SDP, as the service description sent over multicast is a simple string (i.e., no parsing or marshalling of complex data types or documents). UPnP and MUSDAC on the other hand are processing complex XML documents. It should be noted that the response time for UPnP discovery request are exceptionally high, and can be attributed to thread and timeout management problems in the implementation of the stack being used. We are investigating this issue and evaluating other UPnP stacks. Table 1: Service discovery (ms) UPnP SLP MUSDAC (UPnP) MUSDAC (SLP)
Limited 935 3 2365 820
Average 936 2 1642 320
Powerful 593 0.2 1054 228
Nevertheless, the MUSDAC service discovery time is important (about twice the discovery time compared to native UPnP) and should be decomposed. The main part of the overhead is in fact related to the SOAP processing performed by the client and the MUSDAC service. On the limited configuration, an empty SOAP call takes about 957 ms to process (out of the 1450 ms overhead), or about 66% of the MUSDAC overhead. This is primarily due to the complexity of the MUSDAC service description format. The second source of overhead is the generation of the description that takes close to 300 ms on the limited device or about 20% of the overhead. Table 2 provides the measurements for a simple service access to the UPnP service, directly and via MUSDAC. We can note that on all configurations, service access through MUSDAC is faster than the native UPnP service access. Indeed, we use a lightweight and optimized SOAP library (CompactSOAP [11]) for accessing the MUSDAC service which is more efficient than the SOAP processing tools used
in the Siemens UPnP library. The SLP service also uses SOAP for service access and is therefore not represented. Table 2: Service access (ms) UPnP MUSDAC (UPnP)
Limited 770 550
Average Powerful 511 500 371 281
We performed the same tests (discovery and access) with the client, service, and manager located on different devices in Ethernet (100 Mbps), IEEE 802.11b (11 Mbps), and Bluetooth (1 Mbps) networks. No differences were observed, as the number and size of messages are limited, and as the latency and transmission cost of the networks are negligible compared to the SOAP/XML processing time.
4.3. Global Service Discovery and Access We now present performance results for multinetworks configurations. For these tests, the powerful configuration was used (on this workstation, the MUSDAC SOAP overhead is around 130 ms). We tested service discovery and access with up to 5 interconnected networks, thus adding each time an additional Bridge between the client’s network and the service’s network. Table 3: Service discovery (ms)
#Bridges UPnP SLP MUSDAC (UPnP) MUSDAC (SLP)
0 593 0.2
1 -
2 -
3 -
4 -
5 -
1054
1153
1162
1177
1195
1228
228
259
283
305
342
378
From the measurements presented in Table 3, we observe that the service discovery response time increases linearly with the number of Bridges, and that the overhead is around 30 ms per Bridge (30 ms per Bridge for SLP services, and about 35 ms for UPnP services, difference that can be attributed to the difference in the size of the service description). Thus, each Bridge adds a surcharge of 15% to the MUSDAC core overhead. This corresponds to the following operations: (1) unmarshaling of the incoming discovery request (resp. response), (2) evaluation of its propagation rules (single rule limiting the number of hops), (3) update of the propagation hops, and (4) marshalling of the updated message. Again, the largest chunk of the overhead (around two-thirds) is related to XML processing (marshaling between XML messages
and Java classes). This limited bridging overhead supports our goal of providing efficient multi-networks service discovery. From the measurements presented in Table 4, we observe that the response time for service access also increases linearly with the number of Bridges, and that the overhead is around 22ms per Bridge. Thus, each Bridge only adds a surcharge of 10% to the MUSDAC core overhead. This corresponds to the following operations: (1) unmarshaling of the incoming access (resp. response) message, (2) control of the communication channel to use and update of the propagation list, and (3) marshalling of the updated message. Almost the entire overhead is related to XML processing (marshaling between XML messages and Java classes). #Bridges Native UPnP MUSDA C (UPnP)
Table 4: Service access (ms) 0
1
2
3
4
5
505
-
-
-
-
-
306
336
373
388
406
418
The first MUSDAC prototype implementation enabled us to evaluate our approach. While the MUSDAC overhead for service discovery is important, we should bear in mind that the successful discovery of a service is usually followed by many accesses to this service, where the MUSDAC overhead is negligible. We identified the main overheads, which are the use of SOAP for accessing the MUSDAC Service, the generation of MUSDAC Descriptions, and marshalling XML to/from Java classes. In order to address these bottlenecks, we implemented a simple MUSDAC Service using plain XML messages over socket-based communication. Initial test of this alternative implementation of the MUSDAC Service yielded significant improvements (896 ms for MUSDAC/UPnP service discxovery on the powerful configuration down from 1054 ms). We further plan to investigate the automatic prefetching of service descriptions from pullbased SDPs combined with the local caching of the generated service descriptions. These improvements should further drastically reduce the service discovery time in MUSDAC.
5. Conclusion and Future Work The MUlti-protocol Service Discovery and ACcess (MUSDAC) middleware platform overcomes the heterogeneity of middleware platforms and networks inherent to pervasive environments. Our solution is fully transparent to services, and only requires the
client applications to have knowledge of the MUSDAC Service. Through this service, client applications are able to discover and access services that use different interactions protocols and/or are located in different networks. Another key aspect of MUSDAC is that context information is not only used when evaluating a discovery request, but also to filter the requests and responses being propagated in the multi-networks environment. Indeed, it is crucial to both return relevant service descriptions to clients and to limit the networking/processing overhead. A first prototype of MUSDAC has been implemented and diverse SDPs have been easily integrated into the platform. An initial evaluation of the prototype had been performed that identified the main platform overhead to be related to the cost of accessing the MUSDAC Service (i.e., SOAP processing), while the overhead associated with the processing and dissemination of discovery requests (and access messages) through Bridges is limited. Extensions to the MUSDAC platform are being investigated to support additional access protocols such as Jini (e.g., through the use of reflection and dynamic proxy). We also plan to investigate additional access protocols for the MUSDAC Service in order to reduce the overhead associated with its access. While we performed the initial evaluation of the prototype in a simple setting, we now intend to investigate scalability of the platform in terms of number of simultaneous requests and users that it can support. We also plan to investigate new Bridge activation policies for complex multi-network configurations and to take into account device mobility for the dissemination of service and profile information.
Acknowledgements This work described herein is funded by the European Commission under the FP6 IST project UBISEC contract number 506926, and the FP6 IST Project Plastic contract number 026955.
References [1] J. Allard, V. Chinta, S. Gundala, and G. Richard, "Jini Meets UPnP: An Architecture for Jini/UPnP Interoperability," In Proceedings of the 2003 International Symposium on Applications and the Internet (SAINT 2003). [2] K. Arabshian and H. Schulzrinne. “Gloserv: Global service discovery architecture”. In First Intl. Conference on Mobile and Ubiquitous Systems: Networking and Services (Mobiquitous), August. 2004. [3] M. Balazinska, H. Balakrishnan, and D. Karger. “Ins/twine: A scalable peer-to-peer architecture for intentional resource discovery”, Pervasive 2002 - International Conference on Pervasive Computing, Zurich, Switzerland, August 2002.
[4] Y.D. Bromberg, V. Issarny, "INDISS: Interoperable Discovery System for Networked Services", In Proc. of ACM/IFIP/USENIX 6th International Middleware Conference (Middleware'05). Grenoble, France, 2005. [5] B. Brummit, B. Meyers, J. Krumm, A. Kern, and S. Shafer, “EasyLiving: Technologies for Intelligent Environments”, Handeld and Ubiquitous Computing, September 2000. [6] J. V. del Campo, J. Pegueroles, M. Soriano, "Providing Security Services in a Multiprotocol Service Discovery System for Ubiquitous Networks", In Proc. of the First Intl. Conference on Availability, Reliability and Securit (ARES 2006), Vienna, Austria, 2006. [7]
A. K. Dey, G. D. Abowd, D. Salber “A Context-Based Infrastructure for Smart Environments”, In Proceedings of the 1st International Workshop on Managing Interactions in Smart Environments (MANSE '99), 1999.
[8]
A. Friday, N. Davies and E. Catterall “Supporting service discovery, querying and interaction in ubiquitous computing environments”. ACM Baltzer Wireless Networks (WINET) Special Issue on Pervasive Computing and Communications, 10(6):631-641, 2004.
[9]
P. Grace, G. S. Blair and S. Samuel. "A Reflective Framework for Discovery and Interaction in Heterogeneous Mobile Environments". ACM SIGMOBILE Mobile Computing and Communications Review, 9(1), pp 2-14, special section on Discovery and Interaction of Mobile Services, January 2005
[10] D. Gribble, M. Welsh, R. von Behren, E. Brewer, D. Culler, N. Borisov, S. Czerwinski and R. Gummadi. “The ninja architecture for robust internet-scale systems and services” Computer Networks, 35(4):473–497, Mar. 2001. [11] V. Issarny, D. Sacchetti, F. Tartanoglu, F. Sailhan, R. Chibout, N. Levy, and A. Talamona "Developing Ambient Intelligence Systems: A Solution based on Web Services". In Journal of Automated Software Engineering. Vol 12. 2005. [12] T. Koponen and T. Virtanen, "A Service Discovery: A Service Broker Approach" In Proceedings of the 37th Annual Hawaii International Conference on System Sciences (HICSS'04), January 2004 [13] C. Lee and S. Helal, “Context Attributes: An Approach to Enable Contexta-wareness for Service Discovery” in 2003 Symposium on Applications and the Internet , January 2003 [14] P.-G. Raverdy, O. Riva, R. Chibout, A. de La Chapelle and V. Issarny, "Efficient Context-aware Service Discovery in MultiProtocol Pervasive Environments", In Proc. of IEEE Intl. Conference on Mobile Data Management (MDM), Tokyo, Japan, May 2006. [15] F. Sailhan and V. Issarny, "Scalable Service Discovery for MANETS", In Proceedings of Third IEEE International Conference on Pervasive Computing and Communications (2005) [16] D.D. Spinellis, “The information furnace: consolidated home control”, Personnal and Ubiquitous Computing, Vol 7.1, SpringerVerlag London Ltd, May 2003, Pages 5369 [17] UBISEC Deliverable D1.3. "Design of Security Support for Service Discovery", 2005, http://www.ubisec.org/, [18] M. Weiser, The Computer for the 21st Century. Scientific American, 256, 3(Sept.), Pages 94-104. [19] F. Zhu, M. Mutka, L. M. Ni, "Service Discovery in Pervasive Computing Environments", Pervasive Computing, IEEE Volume 4, Issue 4, Oct. Dec. 2005 pp: 81–90
