Pervasive Services on the Move: Smart Service Diffusion on the OSGi Framework
Summary (4 min read)
- Ubiquitous computing will become the next logical step to mobile computing where people are already connected anytime and anywhere.
- By breaking up an application into a configuration of independent services with well-defined interfaces, SOA enables the creation of new applications with the required flexibility to customize services to changing demands and different contexts.
- As such, the authors say that the same service has diffused to multiple hosts.
- It helps to select appropriate targets for service mobility and coordinate synchronization and access to services deployed on these devices, and learns for each service the devices the user will most likely interact with.
2 Requirements for service migration and diffusion
- Pervasive services offer a certain functionality to nearby users.
- They are accessed in an anytime-anywhere fashion and deployed on various kinds of mobile and stationary devices.
- When users or devices become mobile, proactive live service mobility to multiple hosts can provide a solution to the increased risk of disconnecting remote services.
- In this section the authors review several non-functional concerns and requirements that need to be fulfilled to ensure that the migration and diffusion of a service in a mobile and pervasive setting can be accomplished.
2.1 Device, service and resource awareness
- In a pervasive services environment, the multi-user and multi-computer interaction causes a competition for resources on shared devices.
- Therefore, knowledge about the presence, type and context of the devices (including resource-awareness about the maximum availability and current usage of processing power, memory, network bandwidth, battery lifetime, etc.) is a prerequisite to guarantee a minimum usability and quality of service.
- Before relocating a service to another host, a service discovery protocol (SDP) can be used to verify if the service is not already available .
2.2 Explicit service state representation and safe check-pointing
- Stateless services can be replaced with similar ones or redeployed on another host at runtime without further ado as long as the syntax and semantics of the interfaces remain the same such that the binding can be reestablished.
- Stateful services require a state transfer after redeployment before they can continue their operations on a different host.
- Furthermore, the service must be able to resume from the state it acquired.
- Therefore, services should model the properties that characterize their state and make sure that check-points of their state are consistent [7, 8].
2.3 State synchronization and support for disconnected operation
- Due to possible wireless network disruptions in the mobile setting of the user, complete network transparency of remote service invocations can have a detrimental effect on service availability and accessibility.
- The service platform should provide support to deal with intermittent network connectivity in order to recover from temporary failures in network connectivity between two services.
- With handover to replicated services whose states are synchronized, the effect of network disruptions can be reduced.
- Moreover, with discrete state synchronization, the requirement for continuous network connectivity can be mitigated.
2.4 Enhanced service life cycle management
- The service platform must provide functions to manage the life-cycle of services, such as deployment, withdrawal, starting, stopping and updating.
- The service life cycle management should move services to new hosts and replicate the state if necessary.
- This is the typical behavior of ‘follow-me’ applications that move along with the user.
- New replicas acquire the service state and get activated.
- As the effect of network disruptions cannot be mitigated completely, the authors must also clean up stale replicated services.
3 Context-aware service mobility on the OSGi framework
- In this section the authors will discuss how the previous requirements have been implemented on top of the OSGi framework .
- This lightweight service oriented platform has been chosen for its flexibility to build applications as services in a modularized form with Java technology.
- OSGi already offers certain functionalities that are needed to implement the service migration and diffusion requirements.
- OSGi is known for its service dependencies management facilities and the ability to deal with a dynamic availability of services.
- Moreover, OSGi can be deployed on a wide range of devices, from sensor nodes, home appliances, vehicles to high-end servers, and allows the collaboration of many small components, called bundles, on local or remote computers.
3.1 Extending service descriptions with deployment constraints
- These service properties are key-value pairs that help service requesters to differentiate between service providers that offer services with the same service interface.
- Service providers and requesters are packaged into a OSGi bundle, i.e. a JAR file with a manifest file that contains information about the bundle, such as version numbers and service dependencies.
- The above constraint declares that a device should have at least one Java virtual machine instance with a GUI rendering engine instance that belongs to the JavaAWT class.
- The main advantage of their context ontologies  is that complex semantic relationships only need to be specified once and can be reused by every service descriptor.
3.2 Context-awareness as an OSGi distributed declarative service
- In order to diffuse OSGi services in a way that takes into account the heterogeneity and dynamism of a ubiquitous computing environment, the authors need to be aware of what the characteristics and capabilities of these devices are, where they are located, what kind of services they offer and what resources are currently available.
- The COGITO service will provide this information on each host.
- These bundles monitor for context that is changing and gather information from resource sensors, device profiles and other repositories within the system itself or on the network.
- Besides a rule and matching engine that exploits semantic relationships between concepts , it also provides adapters that transform context information into more suitable formats.
- Upon joining a network, each other node in the network creates a remote proxy to the enabling service of the joining node, and the Declarative Services bundle will ensure lazy registration and activation of the proxy whenever remote context is acquired.
3.3 Service state representation, extraction and synchronization
- In order to replicate stateful services on multiple hosts with support for state synchronization, the authors need to explicitly model the state variables of the service, extract them at runtime and send them to the replicated peers.
- The approach is quite similar to the stateful session beans in the Enterprise JavaBeans specification .
- In their approach however, a JavaBean is situated locally within each replicated service and does not involve remote method calls.
- The authors current implementation tries to synchronize as soon as the state of an application has been changed.
- When network failures arise, the state updates are put in a queue and another attempt is carried out later on.
3.4 Extending the life-cycle management to relocate services
- In a ubiquitous computing environment where pervasive services are replicated, a user may switch from one replicated service to another.
- The authors add a revision number that is increased after each write operation on the bean and use Vector Clocks  among all peers to order the state updating events.
- Fig. 3 shows that an active service can not only be stopped, but that in another transition the state can be extracted from the service and synchronized, or that the service can continue to either migrate or replicate to a new host.
- The authors use a lease timeout algorithm to garbage collect stale replicated services in order to recycle resources.
- The timeouts are application dependent, but can be reconfigured by the user.
4 Experimental evaluation
- The usefulness and feasibility of dealing with context-aware service migration and diffusion will be illustrated with three applications: (1) a grocery list application, (2) a Jabber instant messaging client, and (3) a Sudoku game.
- The devices used in the experiment include two PDAs, a laptop and a desktop, all connected to a local WiFi network.
- This setup will simulate the real-life scenario in the next section.
- The scenario goes as follows: Everybody at home uses the grocery list application to make up a shared grocery list.
- They decided to split up the work and go shopping separately.
- He takes his briefcase, turns on his laptop, the application migrates and he continues the conversation there.
- “Back to the PDA but then without the picture”, dad decides.
- In the meantime, mom has arrived and dad tells her about the picture.
- In the experiment all the applications are launched on the desktop PC.
- Later on, the instant messaging application migrates from one PDA to the laptop and back (while synchronizing with the desktop PC).
- The bindings to the remote services are used to test handover to a replicated service after network disruptions.
- The authors let the setup run for 30 minutes, in which the following actions are simulated: – Each 30 seconds the grocery list is modified and synchronized.
- The authors measured the overhead of state transfer and synchronization and compare that to the resources that the applications required.
4.3 Discussion of the results
- The test results show there is only a small overhead for the state transfer.
- Other tests in multi-hop networks showed longer but still acceptable state synchronization delays (at most 5 times longer).
- Of course, this assumes the required bandwidth is available.
- Interesting to note for the handover to the replicated services (in their experiment, the stateless audio service and stateful log service), is that handover to another log service takes a bit longer on average.
- In their experiment, the remote services were only available on two hosts (the laptop and the desktop).
Did you find this useful? Give us your feedback
Related Papers (5)
Frequently Asked Questions (2)
Q1. What contributions have the authors mentioned in the paper "Pervasive services on the move: smart service diffusion on the osgi framework" ?
This paper explores live service mobility in pervasive computing environments as a way to mitigate the risk of disconnections during service provision in mobile ad hoc networks. The authors analyze the basic requirements for service mobility and discuss an implementation on top of OSGi. Finally, the authors evaluate their approach to service mobility and illustrate its effectiveness by means of a real-life scenario.
Q2. What are the future works mentioned in the paper "Pervasive services on the move: smart service diffusion on the osgi framework" ?
Future work will focus on a better handling of state synchronization conflicts and improving the state encapsulation approach to deal with incremental state transfers for data intensive applications. The outcome of this future work could result in a better policy with respect to on how many remote devices a service should be replicated and under which circumstances service migration would be a better approach compared to service diffusion. However, their main concern will always be to keep the supporting infrastructure flexible and lightweight enough for lowend devices with room left to actually run applications.