Provisioning Dynamic QoS Adaptation for Enterprise Distributed Real-time Embedded (DRE) Systems

Provisioning Dynamic QoS Adaptation for Enterprise DRE Systems

March. 3, 2006

1

Provisioning Dynamic QoS Adaptation Provisioning Dynamic QoS Adaptation for Enterprise Distributed Real-time for Enterprise Distributed Real-time

Embedded (DRE) SystemsEmbedded (DRE) Systems

Vanderbilt University Nashville, Tennessee

Institute for Software Integrated Systems

Proposal Defense, March 3rd, 2006

Gan [email protected]

www.dre.vanderbilt.edu/~dengg


March. 3, 2006

2

Presentation Road Map

• Research Motivation • Taxonomy of Related Research • Research Challenges & Proposed Solutions• Evaluation of Success• Dissertation Timeline


March. 3, 2006

3

R&D Motivation: Enterprise DRE SystemsKey Characteristics

• Large-scale, network-centric, dynamic, “systems of systems”

• Highly diverse & complex problem domains

• Simultaneous QoS demands with resource constraints–e.g., loss of resources

Examples• Mission-critical systems for critical

infrastructure• e.g., power grid control,

real-time warehouse management & inventory tracking

• Total Ship Computing Environment (TSCE)• http://peoships.crane.navy.mil/ddx/


March. 3, 2006

4

Demands of Traditional DRE SystemsU

tility

Resources

Utility “Curve”

“Broken” “Works”

“Harder” Requirements

Traditional closed DRE Systems

Key Characteristics• Stringent timing requirements,

e.g., deadline, latency & jitter

• System resources & workloads are known in advance

• System resources & workloads change infrequently


March. 3, 2006

5

Demands of Enterprise DRE SystemsKey Challenges• Highly heterogeneous platform,

languages & tool environments

• Changing system running environments

• Enormous inherent & accidental complexities

Resources

Util

ity

Desired Utility Curve “Working

Range”

“Softer” Requirements

Util

ity

Resources

Utility “Curve”

“Broken” “Works”

“Harder” Requirements

My R&D goal is to ensure end-to-end real-time QoS for enterprise DRE systems

Enterprise DRE Systems


March. 3, 2006

6

Middleware Bus

Container

…

•Components encapsulate application “business” logic

•Components interact via ports•Provided interfaces, e.g.,facets•Required connection points, e.g., receptacles

•Event sinks & sources•Attributes

•Containers provide execution environment for components with common operating requirements

•Components/containers can also•Communicate via a middleware bus & •Reuse common middleware services

•All components must be deployed & configured (D&C) into the target environment

SecurityReplication TransactionPersistence

…

Container

… …

Promising Solution: Component Middleware


March. 3, 2006

7

Enterprise DRE System D&C Requirements• Large scale, i.e., thousands

of components • Systems ideally use

standards-based middleware & D&C model

• Configure underlying middleware to provision desired real-time QoS settings

Thread Pool

LanePrio = 100

LanePrio = 200

Thread Pool

ORB CORE

Card Scenarios based on DARPA ARMS program


March. 3, 2006

8

Enterprise DRE System D&C Requirements• Large scale, i.e., thousands

of components • Systems ideally use

standards-based middleware & D&C model

• Configure underlying middleware to provision desired real-time QoS settings

• Reconfigure the system on demand to accommodate dynamically changing system operating conditions

Enterprise DRE systems require bounded & scalable (re)deployment & (re)configuration capabilities to ensure end-to-end QoS


March. 3, 2006

9

Component Deployment & Configuration (D&C)

SW DeployerDeployment

InfrastructureDeployment Tools (generic)

DeploymentInterfaces

InfrastructureInterfaces

Shipping

SWCreator2

A2A1

Deploymentrequirements

Implementations

SW Creator1

OMG Deployment & Configuration (D&C) specification (ptc/05-01-07)

Goals of D&C Phase– Promote component reuse– Build complex applications by assembling

existing components– Automate common services configuration– Declaratively inject QoS policies into applications– Dynamically deploy components to target

heterogeneous domains – Optimize systems based on component

configuration & deployment settings


March. 3, 2006

10

Component Deployment & Configuration (D&C)

SW DeployerDeployment

InfrastructureDeployment Tools (generic)

DeploymentInterfaces

InfrastructureInterfaces

Shipping

SWCreator2

A2A1

Deploymentrequirements

Implementations

SW Creator1

InterchangeFormats

D & CProfile

XMLSchemaGeneration

IDLGeneration

OMG D & C Spec(PIM & PSMs)

OMG Deployment & Configuration (D&C) specification (ptc/05-01-07)My research enhances the D&C spec to support dynamic QoS provisioning


March. 3, 2006

11




March. 3, 2006

12

QoS Provisioning TimeDevelopment Time Deployment Time

Abs

trac

tion

Leve

lDO

CM

iddl

ewar

ePr

ogra

mm

ing

Lang

uage

s

Development-time QoS DOC

Middleware(RT-CORBA, RTSJ)

Deployment-time QoS DOC

Middleware(QuO,

dynamicTAO)

Development-time Aspect-Oriented

Languages(AspectJ,

AspectC++)

Com

pone

ntM

iddl

ewar

e

Runtime

Development-time QoS Component

Middleware(CIAO, Real-time EJB)

Deployment-timeQoS Component

Middleware(Qosket)

Runtime QoS Component

Middleware(SOFA, BARK,DynamicCIAO)

Deployment-time QoS Languages

(Java Adaptation Class, Specialization Class)

Runtime QoS DOC

Middleware(ACT Generic

CORBA Proxy)

Runtime QoS Languages

(AspectWerkz,PROSE)

Taxonomy of Research Continuum for Real-time QoS Provisioning


March. 3, 2006

13

Development-time QoS Provisioning• Key Ideas:

– Raise the level of abstraction by viewing QoS policies as first-class entities

– Use specialized languages features (e.g., AspectJ or AspectC++), middleware programming interfaces (e.g., Real-time CORBA), or QoS composing techniques (e.g., configuration metadata) to provision QoS statically

Component A Component B

Code Scattering Code tangling


March. 3, 2006

14

Related Research: Development-time QoS ProvisioningResearch Category

Related Research

Programming Language

• AspectC++ Gal et al. "On Aspect-Orientation in Distributed Real-time Dependable Systems," IEEE WORDS 2002.

• AspectJ Tsang et al. "An Evaluation of Aspect-Oriented Programming for Java-Based Real-Time Systems Development," IEEE ISORC 2004.

DOC Middleware

• Real-time CORBA Object Management Group. “Real-time CORBA, v2.0," formal/2003-11-01, OMG Press 2003

• Real-time Java Bollella et al. “The Real-Time Specification for Java”, Addison-Wesley 2000

• AOP in CORBA Zhang et al. “Resolving Feature Convolution in Middleware Systems”, ACM OOPSLA 2004

Component Middleware

• RTCCM Wang et al. "Configuring Real-time Aspects in Component Middleware", OTM DOA 2004.

• RT-EJB Miguel et al. "Integration of QoS Facilities into Component Container Architectures," IEEE ISORC 2002.

• Prism Roll et al. “Towards Model-Based & CCM-Based Applications for Real-Time Systems,” IEEE ISORC 2003

Development-time QoS provisioning is mainly suited for closed DRE systems


March. 3, 2006

15

Development-time QoS Provisioning: What is Missing?

• Unresolved Challenges– What if system resources &

workloads fluctuate frequently?– Development-time QoS

provisioning can not address the problem because all real-time QoS settings are fixed

Solution: Deployment-time QoS Provisioning


March. 3, 2006

16


Abs

trac

tion

Leve

lD

OC

Mid

dlew

are

Prog

ram

min

gLa

ngua

ges




Middleware(QuO,

dynamicTAO)


Languages(AspectJ,

AspectC++)

Com

pone

ntM

iddl

ewar

e

Runtime




Middleware(Qosket)





Runtime QoS DOC


CORBA Proxy)


(AspectWerkz,PROSE)



March. 3, 2006

17

Systemic(QoS) Aspects

Analyzer

AspectCompiler/Weaver

Constraints,Hints

Context (UAV OEP)

AdaptivemiddlewareMiddlewareservices

Application CodeWovenapplicationcode

ConnectivityAspects

FunctionalAspects

Deployment-time QoS Provisioning• Key Ideas:

– Use declarative approach to describe service contracts that capture adaptation rules & policies to specify when & how

– Use special compiler or aspect weaving tools to synthesize or weave code to provision specified adaptive behavior

– Generated application can be “reflective” to allow runtime adaptation

Specify QoS Service

Contracts

Woven adaptation

behavior code

Specialized Compiler or

Aspect weaver

Runtime PhaseDeployment-time Phase


March. 3, 2006

18

Related Research: Deployment-time QoS ProvisioningResearch Category

Related Research

Programming Language

• Specialization Class Volanschi et al. "Declarative Specialization of Object-oriented Programs," ACM OOPSLA 1997.

• Java Adaptation Class Boinot et al. “Declarative Approach for Designing & Developing Adaptive Components”, IEEE ASE 2000

DOC Middleware • QuO Zinky et al. “Architectural Support for Quality of Service for CORBA Objects”, Theory & Practice of Object Systems, April 1997

• ControlWare Zhang et al. “ControlWare: A Middleware Architecture for Feedback Control of Software Performance”, IEEE ICDCS 2002

• FCS/nORB Lu et al. “Feedback Control Real-Time Scheduling in ORB Middleware”, IEEE RTAS 2003


• Qosket Schantz et al. "Packaging Quality of Service Control Behaviors for Reuse", IEEE ISORC 1999.

• Qosket/CIAO Wang et al. “Total Quality of Service Provisioning in Middleware & Applications”, Microprocessors & Microsystems, special issue on Middleware Solutions for QoS-enabled Multimedia Provisioning over the Internet March 2003.

Suitable for DRE systems where QoS adaptation rules are known a priori


March. 3, 2006

19

Deployment-time QoS Provisioning: What is Missing?• Unresolved Challenges

– Adaptation rules or utility control models still must be known a priori– It’s hard to handle dynamically changing operating conditions since new

application behavior & adaptations are needed after systems are deployed

Emergency response required!

Solution: Runtime QoS Provisioning


March. 3, 2006

20


Abs

trac

tion

Leve

lD

OC

Mid

dlew

are

Prog

ram

min

gLa

ngua

ges




Middleware(QuO,

dynamicTAO)


Languages(AspectJ,

AspectC++)

Com

pone

ntM

iddl

ewar

e

Runtime




Middleware(Qosket)





Runtime QoS DOC


CORBA Proxy)


(AspectWerkz,PROSE)



March. 3, 2006

21

• Key Ideas– Decouple system adaptation policy from system application code & allow

them to be changed independently from each other– Decouple system deployment framework & middleware from core system

infrastructure to allow enterprise DRE systems dynamically reconfigurable

Runtime QoS Provisioning

System ObserversSystem ObserversSystem Condition Observers

System Deployment AgentsSystem D&C Actors

& Middleware

Adaptation Planner

My Research Focus Area

ControlAlgorithmControlAlgorithm

AdaptationPlan

SystemConditions

Running Systems


March. 3, 2006

22

Related Research: Runtime QoS ProvisioningResearch Category

Related Research

Programming Languages

• PROSE Popovici et al. “Efficient Dynamic Weaving for Java”, ACM AOSD 2003

DOC Middleware

• Adaptive CORBA Template Sadjadi et al. “Transparent Self-optimization in Existing CORBA Applications”, IEEE ICAC 2004

• XRMI Chen et al. “Extending RMI to Support Dynamic Reconfiguration of Distributed Systems”, IEEE ICDCS 2002


• SOFA Frantisek et al. “SOFA/DCUP: Architecture for Component Trading & Dynamic Updating.”, IEEE ICCDS 1998

• BARK Rutherford et al. “Reconfiguration in the Enterprise Component Model”, ACM/IFIP CD 2002

• Adaptive .NET Rasche et al. “Configuration & Dynamic Reconfiguration of Component-based Applications with Microsoft .NET”, IEEE ISORC 2003

• OpenCOM Coulson et al. “A Component-based Middleware Framework for Configurable & Reconfigurable Grid Computing”, Concurrency & Computation: Practice & Experience, 2006

• JAsCo (Dynamic AOP) Vanderperren et al. “Adaptive Programming in JAsCo”, AOSD 2005

Runtime QoS provisioning is essential for enterprise DRE systems


March. 3, 2006

23

Runtime QoS Provisioning: What is Missing?• Unresolved Challenges

1. How to dynamically reconfigure enterprise DRE systems & real-time policies from the perspective of different end-users?

2. How to make reconfiguration process more predictable & time-bounded?3. How to simplify the planning of reconfiguration process workflow?

http://www.takeourword.com/images/persistence-of-memory.jpg


March. 3, 2006

24




March. 3, 2006

25

Research Goals• Computational model –

Develop dynamic reconfiguration techniques for enterprise DRE systems

• Execution platform – Map the dynamic reconfiguration techniques to a more predictable & time-bounded execution platform

• Programming model – Develop a domain-specific modeling language to simplify dynamic reconfiguration workflow

Constraint is to support standards-based component & D&C model

Operational string

App App App App

App


March. 3, 2006

26

Limitations with OMG D&C Model

• The existing D&C model cannot change the configuration once an application is deployed

–Must shutdown the entire application & redeploy, which is not feasible for enterprise DRE systems

Applicationsalways static

No QoS Assurance

HypothesisExisting CCM components

& applications could be enhanced with dynamic

capabilities w/out breakingstandard component

programming model & D&C model

Baseline: DAnCE Deployment And Configuration Engine (D&C Spec)

SW Deployer Target EnvironmentD&C Tools

D & CProfile

RunningApplications

• The existing D&C model cannot ensure real-time QoS when performing initial D&C & reconfiguration

–Enterprise DRE systems have stringent QoS requirements for dynamic redeployment & reconfiguration

G. Deng et al, “DAnCE: A QoS-enabled Component Deployment & Configuration Engine”, ACM/IFIP Component Deployment’ 05, Grenoble, France, November 28-29, 2005.


March. 3, 2006

27

• Context– Enterprise DRE systems

may have thousands of components distributed across hundreds of nodes

– Components are often grouped together by system architect in the form of operational strings

• Problem– How to make enterprise

DRE systems manageable from end-users (e.g., software architect, software engineer) perspective?

Challenge 1: Reconfigure Enterprise DRE Systems from End-User Perspective

Time-critical end-to-end path through operational string


March. 3, 2006

28

• Develop a ReDaC computational model:– Introduce operational strings as first-class entities– Provide a rich set of services to manage enterprise DRE systems &

system resources at different levels of granularity• Components

Solution ReDaC Computational Model

MLRMInfrastructure

Resource Pool

Resources

MLRMInfrastructure

Resource Pool

Resources

Add_Instance <Plan ID> <Node ID> <Component Type> <Policy Set>Remove_Instance <Plan ID> <Component ID>Bind <Plan ID> <Source Component ID : Port Name> <Dest Component ID : Port Name>Remove_Binding <Plan ID> <Source Component ID : Port Name> <Dest Component ID : Port Name>

App App

Real-time policy set


March. 3, 2006

29

MLRMInfrastructure

Resource Pool

Resources

MLRMInfrastructure

Resource Pool

Resources

• Develop a ReDaC computational model:– Introduce operational strings as first-class entities– Provide a rich set of services to manage enterprise DRE systems &

system resources at different levels of granularity• Components• Operational strings


App AppOperational string

App App App App

Add_OpString <Plan ID> <OpString Descriptor>Remove_OpString <Plan ID> <OpString ID>Update_OpString <Plan ID> <OpString Descriptor>Bind_OpString_OpString <Source OpString ID : Port ID> <Dest OpString ID : Port ID>

Mission


March. 3, 2006

30

MLRMInfrastructure

Resource Pool

Resources

MLRMInfrastructure

Resource Pool

Resources

• Develop a ReDaC computational model :– Introduce operational strings as first-class entities– Provide a rich set of services to manage enterprise DRE systems &

system resources at different levels of granularity• Components• Operational strings• Entire system deployment plan



App App App App

Mission

Deploy_Plan < Deployment Plan Descriptor>Teardown_Plan < Deployment Plan ID>Update_Plan < Plan ID> <Deployment Plan Descriptor>


March. 3, 2006

31

MLRMInfrastructure

Resource Pool

Resources

MLRMInfrastructure

Resource Pool

Resources

• Develop a ReDaC computational model :– Introduce operational strings as first-class entities– Provide a rich set of services to manage enterprise DRE systems &

system resources at different levels of granularity• Components• Operational strings• Entire system assemblies• Interactions among these entities through well-defined interfaces• Components shared by independently designed assemblies



App App App App

C1

Bind_OpString_Component <Plan ID> <OpString ID : Port ID> <Dest Component ID : Port ID>

Mission


March. 3, 2006

32

Current Status of ReDaCDesigned & implemented the baseline & integrated it with DAnCEEnhanced DAnCE to support configuring CCM components with RT policiesDesigned & implemented the initial ReDaC computational model• Adding a component is on a per-instance basis

– Specify component configuration & binding information – Specify what QoS policy the component should be configured– Container placement is transparent to clients for optimization

• Removing a component is on a per-instance basis– Reconfigurations are transparent to peer components

• Components could be shared across assemblies

Instance & binding configuration & QoS

Instance information

G. Deng et al, “Modularizing Variability & Scalability Concerns in DRE Systems with Modeling Tools & Component Middleware: A Case Study”, IEEE ISORC '06, Korea


March. 3, 2006

33

Criteria for EvaluationPerformance Criteria For Reconfiguration (Hypothesis)• Baseline – Existing DARPA ARMS GT4 Testbed, 3 operational strings,

with mission effectiveness values (MEV) of 3, 2, 2• Metric M1 – Average mission effective value loss of all operational strings

Goal: Reduce M1 value by 20-30%

1. Divide the total down time of each operational string by the total experiment operational time.

2. Multiply it by the MEV of that operational string to produce the average MEV loss for that string.

3. Sum up all average MEV loss.


March. 3, 2006

34

Research Contributions & Related Publications• Identified key D&C complexities for enterprise DRE systems• Propose to enhance standards-based component middleware to provision dynamic

capability for enterprise DRE systems to ensure QoS• Propose a ReDaC computational model to simplify the enterprise DRE system

reconfiguration 1. “Modularizing Variability & Scalability Concerns in Distributed Real-time &

Embedded Systems with Modeling Tools & Component Middleware: A Case Study”, IEEE ISORC '06, April 24-26, 2006, Gyeongju, Korea.

2. “DAnCE: A QoS-enabled Component Deployment & Configuration Engine”, ACM/IFIP CD’ 05, Grenoble, France, November 28-29, 2005.

3. “Addressing Domain Evolution Challenges for Software Product-line Architectures (PLAs)”, ACM/IEEE MoDELS 2005 workshop October 2, 2005, Jamaica.

4. “Concern-based Composition & Reuse of Distributed Systems”, ACM/IEEE ICSR8, Madrid, Spain, July 2004.

1st Author 3rd Author


March. 3, 2006

35

• Context– Multiple reconfiguration service requests might arrive simultaneously

• Problems– How to differentiate services from different requests based on their

priorities?

Challenge 2: Ensure Reconfiguration QoS

Non-Critical Critical


March. 3, 2006

36

Proposed Solution ReDaC Execution Platform• ReDaC Execution Platform for

Service Execution – A novel approach to integrate Real-

time CORBA (RT CORBA) features to build a predictable platform model

– All standards-based deployment agents (e.g., ExecutionManager, NodeApplicationManager, & NodeManager) are configured with appropriate RT CORBA policies & run atop RT CORBA middleware

− When external clients request setting up & modifying services, the priority level could also be specified as part of the request

Deployer

Deployer

Deployer

Deployer

Deploy_OpString <OpString Descriptor>

[Service Priority]

Execution Manager

DomainApplication

Manager


March. 3, 2006

37

• RT-CORBA Features Leveraged by ReDaC Execution Platform– Priority Model

• Use “ClientPropagated” policy to propagate client request priorities

– ThreadPool Model• Use “ThreadPoolWithLanes”

policy serve client requests concurrently

• The “lane” feature offers priority partitioning to avoid priority inversion

– Connection Model• Use PriorityBanded policy to

differentiate service request based on priority

Proposed Solution ReDaC Execution Platform

Thread Pool with Lanes

PRIORITY35

PRIORITY50

PRIORITY10

C L I E N TO R B C O R E

P 1 -5 P 1 0 -2 0 P 21 -1 0 0

S E R V E RO R B C O R E

_bind_ priority_ban d()

P 1- 5 P 1 0 -2 0 P 2 1-1 0 0

_bind_ priority_ban d()

Solaris Priority136

LynxOS Priority128


March. 3, 2006

38

Current Status of ReDaC Execution Platform• Initial Design Phase

Deploy_OpString <OpString Descriptor>

[Service Priority] Execution Manager

DomainApplication

Manager

Node ManagerNode

ApplicationManager

Node ManagerNode

ApplicationManager

NodeApplication

NodeApplication


PRIORITY35

PRIORITY50

PRIORITY10


PRIORITY35

PRIORITY50

PRIORITY10


PRIORITY35

PRIORITY50

PRIORITY10

Deployer


March. 3, 2006

39

Criteria for EvaluationPerformance Criteria For Reconfiguration (Hypothesis)• Baseline – Current DARPA ARMS GT4 Testbed (6 operational strings, with

priority values of 3, 2, 2, 2, 1, 1, & system workloads are high)• Metric M2 – Highest priority operational strings mission effective loss

Goal: Reduce M2 value by 20-30%

1. Determine when the first operational string with the highest MEV goes down and obtain that timestamp.

2. Subtract that from the timestamp when all operational strings with the highest MEV were first up.

3. Repeat if another operational string with the highest MEV goes down.

4. Sum up all highest MEV operational down time.5. Divide it by the total experimental measurement time


March. 3, 2006

40

Research Contributions & Related Publications

• Identified key complexities in provisioning predictable dynamic reconfiguration service for enterprise DRE systems

• Proposed a novel solution to address the above challenges by leveraging real-time CORBA features

1. “Supporting Configuration & Deployment of Component-based DRE Systems Using Frameworks & Aspects”, Poster paper of OOPSLA 2005, San Diego, CA, October 2005.

2. “Resolving Component Deployment & Configuration Challenges for DRE Systems via Frameworks & Generative Techniques”, Doctoral Symposium ACM ICSE 2006, Shanghai , China, May 20-28, 2006

1st Author 2nd Author


March. 3, 2006

41Challenge 3: Ad Hoc Techniques for Planning the System Reconfiguration Process

• Context: – Enterprise DRE system reconfiguration process is usually

composed of a number of subtasks

Operational string

App App App App

App

App


March. 3, 2006

42

Ad Hoc Techniques for Planning the Reconfiguration Process• Problem:

– How to allow the reconfiguration process to managed from end-users' perspective?

– How to specify the causal relationship among various subtasks?

Operational string

App App App App

App

App

1

2

3

4

5

5’


March. 3, 2006

43

Solution Reconfiguration Modeling Language (ReML)• Develop a ReDaC Programming Model called ReML:

– Allow end-users to declaratively specify the workflow of the reconfiguration process through ReML, a visual DSML

– Combine the ReML with ReDaC to provision full-fledged enterprise DRE system reconfiguration capability

AddOpString (XYZ)

BindOpString (X to Y)

RemoveInstance (W)

UpdatePlan (P1, P.cdp)


March. 3, 2006

44

Current Status of ReML• Initial Design Phase of ReML• Significant experiences gained before in developing DSMLs:

– Developed an Event QoS Aspect Modeling Language (EQAL), used in DARPA PCES program

• “Model-driven Configuration & Deployment of Component Middleware Publisher/Subscriber Services”, ACM GPCE ‘04, Vancouver, Canada, Oct 2004.

• “Model Driven Middleware: A New Paradigm for Deploying & Provisioning Distributed Real-time & Embedded Applications”, Elsevier Journal of Science of Computer Programming: Special Issue on Model Driven Architecture, 2006 (to appear).

• “Model-Driven Integration of Federated Event Services in Real-Time Component Middleware”, ACMSE ‘04, Huntsville, AL, Apr, 2004.


March. 3, 2006

45

Criteria for Evaluation• The Integration of ReDaC Programming Model & Computational Model

could reduce enterprise DRE systems reconfiguration effort (Hypothesis)– Metrics Lines of Code (LOCs) reduced– M3 = LOC Saved Per Instance (Estimated ~200 LOC)– M4 = LOC Saved Per Connection (Estimated ~200 LOC)– M5 = LOC Saved Per Operational String (Estimated ~5,000 LOC for a

size of 10 components & 15 connections)

Goal: Maximize the LOC SavingsOperational string

App App App App

App

App


March. 3, 2006

46

Research Contributions & Related Publications• Identified key complexities in provisioning reconfiguration workflow for

enterprise DRE systems

• Proposed a model-based solution to address the above challenge by leveraging model driven development (MDD) & domain-specific modeling language (DSML) technologies

1. “Model-driven Configuration & Deployment of Component Middleware Publisher/Subscriber Services”, GPCE ‘04, Vancouver, Canada, October 2004

2. “Model-Driven Integration of Federated Event Services in Real-Time Component Middleware”, ACMSE ‘04, Huntsville, AL, April 2-3, 2004

1st Author 2nd Author


March. 3, 2006

47

Summary of Research ContributionsTopic Benefits

Reconfiguration ComputationalModel

Identified key complexities in enterprise DRE system reconfiguration process, & proposed a novel computational model to provide a rich set of services to allow end-users to manage enterprise DRE systems & system resources at different levels of granularity

ReconfigurationExecution Platform

Identified key performance bottlenecks in enterprise DRE system reconfiguration process, & proposed a novel execution platform model to address reconfiguration predictability & scalability challenges

Reconfiguration Programming Model

Proposed a DSML-based solution to address key complexities in design and plan the reconfiguration workflow


March. 3, 2006

48




March. 3, 2006

49

Dissertation Timeline

ReDaC FrameworkDesign &

Implementation

May 2003 Dec 2005 Dec 2006

ReDaC RT EnhancementsReML Design

Methodology Validation & Architectural Design,

DAnCE Baseline

Initial ReDaCFramework

Implementation

ICSR 2004OOPSLA 2003 Workshop

OOPSLA 2004 PosterGPCE 2004

ACMSE 2004

CD 2005OOPSLA 2005 Poster

MoDELS 2005 WorkshopJournal of Sci of Comp

Programming 2006

ISORC 2006ICSE 2006 Doctoral Sym

ReDaC & ReML Implementation& Experiments

Dec 2004 March 2007

DAnCEArchitectural Design &Initial Implementation

I’m here

March 3, 2006


March. 3, 2006

50

Summary of Publications1. Modularizing Variability & Scalability

Concerns in Distributed Real-time & Embedded Systems with Modeling Tools & Component Middleware: A Case Study”, IEEE ISORC '06, Apr, 2006, Gyeongju, Korea.

2. DAnCE: A QoS-enabled Component Deployment & Conguration Engine, ACM/IFIP CD’ 05, Grenoble, France, Nov, 2005.

3. Addressing Domain Evolution Challenges for Software Product-line Architectures, ACM/IEEE MoDELS 2005 workshop Oct, Jamaica.

4. Evaluating Techniques for Dynamic Component Updating, OTM DOA '05, Agia Napa, Cyprus, Nov, 2005.

5. “Concern-based Composition & Reuse of Distributed Systems”, ACM/IEEE ICSR8, Madrid, Spain, Jul 2004.

6. “Model Driven Development of Inventory Tracking System”, ACM OOPSLA 2003 Workshop on DSML, Anaheim, CA, Oct 2003.

First Author 2nd Author Others

7. Supporting Configuration & Deployment of Component-based DRE Systems Using Frameworks, Models, & Aspects, Poster paper of ACM OOPSLA 2005, San Diego, CA, Oct 2005.

8. Model-driven Configuration & Deployment of Component Middleware Publisher/Subscriber Services, ACM GPCE ‘04, Vancouver, Canada, Oct 2004.

9. Model Driven Middleware: A New Paradigm for Deploying & Provisioning Distributed Real-time & Embedded Applications, Elsevier Journal of Science of Computer Programming: Special Issue on Model Driven Architecture, 2006 (to appear).

10. Model-Driven Integration of Federated Event Services in Real-Time Component Middleware, ACMSE ‘04, Huntsville, AL, Apr, 2004.

11. Resolving Component Deployment & Configuration Challenges for DRE Systems via Frameworks & Generative Techniques, Doctoral Symposium ACM ICSE 2006, Shanghai , China, May 2006


March. 3, 2006

51

Questions?

Documents

Provisioning Dynamic QoS Adaptation for Enterprise Distributed Real-time Embedded (DRE) Systems