A Mobile Fleet Application Case Study Using SyD Middleware

A Mobile Fleet Application Case Study Using SyD Middleware

Janaka Balasooriya (Arizona State University, USA), Sushil K. Prasad (Georgia State University, USA) and Michael Weeks (Georgia State University, USA)
DOI: 10.4018/978-1-61520-655-1.ch046
OnDemand PDF Download:
$37.50

Abstract

This chapter describes the implementation of a large fleet application based on SyD (System on Mobile Devices), a middleware technology for mobile devices. Although one is made to believe that a collaborative application that runs on a collection of heterogeneous mobile devices can be easily developed with the existing middleware technologies, the reality is that they require too many ad-hoc techniques as well as cumbersome and time-consuming programming. The authors’ SyD middleware has a modular architecture that makes such application development very systematic and streamlined. Features of SyD are illustrated here through the prototype application, a complex communication system for a trucking fleet that operates a package delivery system. The fleet system has been implemented employing three technologies, SOAP, JDBC, and SyD. Implementation experience shows that SyD greatly simplifies development and implementation by allowing heterogeneous devices, peer-to-peer communications, group transactions based on event triggers, and mobility support.
Chapter Preview
Top

1. Introduction

To develop an application that requires integrating a set of devices with different capabilities (e.g. mobile phone, PDA, PC, and server) with data distributed on these devices requires solving many problems. For each device, the programming may be different for both data storage and communications; for example, the selection and capabilities of database packages that work with small devices like a PDA is limited. Groups of devices may need to be formed spontaneously, and deal with unexpected situations. Finally, weak connectivity means that data may not be available when needed. In short, the application requires the following technical needs to be met:

  • 1.

    Heterogeneous device, data format and language support,

  • 2.

    Peer-to-Peer computing over dynamic groups,

  • 3.

    Group transactions: Autonomous Database Synchronization based on triggering events; group querying, and,

  • 4.

    Mobility support through proxies and directory service.

The current technology for development of a distributed collaborative applications (hereafter we call them collaborative applications) over a heterogeneous set of wired or wireless devices and networks limitations (Bellavista, P., Corradi,A., Giannelli, C., 2009), (Prasad, S. K., Madisetti, V., Navathe, S., B., et al., 2004). Such application development requires tedious programming on each kind of device, both for data access and for data communication. The application code is governed by the type of device, data format, and the network. The database server is typically a centralized logical entity providing only a fixed set of database services, with little flexibility for user-defined ad hoc services or the ability of user applications to dynamically configure a collection of independent data stores. Applications running across mobile devices are complex because of the lack of persistence of their data due to their weak connectivity.

A practical application that demonstrates the technical problems mentioned above is a truck fleet that operates an automated package delivery system. Figure 1 illustrates the communication architecture of our fleet application. In the fleet application, a user would connect through the Web and Data Center (WDC) web interface, request delivery of a package, and give information pertaining to the package, such as where the package can be picked up, its priority, and where it should be delivered. The WDC passes this on to a depot in the general geographic area of the package, which schedules a pick-up. A truck will arrive according to the schedule set by the depot, and take the package to its next stop, which could be the package’s destination, or some intermediate point between the package’s source and its destination. The trucks, depots and WDC form a heterogeneous network with different types of communications, and databases of varying capacity (Figure 1). The WDC and depots are assumed to have a wired network connection, but depots have wireless connections to their respective trucks. Also, the trucks can communicate with each other directly through their wireless devices.

Figure 1.

Communication in the fleet system

Key Terms in this Chapter

Quality of Service (QoS): The goal of QoS is to provide satisfactory services to the user while executing programs. This can be functional or non-functional features.

Tentative Transaction: Refers to a transaction that is committed without getting the full consent from all participants due to reasons such as unavailability to most recent data. Once all the participants are in a position to make the final decision on the transaction, either tentative transaction will be committed or rolled back.

Proxy (in Mobile Computing): Is a computer that has the authority to act on behalf of another computer (mobile device in our case).

Context Aware Computing: Context aware computing sought to deal with dynamic changes in the computing environment such as low bandwidth, low power, or (and) changes in the location.

Reconfigurable Middleware Systems: Middleware systems that can behave differently by activating and deactivating its components for different applications and environments. Changes in the middleware can be functional or non-functional.

Middleware: Is a software system that functions as the broker between two district applications. Usually, middleware systems abstract the functionality of underlying network, device, or other software applications by hiding system and network heterogeneity.

Complete Chapter List

Search this Book:
Reset