A Mobile Service Provisioning Middleware 

Get Complete Project Material File(s) Now! »

Chapter 3 Odin: A Mobile Service Provisioning Middleware

Through our initial investigation into the challenges inherent in mobile service provi-sioning, and the degree to which current solutions (at the time) met those challenges, we determined that, while each challenge had been addressed to some extent in the literature, there was no holistic approach to mobile service provisioning which addressed all challenges sufficiently while still allowing developers to easily create mobile services. To provide such a solution, we designed, developed and evaluated our own mobile service provisioning middleware with this holistic goal in mind. We dubbed this middleware, Odin.¹
In this chapter, we initially outline the requirements for Odin in section 3.1, as deter-mined by the literature review. In section 3.2, we then provide a brief outline of the key technologies utilized by Odin. Section 3.3 provides an overview of the Odin middle-ware itself. We then provide a brief evaluation of the prototype in section 3.4, prior to concluding the chapter in section 3.5.
Note that this chapter outlines work carried out as part of this thesis, in conjunction with work carried out by Thiranjith Weerasinghe as part of his Masters thesis [3]. Table 3.1 summarizes each of Odin’s features, and details the contributors to those features.

Requirements

From the initial investigation into the challenges inherent in mobile service provisioning, we drew the following set of requirements:

Functional Requirements

Odin should:
FR #1: Expose mobile services to external clients – Clients should be able to discover and consume services provided by host devices. Host devices should be able to expose services over any wireless network.
FR #2: Switch between available network connections within a host device – Hosts should be able to switch between Wi-Fi, 3G, Bluetooth, and / or other network types when hosting a service. Such a switch should be transparent to clients, including those clients with ongoing communication with that service.
FR #3: Support multiple modes of communication – Odin must be able to sup-port request-response, publish-subscribe, and streaming communication between any client and service.
FR #4: Maintain connectivity between clients and host devices – Failures in un-derlying mobile networks should be handled by Odin such that connectivity is maintained, possibly over an alternative network. This process should be transpar-ent to clients.

Non-Functional Requirements

NFR #1: Performance – Odin should not impose excessive bandwidth or latency overheads when compared with a direct communication link across the same network interface.
NFR #2: Scalability – Odin should detect variations in the number of clients accessing a particular mobile service, and take steps to increase available resources for that service when necessary.
NFR #3: Availability – Odin must ensure that mobile services are made available for as long as possible. This includes allowing services to communicate over a variety of networks in case of the failure of a particular network, as well as optimizing battery usage to increase the battery lifespan of a device.
NFR #4: Simplicity – Odin should provide a well-defined API, and hide the complexities involved with managing multiple network channels.
NFR #5: Interoperability – Clients need not have any knowledge of Odin in order to consume services, other than the protocol chosen as the client-to-middleware com-munication protocol.

Supporting Technologies

During the development of Odin, several technologies were investigated and adopted.
This section details the most notable of these.

Jini

Jini is a Java-based distributed service oriented middleware platform [14]. It provides a platform to facilitate interaction between different software and hardware entities, irrespective of the differences in their communication protocols, drivers or operating systems [14]. Our primary motivation for the choice of Jini is its support for protocol independence, configurability and fault tolerance. A core objective of Jini is to enable dynamic addition and removal of services from a Jini federation, which consists of clients and services connected together by Jini middleware [14, 38]. Though based on the Java programming language, Jini is language-independent by allowing non-Java objects to be wrapped within Java code [14]. However, it requires both the service consumer (client) and the provider to support Jini middleware [14].
Figure 3.1 presents the key interactions between different parties in a Jini federation. It can be observed that the design closely follows the traditional SOA paradigm. Jini services, clients and the Lookup Service make up the three core components of the SOA. The Jini Lookup Service (LUS) is a service provided as part of the Jini middleware that acts as a distributed service registry to enable clients to discover services. When joining a Jini federation, services first use a discovery protocol to find a list of LUSs. The discovery protocol can operate either using multicast discovery to locate all LUSs in a specific network, or unicast discovery to locate a LUS at a known address. Services then use the join protocol to register with each discovered LUS. This involves sending a proxy for the service, along with a description which can be searched by clients to identify the service. Services are also given a service id, which uniquely identifies it. Clients then discover LUSs using the same discovery protocol used by services. Once discovered, they search these LUSs for required services based on service name, service id, and / or service metadata.
In addition to decentralized service registries, protocol independence and code mobility, Jini middleware provides various mechanisms to handle common network problems such as latency, low bandwidth and certain classes of failures [14]. This is enabled by various built-in Jini services and a robust infrastructure implementation [14, 38]. The infrastructure provided by Jini helps to seamlessly move objects between clients and services.
Jini addresses failure of clients and services through leasing [14]. For example, services are responsible for periodically notifying LUSs about their availability; if they fail to renew their leases the LUSs will assume that the service is no longer alive and dereference it. This makes the Jini federation self-healing, enables efficient use of resources and makes it possible for clients and services to join/leave a Jini federation at anytime without interrupting other participants. In addition to leasing, distributed events is another important Jini component. It provides support for remote event registration and reliable delivery of remote events, enabling richer services to be built. For example, an ambulance may subscribe to an event on our patient monitoring service to be notified when a patient’s vital signs fluctuate.
Finally, Jini provides several standard services designed to assist clients and services participating in a Jini federation. The LUS is one example of this, and is compulsory for all Jini federations. Other examples include Javaspaces, which provides data storage; and a transaction service for distributed transactions [14, 38].

Jini Surrogate Architecture

Jini provides many features essential for a SOA. However, clients and services are con-strained to use the Jini middleware, which necessitates the use of a full JVM, which many mobile devices do not offer. The Jini Surrogate Architecture (JSA) [39] was designed to allow devices not running a full JVM to participate in a Jini federation via an intermedi-ary machine known as a Surrogate Host (SH). Figure 3.2 shows how the Jini architecture can be extended to include the JSA. A device wishing to participate in a Jini federation discovers a SH using a protocol similar to, but distinct from, the Jini discovery protocol. The device then sends a Surrogate to the SH, which in turn registers the Surrogate as a Jini service, participating in the federation on behalf of the device. Communication between the Surrogate and Device occurs via an Interconnect, the implementation details of which are left up to service developers.

Jini Extensible Remote Invocation (JERI)

JERI is an upgrade over Java’s standard Remote Method Invocation (RMI) protocol. Using JERI, the stubs usually created at compile-time for RMI applications are instead created at runtime using Java’s dynamic proxy support. JERI is also extensible, allowing developers to customize the behavior of its transport and invocation layers [14]. Odin uses this extensibility support to allow clients to continue to communicate with mobile services during and after surrogate migration (see section 3.3).

Technological Overview

Odin’s architecture follows the Jini Surrogate Architecture outlined in section 3.2. Clients simply see Odin services as Jini services, and they discover and interact with them in an identical manner. In this way, the complexities involved with mobile service provisioning are masked from clients.
Figure 3.3 shows a high-level overview of Odin’s layered architecture. Service developers write code for the Application layer on both the device and surrogate, which will then be hosted on a surrogate host. Within the application layer, the device’s Service module, and the surrogate’s Surrogate module, are the primary modules which service developers must implement to provide their service business logic. The Context Source module provides information to Odin’s context-awareness functionality (see section 3.3.3) to inform to allow Odin to be informed of various changes in state.
Within Odin’s Management layer, the Management module is responsible for performing vertical handover (section 3.3.1) and surrogate migration (section 3.3.2). The Context Acquisition module is responsible for gathering raw data from context sources and sending it to the surrogate host’s context processor, while the Context Adaptation module receives instructions based on changes in context to inform the management module whether vertical handover or migration is required (see section 3.3.3).
 The surrogate host’s management layer has further components not located on the host device. The Context Processor module interprets the data from the context sources to determine whether any config changes are necessary. This is located on the host only to free the device’s computational resources from this calculation. The Discovery module constantly listens over available network channels for new devices that wish to connect.
The Export Server module exposes surrogates as Jini services. Finally, the Surrogate Management module stores surrogate instances and manages their lifecycle.
Within the Transport layer, the Reservoir module is responsible for the marshaling and unmarshalling of data using Odin’s data factories, while the Interconnect module is responsible for communication between host devices and surrogates, while managing interruptions in connectivity in association with the reservoir module (see section 3.3.1).
The Data Factory module, located in all layers, allows data to be marshaled and un-marshaled, for communication between a host-device and its surrogate. The serialization process does not depend on the Java serialization mechanism or any other platform-specific protocol – it only requires that a device is capable of writing to / reading from a byte stream. Developers may extend the provided data factories when support for custom data types are required (as is usually the case).

Communication Protocol and Vertical Handover

Odin provides a messaging abstraction to service developers for communication between the device and the surrogate. Odin supports request-response, asynchronous, and stream-ing messages, as dictated by its requirements. To add a particular message type to a system, developers must create a class representing that message, and and entry in the data factory on both the surrogate and device which is responsible for marshaling and unmarshalling those messages. Streaming is obtained by chaining messages. Whenever the host device or surrogate wishes to send a message through the interconnect, it must marshal that message and pass it to the interconnect layer for further processing. Sim-ilarly, the application layer is notified of any received messages, which must then be unmarshaled.
Figure 3.4 shows the classes within Odin’s interconnect layer which are important for message sending and vertical handover. The InterconnectManager can be accessed by a developer’s code on the device or surrogate. Marshaled messages to send are deposited here, while the manager additionally notifies the application layer of received messages, which can be retrieved here. The InterconnectManager contains one or more Interconnec-tAdapter instances – one for each supported interconnect type. By default, Odin provides a HTTP, a TCP, and a Bluetooth adapter. Adapters are responsible for letting the manager know whether or not connectivity is currently available over a particular network interface, and, if so, reading from and writing to the data reservoirs holding marshaled data await-ing transmission or retrieval. The OutgoingDataReservoir contains marshaled message data awaiting transmission across the interconnect, while the IncomingDataReservoir holds received marshaled message data awaiting retrieval an unmarshalling by the appli-cation layer. Figure 3.5 shows the flow of data from an OutgoingDataReservoir, across an active interconnect channel, to an IncomingDataReservoir.

Contents
Abstract 
Acknowledgements 
List of Figures 
List of Tables 
1 Introduction 
1.1 Example Mobile Services
1.2 Research Questions
1.3 Research Contributions
1.4 Thesis Outline
2 Literature Review 
2.1 Challenges with Mobile Service Provisioning
2.2 Mobile Service Provisioning Middleware
2.3 Addressing Reachability
2.4 Addressing Availability
2.5 Addressing Scalability
2.6 Addressing Testability
2.7 Addressing Heterogeneity
2.8 Summary
3 Odin: A Mobile Service Provisioning Middleware 
3.1 Requirements
3.2 Supporting Technologies
3.3 Technological Overview
3.4 Evaluation
3.5 Summary
4 Odin2: A Robust, Cross-Platform Mobile Services Middleware 
4.1 Requirements and Features
4.2 Supporting Technologies
4.3 Architectural Overview
4.4 Connection and Device Registration
4.5 Messaging
4.6 Error Handling
4.7 Cross-Platform Support
4.8 Summary
5 OdinTools: A Model-Driven Tool for Cross-Platform Development of Odin2-based Applications 
5.1 Design
5.2 Service Development with OdinTools
5.3 Summary
6 Odin Test Harness 
6.1 Requirements
6.2 Design
6.3 Test Harness API
6.4 Example Test Scripts
6.5 Test Harness Evaluation
6.6 Summary
7 REMOTE-CR: An Odin2-enabled Telemed System for Cardiac Rehabilitation
7.1 Background
7.2 Requirements
7.3 Design Overview
7.4 Leveraging the Odin2 Middleware
7.5 Summary
8 Evaluation 
8.1 Performance Evaluation
8.2 Odin2 Expressiveness
8.3 Productivity with OdinTools
8.4 Test Harness Evaluation
8.5 Real-World Usage
8.6 Summary
9 Conclusions and Future Work 
9.1 Research Contributions
9.2 Answers to Research Questions
9.3 Future Work
GET THE COMPLETE PROJECT
A Holistic Approach to Mobile Service Provisioning