Upload
hank
View
59
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Institute for Software Integrated Systems. Vanderbilt University Nashville, Tennessee. Model-Driven Engineering of Component-based Distributed Real-time & Embedded Systems. STI Project 2007 Status Report Krishnakumar Balasubramanian, Amogh Kavimandan {kitty, amoghk}@dre.vanderbilt.edu. - PowerPoint PPT Presentation
Citation preview
Model-Driven Engineering of Component-based Distributed
Real-time & Embedded Systems
Vanderbilt University Nashville, Tennessee
Institute for Software Integrated Systems
STI Project 2007 Status Report
Krishnakumar Balasubramanian, Amogh
Kavimandan{kitty, amoghk}@dre.vanderbilt.edu
STI Project 2007 Status Report• Vanderbilt’s contributions
• Model-Driven Engineering tool-chain
• Current year’s focus on two areas
• Model-driven Application Specific Optimizations (Kitty)
• Model-driven QoS Mapping (Amogh)
2
PICMLmodel
CH CH
CHCH
OS KERNEL
OS I/O Subsystem
Network Interfaces
MIDDLEWARE
Physical Assembly Mapper
Deployment Plan
Configuration Files
CH
Required Interface
Provided Interface
Event Sink
Event SourceComponent Home
Component Assembly
Component Invocation
Creates
CH
CH
CH
CH
CH
CH
CH
CH
CH CH
CHCH
Distributed Real-time & Embedded (DRE) Systems• Stringent Quality-of-Service (QoS)
demands, e.g., real-time constraints• Operate under limited resources
• e.g., avionics mission computing• Enterprise DRE Systems
• Simultaneous execution of multiple applications with varying importance
• Highly heterogeneous platform, language & tool environments
• e.g., Total Shipboard Computing Environment (TSCE)
• Use COTS middleware technologies• CORBA, RT-Java
• Use COTS Component/Service technologies
• CORBA Component Model (CCM), EJB, Web Services
3
4
Motivation for Application Specific Optimizations• Middleware tries to optimize
execution for every application
• Collocated method invocations
• Optimize the (de-)marshaling costs by exploiting locality
• Specialization of request path by exploiting protocol properties
• Caching, Compression, various encoding schemes
• Reducing communication costs
• Moving data closer to the consumers by replication
• Reflection-based approaches
• Choosing appropriate alternate implementations at run-time
5
Related ResearchCategory Related Research
Component Middleware
Wang, N. et al, Applying Reflective Techniques to Optimize a QoS-enabled CORBA Component Model Implementation, 24th Annual International Computer Software & Applications Conference Taipai, Taiwan, October 2000.
Teiniker, E. et al, Local Components & Reuse of Legacy Code in the CORBA Component Model, EUROMICRO 2002, Dortmund, Germany (2002)
Diaconescu, A. & Murphy, J., Automating the Performance Management of Component-based Enterprise Systems through the Use of Redundancy, Proceedings of the 20th IEEE/ACM international Conference on Automated Software Engineering (Long Beach, CA, USA, November 07 - 11, 2005).
Gurdip Singh & Sanghamitra Das, Customizing Event Ordering Middleware for Component-Based Systems, pp. 359-362, Eighth IEEE International Symposium on Object-Oriented Real-Time Distributed Computing (ISORC'05), 2005.
Web Services Gao, L et al, 2003, Application specific Data Replication for Edge Services, In Proceedings of the 12th International Conference on World Wide Web (Budapest, Hungary, May 20 - 24, 2003). WWW '03. ACM Press, New York, NY, 449-460.
Mukhi, N. K., 2004, Cooperative Middleware Specialization for Service Oriented Architectures, Proceedings of the 13th International World Wide Web Conference on Alternate Track Papers & Posters (New York, NY, USA, May 19 - 21, 2004).
6
Related Research: What’s missing?• Lack of a high-level notation to
guide optimization frameworks
• Missing AST of application
N N N N
N
N
N
N
NN
Application Abstract Syntax Tree
7
Related Research: What’s missing?• Lack of a high-level notation to
guide optimization frameworks
• Missing AST of application
• Detection at run-time (reflection)
• Additional overhead in the fast path
• Not suitable for DRE systems
• Intrusive optimizations, i.e., not completely application transparent
• Requires providing multiple implementations, e.g., EJB
• Optimization performed either
• Too early, or too late
8
Node Application
Container
CHCH
CHCH
CHCH
CHCH
CHCH
CHCH
CHCH
CHCH
CH
Receptacle
Facet
Event Sink
Event SourceComponent Home
Component Assembly
Component Remote Invocation
Collocated Invocation
Creates
1. Overhead of platform mappings
• Blind adherence to platform semantics
• Inefficient middleware glue code generation per component
• Example:
• Creation of a factory object per component
• Servant glue-code generation for every component
Need optimization techniques to build large-scale component systems!
Application Specific Optimizations: Unresolved Challenges
Solution Approach: Physical Assembly Mapper (PAM)
9
PICMLmodel
CH CH
CHCH
OS KERNEL
OS I/O Subsystem
Network Interfaces
MIDDLEWARE
Physical Assembly Mapper
Deployment Plan
Configuration Files
CH
Required Interface
Provided Interface
Event Sink
Event SourceComponent Home
Component Assembly
Component Invocation
Creates
CH
CH
CH
CH
CH
CH
CH
CH
CH CH
CHCH
• Physical Assembly Mapper
• Uses the application model as the input
• Exploits knowledge about platform semantics to rewrite the input model to a functionally equivalent output model
• Generates middleware glue-code
• Generates deployment configuration files
• Operates just before deployment
• Can be viewed as a “deployment compiler”
PAM Inputs• Set of 3 input graphs
• G1: (V1, E1),
V1 = { Application Components}
E1 = { Connections between application components}
• G2: (V2, E2),
V2 = V1 U {QoS configuration options on components}
E2 = { Connections between the components and the QoS options}
• G3: (V3, E3),
V3 = V1 U {nodes in the target deployment domain}
E3 = {Connections between the components and the nodes}
10
PAM Output
11
• Produces an output graph
• Go: (Vo, Eo),
• Vo = {Physical assemblies created on a single node}
• Eo = {Connections between the composites}
• Creation of physical assemblies subject to a number of constraints
• Average case
• |Vo| < |V1|
• Worst case
• |Vo| = |V1|, i.e., the optimizer couldn’t create any physical assemblies
• Equivalent to deployment of original application
Physical Assembly
12
• Physical Assembly
• Created from the set of components that are deployed within a single process of a target node
• Subject to various constraints
• Example constraints include:
• No two ports of the set of components should have the same name
• No two components should have incompatible RT-CORBA policies
• No changes required to individual component implementations
Physical Assembly Generation
13
• Given set of components deployed on a single process of a target node
• Compute pair-wise intersections of component port name sets
• If intersection is null, merge the two components into a physical assembly
• Additional RT-CCM constraint
• If intersection is null & RT-CORBA policies of the components are compatible
• e.g., PriorityPropagation Models, PriorityBands
• Physical Assembly indistinguishable to external clients
• All valid operations on individual components are still valid
Middleware Concepts Exploited by Physical Assemblies
14
• Opacity of object references
• Components don’t rely on specific details of object references, e.g., location of type information
• Allows replacing references transparent to component implementations
Middleware Concepts Exploited by Physical Assemblies
15
• Opacity of object references
• Components don’t rely on specific details of object references, e.g., location of type information
• Allows replacing references transparent to component implementations
• Presence of a component context
• Components access ports of other components using a context object
• Allows replacing context transparent to component implementations
Container
Servant
ComponentSpecificContext
CCMContext
MainComponent
Executor
ExecutorsExecutorsExecutors
POA
EnterpriseComponent
CCMContext
Container
Servant
ComponentSpecificContext
CCMContext
MainComponent
Executor
ExecutorsExecutorsExecutors
POA
EnterpriseComponent
CCMContext
user implemented
code
Container
CORBAComponen
t
POA
Ext
erna
lI n
t erf
ac e
s
InternalInterface
s
Middleware Concepts Exploited by Physical Assemblies
16
• Opacity of object references
• Components don’t rely on specific details of object references, e.g., location of type information
• Allows replacing references transparent to component implementations
• Presence of a component context
• Components access ports of other components using a context object
• Allows replacing context transparent to component implementations
• Clean separation between glue-code & component implementation
• Allows modifications transparent to component implementations
Technique can be applied to other middleware with these properties
Stub
Executors
Skel
IDL Compiler
IDL
CIDL
CIDL Compiler
Executor IDL
Servants
ExecutorStubs
IDL Compiler
XMLComponentDescriptors
17
Physical Assembly Evaluation Criteria • Footprint of physical assembly
components
• Compared to vanilla Component-Integrated ACE ORB (CIAO)
• Different scenarios
• Simple scenarios (<= 10 components)
• ARMS GateTest scenarios (150+ components)
• Reduce static & dynamic footprint
• Reduce no. of homes by (n – 1) / n
• Reduce no. of objects registered with POA by (n – 1) / n
• Reduce no. of context objects created by (n – 1) / n
n = no. of components deployed on a single process of a target node
CH CH
CHCH
CH CH
CHCH
CH CH
CHCH
CH CH
CHCH
Assembly Optimizer
Factory
CHCH
CH
CH
CH
CH CHCH
Evaluating Physical Assemblies
• Boeing’s BoldStroke Basic Single Processor Scenario• Consists of 4 components
• Timer – Periodically sends refresh signal to the GPS• GPS – Calculates new co-ordinates of the aircraft in response
to Timer signal• Airframe – Processes new location inputs from GPS• Display – Updates the new location of the aircraft in the
navigation display18
Applying Physical Assemblies to BasicSP Scenario
• Assumption: GPS, Airframe and Display components are deployed on a single processor board
• Applying physical assemblies • Combines GPS, Airframe and Display components into a
single physical assembly (BasicSPAsm)• Maintains the same number of connections• Timer component not combined (due to clash in port names)
19
Experimental Results: BasicSP Scenario• Testbed
• Linux 2.6.20 FC6
• Dual 2.4Mhz processor
• 1.5GB RAM
• Evaluation for larger applications (~150 components) is in progress
20Physical assembly mapping reduces the footprint significantly
Static footprint reduction of ~45%
Dynamic footprint reduction of ~10%
21
Application Specific Optimizations: Unresolved Challenges2.Lack of application context
• Optimization decisions relegated to run-time
• e.g., every invocation performs check for locality
• Settle for near-optimal solutions
• Missed middleware optimization opportunities
22
Application Specific Optimizations: Unresolved Challenges2.Lack of application context
• Optimization decisions relegated to run-time
• e.g., every invocation performs check for locality
• Settle for near-optimal solutions
• Missed middleware optimization opportunities
• e.g., allocation of RT-CORBA thread pools and lanes
• Large overhead compared to collocated calls
Cannot be solved efficiently at middleware level alone!
Invocation within the same pool/lane (12µs)
Invocation to a different pool/lane (150µs)
Solution Approach: Use Application Context from Models• Use application structure &
context available in models• Create fast path within
middleware for physical assemblies
• Cross-pool/lane proxy
23
Solution Approach: Use Application Context from Models• Use application structure &
context available in models• Create fast path within
middleware for physical assemblies
• Cross-pool/lane proxy• Utilize available fast path in PAM
• e.g., Use matching real-time policies as additional constraint when creating physical assemblies
24
Solution Approach: Use Application Context from Models• Use application structure &
context available in models• Create fast path within
middleware for physical assemblies
• Cross-pool/lane proxy• Utilize available fast path in PAM
• e.g., Use matching real-time policies as additional constraint when creating physical assemblies
• Configure middleware resources efficiently
• e.g., allocate physical assemblies with matching policies in the same thread pool or thread pool with lanes
25
26
Context-driven Optimization Evaluation Criteria • Improve performance
• t = no. of cross-pool/lane interactions between components within an assembly
• Transform t remote calls to t cross-pool/lane calls
• Eliminate mis-optimizations• Check incompatible POA
policies• Incompatible invocation
semantics (oneway or twoway)
• No changes to individual component implementations• Eliminate need for a local
vs. remote version
• Customizable & application transparent
Experimental Results: Cross pool/lane proxy
27
Standard deviation <= 3µs
Max latency improved by ~50%
99% latency improved by 60-66%
Average latency improved by 60 – 66%
Significant performance benefits with cross pool/lane proxy!
28
Summary of Research ContributionsCategory Benefits
System Optimization Technologies
• Novel mechanism for mapping an assembly as a component to both reduce application footprint and increase performance
• Automatic discovery & realization of optimizations from models in an application transparent fashion
• Performs optimizations that are impossible to perform if operating at the middleware layer alone
• Optimized allocation & configuration of middleware resources using application context derived from models
QoS Mapping Context
29
• Benefits of QoS-enabled middleware technologies
• Raise the level of abstraction
• Support many quality of service (QoS) configuration knobs
Container
COMPONENTEXECUTORS
ComponentHome
POA
CallbackInterfaces
I nt e
r na
lIn
terf
ac e
s
Eve
ntS
inks
Face
t s
Rec
ep
t acl
esE
ven
tS
ou
r ce
s
ComponentReference
Co
mp
on
en
t C
on
t ex
t
COMPONENT SERVER 1
Container
COMPONENTEXECUTORS
ComponentHome
POA
CallbackInterfaces
I nte
r na
lI n
t erf
ace
s
Ev
ent
Sin
ksF
ace
t s
Re
ce
pt a
cle
sE
v en
tS
ou
rce
s
ComponentReference
Co
mp o
nen
t C
on
t ex
t
COMPONENT SERVER 2
ORB
End-to-End PriorityPropagation
Portable PrioritiesProtocol Properties
Priority Band
Publisher(Subscriber) multi-threaded
access
Event Filtering
Event Dispatching
QoS Mapping Context
30
Container
COMPONENTEXECUTORS
ComponentHome
POA
CallbackInterfaces
I nte
r na
lI n
t erf
ace
s
Ev
ent
Sin
ksF
ace
t s
Re
ce
pt a
cle
sE
v en
tS
ou
rce
s
ComponentReference
Co
mp o
nen
t C
on
t ex
t
COMPONENT SERVER
Drawbacks of QoS-enabled middleware technologiesAchieving desired QoS increasingly a system QoS configuration problem, not just
an initial system functional design problem
• Benefits of QoS-enabled middleware technologies
• Raise the level of abstraction
• Support many quality of service (QoS) configuration knobs
Lack of effective QoS configuration tools result in QoS policy mis-configurartions that are hard to analyze & debug
ORB
Example Application: Satellite Mission• Satellite mission consists of four
identically instrumented spacecraft & a ground control system
• Collect mission data
• Send it to ground control at appropriate time instances
31
Example Application: Satellite Mission• Satellite mission QoS requirements span
two dimensions
• Multiple modes of operation
• Varying importance of data collection activity of satellite sensors based on mission phase
• Need to translate QoS policies into QoS configuration options & resolve QoS dependencies
32
Slow Survey
Fast Survey
Burst
Challenge 1: Translating QoS Policies to QoS Options
33
Prioritized service invocations (QoS Policy) must be mapped to Real-time CORBA Banded Connection (QoS configuration)
• Large gap between application QoS policies & middleware QoS configuration options• Bridging this gap is necessary to realize the desired QoS policies
• The mapping between application-specific QoS policies & middleware-specific QoS configuration options is non-trivial, particular for large systems
Policy for handling of dangling(ill-behaved) publishers(subscribers) (QoS Policy) must be mapped to control policy and control period (QoS configuration)
Challenge 1: Translating QoS Policies to QoS Options
34
• Conventional mapping approach requires deep understanding of the middleware configuration space
• e.g., multiple types/levels of QoS policies require configuring appropriate number of thread pools, threadpool lanes (server) & banded connections (client)
ProtocolProperties
Explicit Binding
Client Propagation & Server Declared Priority Models
Portable Priorities
Thread Pools
Static Scheduling Service
StandardSynchonizers
Request Buffering
Challenge 2: Choosing Appropriate QoS Option Values
35
Individually configuring component QoS options is tedious & error-prone
e.g., ~10 distinct QoS options per component & ~140 total QoS options for entire satellite mission
Manually choosing valid values for QoS options does not scale as size & complexity of applications increase
Challenge 3: Validating QoS Options
36
Each QoS option value chosen should be validated
e.g., Filter priority model is CLIENT_PROPAGATED, whereas Comm priority model is SERVER_DECLARED
Each system reconfiguration (at design time) should be validated
e.g., reconfiguration of bands of Analysis should be validated such that the modified value corresponds to (some) lane priority of the Comm
Challenge 4: Resolving QoS Option Dependencies
• “QoS option dependency” is defined as:
• Dependency between QoS options of different components
• Manually tracking dependencies is hard – or in some cases infeasible
• Dependent components may belong to more than one assembly
• Dependency may span beyond immediate neighbors
–e.g., dependency between Gizmo & Comm components
• Empirically validating configuration changes by hand is tedious, error-prone, & slows down development & QA process considerably
• Several iterations before desired QoS is achieved (if at all)
37
ThreadPool priorities of Comm should match priority bands defined at Gizmo
38
Solution Approach: Model-Driven QoS Mapping• QUality of service
pICKER (QUICKER)• Model-driven
engineering (MDE) tools model application QoS policies
• Provides automatic mapping of QoS policies to QoS configuration options
• Validates the generated QoS options
Automated QoS mapping & validation tools can be used iteratively throughout the development process
Enhanced Platform Independent Component Modeling Language (PICML), a DSML for modeling component-based applications
QoS mapping uses Graph Rewriting & Transformation (GReAT) model transformation tool
Customized Bogor model-checker used to define new types & primitives to validate QoS options
39
QUICKER Enabling MDE Technologies
Enhanced Platform Independent Component Modeling Language (PICML), a DSML for modeling component-based applications
QoS mapping uses Graph Rewriting & Transformation (GReAT) model transformation tool
Customized Bogor model-checker used to define new types & primitives to validate QoS options
40
QUICKER Enabling MDE Technologies
CQML Model interpreter generates Bogor Input Representation (BIR) of DRE system from its CQML model
CQML Model Interpreter
Bogor Input Representation
Resolving Challenge 1: Translating Policies to Options (1/2)
46
Expressing QoS policies
PICML modes application-level QoS policies at high-level of abstraction
e.g., multiple service levels support for Comm component, service execution at varying priority for Analysis component, prioritizing event dispatching at Analysis component
Reduces modeling effort
e.g., ~25 QoS policy elements for satellite mission vs. ~140 QoS options
Resolving Challenge 1: Translating Policies to Options (2/2)• Mapping QoS policies to
QoS options
• GReAT model transformations automate the tedious & error-prone translation process
• Transformations generate QoS configuration options as CQML models
• Allow further transformation by other tools
• e.g., code optimizers & generators
• Simplifies application development & enhances traceability
47
Resolving Challenges 2 & 3: Ensuring QoS Option Validity• CQML model
interpreter generates BIR specification from CQML models
• BIR primitives used to check whether a given set of QoS options satisfies a system property
• e.g., fixed priority service execution, a property of Comm component
• Supports iterative validation of QoS options during QoS configuration process
48
QUICKER
Resolving Challenge 4: Resolving QoS Option Dependencies
• Change(s) in QoS options of dependent component(s) triggers detection of potential mismatches• e.g., dependency between Gizmo invocation priority & Comm lane priority
49
Dependency structure maintained in Bogor used to track dependencies between QoS options of components, e.g.:
Analysis & Comm are connected
Gizmo & Comm are dependent
Detect mismatch if either values change
Dependency Structure of Satellite Mission Components
Summary of Research Contributions
• QUICKER provides Model-Driven Engineering (MDE) for QoS-enabled component middleware
• Maps application-level QoS policies to middleware-specific QoS configuration options
• Model transformations automatically generate QoS options
• Model-checking extensions ensure validity of QoS options at component- & application-level
50