1 Component Assembly Evaluation Simple C++ expressions Operators ( +, *, f() ) Operands ( x, y, a ) A compiler will optimize the evaluation of the expression Well-known optimizations Component assembly No optimizations performed! Can we do better? Exploit the metadata available at the asssembly level Optimize evaluation of expression void foo () { int x = 1; double y = x + 7; float a = x * y; short c = f(a, y); } short f (float x1, double y) { return x1 * x1 + y * y; }

2 Middleware Services DRE Applications Operating System & Protocols Hardware & Networks DRE Systems: The Challenges Ahead DRE systems extremely sensitive to Limit to how much application functionality can be refactored into reusable COTS middleware Middleware itself has become very hard to use & provision statically & dynamically IntServ + Diffserv RTOS + RT Java RT/DP CORBA + DRTSJ Load Balancer FT CORBA Network latency & bandwidth Workload & Replicas CPU & memory Connections & priority bands RT-CORBA Services RT-CORBA Apps J2ME Services J2ME Apps DRTSJ Services DRTSJ Apps Component-based DRE systems are also very hard to deploy & configure There are many middleware platform technologies to choose from Gigabit Ethernet

3 Where is “Platform-Independence”? Coming soon to an installer near you Refactor existing metamodel to PICML (the new one) Platform-Independence™ Write GReAT transformations Smooth upgrades New capabilities Generate.NET artifacts Component Interfaces Assemblies Assembly manifests Target.NET CLR

4 What about scalability? Scalable modeling requirements Eliminate redundancy Fast UI response time “Less is more” Scalable Features in PICML Hierarchical assemblies If you add a feature, people will use it; often in an unexpected fashion Attribute mapping Initialize attributes at assembly level Coming soon Property mapping Similar to attribute mapping Pre-defined blocks

5 Enforcing Policies on Components Allow transparent injection of policies (add-hook ‘invoke-hook ‘policy) Models as vehicles Capture policies as metadata Single meta-programmable injection framework Instantiated by CIDL compiler Orthogonal evolution of framework & policy

6 Component-based UAV system Challenges (5/5) Automating propagation of changes Typical in DRE systems evolution Currently changes propagated in an ad-hoc fashion Redundant effort Cascading effect Change to a single UAV stream Needs to get propagated to all instances of the stream –1 stream per UAV –n streams in total (n>=50) Difficult to estimate effect of changes

7 Middleware Services DRE Applications Operating System & Protocols Hardware & Networks RT-CORBA Services RT-CORBA Apps J2ME Services J2ME Apps DRTSJ Services DRTSJ Apps Promising Solution: Model Driven Development (MDD) Develop, validate, & standardize generative software technologies that: 1. Model 2. Analyze 3. Synthesize & 4. Provision multiple layers of middleware & application components that require simultaneous control of multiple QoS properties end-to- end Partial specialization is essential for inter-/intra-layer optimization & advanced product-line architectures Goal is to enhance developer productivity & software quality by providing higher-level languages & tools for middleware/application developers & users <…events this component supplies…> <…events this component supplies…> Gigabit Ethernet

8 Concluding Remarks Models can be used as vehicles To automate non-scalable activities To identify & eliminate redundancy To identify & perform optimizations not possible otherwise To specify policy Middleware & associated frameworks (in conjunction with models) To execute on instructions from models To enforce policy

9 Challenge 2: Lack of Tools for Component Composition Once designed, components are implemented, built and packaged into a single run-time artifact Add/remove functionality iteratively Each component participates in a variety of contexts & roles Code for each context & role Always present, or Dynamically loaded using strategies Add up to the time/space overhead of components Lack of tools & abstractions To build, store, retrieve, version components Previous generation middleware abstractions insufficient Maintain multiple lean & mean implementations of application components

10 Challenge 3: Lack of Tools for System Composition Components are developed in isolation Without application context Combined into assemblies to realize functionality Limited composition granularity Restricted to interactions via ports, e.g., elements on a motherboard Separate implementations Source of time/space overhead Lack of tools for fine-grained composition Single implementation with all functionality, e.g. System-On-a- Chip (SOC)

11 Challenge 4: Lack of Optimization Automation Infrastructure Variety of optimizations spanning different stages in lifecycle Application context-driven (Design-time) Platform-driven (Operating System, language) (Development time) Composition-driven (intra-technology, i.e., middleware) (Development/Integration-time) Integration-driven (inter-technology, i.e., all of the above) (Integration-time) Existing tools Can do one or two of the above Never all of the above Perform optimizations on different artifacts Lack common underlying representation Operate at low-level Lack high-level abstraction

12 Challenge 3 Resolved: Exploit semantics of component models Define a meta-language for application composition Operators (port operations) Operands (component ports, components, component assemblies) An Application is an equation (or sentence) in this language Optimize inefficient sentences into efficient ones Define execution equivalence semantics between sentences Theoretically, e.g. using I/OAutomata (needs further investigation) Empirically, e.g. Validate using CUTS Build catalog of equivalent sentences Sentence A is equivalent to sentence B, iff the effect of evaluating A will yield similar externally observable results as evaluating B, in either the same context C, or a context C’ reducible to C E.g., Invoking a method over IIOP vs UIOP Fuse individual component implementations of an assembly Opportunistically & auto-magically when semantics allow such fusion Component Assembly Fusion == System-On-a-Chip

13 Challenge 4 Resolved: Use Models as Integration Carriers Use models as carriers (vehicles) to carry optimization information Similar to request processing in network stacks with zerocopy semantics Request invocation/upcall is done via a single thread context propagated between layers in the networking stack Different optimizations (layer processing) associated on the same model (context) Spans entire life-cycle of component development Design time, Development time, Integration time Share common underlying representation across different stages of life-cycle Exchange integration information with other tools

14 Integration of Heterogeneous Systems Complex Systems are rarely implemented using a single component middleware platform Every system needs some kind of integration Integration with legacy systems Integration with COTS systems Integration with client systems Support for integration with systems is critical to success of component middleware Also is backward compatibility

15 Related Research CategoryRelated Research

16 Challenge 4: Ineffective Tool Support for System Integration Unresolved Challenges Integration of heterogeneous systems are almost always done at middleware level or lower Potential for major disruption at integration time Renders enhanced tool support for other stages of system development meaningless Integration purely at the middleware level is error-prone Need for higher levels of abstraction for integration of systems

17 Presence of models of platforms to be integrated offers a possible solution Significant requirements from modeling infrastructure Support composition of metamodels Support independent evolution of Composition Things being composed Allow load/save of models corresponding to both platforms in the composed metamodel Challenge 4: Ineffective Tool Support for System Integration

18 Proposed Approach: Multi-Platform System Integrator Tool Enhance modeling infrastructure to support seamless composition of metamodels Work with GME infrastructure team! Utilize enhanced infrastructure support to Refactor PICML Allow integration of systems using both.NET & CCM Develop a pluggable glue-code framework for Bridging/Adapting cross- platform invocations Generate code to perform adaptation utilizing above framework

19 Proposed Approach: Criteria for Evaluation Demonstrate feasibility of integration by prototyping an application Bridges/adapts calls from CCM to.NET Web Services & vice-versa Demonstrate feasibility of automation of integration done at modeling level Identify & document requirements from modeling infrastructure (if any) for future improvements