Скачать презентацию OPTEML Optimization Techniques for Enhancing Middleware Quality of Скачать презентацию OPTEML Optimization Techniques for Enhancing Middleware Quality of

997f4e9fbffef086e7288d4b824e2a19.ppt

  • Количество слайдов: 71

OPTEML: Optimization Techniques for Enhancing Middleware Quality of Service for Product-line Architectures http: //www. OPTEML: Optimization Techniques for Enhancing Middleware Quality of Service for Product-line Architectures http: //www. dre. vanderbilt. edu/~arvindk/proposal. pdf Arvind S. Krishna [email protected] vanderbilt. edu Institute for Software Integrated Systems Vanderbilt University Nashville, Tennessee

Motivation Nav Air Frame HUD Nav AP FLIR Air Frame GPS IFF AP IFF Motivation Nav Air Frame HUD Nav AP FLIR Air Frame GPS IFF AP IFF Cyclic Exec F-15 Nav HUD Air Frame FLIR Legacy distributed real-time & embedded (DRE) systems have historically been: • Stovepiped • Proprietary • Brittle & non-adaptive • Expensive • Vulnerable FLIR GPS A/V-8 B AP IFF GPS Cyclic Exec F/A-18 Consequence: Small HW/SW changes have big (negative) impact on DRE system Qo. S & maintenance Nav GPS HUD AP FLIR Air Frame Cyclic Exec IFF UCAV

Motivation F/A 18 product variant A/V 8 -B product variant F-15 product variant FLIR Motivation F/A 18 product variant A/V 8 -B product variant F-15 product variant FLIR HUD IFF GPS Air Frame AP UCAV product variant Nav Domain-specific Services Common Middleware Services Distribution Middleware Host Infrastructure Middleware OS & Network Protocols Product-line architecture Hardware (CPU, Memory, I/O) • Middleware factors out many reusable general-purpose & domain-specific services from traditional DRE application responsibility • Essential for product-line architectures (PLAs)

Motivation F/A 18 product variant A/V 8 -B product variant F-15 product variant FLIR Motivation F/A 18 product variant A/V 8 -B product variant F-15 product variant FLIR HUD IFF GPS Air Frame AP UCAV product variant Nav Domain-specific Services Common Middleware Services Distribution Middleware Host Infrastructure Middleware OS & Network Protocols Product-line architecture Hardware (CPU, Memory, I/O) • 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

Motivation F/A 18 product variant A/V 8 -B product variant F-15 product variant FLIR Motivation F/A 18 product variant A/V 8 -B product variant F-15 product variant FLIR HUD GPS Air Frame AP IFF UCAV product variant Nav Customized Middleware OS & Network Protocols Product-line architecture Hardware (CPU, Memory, I/O) • 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

Presentation Road Map n n n n Technology Context Research Challenges Related Research Progress Presentation Road Map n n n n Technology Context Research Challenges Related Research Progress Proposed Research Middleware Specialization Techniques Dissertation Timeline Concluding Remarks

Overview of Product-line Architectures (PLAs) PLA Characteristics: Scope Commonalities & Variabilities (SCV) • SCV 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 FLIR HUD GPS IFF Domain-specific Services James Coplien et al. Commonality & Variability in Software Engineering, IEEE Software 1998 Common Middleware Services Distribution Middleware Host Infrastructure Middleware OS & Network Protocols Air Frame AP Nav

Overview of PLAs Applying SCV to Bold Stroke –Commonalities describe the attributes that are 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 Domain-specific Services Common Middleware Services Distribution Middleware Host Infrastructure Middleware OS & Network Protocols Hardware (CPU, Memory, I/O)

Overview of PLAs Applying SCV to Bold Stroke –Variabilities describe the attributes unique to 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 Domain-specific Services Common Middleware Services Distribution Middleware Host Infrastructure Middleware OS & Network Protocols Hardware (CPU, Memory, I/O)

Mature PLA Development Process Comp Deployment Platforms Comp Comp Comp – Synthesize artifacts for Mature PLA Development Process Comp Deployment Platforms Comp Comp Comp – Synthesize artifacts for deployment onto platforms, e. g. , J 2 EE, . NET, & CORBA Comp • Model driven development (MDD) & domain-specific modeling languages (DSMLs) are used to: – Glue components together Component Repository Comp • PLAs define a framework of components that adhere to a common architectural style

Middleware Layers for PLAs Middleware Evolution • Middleware supports application requirements in different domains 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 www. dre. vanderbilt. edu/ACE Examples of Qo. S variabilities • OS priorities, which differ on Sun, Vx. Works, Windows, Linux/RTLinux • Diverse locks & IPC mechanisms

Middleware Layers for PLAs • Distribution middleware defines higher-level distributed programming models whose reusable 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 Qo. S variabilities • Round-trip timeouts, protocol properties, (de)marshaling strategies, concurrency models • # of threads, stack sizes

Middleware Layers for PLAs • Component middleware is a class of middleware that enables 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 www. dre. vanderbilt. edu/CIAO • Containers provide execution environment for components • Interact with underlying middleware to leverage middleware services, such as events, fault-tolerance etc Examples of Qo. S variabilities • Type of containers (e. g. , realtime, transient, persistent) • Services Qo. S properties (e. g. , event channel vs. direct dispatch)

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

Overview of Research Challenges Resolving the tension between • Generality Middleware is designed to 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 & Qo. S requirements for each product variant Product-line Variant Standards-based, General-purpose, Layered Middleware Architecture Customized Middleware Stack Research Challenges

Research Challenges Addressed in OPTEML Middleware fine-grain componentization challenges Asynchrony Configuration evaluation & validation Research Challenges Addressed in OPTEML Middleware fine-grain componentization challenges Asynchrony Configuration evaluation & validation challenges Specialization challenges

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

Optimization dimensions • Applicability General-purpose to more application-specific • A general-purpose optimization can be Optimization dimensions • Applicability General-purpose to more application-specific • A general-purpose optimization can be applied across all PLA variants, while application-specific 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 Binding Time Design-time Taxonomy of Research Continuum Run-time Prior research has focused on a continuum of optimizations General Specific Applicability

General-purpose Optimizations Design-Time General-purpose optimizations are broadly applicable algorithmic & data-structural optimizations within the General-purpose Optimizations Design-Time General-purpose optimizations are broadly applicable algorithmic & data-structural optimizations within the middleware/OS/protocols to improve Qo. S Run-time Binding Time • Applicability Can be used for a range of applications across different domains • Binding time Design-time & runtime General Applicability Specific

Related Research Category Related Research Request Processing Optimizations • Pyarali et al. , “Applying Related Research Category Related Research Request Processing Optimizations • Pyarali et al. , “Applying Optimization Patterns to the design of Real-time ORBs”, 5 th 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, PLo. P Conference, 1999 Protocol Processing Related Optimizations • O’Ryan et al. , “Design of a Pluggable Protocol Framework”, Middleware 2000 • O’Malley 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. pdf

General-purpose Optimizations: What is Missing? Unresolved challenges – Different product-lines achieve different benefits/liabilities from 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

Configuration-driven Optimizations Hook for the event demuxing strategy Hook for marshaling strategy Run-time Hook Configuration-driven Optimizations Hook for the event demuxing strategy Hook for marshaling strategy Run-time Hook for the connection management strategy Hook for the concurrency strategy • Applicability Technique is broadly applicable, but a particular configuration may be specific to a particular application use case Binding Time Design-time Configuration-driven optimizations tune compiler/middleware/webserver configuration knobs to maximize application Qo. S for a particular use case Hook for the underlying transport strategy General Specific Applicability • Binding time Typically bound at system initialization-time

Related Research Category Related Research Functional Correctness of Software Configurations • Memon et al. Related 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, Nextgeneration 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

Configuration-driven Optimization: What is Missing? Unresolved challenges – These optimizations cannot eliminate middleware generality 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/Qo. S/ • 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

Partial Specialization Optimizations Design-time Partial Specialization optimizations customize programminglanguages/middleware according to system invariants known Partial Specialization Optimizations Design-time Partial Specialization optimizations customize programminglanguages/middleware according to system invariants known aheadof-time Applicability Optimizations are highly context-specific Run-time Binding Time Binding time Optimizations are generally applied at design-time General Applicability Specific

Related Research Category Related Research Automatic language mechanisms • T. Mogensen & A. Bondorf, 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 Aspect. J”, 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

Partial Specialization: What is Missing? Lack of Tool Support – Automatic specialization generally restricted 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 – Aspect. J (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 +

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

Challenge #1: Fine-grain Componentization Middleware fine-grain componentization challenges Asynchrony Challenge #1: Fine-grain Componentization Middleware fine-grain componentization challenges Asynchrony

Middleware Feature Componentization Problem Context Each variant in a PLA may require only a Middleware Feature Componentization Problem Context Each variant in a PLA may require only a subset of all the middleware features Asynchrony 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 Synchronous

Addressing Middleware Customizability Challenges for PLAs Hypotheses: Our approach • Enables different levels of Addressing Middleware Customizability Challenges for PLAs Hypotheses: Our approach • Enables different levels of customization • Is application transparent • Significantly reduces footprint • Allows easy addition of new features without undue performance overheads 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

Addressing PLA Customizability Challenges Solution Approach Micro ORB Architectures • Identify ORB services whose 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] Corsaro et al. “Virtual Component Pattern, ” Pattern Language of Programs”, Monticello, Illinois, 2003

Addressing PLA Customizability Challenges Solution Approach Micro ORB Architectures • Identify ORB services whose 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

Research Contributions – Levels of customizability coarsegrain vs. fine-grain componentization • Fine-grain approach break Research Contributions – Levels of customizability coarsegrain 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 properties[ICDCS 04] 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

Challenge #2: Configuration Evaluation & Validation Configuration evaluation & validation challenges Challenge #2: Configuration Evaluation & Validation Configuration evaluation & validation challenges

Ad hoc Techniques for Configuration Evaluation Context Each variant in a PLA requires an Ad hoc Techniques for Configuration Evaluation Context Each variant in a PLA requires an appropriate set of middleware configurations to satisfy Qo. S properties

Ad hoc Techniques for Configuration Evaluation/Validation Problem – Configuration-driven optimizations describe the “ends” (mapping 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 & timeconsuming for middleware • e. g. , for a simple 5 component scenario requires ~ 60 files each ~ 100 -500 LOC

Problem Ad hoc Techniques for Configuration Evaluation/Validation – No systematic process to evaluate & Problem Ad hoc Techniques for Configuration Evaluation/Validation – 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 Qo. S for product-variants? – Configuration Validation • e. g. , how do we ensure that configuration is semantically valid across different deployment scenarios?

Addressing Ad hoc Techniques for Evaluation & Validation Hypotheses: Our approach for different Product-variants Addressing Ad hoc Techniques for Evaluation & Validation Hypotheses: Our approach for different Product-variants • Eliminates accidental complexity in evaluating Qo. S 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 lowerlevel source code – Auto-generate information required to run & evaluate Qo. S of variants with Quality Assurance Processes – Validate generated code across different platforms

Build & Benchmark Generation DSML BGML • Developed a domain specific modeling language (DSML) Build & Benchmark Generation DSML BGML • Developed a domain specific modeling language (DSML) in GME to evaluate middleware configurations to maximize application Qo. S

BGML Tool Features Challenge 1 : How to capture different PLA communication semantics? One-way BGML Tool Features Challenge 1 : How to capture different PLA communication semantics? One-way BGML Challenge Resolution • Provide modeling constructs to depict one-way/two-way invocation semantics Two way synchronous communication synchronous/ asynchronous • Modeling construct to depict events • Interpreters generate platform specific code • Eliminate accidental complexities in understanding IDLC++ mapping (void) this->remote_ref_-> Accept. Work. Order. Response (arg 0, arg 1);

BGML Tool Features Challenge 2 : How to capture different PLA Qo. S characteristics BGML Tool Features Challenge 2 : How to capture different PLA Qo. S characteristics Latency between a b < x msecs Throughput should be more than y calls/sec BGML Challenge Resolution • Provide modeling constructs to capture latency/throughput and jitter Qo. S characteristics • Automatic translation into code that samples data; calculates and computes these metrics ACE_Sample_History history (5000); for (i = 0; i < 5000; i++) { ACE_hrtime_t start = ACE_OS: : gethrtime (); (void) this->remote_ref_-> Accept. Work. Order. Response (arg 0, arg 1); ACE_CHECK; ACE_hrtime_t now = ACE_OS: : gethrtime (); history. sample (now - start); } }

BGML Tool Features Challenge 3 : How to capture PLA workloads, e. g. , BGML Tool Features Challenge 3 : How to capture PLA workloads, e. g. , rate-based? Operations at 20 Hz/sec Operations at 40 Hz/sec BGML Challenge Resolution • Tasks: Threads that run at given/rate or continuous or are random (interactive load) • Task. Set: Group tasks into sets having a given rate/priority ACE_Barrier barrier (2); // Generate the Background workload Accept. Work. Order. Response_Workload task 0 (this->remote_ref_, arg 0_, arg 1_, barrier); Accept. Work. Order. Response_Workload task 1 (this->remote_ref_, arg 0_, arg 1_, barrier); Accept. Work. Order. Response_Workload task 2 (this->remote_ref_, arg 0_, arg 1_, barrier);

Co. SMIC Tool Suite Challenge 5: How to model & generate middleware configurations settings Co. SMIC 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

Co. SMIC Tool Suite Challenge 6: How generate deployment information? BGML integrated with Platform Co. SMIC Tool Suite Challenge 6: How generate deployment information? BGML integrated with Platform Independent Component Modeling Language ng pi ap M 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)

MDD Quality Assurance Process Evaluating and Validating Middleware Configurations – Process output integrated with 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 Qo. S concerns B, C: Synthesize middleware configuration, benchmark and deployment information D: Feed test code to Skoll framework E: Run on varied platforms to measure Qo. S variations F: Maintain database of results from Process time consuming. which patterns of configurations can Do I need to run this process each be identified time?

Main-effects Screening Process Motivation – Identify the important configurations settings that characterize complete configuration 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

Research Contributions Model-Driven QA processes for configuration evaluation & validation – Enhances Configuration-driven optimization 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 [RTAS 05] – 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 & Co. SMIC 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

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

Challenge #3: Middleware Specialization challenges Challenge #3: Middleware Specialization challenges

Where to Specialize? Where do we apply middleware specializations? – Research [Zhang et al. 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 “handcrafted” approach Zhang et al. “Resolving Feature Convolution in Middleware”, OOPSLA Conference, Vancouver, 2004

Bold Stroke PLA Scenario Example System • Basic Single Processor (Basic. SP) –distributed real-time Bold Stroke PLA Scenario Example System • Basic Single Processor (Basic. SP) –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 Co. SMIC/examples/Basic. SP ACE_wrappers/TAO/CIAO/Da. NCE/examples/Basic. SP

Gleaning Scenario Invariants Periodic Timer: Sends same data repeatedly Protocol: A specific protocol used Gleaning Scenario Invariants Periodic Timer: Sends same data repeatedly Protocol: A specific protocol used Single method interfaces: Sends same operation on wire Mapping Ahead of Time (AOT) System Properties to Specializations • Periodicity Pre-create marshaled Request • Single Interface Operations Specialize Request Path A specific Reactor used • Reactor/Protocols Plug in right reactors (remove indirections)

Specialize Request Path Specialize Middleware Paths • Create middleware fast paths based on different Specialize Request Path Specialize Middleware Paths • Create middleware fast paths based on different invariants 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 Normal layered path Optimized Fast path processing

Pre-create Request Specialize Request Creation • The trigger messages sent by the Timeouts do 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

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

Specialization Catalog Client Side Specialization • Request Header Caching • Pre-creating Requests • Marshaling 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

FOCUS Approach: Summary Processing Phase – Middleware developer • Annotates code with specialization points 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

FOCUS: Specialization Rules – Steps that are needed for systematically executing the specializations – FOCUS: 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_Server. Request &request = incoming. get_request (); replace: next_layer->process_request (); final_layer->process_request (request); Work Completed • Capturing specialization rules

FOCUS: Specialization Rules IIOP_Connection_Handler: in process_request (): add: TAO_Server. Request &request = incoming. get_request FOCUS: Specialization Rules IIOP_Connection_Handler: in process_request (): add: TAO_Server. Request &request = incoming. get_request (); replace: next_layer->process_request (); final_layer->process_request (request); Middleware developers: Annotate source with hooks 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

FOCUS: Transformations Work in Progress • GUI to infer ruleselection • Developing Customization engine FOCUS: Transformations Work in Progress • GUI to infer ruleselection • Developing Customization engine Rule Selection Customization Engine: Transforms annotations Source-to-Source Transformations Compiler

FOCUS: Termination Criteria (Hypothesis) • For a mature PLA scenario, considerable performance improvements can FOCUS: 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

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

Dissertation Timeline Policy-driven approaches for middleware MDD Techniques, BGML Skoll Application. Specific optimizations Tools Dissertation Timeline Policy-driven approaches for middleware MDD Techniques, BGML Skoll Application. Specific optimizations Tools for Configuration Validation Fine-grain Componentization May 2003 DOA {2002, 2003} RTAS 2003 ICDCS 2004 Middleware for Communication FOCUS, Specialization Patterns Nov 2004 ICSR 2004 RTAS 2005, ICSE 2005, IEEE Software, IJES, Elsevier Nov 2005 RTAS 2004, Springer Real-time Systems Journal

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

Concluding Remarks • This proposal outlined current & future trends in building customizable middleware 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 Qo. S • Research focus can be categorized hierarchically: – General-purpose optimizations, that enable customization of middleware for different product-variants

Concluding Remarks • This proposal outlined current & future trends in building customizable middleware 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 Qo. S • 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 Qo. S

Concluding Remarks • This proposal outlined current & future trends in building customizable middleware 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 Qo. S • 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

Summary of Research Contributions Area General-purpose optimization techniques Contributions • Patterns & techniques for Summary of Research Contributions Area General-purpose optimization techniques Contributions • Patterns & techniques for developing fine-grain componentized middleware architectures • Policy-driven middleware customization approaches Configuration • Domain-specific modeling language (DSML) to driven optimization capture Qo. S evaluation concerns for component techniques middleware & PLAs Partialspecialization 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

Summary of Publications Contributions My Publications & Acceptance rates Fine-grain 1. Book Chapter: Middleware Summary of Publications Contributions My Publications & Acceptance rates Fine-grain 1. Book Chapter: Middleware for Communications, Wiley, NY, 2004 Componentization 2. International Conference on Distributed Systems (ICDCS) 2004 of Middleware (17%) Architecture 3. Real-time Application Symposium (RTAS) 2003 (25%) 4. Distributed Objects & Applications (DOA) 2002 (25%) 5. Distributed Objects & Applications (DOA) 2003 (30%) Middleware Configuration validation & selection 6. International Conference on Software Engineering (ICSE) 2005 (10 -15%) 7. RTAS 2005 (30 %) 8. International Conference on Software Reuse (ICSR) (22%) 9. Elsevier Science of Computer Programming, 10. International Journal of Embedded Systems (Invited submission) 11. IEEE Software 12. Studia Infomatica Universalis Journal Benchmarking & Performance evaluation 11. Real-time Application Symposium (RTAS) 2004 (27%) (Selected as Best of RTAS 2004) 12. Springer-Verlag Real-time Systems Journal First Author Second Author Third Author

Questions? Questions?