Additional Fundamentals
A.2 Service Provisioning Frameworks
A.2 Service Provisioning Frameworks
Whereas Section 3.3 describes the fundamentals ofservice provisioning, this section presents some of the available protocols with relation to service pro-visioning. Thereby, each protocol has different functionality and deals only with a subset of service provisioning, mainly service discovery.
First, some popular solutions for conventional networks, thus for wired network with low latency, reliable links and enough bandwidth, are pre-sented: SLP (A.2.1), Jini (A.2.2), UPnP (A.2.3), Bluetooth (SDP) (A.2.4) and Salutation (A.2.5).
UPnP and SDP are simple low level protocols that focus on device au-tonomy. SLP assumes an underlying Internet protocol based communica-tion. Salutation is a network protocol independent architecture and attach importance to inter-operability of services. Jini is dependent on the Java language and thus requires considerable computing resources to function properly. All these protocols use typical attribute or interface matching to compare existing services in the network.
Salutation uses multicasting to request and advertise services. SDP of-fers only a method for searching offered services in the neighbourhood, and is not able to advertise services. Jini uses a centralized scheme where all types of services are registered to a lookup service. UPnP and SLP imple-ments a centralized directory based scheme as well as a multicast scheme for discovering services. Table A.4 gives a comparison of these frameworks.
Unfortunately, these approaches are not well suited for mobile ad hoc network with high dynamic topologies, high latency and unreliable links.
Also device capabilities and limitations, as well as user and application pref-erences should be taken into consideration. Users of mobile devices should have the ability to control in which way their device resources are used.
Therefore some policies should be defined in the service provisioning frame-work.
Therefore architectures specifically adapted for mobile ad hoc networks have been proposed.
GSD(A.2.6) is based on group-based forwarding of messages and caching of service advertisements. For service description a semantic language is used. Allia (A.2.7) is a caching-based and policy driven service discovery
SLP Jini UPnP SDP Salutation
Appendix A.2.1 A.2.2 A.2.3 A.2.4 A.2.5
Service Specification X X X X X
Service Indication X X X X X
Service Deployment X X
Service Management X
Environment Observer
Push (Advertisements) X X
Pull (Requests) X X X X
Central Directory X X X
Scalability X X X
Table A.4: Conventional Service Provisioning Frameworks
framework that actively forms alliances between nodes. Lanes (A.2.8) are based on a two-dimensional overlay structure andDSDP(A.2.9) on a virtual backbone for service discovery.
Konark (A.2.10) is a service discovery and delivery protocol that as-sumes IP level connectivity and specifies its own description language. SSDP (A.2.11) and DEAPspace (A.2.12) are simple service discovery protocol for short range networks. GCLP (A.2.13) is uses device location information to lower proactive traffic. And finallyNom (A.2.14) is based on a simple P2P protocol.
In Table A.6 a comparison of this protocol is given.
Finally, in Section A.2.15, Chameleon, a platform for automatic service composition, is shortly depicted.
To improve the availability and scalability of services, paper [46] proposes a caching service for Web Services in mobile ad hoc networks. A simple mechanism with little communication overhead is described. Thereby the first node that accesses a service becomes the proxy of this service. If a node acting as proxy becomes too loaded, it can pass the job to other less loaded nodes. The load information is gossiped in the background among the devices.
A.2ServiceProvisioningFrameworksAppendixA
GSD Allia Lanes DSDP Konark SSDP DEAPspace GCLP Nom Appendix A.2.6 A.2.7 A.2.8 A.2.9 A.2.10 A.2.11 A.2.12 A.2.13 A.2.14
Service Specification X X X X X
Service Indication X X X X X X X X X
Service Deployment X
Service Management
Environment Observer X
Proactive partial partial partial partial partial X X
Reactive partial partial partial partial partial X X
Scalability X X X X X X
Table A.6: Comparison between Service Provisioning Frameworks for Mobile Ad hoc networks
73
Another interesting attempt for service provisioning can be found in Distributed Agent Systems. Refer to FIPA [63] or JADE [64] for more infor-mation about such system.
A.2.1 Service Location Protocol (SLP)
TheService Location Protocol (SLP) [47] is an IETF protocol that provides a scalable framework for the discovery and selection of network services.
It allows but does not require centralized administration. SLP is language independent, thus can be implemented in any program language. The dis-covery is based on service attributes and can handle both hardware and software services. SLP has been designed to serve enterprise networks, and it may not necessarily scale for wide-area networks.
The infrastructure consists of three types of agents. Client applications are modeled as User Agents, services are advertised by Service Agents and Directory Agents act as a centralized repository for service location infor-mation to provide scalability to the protocol. The Services are grouped together using scopes.
Figure A.2: Service Location Protocol Operation (with and without Direc-tory Agent)
(taken from http://www.mactech.com/articles/mactech/Vol.15/15.10/ServiceLocation/)
The protocol allows User Agents to directly issue Service Requests to Service Agents using multicast (Figure A.2). This Service Requests specify the characteristics of the required service. Service Agents answer with a Service Reply specifying the location of all services in the network which satisfy the request.
Beside Service Request to obtain the location of a service there exists alsoAttribute Request to request the attributes of a service andService Type Request to request the types of services that are available.
A.2 Service Provisioning Frameworks Appendix A
In larger networks Directory Agents can be used, to cache cache service location and attribute information. They enhance the performance, robust-ness and scalability of SLP. User and Service Agents can discover Directory Agents by issuing a multicast Service Request for Directory Agent or by listen to infrequently sent Directory Agent Advertisement.
A.2.2 Jini (Java Intelligent Network Interface)
The Jini network technology [48], developed by Sun Microsystems, is an environment for creating dynamically networked components, applications and services based on Java (Figure A.3). Jini provides simple mechanisms to enable devices to form ad hoc network communities, called Jini federations.
Devices in a federation may share services and information with other mem-bers. It provides mechanisms for devices to join and detach from network dynamically without the need for configuring each device.
Figure A.3: Jini network technology
(Copyright Sun Microsystems)
A service advertise itself by publishing a Java object that implements the service API. The client finds services by looking for an object that supports the API. After a appropriate service is found, the client will download any code it needs in order to talk to the service, thereby learning how to talk to the particular service implementation via the API. The downloaded Java object implements the service chooses how to translate an API request into network communication.
The central mechanism of a Jini system is theLookup Servicethat regis-ters devices and services available on the network. It is also the major point of contact between the system and the users of the system.
When a device is plugged into the network, it locates the lookup service and registers its service there. Services from other devices can be accessed, by querying the lookup service for the desired service and then invoking the downloaded interface of the service. Registration information can have attribute/value pairs that are amenable to querying. Service developers can also come to agreement on the network interface methods for specific services, so that the service can be accessed by universal code.
The Jini technology implementation is rather resource demanding, and therefore can be unsuitable for resource-constrained mobile devices. Also, since the code mobility gives services access to other machines, security is a mayor challenge.
A.2.3 Universal Plug and Play (UPnP): SSDP
UPnP [49], pushed primarily by Microsoft, is a framework defined at a much lower level than Jini. UPnP is providing a set of defined network protocols and based on the Internet protocol suite, instead of the application level.
For service announcement and discovery SSDP (Simple Service Discov-ery Protocol) is used, which can operate with or without a lookup direc-tory service in between. In SSDP the registration/query process sends and receives data in HTTP format over both unicast and multicast UDP (Fig-ure A.4).
A device joining the network announce itself with a multicast message that contain a URI that identifies the resource (e.g. ”dmtf:printer”) and a URL to an XML file that provides a description of the device. The XML file uses a style sheet tailored to various types of devices. A query for device discovery can also be multicast, to which devices may respond directly, or it may be directed towards a directory service if present. Queries are only targeted on the URI and not the XML descriptions. After device discovery, its XML description can be retrieved and proprietary protocols can take over in communicating with the devices.
UPnP also addresses the problem of automatic assignment of IP ad-dresses and DNS names to a device being plugged in.
A.2 Service Provisioning Frameworks Appendix A
Figure A.4: Universal Plug and Play (UPnP)
(Copyright Microsoft Corporation)
By concentrating on base level discovery and device capability querying only, UPnP does not address how to invoke services.
A.2.4 Bluetooth: Service Discovery Protocol (SDP)
The Service Discovery Protocol (SDP) [50] is a Bluetooth defined protocol to discover which services are available and to determine the characteristics of those available services.
SDP is a simple protocol with minimal requirements on the underlying transport. It only provides basic methods for searching and recognition of devices and services, without addressing utilization and maintenance of services.
The characteristic of a service is described by a list of service attributes.
Each service is an instance of a service class, that provides the definitions
of all attributes of the service. For each service class and for important attributes of services a Universally Unique Identifier (UUID) is assigned.
To search services, only attributes whose values are UUIDs can be used.
For service discovery SDP offers searching for a specific service, as well as browsing to see what services are actually being offered.
A.2.5 Salutation
The Salutation architecture [51] is a service discovery and session manage-ment protocol developed by a corporation of several companies (e.g. IBM).
It is an open standard and tries to find a balance between device auton-omy and standardization. Salutation is, unlike Jini, UPnP, SDP and SLP, independent of operating systems, communication protocols and hardware platforms.
The Salutation architecture defines an entity called theSalutation Man-ager (SLM) that functions as a service broker for services in the network.
The SLM, which can be located in the same device or remotely, does ev-erything on behalf of its clients. It is also responsible for the data transfer between devices, including those across different media and transport proto-cols (Figure A.5). All registration is done with the local or nearest available SLM. The framework provides also call-backs into the devices to notify of events like data arriving or devices becoming unavailable.
Services are described as a set ofFunctional Units that contain parame-ters with well-defined syntax and semantic. The Salutation Consortium has defined a number of Functional Units that identify features of various ser-vice classes. This standard definitions allow easier inter-operability, because generic drivers for a class of service can be used.
To discovery a service, this functional units can be queried and matched against. Certain well defined comparison functions can be associated with a query. The discovery request is sent to the local SLM which in turn will be directed to other SLMs. SLMs can be asked to periodically check the availability of functional units, to aware when a service has left the scene.
The communication between clients and services can operated in one of 3 different modes. In thenative modemessages are exchanged directly through a native protocol without the SLMs getting involved in data transfer. In the
A.2 Service Provisioning Frameworks Appendix A
Figure A.5: Salutation Architecture
(taken from
http://www.spectrum.ieee.org/WEBONLY/publicfeature/mar01/netf2.html)
emulated mode the SLMs will manage the data transfer, which provides transport protocol independence. In thesalutation mode the SLMs not only carry messages, but also define the message formats to be used in the session, which allows generic inter-operability using well-defined APIs.
It exists also a scaled down version of the Salutation Architecture, called Salutation-Lite, targeted at resource poor devices in a environment of wide-spread connectivity and mobility. The technology provides a standard method to describe and advertise the capabilities of services and devices to other ser-vices and deser-vices.
A.2.6 GSD: Novel Group-based Service Discovery Protocol for MANET
GSD is a group-based distributed service discovery protocol for mobile ad hoc networks [56]. It is based on the concept of peer-to-peer caching of service advertisements and group-based intelligent forwarding of service re-quests to reduce the broadcast storm problem. It does not require a service to register to a lookup server.
For service description the semantic capabilities offered by the DARPA Agent Markup Language (DAML) are used to effectively describe services and resources present in the network. This language supports ontologies to achieve flexibility in service matching and is therefore well suited for the heterogeneity of services in a mobile ad hoc networks.
The services present on the nodes are classified into hierarchical groups.
Each node advertises its services to its neighbors within a defined number of hops. An advertisement also includes a list of the several service groups that the sender node has seen in its vicinity. This group information is used to intelligently selectively forward a service request to other nodes in the network where there are chances of service availability. Thus, the semantic features present in DAML is used to reduce network flooding.
In other words, by maintaining the local advertisement, a node has infor-mation about all the services present in his vicinity, as well as inforinfor-mation about available service groups that may can be reached through a particu-larly node in his vicinity. Thus, instead of broadcasting a request, a node selectively forwards the request to those nodes that have seen the same group of services in its vicinity.
A.2.7 Allia: Alliance-based Service Discovery for MANET Allia is a peer-to-peer caching based and policy driven service discovery framework to facilitate service discovery in mobile ad-hoc networks [58].
The approach adapts structured compound formation of agent communities to the mobile environment and achieves high degree of flexibility in adapt-ing itself to the changes of the ad-hoc environment. The framework takes into consideration device capabilities and limitations, as well as user and application preferences regarding usage of the devices. This gives the users of mobile applications the ability to control the ways in which their own resources are utilized.
The main goal of the platform formation is to provide an agent better access to services in the vicinity.
An agent actively forms its own alliance and passively joins other al-liances in an environment. An alliance helps in service discovery and the alliance formation does not have the overhead of explicit leader election. An alliance of a particular node is a set of nodes whose local service information
A.2 Service Provisioning Frameworks Appendix A
is cached by this node. Thus, a node explicitly knows the member nodes in its alliance. However, a node is not aware of the alliance where it is a mem-ber of. Whenever a node leaves a certain vicinity, and enters a new vicinity, it constructs its own alliance by listening to advertisements. It also becomes a member of other alliances by advertising its local services. Therefore a node do not need to register or deregister with the alliances when it changes its location.
Policies can be used to reflect device capability as well as to restrict platform functionality to take user, application and network preferences into consideration. Policies can specify caching, advertisement and forwarding preferences. Policies can also be used for security restrictions like access rights and credential verification.
When an agent needs to discover a certain service, it first looks at its local platform to check whether that service is available. On failure, it checks the members of its alliance to discover the service. If the service is still unavailable, the source platform tries to broadcast or multicast, depending on his local policy, the request to other alliances in its vicinity. To take care of network resources policy-based multicasting can be used, where the node multicasts the request to other nodes in its vicinity where there are greater chances of obtaining the service.
By passive caching of advertisements rather than actively pulling of ser-vice descriptions from neighboring nodes, network changes can be detected.
Also advertisement collision are not as frequent as in pull-based paradigm, where, in respond to a particular request, the advertisements from different nodes can collide with each other at the receiver.
A.2.8 Lanes: Lightweight Overlay for Service Discovery in MANET
Lanes are application layer overlays to discover services offered in a mobile ad hoc network [54]. They offer a fault-tolerant and efficient structure, which can be used for semantics-based service discovery. Admittedly, a concrete service description is not addressed in the paper and the approach is service description independent.
Lanes are based on theContent Addressable Network (CAN), a scalable indexing system for large-scale decentralized storage applications on the
Internet. A Distributed Hash Table (DHT) is used to associate hash values (keys) with some kind of content in a distributed and decentralized way.
Participants in the DHT each only store a small section of the contents of the hashtable and thus provide scalability.
Figure A.6: Lanes
(taken from [54])
The basic concept of Lanes is a two-dimensional overlay structure (Fig-ure A.6), called lanes, which is similar to, but less strict than the one used in the CAN. One dimension of this overlay propagates service advertisements, the other one distributes service requests. A proactive operation is used within one lane (allowing to use unicasts to well-known predecessors and successors) and a reactive operation is used between the lanes (leading to anycasts to reach an arbitrary node in neighboring lanes). Thus, a node has only to maintain the information of its lane.
Within a lane, there is a strict relationship of predecessors and successors and also the lanes are arranged in a well defined order. Nodes in the same lane share the same anycast addresses and can be treated equally form the outside. A large lane that consists of too many nodes, can be divided into two neighboring lanes and short lanes can be combined to one new lane.
As the nodes are well arranged in a lane, only one periodic ping message
A.2 Service Provisioning Frameworks Appendix A
per node to its successor is require to maintain a lane.
Lanes tries to be a good compromise between weakly structured ap-proaches, which are easily adapted to network characteristics but typically scale poorly, and highly structured approaches with optimal adaptability to user profiles at the cost of highly inefficient maintenance in dynamic network topologies.
A.2.9 DSDP: Distributed Service Discovery Protocol
DSDP is a distributed service discovery architecture which relies on avirtual backbone for locating and registering available services within a dynamic network topology [59].
The proposal consists of the formation of a virtual backbone, as well as distribution of service registrations, requests, and replies.
The dynamic virtual backbone is formed from a subset of the network nodes, such that each node in the network is either a part of the backbone
The dynamic virtual backbone is formed from a subset of the network nodes, such that each node in the network is either a part of the backbone