Patterns, Frameworks, Middleware, Patterns, Frameworks, Middleware, & Modeling: & Modeling: Their Synergistic Relationships Their Synergistic Relationships Douglas C. Schmidt [email protected]Professor of EECS Vanderbilt University Nashville, Tennessee
65
Embed
Patterns, Frameworks, Middleware, & Modeling: Their Synergistic Relationships
Patterns, Frameworks, Middleware, & Modeling: Their Synergistic Relationships. Douglas C. Schmidt [email protected] Professor of EECS Vanderbilt University Nashville, Tennessee. Why We are Succeeding. The maturation of middleware standards. - PowerPoint PPT Presentation
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
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
Motivation•Individual patterns & pattern catalogs are insufficient
•Software modeling methods & tools largely just illustrate how – not why – systems are designed
21
Taxonomy of Patterns & Idioms
Type Description Examples
Idioms Restricted to a particular language, system, or tool
Scoped locking
Design patterns
Capture the static & dynamic roles & relationships in solutions that occur repeatedly
Active Object, Bridge, Proxy, Wrapper Façade, & Visitor
Architectural patterns
Express a fundamental structural organization for software systems that provide a set of predefined subsystems, specify their relationships, & include the rules and guidelines for organizing the relationships between them
• Apply the Publisher-Subscriber architectural pattern to distribute periodic, I/O-drivendata from a single point of source to a collection of consumers
Ensuring Platform-neutral & Network-transparent Communication
operation (params)connect
send_requestmarshal
unmarshal
dispatchoperation (params)
resultmarshalreceive_repl
yunmarshal
result
start_upregister_serviceassigned port
Dynamics
: Broker: Client Proxy : Server Proxy: Client : Server
Context Problems Solution
•Mission computing requires remote IPC
• Stringent DRE requirements
• Applications need capabilities to:•Support remote communication•Provide location transparency•Handle faults•Manage end-to-end QoS•Encapsulate low-level system details
• Apply the Broker architectural pattern to provide platform-neutral communication between mission computing boards
33
Applying the Broker Pattern to Bold Stroke
Board 1
VME
1553
1: Sensors generate data
Board 2
2: I/O via interrupts
5: Event Channel pushes events to subscribers(s)
6: Subscribers perform avionics operations
GPS IFF FLIR
HUD Nav WTS Air Frame
Publishers
Subscribers
push(event)
push(event)
Event Channel
4: Sensor publishers push events to event channel
Bold Stroke uses the Broker pattern to shield distributed applications from environment heterogeneity, e.g., • Programming languages• Operating systems• Networking protocols• Hardware
3: Broker handles I/O via upcalls
Broker
A key consideration for implementing the Broker pattern for mission computing applications is QoS support
• e.g., latency, jitter, priority preservation, dependability, security, etc.
CaveatThese patterns are very useful, but
having to implement them from scratch is tedious & error-prone!!!
34
Overview of Frameworks
Framework Characteristics
Application-specific functionality
•Frameworks exhibit “inversion of control” at runtime via callbacks
Networking Database
GUI
•Frameworks provide integrated domain-specific structures & functionality
Mission Computing E-commerce
ScientificVisualization
•Frameworks are “semi-complete” applications
35
Comparing Class Libraries, Frameworks, & Components
Class Libraries
Frameworks
Macro-levelMeso-levelMicro-level
Borrow caller’s thread
Inversion of control
Borrow caller’s thread
Domain-specific or Domain-independent
Domain-specific
Domain-independent
Stand-alone composition
entities
“Semi-complete”
applications
Stand-alone language entities
Components
Class Library Architecture
ADTs
Strings
LocksIPC
Math
LOCAL INVOCATIONSAPPLICATION-
SPECIFICFUNCTIONALITY
EVENTLOOP
GLUECODE
Files
GUI
A class is a unit of abstraction & implementation in an OO
programming language
Framework Architecture
ADTs
Locks
Strings
Files
INVOKES
A framework is an integrated set of classes that collaborate to produce a reusable architecture for a family of applications
Reactor
GUI
DATABASE
NETWORKING
APPLICATION-SPECIFIC FUNCTIONALITY CALLBACKS
Middleware Bus
Component Architecture
A component is an encapsulation unit with one or more interfaces that provide
clients with access to its services
Naming
LockingLogging
Events
36
Using Frameworks Effectively
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
Successful projects are therefore often
organized using the “funnel” model
37
Overview of the ACE Frameworks
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
Acceptor Connector Component
Configurator
Stream
Reactor Proactor
Task
Application-specific
functionality
Local AreaNetwork
NYSE
NASDAQ
38
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
The POSA2 Pattern Language
39
Implementing the Broker Pattern for Bold Stroke Avionics
• CORBA is a distribution middleware standard
• Real-time CORBA adds QoS to classic CORBA to control:
www.omg.org
3. Memory Resources
•These capabilities address some (but by no means all) important DRE application development & QoS-enforcement challenges
2. Communication Resources
ProtocolProperties
Explicit Binding
Client Propagation & Server Declared Priority Models
Portable Priorities
Thread Pools
Static Scheduling Service
StandardSynchonizers 1. Processor Resources
Request Buffering
40
Applying Patterns & Framworks to Middleware: The ACE ORB (TAO)
www.cs.wustl.edu/~schmidt/TAO.html
• 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
41
Key Patterns Used in TAOwww.cs.wustl.edu/~schmidt/PDF/ORB-patterns.pdf
• Wrapper facades enhance portability
• Proxies & adapters simplify client & server applications, respectively
• Concurrency strategies use Reactor & Leader/Followers
• Acceptor-Connector decouples connection management from request processing
• Managers optimize request demultiplexing
42
Enhancing ORB Flexibility w/the Strategy Pattern
Context Problem Solution
•Multi-domain resuable middleware framework
• Flexible ORBs must support multiple event & request demuxing, scheduling, (de)marshaling, connection mgmt, request transfer, & concurrency policies
•Apply the Strategy pattern to factory out similarity amongst alternative ORB algorithms & policies
Hook for the concurrency strategy
Hook for the request demuxing strategy
Hook for marshaling strategy
Hook for the connection management strategy
Hook for the underlying transport strategy
Hook for the event demuxing strategy
43
Consolidating Strategies with the Abstract Factory Pattern
Context Problem Solution
•A heavily strategized framework or application
•Aggressive use of Strategy pattern creates a configuration nightmare•Managing many individual strategies is hard• It’s hard to ensure that groups of semantically compatible strategies are configured
•Apply the Abstract Factory pattern to consolidate multiple ORB strategies into semantically compatible configurations
•Prematurely commiting to a particular ORB configuration is inflexible & inefficient•Certain decisions can’t be made until runtime•Forcing users to pay for components that don’t use is undesirable
•Apply the Component Configurator pattern to assemble the desired ORB factories (& thus strategies) dynamically
• ORB strategies are decoupled from when the strategy implementations are configured into an ORB
• This pattern can reduce the memory footprint of an ORB
45
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
46
Summary of Pattern, Framework, & Middleware Synergies
The technologies codify expertise of experienced researchers & developers
• Patterns codify expertise in the form of reusable architecture design themes & styles, which can be reused event when algorithms, components implementations, or frameworks cannot
• Frameworks codify expertise in the form of reusable algorithms, component implementations, & extensible architectures
Application-specific functionality
Acceptor Connecto
rComponentConfigurator
Stream
Reactor
Proactor
Task
• 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
There are now powerful feedback loops advancing these technologies
47
The Evolution of DRE Systems
• Stringent quality of service (QoS) demands• e.g., latency, jitter, footprint
• Resource constrained
• Stringent quality of service (QoS) demands• e.g., latency, jitter, footprint
• Resource constrained
The Past
• Network-centric & larger-scale• Stringent simultaneous quality of service (QoS) demands• e.g., availability, security, throughput, scalability
• Part of larger systems• Dynamic context
• Network-centric & larger-scale• Stringent simultaneous quality of service (QoS) demands• e.g., availability, security, throughput, scalability
• Part of larger systems• Dynamic context
The Future
48
Evolution of DRE System Development
Technology ProblemsDRE systems have
historically tended to be:StovepipedProprietary
Brittle & non-adaptiveExpensiveVulnerable
Historically, mission-critical DRE applications were built directly atop hardware
• Tedious• Error-prone• Costly over lifecycles
IOM
IOM
IOM
IOM
IOM
IOM
IOM
IOM
IOM
IOM
IOM
IOM
IOM
IOM
IOM
IOM
IOM
IOM
BSE
BSE
BSE
BSE
BSE
BSE
BSEBSE
BSE
AirFrame
AP
Nav HUD
GPS IFF
FLIR
Cyclic Exec
CLI
SS7
SM CM
RX TX
IP
RTOS
49
Technology ProblemsDRE systems have
historically tended to be:StovepipedProprietary
Brittle & non-adaptiveExpensiveVulnerable
Historically, mission-critical apps were built directly atop hardware
• Tedious• Error-prone• Costly over lifecycles
IOM
IOM
IOM
IOM
IOM
IOM
IOM
IOM
IOM
IOM
IOM
IOM
IOM
IOM
IOM
IOM
IOM
IOM
BSE
BSE
BSE
BSE
BSE
BSE
BSEBSE
BSE
Middleware
MiddlewareServices
DRE Applications
Operating Sys& Protocols
Hardware & Networks
Middleware
MiddlewareServices
DRE Applications
Operating Sys& Protocols
Hardware & Networks
•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
Evolution of DRE System Development
50
Recap of DRE Middleware Layers
Middleware Capabilities
•Services specific to application domains e.g., Syngo (Med), Bold Stroke (Avionics), AMW (telecom)
• 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
PROBLEMSXML file in excess of 3,000 lines, even for medium sized scenarios
Existing practices involve handcrafting the XML descriptors
No standard means for distribution & deployment Distribution &
deployment done in ad hoc manner
XML is hard for systems engineers & domain experts to understand
Challenge 1: Component Assembly & Deployment
56
• 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
SOLUTION
Challenge 1: Component Assembly & Deployment
57
Next StepsDevelop a component descriptor modeling language (CDML)
Synthesize assembly descriptor metadata
Synthesize platform-specific metadata
Synthesizecustom strategiese.g., lazy or eager
Determine appropriate assembly & deployment
Challenge 1: Component Assembly & Deployment
58
Challenge 2: Configuring Container Policies
• 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
TIMER20Hz
GPS
TIMER1 Hz
PILOTCONTROL
NAV DISP
TIMER5 Hz
NAVIG-ATOR
Highpriority
Mediumpriority
Lowpriority
CONTEXT
59
ServerComponent Management Middleware
• Existing techniques for metadata configurations rely on ad hoc manual configurations e.g., CORBA or J2EE server-side programming
PROBLEMS
Determine the server object management policies
Determine right buffer sizes
Determine thread pool sizes; how are they shared; number of lanes and their priorities; if borrowing is enabled
Determine various middleware policies for server objects e.g., security, lifetime, replication
•This “glue code” is traditionally handcrafted
Ensure semantic compatibility among chosen configurations
Determine end-to-end priority propagation model to use
Challenge 2: Configuring Container Policies
60
• 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)
SOLUTION
Challenge 2: Configuring Container Policies
61
TIMER20Hz
GPS
NAV DISP
Highpriority
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
Server Component
Management Middleware
Challenge 2: Configuring Container Policies
62
Challenge 3: Configuring Middleware End-to-End
I/O Subsystem
M/WBus
SkeletonStub
20 10 5 1 20 10 5 1
•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
NAV DISPGPS NAVSTEERING
PILOTCONTROL
CONTEXT
63
I/O Subsystem
M/W Bus
SkeletonStub
20 10 5 1 20 10 5 1
PROBLEMSDetermine right concurrency strategy
Determine right demuxing strategy
Determine right marshaling optimizations
Determine right connection management policy
Configuring subset of underlying transports
•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
Challenge 3: Configuring Middleware End-to-End
64
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
Challenge 3: Configuring Middleware End-to-End
65
TIMER20Hz
GPS
NAV DISP
Highpriority
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
Challenge 3: Configuring Middleware End-to-End
66
Challenge 4: End-to-end QoS Enforcement
QoSSystemic Path
Operating System
Middleware
SysCondition
Mechanism & PropertiesManager
Applications
Operating System
CONTEXT
Appln Server Appln ServerStatic configuration
Need to provide runtime QoS adaptation along functional path
Made feasible using adaptive & reflective middleware
PROBLEMS Glue code depends on the adaptive & reflective middleware used
Most existing middleware not designed to collect & distribute QoS metadata
Need to retrofit middleware to collect & distribute desired QoS metadata
Need to add instrumentation code to collect QoS metadata
Instrumentation code manually handcrafted
Challenge 4: End-to-end QoS Enforcement
68
SOLUTION
MiddlewareModels
IntegratedModels
QoS Metadata
model
Program Transformation
Tool
Language-specificQoS aspects
generator
Middleware
Applications
Operating System
Interceptor
Endsystem
LocalResourceManage-
ment
Infrastructure Middleware
Distribution Middleware
Common Services
Domain-Specific Services
Challenge 4: End-to-end QoS Enforcement
69
Middleware
Applications
Operating System
Interceptor
Endsystem
LocalResourceManage-
ment
Infrastructure Middleware
Distribution Middleware
Common Services
Domain-Specific Services
Next Steps
MiddlewareModels
IntegratedModels
QoS Metadata
model
Program Transformation
Tool
Language-specificQoS aspects
generator
Domain specific modeling language for QoS metadata
Domain specific modeling language for middleware models
Develop model weaver
Develop generators
Challenge 4: End-to-end QoS Enforcement
70
Research Impact & Future Work
Current progress stems from years of iteration, refinement, & successful use
Year1970 2010
Internet
RPC
Micro-kernels
CORBA & DCOM
Real-time (RT)CORBA
Component Models (EJB)
CORBA ComponentModel (CCM)
RT/CCM
DCE
CoSMIC
Long-term Research Directions•High confidence, geographically distributed DRE systems
•Grid applications•Large enterprise systems•Greater focus on platform-independent models
Long-term Research Directions•High confidence, geographically distributed DRE systems
•Grid applications•Large enterprise systems•Greater focus on platform-independent models
Model drivenmiddleware Shape the standards e.g., OMG’s
Model Driven Architecture (MDA) for DRE systems
Advanced MDA
ACE+TAO
2000 2005
71
Concluding Remarks
Model, analyze, synthesize, & provision middleware technologies at multiple layers for distributed real-time & embedded (DRE) systems that require simultaneous control of multiple quality of service properties end-to-end