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

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

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

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

5. F-15 product variant A/V 8-B product variant F/A 18 product variant UCAV product variant Product-line architecture Hardware (CPU, Memory, I/O) OS & Network Protocols Customized Middleware Motivation 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 Air Frame AP Nav HUDGPS IFF FLIR 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] James Coplien et al. Commonality & Variability in Software Engineering, IEEE Software 1998 Applying SCV to Bold Stroke –Scope: Bold Stroke component architecture, object-oriented framework, & associated components, e.g., GPS, Airframe, & Display OS & Network Protocols Host Infrastructure Middleware Distribution Middleware Common Middleware Services Domain-specific Services Air Frame AP Nav HUDGPS IFF FLIR Reusable Architecture Framework Reusable Application Components

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 Hardware (CPU, Memory, I/O) OS & Network Protocols Host Infrastructure Middleware Distribution Middleware Common Middleware Services Domain-specific Services

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 Hardware (CPU, Memory, I/O) OS & Network Protocols Host Infrastructure Middleware Distribution Middleware Common Middleware Services Domain-specific Services

10. Mature PLA Development Process Component Repository Comp Deployment Platforms 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 www.dre.vanderbilt.edu/ACE Examples of QoS variabilities OS priorities, which differ on Sun, VxWorks, Windows, Linux/RT- Linux Diverse locks & IPC mechanisms

12. 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 Middleware Layers for PLAs

13. 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) www.dre.vanderbilt.edu/CIAO Middleware Layers for PLAs

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 Customized Middleware StackStandards-based, General-purpose, Layered Middleware Architecture Product-line Variant Specificity  PLAs are driven by the functional & QoS requirements for each product variant Research Challenges

16. Research Challenges Addressed in OPTEML Asynchrony 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 Binding Time Applicability General Specific Run-time Design-time 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 Prior research has focused on a continuum of optimizations

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

20. Related Research 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, PLoP 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

21. General-purpose Optimizations: What is Missing? Need to determine right hooks 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. Solution: Configuration-driven Optimizations –How to systematically determine what optimizations are ideal for a particular deployment & product variant

22. Configuration-driven Optimizations Applicability General Specific Binding Time Run-time Design-time Hook for the concurrency strategy Hook for marshaling strategy Hook for the connection management strategy Hook for the underlying transport strategy Hook for the event demuxing strategy Configuration-driven optimizations tune compiler/middleware/web- server configuration knobs to maximize application QoS for a particular use case 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

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? 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 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 Solution: Partial Specialization Optimizations

25. Partial Specialization Optimizations Applicability General Specific Binding Time Run-time Design-time 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

26. Related Research CategoryRelated 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 Asynchrony 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 Asynchrony Synchronous

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 –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 properties[ICDCS04] along critical path My ContributionsPublications 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. 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 Problem –Configuration-driven optimizations describe the “ends” (mapping requirements to parameters) Ad hoc Techniques for Configuration Evaluation/Validation

38. 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? BGML Challenge Resolution Provide modeling constructs to depict one-way/two-way invocation semantics Modeling construct to depict events Interpreters generate platform specific code Eliminate accidental complexities in understanding IDL- C++ mapping Two way synchronous communication One-way synchronous/ asynchronous (void) this->remote_ref_-> AcceptWorkOrderResponse (arg0, arg1);

42. BGML Tool Features Challenge 2 : How to capture different PLA QoS characteristics BGML Challenge Resolution Provide modeling constructs to capture latency/throughput and jitter QoS 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_-> AcceptWorkOrderResponse (arg0, arg1); ACE_CHECK; ACE_hrtime_t now = ACE_OS::gethrtime (); history.sample (now - start); } Latency between a  b < x msecs Throughput should be more than y calls/sec

43. BGML Tool Features Challenge 3 : How to capture PLA workloads, e.g., rate-based? 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_Workload task0 (this->remote_ref_, arg0_, arg1_, barrier); AcceptWorkOrderResponse_Workload task1 (this->remote_ref_, arg0_, arg1_, barrier); AcceptWorkOrderResponse_Workload task2 (this->remote_ref_, arg0_, arg1_, barrier); Operations at 20Hz/sec Operations at 40 Hz/sec

44. CoSMIC Tool Suite Challenge 5: How to model & generate middleware configurations settings for PLA variants? Documentation Pane Option selection BGML integrated with the Options Configuration Modeling Language (OCML)

45. CoSMIC Tool Suite Challenge 6: How generate deployment information? BGML integrated with Platform Independent Component Modeling Language Virtual nodes Mapping 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 –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 Process Steps –Use MDD process to generate artifacts

48. Research Contributions ContributionsPublications 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 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]

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 ACE_wrappers/TAO/CIAO/DaNCE/examples/BasicSPCoSMIC/examples/BasicSP Representative DRE application: “rate based” Events  Control information Operation  simple data

53. Gleaning Scenario Invariants Periodic Timer: Sends same data repeatedly Single method interfaces: Sends same operation on wire A specific Reactor used Protocol: A specific protocol used 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)

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

55. Pre-create Request Specialize Request Creation The trigger messages sent by the Timeouts do not have any data nor change across requests 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 Request Header Creation Creation of the header is costly!

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 Select Reactor select () Reactor_Impl select () WFMO_Reactor select () Thread_Pool Reactor select ()

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->process_request (); final_layer->process_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->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

61. FOCUS: Transformations Rule Selection Customization Engine: Transforms annotations Work in Progress GUI to infer rule- selection Source-to-Source Transformations Compiler Developing Customization engine

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 Fine-grain Componentization Tools for Configuration Validation May 2003 Nov 2004 Nov 2005 Application- Specific optimizations Policy-driven approaches for middleware MDD Techniques, BGML Skoll 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 FOCUS, Specialization Patterns

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

66. 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 –General-purpose optimizations, that enable customization of middleware for different product-variants Research focus can be categorized hierarchically:

67. Concluding Remarks –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 Research focus can be categorized hierarchically: 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

68. Concluding Remarks –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 Research focus can be categorized hierarchically: 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

69. Summary of Research Contributions AreaContributions 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 ContributionsMy Publications & Acceptance rates Fine-grain Componentization of Middleware Architecture 1.Book Chapter: Middleware for Communications, Wiley, NY, 2004 2.International Conference on Distributed Systems (ICDCS) 2004 (17%) 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 AuthorSecond AuthorThird Author

71. Questions?