Overview

The Resources middleware system provides mechanism for dynamically composing and restructuring applications to sustain services in a dynamically changing environment. The Resources system provides a thin, lightweight framework for developing network objects, as well as support for discovering available computing resources, deploying components at various hosts, and interconnecting components to dynamically compose and adapt application-level services. The API presented by our component model is designed to hide certain complexities of a highly parallel, distributed system of interconnected components under the veneer of a simple, sequential, and localized system. Although our design is motivated by the implementation needs of our goal-oriented planning layer, the Resources-based computation layer is designed to be usable by those following more conventional approaches to distributed application design.

Background

Conventionally, distributed applications are composed of statically-partitioned client-server modules which communicate using fixed, pre-defined APIs. There is no distinction between mechanism and policy: the function implemented by a module and the policy specifying the role of the module in the overall logic of the application are inextricably intertwined in the code of every module. Therefore, it is often difficult to adapt such distributed applications by replacing its constituent components, or to even reuse a component for satisfying a different goal.

Goal-oriented programming in a pervasive computing environment, on the other hand, involves dynamic assembly, and subsequent re-restructuring, of available distributed components. Therefore, individual components must be reusable for implementing a variety of high-level goals, while the policy for specifying the use of different components must be abstracted away in a process capable of planning the assembly and, subsequent adaptation, of distributed components to accomplish and sustain a high-level goal in the changing characteristics of a pervasive computing environment.

Our goal is to provide a platform-independent substrate that allows a set of components to be selected from a repertoire, including both physical and virtualized components, and interconnected to implement some application-level service. We would like this system to allow hot swapping of resources to upgrade service, as well as controlled but independent evolution of individual code modules.

Figure 1 : Graphical depiction of an application using the Resources middleware framework

Approach

The basic API provides a mechanism for instantiating a collection of resources on various hosts, interconnecting them into a network, and monitoring the operation of the resulting composite via a stream of high-level events generated by the resources and connections. Events are used to report component failures, user inputs, or various resource-specific notifications. The health of devices hosting Resources (and the communication paths between them) is transparently monitored by keep-alive connections; resource state updates and debugging output are collected, filtered, and serialized for presentation to the caller; and disconnected or abandoned component processes are automatically scavenged. The intent is to minimize the tedium of developing and maintaining distributed applications, allowing a high-level application to focus on a simple sequential model for its cognitive deliberations, while the compute-intensive reflexive components are managed largely automatically.

We are building a library of Resource-based object modules, each associated with a unique identifier that establishes (at some abstract level) its function. Resources are, in general, platform independent, and hence there may be multiple implementations of each Resource. Each Resource corresponds to a particular function at a detailed enough level that, in theory, the specification of a Resource as an application component is sufficient to guarantee the acceptable operation of that application. In order to standardize the characteristics of each Resource, we use as the Resource's unique identifier a URI identifying an immutable description of that Resource. The description will, in general, contain a mix of formal interface specifications (method signatures, etc.), informal descriptions (of the sort found in man pages), and arbitrary other potentially useful information including code for test cases and demonstrations. This target description, encoded in XML, will serve a role analogous to that of WSDL descriptions for web services, and may use similar mechanism.

Progress

The current version of the Resources middleware was developed to support pebbles[1], a component substrate for goal-oriented assembly of applications in a pervasive computing environment. It is implemented in Python, and we have an experimental port in Java. We have experimented with a range of applications using this system, including visualization tools, voice-input command interpreter (voice shell), a distributed MP3 player, and especially distributed GUI applications that benefit from centralized logic, such as a multi-party chat application.

Our implementation now exploits instance-specific pecularities of Resources; for example, connected Resources within the same host automatically intercommunicate directly and to share data structures.

Future

Our current efforts are focused on integrating the Resources system with the Goals system using a resource arbitration and virtualization layer. Longer-term goals include developing a mechanism for constructing high-level application bundles from constituent Resources and their interconnections; this composite of Resources would facilitate hot-swapping of application-modules during run-time.

References

[1] Umar Saif, Hubert Pham, Justin Mazzola Paluska, Jason Waterman, Chris Terman, and Steve Ward, A Case for Goal-oriented Programming Semantics. In System Support for Ubiquitous Computing Workshop at the Fifth Annual Conference on Ubiquitous Computing (UbiComp '03).