patterns, frameworks, middleware, & modeling: their synergistic relationships

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

mailto:[email protected]

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






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






25


Product Line Component Model• Configurable for product-specific functionality

& execution environment• Single component development policies• Standard component packaging mechanisms






26







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


Board 2


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


Board 2


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


•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


•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


Board 2


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


•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


•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


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


Hardware & Networks

Hi

Lo

Leve

l of

Abs

trac

tion

51

Middleware

MiddlewareServices

DRE Applications


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


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


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


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


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


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


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


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


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


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


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


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


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


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


TRANSACTIONS


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


TRANSACTIONS


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

patterns, frameworks, middleware, & modeling: their synergistic relationships

Documents

gen dre systems

lifecyclescomponent

veritasdre systems

qosenabled middleware

components frameworks

standard technologies

distributed applications

type of applications