1

Automatic Configuration of Component-Based Distributed Systems

Fabio Kon Roy H. Campbell

University of Illinois at Urbana-Champaign

{f-kon,roy}@cs.uiuc.edu

http://choices.cs.uiuc.edu/2K

2

Why Don’t Component Technologies Work?

Well, they do work, but not as smoothly as we would like. They fail because of a variety of reasons: We can specify the interfaces of a component but we

don’t have a way to specify the actual behavior of complex components.

Components are created by different people, in different groups, with different methodologies. When we combine them to build an application, weird things can happen:

a component behaves differently from what others expected the failure of one component is not properly detected by others updating one component “confuses” the others etc, etc.

3

The Problem Existing technologies provide little or no

support for managing inter-component dependencies.

Component-based systems become less reliable:

Difficult to support fault-tolerance. Difficult to update components on-the-fly. Difficult to support dynamic reconfiguration. In some cases, too many components are

added to the system.

4

The Proposed Solution The operating system and/or the

middleware must manage inter-component dependencies.

It is fundamental to represent these dependencies explicitly.

The 2K distributed operating system manages two kinds of dependencies: Prerequisites Dynamic Runtime Dependencies

It uses them to implement its Automatic Configuration Service.

5

Prerequisites The Prerequisites for a certain component specifies

what the component needs to be properly loaded and executed: the nature of the hardware resources it uses the share of these hardware resources the software services (i.e., other components) it requires

Example of the requirements for a networked Video Client: PC with MPEG decoding card 50% of 200MHZ CPU CORBA Video Service

6

2K Framework for Prerequisite Management

7

Prerequisite Specification In 2K, dependencies on other components are specified in

four different ways: 1. A Pathname in the 2K Implementation Repository.

2. A Compound Name in the CORBA Naming Service.

3. A pair (ServiceTypeName, Constraint) for the CORBA

Trading Service.

4. A persistent IOR (i.e., a reference to a CORBA object).

Prerequisite Resolution Caching Pull-based Policy:

1. Locate prerequisite in the local cache2. If not present, contacts Implementation Repository or Trader to locate remote instance or to fetch the component code.

The cache is a local repository of component implementations and references (IORs) to remote components.

8

Example of a specification using the

Simple Prerequisite Description Format (SPDF)

:hardware requirements

machine_type SPARC

native_os Solaris

min_ram 5MB

optimal_ram 40MB

min_vm 30MB

optimal_vm 40MB

:software requirements

FileSystem IR:/sys/storage/DFS1.0 (optional)

TCPNetworking IR:/sys/networking/BSD-sockets

WindowManager IR:/sys/WinManagers/simpleWin

JVM IR:/interp/Java/jvm1.2 (optional)

Used for QoS-aware Resource Management

Used for Automatic Configuration

9

The 2K Operating SystemWhat You Need Is What You Get

System services and applications are built out of CORBA components and benefit from standard CORBA services.

The system configures itself dynamically based on the user and application requirements, implementing a WYNIWYG model (What You Need is What You Get) .

2K is Network-Centric and provides support for Dynamic Reconfiguration Monitoring and Adaptation QoS-Aware Resource Management Dynamic Security Services (encryption, role-based access control) Code Mobility

Initial target applications: Multimedia Distributed Computing Active Spaces (smart rooms, distant learning, smart meetings)

10

The 2K Architecture

11

Representing Dynamic Dependencies

Objects of the type ComponentConfigurator reify inter-component dependencies,i.e., the objects represent the dependencies explicitly.

ComponentConfigurators are created on-the-fly by the Prerequisite Resolver as new components are loaded.

System and application components can inspect and reconfigure the Dependence Graph at any moment during runtime.

Components can subclass from the ComponentConfigurator base class to implement application-specific extensions for fault-tolerance and dynamic configuration.

12

The ComponentConfigurator

Framework

Each system and application component has a ComponentConfigurator that represents its runtime dependencies on other components.

Together, they form a Dependence Graph that can be navigated and manipulated at runtime.

13

Dynamic Reconfiguration In a component-based operating system, all system and

application components are managed by a dependency-aware infrastructure.

Fault-tolerance and adaptation mechanisms use the dependence information to carry out dynamic reconfiguration.

14

Implementation Status and Ongoing Work

Completed: ComponentConfigurator Framework. The local C++ version of the framework was used

in dynamicTAO, a reflective ORB, to support dynamic reconfiguration.

Prototype of the 2K AutoConfig Service with SPDF.

Ongoing work: Caching Prerequisite Resolver. Applying CORBA version to several 2K services

and applications including QoS Management, Persistent Object Service, Distributed File System, Multimedia Distribution System, etc.

Measuring performance and space overhead.

15

Conclusions Component technologies must pay

attention to component dependencies. Middleware-based dependence

management can make systems: easier to administer automatically configurable more reliable dynamically adaptable

We are looking for an Architectural Description Language (ADL) to enhance our system by supporting the specification of distributed application architectures. Any suggestion?

16

How to Contact us E-mail: f-kon@cs.uiuc.edu roy@cs.uiuc.edu

Several research articles, source code, and

documentation can be retrieved from the 2K Web site:

http://choices.cs.uiuc.edu/2K