Patterns, Frameworks, Middleware, & Modeling: Their Synergistic Relationships

1. Patterns, Frameworks, Middleware, & Modeling:Their Synergistic Relationships Douglas C. Schmidt d.schmidt@vanderbilt.edu Professor of EECS Vanderbilt University Nashville, Tennessee

2. Why We are Succeeding • The maturation of middleware standards • Years of iteration, refinement, & successful use • The maturation of component middleware frameworks & patterns Real-time CCM Applications Web Services Domain-Specific Services CORBA Component Model (CCM) Common Services Component Models (EJB) Distribution Middleware Real-time CORBA Host Infrastructure Middleware CORBA & DCOM Operating Systems & Protocols DCE Hardware Micro-kernels • NET, J2EE, CCM • Real-time CORBA • Real-time Java • SOAP & Web Services RPC ARPAnet 1970 Year 2005 The past decade has yielded significant progress in QoS-enabled middleware, stemming in large part from the following trends:

3. Overview of Patterns • Present solutions to common software problems arising within a certain context • Help resolve key software design forces • Flexibility • Extensibility • Dependability • Predictability • Scalability • Efficiency Client Proxy Service AbstractService service service service • Capture recurring structures & dynamics among software participants to facilitate reuse of successful designs • Generally codify expert knowledge of design strategies, constraints & “best practices” 1 1 The Proxy Pattern

4. Overview of Pattern Languages • Motivation • Individual patterns & pattern catalogs are insufficient • Software modeling methods & tools largely just illustrate how – not why – systems are designed • Benefits of Pattern Languages • Define a vocabulary for talking about software development problems • Provide a process for the orderly resolution of these problems • Help to generate & reuse software architectures

5. Taxonomy of Patterns & Idioms

6. Example: Boeing Bold Stroke Bold Stroke Architecture Middleware Infrastructure Mission Computing Services Operating System Networking Interfaces Hardware (CPU, Memory, I/O) • Avionics mission computing product-line architecture for Boeing military aircraft, e.g., F-18 E/F, 15E, Harrier, UCAV • DRE system with 100+ developers, 3,000+ software components, 3-5 million lines of C++ code • Based on COTS hardware, networks, operating systems, & middleware • Used as Open Experimention Platform (OEP) for DARPA IXO PCES, MoBIES, SEC, MICA programs Data Links Vehicle Mgmt Mission Computer Nav Sensors Radar Weapon Management Weapons

7. Example: Boeing Bold Stroke Middleware Infrastructure Mission Computing Services Operating System Networking Interfaces Hardware (CPU, Memory, I/O) • COTS & Standards-based Middleware Infrastructure, OS, Network, & Hardware Platform • Real-time CORBA middleware services • VxWorks operating system • VME, 1553, & Link16 • PowerPC

8. Example: Boeing Bold Stroke Middleware Infrastructure Mission Computing Services Operating System Networking Interfaces Hardware (CPU, Memory, I/O) • Reusable Object-Oriented Application Domain-specificMiddleware Framework • Configurable to variable infrastructure configurations • Supports systematic reuse of mission computing functionality

9. Example: Boeing Bold Stroke Middleware Infrastructure Mission Computing Services Operating System Networking Interfaces Hardware (CPU, Memory, I/O) • Product Line Component Model • Configurable for product-specific functionality & execution environment • Single component development policies • Standard component packaging mechanisms

10. Example: Boeing Bold Stroke Middleware Infrastructure Mission Computing Services Operating System Networking Interfaces Hardware (CPU, Memory, I/O) Operator • Component Integration Model • Configurable for product-specific component assembly & deployment environments • Model-based component integration policies Push Control Flow Real World Model Pull Data Flow Avionics Interfaces Infrastructure Services

11. Legacy Avionics Architectures • Key System Characteristics • Hard & soft real-time deadlines • ~20-40 Hz • Low latency & jitter between boards • ~100 usecs • Periodic & aperiodic processing • Complex dependencies • Continuous platform upgrades 4: Mission functions perform avionics operations • Avionics Mission Computing Functions • Weapons targeting systems (WTS) • Airframe & navigation (Nav) • Sensor control (GPS, IFF, FLIR) • Heads-up display (HUD) • Auto-pilot (AP) 3: Sensor proxies process data & pass to missions functions 2: I/O via interrupts 1: Sensors generate data Board 1 1553 VME Board 2

12. Legacy Avionics Architectures Air Frame Nav WTS AP FLIR GPS IFF Cyclic Exec • Limitations with Legacy Avionics Architectures • Stovepiped • Proprietary • Expensive • Vulnerable • Tightly coupled • Hard to schedule • Brittle & non-adaptive • Key System Characteristics • Hard & soft real-time deadlines • ~20-40 Hz • Low latency & jitter between boards • ~100 usecs • Periodic & aperiodic processing • Complex dependencies • Continuous platform upgrades 4: Mission functions perform avionics operations 3: Sensor proxies process data & pass to missions functions 2: I/O via interrupts 1: Sensors generate data Board 1 1553 VME Board 2

13. Decoupling Avionics Components Subscriber Filter filterEvent consume Event Structure Dynamics consume Publisher Event Channel : Publisher : Event Channel : Subscriber attachPublisher detachPublisher attachSubscriber detachSubscriber pushEvent produce attachSubscriber produce : Event pushEvent event pushEvent creates receives event * detachSubscriber

14. Applying the Publisher-Subscriber Pattern to Bold Stroke • Bold Stroke uses the Publisher-Subscriber pattern to decouple sensor processing from mission computing operations • Anonymous publisher & subscriber relationships • Group communication • Asynchrony 5: Subscribers perform avionics operations Subscribers HUD WTS Air Frame Nav 4: Event Channel pushes events to subscribers(s) push(event) Event Channel 3: Sensor publishers push events to event channel push(event) • Considerations for implementing the Publisher-Subscriber pattern for mission computing applications include: • Event notification model • Push control vs. pull data interactions • Scheduling & synchronization strategies • e.g., priority-based dispatching & preemption • Event dependency management • e.g.,filtering & correlation mechanisms GPS IFF FLIR Publishers 2: I/O via interrupts 1: Sensors generate data Board 1 1553 VME Board 2

15. Ensuring Platform-neutral & Network-transparent Communication Server Proxy Client Proxy marshal unmarshal dispatch receive_request marshal unmarhal receive_result service_p Structure Broker 1 1 * * calls * message exchange main_loop srv_registration srv_lookup xmit_message manage_QoS message exchange calls * 1 1 Server Client start_up main_loop service_i call_service_p start_task

16. Ensuring Platform-neutral & Network-transparent Communication : Client : Server : Server Proxy : Client Proxy : Broker register_service start_up operation (params) connect assigned port marshal send_request Dynamics unmarshal dispatch operation (params) result receive_reply marshal unmarshal result

17. Applying the Broker Pattern to Bold Stroke 6: Subscribers perform avionics operations • Bold Stroke uses the Broker pattern to shield distributed applications from environment heterogeneity, e.g., • Programming languages • Operating systems • Networking protocols • Hardware Subscribers HUD WTS Nav Air Frame 5: Event Channel pushes events to subscribers(s) push(event) Event Channel 4: Sensor publishers push events to event channel push(event) GPS IFF FLIR • A key consideration for implementing the Broker pattern for mission computing applications is QoS support • e.g., latency, jitter, priority preservation, dependability, security, etc. Publishers 3: Broker handles I/O via upcalls Broker 2: I/O via interrupts 1: Sensors generate data Board 1 1553 Caveat These patterns are very useful, but having to implement them from scratch is tedious & error-prone!!! VME Board 2

18. Overview of Frameworks • Frameworks exhibit “inversion of control” at runtime via callbacks • Frameworks provide integrated domain-specific structures & functionality • Frameworks are “semi-complete” applications Application-specific functionality Scientific Visualization Mission Computing E-commerce GUI Networking Database Framework Characteristics

19. Comparing Class Libraries, Frameworks, & Components Component Architecture Class Library Architecture LOCAL INVOCATIONS APPLICATION- SPECIFIC FUNCTIONALITY Math ADTs Naming Files Events Strings GUI GLUE CODE EVENT LOOP Locks IPC Logging Locking A class is a unit of abstraction & implementation in an OO programming language A component is an encapsulation unit with one or more interfaces that provide clients with access to its services Framework Architecture Class Libraries Frameworks Components NETWORKING Reactor ADTs Micro-level Meso-level Macro-level Strings APPLICATION-SPECIFIC FUNCTIONALITY INVOKES Stand-alone language entities “Semi-complete” applications Stand-alone composition entities GUI CALLBACKS Files Middleware Bus Locks Domain-independent Domain-specific Domain-specific or Domain-independent DATABASE A framework is an integrated set of classes that collaborate to produce a reusable architecture for a family of applications Borrow caller’s thread Inversion of control Borrow caller’s thread

20. Using Frameworks Effectively Successful projects are therefore often organized using the “funnel” model • Observations • Frameworks are powerful, but hard to develop & use effectively by application developers • It’s often better to use & customize COTS frameworks than to develop in-house frameworks • Components are easier for application developers to use, but aren’t as powerful or flexible as frameworks

21. Overview of the ACE Frameworks Application- specific functionality Stream Acceptor Connector Component Configurator Task Reactor Proactor • Features • Open-source • 6+ integrated frameworks • 250,000+ lines of C++ • 40+ person-years of effort • Ported to Windows, UNIX, & real-time operating systems • e.g., VxWorks, pSoS, LynxOS, Chorus, QNX • Large user community • www.cs.wustl.edu/~schmidt/ACE.html

22. The POSA2 Pattern Language • Pattern Benefits • Preserve crucial design information used by applications & middleware frameworks & components • Facilitate reuse of proven software designs & architectures • Guide design choices for application developers

23. Implementing the Broker Pattern for Bold Stroke Avionics Client Propagation & Server Declared Priority Models Static Scheduling Service Standard Synchonizers Explicit Binding Thread Pools Portable Priorities Protocol Properties • CORBA is a distribution middleware standard • Real-time CORBA adds QoS to classic CORBA to control: • 1. Processor Resources Request Buffering 2. Communication Resources • 3. Memory Resources • These capabilities address some (but by no means all) important DRE application development & QoS-enforcement challenges www.omg.org

24. Applying Patterns & Framworks to Middleware:The ACE ORB (TAO) • TAO is an open-source version of Real-time CORBA • TAO Synopsis • > 1,000,000 SLOC • 80+ person years of effort • Pioneered R&D on DRE middleware design, patterns, frameworks, & optimizations • TAO is basis for many middleware R&D efforts • Example of good synergy between researchers & practitioners www.cs.wustl.edu/~schmidt/TAO.html

25. Key Patterns Used in TAO www.cs.wustl.edu/~schmidt/PDF/ORB-patterns.pdf • Wrapper facades enhance portability • Proxies & adapters simplify client & server applications, respectively • Component Configurator dynamically configures Factories • Factories produce Strategies • Strategies implement interchangeable policies • Concurrency strategies use Reactor & Leader/Followers • Acceptor-Connector decouples connection management from request processing • Managers optimize request demultiplexing

26. Enhancing ORB Flexibility w/the Strategy Pattern Hook for marshaling strategy Hook for the request demuxing strategy Hook for the event demuxing strategy Hook for the connection management strategy Hook for the concurrency strategy Hook for the underlying transport strategy

27. Consolidating Strategies with the Abstract Factory Pattern Concrete factories create groups of strategies

28. Dynamically Configuring Factories w/the Component Configurator Pattern • ORB strategies are decoupled from when the strategy implementations are configured into an ORB • This pattern can reduce the memory footprint of an ORB

29. ACE Frameworks Used in TAO • Reactor drives the ORB event loop • Implements the Reactor & Leader/Followers patterns • Acceptor-Connector decouples passive/active connection roles from GIOP request processing • Implements the Acceptor-Connector & Strategy patterns • Service Configurator dynamically configures ORB strategies • Implements the Component Configurator & Abstract Factory patterns

30. Summary of Pattern, Framework, & Middleware Synergies • Frameworks codify expertise in the form of reusable algorithms, component implementations, & extensible architectures • Patterns codify expertise in the form of reusable architecture design themes & styles, which can be reused event when algorithms, components implementations, or frameworks cannot • Middleware codifies expertise in the form of standard interfaces & components that provide applications with a simpler façade to access the powerful (& complex) capabilities of frameworks Application-specific functionality Stream Acceptor Connector Component Configurator Task Reactor Proactor The technologies codify expertise of experienced researchers & developers There are now powerful feedback loops advancing these technologies

31. The Evolution of DRE Systems The Future • Network-centric & larger-scale • Stringent simultaneous quality of service (QoS) demands • e.g., availability, security, throughput, scalability • Part of larger systems • Dynamic context The Past • Stringent quality of service (QoS) demands • e.g., latency, jitter, footprint • Resourceconstrained

32. Evolution of DRE System Development BSE IOM BSE BSE IOM IOM IOM IOM IOM CLI IOM BSE BSE BSE IOM SM CM IOM IOM SS7 IP IOM IOM RX TX IOM BSE BSE BSE IOM IOM IOM RTOS IOM IOM Technology Problems DRE systems have historically tended to be: Stovepiped Proprietary Brittle & non-adaptive Expensive Vulnerable Air Frame Nav HUD AP FLIR GPS IFF Cyclic Exec • Historically, mission-critical DRE applications were built directly atop hardware • Tedious • Error-prone • Costly over lifecycles

33. Evolution of DRE System Development BSE IOM BSE BSE IOM IOM IOM IOM IOM IOM BSE BSE BSE IOM IOM IOM DRE Applications DRE Applications IOM IOM IOM BSE BSE BSE IOM Middleware Services Middleware Services IOM IOM IOM IOM Middleware Middleware Operating Sys & Protocols Operating Sys & Protocols Hardware & Networks Hardware & Networks Technology Problems DRE systems have historically tended to be: Stovepiped Proprietary Brittle & non-adaptive Expensive Vulnerable • Middleware has effectively factored out many reusable mechanisms & services from what was traditionally DRE application responsibility • Middleware is no longer primary DRE system performance bottleneck • Historically, mission-critical apps were built directly atop hardware • Tedious • Error-prone • Costly over lifecycles

34. Recap of DRE Middleware Layers DRE Applications Middleware Services Middleware Operating Sys & Protocols Hardware & Networks • Middleware Capabilities • Services specific to application domains e.g., Syngo (Med), Bold Stroke (Avionics), AMW (telecom) • Common higher-level services e.g., naming, notifications, fault tolerance, transactions, load balancing • Distribution capabilities like location transparency, data marshaling e.g., COM+, CORBA, RMI • Uniform abstraction over hardware, OS, & network protocols, e.g., JVM, ACE Hi Level of Abstraction Lo

35. DRE Systems: The Challenges Ahead CORBA Apps J2EE Apps .NET Apps CORBA Services J2EE Services .NET Services Load Balancer FT CORBA Workload & Replicas CORBA J2EE .NET Connections & priority bands RT/DP CORBA + DRTSJ RTOS + RT Java CPU & memory Network latency & bandwidth IntServ + Diffserv • There is a limit to how much application functionality can be factored into broadly reusable COTS middleware • System infrastructure has become extremely complicated to use, configure, & provision statically & dynamically • There are now multiple middleware technologies to choose from DRE Applications Middleware Services Middleware Operating Sys & Protocols Hardware & Networks

36. Promising Approach:Model DrivenMiddleware DRE Applications Middleware Services Middleware Operating Sys & Protocols Hardware & Networks Distributed system Solution approach: Integrate model-based software technologies with QoS-enabled component middleware • e.g., standard technologies are emerging that can: • Model • Analyze • Synthesize & optimize • Provision & deploy • multiple layers of QoS-enabled middleware & applications • These technologies are guided by patterns & implemented by component frameworks • Partial specialization is essential for inter-/intra-layer optimization <CONFIGURATION_PASS> <HOME> <…> <COMPONENT> <ID> <…></ID> <EVENT_SUPPLIER> <…events this component supplies…> </EVENT_SUPPLIER> </COMPONENT> </HOME> </CONFIGURATION_PASS> Goal is not to replace programmers per se – it is to provide higher-level domain-specific languages for middleware developers & users

37. Model Driven Middleware R&D Thrusts … Requested QoS … … Control Algorithm Control Algorithm Measured QoS Workload & Replicas } Container Control Vars. Connections & priority bands CPU & memory Network latency & bandwidth Middleware Bus Replication Security Persistence Notification • The end-to-end deployment aspect of DRE applications • The component container configuration aspect • The middleware configuration aspect • The dynamic QoS provisioning & adaptation aspect Applying MDA to address

38. Challenge 1: Component Assembly & Deployment CONTEXT • Application components need to be assembled & then deployed in a way that provides optimum resource utilization & delivers required QoS to the DRE application • e.g., existing DRE systems involve assembling & deploying hundreds of components • Assembly & deployment are increasingly defined using XML descriptors & deployment tools

39. Challenge 1: Component Assembly & Deployment PROBLEMS XML file in excess of 3,000 lines, even for medium sized scenarios Existing practices involve handcrafting the XML descriptors <!– Associate components with impls --><componentfiles> <componentfile id=“RateGenerator"> <fileinarchive name=“HouseRateGen.csd"/> </componentfile> <componentfile id=“HiResGPS"> <fileinarchive name=“aGPS.csd"/> </componentfile> <componentfile id=“cockpitDisplay"> <fileinarchive name=“navDisplay-if.csd"/> </componentfile> </componentfiles> XML is hard for systems engineers & domain experts to understand No standard means for distribution & deployment Distribution & deployment done in ad hoc manner

40. Challenge 1: Component Assembly & Deployment SOLUTION • ESML developed by Dr. Gabor Karsai et. al at ISIS • CIDL compiler developed by our group at ISIS • A domain-specific Component Descriptor Modeling Language (CDML) • Currently leverages Embedded Systems Modeling Language (ESML) for synthesis of assembly descriptors • Analyze component requirements & synthesize XML deployment scripts • Synthesize component glue code to interact with environment

41. Synthesize custom strategies e.g., lazy or eager Challenge 1: Component Assembly & Deployment Next Steps Synthesize assembly descriptor metadata Develop a component descriptor modeling language (CDML) Synthesize platform-specific metadata Determine appropriate assembly & deployment

42. Challenge 2: Configuring Container Policies High priority Medium priority Low priority CONTEXT • Components execute in containers that decouple runtime configuration from the component implementation e.g., • Priority propagation models • Threading models • Security, replication, persistence policies • Internal buffer sizes • For example, avionics & vehitronics components run in a multithreaded environment with different end-to-end priorities • Increasingly specified by the deployer using XML-based metadata

43. Challenge 2: Configuring Container Policies Server Component Management Middleware PROBLEMS Determine various middleware policies for server objects e.g., security, lifetime, replication Determine thread pool sizes; how are they shared; number of lanes and their priorities; if borrowing is enabled • Existing techniques for metadata configurations rely on ad hoc manual configurations e.g., CORBA or J2EE server-side programming Determine right buffer sizes Determine end-to-end priority propagation model to use Determine the server object management policies Ensure semantic compatibility among chosen configurations • This “glue code” is traditionally handcrafted

44. Challenge 2: Configuring Container Policies SOLUTION • Develop a domain-specific Container Policy Modeling Language (CPML) • Current version restricted to container configuration glue code generation in the CORBA platform • Container policies are still manually chosen (today)

45. Challenge 2: Configuring Container Policies High priority Server Component Management Middleware Next Steps • Extend CPML to capture application QoS requirements in a platform independent form • Design model transformers to desired platforms • Develop tools that will determine the right values for various platform-specific parameters

46. Challenge 3: Configuring Middleware End-to-End Stub Skeleton 20 10 5 1 20 10 5 1 M/WBus I/O Subsystem CONTEXT • Middleware must be configured with the appropriate systemic metadata end-to-end • e.g., in avionics example, appropriate priority banded connections must be set between application services

47. Challenge 3: Configuring Middleware End-to-End Stub Skeleton 20 10 5 1 20 10 5 1 M/W Bus I/O Subsystem PROBLEMS Determine right marshaling optimizations Determine right concurrency strategy Determine right demuxing strategy Configuring subset of underlying transports Determine right connection management policy • Highly flexible middleware tend to provide numerous configuration knobs that can be configured to deliver required systemic properties to applications • Existing techniques of metadata configurations rely on ad hoc manual selection of configuration parameters

48. Challenge 3: Configuring Middleware End-to-End SOLUTION • Developed a domain-specific modeling language for TAO/CIAO called Options Configuration Modeling Language (OCML) • User provides a model of desired options & their values e.g., • Middleware bus resources • Concurrency & connection management strategies • Constraint checker flags incompatible options • Synthesizes XML descriptors for middleware configuration

49. Challenge 3: Configuring Middleware End-to-End High priority Next Steps • Extend OCML to capture application QoS requirements in a platform independent form • Design model transformers to synthesize platforms-specific configuration models • Design tools that will determine the right values for various platform-specific configuration parameters

50. Challenge 4: End-to-end QoS Enforcement Appln Server Appln Server Static configuration CONTEXT e.g., BBN QuO, UIUC Quarterware, Lancaster OpenORB Made feasible using adaptive & reflective middleware Need to provide runtime QoS adaptation along functional path