Domain-Specific Modeling Languages for Configuring and Evaluating Enterprise DRE System Quality of...

Domain-Specific Modeling Languages for Configuring and Evaluating Enterprise

DRE System Quality of Service

Stoyan G. Paunov, James H. Hill, Douglas C. Schmidt, John M. Slaby & Steve

Baker

ECBS, Potsdam, GermanyMarch 27th-30th , 2006

Model-Driven Development 2

Motivation: 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

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


Hardware Devices

Domain-Specific Services

Common Services

Distribution Middleware

Infrastructure Middleware


Service-Oriented Architecture Middleware



Applications

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

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


Hardware Devices


Common Services

Distribution Middleware

Infrastructure Middleware


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 computing & communication resources for shipboard computing environments



Applications


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


Serialized Phasing is Common in Large-scale Systems

Application components

developed after infrastructure is

mature

Development Timeline

Level of

Ab

stra

ctio

n

System infrastructur

e components developed

first


Serialized Phasing is Common in Large-scale Systems


Level of

Ab

stra

ctio

n

Integration Surprises!!!

System integration & testing

Finished development


Complexities of Serialized Phasing


Level of

Ab

stra

ctio

n

Still in development

Ready for testingComplexities• System infrastructure cannot be

tested adequately until applications are done


Complexities of Serialized Phasing


Level of

Ab

stra

ctio

n

Overall performance?

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?

Key QoS concerns• Which D&C’s meet the QoS

requirements?


Level of

Ab

stra

ctio

n



Performance metrics?


requirements? • What is the worse/average/best

time for various workloads?


Level of

Ab

stra

ctio

n



It is hard to address these concerns in processes that use serialized phasing


requirements? • What is the worse/average/best

time for various workloads?• How much workload can the

system handle until its QoS requirements are compromised?

System overload?


Level of

Ab

stra

ctio

n


Promising Approach: Emulate Application Behavior in the context of QoS-enabled SOA Middleware

While creating target infrastructure 1. Define infrastructure specifications &

requirements2. Define the appropriate QoS

infrastructure policies3. Define emulated application

specifications & requirements4. Deploy the system based on the

predefined design rules5. Use analysis tools to evaluate &

verify QoS performance6. If necessary refine the system QoS

policies & repeat

Enable “application” testing to evaluate target infrastructure earlier in lifecycle

Component Workload Emulator (CoWorker) Utilization Test Suite Workflow (CUTS):

EnsureDesign

Conformance

ValidateDesignRules

Conduct“What If”Analysis


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


Challenges

• Ensuring the right granularity of QoS

• Using the standard RT CORBA API to configure QoS policies

• Specifying behavior of emulated application components to test the infrastructure

• 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

1.Preserving priorities end-to-end

2.Enforcing certain priorities at the server

3.Supporting thread pools effectively

4.Buffering client requests

5.Synchronizing objects correctly

6.Controlling network & end-system resources

C1: Providing the Right QoS Granularity

• 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

• 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

1.Preserving priorities end-to-end

2.Enforcing certain priorities at the server

3.Supporting thread pools effectively

4.Buffering client requests

5.Synchronizing objects correctly

6.Controlling network & end-system resources

Real-time CORBA provides QoS policies to overcome challenges above, including: Client

OBJREF

Object(Servant)

in argsoperation()

out args + return

IDLSTUBS

IDLSKEL

Object Adapter

ORB CORE GIOP

Protocol Properties

End-to-End PriorityPropagation

ThreadPools

StandardSynchronizersExplicit

Binding

Portable Priorities

SchedulingService

C1: Providing the Right QoS Granularity


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 ();

Programming Real-time CORBA QoS policies manually is tedious & error-prone

C2: Using the RT CORBA APIsAccidental Complexities

Declarative Configuration via XML:Better but not much better

Decouple QoS configuration from the core software logic


MDD Solution to QoS Configuration & Provisioning

MODEL

Specify a QoS model

INTERPRETER

IMPLEMENTS

METAMODEL

Provision Real-time Middleware QoS policies via XML

Generates

Approach:

•Develop a QoS Policy Modeling Language (QoSPML) w/GME that can synthesize XML descriptors that provision Real-time CORBA QoS policies

INTERPRETATION

REFLECTS


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: Specify Behavior for Emulated ComponentsContext

• People implementing a SOA application might come from different disciplines

–e.g., software architects, developers, & systems engineers

• CUTS users may not be familiar with 3rd generation programming or configuration languages

–e.g., C++ & Java or XML, respectively

Problem

• Providing alternative methods to programming CoWorkEr behavior & creating dense configuration files

use?


Solution: Use Domain–Specific Modeling Language to Program CoWorkEr Behavior

• Workload Modeling Language (WML) is used to define the behavior of CoWorkEr components



• WML events represent different types of workloads in CoWorkEr

Startup workload

Event-driven workload





• Actions are attached to events & specified in order of execution to define workload strings

–Each action has attributes, e.g., number of repetitions, amount of memory to allocate & etc

Attributes for CPUAction

Workload string





• Actions are attached to events & specified in order of execution to define workload strings

–Each action has attributes, e.g., number of repetitions, amount of memory to allocate & etc

• WML is interpreted to XML characterization files

• Characterization specified in CoWorkEr



C4: Using XML as Configuration Language• Accidental complexities of using XML to

configure QoS policies and to define emulated component behavior 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

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


C5: 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

• 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

Create/Modify Model

(Re)Interpret Model

(Re)Configure Application


Observed Benefits

• 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

Create/Modify Model

(Re)Interpret Model

(Re)Configure Application


Observed Benefits

• QoSPML and WML DSMLs complements each other in various ways

• QoSPML and WML can reduce the learning curve for the end users

• Despite the fact that QoSPML facilitates the seamless QoS configuration, we are still faced with the question of what constitutes a “good” configuration

META-MODEL

INTERPRETER

MODEL

INTERPRETATION

Specifies

Provides Interpretation

implements

reflects


Concluding Remarks

• The QoSPML and WML DSMLs have been integrated in the Component Synthesis with Model Integrated Computing (CoSMIC) tool chain available at:

• http://www.dre.vanderbilt.edu/cosmic/

• The Component Integrated ACE ORB (CIAO) can be downloaded from www.dre.vanderbilt.edu/CIAO/

• For more information on CUTS please check: www.cs.wustl.edu/~schmidt/PDF/CUTS.pdf

http://www.dre.vanderbilt.edu/cosmic/

http://www.dre.vanderbilt.edu/CIAO/

http://www.dre.vanderbilt.edu/CIAO/

http://www.cs.wustl.edu/~schmidt/PDF/CUTS.pdf


Any Questions

Domain-Specific Modeling Languages for Configuring and Evaluating Enterprise

DRE System Quality of Service

Stoyan Paunov, James Hill & Douglas Schmidt

Vanderbilt University, Nashville, TN

Steven D. Baker and John M. Slaby

Raytheon Company, Portsmouth, RI

ECBS 2006, Potsdam, Germany

Domain-Specific Modeling Languages for Configuring and Evaluating Enterprise DRE System Quality of...

Documents

Transcript of Domain-Specific Modeling Languages for Configuring and Evaluating Enterprise DRE System Quality of...