OPTEML Optimization Techniques for Enhancing Middleware Quality of

OPTEML: Optimization Techniques for Enhancing Middleware Quality of Service for Product-line Architectures http: //www. dre. vanderbilt. edu/~arvindk/proposal. pdf Arvind S. Krishna arvindk@dre. 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 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 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 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 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 Proposed Research Middleware Specialization Techniques Dissertation Timeline Concluding Remarks

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 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 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 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 • 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 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 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 Proposed Work Middleware Specialization Techniques Dissertation Timeline Concluding Remarks

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

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 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 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 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 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 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. “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 – 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 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, “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 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 Proposed Work Middleware Specialization Techniques Dissertation Timeline Concluding Remarks

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

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 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 & 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 • 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) 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 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 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. , 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 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 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 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 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 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 Proposed Work Middleware Specialization Techniques Dissertation Timeline Concluding Remarks

Challenge #3: Middleware Specialization challenges

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 & 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 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 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 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 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 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 • 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 – 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 (); 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 Rule Selection Customization Engine: Transforms annotations Source-to-Source Transformations Compiler

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 Proposed Work Middleware Specialization Techniques Dissertation Timeline Concluding Remarks

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 Proposed Work Middleware Specialization Techniques Dissertation Timeline Concluding Remarks

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