Model-Driven Engineering Of Component Systems

1
Model-Driven Engineering Of Component Systems
Krishnakumar Balasubramanian James Hill Dr.
Douglas C. Schmidt kitty, hillj,jules,schmidt_at_dr
e.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
System Integration Technologies
System Optimization Technologies
System Analysis 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

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

6
Software System Analysis Challenge Serialized
Phasing
System infrastructure components developed first
Application components developed after
infrastructure is mature
7
Software System Analysis Challenge Serialized
Phasing
Finished development
System integration testing
Integration Surprises!!!
8
Software System Analysis Challenge Serialized
Phasing
Still in development
Ready for testing

• Complexities
• System infrastructure cannot be tested adequately
  until applications are done

9
Software System Analysis Challenge Serialized
Phasing
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?

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?

12
Software System Analysis Challenge Serialized
Phasing
System overload?

• 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?

It is hard to address these concerns in processes
that use serialized phasing
13
Software System Analysis in 10 Years

• 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
Component Workload Emulator (CoWorker)
Utilization Test Suite Workflow (CUTS)

• 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

Enable testing on target infrastructure early in
development lifecycle
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
Software System Analysis Motivating Question?

• How can system engineers analyze the performance
  of an application on the actual deployment
  environment before the development of application
  components is complete?

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

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

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

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

21
Component System Integration in 10 Years

• 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 Dont Repeat Yourself (DRY)
  principle

Tools to integrate systems-in-the-large
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)

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

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

28
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
Component System Optimizations Unresolved
Challenges

• 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!
30
Component System Optimizations Unresolved
Challenges

• 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
• Standard component models define only virtual
  assemblies

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

32
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

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.ed
u/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,dep
  endent 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

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

39
Solution Approach Physical Assembly Mapping

• 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

40
Component System Optimization Whats missing?

• Lack of high-level notation to guide optimization
  frameworks
• Missing AST of application

41
Component System Optimization Whats missing?

• 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

42
Steps Involved in Integration Using SIML

1. 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

43
Steps Involved in Integration Using SIML

1. Annotate the WSDL model to specify deployment
   information like WSDL port bindings (host name,
   host port number, URI including namespace of
   service et al.
2. Generate CCM deployment descriptors
3. Generate the type-specific proxies, i.e.,
   integration glue-code
4. Generate Web Service deployment descriptors
   including updated WSDL, web container hosting
   artifacts

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