OPTEML: Optimization Techniques for Enhancing Middleware Quality of Service for Product-line Architectures - PowerPoint PPT Presentation

About This Presentation
Title:

OPTEML: Optimization Techniques for Enhancing Middleware Quality of Service for Product-line Architectures

Description:

Arvind S. Krishna. arvindk_at_dre.vanderbilt.edu. Institute for Software ... Krishna et al. 'Empirical Evaluation of CORBA Component Model Implementations' ... – PowerPoint PPT presentation

Number of Views:73
Avg rating:3.0/5.0
Slides: 72
Provided by: dreVand
Category:

less

Transcript and Presenter's Notes

Title: OPTEML: Optimization Techniques for Enhancing Middleware Quality of Service for Product-line Architectures


1
OPTEML Optimization Techniques for Enhancing
Middleware Quality of Service for Product-line
Architectures
http//www.dre.vanderbilt.edu/arvindk/proposal.pd
f
Arvind S. Krishna arvindk_at_dre.vanderbilt.edu Inst
itute for Software Integrated Systems Vanderbilt
University Nashville, Tennessee
2
Motivation
Air Frame
FLIR
FLIR
GPS
GPS
  • Legacy distributed real-time embedded (DRE)
    systems have historically been
  • Stovepiped
  • Proprietary
  • Brittle non-adaptive
  • Expensive
  • Vulnerable

3
Motivation
Air Frame
FLIR
AP
HUD
GPS
Nav
IFF
Domain-specific Services
Common Middleware Services
  • Middleware factors out many reusable
    general-purpose domain-specific services from
    traditional DRE application responsibility
  • Essential for product-line architectures (PLAs)

4
Motivation
Air Frame
FLIR
AP
HUD
GPS
Nav
IFF
Domain-specific Services
Common Middleware Services
  • Middleware factors out many reusable
    general-purpose domain-specific services from
    traditional DRE application responsibility
  • Essential for product-line architectures (PLAs)
  • However, standards-based, general-purpose,
    layered middleware is not yet adequate for the
    most demanding mission-critical PLA based DRE
    systems

5
Motivation
Air Frame
FLIR
AP
HUD
GPS
Nav
IFF
  • Middleware factors out many reusable
    general-purpose domain-specific services from
    traditional DRE application responsibility
  • Essential for product-line architectures (PLAs)
  • However, standards-based, general-purpose, layers
    middleware is not yet adequate for the most
    demanding mission-critical PLA based DRE
    systems

My research optimizes middleware for PLA-based
DRE systems
6
Presentation Road Map
  • Technology Context
  • Research Challenges
  • Related Research
  • Research Progress
  • Proposed Research ? Middleware Specialization
    Techniques
  • Dissertation Timeline
  • Concluding Remarks

7
Overview of Product-line Architectures (PLAs)
  • PLA Characteristics Scope Commonalities
    Variabilities (SCV)
  • SCV analysis is a process that can be applied to
    identify commonalities variabilities in a
    domain to guide development of a PLA Coplien
  • Applying SCV to Bold Stroke
  • Scope Bold Stroke component architecture,
    object-oriented framework, associated
    components, e.g., GPS, Airframe, Display

Reusable Application Components
Reusable Architecture Framework
Air Frame
FLIR
AP
HUD
GPS
Nav
IFF
James Coplien et al. Commonality Variability in
Software Engineering, IEEE Software 1998
8
Overview of PLAs
  • Applying SCV to Bold Stroke
  • Commonalities describe the attributes that are
    common across all members of the family
  • Common object-oriented framework set of
    components
  • e.g., GPS, Airframe, Navigation Display
    components
  • Common middleware infrastructure
  • e.g., Real-time CORBA a variant of Lightweight
    CORBA Component Model (CCM) called Prism

9
Overview of PLAs
  • Applying SCV to Bold Stroke
  • Variabilities describe the attributes unique to
    the different members of the family
  • Product-dependent component implementations
    (GPS/INS)
  • Product-dependent component connections
  • Product-dependent components (Different weapons
    systems for security concerns)
  • Different hardware, OS, network/bus
    configurations

10
Mature PLA Development Process
  • PLAs define a framework of components that adhere
    to a common architectural style
  • Model driven development (MDD) domain-specific
    modeling languages (DSMLs) are used to
  • Glue components together
  • Synthesize artifacts for deployment onto
    platforms, e.g., J2EE, .NET, CORBA

11
Middleware Layers for PLAs
  • Middleware Evolution
  • Middleware supports application requirements in
    different domains
  • Often exhibits a standards-based,
    general-purpose, layered architecture
  • Host infrastructure middleware encapsulates
    native OS mechanisms to create reusable network
    programming components
  • Example ACE toolkit JVMs
  • Examples of QoS variabilities
  • OS priorities, which differ on Sun, VxWorks,
    Windows, Linux/RT-Linux
  • Diverse locks IPC mechanisms

12
Middleware Layers for PLAs
  • Distribution middleware defines higher-level
    distributed programming models whose reusable
    APIs components automate extend native OS
    capabilities
  • Avoids hard-coding dependencies on OS, languages,
    location
  • Examples Real-time CORBA, COM, Distributed
    Real-time Java, Java RMI,

www.dre.vanderbilt.edu/TAO
  • Examples of QoS variabilities
  • Round-trip timeouts, protocol properties,
    (de)marshaling strategies, concurrency models
  • of threads, stack sizes

13
Middleware Layers for PLAs
  • Component middleware is a class of middleware
    that enables reusable services to be composed,
    configured, installed to create applications
    rapidly robustly
  • Components encapsulate application business
    logic
  • Containers provide execution environment for
    components
  • Interact with underlying middleware to leverage
    middleware services, such as events,
    fault-tolerance etc
  • Examples of QoS variabilities
  • Type of containers (e.g., real-time, transient,
    persistent)
  • Services QoS properties (e.g., event channel vs.
    direct dispatch)

14
Presentation Road Map
  • Technology Context
  • Research Challenges
  • Related Research
  • Research Progress
  • Proposed Work ? Middleware Specialization
    Techniques
  • Dissertation Timeline
  • Concluding Remarks

15
Overview of Research Challenges
  • Resolving the tension between
  • Generality ? Middleware is designed to be
    independent of particular application
    requirements
  • Specificity ? PLAs are driven by the functional
    QoS requirements for each product variant

Product-line Variant
Customized Middleware Stack
Standards-based, General-purpose, Layered
Middleware Architecture
16
Research Challenges Addressed in OPTEML
Middleware fine-grain componentization challenges
Configuration evaluation validation challenges
Specialization challenges
17
Presentation Road Map
  • Technology Context
  • Research Challenges
  • Related Research
  • Research Progress
  • Proposed Work ? Middleware Specialization
    Techniques
  • Dissertation Timeline
  • Concluding Remarks

18
Taxonomy of Research Continuum
  • Optimization dimensions
  • Applicability ? General-purpose to more
    application-specific
  • A general-purpose optimization can be applied
    across all PLA variants, while application-specifi
    c targets a particular variant
  • Binding time ? Run-time to design-time
  • Determines when the optimizations are bound,
    i.e., run-time ? system execution, design-time ?
    system development

Design-time
Binding Time
Prior research has focused on a continuum of
optimizations
Run-time
General
Specific
Applicability
19
General-purpose Optimizations
  • General-purpose optimizations are broadly
    applicable algorithmic data-structural
    optimizations within the middleware/OS/protocols
    to improve QoS

Design-Time
  • Applicability ? Can be used for a range of
    applications across different domains
  • Binding time ? Design-time run-time

Binding Time
Run-time
General
Specific
Applicability
20
Related Research
Research Category Related Research
Request Processing Optimizations Pyarali et al., Applying Optimization Patterns to the design of Real-time ORBs, 5th COOTS Conference, 1999 Wang et al. Collocation Optimizations, IEEE Distributed Systems, 2001
Demultiplexing Threading optimizations Feldmeier, Multiplexing Issues in Communications System Design, ACM SIGCOMM, 1996 Hutchinson et al. The Design of the x-kernel, ACM SIGCOMM, 1998
Patterns for Connection Management Schmidt, Acceptor Connector Design Patterns for Actively Passively Initializing Network Services, Euro PLOP Conference, 1997
Patterns for Request Processing Pyarali et al., Asynchronous Completion Token An Object Behavioral Pattern of Efficient Request Processing, PLoP Conference, 1999
Protocol Processing Related Optimizations ORyan et al., Design of a Pluggable Protocol Framework, Middleware 2000 OMalley et al. USC A Universal Stub Generator, SIGCOMM 94
Schmidt et al., Pattern Oriented Software
Architecture 2, Addison Wesley
http//www.dre.vanderbilt.edu/arvindk/proposal.pd
f
21
General-purpose Optimizations What is Missing?
  • Unresolved challenges
  • Different product-lines achieve different
    benefits/liabilities from enabling/disabling
    different optimizations
  • e.g. type of ORB reactor, type of queue, type of
    connection management strategy etc.
  • How to systematically determine what
    optimizations are ideal for a particular
    deployment product variant

Need to determine right hooks
Solution Configuration-driven Optimizations
22
Configuration-driven Optimizations
Configuration-driven optimizations tune
compiler/middleware/web-server configuration
knobs to maximize application QoS for a
particular use case
Hook for the concurrency strategy
Hook for the event demuxing strategy
Design-time
Hook for marshaling strategy
  • Applicability ? Technique is broadly applicable,
    but a particular configuration may be specific to
    a particular application use case
  • Binding time ? Typically bound at system
    initialization-time

Binding Time
Hook for the connection management strategy
Hook for the underlying transport strategy
Run-time
General
Specific
Applicability
23
Related Research
Research Category Related Research
Functional Correctness of Software Configurations Memon et al. Distributed Continuous Quality Assurance, ICSE 2004, Edinburgh, Scotland Yilmaz et al. Covering Arrays for Efficient Fault Characterization in Complex Configuration Spaces, ISSTA, 2004
Continuous Monitoring Childers et al. Continuous Compilation A New Approach to Aggressive Adaptive Code Transform, IPDPS 2003, Next-generation software workshop
Generative Programming Techniques Rutherford et al. A Case for Test-Code Generation in Model-driven Systems, GPCE 2003, Erfurt Germany
Compiler Technology Yotov et al. A Comparison of Empirical Model Driven Optimizations, PLDI 2003
Web-service Configuration importance estimation Sophiktomol et al. A Method for Evaluating the Impact of Software Configuration Parameter on E-Commerce Sites, Workshop on Software Performance, 2005
24
Configuration-driven Optimization What is
Missing?
  • Unresolved challenges
  • These optimizations cannot eliminate middleware
    generality
  • Overhead from specification compliance, redundant
    checks, indirection
  • e.g., benchmarking efforts revealed that even
    with most optimal configuration, indirection
    overheads are costly
  • How to optimize the request processing path to
    improve performance

http//www.atl.external.lmco.com/projects/QoS/
  • Krishna et al. CCMPerf A benchmarking tool for
    CORBA Component Model Implementations, RTAS
    2004, Toronto Canada
  • Krishna et al. Empirical Evaluation of CORBA
    Component Model Implementations, Springer-Verlag
    Journal on Real-time Systems, March 2005

Solution Partial Specialization Optimizations
25
Partial Specialization Optimizations
Partial Specialization optimizations customize
programming-languages/middleware according to
system invariants known ahead-of-time
Applicability ? Optimizations are highly
context-specific Binding time ? Optimizations
are generally applied at design-time
Design-time
Binding Time
Run-time
General
Specific
Applicability
26
Related Research
Category Related Research
Automatic language mechanisms T. Mogensen A. Bondorf, Logimix A Self-Applicable Partial Evaluator for Prolog, Program Evaluation Program Specialization conference (PEPM), 1993 S.M. Abramov, A Compiler Based on Partial Evaluation, Problems of Applied Mathematics Software Systems, Moscow State University Press,
Manual language mechanisms Kiczales, An Overview of AspectJ, Lecture Notes in Computer Science, 1999 Lohmann et al. Generative Programming with Aspect C, GPCE 2004, Vancouver, Canada Todd Veldhuizen Using C meta programs, C Report 1999
Specification level mechanisms Ira Baxter Design Maintenance System, Semantic Designs Inc, Goodman Processor for Multiple Language Application, Promula
Domain Operating Systems Massalin et al. The Synthesis Kernel, Computing Systems Journal, 1998 Pu et al. Optimistic Incremental Specialization Streamlining a Commercial Operating System, SOSP 95
Domain Feature oriented specialization Zhang et al. Towards Just in Time Middleware, Aspect Oriented Software Engineering, (AOSD 2005), Chicago, 2004 Zhang et al. Resolving Feature Convolution in Middleware, ACM SIGPLAN OOPSLA Conference, Vancouver, Canada 2004
27
Partial Specialization What is Missing?
  • Lack of Tool Support
  • Automatic specialization generally restricted to
    declarative languages, such as lambda
  • Little support for OO languages such as C/Java
  • Lack of Middleware approaches
  • Middleware is designed for generality, these
    techniques hold promise when applied to
    middleware
  • No approaches address middleware-related issues
  • Lack of approaches that deal with optimizations
  • AspectJ (Resolving Feature Convolution, Zhang et
    al.) did not focus on improving performance using
    optimizations
  • Aspects are a delivery mechanism, the woven code
    can be suboptimal!
  • Aspects also add run-time overhead (need to link
    to library) create portability issues

Provides no guarantees on woven code
28
Presentation Road Map
  • Technology Context
  • Research Challenges
  • Related Research
  • Research Progress
  • Proposed Work ? Middleware Specialization
    Techniques
  • Dissertation Timeline
  • Concluding Remarks

29
Challenge 1 Fine-grain Componentization
Middleware fine-grain componentization challenges
30
Middleware Feature Componentization Problem
  • Context
  • Each variant in a PLA may require only a subset
    of all the middleware features
  • Research Challenges
  • General-purpose optimizations address performance
    issues, but do not address feature-driven
    componentization
  • Monolithic ORB architectures put all code in one
    executable
  • Conditional compilation allows fine-grained
    componentization but
  • Increases number of configuration settings
  • Hard to maintain add new features

31
Addressing Middleware Customizability Challenges
for PLAs
  • Solution Approach ? Micro ORB Architectures
  • Identify ORB services whose behavior may vary,
    e.g.,
  • Object Adapters, Anys, Protocols, (de)marshaling,
    buffer allocation mechanisms
  • Move these out of the ORB
  • Hypotheses Our approach
  • Enables different levels of customization
  • Is application transparent
  • Significantly reduces footprint
  • Allows easy addition of new features without
    undue performance overheads

32
Addressing PLA Customizability Challenges
  • Solution Approach ? Micro ORB Architectures
  • Identify ORB services whose behavior may vary,
    e.g.,
  • Object Adapters, Anys, Protocols, (de)marshaling
    buffer allocation mechanisms
  • Move these out of the ORB
  • Implement alternatives as pluggable strategies,
    i.e., virtual components VC

VC Corsaro et al. Virtual Component Pattern,
Pattern Language of Programs, Monticello,
Illinois, 2003
33
Addressing PLA Customizability Challenges
  • Solution Approach ? Micro ORB Architectures
  • Identify ORB services whose behavior may vary
  • Object Adapters, Anys, Protocols, (de)marshaling
    buffer allocation mechanisms
  • Move these out of the ORB
  • Implement alternatives as pluggable strategies,
    i.e., virtual components VC
  • Each product variant can then choose what
    component it does or does not require
  • Application Transparent ?
  • No changes to CORBA interfaces
  • No changes to existing implementations

34
Research Contributions
  • Research Contributions
  • Levels of customizability ? coarse-grain vs.
    fine-grain componentization
  • Fine-grain approach break component into multiple
    sub-components
  • Policy driven approaches to fine-grain
    componentization
  • Footprint ? Fine-grain approach has 50 reduction
    compared with monolithic approach DOA 02, 03

  • Cost ?Adding new features for variants
    modularized (e.g., new protocol)
  • Performance ? enables all general
    purpose-optimizations RTAS 03 real-time
    propertiesICDCS04 along critical path

My Contributions Publications
Next Generation Middleware Design Book Chapter Middleware for Communications Wiley Sons, New York, 2004
Real-time Performance Predictability International Conference on Distributed Systems (ICDCS) 2004 Real-time Application Symposium (RTAS) 2003
Pluggable POA Architecture ORB Core Architecture Distributed Objects Applications (DOA) 2002 Distributed Objects Applications (DOA) 2003
35
Challenge 2 Configuration Evaluation
Validation
Configuration evaluation validation challenges
36
Ad hoc Techniques for Configuration Evaluation
Context Each variant in a PLA requires an
appropriate set of middleware configurations to
satisfy QoS properties
37
Ad hoc Techniques for Configuration
Evaluation/Validation
  • Problem
  • Configuration-driven optimizations describe the
    ends (mapping requirements to parameters)
  • However, the means (process for the mapping)
    are tedious, error prone time-consuming for
    middleware
  • e.g., for a simple 5 component scenario requires
    60 files each 100-500 LOC

38
Ad hoc Techniques for Configuration
Evaluation/Validation
  • Problem
  • No systematic process to evaluate validate
    configuration settings across different platforms
  • Configuration Evaluation
  • e.g., how do we ensure the right middleware
    configuration for maximizing QoS for
    product-variants?
  • Configuration Validation
  • e.g., how do we ensure that configuration is
    semantically valid across different deployment
    scenarios?

39
Addressing Ad hoc Techniques for Evaluation
Validation
  • Hypotheses Our approach for different
    Product-variants
  • Eliminates accidental complexity in evaluating
    QoS of middleware configurations
  • Enables validation of middleware configurations
    across diverse platforms
  • Can be applied to identify middleware
    configurations that most influence end-to-end
    performance/latency/jitter (i.e., the main
    effects)
  • Solution Approach Combine MDD Approach
  • Raise the level of abstraction, i.e., think in
    terms of middleware configurations rather than
    lower-level source code
  • Auto-generate information required to run
    evaluate QoS of variants
  • with Quality Assurance Processes
  • Validate generated code across different platforms

40
Build Benchmark Generation DSML
  • BGML
  • Developed a domain specific modeling language
    (DSML) in GME to evaluate middleware
    configurations to maximize application QoS

41
BGML Tool Features
Challenge 1 How to capture different PLA
communication semantics?
One-way synchronous/ asynchronous
  • BGML Challenge Resolution
  • Provide modeling constructs to depict
    one-way/two-way invocation semantics
  • Modeling construct to depict events

Two way synchronous communication
  • Interpreters generate platform specific code
  • Eliminate accidental complexities in
    understanding IDL-C mapping

(void) this-gtremote_ref_-gt
AcceptWorkOrderResponse (arg0, arg1)
42
BGML Tool Features
Challenge 2 How to capture different PLA QoS
characteristics
Latency between a?b lt x msecs
Throughput should be more than y calls/sec
  • BGML Challenge Resolution
  • Provide modeling constructs to capture
    latency/throughput and jitter QoS characteristics

ACE_Sample_History history (5000) for (i 0 i
lt 5000 i) ACE_hrtime_t start
ACE_OSgethrtime () (void)
this-gtremote_ref_-gt AcceptWorkOrderRespo
nse (arg0, arg1) ACE_CHECK
ACE_hrtime_t now ACE_OSgethrtime ()
history.sample (now - start)
  • Automatic translation into code that samples
    data calculates and computes these metrics

43
BGML Tool Features
Challenge 3 How to capture PLA workloads, e.g.,
rate-based?
Operations at 20Hz/sec
Operations at 40 Hz/sec
  • BGML Challenge Resolution
  • Tasks Threads that run at given/rate or
    continuous or are random (interactive load)
  • TaskSet Group tasks into sets having a given
    rate/priority

ACE_Barrier barrier (2) // Generate the
Background workload AcceptWorkOrderResponse_Workl
oadltTgt task0 (this-gtremote_ref_, arg0_, arg1_,
barrier) AcceptWorkOrderResponse_WorkloadltTgt
task1 (this-gtremote_ref_, arg0_, arg1_,
barrier) AcceptWorkOrderResponse_WorkloadltTgt
task2 (this-gtremote_ref_, arg0_, arg1_, barrier)
44
CoSMIC Tool Suite
Challenge 5 How to model generate middleware
configurations settings for PLA variants?
BGML integrated with the Options Configuration
Modeling Language (OCML)
Option selection
Documentation Pane
45
CoSMIC Tool Suite
Challenge 6 How generate deployment information?
BGML integrated with Platform Independent
Component Modeling Language
Mapping
Virtual nodes
  • This MDD process automates ALL code required to
    enact a scenario
  • Deployment Plan XML deployment information
    (PICML)
  • svc.conf Configuration for each component
    implementation (OCML)
  • Benchmark code source code for executing
    benchmarks (BGML)
  • IDL CIDL files (PICML/BGML)
  • Build Files MPC files (www.ociweb.com) (BGML)

46
MDD Quality Assurance Process
  • Evaluating and Validating Middleware
    Configurations
  • Process output integrated with Skoll
    (www.cs.umd.edu/projects/skoll)
  • Skoll QA processes validates configurations
    across different platforms, compilers OS

A Use MDD process explained earlier to capture
PLA QoS concerns B, C Synthesize middleware
configuration, benchmark and deployment
information D Feed test code to Skoll
framework E Run on varied platforms to measure
QoS variations F Maintain database of results
from which patterns of configurations can be
identified
Process time consuming. Do I need to run this
process each time?
47
Main-effects Screening Process
  • Motivation
  • Identify the important configurations settings
    that characterize complete configuration space
  • Process Steps
  • Use MDD process to generate artifacts
  • Enhance Skoll to use a statistical techniques
    (Design of Experiments theory) to estimate
    validate configuration importance
  • e.g., G is most important parameter for the
    scenario followed by H
  • Enables defining a region for required
    performance
  • Penalty for leaving the region X msecs

48
Research Contributions
  • Model-Driven QA processes for configuration
    evaluation validation
  • Enhances Configuration-driven optimization
    techniques by providing a reusable, automated
    process reproducible for different variants
    RTAS05
  • Addresses accidental complexities in
    code-generation ICSR
  • Addresses validation challenges across different
    hosts/configurations IEEE Software
  • Documents configuration main-effects that can
    drive customizations or further validation ICSE
    2005

Contributions Publications
Configuration main effects (MDD Skoll) Real-time Application Symposium (RTAS) 2005 International Conference on Software Engineering (ICSE) 2005
BGML CoSMIC Tool Suite International Conference on Software Reuse (ICSR) Elsevier Science of Computer Programming, International Journal of Embedded Systems (Invited submission)
Distributed Testing Quality Assurance IEEE Software, Studia Infomatica Universalis Journal
49
Presentation Road Map
  • Technology Context
  • Research Challenges
  • Related Research
  • Research Progress
  • Proposed Work ? Middleware Specialization
    Techniques
  • Dissertation Timeline
  • Concluding Remarks

50
Challenge 3 Middleware Specialization
Specialization challenges
51
Where to Specialize?
  • Where do we apply middleware specializations?
  • Research Zhang et al. showed that woven code is
    not always optimal
  • Identification of specialization points within
    the middleware is a key step towards eliminating
    generality
  • Approach
  • Examined critical request response processing
    path
  • Identified documented places of generality
  • Redundant checks lookups along request
    processing path
  • Implemented them as alternatives using a
    hand-crafted approach

Zhang et al. Resolving Feature Convolution in
Middleware, OOPSLA Conference, Vancouver, 2004
52
Bold Stroke PLA Scenario
  • Example System
  • Basic Single Processor (BasicSP) distributed
    real-time embedded (DRE) application scenario
    based on Boeing Bold Stroke
  • Timer Component triggers periodic refresh rates
  • GPS Component generates periodic position
    updates
  • Airframe Component processes input from the GPS
    component feeds to Navigation display
  • Navigation Display displays GPS position
    updates

Representative DRE application rate based
Events ? Control information Operation ? simple
data
ACE_wrappers/TAO/CIAO/DaNCE/examples/BasicSP
CoSMIC/examples/BasicSP
53
Gleaning Scenario Invariants
Single method interfaces Sends same operation on
wire
Periodic Timer Sends same data repeatedly
  • Mapping Ahead of Time (AOT) System Properties to
    Specializations
  • Periodicity ? Pre-create marshaled Request
  • Single Interface Operations ? Specialize Request
    Path
  • Reactor/Protocols ? Plug in right reactors
    (remove indirections)

Protocol A specific protocol used
A specific Reactor used
54
Specialize Request Path
  • Specialize Middleware Paths
  • Create middleware fast paths based on different
    invariants

Normal layered path
  • Request Processing Fast Paths
  • Normal layered path ?Uses general-purpose
    optimization for request lookup
  • Optimized fast path ? Bypasses middleware layers
    to directly perform operation invocation
  • Invariant The same operation is invoked on a
    given connection

Optimized Fast path processing
55
Pre-create Request
  • Specialize Request Creation
  • The trigger messages sent by the Timeouts do not
    have any data nor change across requests
  • Request Header Creation
  • Creation of the header is costly!
  • Pre-create Request
  • Pre-create marshal the request
  • Each time same request is sent to the client
  • Update request ID of the request only
  • Save cost of request construction marshaling

56
Reactor Specialization
  • Reactor Pattern
  • Reactor pattern separates the event detection
    from the demultiplexing
  • Allows a single-thread to do both activities
  • Multiple Reactor implementations need only one!
  • Reactor Specialization
  • Remove indirection, e.g., Reactor_Impl base class
    completely (all virtual methods concrete)
  • No changes to component interface. Does not break
    compatibility
  • Similar Situations
  • Protocol framework ? only one protocol
  • Locking Strategy ? enable/disable

57
Specialization Catalog
  • Client Side Specialization
  • Request Header Caching
  • Pre-creating Requests
  • Marshaling checks
  • Target Location
  • Server Side Specialization
  • Specialize Request Processing
  • Avoid Demarshaling checks
  • ORB Component Specialization
  • Multiple types of Reactor
  • Pluggable protocol framework
  • Specializations implemented using hand-crafted
    techniques
  • What is needed? (1) enable new specializations to
    be added (2) delivery mechanisms for automating
    this process

58
FOCUS Approach Summary
  • Processing Phase
  • Middleware developer
  • Annotates code with specialization points
  • Creates specialization rules (e.g., in a
    database)
  • Creates GUI to infer specialization via
    high-level questions do you need concurrency?
  • Specialization Phase
  • PLA Application developer
  • Uses GUI to choose type of specialization
    required
  • Selection of right specialization rules
  • FOCUS tool Feature-Oriented Customization
    removes the generality by specializing hooks
  • Evolution
  • Add new specializations maintain their
    dependencies

59
FOCUS Specialization Rules
  • Specialization Rules
  • Steps that are needed for systematically
    executing the specializations
  • Transformations (replace) similar to aspects
    (before/after join-points) add dissimilar as no
    join-point to add an advice!

IIOP_Connection_Handler in process_request
() add TAO_ServerRequest request
incoming.get_request () replace
next_layer-gtprocess_request ()
final_layer-gtprocess_request
(request)
  • Work Completed
  • Capturing specialization rules

60
FOCUS Specialization Rules
IIOP_Connection_Handler in process_request
() add TAO_ServerRequest request
incoming.get_request () replace
next_layer-gtprocess_request ()
final_layer-gtprocess_request
(request)
Middleware developers Specify transformations as
rules multiple rules in a database
  • Work in Progress
  • Developing an XML schema for capturing rules
    dependencies
  • Aspects
  • run-time overhead portability issues add advice
    tool-maturity

Middleware developers Annotate source with hooks
61
FOCUS Transformations
  • Work in Progress
  • GUI to infer rule-selection

Rule Selection
  • Developing Customization engine

Customization Engine Transforms annotations
Source-to-Source Transformations
Compiler
62
FOCUS Termination Criteria
  • Termination Criteria (Hypothesis)
  • For a mature PLA scenario, considerable
    performance improvements can be achieved by using
    the FOCUS approach
  • We will use TAO mature real-time ORB as our gold
    standard
  • Greatest benefits will be accrued for scenarios
    that can turn on all/most of the optimizations
  • Performance improvements estimated 30 40
    improvement in performance
  • Turning on just one/two optimizations might
    improve performance by 10 15 improvement

63
Presentation Road Map
  • Technology Context
  • Research Challenges
  • Related Research
  • Research Progress
  • Proposed Work ? Middleware Specialization
    Techniques
  • Dissertation Timeline
  • Concluding Remarks

64
Dissertation Timeline
Policy-driven approaches for middleware
MDD Techniques, BGML Skoll
FOCUS, Specialization Patterns
Fine-grain Componentization
Tools for Configuration Validation
Application- Specific optimizations
May 2003
Nov 2005
Nov 2004
DOA 2002, 2003 RTAS 2003 ICDCS 2004 Middleware
for Communication
ICSR 2004 RTAS 2005, ICSE 2005, IEEE Software,
IJES, Elsevier
RTAS 2004, Springer Real-time Systems Journal
65
Presentation Road Map
  • Technology Context
  • Research Challenges
  • Related Research
  • Research Progress
  • Proposed Work ? Middleware Specialization
    Techniques
  • Dissertation Timeline
  • Concluding Remarks

66
Concluding Remarks
  • This proposal outlined current future trends in
    building customizable middleware for product-line
    architectures
  • It also motivated the need for a continuum of
    optimizations to address enhance application
    QoS
  • Research focus can be categorized hierarchically
  • General-purpose optimizations, that enable
    customization of middleware for different
    product-variants

67
Concluding Remarks
  • This proposal outlined current future trends in
    building customizable middleware for product-line
    architectures
  • It also motivated the need for a continuum of
    optimizations to address enhance application
    QoS
  • Research focus can be categorized hierarchically
  • General-purpose optimizations, that enable
    customization of middleware across different
    product-variants,
  • Configuration-driven optimizations, that enable
    selection of right configurations for different
    variants to maximize QoS

68
Concluding Remarks
  • This proposal outlined current future trends in
    building customizable middleware for product-line
    architectures
  • It also motivated the need for a continuum of
    optimizations to address enhance application
    QoS
  • Research focus can be categorized hierarchically
  • General-purpose optimizations, that enable
    customization of middleware across different
    product-variants,
  • Configuration-driven optimizations, that enables
    selection of right configurations for different
    variants
  • Partial Specialization optimizations, that will
    customize middleware according to application
    invariants

69
Summary of Research Contributions
Area Contributions
General-purpose optimization techniques Patterns techniques for developing fine-grain componentized middleware architectures Policy-driven middleware customization approaches
Configuration-driven optimization techniques Domain-specific modeling language (DSML) to capture QoS evaluation concerns for component middleware PLAs
Partial-specialization optimization techniques FOCUS A tool-driven approach for middleware specialization
Preserving validating middleware configuration properties MDD Distributed Continuous Quality Assurance (DCQA) process for preserving validating middleware configuration properties Main-effects screening, which is a DCQA process for identifying middleware configuration main effects
70
Summary of Publications
Contributions My Publications Acceptance rates
Fine-grain Componentization of Middleware Architecture Book Chapter Middleware for Communications, Wiley, NY, 2004 International Conference on Distributed Systems (ICDCS) 2004 (17) Real-time Application Symposium (RTAS) 2003 (25) Distributed Objects Applications (DOA) 2002 (25) Distributed Objects Applications (DOA) 2003 (30)
Middleware Configuration validation selection International Conference on Software Engineering (ICSE) 2005 (10-15) RTAS 2005 (30 ) International Conference on Software Reuse (ICSR) (22) Elsevier Science of Computer Programming, International Journal of Embedded Systems (Invited submission) IEEE Software Studia Infomatica Universalis Journal
Benchmarking Performance evaluation Real-time Application Symposium (RTAS) 2004 (27) (Selected as Best of RTAS 2004) Springer-Verlag Real-time Systems Journal
First Author
Second Author
Third Author
71
Questions?
Write a Comment
User Comments (0)
About PowerShow.com