Aiding the Deployment and Configuration of Component Middleware in Distributed, Real-time and Embedded Systems Stoyan G. Paunov Master’s Thesis Presentation.

Aiding the Deployment and Configuration of Component Middleware in Distributed, Real-time and Embedded Systems Stoyan G. Paunov Master’s Thesis Presentation Vanderbilt U, Nashville, TN April 15th, 2006 Special Thanks to: Dr. Douglas C. Schmidt Dr. Aniruddha Gokhale

Presentation Outline … Brief Overview of Component Middleware
Component A v1 … Component B v1 Brief Overview of Component Middleware Addressing Deployment and Configuration complexities by means of Repository Managers Configuring Component Middleware for Quality of Service (QoS) by means of Model-Driven Development Querying & Retrieval Installation & Manipulation Organization REPOMAN Visual Model Interpretation maps to

Motivation: Service–Oriented Architectures
Historically, distributed real-time & embedded (DRE) systems were built directly atop OS & protocols Applications Operating System & Communication Protocols Hardware Devices

Historically, distributed real-time & embedded (DRE) systems were built directly atop OS & protocols Applications Service-Oriented Architecture Middleware Traditional methods of development have been replaced by middleware layers to reuse architectures & code Viewed externally as Service-Oriented Architecture (SOA) Middleware Domain-Specific Services Common Services Distribution Middleware Infrastructure Middleware Operating System & Communication Protocols Hardware Devices

Historically, distributed real-time & embedded (DRE) systems were built directly atop OS & protocols Applications Multi-layer Resource Manager (MLRM) Traditional methods of development have been replaced by middleware layers to reuse architectures & code Viewed externally as Service-Oriented Architecture (SOA) Middleware Domain-Specific Services Common Services Distribution Middleware Infrastructure Middleware e.g., DARPA Adaptive & Reflective Management System (ARMS) program’s Multi-layer Resource Manager (MLRM) MLRM leverages standards-based SOA middleware to manage computing & communication resources for shipboard computing environments Operating System & Communication Protocols Hardware Devices

ARMS Multi–Layer Resource Manager (MLRM)
Domain-specific layered architecture includes Top domain layer contains components that interact with the mission manager of TSCE Middle resource pool layer is an abstraction for a set of computer nodes managed by a pool manager Bottom resource layer contains the actual resource computing components Applications Domain-Specific Services

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 Applications Multi-layer Resource Manager (MLRM) Domain-Specific Services Common Services Distribution Middleware Infrastructure Middleware Operating System & Communication Protocols Hardware Devices Need to provide the right implementation under the right circumstances

Solution: Standardized Deployment & Configuration
Need an administrative entity which Keeps track of software implementation artifacts & their configuration metadata in heterogeneous environments Facilitates online upgrades, reconfiguration, & redeployment of components Component A v1 … Component B v1 … Component B v2 … RepoMan: an implementation of OMG CCM Repository Manager specification tailored to the needs of enterprise DRE systems

Overview of RepoMan Component A v1 … Component B v1 … 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 CORBA HTTP Filesystem R E P O M A N Metadata XML Descriptors Implementation Artifacts bundled via ZIP compression have *.CPK extension

RepoMan Design Challenges
CORBA Object HTTP Server File System Component … Client ADMIN Efficiency Concurrency Synchronization Consistency Portability 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

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 HTTP Server CORBA Object File System The Triangle of Mystery

Solution: Loose Coupling Between CORBA Object & HTTP Server
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 = install C = configure Q = query R = retrieve D = delete LEGEND CORBA Object HTTP Server Clients I,C,Q,D R ADMIN File System No explicit knowledge of each other Do not share internal state Share a common filesystem JAWS vs. Apache

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

Logic for handling each element has a well defined scope
Solution: Use Visitor pattern to Cope with Accidental complexity of PackageConfiguration Intent centralize 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
HTTP Retrieve 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 Store Local Un-ZIP Read Package uncompress Disk Read descriptors Parse XML Populate C++ data Structure

PackageConfiguration
Solution: Minimizing Data Movement & XML Parsing to Improve CPU & I/O Usage *.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 *.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 File System myPackage.cpk CORBA Object Install PackageConfiguration

Challenge 4: Organizing & Managing Data Efficiently
Install Delete 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 …

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 myPackage.cpk Install File System myPackage.cpk myPackage.epc myPackage/descriptors/* myPackage/implementations/*

Challenge 5: Scalability & Synchronization
Client CORBA Object 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 Client CORBA Object Thread Pool

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

Lessons Learned CORBA Object HTTP Server File System Component … Client ADMIN 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

Section Summary CORBA Object HTTP Server File System Component … Client ADMIN 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 For more information on JAWS check:

Serialized Phasing is Common in Large-scale Systems
System infrastructure components developed first Development Timeline Level of Abstraction Application components developed after infrastructure is mature

Serialized Phasing is Common in Large-scale Systems
Finished development Development Timeline Level of Abstraction System integration & testing Integration Surprises!!!

Complexities of Serialized Phasing
Still in development Development Timeline Level of Abstraction Ready for testing Complexities System infrastructure cannot be tested adequately until applications are done

Complexities of Serialized Phasing
Overall performance? Development Timeline Level of Abstraction Complexities System infrastructure cannot be tested adequately until applications are done Entire system must be deployed & configured properly to meet QoS requirements Existing evaluation tools do not support “what if” evaluation

Unresolved QoS Concerns with Serialized Phasing
Meet QoS requirements? Development Timeline Level of Abstraction Key QoS concerns Which D&C’s meet the QoS requirements?

Performance metrics? Development Timeline Level of Abstraction Key QoS concerns Which D&C’s meet the QoS requirements? What is the worse/average/best time for various workloads?

Development Timeline Level of Abstraction System overload? Key QoS concerns Which D&C’s meet the QoS requirements? What is the worse/average/best time for various workloads? How much workload can the system handle until its QoS requirements are compromised? It is hard to address these concerns in processes that use serialized phasing

Promising Approach: Emulate Application Behavior in the context of QoS-enabled SOA Middleware
Component Workload Emulator (CoWorker) Utilization Test Suite Workflow (CUTS): While creating target infrastructure Define infrastructure specifications & requirements Define the appropriate QoS infrastructure policies Define emulated application specifications & requirements Deploy the system based on the predefined design rules Use analysis tools to evaluate & verify QoS performance If necessary refine the system QoS policies & repeat Enable “application” testing to evaluate target infrastructure earlier in lifecycle

QoS Configuration Challenges
Ensuring the right granularity of QoS Using the standard RT CORBA API to configure QoS policies Managing the accidental complexities of declarative configuration approaches based on XML Managing large scale system configurations Enable the evolution and refining of the system

Inherent Complexities
C1: Providing the Right QoS Granularity Inherent Complexities Preserving priorities end-to-end Enforcing certain priorities at the server Supporting thread pools effectively Buffering client requests Synchronizing objects correctly Controlling network & end-system resources Ensuring the right granularity of QoS E.g. high throughput of continuously refreshed data hard real-time deadlines associated with periodic processing soft real-time processing of many tasks timely operator display and control requirements

Inherent Complexities
C1: Providing the Right QoS Granularity Inherent Complexities Preserving priorities end-to-end Enforcing certain priorities at the server Supporting thread pools effectively Buffering client requests Synchronizing objects correctly Controlling network & end-system resources Real-time CORBA provides QoS policies to overcome challenges above, including: Thread pool policy model: thread pools & thread pools with lanes Priority propagation model: server declared & client propagated Connection model: a connection with logical bands for different priorities

Accidental Complexities
C2: Using the RT CORBA APIs Accidental Complexities Programming Real-time CORBA QoS policies manually is tedious & error-prone CORBA::Object_var object = this->orb_->resolve_initial_references ("RootPOA"); object = this->orb_->resolve_initial_references ("RTORB“) RTCORBA::RTORB_var rt_orb = RTCORBA::RTORB::_narrow (object.in ()); CORBA::Boolean allow_request_buffering = 0; CORBA::ULong max_buffered_requests = 0; CORBA::ULong max_request_buffer_size = 0; RTCORBA::ThreadpoolId threadpool_id_1 = rt_orb->create_threadpool (0, static_threads, dynamic_threads, default_thread_priority, allow_request_buffering, max_buffered_requests, max_request_buffer_size); CORBA::Policy_var threadpool_policy_1 = rt_orb->create_threadpool_policy (threadpool_id_1); result = this->create_POA_and_register_servant (threadpool_policy_1.in (), "first_poa", poa_manager.in (), root_poa.in (), this->orb_.in (), rt_orb.in ()); if (result != 0) return result; this->orb_->run (); this->orb_->destroy (); Decouple QoS configuration from the core software logic Declarative Configuration via XML: Better but not much better

MDD Solution to QoS Configuration & Provisioning
Approach: Develop a QoS Policy Modeling Language (QoSPML) w/GME that can synthesize XML descriptors that provision Real-time CORBA QoS policies MODEL Specify a QoS model METAMODEL Provision Real-time Middleware QoS policies via XML INTERPRETATION REFLECTS INTERPRETER IMPLEMENTS Generates

Overview of QoSPML Allows the configuration of Real-time CCM QoS policies in DRE systems Configurable features: Thread pool policy model Connection policy model Priority propagation policy model Create QoS models Constraints used to assure correctness of models Synthesize XML configuration data via QoSPML model interpreter XML configurations fed into Deployment & Configuration (DAnCE) runtime to configure QoS properties automatically

C3: Using XML as Configuration Language
Accidental complexities of using XML to configure QoS policies declaratively: Expressive, but hard to read manually Schema-based element hierarchy, but flat document structure Highly verbose, lack of intuitive domain relationship Single typo can compromise document structure and cause parser failure Modification of configuration data is very cumbersome XML

MDD Solution: Bypass XML Accidental Complexities
Using MDD technologies solves the problem by: Allowing you to concentrate on the domain specific goal and ignore the means used to achieve it Bypass XML coding by raising the level of abstraction and substitute it with visual modeling tools Automate the generation of XML Utilize constraint checking facility of modeling framework to ensure the correctness of the visual models The generated XML is correct as long as the interpreter is correct

C4: Managing & Refining System Configuration Space
Managing large scale hand-coded system configurations No easy way to examine the QoS configuration space Addressing weaknesses in the design is tedious and error-prone System evoluton Changing functional requirements Deeper domain understanding Uncovered weak design points

Using MDD techniques to Manage & Refine System Configuration Space
Create/Modify Model (Re)Interpret Model (Re)Configure Application High-level models enable the quick and seamless examination of the overall system configuration Shield developers from the accidental complexities of the evolving configuration space Evolution based on high-level models, not the actual configuration artifacts Automatically regenerate the configuration metadata every time a change has been made

(Re)Configure Application
Observed Benefits Create/Modify Model (Re)Interpret Model (Re)Configure Application Using highly-configurable component middleware such as CIAO enhances software development and productivity. Unfortunately, it also introduces new complexities. Using DSMLs technologies expedites application development and QoS evaluation by providing proper integration of MDD tools with the underlying component middleware infrastructure

Provides Interpretation
Observed Benefits META -MODEL INTERPRETER MODEL INTERPRETATION Specifies Provides Interpretation implements reflects QoSPML can reduce the learning curve for the end users QoSPML simplifies and expedites the QoS configuration process Despite the fact that QoSPML facilitates the seamless QoS configuration, we are still faced with the question of what constitutes a “good” configuration

Summary The QoSPML DSML has been integrated in the Component Synthesis with Model Integrated Computing (CoSMIC) tool chain available at: The Component Integrated ACE ORB (CIAO) can be downloaded from For more information on CUTS please check:

Any Questions

Benefits of Using Emulation
Can use actual target infrastructure Rather than imprecise simulations Many artifacts can be used directly in the final production system e.g., models of application component D&C plans, QoS configuration artifacts Early feedback to developers, architects & systems engineers Instead of waiting for the completion of application components to conduct performance experiments

Aiding the Deployment and Configuration of Component Middleware in Distributed, Real-time and Embedded Systems Stoyan G. Paunov Master’s Thesis Presentation.

Similar presentations

Presentation on theme: "Aiding the Deployment and Configuration of Component Middleware in Distributed, Real-time and Embedded Systems Stoyan G. Paunov Master’s Thesis Presentation."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Aiding the Deployment and Configuration of Component Middleware in Distributed, Real-time and Embedded Systems Stoyan G. Paunov Master’s Thesis Presentation.

Similar presentations

Presentation on theme: "Aiding the Deployment and Configuration of Component Middleware in Distributed, Real-time and Embedded Systems Stoyan G. Paunov Master’s Thesis Presentation."— Presentation transcript:

Similar presentations

About project

Feedback