Ubiquitous Service Discovery in Pervasive Computing Environment

INTRODUCTION

Service discovery techniques help users to find services, applications and devices that are available in the network. This feature is especially useful for mobile users in foreign networks and for groups of users that form a spontaneous (Ad hoc) wireless network and ubiquitous computing environment (Weiser, 1993).

A user can trace a service by requesting for a particular service type (e.g. printer) and may make an intelligent service selection in case multiple services of the desired type are available. As well the added value for the user, service discovery techniques also surprisingly reduce the network administration load, especially when new services are to be introduced in a large network.

The following example illustrates the convenience of service discovery:

A news reporter is visiting a news room which is established in political convention center where a current political conference is going on. There are several services installed in news room, such as a printer, a scanner, a fax machine and a network access point to the Internet. If the news reporter likes to print some reports and wants to fax them back to news station, she will first have to find out what type of printer is present and then she will install the device driver that enable to print. If a service discovery protocol is installed; it will automatically detect and configure these services and facilitate the user from any manual setup operation.

Ubiquitous Service Discovery is a large-scale service discovery architecture that addresses the need for large area service discovery for ubiquitous and pervasive computing environment. It operates on wide area network as well as local area networks. Any type of service is handled which may include events, location-based services, communication or web services.

The Ubiquitous Service Discovery systems are useful in many different scenarios of life. Ubiquitous Services will be in every important aspect of future life like health, security, education, business and traveling. So just visualize a passionate traveler who is interested in different events or services that are taking place in a particular city. He is the citizen of the USA visiting South Korea, for instance, wants to be notified of all the cultural shows taking place in Seoul. When he reaches in the Seoul, his PDA will issue a query pertaining to his preference, such as artistic music concerts and then try to locate artistic music concerts close to his hotel area or according his preference to music style. At the end he will get the information about the musical show and place of musical show according to his predilection.

RELATED WORK

Almost services discovery are based on publicize and listen in method where the periodic multicast is used for services announcement and discovery.

This problem is widely recognized; many companies, standards bodies and consortia are addressing it at various levels in different ways. A variety of service discovery protocols are currently under development. The most well known so far are:

Jini (Anonymous, 2005a): Is an extension of the programming language Java and has been developed by Sun Microsystems. The Jini architecture is consists:

Lookup service: The lookup service keeps track of the Jini services and provides the proxies to communicate with the service. In addition, the lookup service is a Jini Service as well.

Jini service: Jini Service is registered with the lookup service and is capable of being invoked through their public interface which is defined via a Java remote interface. The underlying system that allows Jini services to communicate is RMI (Remote Method Invocation).

Jini client: The Jini client is software that requests the proxy from the lookup service in order to invoke the Jini Service.

SDP (Anonymous, 2005b) addresses service discovery specifically for the Bluetooth environment. It is optimized for the highly dynamic nature of Bluetooth communications. SDP does not define methods for accessing services; once services are discovered with SDP, they can be accessed in various ways depending upon the service. SDP uses a request/response model where each transaction consists of one request Protocol Data Unit (PDU) and one response PDU. In the case where SDP is used with the Bluetooth L2CAP transport protocol, only one SDP request PDU per connection to a given SDP server may be outstanding at a given moment.

UpnP (Anonymous, 2005b; Miller et al., 2001) extends Microsoft`s Plug and Play technology to the scenario where devices are reachable through a TCP/IP network. It is designed for small office or home computer networks and there is no central service register as in SLP. The UPnP discovery protocol allows that device to advertise its services to control points on the network. Similarly, when a control point is added to the network, the UPnP discovery protocol allows that control point to search for devices of interest on the network.

SLP (Perkins, 1998; Goland et al., 1999) Service Location Protocol is Internet Engineering Task Force (IETF) proposed standard protocol that was designed to simplify the discovery and use of network resources. It is decentralized, lightweight, scalable and extensible protocol for service discovery within a site. It allows but does not require centralized administration. SLP comprised three components:

User Agent (UA) supports service query functions. It acquires service information for user applications. The user agent retrieves service information from the service agent or directory agents. A Host On-Demand client is an example of a user agent.

Service Agent (SA) advertise the location and characteristics of services, on behalf of the services.

Directory Agent (DA) collects service information from service agents to provide a repository of service information in order to centralize it for efficient access by user agents. There can only be one DA present per given host.

UBIQUITOUS REMOTE MANGER

The Ubiquitous Service Discovery (USD) has developed for Ubiquitous Remote Manager (URM). URM controls the home gateways from end to end remotely and self managed so that the complexity of the system can be reduced and more control can be achieved over the network.

In Ubiquitous Remote Manager we have added some more valuable services like U-Bid Service, U-Device Advertiser and U-Service Composition, U-Service Advertiser etc. With these various services it will be very complex and not feasible to personally manage all of them. For this Autonomic self Management feature has been added. This feature will allow the system to manage itself and hence virtually no human assistance will be needed for tiny matters.

Control center: The Control Center (CC) unit has vital role in the preliminary and consequent configuration. It is a set of connections with in the Ubiquitous Remote Manager. Only the control center can add/remove backend server hosts, configure the system databases, etc. The initial configuration of the system always begins on the control center. After initial configuration, the CC can go offline and the system can continue carrying out without it. However, the Control Center (CC) cannot be completely changes in the system configuration can be done only through this module.

Management server: A management server handles the communication with service gateways, monitoring changes in their configuration state, schedules management jobs for execution and keeps track of job results replied by service gateways. The management server uses the centralized database for storing configuration information about all gateways it controls, as well as pending for execution management jobs. Each management server is responsible for synchronizing the configuration state of service gateways with the configuration data stored in the database.

The management server also provides support for storing and accessing all persistent information from gateways on the backend system, so OSGi (Anonymous, 2005c) frameworks can be deployed on devices without any importunate memory (disk, flash RAM).

Remote access server: It allows the service provider and service user to access Ubiquitous Remote Manager remotely. The service providers perform services publishing and administration through RAS. Users can access the Ubiquitous Remote Manager (URM) functions and services.

Ubiquitous autonomic management server: The Ubiquitous Autonomic Management Server (UAMS) component is the Application server that will contain the services in the form of JAR files. These files can be accessed and downloaded by all other applications and servers in the system.

HTTP server: The HTTP Server upholds the TCP/IP connection inside and outside the Ubiquitous Remote Manger. Gateway Operator and Service Provider make connection to Ubiquitous Remote Manager in the course of HTTP Server.

UBIQUITOUS SERVICE DISCOVERY

In Ubiquitous Service Discovery (USD) the most important obsession is a service is an entity that can be used by a person, a program, or another service. A service may be a computation, storage, a communication channel to another user, a software filter, a hardware device, or another user. Two examples of services are printing a document and translating from one word-processor format to some other.

Ubiquitous Service Discovery (USD) provides mechanisms for service construction, discovery, communication and use in a distributed system. Examples of services include devices such as printers, displays, disk; software such as applications or utilities; information like databases and files; and users of the system.

Fig. 1:	Ubiquitous remote manager environment, smart home environment with user, service provider and gateway operator above Fig. 1 describe the overall system architecture of a ubiquitous remote manager with its basic elements like CC (Control Center), UAMS (Ubiquitous Autonomic Management Server), MS (Management Server), RAS (Remote Server) and HTTP server

Fig. 2:	Architecture of ubiquitous service discovery with home environment

Ubiquitous Service Discovery (USD) architecture contains Service Pointer that will point (discover) the service with in the network to user, service update service will update the services directory and cache.

Service pointer: Services are found and resolved by a service pointer. The service pointer is the central mechanism for the system and provides the major point of contact between the system and users of the system. In specifically terms, a service pointer takes queries from user and point the service from the services database and cache within the network to the user.

Service update service: When the Service provider adds some new services to services directory via Ubiquitous Remote Manager, The Service updates service, update the services directory and service cache and this service Directory and cache maintain by Management Server. These services can be put in through Service Advertise as well.

Preference search service: Preference Search Service, expressive entries allow for more fine grained selection of services based on properties understood by peoples. This provides the user defined parameters for the search such as searching by service type or service provider.