Dr. Aniruddha Gokhale a.gokhale@vanderbilt dre.vanderbilt/~gokhale

CoSMIC: A Model Driven Middleware for CoSMIC: A Model Driven Middleware for Provisioning Large-scale Distributed Provisioning Large-scale Distributed Real-time and Embedded SystemsReal-time and Embedded Systems

Dr. Aniruddha [email protected]

www.dre.vanderbilt.edu/~gokhale

Assistant Professor (EECS & ISIS)Vanderbilt UniversityNashville, TN 37203

Work supported by AFRL contract# F33615-03-C-4112 for DARPA PCES Program

2

Aniruddha Gokhale CoSMIC

Research Synopsis

Develop, validate, & help to standardize technologies that:

(1) Model(2) Analyze(3) Synthesize &(4) Provision

multiple layers of middleware for distributed real-time and embedded (DRE) systems that require simultaneous control of multiple quality of service properties end-to-end

Model Driven Approach for Distributed Real-time & Embedded MiddlewareModel Driven Approach for Distributed Real-time & Embedded MiddlewareModel Driven Approach for Distributed Real-time & Embedded MiddlewareModel Driven Approach for Distributed Real-time & Embedded Middleware

Middleware

MiddlewareServices

DRE Applications

Operating Sys& Protocols

Hardware & Networks

<CONFIGURATION_PASS> <HOME> <…>

<COMPONENT> <ID> <…></ID> <EVENT_SUPPLIER> <…events this component supplies…> </EVENT_SUPPLIER> </COMPONENT> </HOME></CONFIGURATION_PASS>



distributed system

3


Distributed Real-time & Embedded Systems

•Stringent simultaneous quality of service (QoS) demands

•Part of larger systems•Resource constrained

•Stringent simultaneous quality of service (QoS) demands


•Network-centric & large-scale•Dynamic context•Stringent simultaneous quality of service (QoS) demands


•Network-centric & large-scale•Dynamic context•Stringent simultaneous quality of service (QoS) demands


The Past The Future

4


Historical Overview of DRE Systems Development

Technology ProblemsDRE systems have

historically tended to be:StovepipedProprietary

Brittle & non-adaptiveExpensiveVulnerable

Historically, mission-critical apps were built directly atop hardware

•Tedious•Error-prone•Costly over lifecycles

IOM

IOM

IOM

IOM

IOM

IOM

IOM

IOM

IOM

IOM

IOM

IOM

IOM

IOM

IOM

IOM

IOM

IOM

BSE

BSE

BSE

BSE

BSE

BSE

BSEBSE

BSE

Middleware

MiddlewareServices

DRE Applications

OperatingSystems

Hardware & Networks

Middleware

MiddlewareServices

DRE Applications

OperatingSystems

Hardware & Networks

•Middleware has effectively factored out many reusable mechanisms & services from what was traditionally DRE application responsibility

•Middleware is no longer primary DRE system performance bottleneck

5


Layers of Middleware for DRE Systems

Middleware characteristics

•Uniform abstraction over h/w & OS e.g., JVM, ACE

•Distribution capabilities like location transparency, data marshaling e.g., CORBA, J2EE, webservices

•Commonly used higher level services e.g., Naming, Event

•Services specific to domains e.g., Bold Stroke (Avionics), AMW (telecom)

Middleware

MiddlewareServices

DRE Applications


Hardware & Networks

6


R&D Contributions to Middleware for DRE Systems• Network Element Software Management, Network contact center service

• patent pending

• Fault tolerant CORBA technologies & standardization effort

• HiPC 00, DOA 00, J. Cluster Computing 03

• The TAO high-performance, Real-time CORBA ORB

• Influenced Real-time CORBA standard• ACM Sigcomm96, IEEE Journal of Selected

Areas in Communication 99, IEEE Transactions on Computing 97, Journal of Real-time systems 99, IEEE Globecomm 96/97, IEEE Comm 97

• Automatic test suite generation for protocol conformance testing

• ASU Master’s thesis

Middleware

MiddlewareServices

DRE Applications


Hardware & Networks

7


Emergence of Component Middleware•Component middleware gaining importance (CCM, J2EE, .NET)

•Components encapsulate application core logic

•Components possess•Event sinks & sources•Connection points e.g., receptacles• Interfaces e.g., facets•attributes

•Containers provide execution environment for components with common operating requirements

•Containers communicate via a middleware bus

Middleware Bus

SecurityReplication NotificationPersistence

Container

… …

…

8


DRE Systems: The Challenges Ahead

Win2K Linux LynxOS

Solaris VxWorks

CORBA

CORBAServices

CORBAApps

MIDDLEWARE ARCHS

J2EE

J2EEServices

J2EEApps

.NET

.NETServices

.NETApps

Middleware

MiddlewareServices

DRE Applications


Hardware & Networks

•There is a limit to how much application functionality can be factored into broadly reusable COTS middleware

•Middleware has become extremely complicated to use, configure, & provision statically & dynamically

•There are now multiple middleware technologies to choose from

9


Related Work: •MIC, Vanderbilt (Sztipanovits, Karsai, et al)

•Ptolemy, UC Berkeley (Lee et al)•Cadena, KSU (John Hatcliff et al)•Quality Connector, LMCO (Joe Cross et. al)

Key Benefits•Preserves DRE application functional & systemic QoS properties as high level models

•Domain-specific languages & analysis/synthesis tools transform models to customize underlying multi-layered middleware platforms

•Leverages & shapes standards for wider applicability

Our Solution: Model-Driven Middleware for DRE Systems

Middleware Bus


Container

… …

Container

… …





10


MDA-Middleware Integration

1.Configuring and deploying application services end-to-end

2.Composing components into component servers

3.Configuring application component containers

4.Synthesizing application component implementations

5.Synthesizing dynamic QoS provisioning and adaptation logic

6.Synthesizing middleware-specific configurations

7.Synthesizing middleware implementations

ComponentRepository

Compose Deploy

Middleware Bus

CentralDataStore

1

System Development

Field RadarControlSystem

ChicagoData

Center

ComponentAssembly

FlightScheduling

2

CoSMICModel

Interpreter &Synthesizer

UML Model

selectcomponents

CIAO

ContainerCORBA

Component

ComponentHome

POA

QoS PropertyAdaptor

QoS Policies

Re

flect

4

CCM Component Library

1

ORB

ORB QoS Interfaces(Scheduling,

Timeliness,Priority,...)

ORB Plugins

ORBMetadata

6

7

3

5

AirportTrafficControl

11


Our Target Middleware: CIAO CORBA Component Model

www.dre.vanderbilt.edu/CIAOComponent Integrated ACE ORB (CIAO)

Focus on infrastructure support for composition of the following aspects CIDL compiler to synthesize component descriptor metadata & stubs/skeletons RT event channel integration with CIAO containers Assembly & deployment framework Collaboration with Washington University

RT EventChannel

RT EventChannel

12


Boeing Bold Stroke: Our Research Vehicle

•Avionics Product Line Component Model

•DRE system with 3,000+ domain-specific software components, 3-5 million lines of C++ code

•100+ developers

•Mission-control software for Boeing military aircraft, e.g., F-18 E/F, Harrier, UCAV

•Leverages the ACE+TAO middleware

•Used as Avionics Open Experimental Platform (OEP) for DARPA/IXO PCES & MoBIES programs

•Moving towards using CIAO CCM

13


Bold Stroke Architectural Elements

•Hardware organization

•ACE+TAO real-time CORBA distribution middleware

•Push-based event model•Pull-based data model

•This common usage simplifies assembly complexity

•Application components (consumer)

•Application components (supplier)

14


Bold Stroke Illustrative Example

Basic Modal Single Process Product Scenario (2 operational modes)

Determining the right assembly and deployment

Determining the right assignment of priorities

Determining the right concurrency strategy

Adapting to changing operating conditions

15


Research Thrusts of CoSMICApplying MDA to address

1.the end-to-end deployment aspect of DRE applications

2.the component container configuration aspect3.the middleware configuration aspect4.the dynamic QoS provisioning & adaptation

aspect

…

Container

… …

TIMER20Hz

GPS

NAV DISP

•Our tool suite is called CoSMIC

•CoSMIC = Component Synthesis using Model Integrated Computing

Middleware Bus


16


Challenge 1: Component Assembly & Deployment

•Application components are assembled and then deployed in a way that provides optimum resource utilization & delivers required QoS to the application•e.g., Bold Stroke scenarios involve assembling & deploying hundreds of components

•Assembly & deployment can be scripted by using XML descriptors & deployment tools

CONTEXT

TIMER20Hz

GPS NAV DISP

17


Challenge1: Component Assembly & Deployment

<!– Associate components with impls --><componentfiles> <componentfile id=“RateGenerator"> <fileinarchive name=“HouseRateGen.csd"/> </componentfile>

<componentfile id=“HiResGPS"> <fileinarchive name=“aGPS.csd"/> </componentfile>

<componentfile id=“cockpitDisplay"> <fileinarchive name=“navDisplay-if.csd"/> </componentfile>

</componentfiles>

PROBLEMSXML file in excess of 3,000 lines for medium sized scenarios

Existing practices involve handcrafting the XML descriptors

Partitioning, Distribution and Deployment done in ad hoc manner

Modifications in assembly requires modifying XML file

18


• ESML developed by Dr. Gabor Karsai et. al for DARPA/IXO MoBIES program

• CIDL compiler developed by our group at ISIS

•A domain-specific Component Descriptor Modeling Language (CDML)Currently leverages ESML for synthesis of assembly descriptors

ESML allows modeling component behavior & interactions in Bold Stroke

•Analyze component requirements and synthesize deployment scripts

•Synthesize component glue code to interact with environment

SOLUTION


19



Next StepsDevelop a component descriptor modeling language (CDML)

Synthesize assembly descriptor metadata

Synthesize platform-specific metadata

Synthesizecustom strategiese.g., lazy or eager

Determine appropriate assembly & deployment

21


Challenge 2: Configuring Container Policies

•Components execute in containers that decouple runtime configuration from the component implementation e.g.,Priority propagation modelsThreading modelsSecurity, replication, persistence policies

Internal buffer sizese.g., Boldstroke components run in a multithreaded environment with different end-to-end priorities

•Usually specified by the deployer using XML-based metadata

TIMER20Hz

GPS

TIMER1 Hz

PILOTCONTROL

NAV DISP

TIMER5 Hz

NAVIG-ATOR

Highpriority

Mediumpriority

Lowpriority

CONTEXT

22


server object management middleware


•Existing techniques for metadata configurations rely on ad hoc manual configurations e.g., CORBA server-side programming

PROBLEMS

Determine the server object management policies

Determine right buffer sizes

Determine thread pool sizes; how are they shared; number of lanes and their priorities; if borrowing is enabled

Determine various middleware policies for server objects e.g., security, lifetime, replication

•This “glue code” is traditionally handcrafted

Ensure semantic compatibility among chosen configurations

Determine end-to-end priority propagation model to use

23


• Develop a domain-specific Container Policy Modeling Language (CPML)

• Current version restricted to container configuration glue code generation in the CORBA environment

• Container policies are still manually chosen

Challenge 2: Configuring Container PoliciesSOLUTION

24



TIMER20Hz

GPS

NAV DISP

Highpriority

Next Steps

•Extend CPML to capture application QoS requirements in a platform independent form

•Design model transformers to desired platforms

•Develop tools that will determine the right values for various platform-specific parameters

server object management middleware

26


Challenge 3: Configuring Middleware End-to-End

I/O Subsystem

M/WBus

SkeletonStub

20 10 5 1 20 10 5 1

•Middleware must be configured with the appropriate systemic metadata end-to-end•e.g., in Bold Stroke example, appropriate priority banded connections must be set between application services

NAV DISPGPSNAV

STEERINGPILOT

CONTROL

CONTEXT

27



I/O Subsystem

M/W Bus

SkeletonStub

20 10 5 1 20 10 5 1

PROBLEMSDetermine right concurrency strategy

Determine right demux strategy

Determine right marshaling optimizations

Determine right connection mgmt policy

Configuring subset of underlying transports

•Highly flexible middleware tend to provide numerous configuration knobs that can be configured to deliver required systemic properties to applications

•Existing techniques of metadata configurations rely on ad hoc manual selection of configuration parameters

28


Challenge 3: Configuring Middleware End-to-EndSOLUTION

•Developed a domain-specific modeling language for TAO/CIAO called Options Configuration Modeling Language (OCML) using GME

•User provides a model of desired options & their values e.g.,

•Middleware bus resources

•Concurrency & connection management strategies

•Constraint checker flags incompatible options

•Synthesizes XML descriptors for middleware configuration

29



TIMER20Hz

GPS

NAV DISP

Highpriority

Next Steps

•Extend OCML to capture application QoS requirements in a platform independent form

•Design model transformers to synthesize platforms-specific configuration models

•Design tools that will determine the right values for various platform-specific configuration parameters

30


Challenge 4: End-to-end QoS Provisioning & Enforcement

QoSSystemic Path

Operating System

Middleware

SysCondition

Mechanism & PropertiesManager

Applications

Operating System

CONTEXT

Appln Server Appln ServerStatic configuration

Need to provide runtime QoS adaptation along functional path

Made feasible using adaptive & reflective middleware

e.g., BBN QuO, UIUC Quarterware, Lancaster OpenORB

31


Challenge 4: End-to-end QoS Provisioning & Enforcement

QoSSystemic Path

Operating System

Middleware

SysCondition

Mechanism & PropertiesManager

Applications

Operating System

PROBLEMSGlue code depends on the adaptive/reflective middleware used

Most existing middleware not designed to collect and distribute QoS metadata

Need to retrofit middleware to collect and distribute desired QoS metadata

Need to add instrumentation code to collect QoS metadata

Instrumentation code manually handcrafted

32


Challenge 4: End-to-end QoS Provisioning & EnforcementSOLUTION

MiddlewareModels

IntegratedModels

QoS Metadata

model

Program Transformation

Tool

Language-specificQoS aspects

generator

Collaboration with Dr. Jeff Gray (UAB)

Middleware

Applications

Operating System

Interceptor

Endsystem

LocalResourceManage-

ment

Infrastructure Middleware

Distribution Middleware

Common Services

Domain-Specific Services

33


Middleware

Applications

Operating System

Interceptor

Endsystem

LocalResourceManage-

ment

Infrastructure Middleware

Distribution Middleware

Common Services

Domain-Specific Services

Challenge 4: End-to-end QoS Provisioning & EnforcementNext Steps

MiddlewareModels

IntegratedModels

QoS Metadata

model

Program Transformation

Tool

Language-specificQoS aspects

generator

Domain specific modeling language for QoS metadata

Domain specific modeling language for middleware models

Develop model weaver

Develop generators

34


Research Impact & Future Work•Current progress stems from years of iteration, refinement, & successful use

Year1970 2010

ARPAnet

RPC

Micro-kernels

CORBA & DCOM

Real-time (RT)CORBA

Component Models (EJB)

CORBA ComponentModel (CCM)

RT/CCM

DCE

CoSMIC

Future Research Directions•High confidence, geographically distributed DRE systems

•Grid applications•Large enterprise systems•Focus on platform-independent models

Future Research Directions•High confidence, geographically distributed DRE systems

•Grid applications•Large enterprise systems•Focus on platform-independent models

Model integratedmiddleware

Shape the standards e.g., OMG’s Model Driven Architecture (MDA)

Advance

d MDA

ACE/TAO

2000 2005

35


Concluding RemarksModel, analyze, synthesize, and provision middleware technologies at multiple layers for distributed real-time and embedded systems that require simultaneous control of multiple quality of service properties end-to-end

1. Configure and deploy DRE applications end-to-end

2. Configure application component containers

3. Synthesize middleware-specific configurations

4. Synthesize dynamic QoS provisioning and adaptation logic

Model Driven Approach to:

www.dre.vanderbilt.edu/~gokhale/cosmic.html

36


Vanderbilt DRE DOC Group Capabilities

• Faculty: Dr. Douglas C. Schmidt• Research Scientist: Dr. Aniruddha Gokhale• Research Engineers: Bala Natarajan, Jeff Parsons, Boris Kolpakov, Tao Lu• Grad/UGrad Students: B. Krishnakumar, George Edwards, Emre Turkay,

Arvind Krishna, J. Balasubramaniam, Gan Geng

Pa

tter

ns

& P

atte

rn

La

ng

ua

ge

s

ACE Host Infrastructure Middleware

ConfigurableCommunication

Systems

Mission CriticalDoD Systems

IndustrialProcessControl

MedicalImagingSystems

TAO CORBA Distribution Middleware

CIAO CORBA Component Middleware

CoSMIC Model Driven Architecture

37


Downloading the Middleware & Tools

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

• Beta and Stable release can be accessed from http://www.dre.vanderbilt.edu/Download.html

38


•Patterns & frameworks for concurrent & networked objects•www.posa.uci.edu•www.ace.uci.edu

•ACE & TAO open-source middleware•www.cs.wustl.edu/~schmidt/ACE.html•www.cs.wustl.edu/~schmidt/TAO.html

•DRE research papers•www.cs.wustl.edu/~schmidt/research.html

•DRE tutorials•www.cs.wustl.edu/~schmidt/tutorials.html

•ACE books•www.cs.wustl.edu/~schmidt/ACE/

Additional Information

Dr. Aniruddha Gokhale a.gokhale@vanderbilt dre.vanderbilt/~gokhale

Documents

Transcript of Dr. Aniruddha Gokhale a.gokhale@vanderbilt dre.vanderbilt/~gokhale