RepoMan A Component Repository Manager for Enterprise DRE Systems

RepoMan

A Component Repository Manager for Enterprise DRE Systems

Stoyan Paunov & Douglas C. SchmidtVanderbilt University

Institute for Software Integrated Systems (ISIS)

Context: Service–Oriented Architectures• Historically, distributed real-time &

embedded (DRE) systems were built directly atop OS & protocols

Operating System & Communication Protocols

Hardware Devices

Applications

Applications

• Traditional methods of development have been replaced by middleware layers to reuse architectures & code for enterprise DRE systems

• Viewed externally as Service-Oriented Architecture (SOA) Middleware


Hardware Devices

Domain-Specific Services

Common Services

Distribution Middleware

Infrastructure Middleware

• Historically, distributed real-time & embedded (DRE) systems were built directly atop OS & protocols

Service-Oriented Architecture Middleware

Context: Service–Oriented Architectures

Applications

• Traditional methods of development have been replaced by middleware layers to reuse architectures & code for enterprise DRE systems

• Viewed externally as Service-Oriented Architecture (SOA) Middleware


Hardware Devices


Common Services



• Historically, distributed real-time & embedded (DRE) systems were built directly atop OS & protocols

Multi-layer Resource Manager (MLRM)

• e.g., DARPA Adaptive & Reflective Management System (ARMS) program’s Multi-layer Resource Manager (MLRM)

• MLRM leverages standards-based SOA middleware to manage resources for shipboard computing environments

Context: Service–Oriented Architectures

dtsn.darpa.mil/ixodarpatech/ixo_FeatureDetail.asp?id=6

Applications


ARMS Multi–Layer Resource Manager (MLRM) • ARMS MLRM architecture

includes

• Top domain layer containing components that interact with the ship mission manager

• Middle resource pool layer is an abstraction for a set of computer nodes managed by a pool manager

• Bottom resource layer manages the actual resource computing components, i.e., CPUs, memory, networks, etc.

www.cs.wustl.edu/~schmidt/PDF/JSS-2006.pdf

Problem: New Complexities

• Applications composed of loosely-coupled, course-grained distributed components

• Large number of deployment & configuration artifacts

• Need to shield deployment & configuration logic from heterogeneous hardware/software environments

• Continuous system evolution

• Enable the dynamic redeployment & reconfiguration of application & middleware components

Need to provide the right implementation under the right circumstances

Applications


Hardware Devices


Common Services



Multi-layer Resource Manager (MLRM)

Solution: Standardized Deployment & Configuration (D&C)• Need an administrative entity which

RepoMan: an implementation of OMG CCM Repository Manager specification tailored to the needs of enterprise DRE systems

Component A v1

…

Component B v1

…

• Facilitates online upgrades, reconfiguration, & redeployment of components

Component B v2

…

• Keeps track of software implementation artifacts & their configuration metadata in heterogeneous environments

Overview of RepoMan

• Organizes various configurations of component packages

• Knows how to parse the XML metadata

• Keeps track of component interfaces & their relationships

• Facilitates the dynamic update of components at run-time

Component A v1

…

Component B v1

…

Metadata XML Descriptors Implementation Artifacts bundled via ZIP compression have *.CPK extension

CORBA

HTTP

Filesystem

R

E

P

O

M

A

N

RepoMan Design Challenges

• The CCM specification defines the interface, but it does not prescribe any design & implementation details

• We were faced with a number of challenges which we discuss next

CORBA Object

HTTPServer

File System

Component

…

ClientClient

ClientClient

ADMIN

EfficiencyConcurrency

SynchronizationConsistencyPortability

Challenge 1: RepoMan & HTTP Server Architecture

• Context • The RepoMan architecture consists of a

CORBA object & an HTTP Server• Need to implement the CORBA interface

specified by the CCM Specification• Need to allow retrieval of implementation

artifacts via HTTP• Problem

• Shared memory• Lack of portability• Inflexible

• Extend the CORBA server & client• Limited to CORBA• Unnecessary effort

HTTPServer

CORBA Object

File System

The Triangle of Mystery

Solution: Loose Coupling Between CORBA Object & HTTP Server

• No explicit knowledge of each other

• Do not share internal state

• Share a common filesystem

• JAWS vs. Apache

• The CORBA object supports the standard set of operations enabling

• manipulation & querying of data in repository

• retrieval & updating of configuration information

• A collocated HTTP server enables retrieval of implementation artifacts

I = installC = configureQ = queryR = retrieveD = delete

LEGEND

CORBA Object

HTTPServer

ClientsI,C,Q,D

R

ADMIN

File Systemhttp://www.dre.vanderbilt.edu/JAWS/

http://httpd.apache.org/

Challenge 2: PackageConfiguration Complexity • Context

• PackageConfiguration – one of the most complex elements in CCM

• Location of implementation artifacts not known at package creation

• Problem

• Monolithic components• 8 levels of hierarchy

• Assembly-based components• 11 levels of hierarchy

• Programming nightmare

• Need to update the locations of the implementation artifacts in the PackageConfiguration

Solution: Use Visitor pattern to Cope with Accidental complexity of PackageConfiguration

Intentcentralize operations on an object structure so that they can

vary independently but still behave polymorphically

Applicability• class relationships of objects in the structure rarely change,

but the operations on them change often• algorithms keep state that’s updated during traversal

Structure

Logic for handling each element has a well defined scope

Challenge 3: Cost of Data Movement & XML Parsing

• Context

• Manipulating contents of component packages

• Problem

• Data movement costs:

• Uncompressing

• Writing to disk

• Parsing with XERCES-C

• Storing in equivalent C++ classes

• XML parsing

• PackageConfiguration parsing involves on the order of tens of files & is therefore very slow

Un-ZIP

Disk

Parse XML

C++ dataStructure

Read Package

uncompress

Read descriptors

Populate

Retrieve

Store Local

HTTP

PackageConfiguration

Solution: Minimizing Data Movement & XML Parsing to Improve CPU & I/O Usage

File System

CORBA Object

*.cpk */descriptors/**/implementations/*

• Extract the package contents only once at installation

• Wasteful on hard disk usage, but avoiding a bulk of CPU & I/O processing

*.EPC

• Externalizing via CORBA CDR to minimize XML parsing

• Leveraging the cost of externalizing over lifetime of PackageConfiguration

• Humanly visible speed-up of metadata retrieval operations

myPackage.cpk

Install

Challenge 4: Organizing & Managing Data Efficiently

• Context

• Need to store local copies of packages

• Problem

• Ensure consistency

• Access, traversal & clean-up

• No standard filesystem API

• Need for portability precludes a tightly coupled approach

• Third-party libraries place limitations on the user community

File System

Component

…Component

…

Install Delete

Solution: Use Package Name & Structure

• Use the fact that installation name uniqueness in enforces to device the local directory structure

• Mimic the package structure on the local filesystem

• Use layout of package to guide you through the clean-up process

File SystemmyPackage.cpkmyPackage.epcmyPackage/descriptors/*myPackage/implementations/*

myPackage.cpk

Install

Challenge 5: Scalability & Synchronization• Context

• Need to provide high scalability & efficiency

• Need to preserve consistency

• Concurrency & synchronization

• Problems

• Concurrency strategy choice

• Single-threaded model

• Thread-per-request model

• Can exhaust system resources & degrade performance

• Thread pool

• Synchronization inherently incurs overhead

Thread-per-Request

Thread Pool

CORBAObjectClient

ClientCORBAObject

Solution: Use a Synchronized Variable-size Threadpool to Handle Incoming Requests

• Scalability

• Thread pool implemented with the Leader-Followers pattern to handle requests

• Hash maps to keep internal state O(1) best case access

• Synchronization

• Synchronize only the hash maps, not the entire functions

• Much more efficient than the Monitor pattern

CORBA Object

HTTPServer

File System

Component

…

ClientClient

ClientClient

ADMIN

Lessons Learned• Building enterprise DRE systems requires

a component repository to keep track of software implementations & their configuration metadata

• Thereby enabling the automated (re)deployment & (re)configuration of the system

• Applying patterns helps ensure good design

• Patterns applied to RepoMan included

• Visitor, Null Object, Leader-Followers, & Memento in the CORBA object

• Strategy, Bridge, Service Configurator, Iterator, & Singleton in HTTP server

• Amortizing cost over the lifetime helps improving performance

CORBA Object

HTTPServer

File System

Component

…

ClientClient

ClientClient

ADMIN

Concluding Remarks

• RepoMan strikes an effective balance between flexibility and efficiency. It keeps client code simple and supports system (re)deployment and (re)configuration and dynamic updates.

• RepoMan is available as part of the Component Integrated ACE ORB (CIAO) at www.dre.vanderbilt.edu/CIAO/

• For more information on JAWS check: http://www.dre.vanderbilt.edu/JAWS/

Any Questions

Functionality of RepoMan• Installation

• installPackage ()

• createPackage ()

• Deletion

• deletePackage ()

• Retrieval

• findPackageByName ()

• findPackageByUUID ()

• Querying

• getAllNames ()

• getAllTypes ()

• findNamesByType ()

• Retrieving implementations

Clients

Package

PC = PackageConfigurationIA = Implementation ArtifactCI = Component InterfaceIN = installation name

HDD

CORBA Object

HTTPServer

1. Validate Package content2. Install IA3. Associate package w/ IN4. Associate CI w/ IN

HTTP




• Deletion


• Retrieval



• Querying

• getAllNames ()

• getAllTypes ()



Clients

Find IN


HDD

CORBA Object

HTTPServer

Return PC




• Deletion


• Retrieval



• Querying

• getAllNames ()

• getAllTypes ()



Clients


HDD

CORBA Object

HTTPServer

http://.../IA.dll IA.dll

Documents

RepoMan A Component Repository Manager for Enterprise DRE Systems