patterns, frameworks, middleware, & modeling: their synergistic relationships
DESCRIPTION
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 PresentationTRANSCRIPT
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
18
Why We are SucceedingThe past decade has yielded significant progress in QoS-enabled middleware, stemming in large part from the following trends:
• NET, J2EE, CCM• Real-time CORBA• Real-time Java• SOAP & Web Services
•The maturation of middleware standards
Hardware
Domain-SpecificServicesCommonServices
DistributionMiddleware
Host InfrastructureMiddleware
Operating Systems & Protocols
Applications
•Years of iteration, refinement, & successful use
Year1970 2005ARPAnet
RPC
Micro-kernels
CORBA & DCOM
Real-timeCORBA
Component Models (EJB)
CORBA ComponentModel (CCM)
Real-time CCM
DCE
Web Services
•The maturation of component middleware frameworks & patterns
19
•Present solutions to common software problems arising within a certain context
Overview of Patterns
•Capture recurring structures & dynamics among software participants to facilitate reuse of successful designs
The Proxy Pattern
1 1Proxy
service
Service
service
AbstractService
service
Client
•Help resolve key software design forces
•Flexibility•Extensibility•Dependability•Predictability•Scalability•Efficiency
•Generally codify expert knowledge of design strategies, constraints & “best practices”
20
Overview of Pattern Languages
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
Half-Sync/Half-Async, Layers, Proactor, Publisher-Subscriber, & Reactor
Optimization principle patterns
Document rules for avoiding common design & implementation mistakes that degrade performance
Optimize for common case, pass information between layers
22
Example: Boeing Bold StrokeNav Sensors
WeaponManagement
Data LinksMissionComputer
VehicleMgmt
Weapons
• 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
Bold Stroke Architecture
Hardware (CPU, Memory, I/O)Hardware (CPU, Memory, I/O)
Networking InterfacesNetworking Interfaces
Operating SystemOperating System
Middleware InfrastructureMiddleware Infrastructure
Mission Computing ServicesMission Computing Services
Radar
23
Hardware (CPU, Memory, I/O)Hardware (CPU, Memory, I/O)
Networking InterfacesNetworking Interfaces
Operating SystemOperating System
Middleware InfrastructureMiddleware Infrastructure
Mission Computing ServicesMission Computing Services
Example: Boeing Bold Stroke
COTS & Standards-based Middleware Infrastructure, OS, Network, & Hardware Platform• Real-time CORBA middleware services• VxWorks operating system• VME, 1553, & Link16• PowerPC
24
Example: Boeing Bold StrokeReusable Object-Oriented Application Domain-specific Middleware Framework • Configurable to variable infrastructure configurations
• Supports systematic reuse of mission computing functionality
Hardware (CPU, Memory, I/O)Hardware (CPU, Memory, I/O)
Networking InterfacesNetworking Interfaces
Operating SystemOperating System
Middleware InfrastructureMiddleware Infrastructure
Mission Computing ServicesMission Computing Services
25
Example: Boeing Bold Stroke
Product Line Component Model• Configurable for product-specific functionality
& execution environment• Single component development policies• Standard component packaging mechanisms
Hardware (CPU, Memory, I/O)Hardware (CPU, Memory, I/O)
Networking InterfacesNetworking Interfaces
Operating SystemOperating System
Middleware InfrastructureMiddleware Infrastructure
Mission Computing ServicesMission Computing Services
26
Hardware (CPU, Memory, I/O)Hardware (CPU, Memory, I/O)
Networking InterfacesNetworking Interfaces
Operating SystemOperating System
Middleware InfrastructureMiddleware Infrastructure
Mission Computing ServicesMission Computing Services
Example: Boeing Bold Stroke
Component Integration Model• Configurable for product-specific component assembly & deployment environments
• Model-based component integration policies
Avionics Interfaces
Operator
Real World Model
Infrastructure Services
27
Legacy Avionics Architectures
Board 1
VME
1553
1: Sensors generate data
Board 2
2: I/O via interrupts
3: Sensor proxies process data & pass to missions functions
4: Mission functions perform avionics operations
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
Avionics Mission Computing Functions•Weapons targeting systems (WTS)
•Airframe & navigation (Nav)
•Sensor control (GPS, IFF, FLIR)
•Heads-up display (HUD)
•Auto-pilot (AP)
28
Legacy Avionics Architectures
Board 1
VME
1553
1: Sensors generate data
Board 2
2: I/O via interrupts
3: Sensor proxies process data & pass to missions functions
4: Mission functions perform avionics operations
AirFrame
AP
Nav WTS
GPS IFF
FLIR
Cyclic ExecLimitations 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
29
Decoupling Avionics Components
Context Problems Solution
• I/O driven DRE application
•Complex dependencies
•Real-time constraints
• Tightly coupled components
•Hard to schedule
• Expensive to evolve
• Apply the Publisher-Subscriber architectural pattern to distribute periodic, I/O-drivendata from a single point of source to a collection of consumers
Event*
Subscriber
consume
creates receives
Event Channel
attachPublisher detachPublisherattachSubscriberdetachSubscriberpushEvent
Filter
filterEvent
Publisher
produce
Structure
attachSubscriber
produce
pushEventevent
eventpushEvent
consume
detachSubscriber
: Event
: Subscriber: Event Channel: Publisher
Dynamics
30
Applying the Publisher-Subscriber Pattern to Bold Stroke
Board 1
VME
1553
1: Sensors generate data
Board 2
2: I/O via interrupts
4: Event Channel pushes events to subscribers(s)
5: Subscribers perform avionics operations
GPS IFF FLIR
HUD
Nav
WTSAir
Frame
Publishers
Subscribers
push(event)
push(event)
Event Channel
3: Sensor publishers push events to event channel
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
Bold Stroke uses the Publisher-Subscriber pattern to decouple sensor processing from mission computing operations• Anonymous publisher & subscriber relationships
• Group communication
• Asynchrony
31
Ensuring Platform-neutral & Network-transparent Communication
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
message exchange
message exchange
*
marshalunmarhalreceive_resultservice_p
Client Proxy
calls*
*
call_service_pstart_task
Client
1
marshalunmarshaldispatchreceive_request
Server Proxy
calls*
start_upmain_loopservice_i
Server
1
1
main_loopsrv_registrationsrv_lookupxmit_messagemanage_QoS
Broker1
Structure
32
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
• 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
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
Concrete factories create groups of strategies
44
Dynamically Configuring Factories w/the Component Configurator Pattern
Context Problem Solution
•Resource constrained & highly dynamic environments
•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)
•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
Middleware
MiddlewareServices
DRE Applications
Operating Sys& Protocols
Hardware & Networks
Hi
Lo
Leve
l of
Abs
trac
tion
51
Middleware
MiddlewareServices
DRE Applications
Operating Sys& Protocols
Hardware & Networks
DRE Systems: The Challenges Ahead
•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
IntServ + Diffserv
RTOS + RT Java
RT/DP CORBA + DRTSJ
Load BalancerFT CORBA
Network latency & bandwidth
Workload & Replicas
CPU & memory
Connections & priority bands
CORBA
CORBAServices
CORBAApps
J2EE
J2EEServices
J2EEApps
.NET
.NETServices
.NETApps
52
•e.g., standard technologies are emerging that can:1. Model2. Analyze3. Synthesize & optimize4. 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
Promising Approach: Model Driven Middleware
Middleware
MiddlewareServices
DRE Applications
Operating Sys& Protocols
Hardware & Networks
<CONFIGURATION_PASS> <HOME> <…> <COMPONENT> <ID> <…></ID> <EVENT_SUPPLIER> <…events this component supplies…> </EVENT_SUPPLIER> </COMPONENT> </HOME></CONFIGURATION_PASS>
<CONFIGURATION_PASS> <HOME> <…> <COMPONENT> <ID> <…></ID> <EVENT_SUPPLIER> <…events this component supplies…> </EVENT_SUPPLIER> </COMPONENT> </HOME></CONFIGURATION_PASS>
Distributedsystem
Goal is not to replace programmers per se – it is to provide higher-level domain-specific languages for middleware developers & users
Solution approach: Integrate model-based software technologies with QoS-enabled component middleware
53
TIMER20Hz
GPS
NAV DISP
Model Driven Middleware R&D Thrusts
1.The end-to-end deployment aspect of DRE applications
2.The component container configuration aspect
3.The middleware configuration aspect
4.The dynamic QoS provisioning & adaptation aspect
…
Container
… …
Middleware Bus
SecurityReplication NotificationPersistence
Applying MDA to address
Network latency & bandwidth
Workload & Replicas
CPU & memory
Connections & priority bands
Control Vars.
}
ControlAlgorithmControlAlgorithm
Measured QoS
Requested QoS
54
Challenge 1: Component Assembly & Deployment
• 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
CONTEXT
TIMER20Hz
GPS NAV DISP
55
<!– 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>
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
e.g., BBN QuO, UIUC Quarterware, Lancaster OpenORB
67
QoSSystemic Path
Operating System
Middleware
SysCondition
Mechanism & PropertiesManager
Applications
Operating System
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
1. Configure & deploy DRE applications end-to-end
2. Configure application component containers
3. Synthesize middleware-specific configurations
4. Synthesize dynamic QoS provisioning & adaptation logic
Model Driven Approach to:
72
•Prior R&D efforts have address some, but by no means all, of the challenging DOC middleware research topics
Concluding Remarks•Researchers & developers of distributed systems face common challenges, e.g.:
R&D Synergies
•Patterns, frameworks, middleware, & modeling tools work together to help resolve these challenges
•connection management•service initialization•error handling• flow & congestion control•event demultiplexing•distribution•concurrency & synchronization• fault tolerance•scheduling & •persistence
• Layered QoS specification & enforcement
• Separating policies & mechanisms across layers
• Time/space optimizations for middleware & apps
• Multi-level global resource mgmt. & optimization
• High confidence • Stable & robust adaptive systems
Key open R&D challenges include:
StandardCOTS
R&D
UserNeeds
R&D
73
Context for DRE R&D at ISIS
Open-source Standards-based COTS
Patterns & Pattern LanguagesStandards-based QoS-enabled Middleware
Our R&D focus: Advancing distruptive technologies to commoditize distributed real-time & embedded (DRE) systems
Model-based Software Development & Domain-specific Languages
74
TAO–The ACE ORB
Container
ClientOBJREF
in argsoperation()out args +
return
DIIIDL
STUBSORB
INTERFACE
IDLSKEL
Object Adapter
ORB CORE GIOP/IIOP/ESIOPS
Component(Servant)
Services
• More than 500 Ksloc (C++)
• Open-source• Based on ACE wrapper
facades & frameworks• Available on Unix, Win32,
MVS, QNX, VxWorks, LynxOS, VMS, etc.
• Thousands of users around the world
Objective: Advance technology to simplify the development of embedded & real-time systems
Approach: Use standard OO techology & patterns
•Commercially supported by many companies•OCI (www.theaceorb.com)•PrismTech (www.prismtechnologies.com)•And many more
•www.cs.wustl.edu/~schmidt/commercial-support.html
75
The Evolution of TAO
TAO ORB
• Largely compliant with CORBA 3.0
• No DCOM bridge ;-)
• Pattern-oriented software architecture
• www.posa.uci.edu
• Key capabilities
• QoS-enabled
• Highly configurable
• Pluggable protocols
• IIOP/UIOP
• DIOP
• Shared memory
• SSL
• MIOP
•TAO can be downloaded from • deuce.doc.wustl.edu/Download.html
76
The Evolution of TAORT-CORBA• Portable priorities• Protocol properties• Standard synchronizers• Explicit binding mechanisms
• Thread pools
TAO 1.4 (Fall ’03)• Next “official” release of TAO
• Heavily tested & optimized
• Baseline for next OCI & PrismTech supported releases
• www.dre.vanderbilt.edu/ scoreboard
ZEN • RT-CORBA/RT-Java• Alpha now available www.zen.uci.edu
RT-CORBA 1.0
77
The Evolution of TAO
A/V STREAMING
DYNAMIC/STATICSCHEDULING
A/V Streaming Service• QoS mapping• QoS monitoring• QoS adaptation
ACE QoS API (AQoSA)• GQoS/RAPI & DiffServ• IntServ integrated with A/V Streaming & QuO
• DiffServ integrated with ORB
RT-CORBA 1.0
Static Scheduling (1.0)• Rate monotonic analysisDynamic Scheduling (2.0)• Earliest deadline first• Minimum laxity first• Maximal urgency firstHybrid Dynamic/Static• Demo in WSOA• Kokyu integrated by Summer 2003
78
The Evolution of TAODYNAMIC/STATIC
SCHEDULINGFT-CORBA
& LOAD BALANCING
FT-CORBA (DOORS)• Entity redundancy• Multiple models
• Cold passive• Warm passive
• IOGR• HA/FT integrated by Winter 2004
Load Balancing• Static & dynamic• Integrated in TAO 1.3• De-centralized LB• OMG LB specification
SSL Support• Integrity • Confidentiality• Authentication (limited)Security Service (CSIv2)• Authentication• Access control• Non-repudiation• Audit• Beta by Fall 2003
A/V STREAMINGSECURITY
RT-CORBA 1.0
79
The Evolution of TAONOTIFICATIONS
A/V STREAMINGSECURITY
TRANSACTIONS
DYNAMIC/STATICSCHEDULING
FT-CORBA & LOAD
BALANCING
Notification Service•Structured events•Event filtering•QoS properties
• Priority• Expiry times• Order policy
•Compatible w/Events
Real-time Notification Service•Summer 2003
Object TransactionService• Encapsulates RDBMs• www.xots.org
RT-CORBA 1.0
80
The Evolution of TAONOTIFICATIONS
A/V STREAMINGSECURITY
TRANSACTIONS
DYNAMIC/STATICSCHEDULING
FT-CORBA & LOAD
BALANCING
CORBA ComponentModel (CIAO)• Extension Interfaces• Component navigation• Standardized life-cycles
• Dynamic configuration• QoS-enabled containers
• Reflective collocation• Beta by Fall 2003
RT-CORBA 1.0
81
•Patterns & frameworks for concurrent & networked objects•www.cs.wustl.edu/~schmidt/POSA/•www.cs.wustl.edu/~schmidt/ACE/
•ACE & TAO open-source middleware•www.cs.wustl.edu/~schmidt/ACE.html•www.cs.wustl.edu/~schmidt/TAO.html
•Research papers•www.cs.wustl.edu/~schmidt/research.html
•Tutorial on patterns, frameworks, & middleware•UCLA extension, January, 2004•www.cs.wustl.edu/~schmidt/UCLA.html
•Conferences on patterns, frameworks, & middleware• DOA, ECOOP, ICDCS, ICSE, Middleware, OOPSLA, PLoP(s), RTAS
Additional Information