1 / 16

Automatic Configuration of Component-Based Distributed Systems

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. Why Don’t Component Technologies Work?.

tierra
Download Presentation

Automatic Configuration of Component-Based Distributed Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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 CORBA Prerequisite Parser CORBA Persistent Object Service Prerequisite Parser SPDF Parser Prerequisite Resolver 2K Implementation Repository

  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 CompoundName 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 cache 2. 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 theSimple 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 2KOperating 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. RepresentingDynamic 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. TheComponentConfiguratorFramework • 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 the2K Web site: http://choices.cs.uiuc.edu/2K

More Related