This article focuses on the effect of mobile computing on electronic commerce and discusses the paradigm shift that is being so induced. It elucidates different ways of discovering services in such a dynamic environment. The increased use of Personal Digital Assistants like PalmPilots has opened a new horizon of proliferation in the electronic market and has coined a new term "Mobile Commerce". Electronic Commerce can be defined in general as an aggregation of all transactions on the internet. When these types of applications and transaction processing facilities need to be accessed from a wireless device, a new domain of research area and challenging problems come into the picture. As is immediately evident, Mobile Commerce has to deal with the new problem of finding location dependent data.
Services in general can be defined as facilities that are available to a computer. A computer connected to a distributed system has access to the printer, copier, scanner etc. If it is a node wired to the Internet it can access prices of books through web sites and carry on various other transactions. As businesses offer various types of heterogeneous services to their customers, finding out a service efficiently becomes important. This article summarizes existing architectures for discovering services, compares and contrasts the existing infrastructures and explains some of the inherent drawbacks. We also present the Ronin Agent framework and the work done in the XReggie project to improve upon the existing techniques of service discovery [4,6].
Is it possible?
Jill is driving down I695. The car has its own onboard computer. She
herself has a cellular phone and a PalmPilot. The car's onboard computer
connects with computers in nearby cars using its built-in wireless device
and exchanges information regarding the traffic ahead, accident information
etc. Jill is running out of gas and wants to know the nearest gas station
nearby. Her onboard computer or her PalmPilot can do this job for her.
The onboard computer connects to other onboard computers of cars passing
in the opposite direction using adhoc-networking protocols and tries to
glean the information whether any car has refueled recently and also tries
to know the location of the gas station. In the meantime, her PalmPilot
is searching out for gas station agents in the vicinity. Soon, it gets
a reply from one and figures out its position. The PalmPilot also finds
out a map agent who feeds the driving directions to the gas station into
Jill has no problem filling in.
She is driving the whole day and its almost evening. Jill decides to call it a day. Jill tells her PalmPilot to book a room at the nearest Chariott hotel. The palm device contacts the proxy agents for the local hotel/restaurant associations and gets the best possible deal on the room she wants. Jill wants her mexican style dinner ready when she arrives at the hotel. The agent in her PalmPilot places this request to be executed by the hotel agent. Driving directions are obtained as usual. Figure 1 gives a brief overview of the communication going on within different agents during the whole episode.
There are some basic assumptions in realizing the above scenario. We
assume that the level of networking and computing hardware will increase
consistently in the recent future. We assume the emergence of PalmPilots
and Bluetooth like systems, which would provide short-range moderate
bandwidth connections at very low cost. We also assume the existence of
widely deployed and easily accessible wireless Local Area Networks
(LAN) and Wide Aread Networks (WAN).
Bluetooth technology for beginners, is essentially a cable replacement technology where two bluetooth enabled devices can communicate effeciently with each other using
radio frequency. Its a joint achievement of nine leading companies within the telecommunications and computer industry.
So, what technical insinuations do we get from the above example?
There should be service agents in the vicinity to receive the requests
and process them. But another important question bubbling up in a computer
scientist's mind would be " So, How do my PalmPilot know about the electronic
facilities available around me?". Discovering these type of services dynamically
is becoming increasingly important in the present scenario. In the near
future, a service would be selected automatically for a job, taking into
consideration its physical location, previous history and various other
semantic information. The discovery mechanism needs to move beyond
trivial attribute or interface matching. The discovery mechanism would
be much more knowledge based and artificial intelligence would play
a major role in service selection. While trying to build a efficient service
discovery architecture, some of the high level questions a researcher might
try to address are:
1. Effeciency of the discovery mechanism: How quickly and with how much less cost can a service be discovered
2. Reliability of the underlying communication mechanism: if the underlying communication mechanism is unreliable then the protocol has to adjust accordingly
3. Service lifetime management: In a dynamic environment services might be available only for a particular amount of time
4. Security issues: malicious users should not be able to access secure services
We venture out into the Internet and travel from network to network to find out the existing service discovery protocols. We try to identify some of the inherrent problems associated with the existing discovery infrastructures. Subsequently we describe the work we have done in the service discovery arena to make service discovery more dynamic.
Service Discovery Survey
Service Location Protocol (SLP)
The Service Location Protocol (SLP) is a product of the Service Location Protocol Working Group (SVRLOC) of the Internet Engineering Task Force (IETF) [9,10]. It is a protocol for automatic resource discovery on Internet Protocol based networks. Service Location Protocol is a language independent protocol. Thus the protocol specification can be implemented in any language. It bases its discovery mechanism on service attributes, which are essentially different ways of describing a service. It and can cater to both hardware and software form of services.
The Service Location Protocol infrastructure consists of three types
1. User Agent
2. Service Agent
3. Directory Agent
The User Agents acquire service handles for end user applications that request the services. The Service Agents are responsible for advertising service handles to the Directory Agents thus making services available to the User Agents. The Directory Agent maintains a list of the advertised services in a network. In the above scenario, the agent residing in the palm pilot is the user agent and the agent keeping track of hotel information is the service agent. The core functionalities of Service Location Protocol are the following:
1. Obtaining service handles for User Agents.
2. Maintaining the directory of advertised services.
3. Discovering available service attributes.
4. Discovering available Directory Agents.
5. Discovering the available types of Service Agents.
Figure 2 explains the basic transactions of the Service Location protocol:
A service is described by configuration values of the attributes possible for that service. For instance, a service that allows users to download audio or video content can be described as a service that is a pay-per-use real-time service or a free-of-charge service. The Service Location Protocol also supports a simple service registration leasing mechanism that handles the cases where service hardware is broken but the services continue to be advertised.
Jini: A service discovery architecture based on Java
Jini is a distributed service-oriented architecture developed by Sun Microsystems . Jini services can be realized to represent hardware devices, software programs or a combination of the two. A collection of Jini services forms a Jini federation. Jini services coordinate with each other within the federation. The overall goal of Jini is to turn the network into a flexible, easily administered tool on which human and computational clients can find services in a flexible and robust fashion. Jini is designed to make the network a more dynamic entity that better reflects the dynamic nature of the workgroup by enabling the ability to add and delete services flexibly.
One of the key components of Jini is the Jini Lookup Service (JLS), which maintains dynamic information about the available services in a Jini federation. Every service must discover one or more Jini Lookup Service before it can enter a federation. The location of the Jini Lookup Service could be known before hand, or they may be discovered using multicast. A Jini Lookup Service can potentially be made available to the local network or other remote networks (i.e. the Internet). The Jini Lookup Service can also be assigned to have group names so that a service may discover a specific group in its vicinity.
When a Jini service wants to join a Jini federation, it first discovers one or many Jini Lookup Service from the local or remote networks. The service then uploads its service proxy (i.e. a set of Java classes) to the Jini Lookup Service . The service clients can use this proxy to contact the original service and invoke methods on the service. Since service clients only interact with the Java-based service proxies, this allows various types of services, both hardware and software services, to be accessed in a uniform fashion. For instance, a service client can invoke print requests to a PostScript printing service even if it dosent have any knowledge about the PostScript language.
An user searching for a service in the network first multicasts a query to find out the Jini Lookup Service in the network. If a Jini Lookup Service exists, the corresponding remote object is downloaded into the user's machine. The user then uses this object to find out its required service. In Jini, service discovery is done by interface matching or java attribute matching. If the Jini Lookup Service contains a valid service implementing the interface specified by the user, then a proxy for that service is downloaded in the user's machine. The proxy is used henceforth to call different functions offered by the service.
Universal Plug and Play (UPnP): Microsoft's solution to service discovery
Universal Plug and Play (UPnP), pushed primarily by Microsoft is an evolving architecture that is designed to extend the original Microsoft Plug and Play peripheral model to a highly dynamic world of many network devices supplied by many vendors . Universal Plug and Play works primarily at lower layer network protocols suite (i.e. TCP/IP), implementing standards at this level. This primarily involves in addition to the suite certain optional protocols, which can be implemented natively by devices. The keyword here is "natively". Universal Plug and Play attempts to make sure that all device manufacturers can quickly adhere to the proposed standard without major hassles. By providing a set of defined network protocols UPnP allows devices to build their own Application Programming Interfaces that implement these protocols - in whatever language or platform they choose.
Universal Plug and Play uses the Simple Service Discovery Protocol
(SSDP) for discovery of services on Internet Protocol based networks.
Simple Service Discovery Protocol can be operated with or without a lookup
or directory service in the network. Simple Service Discovery Protocol
operates on the top of the existing open standard protocols, using hypertext
Transfer Protocol over both unicast User Datagram Protocol and multicast
User Datagram Protocol. The registration process sends and receives data
in hypertext format, but has special semantics.
When a service wants to join the network, it first sends out an advertise (or announcement) message, notifying the world about its presence. In the case of multicast advertising, the service sends out the advertisement on a reserved multicast address. If a lookup (or directory) service is present, it can record such advertisements. Meanwhile, other services in the network may directly see these advertisements as well. The 'advertise' message contains a Universal Resource Locator that identifies the advertising service and a Universal Resource Locator to a file that provides a description of the advertising service.
When a service client wants to discover a service, it can either contact the service directly through the Universal Resource Locator that is provided in the service advertisement, or it can send out a multicast query request. In the case of discovering a service through the multicast query request, the client request may be responded by the service directly or by a lookup (or directory) service. The service description does not play a role in the service discovery process.
Salutation: A light weight network protocol independent service discovery protocol
Salutation is a service discovery and session management protocol developed by leading information technology companies . Salutation is an open standard, independent of operating systems, communication protocols and hardware platforms. Salutation was created to solve the problems of service discovery and utilization among a broad set of appliances and equipments in an environment of widespread connectivity and mobility. The architecture provides applications, services and formulates a standard method for describing and advertising their capabilities, as well as finding out the capabilities of others. The architecture also enables applications, services and devices to search for a particular capability, and to request and establish interoperable sessions with them.
The Salutation architecture defines an entity called the Salutation Manager (SLM) that functions as a service broker for services in the network. Different functions of a service are represented by functional units. Functional Units represent essential features of a service (E.g. fax, print, scan etc). Furthermore, the attributes of each Functional Unit are captured in the Functional Unit Description Record. Salutation defines the syntax and semantics of the Functional Unit Description Record (E.g. name, value). Salutation Manager can be discovered by services in a number of ways such as:
1. Using a static table that stores the transport address of the remote
2. Sending a broadcast discovery query using the protocol defined by the Salutation architecture.
3. Inquiring the transport address of a remote SLM through a central directory server. This protocol is undefined by the Salutation architecture, however, the current
specification suggests the use of Service Location Protocol (SLP).
4. The service specifies the transport address of a remote SLM directly.
The service discovery process can be performed across multiple SLMs.
A SLM can discover other remote SLMs and determine the services that are
registered there. Service Discovery is performed by comparing a required
service type(s), as specified by the local SLM, with the service type(s)
available on a remote SLM. Remote Procedure Calls are used to transmit the required Service type(s) from the local SLM to the remote SLM and to transmit the response from the remote SLM to the local SLM. The SLM determines the characteristics of all services registered at a remote SLM by manipulating the specification of required service type(s). It can also determine the characteristics of a specific service registered at a remote SLM or the presence of a specific service on a remote SLM by matching a specific set of characteristics.
Critical comparison of existing service discovery techniques
The protocols described above essentially use typical attribute or interface
matching to compare existing services in the network. Service Location
Protocol assumes the existence of an underlying Internet Protocol based
communication mechanism and uses User Datagram Protocol (UDP) to communicate.Salutation
in contrast is a network protocol independent architecture. The presence
of a transport manager in salutation shields the underlying communication
mechanism from the salutation manager. Thus salutation is expected to come
into prominence when non Internet Protocol based networks come into vogue.
Universal Plug and Play works at lower level protocol suites and its specification
is based on the assumption of an Internet Protocol type network underneath.
Both Service Location Protocol, Salutation and Universal Plug and Play are language independent protocols. The protocol specifications can be implemented in any language. Jini on the other hand is totally dependent on Java for its implementation. Java is a platform independent language which inturn makes Jini platform independent. In Jini, the interaction between services and users is defined in terms of an object interface, whereas in UPnP, the interaction is defined in terms of a network protocol. UPnP uses an Extended Markup Language (XML) based matching schema while discovering services. Jini of the otherhand uses java Interfaces.
UPnP and Salutation essentially uses multicasting to find out services or listen to broadcast service requests to find out location of desired services. Jini on the otherhand uses a centralized scheme where all types of services are registered to a lookup service. Users contact the lookup service to discover existing services in the network. Service Location Protocol implements a centralized directory based scheme as well as a multicast scheme for discovering services. While centralized schemes of Service Location Protocol and Jini are more scalable, they are also prone to single point of failures. Salutation unlike Jini is a lightweight protocol and makes the least assumption of the underlying protocol stack and computing resources. Hence it can easily be ported to low power handheld devices. Jini on the otherhand, due to its dependence on Java requires considerable computing resources to function properly.
Defeciencies in the existing service discovery architectures
All the above mentioned service discovery infrastructures and architectures
like Service Location Protocol (SLP), Jini, Universal Plug and Play (UPnP)
and Salutation have been developed to explore the service discovery issues
in the context of distributed systems. While many of the architectures
provide good base foundations for developing systems with distributed components
in the networks, they do not adequately solve all the problems that may
arise in a dynamic domain.
Some of the defeciencies are:
1. Lack of rich representation
Services in the Electronic Commerce are heterogeneous in nature. These services are defined in terms of the their functionalities and capabilities. The functionality and capability descriptions of these services are used by the service clients to discover the desired services. Attribute matching is a very important component for finding out the proper services in such an environment. The existing service discovery infrastructures lack expressive languages, representations and tools that are good at representing a broad range of service descriptions and are good for reasoning about the functionalities and the capabilities of the services. E.g.the service discovery protocols dosent use any performance parameters for the existing services. They are satisfied with finding out a service only. They dont consider whether the service would be able to serve the requester.
2. Lack of Inexact matching
In the Jini architecture, service functionalities and capabilities are described in Java object interface types. Service capability matchings are processed in the object-level and syntax-level only. For instance, the generic Jini Lookup and other discovery protocols allow a service client to find a printing service that supports color printing, but the protocols are not powerful enough to find a geographically closest printing service that has the shortest print queue. The protocols do exact semantic matching while finding out a service. Thus they lack the power to give a 'close match' even if it was available.
Enhanced service discovery techniques for Mobile Commerce
Having identified some of the common deficiencies in the existing service discovery techniques, we present a brief description of our work aimed at resolving the issues. One way of improving the service discovery mechanism is to apply Artificial Intelligence tools and techniques to the existing systems. The XReggie project concentrates on improving the attribute matching beyond trivial syntax based matching. With Ad-hoc networks and Agent based approaches coming up, it will be extremely necessary to communicate between different agent groups in different networks who speak different languages. In the Ronin project we have addressed this problem and provided a framework for such communications.
The Ronin Agent Framework
The Ronin Agent Framework is a Jini-based distributed agent development framework [2,4]. Ronin introduces a hybrid architecture, a composition of agent-oriented and service-oriented architecture, for deploying in dynamic distributed systems. Among many of the distinguishable features of the framework, Ronin offers a simple but powerful agent description facility that allows agents to find each other and an infrastructure that encourages the reuse of the existing non-Java Artificial Intelligence applications.
In Ronin, agents are described using two types of attributes: the Common Agent Attributes and the Domain Agent Attributes. The Common Agent Attributes and the Domain Agent Attributes are two sets of Jini service attributes that are associated with each Ronin agent in the Jini Lookup Service. The Common Agent Attributes defines the generic functionalities and capabilities of an agent in a domain-independent fashion. The Domain Agent Attributes defines the domain specific functionality of an agent. The framework defines the semantic meanings of each Common Agent Attribute, but it does not define the semantic meaning of any Domain Agent Attribute.
The Ronin description facility can enhance the Jini service discovery infrastructure for Mobile Commerce in the following ways:
1. As all agent-oriented Jini services, Ronin agents, share a set of
Common Agent Attributes, they can discover other services solely based
on the domain independent functionalities of the services.
2. Once a service has discovered another service using the Ronin description facility, it is possible for these two services to form basic communication negotiation based on the semantic meanings of the Common Agent Attributes. For instance, if a service has knowledge about the type of Agent Communication Language (ACL) that the other service speaks, they can start their conversation by following the pre-defined standard Agent Communication Language negotiation protocol.
The Ronin framework encourages the reuse of the existing non-Java Artificially Intelligent applications. The philosophy is that developing infrastructures, such as the service discovery in Mobile Commerce, that are highly adaptive, interactive, interoperable and autonomous requires more than just the Jini architecture. Developing infrastructures that are more "intelligent'' often requires sophisticated AI tools and techniques, such as inference engine, knowledge representation system, constraint programming etc. For instance, it would be useful for a Jini Lookup Service to be able to reason about the capabilities of its registered services, enabling the JLS to make more ``intelligent'' service lookup recommendations.
The Ronin framework provides a Jini Prolog Engine Service (JPES) . This service provides remote Prolog engine services to Jini-enabled components in the network. The JPES provides a distributed logical programming tool to the Jini-enabled services. An enhanced Jini Lookup Service can use the JPES to reason about the capabilities of services and can make more ``intelligent'' recommendations.
Adding descriptive powers to services through XReggie
The project XReggie investigates how Jini and similar systems can be taken beyond their simple syntax-based service matching approaches, adding expressive powers to the service descriptions. XReggie adds the facilities to describe service functionalities and capabilities using Extended Markup Language. XReggie allows service discovery to be performed in a more structured and descriptive fashion . At the heart of the XReggie is the enhanced Jini Lookup Service that provides ``service location'' for Jini-enabled services. XReggie can help service clients to discover services in a manner essentially unchanged from the existing Jini Lookup and Discovery infrastructure. In addition, it allows services to advertise their capabilities in a well-structured descriptive format using Extended Markup Language. Furthermore, XReggie allows services to be discovered using the Extended Markup Language descriptions.
This article describes service discovery architectures that would come into prominence with the advent of Mobile Commerce. As increasing number of people start using laptops and palm pilots, the need for connecting them to the internet and ubiquitous sharing and accessing of data will accentuate. The stationary computers connected to the Internet is no longer considered sufficient for 'any time' and 'anywhere' computing. Mobile Commerce and its proliferation is obviously leading us to a more refined and flexible way of accessing facilities from anywhere. A location based service oriented model is one of the most important necessities in such a distributed environment. A good Service discovery infrastructure will play an important role in such an environment. We have reviewed a number of existing service discovery infrastructures. We found that these infrastructures all suffer from one common problem, viz. lacking of the descriptive languages, representations and tools that are good at representing a broad range of service descriptions and are good for reasoning about the functionalities and the capabilities of the services. Lacking of infrastructures for defining common ontologism across enterprises and customers is another key problem in the existing service discovery infrastructures.
We have developed the Ronin Agent Framework and XReggie that aimed to
enhance the performance of the Jini service discovery infrastructure in
the future Mobile Electronic Market. The Ronin framework enhances the Jini
service discovery infrastructure by providing a simple but powerful description
facility and encourages the reuse of the non-Java tools in the Jini environment.
The XReggie project enhances the Jini service discovery infrastructure
by extending the existing Jini Lookup Service to handle service registration
and matching using the well-structured Extended Markup Language descriptions.
Dipanjan Chakraborty can be reached at email@example.com. He is a Ph.D. student and a Research Assistant in the Department of Computer Science & Electrical Engineering, University of Maryland Baltimore County. His research interests include Mobile and distributed computing, Electronic Commerce, Network Protocols, Ad-hoc Networks, Distributed Systems. He is a student member of ACM.
Harry Chen can be reached at firstname.lastname@example.org. He is a Ph.D. student
and a Research Assistant in the Department of Computer Science & Electrical
Engineering, University of Maryland Baltimore County. His research interests
includes Multi-Agent System, Mobile Computing, Pervasive Computing, Electronic
Commerce and Distributed Systems. The URL to his home page is http://www.acm.org/~hchen1/