1. Domain-Specific Modeling Languages for Configuring and Evaluating Enterprise DRE System Quality of Service Stoyan G. Paunov, James H. Hill, Douglas C. Schmidt, John M. Slaby & Steve Baker ECBS, Potsdam, Germany March 27 th -30 th, 2006

2. Model-Driven Development 2 Motivation: Service–Oriented Architectures Historically, distributed real-time & embedded (DRE) systems were built directly atop OS & protocols Operating System & Communication Protocols Hardware Devices Applications

3. Model-Driven Development 3 Applications Traditional methods of development have been replaced by middleware layers to reuse architectures & code Viewed externally as Service-Oriented Architecture (SOA) Middleware Operating System & Communication Protocols Hardware Devices Domain-Specific Services Common Services Distribution Middleware Infrastructure Middleware Historically, distributed real-time & embedded (DRE) systems were built directly atop OS & protocols Service-Oriented Architecture Middleware Motivation: Service–Oriented Architectures

4. Model-Driven Development 4 Applications Traditional methods of development have been replaced by middleware layers to reuse architectures & code Viewed externally as Service-Oriented Architecture (SOA) Middleware Operating System & Communication Protocols Hardware Devices Domain-Specific Services Common Services Distribution Middleware Infrastructure Middleware Historically, distributed real-time & embedded (DRE) systems were built directly atop OS & protocols Multi-layer Resource Manager (MLRM) e.g., DARPA Adaptive & Reflective Management System (ARMS) program’s Multi-layer Resource Manager (MLRM) MLRM leverages standards-based SOA middleware to manage computing & communication resources for shipboard computing environments Motivation: Service–Oriented Architectures

5. Model-Driven Development 5 Applications Domain-Specific Services ARMS Multi–Layer Resource Manager (MLRM) Domain-specific layered architecture includes –Top domain layer contains components that interact with the mission manager of TSCE –Middle resource pool layer is an abstraction for a set of computer nodes managed by a pool manager –Bottom resource layer contains the actual resource computing components

6. Model-Driven Development 6 Serialized Phasing is Common in Large-scale Systems Application components developed after infrastructure is mature Development Timeline Level of Abstraction System infrastructure components developed first

7. Model-Driven Development 7 Serialized Phasing is Common in Large-scale Systems Development Timeline Level of Abstraction Integration Surprises!!! System integration & testing Finished development

8. Model-Driven Development 8 Complexities of Serialized Phasing Development Timeline Level of Abstraction Still in development Ready for testing Complexities System infrastructure cannot be tested adequately until applications are done

9. Model-Driven Development 9 Complexities of Serialized Phasing Development Timeline Level of Abstraction Overall performance? Complexities System infrastructure cannot be tested adequately until applications are done Entire system must be deployed & configured properly to meet QoS requirements Existing evaluation tools do not support “what if” evaluation

10. Model-Driven Development 10 Unresolved QoS Concerns with Serialized Phasing Meet QoS requirements? Key QoS concerns Which D&C’s meet the QoS requirements? Development Timeline Level of Abstraction

11. Model-Driven Development 11 Unresolved QoS Concerns with Serialized Phasing Performance metrics? Key QoS concerns Which D&C’s meet the QoS requirements? What is the worse/average/best time for various workloads? Development Timeline Level of Abstraction

12. Model-Driven Development 12 Unresolved QoS Concerns with Serialized Phasing It is hard to address these concerns in processes that use serialized phasing Key QoS concerns Which D&C’s meet the QoS requirements? What is the worse/average/best time for various workloads? How much workload can the system handle until its QoS requirements are compromised? System overload? Development Timeline Level of Abstraction

13. Model-Driven Development 13 Promising Approach: Emulate Application Behavior via QoS-enabled SOA Middleware & MDD Tools While creating target infrastructure 1.Define & validate infrastructure specifications & requirements 2.Define & validate the appropriate QoS infrastructure policies 3.Define & validate application specifications & requirements of the emulated application components 4.Deploy the system based on the design rules so that it conforms to its specifications & requirements 5.Use analysis tools to evaluate & verify QoS performance 6.If necessary refine the system QoS policies’ configuration & repeat Enable “application” testing to evaluate target infrastructure earlier in lifecycle Component Workload Emulator (CoWorker) Utilization Test Suite Workflow (CUTS):

14. Model-Driven Development 14 Motivation for Using Emulation Can use actual target infrastructure Rather than imprecise simulations Many artifacts can be used directly in the final production system e.g., models of application component D&C plans Early feedback to developers, architects & systems engineers Instead of waiting for to complete application components before conducting performance experiments

15. Model-Driven Development 15 Challenges Ensuring the right granularity of QoS Using the standard RT CORBA API to configure QoS policies Specifying behavior of emulated application components to test the infrastructure Using XML metadata to configure components for QoS and to define behavioral components Managing large scale system configurations Refining system QoS properties

16. Model-Driven Development 16 Inherent Complexities 1.Preserving priorities end-to-end 2.Enforcing certain priorities at the server 3.Supporting thread pools effectively 4.Buffering client requests 5.Synchronizing objects correctly 6.Controling network & end-system resources C1: Providing the Right QoS Granularity Ensuring the right granularity of QoS E.g. high throughput of continuously refreshed data hard real-time deadlines associated with periodic processing well-defined computational paths traversing multiple components soft real-time processing of many tasks operator display and control requirements

17. Model-Driven Development 17 Inherent Complexities Thread pool policy model: thread pools & thread pools with lanes Priority propagation model: server declared & client propagated Connection model: a connection with logical bands for different priorities 1.Preserving priorities end-to-end 2.Enforcing certain priorities at the server 3.Supporting thread pools effectively 4.Buffering client requests 5.Synchronizing objects correctly 6.Controling network & end-system resources Real-time CORBA provides QoS policies to overcome challenges above, including: C1: Providing the Right QoS Granularity

18. Model-Driven Development 18 CORBA::Object_var object = this->orb_->resolve_initial_references ("RootPOA"); object = this->orb_->resolve_initial_references ("RTORB“) RTCORBA::RTORB_var rt_orb = RTCORBA::RTORB::_narrow (object.in ()); CORBA::Boolean allow_request_buffering = 0; CORBA::ULong max_buffered_requests = 0; CORBA::ULong max_request_buffer_size = 0; RTCORBA::ThreadpoolId threadpool_id_1 = rt_orb->create_threadpool (0, static_threads, dynamic_threads, default_thread_priority, allow_request_buffering, max_buffered_requests, max_request_buffer_size); CORBA::Policy_var threadpool_policy_1 = rt_orb->create_threadpool_policy (threadpool_id_1); result = this->create_POA_and_register_servant (threadpool_policy_1.in (), "first_poa", poa_manager.in (), root_poa.in (), this->orb_.in (), rt_orb.in ()); if (result != 0) return result; this->orb_->run (); this->orb_->destroy (); Programming Real-time CORBA QoS policies manually is tedious & error-prone C2: Using the RT CORBA APIs Accidental Complexities Declarative Configuration via XML: Better but not much better Decouple QoS configuration from core business logic

19. Model-Driven Development 19 MDD Solution to QoS Configuration & Provisioning MODEL Specify a program INTERPRETER IMPLEMENT S METAMODEL Provision Real-time CORBA ORBs QoS policies via XML Generates INTERPRETATION REFLECT S Approach: Develop a QoS Modeling Language (QoSPML) w/GME that can synthesize XML descriptors that provision Real-time CORBA QoS policies

20. Model-Driven Development 20 Overview of QoSPML Allows the configuration of Real-time CCM QoS policies in DRE systems Configurable features: Thread pool model Connection model Priority propagation model Create QoS models Constraints used to assure correctness of models Synthesize XML configuration data via QoSPML model interpreter XML configurations fed into Deployment & Configuration (DAnCE) runtime to configure QoS properties automatically

21. Model-Driven Development 21 C3: Specify Behavior for Emulated Components Context People implementing a SOA application might come from different disciplines –e.g., software architects, developers, & systems engineers CUTS users may not be familiar with 3 rd generation or configuration languages –e.g., C++ & Java or XML, respectively Problem Providing alternative methods to programming CoWorkEr behavior & creating dense configuration files use?

22. Model-Driven Development 22 Solution: Use Domain–Specific Modeling Language to Program CoWorkEr Behavior Workload Modeling Language (WML) is used to define the behavior of CoWorkEr components

23. Model-Driven Development 23 Workload Modeling Language (WML) is used to define the behavior of CoWorkEr components WML events represent different types of workloads in CoWorkEr Startup workload Event-driven workload Solution: Use Domain–Specific Modeling Language to Program CoWorkEr Behavior

24. Model-Driven Development 24 Workload Modeling Language (WML) is used to define the behavior of CoWorkEr components WML events represent different types of workloads in CoWorkEr Actions are attached to events & specified in order of execution to define workload strings –Each action has attributes, e.g., number of repetitions, amount of memory to allocate & etc Attributes for CPUAction Workload string Solution: Use Domain–Specific Modeling Language to Program CoWorkEr Behavior

25. Model-Driven Development 25 Workload Modeling Language (WML) is used to define the behavior of CoWorkEr components WML events represent different types of workloads in CoWorkEr Actions are attached to events & specified in order of execution to define workload strings –Each action has attributes, e.g., number of repetitions, amount of memory to allocate & etc WML is interpreted to XML characterization files Characterization specified in CoWorkEr Solution: Use Domain–Specific Modeling Language to Program CoWorkEr Behavior

26. Model-Driven Development 26 C4: Using XML as Configuration Language Using XML to configure QoS policies and to define emulated component behavior declaratively leads to the following problems: Expressive, but hard to read manually Schema-based element hierarchy, but flat document structure Highly verbose, lack of intuitive domain relationship Single typo can compromise document structure and cause parser failure Modification of configuration data is very cumbersome XML

27. Model-Driven Development 27 MDD Solution: Bypass XML Accidental Complexities Using MDD technologies solves the problem by: Allowing you to concentrate on the domain specific goal and ignore the means used to achieve it Bypass XML coding by raising the level of abstraction and substitute it with visual modeling tools Automate the generation of XML Utilize constraint checking facility of modeling framework to ensure the correctness of the visual models Ensure the correctness of the XML by verifying the correctness of the interpreter

28. Model-Driven Development 28 C5: Managing & Refining System Configuration Space Managing large scale hand-coded system configurations Hand-coding leads to track- able but hard to examine configurations Uncovered weak design points are tedious and error-prone to remedy Refining system QoS properties Changing functional requirements Deeper domain understanding Uncovered weak design points

29. Model-Driven Development 29 Using MDD techniques to Manage & Refine System Configuration Space High-level models enable the quick and seamless examination of the overall system configuration Shield developers from the accidental complexities of the evolving configuration space Evolution based on high-level models, not the actual configuration artifact Automatically regenerate the configuration metadata every time a change has been made Create/Modify Model (Re)Interpret Model (Re)Configure Application

30. Model-Driven Development 30 Observed Benefits Using highly-configurable component middleware such as CIAO enhances software development and productivity. Unfortunately, it also introduces new complexities. Using DSMLs technologies expedites application development and QoS evaluation by providing proper integration and tuning of MDD tools with the underlying component middleware infrastructure Create/Modify Model (Re)Interpret Model (Re)Configure Application

31. Model-Driven Development 31 Observed Benefits META-MODELMETA-MODEL INTERPRETERINTERPRETER MODELMODEL INTERPRETATIONINTERPRETATION Specifies Provides Interpretation reflectsreflects implementsimplements QoSPML and WML DSMLs complements each other in various ways QoSPML and WML can reduce the learning curve for the end users Despite the fact that QoSPML facilitates QoS configuration, we are still faced with the question of what constitutes a “good” configuration Although MDD tools remove many complexities associated with handcrafted solutions, developers are still faced with the challenge of evolving existing models when the respective domain evolves

32. Model-Driven Development 32 Concluding Remarks The QoSPML and WML DSMLs have been integrated in the Component Synthesis with Model Integrated Computing (CoSMIC) tool chain available at: http://www.dre.vanderbilt.edu/cosmic/ The Component Integrated ACE ORB (CIAO) can be downloaded from www.dre.vanderbilt.edu/CIAO/ www.dre.vanderbilt.edu/CIAO/ For more information on CUTS please check: www.cs.wustl.edu/~schmidt/PDF/CUTS.pdf www.cs.wustl.edu/~schmidt/PDF/CUTS.pdf

33. Model-Driven Development 33 Any Questions

34. Domain-Specific Modeling Languages for Configuring and Evaluating Enterprise DRE System Quality of Service Stoyan Paunov, James Hill & Douglas Schmidt Vanderbilt University, Nashville, TN Steven D. Baker and John M. Slaby Raytheon Company, Portsmouth, RI ECBS 2006, Potsdam, Germany

35. Model-Driven Development 35 Addressing the Complexities of Serialized Phasing Use model-driven development tools to simplify the: Emulation of application component behavior in terms of computations, database activities, memory accesses, and network communication. Configuration, deployment, and execution of these emulated application components atop actual infrastructure component deployments and configurations to determine their impact on QoS empirically in actual run­time environments. Process of feeding back the results to enhance system architectures and components to improve QoS.

36. Model-Driven Development 36 Challenges Ensuring the right granularity of QoS Using the standard RT CORBA API to configure QoS policies Specifying behavior of emulated application components to test the infrastructure Using XML metadata to configure components for QoS and to define behavioral components Managing large scale system configurations Problems of imperative configuration and/or XML-based configuration Refining system QoS properties Changing functional requirements Deeper domain understanding Uncovered weak design points