An ArchitectureCentric Methodology for Ensuring QualityofService in LargeScale Distributed Systems

1
An Architecture-Centric Methodology for Ensuring
Quality-of-Service in Large-Scale Distributed
Systems

• George Edwards
• gedwards_at_usc.edu
• Computer Science Department
• University of Southern California

2
Presentation Outline

• Background and Motivation
• Modeling Languages
• Component and Analysis Technologies
• Model-Driven Engineering
• The eXtensible Toolchain for Evaluation of
  Architectural Models (XTEAM)
• Extensible Modeling Environment
• Model Interpreter Frameworks
• Conclusions

3
Approaches to Software and System Modeling

• Use standardized languages that are widely used
  throughout the software and systems engineering
  community
• The Unified Modeling Language (UML) and
  accompanying Model-Driven Architecture (MDA) is
  the foremost example of this approach
• Widespread success and industrial adoption
• Use domain-specific languages that are customized
  for a particular RD program
• Tools like the Generic Modeling Environment (GME)
  implement this approach
• Emerging approach with less (but growing)
  industrial adoption
• Has been termed Model-Integrated Computing (MIC)
  and more recently, Model-Driven Engineering (MDE)
• Focus of todays lecture

4
Standardized Languages

• Advantages
• Provide a common vocabulary for engineers to
  exchange ideas and designs
• Extensive tool support is available
• Most engineers may already be familiar with the
  language less training needed
• Disadvantages
• Design by committee
• Usually not the most effective way to
  capture/express domain concepts

5
Domain-SpecificModeling Languages (DSMLs)

• Advantages
• Express domain concepts in the most
  straightforward, intuitive way
• Can be customized for the needs of each RD
  program
• Can be easily modified, evolved, composed, etc.
• Disadvantages
• Constructing good languages is difficult and may
  represent a significant investment of resources
• Language change and evolution may negatively
  impact a development project
• Engineers may need to be trained to use the
  language correctly

6
Architecture Description Languages

• Capabilities
• Capture crucial design decisions
• Can be leveraged throughout the software
  development process
• Shortcomings
• Rely on rigid formalisms
• Focus on structural elements
• Lack support for domain-specific extensibility

Chart is taken from Medvidovic et al., A
Classification and Comparison Framework for
Software Architecture Description Languages
7
Component Technologies

• Component technologies provide the basis for
  modeling, implementation, and deployment of
  software architectures
• A component model defines the well-formedness of
  component instances/assemblies
• A development platform/run-time environment
  enforces the component model
• Examples include Java EE, CORBA Component Model
  and the .NET Framework

Java EE Component Model (informal)
8
Analysis Technologies

• Analysis technologies enable the prediction of
  the non-functional properties of software systems
• An analysis technique defines a process for
  applying a computational theory to system models
• Analysis techniques rely on specific assumptions
  about the systems to which they are applied
• Prediction of the non-functional properties of
  component-based architectures requires the
  integration of component technologies and
  analysis technologies

Layered Queuing Network (LQN) Analysis Model
(informal)
9
Model-Driven Engineering

• Model-driven engineering (MDE) combines
  domain-specific modeling languages with model
  analyzers, transformers, and generators
• Models are the central engineering artifacts
  throughout the engineering lifecycle
• Domain concepts are codified as first-class
  modeling elements
• Model transformations allow a single system model
  to be used for a variety of purposes

Metamodels define elements, relationships, views,
and constraints Model interpreters leverage
domain-specific models for analysis, generation,
and transformation
10
Model Interpreters

• Custom-built components that utilize the model to
  perform some function
• Access an API provided by the modeling
  environment
• Analysis and simulation
• Analyze the behavior and properties of a system
  model
• Generate a simulation of the system
• Model transformation
• Convert domain-specific models to UML
• Translate models between different DSMLs
• System synthesis, configuration, and deployment
• Program generators
• Model-Driven Middleware (MDM)

11
Model Interpreter Frameworks

• Problem Using the standard MDE process, a model
  interpreter must be constructed for each analysis
  that will be applied to a design model
• Requires system architects and developers to
  become tool developers rather than merely tool
  users to achieve integrated design analysis
• Organizations want to develop with third-party,
  commercially-supported tools to reduce risk and
  cost
• Solution Use a model interpreter framework to
  implement architectural analyses
• Allows tasks to be performed only once for a
  broad family of analysis techniques
• Provides built-in analysis capabilities along
  with metamodeling and domain specific
  extensibility

• Model Interpreter Implementation Tasks
• Find a computational theory that derives the
  relevant properties
• Determine the syntax and semantics of
  theanalysis modeling constructs
• Discover the semantic relationships betweenthe
  constructs present in the architecturalmodels
  and those present in the analysismodels
• Determine the compatibility between
  theassumptions and constraints of the
  architecturalmodels and the analysis models, and
  resolveconflicts
• Implement a model interpreter that executes
  asequence of operations to transform
  anarchitectural model into an analysis model
• Verify the correctness of the transformation

12
Model Interpreter Frameworks

• An infrastructure for constructing a family of
  model interpreters
• Implement a semantic mapping between a component
  model and an analysis model

• Provide extension mechanisms to accommodate
  domain-specific modeling and analysis
• Enable a family of analytic techniques to be
  applied to a component model
• Can be reused by a software architect to rapidly
  construct analysis models from domain-specific
  architectures

13
MIFs Assumptions

• System models contain domain-independent elements
  that are sufficient to implement an
  interpretation
• The interpretation of domain-independent elements
  is not dependent on the interpretation of
  domain-specific elements
• Domain-specific constraints do not violate
  domain-independent constraints

14
MIFs Requirements

• The model interpreter framework abstracts the
  details of domain-independent interpretation
• The model interpreter framework produces an
  artifact useful in a wide variety of contexts
• The model interpreter framework provides
  extension mechanisms sufficient to accommodate
  domain-specific interpretation

15
Project Goals

• Provide an extensible infrastructure to aid
  software architects
• provide design rationale
• Using a peer-to-peer architectural style for
  System X will result in greater scalability.
• weigh architectural trade-offs
• Increasing the reliability of Service Y will
  incur an increase in latency.
• evaluate off-the-shelf component assemblies
• The set of components selected will meet system
  energy consumption requirements.
• test and validate systems incrementally
• The prototype of Component Z is not behaving as
  expected.

16
The eXtensible Toolchain for Evaluation of
Architectural Models (XTEAM)

• A modeling environment and analysis framework for
  software architectures
• Targeted towards highly resource-constrained and
  mobile computing environments
• Implements a model-driven engineering (MDE)
  approach to software architecture
• Consists of a suite of architecture description
  language (ADL) extensions and model
  transformation engines
• Generates system simulations that provide a
  dynamic, scenario- and risk-driven view of the
  executing system
• Provides the extensibility to easily accommodate
  both new modeling language features and new
  architectural analyses

17
High-Level Approach
18
The XTEAM Tool-chain

• XTEAM employs a metaprogrammable graphical
  modeling environment (GME)
• XTEAM composes existing general-purpose ADLs
  xADL Core (structures and types) and FSP
  (behavior)
• GME configures a domain-specific modeling
  environment with the XTEAM ADL
• Architecture models that conform to the XTEAM ADL
  are created
• XTEAM implements a model interpreter framework
• The XTEAM ADL is enhanced to capture
  domain-specific information
• The XTEAM Model Interpreter Framework is utilized
  to implement simulation generators
• Application simulations execute in the adevs
  discrete event simulation engine
• Simulations operate on the information captured
  in ADL extensions to perform scenario-driven
  analysis

19
Extensible Modeling Environment

• Key Challenges
• Development of ADLs is inherently difficult
• Combining extensibility with formal semantics
• Solution Codify ADLs as metamodels
• ADL composition enables the combination of
  constructs from multiple ADLs within a single
  model
• ADL enhancement allows the definition of new,
  customized ADL constructs

Reuse of existing ADLs maximizes the potential
for reuse of the tool infrastructure. Incremental
language extensions enable a specific
architectural analysis technique.
20
The XTEAM Model Interpreter Framework

• Implements a mapping from the XTEAM
  domain-independent component model to a discrete
  event simulation model
• Employs the Strategy pattern to enable an
  architect to implement domain-specific extensions
• Each Concrete Strategy generates code to realize
  a particular analytic theory

• Invoked at specific times during the
  interpretation process
• Generated code calculates and records analysis
  results
• Invoked when a component sends or receives data,
  calls an interface, starts or completes a task,
  etc.

21
Scenario-Driven Dynamic Analysis

• Allows the architect to rapidly investigate the
  consequences of design decisions in terms of
  their impact on non-functional properties
• Results depend heavily on the environmental
  context (e.g., the load put on the system)
• May contain elements of randomness and
  unpredictability (e.g., the timing of client
  requests)
• The set of scenarios to be simulated should
  include high-risk situations and boundary
  conditions

22
Example Energy Consumption Estimation

• A computational energy cost is incurred when a
  components interfaces are invoked
• Interfaces are classified and parameterized
  according to energy consumption profile
• A communication energy cost is incurred when data
  is transmitted over a wireless network
• Depends on data size, network bandwidth, etc.

23
Evaluation

• Evaluated using the MIDAS system, a family of
  sensor network applications
• Runs on Prism-MW, a lightweight architectural
  middleware platform
• Two candidate architectures were analyzed
  client-server and publish-subscribe
• XTEAM was used to determine the most energy
  efficient architectural style
• Predictions of system properties made by XTEAM
  were compared with measured values taken from the
  executing system

Client-server architecture
Publish-subscribe architecture
24
Verification

• The predicted energy consumption fell within 10
  of the measured energy consumption in all
  scenarios
• The pub-sub style was more energy-efficient
• Requires fewer events to be sent over the
  wireless network
• The energy overhead due to processing
  subscription requests and retrieving subscriber
  lists is small
• The margin of error was sufficiently small that
  it led to the correct choice of architectural
  style

25
Project Goals

• Provide an extensible infrastructure to aid
  software architects
• provide design rationale
• Using a peer-to-peer architectural style for
  System X will result in greater scalability.
• weigh architectural trade-offs
• Increasing the reliability of Service Y will
  incur an increase in latency.
• evaluate off-the-shelf component assemblies
• The set of components selected will meet system
  energy consumption requirements.
• test and validate systems incrementally
• The prototype of Component Z is not behaving as
  expected.

26
Providing Design Rationale
Client-Server Architecture

• Architects rely on intuition and experience to
  make important decisions early in the design
  phase
• What architectural style to use
• How to allocate functionality among subsystems
• What types of connectors to use
• XTEAM allows architects to rationalize such
  decisions with experimental evidence
• Model confidence level Low

Peer-to-peer Architecture
Potential Workload
Comparison of latency ? P2P achieves greater
scalability
27
Weighing Architectural Trade-offs

• Nearly all architectural decisions come down to
  trade-offs between multiple desirable properties
• Emphasis on one system property may yield
  diminishing returns
• XTEAM allows architects to evaluate design
  alternatives in terms of their impact on multiple
  non-functional properties
• Model confidence level Medium

Decreases response time
Replication of components
Consumes more battery power
28
Evaluating Component Assemblies

• Contemporary large-scale distributed systems
  contain numerous off-the-shelf components
• Detailed information about the behaviors and
  properties of individual components may be known
• Component assemblies may exhibit unforeseen
  behavior due to subtle interactions between
  constituent components
• XTEAM allows an architect to determine the
  emergent properties of a composed system
• Model confidence level High

Determination of emergent properties
Off-the-shelf components
Highly accurate parameterization
29
Incremental System Validation

• Individual component implementations may become
  available in a piecemeal fashion
• XTEAM allows architects to
• Immediately incorporate component implementations
  into a simulated system, increasing the accuracy
  of analysis results
• Rapidly test individual components in the context
  of a wide variety of operational scenarios
• Model confidence level High

Component implementation available
Invoke implementation from behavior model
Integrated simulation and test environment
30
Proposed XTEAM MIFs