model-driven engineering of component systems
Post on 31-Dec-2015
34 Views
Preview:
DESCRIPTION
TRANSCRIPT
Model-Driven Engineering Of Component Systems
Vanderbilt University Nashville, Tennessee
Institute for Software Integrated Systems
Krishnakumar BalasubramanianJames Hill
Dr. Douglas C. Schmidt{kitty,
hillj,jules,schmidt}@dre.vanderbilt.edu
2
Presentation Roadmap• Research Challenges
• Software System Analysis • Component System Integration • Component System Optimization
• Demonstration Section • Scenario• Question• Capability Demo• Enabling Technology
• Concluding Remarks• December Demo• Benefits & Roadmap
3
Model-Driven Engineering Technologies
Component configurator(4
) con
figur
es
CoSMIC
packagingas
sem
bly
specification
configuration
plan
ning
feedback
Component Developer
Component
ResourceRequirements
Impl
Impl
Impl
Properties
(1) d
evel
ops
Component Assembler
Component Assembly
Component Component
Component Component
(2) assembles
Component Package
Component Assembly
Component Component
Component Component
Component Assembly
Component Component
Component Component
Component packager
(3) packages
Component deployer
(5) deployment planningAssembly
DeploymentApplication
Assembly
Assembly
(7) feedback to
configuration &
planning
Analysis & Benchmarking
systemanalyzer
(6) analysis & benchmarking
System Optimization Technologies
System Analysis
Technologies
System Integration
Technologies
4
SLICE System Scenario (1/2)
SLICE application string consists of: 2 sensors 2 planners that process data from the
sensors Configuration component responsible
for converting planner output into configuration input for effectors
Effectors that perform action based on configuration parameters
sensor 2
sensor 1(main)
planner 1 planner 2
configuration
error recovery
effector 2
effector 1(main)
5
SLICE System Scenario (2/2)
Deployment & Performance Requirements
• Critical path deadline is 350 ms• main sensor to main effector
through configuration • Components in the critical path must
be deployed across multiple hosts• Main sensor & effector must be
deployed on separate hosts
• Three hosts• One database is shared between
all hosts
sensor 2
sensor 1(main)
planner 1 planner 2
configuration
error recovery
effector 2
effector 1(main)
6
Software System Analysis Challenge: Serialized Phasing
Application components
developed after infrastructure is
mature
Development Timeline
Level of
Ab
stra
ctio
n
System infrastructur
e components developed
first
7
Software System Analysis Challenge: Serialized Phasing
Development Timeline
Level of
Ab
stra
ctio
n
Integration Surprises!!!
System integration & testing
Finished development
8
Software System Analysis Challenge: Serialized Phasing
Development Timeline
Level of
Ab
stra
ctio
n
Still in development
Ready for testingComplexities• System infrastructure cannot be
tested adequately until applications are done
9
Software System Analysis Challenge: Serialized Phasing
Development Timeline
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
10
Software System Analysis Challenge: Serialized Phasing
Meet QoS requirements?
Key QoS concerns• Which deployment configurations
meet the QoS requirements?
Development Timeline
Level of
Ab
stra
ctio
n
11
Software System Analysis Challenge: Serialized Phasing
Performance metrics?
Key QoS concerns• Which deployment configurations
meet the QoS requirements? • What is the worse/average/best
time for various workloads?
Development Timeline
Level of
Ab
stra
ctio
n
12
Software System Analysis Challenge: Serialized Phasing
It is hard to address these concerns in processes that use serialized phasing
Key QoS concerns• Which deployment configurations
meet the QoS requirements? • What is the worst/average/best time
for various workloads?• How much workload can the
system handle until its QoS requirements are compromised?
System overload?
Development Timeline
Level of
Ab
stra
ctio
n
13
Software System Analysis in 10 Years
EnsureDesign
Conformance
ValidateDesignRules
Conduct “What If”Analysis
Validate Design Rules
• System will adhere to system design specifications
• “Correct-by-construction”
Ensure Design Conformance
• System will be deployed & configured to conform to system design rules
Conduct “What If” Analysis
• QoS concerns can be analyzed prior to completing the entire system
• e.g., before system integration phase
The cycle is repeated when developing application & infrastructure components
14
Software System Analysis in 3 Years
•Develop MDE tools which allow emulation of real components on target infrastructure
•Develop analysis tools to evaluate & verify QoS performance
•Develop framework to allow instrumentation of “real” components
•Develop framework for intermixing of emulation components with “real” component
ValidateDesignRules
Enable testing on target infrastructure early in development lifecycle
Component Workload Emulator (CoWorker) Utilization Test Suite Workflow (CUTS):
ValidateDesign
Conformance
Conduct“What If”Analysis
15
Software System Analysis 2006 Demos
• August• Model-Driven Software System Analysis Tools• Automated generation of emulation components
• December• Develop CoWorkEr emulation framework in multiple SOA
technologies• Microsoft .NET web services• J2EE web service
• Integration of CBML & WML into other MDD tools• GEMS
16
How can system engineers analyze the performance of an application on the actual deployment
environment before the development of application components is complete?
Software System Analysis Motivating Question?
17
Enabling Technology: Model-Driven Software System Analysis
• The Component Behavior Modeling Language (CBML) & Workload Modeling Language (WML) is used to define the behavior of CoWorkEr components in a PICML model
• CoWorkEr implementation is generated on top of a component framework that contains a benchmarking aspect
Emulation Framework
18
Component System Integration• System refers to software systems built
using• Service-Oriented Architecture (SOA)
technologies like Web Services• Component middleware technologies
like Enterprise Java Beans (EJB), CORBA Component Model (CCM)
• Integration can be done at multiple levels• Process Integration• Functional Integration• Data integration• Presentation Integration• Portal Integration
• System Integration refers to functional integration done via
• Distributed Object Integration• Service-Oriented Integration
QoSProperties
Checksum
Version Dependencies
List of FilesQoS Specs ComponentInterconnections
ImplementationDLL DLL
QoSProperties
Checksum
Version Dependencies
ImplementationDLL DLL
19
Component System Integration: Unresolved Challenges• Component middleware is getting a lot
more declarative• Management of diverse metadata
& configuration of middleware is proving to be error-prone
• Current practice attempts integration in a manual fashion
• Inappropriate level of abstraction• Integrators need to learn enough of
every technology• Lack of automated tools limits
scalability of integration• Total system performance determined
by “Quality-of-Integration” (QoI)• QoI refers to the effect of the
integration on the functional & QoS properties of the integrated system
• Along with “Quality-of-Implementation”
<assemblyImpl>
<instance xmi:id="ScaleQosket">
<name>ScaleQosket</name>
<package href="ScaleQosket.cpd"/>
</instance>
<instance xmi:id="LocalResourceManagerComponent">
<name>LocalResourceManagerComponent</name>
<package href="LocalResourceManagerComponent.cpd"/>
</instance>...<connection>
<name>incoming_image_outgoing_image_Evt</name>
<internalEndpoint>
<portName>outgoing_image_Evt</portName>
<instance xmi:idref="LocalReceiver"/>
</internalEndpoint>
<internalEndpoint>
<portName>incoming_image_Evt</portName>
<instance xmi:idref="MultiReceiver"/>
</internalEndpoint>
</connection>
</assemblyImpl>
OS KERNEL
OS I/O Subsystem
Network Interfaces
OS KERNEL
OS I/O Subsystem
Network Interfaces
MIDDLEWARE
ComponentComponent
<assemblyImpl>
<instance xmi:id="ScaleQosket">
<name>ScaleQosket</name>
<package href="ScaleQosket.cpd"/>
</instance>
<instance xmi:id="LocalResourceManagerComponent">
<name>LocalResourceManagerComponent</name>
<package href="LocalResourceManagerComponent.cpd"/>
</instance>...<connection>
<name>incoming_image_outgoing_image_Evt</name>
<internalEndpoint>
<portName>outgoing_image_Evt</portName>
<instance xmi:idref="LocalReceiver"/>
</internalEndpoint>
<internalEndpoint>
<portName>incoming_image_Evt</portName>
<instance xmi:idref="MultiReceiver"/>
</internalEndpoint>
</connection>
</assemblyImpl>
<assemblyImpl>
<instance xmi:id="ScaleQosket">
<name>ScaleQosket</name>
<package href="ScaleQosket.cpd"/>
</instance>
<instance xmi:id="LocalResourceManagerComponent">
<name>LocalResourceManagerComponent</name>
<package href="LocalResourceManagerComponent.cpd"/>
</instance>...<connection>
<name>incoming_image_outgoing_image_Evt</name>
<internalEndpoint>
<portName>outgoing_image_Evt</portName>
<instance xmi:idref="LocalReceiver"/>
</internalEndpoint>
<internalEndpoint>
<portName>incoming_image_Evt</portName>
<instance xmi:idref="MultiReceiver"/>
</internalEndpoint>
</connection>
</assemblyImpl>
<assemblyImpl>
<instance xmi:id="ScaleQosket">
<name>ScaleQosket</name>
<package href="ScaleQosket.cpd"/>
</instance>
<instance xmi:id="LocalResourceManagerComponent">
<name>LocalResourceManagerComponent</name>
<package href="LocalResourceManagerComponent.cpd"/>
</instance>...<connection>
<name>incoming_image_outgoing_image_Evt</name>
<internalEndpoint>
<portName>outgoing_image_Evt</portName>
<instance xmi:idref="LocalReceiver"/>
</internalEndpoint>
<internalEndpoint>
<portName>incoming_image_Evt</portName>
<instance xmi:idref="MultiReceiver"/>
</internalEndpoint>
</connection>
</assemblyImpl>
XML
XMLXML
XML
20
Component System Integration: Unresolved Challenges• Lack of tool support for key integration
activities• Needed to scale up the integration &
deployment process• Relieve the system integrator from
ever-changing platform-specific details aka “accidental complexities”
• Unable to define constraints at the whole system level
• Needed to evaluate service-level agreements before integration
• Check system consistency before & after integration
• Lack of infrastructure to apply system level optimizations
• Needed to automate and optimize the generated glue-code
• (Re-)Target emerging & new middleware technologies
QoSProperties
Checksum
Version Dependencies
List of FilesQoS Specs ComponentInterconnections
ImplementationDLL DLL
QoSProperties
Checksum
Version Dependencies
ImplementationDLL DLL
21
Component System Integration in 10 Years
Tools to integrate “systems-in-the-large”
• Provide abstractions for expressing system level design intent
• Automation of key system integration activities
• Generation of integration glue-code
• Generation of middleware & deployment metadata
• Integrated system satisfies Service Level Agreements (SLAs)
• De-emphasize programming-in-the-small
• No more whack-a-mole approach to system integration
• No more violation of Don’t Repeat Yourself (DRY) principle
22
Component System Integration in 3 Years•Develop tools to allow functional integration of two sample COTS technologies
•CCM•Web Services
•Express & evaluate service level agreements between applications built using
•CCM•Web Services
•Enable integrators to evaluate QoI using different
• Integration topologies, e.g., Message Bus, Point-to-Point, Broker (Indirect/Direct), Publish/Subscribe
• Integration architectures, e.g., Java Business Integration (JBI), Service Component Architecture (SCA), Windows Communication Foundation (WCF)
System Integration Modeling Language (SIML)
PICML (CCM DSML)
WSML (WS DSML)
CCM Deployment descriptors
Web Service Deployment descriptors
23
Component System Integration 2006 Demos• August
• Use CCM & Web Service as sample technologies to be integrated
• Show automatic generation of Web Service implementation from model
• December• To be defined in discussion with LMCO STI personnel
24
Component System Integration Motivating Questions?
1. How do you integrate systems that were not designed to work together?
2. How do you predict the effects of system integration before the actual integration?
3. How do you automate key system integration activities?
25
Demonstration Scenario
Web Service Client
CCM Client
Benchmark_Data_Collector Web Service
TypeSpecific IIOP ó SOAP
SOAP Server
CCMClient
26
Enabling Technology: Model-Driven System Integration• Model-based approach to system
integration• Develop System Integration
Modeling Language (SIML), a DSML for system integration
• Hierarchical composition of DSMLs• Composed from multiple sub-DSMLs
• PICML CCM • WSML Web Services• Each sub-DSML is used as a
model library• Built in a re-usable & extensible
fashion • “Open-Closed” principle• New languages can be added;
existing ones reused• Preserve existing investment
• Tools for sub-DSMLs work seamlessly in composite DSML
System Integration Modeling Language (SIML)
PICML (CCM DSML)
WSML (WS DSML)
CCM Deployment descriptors
Web Service Deployment descriptors
27
Enabling Technology: Usage Scenarios• SIML consists of DSMLs for each
technology being integrated• Targets system developers &
integrators• System Developers
• Use DSML of corresponding technology
• Assists in automating key deployment activities
• Used during development of individual sub-systems
• System Integrators• Use the integration DSML • Assists in combining sub-
systems together• Used during integration testing
of the whole system
System Integration Modeling Language (SIML)
PICML (CCM DSML)
WSML (WS DSML)
CCM Deployment descriptors
Web Service Deployment descriptors
28
Control Center SystemResource
Manager
ScaleQosket
CropQosket
Compress Qosket
LocalResourceManager
Cropping QoSPredictorScaling QoS
Predictor
Compression QoSPredictor
Image Feeds (.NET Web
Service)
Component System Optimization• 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
29
Control Center Display
SystemResourceManager
LocalResourceManager
Sender ReceiverCrop
Qosket
Compress Qosket
Scale Qosket
Compression QoS Predictor
Scaling QoS Predictor
Cropping QoS Predictor
Stream 4
Stream 3
Stream 2
Stream 1
Component System Optimizations: Unresolved Challenges1.Lack of application
context• Missed middleware
optimization opportunities
• E.g., every invocation performs check for locality
• Optimization decisions relegated to run-time
• Impossible for middleware (alone) to predict application usage
• Settle for near-optimal solutions
Cannot be solved efficiently at middleware level alone!
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
30
Control Center Display
SystemResourceManager
LocalResourceManager
Sender ReceiverCrop
Qosket
Compress Qosket
Scale Qosket
Compression QoS Predictor
Scaling QoS Predictor
Cropping QoS Predictor
Stream 4
Stream 3
Stream 2
Stream 1
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
2.Overhead of platform mappings
• Blind adherence to platform semantics
• Inefficient middleware glue code generation per component
• Example: Every component is created using a Factory Object
• Overhead of external components similar to internal ones
3.Standard component models define only virtual assemblies
Component System Optimizations: Unresolved Challenges
31
Component System Optimization in 10 Years• Generate application
specific components for a product-line architecture
• Optimize middleware in an application-specific fashion
• Improve performance
• Reduce static & dynamic footprint
• Eliminate mis-optimizations
• No changes to individual component implementations
• Customizable & completely application transparent
CH CH
CHCH
CH CH
CHCH
CH CH
CHCH
CH CH
CHCH
Assembly Optimizer
Factory
CHCH
CH
CH
CH
CH CHCH
32
Control Center Display
SystemResourceManager
LocalResourceManager
Sender ReceiverCrop
Qosket
Compress Qosket
Scale Qosket
Compression QoS Predictor
Scaling QoS Predictor
Cropping QoS Predictor
Stream 4
Stream 3
Stream 2
Stream 1
Node Application
Container
Factory
CHCH
CH
CH
CH
CH
Receptacle
Facet
Event Sink
Event Source
Component Home
Component Assembly
Component Remote Invocation
Optimized Invocation
Creates
CHCHCH
Component System Optimization in 3 Years• Identify sources of overhead in
large-scale component-based system of systems
• Develop component assembly optimizer which eliminates these sources of overhead
• Use CORBA Component Model as a test bed
• Apply optimization technology to a variety of scenarios
• PCES Emergency Response System (30+ components)
• ARMS GateTest scenarios (100+ components)
• Scenarios with & without inherent hierarchy
33
Component System Optimization Motivating Question?
How do you custom optimize individual component implementations based on the
global system composition properties & usage scenario without requiring any changes to the
component implementation?
34
Component System Optimization: December Demo• Baseline for comparison
• Performance & footprint (with vanilla CIAO)
• Emergency Response System (30+ components)
• ARMS GateTest scenarios (100+ components)
• Scenario with & without inherent hierarchy
• Reduce static & dynamic footprint
• n = no. of internal components, x = total no. of components in the assembly
• Reduce from n factories to 1 factory
CH CH
CHCH
CH CH
CHCH
CH CH
CHCH
CH CH
CHCH
Assembly Optimizer
Factory
CHCH
CH
CH
CH
CH CHCH
35
Component System Optimization: December Demo• Improve performance
• t = no. of interactions between components within an assembly
• Transform t collocation checked calls to t unchecked 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• Investigate feasibility of applying
optimizations to Web Services (in addition to CCM)
36
Concluding Remarks• Our research focuses on Model-driven Engineering (MDE) solutions
• Software System Analysis Tools (CUTS/PICML/WSML)
• Benefits
• Reduces complexities with serialized phasing in large-scale systems
• Automates generation of distributed emulation infrastructure
• Component System Integration Tools (SIML)
• Benefits
• Provides infrastructure to evaluate service level agreements
• Automates generation of integration glue-code
• Component System Optimization Tools (PICML/WSML)
• Benefits
• Perform optimizations on a “system-of-systems” scale
Tools can be downloaded from www.dre.vanderbilt.edu/CoSMIC/
37
Enabling Technology: Component Assembly Optimizer• Component Assembly Optimizer
• Uses system models as input• Combines
• Information about the system-as-a-whole as well as individual components from the model
• Catalog of (feature, perf. overhead),(feature,dependent features) & (feature, incompatible features) tuples of the underlying middleware technology
• To optimize globally, i.e., across the whole “system-of-systems”, the
• Generated middleware glue code• Configuration of underlying
middleware• Generated deployment metadata
CH CH
CHCH
CH CH
CHCH
CH CH
CHCH
CH CH
CHCH
Assembly Optimizer
Factory
CHCH
CH
CH
CH
CH CHCH
38
Target Scenarios• “System of Systems” with
portions exhibiting• Hierarchy• No hierarchy
• Built using COTS component/SOA technologies
• Web Services• CCM• EJB
• Specific deployment scenario• Information about
• Composition structure of systems/component assemblies
• Desired QoS policies• Target deployment
domain
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
39
Solution Approach: Physical Assembly Mapping3.Devise mapping for physical
component assembly
• Exploit hierarchy of application structure to fuse (make a component internal) at multiple levels in hierarchy
• Experimentally validate right depth of hierarchy to stop fusion
• Too deep – Single giant blob
• Too shallow – Potentially lower benefits
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
Assembly Optimizer
40
Component System Optimization: What’s missing?• Lack of high-level notation to
guide optimization frameworks
• Missing AST of application
N N N N
N
N
N
N
NN
Application Abstract Syntax Tree
41
• Lack of high-level notation to guide optimization frameworks
• Missing AST of application
• Emphasis on detection at run-time (reflection)
• Additional overhead in the fast path
• Not suitable for all systems
• Not completely application transparent
• Requires providing multiple implementations
• Optimization performed either
• Too early, or too late
Control Center SystemResource
Manager
ScaleQosket
CropQosket
Compress Qosket
LocalResourceManager
Cropping QoSPredictorScaling QoS
Predictor
Compression QoSPredictor
Image Feeds (.NET Web
Service)
Component System Optimization: What’s missing?
42
Steps Involved in Integration Using SIML1.Generate a CCM DSML model
from the IDL definition of application components
2.Generate a WSDL file from the IDL of the component(s) to be exposed as Web Service(s)
3.Import the CCM model into integration DSML; define connections between CCM components to assemble application
4.Generate a WSDL DSML model from generated WSDL
5.Import the Web Service model into integration DSML
Integration DSML
CORBA Component
Model DSML
Web Services DSML
CCM Deployment descriptors
Web Service Deployment descriptors
CORBA Component Application
IDL 2 WSDL Generator
1
IDL 2 PICML Generator
WSDL Importer
Web Service Client
Web Service Client
Web Service Client
TypeSpecific IIOP ó SOAP
SOAP Server
CCMClient
CCM Component
2
3
4
5
8
97
6
43
Steps Involved in Integration Using SIML6.Annotate the WSDL model to
specify deployment information like WSDL port bindings (host name, host port number, URI including namespace of service et al.
7.Generate CCM deployment descriptors
8.Generate the type-specific proxies, i.e., integration glue-code
9.Generate Web Service deployment descriptors including updated WSDL, web container hosting artifacts
Integration DSML
CORBA Component
Model DSML
Web Services DSML
CCM Deployment descriptors
Web Service Deployment descriptors
CORBA Component Application
IDL 2 WSDL Generator
1
IDL 2 PICML Generator
WSDL Importer
Web Service Client
Web Service Client
Web Service Client
TypeSpecific IIOP ó SOAP
SOAP Server
CCMClient
CCM Component
2
3
4
5
8
97
6
44
SIML Benefits• Develop integration DSML in a
modular & extensible fashion• Model-library based approach• Allows re-use of existing
platform DSMLs• New platforms can be added
easily
Integration DSML
CORBA Component
Model DSML
Web Services DSML
CCM Deployment descriptors
Web Service Deployment descriptors
Web Service Client
Web Service Client
Web Service Client
Generic IIOP ó SOAP
SOAP Server
CCMClient
CCM Component
Web Service Client
Web Service Client
Web Service Client
TypeSpecific IIOP ó SOAP
SOAP Server
CCMClient
CCM Component
top related