As part of our research on achieving middleware interoperability, we have designed the Multi-Protocol Service Discovery and Access (MSDA - also called MUSDAC) middleware to overcome both the limited interconnectivity between the different networks available at a location, and the lack of interoperability of the existing discovery and access protocols. Indeed, the use of various wireless technologies (e.g., cellular networks, WiFi, or Bluetooth) and network management models (e.g., ad hoc- or infrastructure-based) 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 time (often a single one), many services may not be accessible (i.e., not IP reachable). The use of various middleware platforms (e.g., UPnP, Jini, Web services) by mobile users further limits the number of accessible services due to the incompatibilities between the different discovery and access protocols.
In MSDA, the environment is viewed as a dynamic composition of independent networks in which services use different protocols for discovering and accessing services. MSDA relies on specific plugins to interact with existing middleware, manages the efficient dissemination of the service information between the different networks, and enables clients to access all the networked services in them. The originality of our approach is that:
In a nutshell, an instance of the MSDA is started in each independent network. Each instance of MSDA is composed of:
In MSDA, services are described using the MSDA Description format, which is a generic and modular service description format able to record any information available in an SD-specific service definition. SDA Plugins and Transformers generate MSDA Descriptions based on the SD-specific service descriptions they receive.
A client looking for services in the pervasive environement first discovers their local MSDA, and issues an MSDA-specific discovery request that is forwarded to the MSDA Manager. The local MSDA Manager then forwards the request to the local SDA Plugins for processing, and relies on the active MSDA Bridges in the network to propagate the request in the global network and return the results. MSD Bridges and MSDA Managers perform advanced filtering based on context information (e.g., service and client profiles, network status) to only return relavant instances of the requested service. For service access, MSDA creates a communication channel along the MSDA Bridges leading to the service’s network, and then sends the client’s service access requests on this communication channel. The relevant SDA Plugin at the other end of the communication channel then executes the service access requests on behalf of the client and returns the results.