Virtual Private Computing

A new paradigm for omnipresent,
internet-based computing

Introduction

Not only the number of computers and computing devices has tremendously risen over the last years but also the ratio of devices connected to the global Internet. This increase in connectivity is currently causing a paradigm shift, away from the initial intention to have a personal computer as an own, stationary device, which stores all the user's data and programs. Instead of being restricted to use only their own machines to have access to their data and favourite programs, users want to have omnipresent access to their programs and data, independent of where they are and what device they have available.

Existing programming paradigms and middleware systems used for the development of standard applications are not prepared for the requirements of these omnipresent, Internet-based applications. To effectively and efficiently realize such applications, a system has to be flexible enough to cope with different hard- and software platforms and to adapt to varying resource availabilities.

We therefore propose a new programming paradigm that allows to specify the architecture of component-based applications and a runtime system that uses this information to run the applications. The runtime mechanisms are able to dynamically distribute applications in a peer-to-peer fashion over a network of participating machines and care for all aspects of distribution, from partitioning the application and finding appropriate target hosts to run a component, over downloading suitable implementation code for the chosen hosts, to instantiating and binding the components to get a fully running system. The programming modell as well as all necessary mechanisms are designed for efficiency and scalability, which is the central aspect to successfully implement the system.

Virtual Private Computing

The basic idea of virtual private computing is to create the vision of a single virtual computer that consists of an arbitrary number of possibly heterogeneous and widely distributed machines. The term VPC therefore originates from the two most central aspects of this system:

It is a virtual computer:

A huge number of probably globally distributed and heterogenous hosts can participate in the system and can bring in resources like processor time, storage capacity and networking bandwidth. All these hosts and their resources act like one large, globally available computer offering huge amounts of resources.

It behaves like a private computer:

Similar to personal computers, this virtual host allows a user to access his private data and favourite applications independent of the actual host he uses. Data safety, security and integrity are comparable to existing paradigms. The same is true for the execution behaviour of applications in response times and execution speed.

The VPC programming model

VPC applications are developed in a component-oriented manner. But while typical component oriented systems like the CORBA Component Model (CCM) or DCOM rely on component implementations in their composition process, the VPC programming-model bases on the description of component-types and properties. A application developer specifies all the information that is necessary to choose an appropriate implementation at runtime. Additionally the application developer describes the structure of his application, i.e. the interconnections between all of the previously defined components. Only this architecture description is deployed.

The VPC runtime-environment interprets the description and has therefore all the information that is necessary to decide whether and how the application should be distributed depending on the currently available resources. Distribution and binding is done on demand. If a component is accessed by the application the first time, the runtime mechanisms search for implementations that comply to the stated type and property information, instantiates the component on a suitable host and connects it via a CORBA compliant middleware. As the interpretation process is not involved in realizing the functuality of the application, it does not create any additional overhead.

The whole application description is done in an own XML-based architecture description language, that was carefully designed to support the maximum reuse of implementation in order to guarantee efficiency and scalability.

The VPC Runtime Environment

The above figure sketches the runtime environment of a VPC application with a central CORBA middleware that is used for all communication between application and system components, together with the most essential system services. Main system component is the VPCHost, which is responsible for starting and initializing all other components. If an application should be started, it is given to the VPCLoader, which creates a VPCSession component. This is the representative of a running VPC application on this host. It maintains a list of socalled VPCContext components, which host the real components that make up the application. Although one context component can host an arbitrary number of components of a single application, more than one context component can run for one application, if components realized in different programming languages should be used in one application

Distribution decisions are made by the Distributor, which uses the information provided by the architecture description and its knowledge about other hosts to find an appropriate target host for a component. If a host has been chosen to instantiate a component it triggers its localComponentBroker to find a suitable implementation. The code will either be found locally in a implementation cache maintained by the broker, or at another broker that provides the code.

Publications & Technical Reports

Virtual Private Computing - A New Paradigm for Component-Based Distributed Applications

Martin Steckermeier Franz Hauck

TR-I4-00-02, english July 06, 2000, 10 pages

[Full Paper (pdf) , 62 kB]

Virtual Private Computing

Martin Steckermeier Franz Hauck

TR-I4-99-06, english July 1999, 11 pages

[Full Paper (pdf) , 71 kB]

Team

Dipl.-Inf. Martin Steckermeier

Dr.-Ing. Franz J. Hauck