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 in the context of QoS-enabled SOA Middleware While creating target infrastructure 1.Define infrastructure specifications & requirements 2.Define the appropriate QoS infrastructure policies 3.Define emulated application specifications & requirements 4.Deploy the system based on the predefined design rules 5.Use analysis tools to evaluate & verify QoS performance 6.If necessary refine the system QoS policies & 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 Benefits of 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, QoS configuration artifacts Early feedback to developers, architects & systems engineers Instead of waiting for the completion of application components to conduct 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 Managing the accidental complexities of declarative configuration approaches based on XML Managing large scale system configurations Enable the evolution and refining of the system

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.Controlling 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 soft real-time processing of many tasks timely 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.Controlling 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 the core software logic

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

20. Model-Driven Development 20 Overview of QoSPML Allows the configuration of Real-time CCM QoS policies in DRE systems Configurable features: Thread pool policy model Connection policy model Priority propagation policy 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 programming 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 Accidental complexities of using XML to configure QoS policies and to define emulated component behavior declaratively: 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 The generated XML is correct as long as the interpreter is correct

28. Model-Driven Development 28 C5: Managing & Refining System Configuration Space Managing large scale hand-coded system configurations No easy way to examine the QoS configuration space Addressing weaknesses in the design is tedious and error- prone System evoluton 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 artifacts 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 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 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 the seamless QoS configuration, we are still faced with the question of what constitutes a “good” configuration META-MODELMETA-MODEL INTERPRETERINTERPRETER MODELMODEL INTERPRETATIONINTERPRETATION Specifies Provides Interpretation implementsimplements reflectsreflects

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