Research Abstracts - 2007

Overview

The Network Portable Object Pointer (NPOP) middleware system provides mechanism for dynamically composing and restructuring applications to sustain services in a dynamically changing environment. The NPOP 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 NPOP-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-structuring, 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.

Approach

The basic API provides a mechanism for instantiating a collection of NPOPs on various hosts, interconnecting them into a network, and monitoring the operation of the resulting composite via a serialized 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 NPOPs (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 NPOP-based object modules, each associated with a unique identifier that establishes (at some abstract level) its function. NPOPs are, in general, platform independent, and hence there may be multiple implementations of each NPOP. Each NPOP corresponds to a particular function at a detailed enough level that, in theory, the specification of an NPOP as an application component is sufficient to guarantee the acceptable operation of that application. In order to standardize the characteristics of each NPOP, we use as the NPOP's unique identifier a URI identifying an immutable description of that NPOP. 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 NPOP 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 audio and video player, and especially distributed GUI applications that benefit from centralized logic, such as a multi-party chat application.

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

We recently implemented a mechanism for constructing high-level application bundles, termed composites, from constituent distributed NPOP objects and their interconnections. These composites can be subsequently combined into larger composites, thus enabling design hierarchy in application construction. Leveraging the NPOP composition framework, we have implemented a mechanism for facilitating application-module hotswapping during run-time.

Future

We have begun experimenting with building NPOP modules that stream and receive real-time audio and video streams. Specifically, we are interested in incorporating RTP to stream media data between hot-swappable components. Additionally, we are continuing to refine the top-level developer API and plan to package the NPOP framework for release.

Funding

This project has been funded by the Oxygen project, CMI, and the Quanta/CSAIL T-Party project.

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).