SyD: A middleware infrastructure for mobile iAppliance devices -

SyD: A middleware infrastructure for mobile iAppliance devices

It is generally assumed that a collaborative mobile wireless application that runs on a collection of heterogeneous iappliance devices can be easily developed with the existing Web services middleware technologies such as JXTA, BREW, compact .NET and J2ME. The harsh reality is that they also require the extensive use of ad-hoc techniques and cumbersome time-consuming programming.

However, a System on Mobile Devices (SyD) middleware framework, prototyped as part of State of Georgia's Yamacraw Project, has a modular architecture that makes such application development very systematic and streamlined, despite running on devices of varying capabilities(pagers, cell phones, PDAs, PCs, etc.).

From the current perspective of Internet-centric embedded devices and small footprint personal computing iappliances, first prototypes of this architecture indicate that it can be deployed in most remote clients on a memory footprint of only 112 KB. Of this, 76 KB is device-resident, with most of the necessary functionality maintained on a central location outside on a server for directory and global event handling. For even smaller devices, this can be further reduced to 42 KB. And for a fully peer-to-peer version, all of the 112 KB is on the device.

In the SyD prototype for the Yamacraw Project, various existing commercial hardware and software elements were used or integrated into the framework including:

1. HP's iPAQ models 3600 and 3700 with 32 and 64 MB storage running Windows CE/Pocket PC OS interconnected through IEEE 802.11 adaptors cards and a 11 MB/s Wireless LAN;
2. Jeode EVM personal java 1.2 compatible, implementing Java Virtual Machine;
3. Instant DB version 3.26 on iPAQ for databases for various applications;
4. TCP Sockets for remote method invocation and JAVA RMI for local method execution through reflection; and,
5. the use of the XML standard for all inter-device communication.

Limits of existing frameworks

In general, current alternatives, such as JXTA, Proem, Jini Microedition, Microsoft's .NET, UPnP, and Websphere are not adequate to the needs of this environment. The reason is that they each lack one or more of three key functions to be a successful device-to-device middleware building block: a uniform connected view, or framework; a high level development and deployment environment; and the availability of easily implemented peer-to-peer and other distributed server-based connectivity alternatives.

Using existing methodologies, developing an application requires explicit and tedious programming on each kind of device, both for data access and for data communication. The application code is specific to the type of device, data format, and the network. The data-stores are typically a centralized logical entity providing only a fixed set of 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 and unreliable connectivity. There are only a few existing middleware frameworks which address the stated requirements. But they are, variously, not completely functional at this time;enable only client-side programming on mobile devices; are geared to a limited domain of applications; or are limited in group or transaction functionalities or mobility support.

The proposed System of Mobile Devices (SyD) architectural framework successfully addresses the key problems of heterogeneity of device, data format and network, and that of mobility by building on one simple, but powerful idea: separating device management from management of groups of users and/or data stores.

In this approach, each device is managed by a SyD deviceware wrapper that encapsulates it. Its function is to present a uniform and persistent object view of the device data and methods. Groups of SyD devices are managed by the SyD groupware that brokers all inter-device activities, and presents a uniform world-view to the SyD application to be developed and executed on. All objects hosted by each device are published with the SyD groupware directory servicethat enables SyD applications to dynamically form groups of objects hosted by devices, and operate on them in a manner independent of devices, data,and underlying networks.

The SyD groupware hosts the application and other middleware objects, and provides a powerful set of services for directory and group management, and for performing group communication and other functionalities across multiple devices. SyD encapsulates different devices into a persistent object framework thus addressing device and data heterogeneity problem. The uniform object view is enabled by SyD deviceware and its persistence is enabled jointly by the deviceware and the groupware.

Each server application hosted on a mobile device maintains its proxy on a wired device, intelligently synchronizes with it to allow flexible, partial, transactions, and keeps the SyD groupware updated on its connectivity and power-on status, all aided by the deviceware. The groupware's dynamic directory intelligently switches between an application and its proxy, based on its availability and timeout mechanisms.

Each device is a database

In the SyD approach, each physical device in an Internet-centric collection of cooperating elements is represented by a independent databases which collaborate with each other in a mobile environment.

Individual devices are represented in SyD by a variety of database instantiations. Each could variously be represented by a traditional database such as relational or object-oriented, an ad-hoc data store such as a flat file, an EXCEL worksheet or even a list repository. Thesemay be located in traditional computers or in personal digital databases where they would collect the results of the queries, and (by writing code) that the databases as a whole need to satisfy.

A problem with the current technology is that it is difficult to deal with multiple types of heterogeneity — one individual may have a relational database while others may be using a flat file to record their schedule data.

To maintain consistency in such a diverse environment, SyD consists of three levels of interrelated functionality. (Figure One, below). At the lowest layer, individual data stores are encapsulated by device objects. These device objects export the data that the device devices hold along with methods/operations that allow access, as well as manipulation of this data in a controlled manner.

Figure 1:SyD has three levels of functionality

This cooperative computing environment is enabled by SyD deviceware consisting of a listener module to register objects and to execute local methods in response to remote invocations, and an engine module to invoke methods on remote objects. SyD device objects also have inherent capabilitiesto link with each other in an interdependent fashion to enable object composition and atomic transactions over multiple objects, provided by a linking module.

At the middle layer, there is SyD groupware, a logically coherent collection of services, APIs, and objects that facilitates the execution of application programs. SyD groupware consists of a directory services module, an engine module for group service invocation and result aggregation, and an event handler module for global events.

At the highest level are the applications themselves. They rely only on these groupware services, and are independent of device, database and network. These applications include instantiations of SyDAPP Objects that are aggregations of the device objects, and SyD middleware objects. The three-tier architecture of SyD enables applications to be developed in a flexible manner without knowledge of device, database and network details.

The kernel is the key

What makes this three level framework viable is the use of a modular SyD kernel, written in Java, consisting of five modules: SyDirectory, SyDListener, SyDEngine, SyDEventHandler and SyDLinks. (Figure 2, below)

The. SyDDirectory provides user/group/service publishing, management, and lookup services to SyD users and device objects. It also supports intelligent proxy maintenance for users/devices. SyDListener enables SyD device objects to publish their services (server functionalities) as “listeners”locally on the device and globally via the directory services. It then allows users on the SyD network to invoke single or group services via remote invocations seamlessly (location transparency).

The SyDEngine allows users to execute single or group services remotely and aggregate results while the SyDEventHandler manages local and global event registration, monitoring, and triggering. Finally, there are SyDLinks which enable an application to create and enforce interdependencies, constraints and automatic updates among groups of SyD entities.

SyD's runtime runs things

In actual operation there is a SyD runtime environment (Figure Two, below) middleware layer located between the applications and the communication services provided by primitive distribution middleware (Sockets, RMI, JXTA, CORBA, etc.). Each layer depends on the services provided by a lower layer. Therefore, each layer hides complexities of the tasks provided in that layer from upper layers. This provides two benefits: distribution transparency and rapid application development.

As to the first benefit, SyD modules provide location, access, resource sharing, and migration transparencies. Application developers concentrate on application functionality, and business logic; distribution servicesare provided by SyD Kernel seamlessly. During application development, detailed application distribution issues are hidden from designers andprogrammers

Figure 2:SyD kernel is at the core

(distribution transparency) therefore reducing design and developmenttime.

SyD uses various existing “primitive” distribution middleware technologies for remote method invocations, distributed object access, and registration. These could be Sockets, Java/RMI, CORBA, .NET, SOAP, etc. In the current implementation, we have used TCP Sockets for small footprint and maximum flexibility. Future versions of SyD will be expanded to include otherdistribution middleware technologies, such as JXTA, for wider heterogeneityand acceptance.

As to the second benefit, because we have developed SyD Kernel using Java and utilizing TCP Sockets for the distributed communication layer, applications developed using SyD run on a JVM. This also allows SyD applications to run on heterogenous devices and operating systems since JVM is available on many different platforms including small mobile devices (remember, we employed Jeode JVM on iPAQs). But most importantly, in this framework, applications are developed rapidly using SyD Kernel modules without any knowledge about lower layer services (primitive distribution middleware, OS environment).

Managing Diverse Services

A SyD-based server manages the remote interactions betweenvarious distributed SyD applications, providing services to local users as well as to global users on the network. Global users access remote services by invoking methods remotely that are previously published as listeners. Thus, user interface (client portion) and server application functionalities are separated in the implementation

A server-based Client interface allows users to invoke application services,locally or globally. A SyD-based application provides distribution transparency via SyDDirectory-based server applications, each of which maintains user service directories and upon request delivers the location information to requesters on the fly.

In this framework, a requester of a remote service acts as a “client” of the remote service that is provided by a remote SyD-based application that acts as a “server”. For this interaction, the client consults with the SyDDirectory to get remote user/service information about the remote “server”.

How SyD devices cooperate

Within this infrastructure, ordered collections of data– be they formal databases or ASCII lists, stored on PDAs or on mainframes — are supported by SyD deviceware that allow the construction, naming, and publication of device objects which operate on these data stores through methods.

SyD groupware is responsible for making software applications (anywhere) aware of the named objects and their methods/services, executing these methods on behalf of applications, allowing the construction of SyD Application Objects (SyDAppOs) that are built on the device objects, and providing the communications infrastructure between SyD Applications (SyDApps), in addition to providing QoS support services for SyDApps.

SyDApps are applications written by and for the end users (human or machine) that operate on the SyDAppOs alone and are able to define their own services that utilize the SyDAppOs, without directly depending on either the location or the type of database or type of device (PDA or mainframe) where a certain information field is stored.

The SyD groupware provides only a named device object for use by the SyDApps, without revealing the physical address, type or location of the information store. SyDApps are, thus, truly portable, network and database independent, and are able to operate across multiple networks and multiple devices, relying on the middleware to provide the supporting services that translate the SyDApps code to the correct drivers, for both communications and computing.

SyDApps can also decide on their own features and services they offer, without depending on individual databases residing on remote computing devices to offer those services. The SyD architecture, thus, is compatible with and extends the currently emerging Web-services paradigm for Internet-centric applications.

What Next?

There are a number of over-riding benefits of our approach for developers of devices that must operate in the current distributed computing environment. One is that it enables rapid development of robust collaborative applications. It also hides the heterogeneity inherent among devices (their OS and languages), data stores (their format and access mechanism) and network (protocols, wired or wireless). As a result there is a uniform and persistent object view of mobile server applications and data-stores interacting through XML/SOAP requests and responses.

Requiring only 74 KB of program storage space, the device-resident portion of our system within a variety mobile devices and functions can be seamless switched, with connections between between hosted applications and their stable proxies that are reliable and can tolerate temporary disconnections and still provide persistence.

Ongoing and future work involves porting SyD to devices other than iPAQs (such as Palm Pilots and cell phones); obtaining a pure peer-to-peer version, possibly leveraging off JXTA's directory service; providing more robust quality of service (QoS) functionalities including real-time constraints and application-level QoS; and addressing security issues.

The application of this technology to a variety of mobile web-services applications ranging from fleet management, distributed logistics services, to financial transactions is being pursued, together with a cohesive rapid application design and development environment for the proposed middleware technology.

The authormay be contacted at vkm@ece.gatech.eduor

Additional details may be obtained from the Yamacraw Embedded Software links at

For more general information about the issues, products and technologies in this story, go to the iAppliance Web Views page and call up the associatively-linked XML/Java Web map of the iApplianceWeb site and search for information since the beginning of 2002.

For technical article coverage, go to EETimes In Focus maps on the same Web page and browse or quickly search for all articles on a particular topic since the beginning of 1998.

These Web Maps can be browsed by date, by category, by title, or by keyword, with results displayed instantly either as a list of possible hits or with the specific Web page.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.