Model-Driven Engineering of Component Middleware-based Systems Vanderbilt University Nashville, Tennessee Institute for Software Integrated Systems CS WithIT Seminar, April 26 th, 2007 Krishnakumar Balasubramanian

2 Model-Driven Engineering Approach System Composition Technologies – A Domain-Specific Modeling Language (DSML) to allow component specification & composition System Optimization Technologies – System optimization infrastructure Generation Technologies – Metadata generation infrastructure System Integration Technologies – System Integration using model composition Generation Technologies System Composition Technologies System Optimization Technologies System Integration Technologies

3 Presentation Road Map Technology Context Overview of Research Challenges Research Area 1: Component System Integration Research Area 2: Application-Specific Optimizations Summary of Research Contributions Concluding Remarks

4 Component Middleware Components encapsulate “business” logic Components interact via ports Provided interfaces Required interfaces Event sinks & sources Attributes Allow navigation between ports Containers provide execution environment for components Components/containers can also Communicate via a middleware bus & reuse common middleware services SecurityReplicationNotificationPersistence SchedulingA/V StreamingLoad Balancing Middleware Bus … Container … … … Components allow reasoning about systems at higher level of abstraction e.g., CORBA Component Model (CCM), Microsoft.NET Web Services, Enterprise Java Beans (EJB)

5 Presentation Road Map Technology Context Overview of Research Challenges Research Area 1: Component System Integration Research Area 2: Application-Specific Optimizations Summary of Research Contributions Concluding Remarks

6 Component System Development Challenges Lack of system composition tools

7 Component System Development Challenges Lack of system composition tools Complexity of declarative platform API & notations

8 Component System Development Challenges Lack of system composition tools Complexity of declarative platform API & notations Composition overhead in large- scale systems

9 Component System Development Challenges Lack of system composition tools Complexity of declarative platform API & notations Composition overhead in large- scale systems Need to integrate with systems built using heterogeneous middleware

10 Component System Development Challenges My research provides tools to design, optimize & integrate “systems-in-the-large” Lack of system composition tools Complexity of declarative platform API & notations Composition overhead in large- scale systems Need to integrate with systems built using heterogeneous middleware Emphasis still on programming- in-the-small Whack-a-mole approach to system development Violation of Don’t Repeat Yourself (DRY) principle Need abstractions for expressing system level design intent

11 Solution Approach: PICML & SIML System Composition Technologies – A Domain-Specific Modeling Language (DSML) to allow component specification & composition System Optimization Technologies – System optimization infrastructure Generation Technologies – Metadata generation infrastructure System Integration Technologies – System Integration using model composition Generation Technologies System Composition Technologies System Optimization Technologies System Integration Technologies

12 Presentation Road Map Technology Context Overview of Research Challenges Research Area 1: Component System Integration Research Area 2: Application-Specific Optimizations Summary of Research Contributions Concluding Remarks

Research Area 1: Component System Integration Integration can be done at multiple levels Process Integration Functional Integration Data integration Presentation Integration Portal Integration System refers to software systems built using Service-Oriented Architecture (SOA) technologies like Web Services Component middleware technologies like Enterprise Java Beans (EJB), CORBA Component Model (CCM) System Integration refers to functional integration done via Distributed Object Integration Service-Oriented Integration 13

Related Research 14 CategoryRelated Research Integration Evaluation Tools IBM’s WebSphere Smith, C., & Williams, L. (2001). Performance Solutions Integration Design Tools Object Management Group. UML Profile for Enterprise Application Integration (EAI), omg document formal/ edition, March Integration Patterns G. Hohpe and B. Woolf. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley Professional, October Resource Adapters Java Messaging Specification & J2EE Connector Architecture IBM’s MQSeries (IBM, 1999), Microsoft BizTalk Server Integration frameworks Web Ontology Language. Feb Ian Foster, C. Kesselman, J. M. Nick, and S. Tuecke. Grid Services for Distributed System Integration. Computer, 35(6):37–46, 2002 L. Zeng, B. Benatallah, A. H. Ngu, M. Dumas, J. Kalagnanam, and H. Chang. QoS-Aware Middleware for Web Services Composition. IEEE Trans. Softw. Eng., 30(5):311–327, 2004 Integration Quality Analysis H. Ludwig, A. Keller, A. Dan, R. P. King, and R. Franck. Web Service Level Agreement Language Specification. January 2003.

Related Research: What’s missing? Integration Evaluation Tools Serve only the preliminary stage Integration Design tools Not integrated with deployment Integration Patterns Offer best practices (only) Resource Adapters Still require manual “integration programming” Integration frameworks Rely on unambiguous, formal representations of capabilities Not always feasible with legacy systems 15

Motivating Application Enterprise Distributed System Different client applications Differentiated services to clients System Domain Shipboard Computing On-demand situation awareness Integration with human operators Logging Component Originally built using CORBA Component Model (CCM) Needed to be exposed as a Web Service Integrate with Log Analyzer built as Web Service Clients 16

Component System Integration: Unresolved Challenges(1/5) 1.Choosing an appropriate level of integration Need to select elements from the different technologies Selection Challenges Number of normalizations To/from native types Flexibility of deployment In-process/Out-of- process Evolving the integration architecture Increasing the number of peers integrated Availability of platform- specific infrastructure OS, languages 17

2.Reconciling differences in interface specifications Datatype Mapping e.g., CORBA IDL to Web Services WSDL Exception Mapping e.g., SOAP faults to CORBA Exceptions Language Mapping Different source/target implementation languages Limited scope at level of functional integration Restricted to out-of- process IPC 18 Component System Integration: Unresolved Challenges(2/5)

Component System Integration: Unresolved Challenges(3/5) 3.Managing differences in implementation technologies How to map low-level technology details such as networking, discovery? Protocol differences e.g., Internet Inter-ORB Protocol (IIOP) in CCM vs. SOAP in Web Services Discovery services differences e.g., CORBA Naming Service vs. UDDI repositories Quality of Service (QoS) Ensure service-level agreements are met 19

Component System Integration: Unresolved Challenges(4/5) 4.Managing deployment of subsystems Declarative notations used to capture various configuration options e.g., CCM deployment descriptors,.NET assembly manifests Functionality of system depends on correct configuration of metadata Development-time default values different from production values e.g., configuration of Web Servers hosting Web Services 20

Component System Integration: Unresolved Challenges(5/5) 5.Interoperability issues Multiple implementations of same middleware technology Differences between implementations e.g., Java Web Services stack vs..NET Web Services stack Problems show up only during system integration e.g., existence of standards like Web Services-Interoperability (WS-I) Need to deal with interoperability issues in a less than ideal world 21

22 Solution Approach: (Meta-) Model Composition System Integration using (Meta-) Model composition Hierarchical composition of multiple domain-specific modeling languages(DSMLs) Each corresponding to the different middleware technologies (domains) Built in a reusable & extensible fashion “Open-Closed” principle New languages can be added; existing ones reused Semantics of existing DSMLs preserved in composition Refinement of semantics allowed

System Integration Modeling Language (SIML) Prototype implementation of (Meta-) model composition Composed from two domain- specific Modeling Languages (DSMLs) CCM  Platform- Independent Component Modeling Language (PICML) Web Services  Web Services Modeling Language (WSML) Supports integration of applications built using CCM and Web Services 23

24 System Integration Evaluation Criteria 1.Seamless support for existing tools Existing investment in tools should be preserved 2.Integration architecture should evolve with changes to the applications Changes to applications shouldn’t require a lot of rework 3.Preserve application encapsulation Individual applications should be shielded from changes in other applications 4.Existing semantics should be preserved Semantics of stand-alone applications should be preserved

25 Evaluating System Integration using SIML 1.Representation of independent concepts PICML & WSML model interpreters work seamlessly in SIML Allows Import/Export of both PICML and WSML models 2.Supporting model evolution PICML & WSML packaged as read-only model libraries Changes to either propagated through library refresh 3.Partitioning model namespaces PICML & WSML assigned separate namespaces 4.Handling constraints Namespaces provide appropriate context for constraint evaluation SIML satisfies the evaluation criteria for system integration

Resolving Challenge 1 : Choosing Integration Level Combination of pre-defined & customizable integration levels Pre-defined interactions CCM Ports  Web Service Ports User-defined interactions Component level Assembly level SIML defines new interactions between CCM ports and Web Services ports Allows integration of other middleware technologies e.g., Enterprise Java Beans 26 SIML allows representing integration architecture at the model level

Resolving Challenge 2: Reconciling Differences in Interfaces SIML provides a set of tools idl_to_wsdl, idl_to_picml, WSDLImporter Both IDL and WSDL can be directly imported into models Performs datatype mapping Maps CORBA datatypes to WSDL datatypes Performs exception mapping Maps CORBA exceptions to WSDL faults Limited language mapping Maps ISO/ANSI C++ to Microsoft C++/CLI 27 SIML’s interface mapping automatically handles differences in interfaces

Resolving Challenge 3: Handling Implementation Differences Resource Adapters are typically used to bridge implementation differences SIML implements resource adapters via Gateways Automatically generates gateways from models Perform protocol mapping IIOP  SOAP mapping Perform discovery mapping Connects to CORBA Naming Service Configurable Gateway generation from models GSOAP, Microsoft.NET Web Services 28 SIML generates integration glue-code directly from the application models

Resolving Challenge 4: Managing Heterogeneous Deployment Deployment of sub-systems requires different mechanisms SIML can use existing tools for individual sub-system deployment Possible because of model composition Deployment metadata configuration & generation Directly from within SIML CCM DeploymentPlan.exe Web Services WSDLExporter.exe 29 SIML provides an integrated view of heterogeneous deployment

Resolving Challenge 5: Handling Interoperability Differences Knowledge of sub-DSML technologies built into SIML Allows compensating for interoperability differences idl_to_wsdl.exe Maps IDL to WS-I defined subset of WSDL GatewayGenerator.exe Inter-operable subset of RPC encoding WSDLExporter.exe Interoperable XML namespaces in WSDL Newly discovered incompatibilities can be worked around  30 SIML codifies inter-operability workarounds

31 Summary of Research Contributions CategoryBenefitsPublications System Integration Technologies System integration from the high-level abstraction of models Model-composition allows preserving investment in existing domain-specific languages Relieves system integrators from dealing with intricacies of heterogeneous middleware technologies by automatically generating integration glue code 1.IEEE Engineering of Computer-Based Systems, Designing Software- Intensive Systems: Methods and Principles, Bookchapter Edited by Dr. Pierre F. Tiako, Langston University, OK. (Accepted for publication)

32 Presentation Road Map Technology Context Overview of Research Challenges Research Area 1: Component System Integration Research Area 2: Application-Specific Optimizations Summary of Research Contributions Concluding Remarks

33 Research Area 2: Application Specific Optimizations Middleware tries to optimize execution for every application Collocated method invocations Optimize the (de-)marshaling costs by exploiting locality Specialization of request path by exploiting protocol properties Caching, Compression, various encoding schemes Reducing communication costs Moving data closer to the consumers by replication Reflection-based approaches Choosing appropriate alternate implementations

34 Related Research CategoryRelated Research Component Middleware Wang, N. et al, Applying Reflective Techniques to Optimize a QoS-enabled CORBA Component Model Implementation, 24th Annual International Computer Software & Applications Conference Taipai, Taiwan, October Teiniker, E. et al, Local Components & Reuse of Legacy Code in the CORBA Component Model, EUROMICRO 2002, Dortmund, Germany (2002) Diaconescu, A. & Murphy, J., Automating the Performance Management of Component-based Enterprise Systems through the Use of Redundancy, Proceedings of the 20th IEEE/ACM international Conference on Automated Software Engineering (Long Beach, CA, USA, November , 2005). Gurdip Singh & Sanghamitra Das, Customizing Event Ordering Middleware for Component-Based Systems, pp , Eighth IEEE International Symposium on Object-Oriented Real-Time Distributed Computing (ISORC'05), Web ServicesGao, L et al, 2003, Application specific Data Replication for Edge Services, In Proceedings of the 12th International Conference on World Wide Web (Budapest, Hungary, May , 2003). WWW '03. ACM Press, New York, NY, Mukhi, N. K., 2004, Cooperative Middleware Specialization for Service Oriented Architectures, Proceedings of the 13th International World Wide Web Conference on Alternate Track Papers & Posters (New York, NY, USA, May , 2004).

35 Related Research: What’s missing? Lack of high-level notation to guide optimization frameworks Missing AST of application

36 Related Research: What’s missing? Lack of high-level notation to guide optimization frameworks Missing AST of application Emphasis on detection at run- time (reflection) Additional overhead in the fast path Not suitable for all systems Not completely application transparent Requires providing multiple implementations Optimization performed either Too early, or too late

37 1.Overhead of platform mappings Blind adherence to platform semantics Inefficient middleware glue code generation per component Example: Creation of a factory object per component Servant glue- code generation for every component Need optimization techniques to build large-scale component systems! Application Specific Optimizations: Unresolved Challenges

Solution Approach: Component Assembly Optimizer 38 Component Assembly Optimizer Uses the application model as the input Exploits knowledge about platform semantics to rewrite the input model to a functionally equivalent output model Generates middleware glue- code Generates deployment configuration files Operates just before deployment Can be viewed as a “deployment compiler”

Component Assembly Optimizer Inputs Set of 3 input graphs G 1 : (V 1, E 1 ) where V 1 is the set of components in the application & E 1 is the set of connections between them G 2 : (V 2, E 2 ), where V 2 is the union of vertices in V 1 with the set of QoS configuration options on components & E 2 is the set of associations between the components and the QoS options G 3 : (V 3, E 3 ), where V 3 is the union of vertices in V 1 with the set of nodes in the target deployment domain of the application & E 3 is the set of associations between the components and the nodes of the domain 39

Component Assembly Optimizer Output 40 Produces an output graph G o : (V o, E o ), where V o is the set of composites (physical assemblies) created on a single node, & E o is the set of connections between the composites Creation of physical assemblies subject to a number of constraints Average case |V o | < |V 1 | Worst case |V o | = |V 1 |, i.e., the optimizer couldn’t create any physical assemblies Equivalent to deployment of original application

Physical Assembly 41 Physical Assembly Created from the set of components that are deployed within a single process of a target node Subject to various constraints Example constraints include No two ports of the set of components should have the same name No two components should have incompatible RT- CORBA policies No change to individual component implementations

Physical Assembly Generation 42 Given set of components deployed on a single process of a target node Compute pair-wise intersections of component port name sets If intersection is null, merge the two components into a physical assembly Supported interfaces of constituent components are supported by physical assembly Additional RT-CCM constraint If intersection is null & RT- CORBA policies of the components are compatible

Middleware Concepts Exploited by Physical Assemblies 43 Opacity of object references Components don’t rely on specific details of object references, e.g., location of type information Allows replacing references transparent to component implementations

Middleware Concepts Exploited by Physical Assemblies 44 Opacity of object references Components don’t rely on specific details of object references, e.g., location of type information Allows replacing references transparent to component implementations Presence of a component context Components access ports of other components using a context object Allows replacing context transparent to component implementations Container Servant Component Specific Context CCMContext Main Component Executor Executors POA EnterpriseComponent CCMContext Container Servant Component Specific Context CCMContext Main Component Executor Executors POA EnterpriseComponent CCMContext user implemented code Container CORBA Component POA E x t e r n a l I n t e r f a c e s Interna l Interface s

Middleware Concepts Exploited by Physical Assemblies 45 Opacity of object references Components don’t rely on specific details of object references, e.g., location of type information Allows replacing references transparent to component implementations Presence of a component context Components access ports of other components using a context object Allows replacing context transparent to component implementations Clean separation between glue-code & component implementation Allows modifications transparent to component implementations Technique can be applied to other middleware with these properties

46 Physical Assembly Evaluation Criteria Footprint of physical assembly components Compared to vanilla Component- Integrated ACE ORB (CIAO) Different scenarios Simple scenarios (<= 10 components) ARMS GateTest scenarios (150+ components) Reduce static & dynamic footprint Reduce no. of homes by (n – 1) / n Reduce no. of objects registered with POA by (n – 1) / n Reduce no. of context objects created by (n – 1) / n n = no. of components deployed in a single process

Evaluating Physical Assemblies Boeing’s BoldStroke Basic Single Processor Scenario Consists of 4 components Timer – Periodically sends refresh signal to the GPS GPS – Calculates new co-ordinates of the aircraft in response to Timer signal Airframe – Processes new location inputs from GPS Display – Updates the new location of the aircraft in the navigation display 47

Applying Physical Assemblies to BasicSP Scenario Assumption: GPS, Airframe and Display components are deployed on a single processor board Applying physical assemblies Combines GPS, Airframe and Display components into a single physical assembly (BasicSPAsm) Maintains the same number of connections Timer component not combined (due to clash in port names) 48

Experimental Results: BasicSP Scenario Testbed Linux FC6 Dual 2.4Mhz processor 1.5GB RAM Evaluation for larger applications (~150 components) is in progress 49 Physical assembly mapping reduces the footprint significantly Static footprint reduction of ~45% Dynamic footprint reduction of ~10%

50 Application Specific Optimizations: Unresolved Challenges 2.Lack of application context Optimization decisions relegated to run-time e.g., every invocation performs check for locality Settle for near-optimal solutions Missed middleware optimization opportunities

51 Application Specific Optimizations: Unresolved Challenges 2.Lack of application context Optimization decisions relegated to run-time e.g., every invocation performs check for locality Settle for near-optimal solutions Missed middleware optimization opportunities e.g., allocation of RT-CORBA thread pools and lanes Large overhead compared to collocated calls Cannot be solved efficiently at middleware level alone! Invocation within the same pool/lane (12µs) Invocation to a different pool/lane (150µs)

Solution Approach: Use Application Context from Models Use application structure & context available in models Create fast path within middleware for physical assemblies Cross-pool/lane proxy Create platform mappings to use fast path E.g., Use matching real-time policies as additional constraint when creating physical assemblies Configure middleware resources efficiently E.g., place physical assemblies with matching policies in the same thread pool or thread pool with lanes 52

53 Context-driven Optimization Evaluation Criteria Improve performance t = no. of cross-pool/lane interactions between components within an assembly Transform t remote calls to t cross-pool/lane calls Eliminate mis-optimizations Check incompatible POA policies Incompatible invocation semantics (oneway or twoway) No changes to individual component implementations Eliminate need for a local vs. remote version Customizable & application transparent

Experimental Results: Cross pool/lane proxy 54 Standard deviation <= 3µs Max latency improved by ~50% 99% latency improved by 60-66% Average latency improved by 60 – 66% Significant performance benefits with cross pool/lane proxy!

55 Presentation Road Map Technology Context Overview of Research Challenges Research Area 1: Component System Integration Research Area 2: Application-Specific Optimizations Summary of Research Contributions Concluding Remarks

56 Summary of Research Contributions TopicBenefits System Composition Technologies Support static composition of systems by ensuring that the components get built correctly Support dynamic composition of systems by ensuring that the connections between components are correct Address composition scalability concerns by employing model-weaving technologies Generation Technologies Expressing domain constraints in the form of a platform-independent MDE tool Manage & automate the generation of syntactically valid metadata in various required declarative notations System Integration Technologies Novel approach to system integration based on model composition Supports functional integration of heterogeneous middleware Generation of integration glue-code directly from models System Optimization Technologies Automatic discovery & realization of optimizations from models using application context; such optimizations are impossible to perform if operating at the middleware layer alone. A novel mechanism for mapping an assembly as a component to both reduce application footprint and increase performance

57 Summary of Publications CategoryPublications System Composition Technologies 1.Towards Composable Distributed Real-time & Embedded Software, Proceedings of the 8th IEEE Workshop on Object-oriented Real-time Dependable Systems (WORDS), Guadalajara, Mexico, January Applying Model-Driven Development to Distributed Real-time & Embedded Avionics Systems, the International Journal of Embedded Systems, special issue on Design & Verification of Real- Time Embedded Software, April A Platform-Independent Component Modeling Language for Distributed Real-time & Embedded Systems, Elsevier J. of Computer & System Sciences, Weaving Deployment Aspects into Domain-Specific Models, International J. on Software Engineering & Knowledge Engineering, Summer 2006 (Accepted). Generation Technologies 1.A Platform-Independent Component Modeling Language for Distributed Real-time & Embedded Systems, 11th IEEE Real-Time & Embedded Technology & Applications Symposium, San Francisco, CA, March Developing Applications Using Model-Driven Design Environments, Computer, vol. 39, no. 2, pp , Feb., Model-driven Development of Component-based Distributed Real-time & Embedded Systems, Model Driven Engineering for Distributed Real-time & Embedded Systems, Hermes, Model Driven Middleware: A New Paradigm for Deploying & Provisioning Distributed Real-time & Embedded Applications, Elsevier J. of Science of Computer Programming: Special Issue on Model Driven Architecture, System Integration Technologies 1.Component-based System Integration via (Meta)Model Composition, 14th Annual IEEE International Conference and Workshop on the Engineering of Computer Based Systems (ECBS), Tucson, AZ, March System Integration via Model Composition, Designing Software-Intensive Systems: Methods and Principles, Edited by Dr. Pierre F. Tiako, Langston University, OK. (Submitted) First AuthorSecond Author

58 Concluding Remarks Component middleware is an emerging paradigm Problems with component middleware Significant gaps in the development & integration toolchain Potential to negate benefits of using component middleware Direct application to DRE systems not possible Might not meet the stringent QoS requirements of DRE systems My research Resulted in improved tool-support for component middleware Model-Driven Engineering toolchain Performs optimizations on component middleware that were previously infeasible Exploit application context made available by MDE tool- chain Successful transition to DD(X) program for TSCEI deployment & configuration services Tools can be downloaded from

Questions? 59

60 Presentation Road Map Motivation Technology Context Overview of Research Challenges Research Area 1: Component System Integration Research Area 2: Application-Specific Optimizations Summary of Research Contributions Concluding Remarks

61 Where We Started: Object-Oriented Programming Object-oriented (OO) programming simplified software development through higher level abstractions & patterns, e.g., Well-written OO programs exhibit recurring structures that promote abstraction, flexibility, modularity, & elegance Decoupling interfaces & implementations Associating related data & operations operation1() operation2() operation3() operationn() data class X

62 Distributed Object Computing (DOC) Middleware Applies the Broker pattern to abstract away lower-level OS & protocol-specific details for network programming Creates distributed systems that are easier to model & build using OO techniques Result: robust distributed systems built with distributed object computing (DOC) middleware e.g., CORBA, Java RMI, etc. 11 Proxy service Service service AbstractService service Client We now have more robust software & more powerful distributed systems operation() Object : Interface X : Client Middleware

63 Traditional DOC Middleware Limitations Unable to provide multiple, alternate views per client

64 Traditional DOC Middleware Limitations Unable to provide multiple, alternate views per client Unable to navigate between interfaces in a standardized fashion

65 Traditional DOC Middleware Limitations Unable to provide multiple, alternate views per client Unable to navigate between interfaces in a standardized fashion Specification & enforcement of policy Done via low-level mechanisms, i.e., by writing code

66 Traditional DOC Middleware Limitations Unable to provide multiple, alternate views per client Unable to navigate between interfaces in a standardized fashion Specification & enforcement of policy Done via low-level mechanisms, i.e., by writing code Accidental complexities Middleware configuration is complex, tedious & error-prone Ad hoc deployment mechanisms Tedious, error-prone Not reusable Significant challenges for system developers!

67 Traditional DOC Middleware Limitations Unable to provide multiple, alternate views per client Unable to navigate between interfaces in a standardized fashion Extensibility restricted to language (Java, C++) and/or platform (CORBA)

68 Component System Development Lifecycle Specification of supported interfaces

69 Component System Development Lifecycle Specification of component types, e.g., provided & required interfaces

70 Component System Development Lifecycle Component Implementation

71 Component System Development Lifecycle Grouping of component implementation artifacts & metadata into component packages

72 Component System Development Lifecycle Specification of component interconnections & composition of component assembly packages

73 Component System Development Lifecycle Specification of deployment target domain & configuration of component assembly

74 Component System Development Lifecycle Deploy component assembly packages onto target nodes according to a deployment plan

75 System Resource Manager Global QoS manager Control Center User interaction.NET Web Services Image Stream(s) Local Resource Manager Local QoS manager Qoskets QoS enforcer QoS predictors QoS estimators Built using the Component-Integrated ACE ORB (CIAO) Example Scenario: Emergency Response System Developed for DARPA PCES program (dist-systems.bbn.com/papers/)

76 Presentation Road Map Motivation Technology Context Overview of Research Challenges Research Area 1: Composition of Component Systems Research Area 2: Expression of Design Intent Research Area 3: Component System Integration Research Area 4: Application-Specific Optimizations Summary of Research Contributions Concluding Remarks

77 Component middleware allows composition across multiple dimensions Temporal – Static vs. dynamic Research Area 1: Composition of Component Systems

78 Component middleware allows composition across multiple dimensions Temporal – Static vs. dynamic Structural – Flat vs. hierarchical Systems are no longer built from scratch Composed from COTS components & frameworks using design patterns Research Area 1: Composition of Component Systems

79 Related Research CategoryRelated Research Component Environments G. Karsai et al, A Modeling Language & Its Supporting Tools for Avionics Systems, In Proceedings of 21st Digital Avionics Systems Conf., Aug Lüer, C. & Rosenblum, D. S. 2001, WREN---an environment for component- based development, SIGSOFT Soft. Eng. Notes 26, 5 (Sep. 2001), Jack Greenfield et al, Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools, Wiley, 2004 Programming Models G. T. Heineman & W. T. Councill, editors, Component-Based Software Engineering: Putting the Pieces Together, Addison-Wesley, Czarnecki, K. & Eisenecker, U. W. Generative Programming: Methods, Tools, & Applications, ACM Press/Addison-Wesley Publishing Co., 2000 Batory, D. et al, Scaling step-wise refinement, in Proceedings of the 25th International Conference on Software Engineering (Portland, Oregon, May , 2003). Functional Verification J. Hatcliff et. al., Cadena: An Integrated Development, Analysis, & Verification Environment for Component-based Systems, in Proceedings of the 25th International Conference on Software Engineering, (Portland, OR), May J. A. Stankovic et al, VEST: An Aspect-based Composition Tool for Real-time Systems, in Proceedings of the IEEE Real-time Applications Symposium, (Washington,DC), IEEE, May 2003.

80 Related Research: What’s Missing? Tool-specific component technologies As opposed to component- technology agnostic tools! Emphasis on component programming models /languages How to write better components? Lack of deployment-time tool support No support for deployment artifacts! Lack of tool support for system level development It’s not just the functionality, it’s the packaging!

81 1.Lack of tool support for defining consistent component interactions Primitive interface definition tools: Edit  Compile  Run  Fix cycle component SystemResourceManager { attribute double available_cpu; attribute double available_bw; attribute double needed_cpu; attribute double needed_bw; attribute UAV_List uavs_from_lrm; uses multiple LRMInterface my_lrms; provides SRMInterface srm_interface; publishes ResourceAllocationEvt resourceEvt; publishes PolicyChangeEvt policy_evt; }; System Composition: Unresolved Challenges

82 1.Lack of tool support for defining consistent component interactions Primitive interface definition tools: Edit  Compile  Run  Fix cycle No inter-connection information 2.Lack of integrated system view Design view, e.g., UML models Development view, e.g., Visual Studio component MultiReceiver : ImageProcessingQosket { consumes ResourceAllocationEvt resourceEvt; consumes PolicyChangeEvt policyEevt; }; Integrated view of the system is essential! System Composition: Unresolved Challenges

83 3.Lack of tool support for multi-level composition Change propagation done in an ad-hoc fashion Redundant & error-prone Violates “Don’t Repeat Yourself” (DRY) principle Need support for different composition granularities 4.Lack of context-aware policy specification mechanisms No one size fits all! 5.Lack of scalable techniques for composition Manual techniques don’t scale well Lack of tool support negates benefits of components! System Composition: Unresolved Challenges Policy A Policy A’

84 Solution Approach: DSML Infrastructure Platform-Independent Component Modeling Language (PICML) Developed using GME Core of Component Synthesis using Model- Integrated Computing (CoSMIC) toolchain Capture elements & dependencies visually

85 Solution Approach: DSML Infrastructure Platform-Independent Component Modeling Language (PICML) Developed using GME Core of Component Synthesis using Model- Integrated Computing (CoSMIC) toolchain Capture elements & dependencies visually Define “static semantics” using Object Constraint Language (OCL)

86 Solution Approach: DSML Infrastructure Platform-Independent Component Modeling Language (PICML) Developed using GME Core of Component Synthesis using Model- Integrated Computing (CoSMIC) toolchain Capture elements & dependencies visually Define “static semantics” using Object Constraint Language (OCL) Define “dynamic semantics” via model interpreters Employ generative technologies

87 Solution Approach: System Composition Tools Disallow inconsistent component interactions Provide integrated view of system Support system composition across multiple levels Support context-dependent policy specifications Support scalable composition techniques Support integration with component build tools & component repositories Policy A Policy A’

88 Challenges 1 & 2 Resolved: Visual Interaction Definition 1.Syntactically compatible component interaction definition Enforce platform semantics using OCL constraints Disallow inconsistent component interactions

89 Challenges 1 & 2 Resolved: Visual Interaction Definition 1.Syntactically compatible component interaction definition Enforce platform semantics using OCL constraints 2.High-level integrated view of system In addition to multiple task-specific views of the same system K Balasubramanian et al, “Applying Model-Driven Development to Distributed Real-time & Embedded Avionics Systems,” the International Journal of Embedded Systems, special issue on Design & Verification of Real-Time Embedded Software, April 2005 Provide integrated view of system

90 Challenges 3 & 4 Resolved: Hierarchical Composition 3.Allow composition across multiple levels Components, assemblies of components & assemblies of assemblies Propagate changes automatically Define assemblies as types Instantiate multiple times Support system composition across multiple levels

91 Challenges 3 & 4 Resolved: Hierarchical Composition 3.Allow composition across multiple levels Components, assemblies of components & assemblies of assemblies Propagate changes automatically Define assemblies as types Instantiate multiple times 4.Policy/Configuration can be specified At component level Overridden at assembly level(s) K Balasubramanian et al, “A Platform-Independent Component Modeling Language for Dist- ributed Real-time & Embedded Systems,” Journal of Computer & System Sciences, 2006 Support context-dependent policy specifications

92 Challenge 5 Resolved: Scalable System Composition 5.Integrate support for scalable composition techniques Aspect-Oriented Modeling Addresses scalability of modeling effort C-SAW tool Developed by SOFTCOM (UAB) C-SAW with PICML Provides template configurations (using ECL) that are weaved into a model User can customize the templates depending on application requirements K. Balasubramanian et al, “Weaving Deployment Aspects into Domain-Specific Models,” the International Journal on Software Engineering & Knowledge Engineering, 2006 (Accepted) Support scalable composition techniques

93 Research Contributions CategoryBenefitsPublications System Composition Technologies Support static composition of systems by ensuring that the components get built correctly Support dynamic composition of systems by ensuring that the connections between components are correct Provide integrated view of system Address composition scalability concerns by employing model-weaving technologies 1.IEEE Workshop on Object- oriented Real-time Dependable Systems (WORDS), International Journal of Embedded Systems, Special issue on Design & Verification of Real-Time Embedded Software, Elsevier Journal of Computer & System Sciences, International Journal on Software Engineering & Knowledge Engineering, (Accepted)

94 Presentation Road Map Motivation Technology Context Overview of Research Challenges Research Area 1: Composition of Component Systems Research Area 2: Expression of Design Intent Research Area 3: Component System Integration Research Area 4: Application-Specific Optimizations Summary of Research Contributions Concluding Remarks

95 Research Area 2: Expression of Design Intent Traditional middleware had a significant gap between design intent & its expression using 3 rd generation languages Component middleware helps bridge this gap by replacing imperative techniques with declarative techniques Examples: Describing connection between components Describing constituents of component packages Configuration of components Configuration of middleware infrastructure

96 Related Research CategoryRelated Research Operating System John DeTreville, Making System Configuration More Declarative, Proceedings of the 10th Work. on Hot Topics in Operating Systems, June 2005, USENIX. Bryan Cantrill et al, Dynamic Instrumentation of Production Systems, USENIX Annual Technical Conference, 2004 Lionel Cons & Piotr Poznanski, Pan: A High-Level Configuration Language, LISA, Proceedings of the 16th Conference on Systems Administration (LISA 2002), 2002, pp Software Description R. Chinnici et al, Web Services Description Language (WSDL) 2.0 part 1: Core language, August 2004, Dashofy, E. M. et al, An infrastructure for the rapid development of XML-based architecture description languages, Proceedings of the 24th international Conference on Software Engineering (Orlando, Florida, May , 2002) Middleware Packaging Richter, J., Applied Microsoft.NET Framework Programming, Microsoft Press, Sun Microsystems, Enterprise Java Beans Specification, Version 2.1, 2002 Middleware Communication M Rose, The Blocks Extensible Exchange Protocol Core (BEEP), RFC 3080, March 2001 Don Box et al, Simple Object Access Protocol (SOAP) 1.1,

97 ScaleQosket LocalResourceManagerComponent... incoming_image_outgoing_image_Evt outgoing_image_Evt incoming_image_Evt Related Research: What’s Missing? Declarative techniques use tool-friendly technologies to express design intent Example: XML XML is non-intuitive Error-prone to write manually Changes to system require changes to generated XML Redundant effort Problems with imperative techniques not solved Declarative techniques shifted the problem into a different space “Whack-a-mole” approach Support for declarative notations of component middleware is critical! Is id unique? Does portName refer to a valid port? Is idref a valid reference?

98 Expression of Design Intent: Unresolved Challenges 1.Complexity of Declarative Notations Example 1: CORBA Interface Definition Language (IDL) Differences between CORBA 2.x & CORBA 3.x (CCM) New keywords in the language Subtle differences in syntax & semantics of similar elements –CORBA 2.x interfaces –CORBA 3.x components // CORBA 3.x component ImageProvider {}; component ImageViewer {}; component LRM : ImageProvider, ImageViewer { // Operations on LRM }; // CORBA 2.x interface ImageProvider {}; interface ImageViewer {}; interface LRM : ImageProvider, ImageViewer { // Operations on LRM }; Accidental complexities are present in every technology!

99 Expression of Design Intent: Unresolved Challenges Example 2:.NET manifests Each assembly in.NET can be associated with manifests Policy specifications for assembly, user, domain Configuration of assembly Manifest names are closely associated with assembly names Foo.dll  Foo.dll.manifest Foo.dll  Foo.dll.config OS loader ignores configurations in files with other names 2.Lack of support for system evolution Interfaces & metadata of individual components needs to evolve with the system Need flexible abstractions to express design intent!

100 Solution Approach: Model-Driven Generation Provide high-level abstractions for specification of design intent Automate generation of platform-specific metadata from these abstractions Provide support for system interface & metadata evolution Provide support for developing heterogeneous systems

101 Challenge 1 Resolved: Automate Generation of Metadata 1.High-level, user- friendly visual abstractions for declarative notations Define a type system that captures the platform semantics e.g., CCM,.NET Provide high-level abstractions for specification of design intent

102 Challenge 1 Resolved: Automate Generation of Metadata 1.High-level, user- friendly visual abstractions for declarative notations Define a type system that captures the platform semantics e.g., CCM,.NET Build model interpreters Generate descriptors in required (potentially different) declarative notation(s) for multiple platforms Ensure generated artifacts are: Syntactically valid K. Balasubramanian et al, “Developing Applications Using Model-Driven Design Environments,” Computer, vol. 39, no. 2, pp , Feb., 2006 Automate generation of platform-specific metadata from these abstractions

103 Challenge 2 Resolved: System Interface Evolution 2.Provide support for system interface evolution (Re-)Import/(Re-)Export IDL Provides migration for legacy systems Eliminate accidental complexities Define platform interface semantics using MetaGME & OCL constraints e.g., a receptacle should be connected to a facet of the same type or a type derived from the receptacle K. Balasubramanian et al, “A Platform-Independent Component Modeling Language for Distributed Real-time & Embedded Systems,” Proceedings of the 11th IEEE Real-Time & Embedded Technology & Applications Symposium, San Francisco, CA, March 2005 Provide automated support system interface & metadata evolution

104 Research Contributions CategoryBenefitsPublications Generative System Technologies Expressing domain constraints in the form of a platform-independent MDE tool Manage & automate the generation of syntactically valid metadata in various (potentially different) required declarative notations 1.Model Driven Engineering for Distributed Real-time & Embedded Systems, edited by Sebastien Gerard, Joel Champea, & Jean-Philippe Babau, Hermes, IEEE Real-Time & Embedded Technology & Applications Symposium, Elsevier Journal of Science of Computer Programming: Special Issue on Model Driven Architecture, IEEE Computer, 2006

105 System Composition: Proposed Enhancements Integrate with portable infrastructure build tools like MakeProjectCreator Exploit application context information to take advantage of native platform build tool capabilities, e.g.: Alter the visibility of symbols Elevate implementation artifact abstraction Allows managing components in terms of packages Push metadata into Repository Manager to allow execution of meta-queries, e.g.: “Do you have a sensor with latency specification < 6 µs?” “Give me a database capable of handling 2,000 transactions/sec”

106 Proposed Enhancements: Evaluation Criteria Baseline for comparison Deployment of a system with existing tools (vanilla CIAO & DAnCE) Eliminate the need to manually write build scripts Reduce static footprint per component type by 20% Simple changes already yield 10% Total savings accrue based on number of unique types per assembly Automate the creation of component packages Ability to automatically deploy a package into the Repository Manager

107 Expression of Design Intent: Proposed Enhancements Extend generative capabilities of PICML to.NET Web Services to generate: Assembly manifests (.dll.manifest) – Describes contents of a.NET component Application manifests (.exe.manifest) – Describes metadata associated with an application Application Configuration Files (app.config) – Describes application behavior configuration elements Web Service Configuration File (web.config) – Equivalent to app.config for external subsystems of a web Service Policy files ({enterprisesec, machine, security}.config) – Describes code access security policy elements Support development of heterogeneous systems

108 Proposed Enhancements: Evaluation Criteria Baseline for comparison Deployment of a system having both CCM components &.NET Web Services with existing tools (vanilla CIAO, Visual Studio) Automate three-staged deployment of typical.NET Web services Syntactically valid manifests for the 3 stages: Development, Testing, & Production Eliminate errors in deployment due to inconsistent policies Eliminate need for user to write glue code to integrate a CCM component with a.NET Web Service

109 Proposed Approach: Physical Assembly Mapping 3.Devise mapping for physical component assembly Exploit hierarchy of application structure to fuse (make a component internal) at multiple levels in hierarchy Experimentally validate right depth of hierarchy to stop fusion Too deep – Single giant blob Too shallow – Potentially lower benefits

110 Proposed Approach: Evaluation Criteria Baseline for comparison Performance & footprint (with vanilla CIAO) Emergency Response System (30+ components) ARMS GateTest scenarios (1,800+ components) Scenario with & without inherent hierarchy Reduce static & dynamic footprint n = no. of internal components, x = total no. of components in the assembly Reduce no. of homes by (n-1)/x Reduce no. of objects registered with POA by (n-1)/x

111 Proposed Approach: Evaluation Criteria Improve performance t = no. of interactions between components within an assembly Transform t collocation checked calls to t unchecked calls Eliminate mis-optimizations Check incompatible POA policies Incompatible invocation semantics (oneway or twoway) No changes to individual component implementations Eliminate need for a local vs. remote version Customizable & application transparent Investigate feasibility of applying optimizations to.NET Web Services (in addition to CCM)

112 Doctoral Research & Dissertation Timeline