Your SlideShare is downloading. ×
0
Pattern-Oriented Software Architectures Patterns & Frameworks for  Concurrent & Distributed Systems   Dr. Douglas C. Schmi...
Tutorial Motivation Stand-alone Architecture <ul><ul><li>Building robust, efficient, & extensible concurrent & networked a...
Tutorial Outline <ul><li>OO techniques & language features: </li></ul><ul><li>Patterns  (25+) ,   which embody reusable so...
Technology Trends (1/4) <ul><li>Information technology is being commoditized   </li></ul><ul><ul><li>i.e., hardware & soft...
Technology Trends (2/4) <ul><li>Growing acceptance of a network-centric component paradigm </li></ul><ul><ul><li>i.e., dis...
Technology Trends (3/4) <ul><li>Components  encapsulate application “business” logic </li></ul><ul><li>Components interact...
<ul><li>e.g., standard technologies are emerging that can: </li></ul><ul><ul><li>Model </li></ul></ul><ul><ul><li>Analyze ...
The Evolution of Middleware There are multiple COTS middleware layers & research/business opportunities Historically, miss...
Operating System & Protocols <ul><li>Operating systems & protocols  provide mechanisms to manage endsystem resources, e.g....
Host Infrastructure Middleware <ul><li>Host infrastructure middleware  encapsulates & enhances native OS mechanisms to cre...
Distribution Middleware <ul><li>Distribution middleware  defines higher-level distributed programming models whose reusabl...
Common Middleware Services <ul><li>Common middleware services  augment distribution middleware by defining higher-level do...
Domain-Specific Middleware <ul><li>Domain-specific middleware services  are tailored to the requirements of particular dom...
Consequences of COTS  & IT Commoditization <ul><li>More emphasis on integration rather than programming  </li></ul><ul><li...
Why We are Succeeding Now <ul><li>Recent synergistic advances in fundamental technologies & processes: </li></ul><ul><li>W...
Example: Applying COTS in Real-time Avionics <ul><li>Key System Characteristics </li></ul><ul><ul><li>Deterministic & stat...
Example: Applying COTS to Time-Critical Targets <ul><li>Time-critical targets require immediate response because: </li></u...
Example:   Applying COTS to Large-scale Routers <ul><li>Goal </li></ul><ul><li>Switch ATM cells + IP packets at terabit ra...
Example:   Applying COTS to Software Defined Radios Key Software Solution Characteristics <ul><li>Transitioned to BAE syst...
Example: Applying COTS to Hot Rolling Mills <ul><li>Goals </li></ul><ul><li>Control the processing of molten steel moving ...
Example: Applying COTS to Real-time Image Processing <ul><li>Goals </li></ul><ul><li>Examine glass bottles for defects in ...
Key Opportunities & Challenges in Concurrent Applications <ul><li>Motivations </li></ul><ul><li>Leverage hardware/software...
Key Opportunities & Challenges in  Networked & Distributed Applications <ul><li>Motivations </li></ul><ul><li>Collaboratio...
Overview of Patterns <ul><li>Present  solutions  to common software  problems  arising within a certain  context </li></ul...
Overview of Pattern Languages <ul><li>Benefits of Pattern Languages </li></ul><ul><li>Define a  vocabulary  for talking ab...
Taxonomy of Patterns & Idioms Active Object, Bridge, Proxy, Wrapper Façade, & Visitor Capture the static & dynamic roles &...
Example:   Boeing Bold Stroke Product-line Architecture Nav Sensors Expendable Management Data Links Mission Computer Vehi...
Example:   Boeing Bold Stroke Product-line Architecture <ul><li>COTS & Standards-based Middleware Infrastructure, OS, Netw...
Example:   Boeing Bold Stroke Product-line Architecture <ul><li>Reusable Object-Oriented Application Domain-specific   Mid...
Example:   Boeing Bold Stroke Product-line Architecture <ul><li>Product Line Component Model </li></ul><ul><li>Configurabl...
Example:   Boeing Bold Stroke Product-line Architecture <ul><li>Component Integration Model </li></ul><ul><ul><li>Configur...
Legacy Avionics Architectures Board 1 VME 1553 1: Sensors  generate  data Board 2 2: I/O via  interrupts 3: Sensor  proxie...
Legacy Avionics Architectures Board 1 VME 1553 1: Sensors  generate  data Board 2 2: I/O via  interrupts 3: Sensor  proxie...
Decoupling Avionics Components <ul><li>Apply the  Publisher-Subscriber  architectural pattern to distribute periodic, I/O-...
Applying the Publisher-Subscriber Pattern to Bold Stroke Board 1 VME 1553 1: Sensors  generate  data Board 2 2: I/O via in...
Ensuring Platform-neutral & Network-transparent Communication Wrapper Facade Layers Component internal partitioning Remoti...
Ensuring Platform-neutral & Network-transparent Communication operation (params) connect send_request marshal unmarshal di...
Applying the Broker Pattern  to Bold Stroke Board 1 VME 1553 1: Sensors  generate  data Board 2 2: I/O via interrupts 5: E...
<ul><li>Enables reuse of software architectures & designs </li></ul><ul><li>Improves development team communication </li><...
<ul><li>Require significant tedious & error-prone human effort to handcraft pattern implementations </li></ul><ul><li>Can ...
Software Design Abstractions for  Concurrent & Networked Applications <ul><li>Problem </li></ul><ul><li>Distributed app & ...
Overview of Frameworks Framework Characteristics  Application-specific functionality  <ul><li>Frameworks exhibit “inversio...
Comparing Class Libraries,  Frameworks, & Components Class  Libraries Frameworks Macro-level Meso-level Micro-level Borrow...
Using Frameworks Effectively <ul><li>Observations </li></ul><ul><li>Frameworks are powerful, but hard to develop & use eff...
Overview of the ACE Frameworks <ul><li>Features </li></ul><ul><li>Open-source </li></ul><ul><li>6+ integrated frameworks <...
The Layered Architecture of ACE <ul><li>Features </li></ul><ul><li>Open-source </li></ul><ul><li>250,000+ lines of C++ </l...
Key Capabilities Provided by ACE Service Access & Control Event Handling Concurrency Synchronization
The POSA2 Pattern Language <ul><li>Pattern Benefits </li></ul><ul><ul><li>Preserve crucial design information used by appl...
POSA2 Pattern Abstracts Service Access & Configuration Patterns The  Wrapper Facade  design pattern encapsulates the funct...
POSA2 Pattern Abstracts  (cont’d) Synchronization Patterns The  Scoped Locking  C++ idiom ensures that a lock is acquired ...
Implementing the Broker Pattern  for Bold Stroke Avionics <ul><li>CORBA  is a distribution middleware standard </li></ul><...
Example of Applying Patterns & Frameworks to Middleware : Real-time CORBA & The ACE ORB (TAO) <ul><li>TAO Features </li></...
Key Patterns Used in TAO www.cs.wustl.edu/~schmidt/PDF/ORB-patterns.pdf <ul><li>Wrapper facades  enhance portability </li>...
Enhancing ORB Flexibility  w/the Strategy Pattern   <ul><li>Apply the  Strategy  pattern to factory out commonality amongs...
Consolidating Strategies with  the Abstract Factory Pattern <ul><li>Apply the  Abstract Factory  pattern to consolidate mu...
Dynamically Configuring Factories  w/the Component Configurator Pattern <ul><li>Apply the  Component Configurator  pattern...
ACE Frameworks Used in TAO <ul><li>Reactor  drives the ORB event loop </li></ul><ul><ul><li>Implements the  Reactor  &  Le...
Summary of Pattern, Framework,  & Middleware Synergies These technologies codify expertise of skilled researchers & develo...
Example: Electronic Medical Imaging Systems <ul><li>Goal </li></ul><ul><li>Route, manage, & manipulate electronic medical ...
Example: Electronic Medical Imaging Systems <ul><li>System Characteristics   </li></ul><ul><li>Large volume of “blob” data...
Example: Electronic Medical Imaging Systems Key Software Solution Characteristics (e.g., www.syngo.com) <ul><li>Affordable...
Image Acquisition Scenario Modalities e.g.,  MRI, CT, CR, Ultrasound, etc. Image Xfer Interface Image Xfer Component Execu...
Applying Patterns to Resolve Key  Distributed System Design Challenges Patterns help resolve the following common design c...
Separating Concerns Between Tiers <ul><li>Solution </li></ul><ul><li>Apply the  Layers  pattern (P1) to create a multi-tie...
Applying the Layers Pattern to  Image Acquisition <ul><li>Image servers  are middle tier entities that: </li></ul><ul><ul>...
Pros & Cons of the Layers Pattern <ul><li>This pattern has four  benefits : </li></ul><ul><li>Reuse of layers </li></ul><u...
Overview of Distributed Object Computing Communication Mechanisms <ul><li>Solution </li></ul><ul><li>DOC middleware provid...
Core Distribution Infrastructure Patterns <ul><li>Broker  makes invocations on remote component objects look & act as much...
Improving Type-safety & Performance (1/2) <ul><li>Context </li></ul><ul><li>The configuration of components in distributed...
Improving Type-safety & Performance (2/2) <ul><li>A   Service  implements the object, which is not accessible directly </l...
Applying the Proxy Pattern  to Image Acquisition Client 1 1 We can apply the Proxy pattern to provide a strongly-typed int...
Pros & Cons of the Proxy Pattern <ul><li>This pattern provides three  benefits : </li></ul><ul><li>Decoupling clients from...
Enabling Client Extensibility (1/2) <ul><li>Context </li></ul><ul><li>Object models define how components import & export ...
Enabling Client Extensibility (2/2) <ul><li>Solution </li></ul><ul><li>Apply the  Extension Interface  design pattern (P2)...
Extension Interface Pattern Dynamics :  Client Start_client :  Factory createInstance(Ext.Intf. 1) new Ref. To Extension1 ...
Pros & Cons of the  Extension Interface Pattern <ul><li>This pattern has five  benefits : </li></ul><ul><ul><li>Separation...
Ensuring Platform-neutral & Network-transparent OO Communication (1/2) <ul><li>Problem </li></ul><ul><li>A middleware arch...
Ensuring Platform-neutral & Network-transparent OO Communication (2/2) <ul><li>Solution </li></ul><ul><li>Apply the  Broke...
Broker Pattern Dynamics method (proxy) locate_server server port send_request marshal unmarshal dispatch method (impl.) re...
Applying the Broker Pattern  to Image Acquisition   <ul><li>Common Broker pattern implementations   </li></ul><ul><ul><li>...
Pros & Cons of the Broker Pattern <ul><li>This pattern has five  benefits : </li></ul><ul><ul><li>Portability enhancements...
Supporting Async Communication (1/2) <ul><li>Context </li></ul><ul><li>Some clients want to send requests, continue their ...
Supporting Async Communication (1/2) <ul><li>Solution </li></ul><ul><li>Apply the  Messaging  (P4/EIP) pattern to allow as...
Messaging Pattern Dynamics :   Client :  Message create store Message forward Message :  Message Processor create receive ...
Applying the Messaging  Pattern to Image Acquisition <ul><li>We can apply the Messaging pattern to </li></ul><ul><ul><li>Q...
Pros & Cons of the Messaging Pattern <ul><li>This pattern provides three  benefits : </li></ul><ul><li>Enhances concurrenc...
Supporting OO Async Communication   (1/2) <ul><li>Context </li></ul><ul><li>Some clients want to invoke remote operations,...
Supporting OO Async Communication (2/2) <ul><li>Solution </li></ul><ul><li>Apply the  Active Object  design pattern (P2) t...
Active Object Pattern Dynamics <ul><li>A  client  invokes a method on the  proxy </li></ul><ul><li>The  proxy  returns a f...
Applying the Active Object Pattern  to Image Acquisition <ul><li>OO developers often prefer  method-oriented  request/resp...
Pros & Cons of the Active Object Pattern <ul><li>This pattern provides four  benefits : </li></ul><ul><li>Enhanced type-sa...
Decoupling Suppliers & Consumers (1/2) <ul><li>Problem </li></ul><ul><li>Having each client call a specific server is inef...
Decoupling Suppliers & Consumers (2/2) <ul><li>Decouple suppliers (publishers) & consumers (subscribers) of events: </li><...
Publisher-Subscriber Pattern Dynamics <ul><li>The Publisher-Subscriber pattern helps keep the state of cooperating compone...
Applying the Publisher-Subscriber Pattern to Image Acquisition * creates receives Event Channel attachPublisher  detachPub...
Pros & Cons of the Publisher-Subscriber Pattern <ul><li>This pattern has two  benefits : </li></ul><ul><li>Decouples consu...
Locating & Creating Components Scalably (1/2) <ul><li>Context </li></ul><ul><li>Our electronic medical imaging system cont...
Locating & Creating Components Scalably (2/2) <ul><li>An  Abstract  Home  declares an interface for operations that  find ...
Factory/Finder Pattern Dynamics <ul><li>Homes enable the creation & location of components, but we still need some type of...
Applying the Factory/Finder Pattern  to Image Acquisition Image Xfer Interface Factory Proxy <ul><li>We can apply the Fact...
Pros & Cons of the Factory/Finder Pattern <ul><li>This pattern has three  benefits : </li></ul><ul><ul><li>Separation of c...
Extending Components Transparently <ul><li>Context </li></ul><ul><li>Component developers may not know  a priori  the cont...
Extending Components Transparently  (cont‘d) <ul><li>Problem </li></ul><ul><li>Developers should be able to specify  decla...
Interceptor Pattern Dynamics <ul><li>Interceptor are a “ meta-programming mechanism ,” along with </li></ul><ul><ul><li>Sm...
Applying the Interceptor Pattern  to Image Acquisition <ul><li>A container provides generic interfaces to a component that...
Pros & Cons of the Interceptor Pattern <ul><li>This pattern has five  benefits : </li></ul><ul><li>Extensibility & flexibi...
Minimizing Resource Utilization (1/2) <ul><li>Problem </li></ul><ul><li>It may not feasible to have all image server imple...
Minimizing Resource Utilization (2/2) <ul><li>Solution </li></ul><ul><li>Apply the  Activator  (PLoP12/P4) design pattern ...
Activator Pattern Dynamics <ul><li>An Activator can be used to activate & passivate a server </li></ul><ul><ul><li>e.g., a...
Applying the Activator Pattern  to Image Acquisition Activator createService() findService() activate() deactivate() addSe...
Pros & Cons of the Activator Pattern <ul><li>This pattern has three  benefits : </li></ul><ul><li>More effective resource ...
Enhancing Server (Re)Configurability (1/2) <ul><li>Certain factors are  static , such as the number of available CPUs & op...
Enhancing Server (Re)Configurability   (2/2) <ul><li>This pattern allows an application to link & unlink its component imp...
Component Configurator Pattern Dynamics run_component() run_component() fini() remove() remove() fini() Comp. A Concrete C...
Applying the Component Configurator Pattern to Image Acquisition <<contains>> components * Component Configurator Componen...
Reconfiguring an Image Server Image servers can also be reconfigured dynamically to support new components & new component...
Pros & Cons of the  Component Configurator Pattern <ul><li>This pattern offers four  benefits : </li></ul><ul><li>Uniformi...
Example: High-performance Content Delivery Servers <ul><li>Support many content delivery server design alternatives seamle...
JAWS Content Server Framework <ul><li>Key Sources of Variation </li></ul><ul><li>Concurrency models </li></ul><ul><ul><li>...
Applying Patterns to Resolve Key JAWS Design Challenges Patterns help resolve the following common design challenges:   <u...
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Pattern-Oriented Distributed Software Architectures
Upcoming SlideShare
Loading in...5
×

Pattern-Oriented Distributed Software Architectures

3,663

Published on

Published in: Technology

Transcript of "Pattern-Oriented Distributed Software Architectures "

  1. 1. Pattern-Oriented Software Architectures Patterns & Frameworks for Concurrent & Distributed Systems Dr. Douglas C. Schmidt [email_address] www.dre.vanderbilt.edu/~schmidt/ Professor of EECS Vanderbilt University Nashville, Tennessee
  2. 2. Tutorial Motivation Stand-alone Architecture <ul><ul><li>Building robust, efficient, & extensible concurrent & networked applications is hard </li></ul></ul><ul><ul><ul><li>e.g., we must address many complex topics that are less problematic for non-concurrent, stand-alone applications </li></ul></ul></ul>Observations <ul><li>Fortunately, there are reusable solutions to many common challenges, e.g.: </li></ul><ul><ul><li>Connection mgmt & event demuxing </li></ul></ul><ul><ul><li>Service initialization </li></ul></ul><ul><ul><li>Error handling & fault tolerance </li></ul></ul><ul><ul><li>Flow & congestion control </li></ul></ul><ul><ul><li>Distribution </li></ul></ul><ul><ul><li>Concurrency, scheduling, & synchronization </li></ul></ul><ul><ul><li>Persistence </li></ul></ul>Key challenge: How can we reuse the these solutions effectively in a changing, heterogeneous world? Networked Architecture
  3. 3. Tutorial Outline <ul><li>OO techniques & language features: </li></ul><ul><li>Patterns (25+) , which embody reusable software architectures & designs </li></ul><ul><li>Frameworks & components , which embody reusable software middleware & application implementations </li></ul><ul><li>OO language features , e.g., classes , dynamic binding & inheritance , parameterized types </li></ul>Cover OO techniques & language features that enhance software quality Modalities e.g., MRI, CT, CR, Ultrasound, etc. <ul><li>Tutorial Organization </li></ul><ul><li>Technology trends & background </li></ul><ul><li>Concurrent & network challenges & solution approaches </li></ul><ul><li>Case studies </li></ul><ul><li>Wrap-up </li></ul>
  4. 4. Technology Trends (1/4) <ul><li>Information technology is being commoditized </li></ul><ul><ul><li>i.e., hardware & software are getting cheaper, faster, & (generally) better at a fairly predictable rate </li></ul></ul>These advances stem largely from standard hardware & software APIs & protocols, e.g.: <ul><ul><li>TCP/IP, GSM, Link16 </li></ul></ul><ul><ul><li>POSIX, Windows, & VMs </li></ul></ul><ul><ul><li>Middleware & component models </li></ul></ul><ul><ul><li>Intel x86 & Power PC chipsets </li></ul></ul><ul><ul><li>Quality of service (QoS) aspects </li></ul></ul>
  5. 5. Technology Trends (2/4) <ul><li>Growing acceptance of a network-centric component paradigm </li></ul><ul><ul><li>i.e., distributed applications with a range of QoS needs are constructed by integrating components & frameworks via various communication mechanisms </li></ul></ul>Process Automation Quality Control Avionics Mission Computing Modalities e.g., MRI, CT, CR, Ultrasound, etc. Electronic Medical Imaging Software Defined Radio Hot Rolling Mills
  6. 6. Technology Trends (3/4) <ul><li>Components encapsulate application “business” logic </li></ul><ul><li>Components interact via ports </li></ul><ul><ul><li>Provided interfaces , e.g.,facets </li></ul></ul><ul><ul><li>Required connection points , e.g., receptacles </li></ul></ul><ul><ul><li>Event sinks & sources </li></ul></ul><ul><ul><li>Attributes </li></ul></ul><ul><li>Containers provide execution environment for components with common operating requirements </li></ul><ul><li>Components/containers can also </li></ul><ul><ul><li>Communicate via a middleware bus & </li></ul></ul><ul><ul><li>Reuse common middleware services </li></ul></ul>Component middleware is maturing & becoming pervasive … Security Replication Notification Persistence Scheduling A/V Streaming Load Balancing Container … … Middleware Bus Container …
  7. 7. <ul><li>e.g., standard technologies are emerging that can: </li></ul><ul><ul><li>Model </li></ul></ul><ul><ul><li>Analyze </li></ul></ul><ul><ul><li>Synthesize & optimize </li></ul></ul><ul><ul><li>Provision & deploy </li></ul></ul><ul><li>multiple layers of QoS-enabled middleware & applications </li></ul><ul><li>These technologies are guided by patterns & implemented by component frameworks </li></ul><ul><li>Partial specialization is essential for inter-/intra-layer optimization </li></ul><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 Model driven development is integrating generative software technologies with QoS-enabled component middleware Technology Trends (4/4) Middleware Middleware Services DRE Applications Operating Sys & Protocols Hardware & Networks Distributed system
  8. 8. The Evolution of Middleware There are multiple COTS middleware layers & research/business opportunities Historically, mission-critical apps were built directly atop hardware <ul><li>Tedious, error-prone, & costly over lifecycles </li></ul><ul><li>Standards-based COTS middleware helps: </li></ul><ul><ul><li>Control end-to-end resources & QoS </li></ul></ul><ul><ul><li>Leverage hardware & software technology advances </li></ul></ul><ul><ul><li>Evolve to new environments & requirements </li></ul></ul><ul><ul><li>Provide a wide array of reusable, off-the-shelf developer-oriented services </li></ul></ul>There are layers of middleware, just like there are layers of networking protocols Hardware Applications Domain-Specific Services Common Middleware Services Distribution Middleware Host Infrastructure Middleware & OS Operating Systems & Protocols
  9. 9. Operating System & Protocols <ul><li>Operating systems & protocols provide mechanisms to manage endsystem resources, e.g., </li></ul><ul><ul><li>CPU scheduling & dispatching </li></ul></ul><ul><ul><li>Virtual memory management </li></ul></ul><ul><ul><li>Secondary storage, persistence, & file systems </li></ul></ul><ul><ul><li>Local & remote interprocess communication (IPC) </li></ul></ul><ul><li>OS examples </li></ul><ul><ul><li>UNIX/Linux, Windows, VxWorks, QNX, etc. </li></ul></ul><ul><li>Protocol examples </li></ul><ul><ul><li>TCP, UDP, IP, SCTP, RTP, etc. </li></ul></ul>RTP DNS HTTP UDP TCP IP TELNET Ethernet ATM FDDI Fibre Channel FTP INTERNETWORKING ARCH TFTP 20 th Century Win2K Linux LynxOS Solaris VxWorks Middleware Middleware Services Middleware Applications MIDDLEWARE ARCH 21 st Century
  10. 10. Host Infrastructure Middleware <ul><li>Host infrastructure middleware encapsulates & enhances native OS mechanisms to create reusable network programming components </li></ul><ul><ul><li>These components abstract away many tedious & error-prone aspects of low-level OS APIs </li></ul></ul>Domain-Specific Services Common Middleware Services Distribution Middleware Host Infrastructure Middleware www.cs.wustl.edu/~schmidt/ACE.html Synchronization Memory Management Physical Memory Access Asynchronous Event Handling Scheduling Asynchronous Transfer of Control www.rtj.org <ul><li>Examples </li></ul><ul><ul><li>Java Virtual Machine (JVM), Common Language Runtime (CLR), ADAPTIVE Communication Environment (ACE) </li></ul></ul>
  11. 11. Distribution Middleware <ul><li>Distribution middleware defines higher-level distributed programming models whose reusable APIs & components automate & extend native OS capabilities </li></ul>Domain-Specific Services Common Middleware Services Distribution Middleware Host Infrastructure Middleware Distribution middleware avoids hard-coding client & server application dependencies on object location, language, OS, protocols, & hardware <ul><li>Examples </li></ul><ul><ul><li>OMG Real-time CORBA & DDS, Sun RMI, Microsoft DCOM, W3C SOAP </li></ul></ul>en.wikipedia.org/wiki/Data_Distribution_Service realtime.omg.org/
  12. 12. Common Middleware Services <ul><li>Common middleware services augment distribution middleware by defining higher-level domain-independent services that focus on programming “business logic” </li></ul>Domain-Specific Services Common Middleware Services Distribution Middleware Host Infrastructure Middleware <ul><li>Common middleware services support many recurring distributed system capabilities, e.g., </li></ul><ul><ul><li>Transactional behavior </li></ul></ul><ul><ul><li>Authentication & authorization, </li></ul></ul><ul><ul><li>Database connection pooling & concurrency control </li></ul></ul><ul><ul><li>Active replication </li></ul></ul><ul><ul><li>Dynamic resource management </li></ul></ul><ul><li>Examples </li></ul><ul><ul><li>CORBA Component Model & Object Services, Sun’s J2EE, Microsoft’s .NET, W3C Web Services </li></ul></ul>
  13. 13. Domain-Specific Middleware <ul><li>Domain-specific middleware services are tailored to the requirements of particular domains, such as telecom, e-commerce, health care, process automation, or aerospace </li></ul>Domain-Specific Services Common Middleware Services Distribution Middleware Host Infrastructure Middleware Modalities e.g., MRI, CT, CR, Ultrasound, etc. <ul><li>Siemens MED Syngo </li></ul><ul><li>Common software platform for distributed electronic medical systems </li></ul><ul><li>Used by all ~13 Siemens MED business units worldwide </li></ul><ul><li>Boeing Bold Stroke </li></ul><ul><ul><li>Common software platform for Boeing avionics mission computing systems </li></ul></ul><ul><li>Examples </li></ul>
  14. 14. Consequences of COTS & IT Commoditization <ul><li>More emphasis on integration rather than programming </li></ul><ul><li>Increased technology convergence & standardization </li></ul><ul><li>Mass market economies of scale for technology & personnel </li></ul><ul><li>More disruptive technologies & global competition </li></ul><ul><li>Lower priced--but often lower quality--hardware & software components </li></ul><ul><li>The decline of internally funded R&D </li></ul><ul><li>Potential for complexity cap in next-generation complex systems </li></ul>Not all trends bode well for long-term competitiveness of traditional R&D leaders Ultimately, competitiveness depends on success of long-term R&D on complex distributed real-time & embedded (DRE) systems
  15. 15. Why We are Succeeding Now <ul><li>Recent synergistic advances in fundamental technologies & processes: </li></ul><ul><li>Why middleware-centric reuse works </li></ul><ul><li>Hardware advances </li></ul><ul><ul><li>e.g., faster CPUs & networks </li></ul></ul><ul><li>Software/system architecture advances </li></ul><ul><ul><li>e.g., inter-layer optimizations & meta-programming mechanisms </li></ul></ul><ul><li>Economic necessity </li></ul><ul><ul><li>e.g., global competition for customers & engineers </li></ul></ul>Revolutionary changes in software process & methods: Open-source, refactoring, agile methods, advanced V&V techniques, model-driven development Patterns & Pattern Languages: Generate software architectures by capturing recurring structures & dynamics & by resolving design forces Standards-based QoS-enabled Middleware: Pluggable service & micro-protocol components & reusable “semi-complete” application frameworks
  16. 16. Example: Applying COTS in Real-time Avionics <ul><li>Key System Characteristics </li></ul><ul><ul><li>Deterministic & statistical deadlines </li></ul></ul><ul><ul><ul><li>~20 Hz </li></ul></ul></ul><ul><ul><li>Low latency & jitter </li></ul></ul><ul><ul><ul><li>~250 u secs </li></ul></ul></ul><ul><ul><li>Periodic & aperiodic processing </li></ul></ul><ul><ul><li>Complex dependencies </li></ul></ul><ul><ul><li>Continuous platform upgrades </li></ul></ul><ul><li>Goals </li></ul><ul><li>Apply COTS & open systems to mission-critical real-time avionics </li></ul><ul><li>Test flown at China Lake NAWS by Boeing OSAT II ‘98, funded by OS-JTF </li></ul><ul><ul><li>www.cs.wustl.edu/~schmidt/TAO-boeing.html </li></ul></ul><ul><li>Also used on SOFIA project by Raytheon </li></ul><ul><ul><li>sofia.arc.nasa.gov </li></ul></ul><ul><li>First use of RT CORBA in mission computing </li></ul><ul><li>Drove Real-time CORBA standardization </li></ul>Key Results
  17. 17. Example: Applying COTS to Time-Critical Targets <ul><li>Time-critical targets require immediate response because: </li></ul><ul><li>They pose a clear & present danger to friendly forces & </li></ul><ul><li>Are highly lucrative, fleeting targets of opportunity </li></ul>Challenges are also relevant to TBMD & NMD <ul><li>Goals </li></ul><ul><li>Detect, identify, track, & destroy time-critical targets </li></ul><ul><li>Real-time mission-critical sensor-to-shooter needs </li></ul><ul><li>Highly dynamic QoS requirements & environmental conditions </li></ul><ul><li>Multi-service & asset coordination </li></ul>Key System Characteristics Key Solution Characteristics <ul><li>Efficient & scalable </li></ul><ul><li>Affordable & flexible </li></ul><ul><li>COTS-based </li></ul><ul><li>Adaptive & reflective </li></ul><ul><li>High confidence </li></ul><ul><li>Safety critical </li></ul>
  18. 18. Example: Applying COTS to Large-scale Routers <ul><li>Goal </li></ul><ul><li>Switch ATM cells + IP packets at terabit rates </li></ul><ul><li>Key System Characteristics </li></ul><ul><ul><li>Very high-speed WDM links </li></ul></ul><ul><ul><li>10 2 /10 3 line cards </li></ul></ul><ul><ul><li>Stringent requirements for availability </li></ul></ul><ul><ul><li>Multi-layer load balancing, e.g.: </li></ul></ul><ul><ul><ul><li>Layer 3+4 </li></ul></ul></ul><ul><ul><ul><li>Layer 5 </li></ul></ul></ul>www.arl.wustl.edu IOM IOM IOM IOM IOM IOM IOM IOM IOM IOM IOM IOM IOM IOM IOM IOM IOM IOM BSE BSE BSE BSE BSE BSE BSE BSE BSE Key Software Solution Characteristics <ul><li>High confidence & scalable computing architecture </li></ul><ul><ul><li>Networked embedded processors </li></ul></ul><ul><ul><li>Distribution middleware </li></ul></ul><ul><ul><li>FT & load sharing </li></ul></ul><ul><ul><li>Distributed & layered resource management </li></ul></ul><ul><li>Affordable, flexible, & COTS </li></ul>
  19. 19. Example: Applying COTS to Software Defined Radios Key Software Solution Characteristics <ul><li>Transitioned to BAE systems for the Joint Tactical Radio Systems </li></ul><ul><li>Programmable radio with waveform-specific components </li></ul><ul><li>Uses CORBA component middleware based on ACE+TAO </li></ul>www.omg.org/docs/swradio Core Framework (CF) Commercial Off-the-Shelf (COTS) Applications OE Red Hardware Bus CF Services & Applications CORBA ORB & Services (Middleware) Network Stacks & Serial Interface Services Board Support Package (Bus Layer) Black Hardware Bus CF Services & Applications CORBA ORB & Services (Middleware) Network Stacks & Serial Interface Services Board Support Package (Bus Layer) Operating System Core Framework IDL Non-CORBA Modem Components Non-CORBA Security Components Non-CORBA I/O Components RF Modem Components Link, Network Components Security Components Modem Adapter Security Adapter Security Adapter I/O Adapter I/O Components MAC API LLC/Network API LLC/Network API Link, Network Components Security API Operating System Physical API I/O API (“Logical Software Bus” via CORBA)
  20. 20. Example: Applying COTS to Hot Rolling Mills <ul><li>Goals </li></ul><ul><li>Control the processing of molten steel moving through a hot rolling mill in real-time </li></ul><ul><li>System Characteristics </li></ul><ul><ul><li>Hard real-time process automation requirements </li></ul></ul><ul><ul><ul><li>i.e., 250 ms real-time cycles </li></ul></ul></ul><ul><ul><li>System acquires values representing plant’s current state, tracks material flow, calculates new settings for the rolls & devices, & submits new settings back to plant </li></ul></ul>Key Software Solution Characteristics <ul><li>Affordable, flexible, & COTS </li></ul><ul><ul><li>Product-line architecture </li></ul></ul><ul><ul><li>Design guided by patterns & frameworks </li></ul></ul><ul><ul><li>Windows NT/2000 </li></ul></ul><ul><ul><li>Real-time CORBA (ACE+TAO) </li></ul></ul>www.siroll.de
  21. 21. Example: Applying COTS to Real-time Image Processing <ul><li>Goals </li></ul><ul><li>Examine glass bottles for defects in real-time </li></ul><ul><li>System Characteristics </li></ul><ul><ul><li>Process 20 bottles per sec </li></ul></ul><ul><ul><ul><li>i.e., ~50 msec per bottle </li></ul></ul></ul><ul><ul><li>Networked configuration </li></ul></ul><ul><ul><li>~10 cameras </li></ul></ul>www.krones.com Key Software Solution Characteristics <ul><li>Affordable, flexible, & COTS </li></ul><ul><ul><li>Embedded Linux (Lem) </li></ul></ul><ul><ul><li>Compact PCI bus + Celeron processors </li></ul></ul><ul><li>Remote booted by DHCP/TFTP </li></ul><ul><li>Real-time CORBA (ACE+TAO) </li></ul>
  22. 22. Key Opportunities & Challenges in Concurrent Applications <ul><li>Motivations </li></ul><ul><li>Leverage hardware/software advances </li></ul><ul><li>Simplify program structure </li></ul><ul><li>Increase performance </li></ul><ul><li>Improve response-time </li></ul><ul><li>Accidental Complexities </li></ul><ul><li>Low-level APIs </li></ul><ul><li>Poor debugging tools </li></ul><ul><li>Inherent Complexities </li></ul><ul><li>Scheduling </li></ul><ul><li>Synchronization </li></ul><ul><li>Deadlocks </li></ul>
  23. 23. Key Opportunities & Challenges in Networked & Distributed Applications <ul><li>Motivations </li></ul><ul><li>Collaboration </li></ul><ul><li>Performance </li></ul><ul><li>Reliability & availability </li></ul><ul><li>Scalability & portability </li></ul><ul><li>Extensibility </li></ul><ul><li>Cost effectiveness </li></ul><ul><li>Accidental Complexities </li></ul><ul><li>Algorithmic decomposition </li></ul><ul><li>Continuous re-invention & re-discovery of core concepts & components </li></ul><ul><li>Inherent Complexities </li></ul><ul><li>Latency </li></ul><ul><li>Reliability </li></ul><ul><li>Load balancing </li></ul><ul><li>Causal ordering </li></ul><ul><li>Security & information assurance </li></ul>
  24. 24. Overview of Patterns <ul><li>Present solutions to common software problems arising within a certain context </li></ul><ul><li>Capture recurring structures & dynamics among software participants to facilitate reuse of successful designs </li></ul>The Proxy Pattern 1 1 Proxy service Service service AbstractService service Client <ul><li>Help resolve key software design forces </li></ul><ul><ul><li>Flexibility </li></ul></ul><ul><ul><li>Extensibility </li></ul></ul><ul><ul><li>Dependability </li></ul></ul><ul><ul><li>Predictability </li></ul></ul><ul><ul><li>Scalability </li></ul></ul><ul><ul><li>Efficiency </li></ul></ul><ul><li>Generally codify expert knowledge of design strategies, constraints & “best practices” </li></ul>
  25. 25. Overview of Pattern Languages <ul><li>Benefits of Pattern Languages </li></ul><ul><li>Define a vocabulary for talking about software development problems </li></ul><ul><li>Provide a process for the orderly resolution of these problems, e.g.: </li></ul><ul><ul><li>What are key problems to be resolved & in what order </li></ul></ul><ul><ul><li>What alternatives exist for resolving a given problem </li></ul></ul><ul><ul><li>How should mutual dependencies between the problems be handled </li></ul></ul><ul><ul><li>How to resolve each individual problem most effectively in its context </li></ul></ul><ul><li>Help to generate & reuse software architectures </li></ul><ul><li>Motivation </li></ul><ul><li>Individual patterns & pattern catalogs are insufficient </li></ul><ul><li>Software modeling methods & tools largely just illustrate what/how – not why – systems are designed </li></ul>
  26. 26. Taxonomy of Patterns & Idioms Active Object, Bridge, Proxy, Wrapper Façade, & Visitor Capture the static & dynamic roles & relationships in solutions that occur repeatedly Design patterns Half-Sync/Half-Async, Layers, Proactor, Publisher-Subscriber, & Reactor Express a fundamental structural organization for software systems that provide a set of predefined subsystems, specify their relationships, & include the rules & guidelines for organizing the relationships between them Architectural patterns Optimize for common case, pass information between layers Document rules for avoiding common design & implementation mistakes that degrade performance Optimization principle patterns Scoped locking Restricted to a particular language, system, or tool Idioms Examples Description Type
  27. 27. Example: Boeing Bold Stroke Product-line Architecture Nav Sensors Expendable Management Data Links Mission Computer Vehicle Mgmt Expendable Radar <ul><li>Avionics mission computing product-line architecture for Boeing military aircraft, e.g., F-18 E/F, 15E, Harrier, UCAV </li></ul><ul><li>DRE system with 100+ developers, 3,000+ software components, 3-5 million lines of C++ code </li></ul><ul><li>Based on COTS hardware, networks, operating systems, & middleware </li></ul><ul><li>Used as Open Experimentation Platform (OEP) for DARPA IXO PCES, MoBIES, SEC, MICA programs </li></ul>Bold Stroke Architecture Hardware (CPU, Memory, I/O) Networking Interfaces Operating System Middleware Infrastructure Mission Computing Services
  28. 28. Example: Boeing Bold Stroke Product-line Architecture <ul><li>COTS & Standards-based Middleware Infrastructure, OS, Network, & Hardware Platform </li></ul><ul><ul><li>Real-time CORBA middleware services </li></ul></ul><ul><ul><li>VxWorks operating system </li></ul></ul><ul><ul><li>VME, 1553, & Link16 </li></ul></ul><ul><ul><li>PowerPC </li></ul></ul>Hardware (CPU, Memory, I/O) Networking Interfaces Operating System Middleware Infrastructure Mission Computing Services
  29. 29. Example: Boeing Bold Stroke Product-line Architecture <ul><li>Reusable Object-Oriented Application Domain-specific Middleware Framework </li></ul><ul><ul><li>Configurable to variable infrastructure configurations </li></ul></ul><ul><ul><li>Supports systematic reuse of mission computing functionality </li></ul></ul>Hardware (CPU, Memory, I/O) Networking Interfaces Operating System Middleware Infrastructure Mission Computing Services
  30. 30. Example: Boeing Bold Stroke Product-line Architecture <ul><li>Product Line Component Model </li></ul><ul><li>Configurable for product-specific functionality & execution environment </li></ul><ul><li>Single component development policies </li></ul><ul><li>Standard component packaging mechanisms </li></ul>Hardware (CPU, Memory, I/O) Networking Interfaces Operating System Middleware Infrastructure Mission Computing Services
  31. 31. Example: Boeing Bold Stroke Product-line Architecture <ul><li>Component Integration Model </li></ul><ul><ul><li>Configurable for product-specific component assembly & deployment environments </li></ul></ul><ul><ul><li>Model-based component integration policies </li></ul></ul>Avionics Interfaces Operator Real World Model Infrastructure Services Push Control Flow Pull Data Flow Hardware (CPU, Memory, I/O) Networking Interfaces Operating System Middleware Infrastructure Mission Computing Services
  32. 32. 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 <ul><li>Key System Characteristics </li></ul><ul><ul><li>Hard & soft real-time deadlines </li></ul></ul><ul><ul><ul><li>~20-40 Hz </li></ul></ul></ul><ul><ul><li>Low latency & jitter between boards </li></ul></ul><ul><ul><ul><li>~100 u secs </li></ul></ul></ul><ul><ul><li>Periodic & aperiodic processing </li></ul></ul><ul><ul><li>Complex dependencies </li></ul></ul><ul><ul><li>Continuous platform upgrades </li></ul></ul><ul><li>Avionics Mission Computing Functions </li></ul><ul><ul><li>Weapons targeting systems (WTS) </li></ul></ul><ul><ul><li>Airframe & navigation (Nav) </li></ul></ul><ul><ul><li>Sensor control (GPS, IFF, FLIR) </li></ul></ul><ul><ul><li>Heads-up display (HUD) </li></ul></ul><ul><ul><li>Auto-pilot (AP) </li></ul></ul>
  33. 33. 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 <ul><li>Key System Characteristics </li></ul><ul><ul><li>Hard & soft real-time deadlines </li></ul></ul><ul><ul><ul><li>~20-40 Hz </li></ul></ul></ul><ul><ul><li>Low latency & jitter between boards </li></ul></ul><ul><ul><ul><li>~100 u secs </li></ul></ul></ul><ul><ul><li>Periodic & aperiodic processing </li></ul></ul><ul><ul><li>Complex dependencies </li></ul></ul><ul><ul><li>Continuous platform upgrades </li></ul></ul>Air Frame AP Nav WTS GPS IFF FLIR Cyclic Exec <ul><li>Limitations with Legacy Avionics Architectures </li></ul><ul><ul><li>Stovepiped </li></ul></ul><ul><ul><li>Proprietary </li></ul></ul><ul><ul><li>Expensive </li></ul></ul><ul><ul><li>Vulnerable </li></ul></ul><ul><ul><li>Tightly coupled </li></ul></ul><ul><ul><li>Hard to schedule </li></ul></ul><ul><ul><li>Brittle & non-adaptive </li></ul></ul>
  34. 34. Decoupling Avionics Components <ul><li>Apply the Publisher-Subscriber architectural pattern to distribute periodic, I/O-driven data from a single point of source to a collection of consumers </li></ul><ul><li>Tightly coupled components </li></ul><ul><li>Hard to schedule </li></ul><ul><li>Expensive to evolve </li></ul><ul><li>I/O driven DRE application </li></ul><ul><li>Complex dependencies </li></ul><ul><li>Real-time constraints </li></ul>Solution Problems Context Event * Subscriber consume creates receives Event Channel attachPublisher detachPublisher attachSubscriber detachSubscriber pushEvent Filter filterEvent Publisher produce Structure attachSubscriber produce pushEvent event event pushEvent consume detachSubscriber : Event : Subscriber : Event Channel : Publisher Dynamics
  35. 35. 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 WTS Air Frame Publishers Subscribers push(event) push(event) Event Channel 3: Sensor publishers push events to event channel <ul><li>Considerations for implementing the Publisher-Subscriber pattern for mission computing applications include: </li></ul><ul><ul><li>Event notification model </li></ul></ul><ul><ul><ul><li>Push control vs. pull data interactions </li></ul></ul></ul><ul><ul><li>Scheduling & synchronization strategies </li></ul></ul><ul><ul><ul><li>e.g., priority-based dispatching & preemption </li></ul></ul></ul><ul><ul><li>Event dependency management </li></ul></ul><ul><ul><ul><li>e.g.,filtering & correlation mechanisms </li></ul></ul></ul><ul><li>Bold Stroke uses the Publisher-Subscriber pattern to decouple sensor processing from mission computing operations </li></ul><ul><ul><li>Anonymous publisher & subscriber relationships </li></ul></ul><ul><ul><li>Group communication </li></ul></ul><ul><ul><li>Asynchrony </li></ul></ul>
  36. 36. Ensuring Platform-neutral & Network-transparent Communication Wrapper Facade Layers Component internal partitioning Remoting Error Lookup Requestor Object Adapter Container Facade Business Delegate Invoker Client Proxy OS abstraction request issuing request reception error notification Broker configuration component discovery request dispatching request dispatching b roker access component access component access component creation Message Publisher- Subscriber Factory Method request encapsulation publish- subscribe communication Broker <ul><li>Apply the Broker architectural pattern to provide platform-neutral communication between mission computing boards </li></ul><ul><li>Applications need capabilities to: </li></ul><ul><ul><li>Support remote communication </li></ul></ul><ul><ul><li>Provide location transparency </li></ul></ul><ul><ul><li>Handle faults </li></ul></ul><ul><ul><li>Manage end-to-end QoS </li></ul></ul><ul><ul><li>Encapsulate low-level system details </li></ul></ul><ul><li>Mission computing requires remote IPC </li></ul><ul><li>Stringent DRE requirements </li></ul>Solution Problems Context
  37. 37. Ensuring Platform-neutral & Network-transparent Communication operation (params) connect send_request marshal unmarshal dispatch operation (params) result marshal receive_reply unmarshal result start_up register_service assigned port Dynamics : Broker : Client Proxy : Object Adapter : Client : Server <ul><li>Apply the Broker architectural pattern to provide platform-neutral communication between mission computing boards </li></ul><ul><li>Applications need capabilities to: </li></ul><ul><ul><li>Support remote communication </li></ul></ul><ul><ul><li>Provide location transparency </li></ul></ul><ul><ul><li>Handle faults </li></ul></ul><ul><ul><li>Manage end-to-end QoS </li></ul></ul><ul><ul><li>Encapsulate low-level system details </li></ul></ul><ul><li>Mission computing requires remote IPC </li></ul><ul><li>Stringent DRE requirements </li></ul>Solution Problems Context
  38. 38. 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 <ul><li>Bold Stroke uses the Broker pattern to shield distributed applications from environment heterogeneity, e.g., </li></ul><ul><ul><li>Programming languages </li></ul></ul><ul><ul><li>Operating systems </li></ul></ul><ul><ul><li>Networking protocols </li></ul></ul><ul><ul><li>Hardware </li></ul></ul>3: Broker handles I/O via upcalls Broker <ul><li>A key consideration for implementing the Broker pattern for mission computing applications is QoS support </li></ul><ul><ul><ul><li>e.g., latency, jitter, priority preservation, dependability, security, etc. </li></ul></ul></ul>
  39. 39. <ul><li>Enables reuse of software architectures & designs </li></ul><ul><li>Improves development team communication </li></ul><ul><li>Convey “best practices” intuitively </li></ul><ul><li>Transcends language-centric biases/myopia </li></ul><ul><li>Abstracts away from many unimportant details </li></ul>Benefits of Patterns www.cs.wustl.edu/ ~schmidt/patterns.html Hardware (CPU, Memory, I/O) Networking Interfaces Operating System Middleware Infrastructure Mission Computing Services GPS IFF FLIR HUD Nav WTS Air Frame Publishers Subscribers push(event) push(event) Event Channel Broker
  40. 40. <ul><li>Require significant tedious & error-prone human effort to handcraft pattern implementations </li></ul><ul><li>Can be deceptively simple </li></ul><ul><li>Leaves some important details unresolved </li></ul>Limitations of Patterns www.cs.wustl.edu/ ~schmidt/patterns.html Hardware (CPU, Memory, I/O) Networking Interfaces Operating System Middleware Infrastructure Mission Computing Services GPS IFF FLIR HUD Nav WTS Air Frame Publishers Subscribers push(event) push(event) Event Channel Broker
  41. 41. Software Design Abstractions for Concurrent & Networked Applications <ul><li>Problem </li></ul><ul><li>Distributed app & middleware functionality is subject to change since it’s often reused in unforeseen contexts, e.g., </li></ul><ul><ul><li>Accessed from different clients </li></ul></ul><ul><ul><li>Run on different platforms </li></ul></ul><ul><ul><li>Configured into different run-time contexts </li></ul></ul>MIDDLEWARE <ul><li>Solution </li></ul><ul><li>Don‘t structure distributed applications & middleware as a monolithic spagetti </li></ul><ul><li>Instead, decompose them into modular classes , frameworks , & components </li></ul>
  42. 42. Overview of Frameworks Framework Characteristics Application-specific functionality <ul><li>Frameworks exhibit “inversion of control” at runtime via callbacks </li></ul>Networking Database GUI <ul><li>Frameworks provide integrated domain-specific structures & functionality </li></ul>Mission Computing E-commerce Scientific Visualization <ul><li>Frameworks are “semi-complete” applications </li></ul>
  43. 43. Comparing Class Libraries, Frameworks, & Components Class Libraries Frameworks Macro-level Meso-level Micro-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 Locks IPC Math LOCAL INVOCATIONS APPLICATION- SPECIFIC FUNCTIONALITY EVENT LOOP GLUE CODE 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 Locking Logging Events
  44. 44. Using Frameworks Effectively <ul><li>Observations </li></ul><ul><li>Frameworks are powerful, but hard to develop & use effectively by application developers </li></ul><ul><ul><li>It’s often better to use & customize COTS frameworks than to develop in-house frameworks </li></ul></ul><ul><li>Components are easier for application developers to use, but aren’t as powerful or flexible as frameworks </li></ul>Successful projects are therefore often organized using the “funnel” model
  45. 45. Overview of the ACE Frameworks <ul><li>Features </li></ul><ul><li>Open-source </li></ul><ul><li>6+ integrated frameworks </li></ul><ul><li>250,000+ lines of C++ </li></ul><ul><li>60+ person-years of effort </li></ul><ul><li>Ported to Windows, UNIX, & real-time operating systems </li></ul><ul><ul><li>e.g., VxWorks, pSoS, LynxOS, Chorus, QNX </li></ul></ul><ul><li>Large user community </li></ul><ul><ul><li>www.cs.wustl.edu/~schmidt/ACE.html </li></ul></ul>Acceptor Connector Service Configurator Stream Reactor Proactor Task Application- specific functionality
  46. 46. The Layered Architecture of ACE <ul><li>Features </li></ul><ul><li>Open-source </li></ul><ul><li>250,000+ lines of C++ </li></ul><ul><li>40+ person-years of effort </li></ul><ul><li>Ported to Win32, UNIX, & RTOSs </li></ul><ul><ul><li>e.g., VxWorks, pSoS, LynxOS, Chorus, QNX </li></ul></ul><ul><li>Large open-source user community </li></ul><ul><ul><li>www.cs.wustl.edu/~schmidt/ACE-users.html </li></ul></ul><ul><li>Commercial support by Riverace </li></ul><ul><ul><li>www.riverace.com/ </li></ul></ul>www.cs.wustl.edu/~schmidt/ACE.html
  47. 47. Key Capabilities Provided by ACE Service Access & Control Event Handling Concurrency Synchronization
  48. 48. The POSA2 Pattern Language <ul><li>Pattern Benefits </li></ul><ul><ul><li>Preserve crucial design information used by applications & middleware frameworks & components </li></ul></ul><ul><ul><li>Facilitate reuse of proven software designs & architectures </li></ul></ul><ul><ul><li>Guide design choices for application developers </li></ul></ul>
  49. 49. POSA2 Pattern Abstracts Service Access & Configuration Patterns The Wrapper Facade design pattern encapsulates the functions & data provided by existing non-object-oriented APIs within more concise, robust, portable, maintainable, & cohesive object-oriented class interfaces. The Component Configurator design pattern allows an application to link & unlink its component implementations at run-time without having to modify, recompile, or statically relink the application. Component Configurator further supports the reconfiguration of components into different application processes without having to shut down & re-start running processes. The Interceptor architectural pattern allows services to be added transparently to a framework & triggered automatically when certain events occur. The Extension Interface design pattern allows multiple interfaces to be exported by a component, to prevent bloating of interfaces & breaking of client code when developers extend or modify the functionality of the component. Event Handling Patterns The Reactor architectural pattern allows event-driven applications to demultiplex & dispatch service requests that are delivered to an application from one or more clients. The Proactor architectural pattern allows event-driven applications to efficiently demultiplex & dispatch service requests triggered by the completion of asynchronous operations, to achieve the performance benefits of concurrency without incurring certain of its liabilities. The Asynchronous Completion Token design pattern allows an application to demultiplex & process efficiently the responses of asynchronous operations it invokes on services. The Acceptor-Connector design pattern decouples the connection & initialization of cooperating peer services in a networked system from the processing performed by the peer services after they are connected & initialized.
  50. 50. POSA2 Pattern Abstracts (cont’d) Synchronization Patterns The Scoped Locking C++ idiom ensures that a lock is acquired when control enters a scope & released automatically when control leaves the scope, regardless of the return path from the scope. The Strategized Lockin g design pattern parameterizes synchronization mechanisms that protect a component’s critical sections from concurrent access. The Thread-Safe Interface design pattern minimizes locking overhead & ensures that intra-component method calls do not incur ‘self-deadlock’ by trying to reacquire a lock that is held by the component already. The Double-Checked Locking Optimization design pattern reduces contention & synchronization overhead whenever critical sections of code must acquire locks in a thread-safe manner just once during program execution. Concurrency Patterns The Active Object design pattern decouples method execution from method invocation to enhance concurrency & simplify synchronized access to objects that reside in their own threads of control. The Monitor Object design pattern synchronizes concurrent method execution to ensure that only one method at a time runs within an object. It also allows an object’s methods to cooperatively schedule their execution sequences. The Half-Sync/Half-Async architectural pattern decouples asynchronous & synchronous service processing in concurrent systems, to simplify programming without unduly reducing performance. The pattern introduces two intercommunicating layers, one for asynchronous & one for synchronous service processing. The Leader/Followers architectural pattern provides an efficient concurrency model where multiple threads take turns sharing a set of event sources in order to detect, demultiplex, dispatch, & process service requests that occur on the event sources. The Thread-Specific Storage design pattern allows multiple threads to use one ‘logically global’ access point to retrieve an object that is local to a thread, without incurring locking overhead on each object access.
  51. 51. Implementing the Broker Pattern for Bold Stroke Avionics <ul><li>CORBA is a distribution middleware standard </li></ul><ul><li>Real-time CORBA adds QoS to classic CORBA to control: </li></ul>www.omg.org <ul><ul><li>3. Memory Resources </li></ul></ul><ul><li>These capabilities address some (but by no means all) important DRE application development & QoS-enforcement challenges </li></ul>2. Communication Resources <ul><ul><li>1. Processor Resources </li></ul></ul>Request Buffering Protocol Properties Explicit Binding Client Propagation & Server Declared Priority Models Portable Priorities Thread Pools Static Scheduling Service Standard Synchonizers
  52. 52. Example of Applying Patterns & Frameworks to Middleware : Real-time CORBA & The ACE ORB (TAO) <ul><li>TAO Features </li></ul><ul><li>Open-source </li></ul><ul><li>500,000+ lines of C++ </li></ul><ul><li>ACE/patterns-based </li></ul><ul><li>50+ person-years of effort </li></ul><ul><li>Ported to UNIX, Win32, MVS, & many RT & embedded OSs </li></ul><ul><ul><li>e.g., VxWorks, LynxOS, Chorus, QNX </li></ul></ul>www.cs.wustl.edu/~schmidt/TAO.html <ul><li>Large open-source user community </li></ul><ul><ul><li>www.cs.wustl.edu/~schmidt/ TAO-users.html </li></ul></ul><ul><li>Commercially supported </li></ul><ul><ul><li>www.theaceorb.com , www.remedy.nl , www.prismtechnologies.com </li></ul></ul>Protocol Properties Explicit Binding Thread Pools Scheduling Service Standard Synchronizers Portable Priorities End-to-end Priority Propagation
  53. 53. Key Patterns Used in TAO www.cs.wustl.edu/~schmidt/PDF/ORB-patterns.pdf <ul><li>Wrapper facades enhance portability </li></ul><ul><li>Proxies & adapters simplify client & server applications, respectively </li></ul><ul><li>Component Configurator dynamically configures Factories </li></ul><ul><li>Factories produce Strategies </li></ul><ul><li>Strategies implement interchangeable policies </li></ul><ul><li>Concurrency strategies use Reactor & Leader/Followers </li></ul><ul><li>Acceptor-Connector decouples connection management from request processing </li></ul><ul><li>Managers optimize request demultiplexing </li></ul>
  54. 54. Enhancing ORB Flexibility w/the Strategy Pattern <ul><li>Apply the Strategy pattern to factory out commonality amongst variable ORB algorithms & policies </li></ul><ul><li>Flexible ORBs must support multiple event & request demuxing, scheduling, (de)marshaling, connection mgmt, request transfer, & concurrency policies </li></ul><ul><li>Multi-domain resuable middleware framework </li></ul>Solution Problem Context 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
  55. 55. Consolidating Strategies with the Abstract Factory Pattern <ul><li>Apply the Abstract Factory pattern to consolidate multiple ORB strategies into semantically compatible configurations </li></ul><ul><li>Aggressive use of Strategy pattern creates a configuration nightmare </li></ul><ul><ul><li>Managing many individual strategies is hard </li></ul></ul><ul><ul><li>It’s hard to ensure that groups of semantically compatible strategies are configured </li></ul></ul><ul><li>A heavily strategized framework or application </li></ul>Solution Problem Context Concrete factories create groups of strategies
  56. 56. Dynamically Configuring Factories w/the Component Configurator Pattern <ul><li>Apply the Component Configurator pattern to assemble the desired ORB factories (& thus strategies) dynamically </li></ul><ul><li>Prematurely commiting to a particular ORB configuration is inflexible & inefficient </li></ul><ul><ul><li>Certain decisions can’t be made until runtime </li></ul></ul><ul><ul><li>Forcing users to pay for components they don’t use is undesirable </li></ul></ul><ul><li>Resource constrained & highly dynamic environments </li></ul>Solution Problem Context <ul><li>ORB strategies are decoupled from when the strategy implementations are configured into an ORB </li></ul><ul><li>This pattern can reduce the memory footprint of an ORB </li></ul>
  57. 57. ACE Frameworks Used in TAO <ul><li>Reactor drives the ORB event loop </li></ul><ul><ul><li>Implements the Reactor & Leader/Followers patterns </li></ul></ul><ul><li>Acceptor-Connector decouples passive/active connection roles from GIOP request processing </li></ul><ul><ul><li>Implements the Acceptor-Connector & Strategy patterns </li></ul></ul><ul><li>Service Configurator dynamically configures ORB strategies </li></ul><ul><ul><li>Implements the Component Configurator & Abstract Factory patterns </li></ul></ul>www.cs.wustl.edu/~schmidt/PDF/ICSE-03.pdf
  58. 58. Summary of Pattern, Framework, & Middleware Synergies These technologies codify expertise of skilled researchers & developers There are now powerful feedback loops advancing these technologies <ul><li>Patterns codify expertise in the form of reusable architecture design themes & styles, which can be reused event when algorithms, components implementations, or frameworks cannot </li></ul><ul><li>Frameworks codify expertise in the form of reusable algorithms, component implementations, & extensible architectures </li></ul>Application-specific functionality Acceptor Connector Component Configurator Stream Reactor Proactor Task <ul><li>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 </li></ul>
  59. 59. Example: Electronic Medical Imaging Systems <ul><li>Goal </li></ul><ul><li>Route, manage, & manipulate electronic medical images robustly, efficiently, & securely thoughout a distributed health care environment </li></ul>Modalities e.g., MRI, CT, CR, Ultrasound, etc.
  60. 60. Example: Electronic Medical Imaging Systems <ul><li>System Characteristics </li></ul><ul><li>Large volume of “blob” data </li></ul><ul><ul><li>e.g., 10 to 40 Mbps </li></ul></ul><ul><ul><li>“ Lossy” compression isn’t viable due to liability concerns </li></ul></ul><ul><li>Diverse QoS requirements, e.g., </li></ul><ul><ul><li>Sync & async communication </li></ul></ul><ul><ul><li>Event- & method-based invocation </li></ul></ul><ul><ul><li>Streaming communication </li></ul></ul><ul><ul><li>Prioritization of requests & streams </li></ul></ul><ul><ul><li>Distributed resource management </li></ul></ul>Modalities e.g., MRI, CT, CR, Ultrasound, etc.
  61. 61. Example: Electronic Medical Imaging Systems Key Software Solution Characteristics (e.g., www.syngo.com) <ul><li>Affordable, flexible, & COTS </li></ul><ul><ul><li>Product-line architecture </li></ul></ul><ul><ul><li>Design guided by patterns & frameworks </li></ul></ul><ul><ul><li>General-purpose & embedded OS platforms </li></ul></ul><ul><ul><li>Middleware technology agnostic </li></ul></ul>Modalities e.g., MRI, CT, CR, Ultrasound, etc.
  62. 62. Image Acquisition Scenario Modalities e.g., MRI, CT, CR, Ultrasound, etc. Image Xfer Interface Image Xfer Component Executor Xfer Proxy Factory Proxy Diagnostic & Clinical Workstations Radiology Client <ul><li>Key Tasks </li></ul><ul><li>Image location & routing </li></ul><ul><li>Image delivery </li></ul>Image Database 8. New 9. Return Ref 7.New 1. Deploy 3. Bind Factory Configuration Database Configuration Container 2. Enter info 6. Intercept & delegate 10. Invoke get_image() call 11. Query Config. 12. Check Authorization 5. Find Image 13. Activate Factory/Finder Security Service Naming Service 4. Find Factory 14. Delegate
  63. 63. Applying Patterns to Resolve Key Distributed System Design Challenges Patterns help resolve the following common design challenges: <ul><li>Decoupling suppliers & consumers </li></ul><ul><li>Locating & creating components scalably </li></ul><ul><li>Extending components transparently </li></ul><ul><li>Minimizing resource utilization </li></ul><ul><li>Enhancing server (re)configurability </li></ul><ul><li>Separating concerns between tiers </li></ul><ul><li>Improving type-safety & performance </li></ul><ul><li>Enabling client extensibility </li></ul><ul><li>Ensuring platform-neutral & network-transparent OO communication </li></ul><ul><li>Supporting async communication </li></ul><ul><li>Supporting OO async communication </li></ul>Image Xfer Interface Configuration Database Configuration Container Image Xfer Component Servant Xfer Proxy Factory Proxy Image Database Factory/Finder Security Service Naming Service Radiology Client Proxy Broker Active Object Publisher- Subscriber Component Configurator Extension Interface Factory/Finder Messaging Layers Interceptor Activator
  64. 64. Separating Concerns Between Tiers <ul><li>Solution </li></ul><ul><li>Apply the Layers pattern (P1) to create a multi-tier architecture that separates concerns between groups of tasks occurring at distinct layers in the distributed system </li></ul><ul><li>Context </li></ul><ul><li>Distributed systems are now common due to the advent of </li></ul><ul><ul><li>The global Internet </li></ul></ul><ul><ul><li>Ubiquitous mobile & embedded devices </li></ul></ul><ul><li>Problem </li></ul><ul><li>It’s hard to build distributed systems due to the complexity associated with many capabilities at many levels of abstraction </li></ul><ul><li>Services in the middle tier participate in various types of tasks, e.g., </li></ul><ul><ul><li>Workflow of integrated “business” processes </li></ul></ul><ul><ul><li>Connect to databases & other backend systems for data storage & access </li></ul></ul><ul><li>Database Tier </li></ul><ul><li>e.g., persistent data </li></ul>DB Server DB Server <ul><li>Middle Tier </li></ul><ul><li>e.g., common business logic </li></ul>comp comp Application Server <ul><li>Presentation Tier </li></ul><ul><li>e.g., thin client </li></ul><ul><li>displays </li></ul>Client Client
  65. 65. Applying the Layers Pattern to Image Acquisition <ul><li>Image servers are middle tier entities that: </li></ul><ul><ul><li>Provide server-side functionality </li></ul></ul><ul><ul><ul><li>e.g., they are responsible for scalable concurrency & networking </li></ul></ul></ul><ul><ul><li>Can run in their own address space </li></ul></ul><ul><ul><li>Are integrated into containers that hide low-level OS platform details </li></ul></ul><ul><li>Diagnostic & clinical workstations are presentation tier entities that: </li></ul><ul><ul><li>Typically represent sophisticated GUI elements </li></ul></ul><ul><ul><li>Share the same address space with their clients </li></ul></ul><ul><ul><ul><li>Their clients are containers that provide all the resources </li></ul></ul></ul><ul><ul><li>Exchange messages with the middle tier components </li></ul></ul>Image Database Patient Database <ul><li>Database Tier </li></ul><ul><li>e.g., persistent image data </li></ul><ul><li>Middle Tier </li></ul><ul><li>e.g., image routing, security, & image transfer logic </li></ul>comp comp Image Servers <ul><li>Presentation Tier </li></ul><ul><li>e.g., radiology clients </li></ul>Diagnostic Workstations Clinical Workstations
  66. 66. Pros & Cons of the Layers Pattern <ul><li>This pattern has four benefits : </li></ul><ul><li>Reuse of layers </li></ul><ul><ul><li>If an individual layer embodies a well-defined abstraction & has a well-defined & documented interface, the layer can be reused in multiple contexts </li></ul></ul><ul><li>Support for standardization </li></ul><ul><ul><li>Clearly-defined & commonly-accepted levels of abstraction enable the development of standardized tasks & interfaces </li></ul></ul><ul><li>Dependencies are localized </li></ul><ul><ul><li>Standardized interfaces between layers usually confine the effect of code changes to the layer that is changed </li></ul></ul><ul><li>Exchangeability </li></ul><ul><ul><li>Individual layer implementations can be replaced by semantically-equivalent implementations without undue effort </li></ul></ul><ul><li>This pattern also has liabilities : </li></ul><ul><li>Cascades of changing behavior </li></ul><ul><ul><li>If layer interfaces & semantics aren’t abstracted properly then changes can ripple when behavior of a layer is modified </li></ul></ul><ul><li>Higher overhead </li></ul><ul><ul><li>A layered architecture can be less efficient than a monolithic architecture </li></ul></ul><ul><li>Unnecessary work </li></ul><ul><ul><li>If some services performed by lower layers perform excessive or duplicate work not actually required by the higher layer, performance can suffer </li></ul></ul><ul><li>Difficulty of establishing the correct granularity of layers </li></ul><ul><ul><li>It’s important to avoid too many & too few layers </li></ul></ul>
  67. 67. Overview of Distributed Object Computing Communication Mechanisms <ul><li>Solution </li></ul><ul><li>DOC middleware provides multiple types of communication mechanisms: </li></ul><ul><ul><li>Collocated client/server ( i.e., native function call) </li></ul></ul><ul><ul><li>Synchronous & asynchronous RPC/IPC </li></ul></ul><ul><ul><li>Group communication & events </li></ul></ul><ul><ul><li>Data streaming </li></ul></ul><ul><li>Problem </li></ul><ul><li>A single communication mechanism does not fit all uses! </li></ul>Context In multi-tier systems both the tiers & the components within the tiers must be connected via communication mechanisms We now explore various distribution infrastructure (P4) patterns that applications can apply to leverage these communication mechanisms
  68. 68. Core Distribution Infrastructure Patterns <ul><li>Broker makes invocations on remote component objects look & act as much as possible like invocations on component objects in the same address space as their clients </li></ul><ul><li>Messaging & Publisher-Subscriber are most appropriate for integration scenarios where multiple, independently developed & self-contained services or applications must collaborate & form a coherent software system </li></ul>Event Formats One-to-Many Events Publisher/ Subscriber Communication Endpoints & Message Formats Many-to-One Message Messaging Component Interfaces One-to-One Remote Method Invocation Broker Component Dependencies Communication Relationship Communication Style Pattern
  69. 69. Improving Type-safety & Performance (1/2) <ul><li>Context </li></ul><ul><li>The configuration of components in distributed systems is often subject to change as requirements evolve </li></ul><ul><li>Problems </li></ul><ul><li>Low-level message passing (e.g., using sockets) is error-prone & fraught with accidental complexity </li></ul><ul><li>Remote components should look like local components from an application perspective </li></ul><ul><ul><li>i .e., ideally clients & servers should be oblivious to communication mechanisms & locations </li></ul></ul>
  70. 70. Improving Type-safety & Performance (2/2) <ul><li>A Service implements the object, which is not accessible directly </li></ul><ul><li>A Proxy represents the Service & ensures the correct access to it </li></ul><ul><ul><li>Proxy offers same interface as Service </li></ul></ul><ul><li>Clients use the Proxy to access the Service </li></ul>Client 1 1 Solution Apply the Proxy design pattern (P1, GoF) to provide an OO surrogate through which clients can access remote objects Proxy service Service service AbstractService service : Service : Proxy : Client service service pre-processing: e.g.,marshaling post-processing: e.g., unmarshaling
  71. 71. Applying the Proxy Pattern to Image Acquisition Client 1 1 We can apply the Proxy pattern to provide a strongly-typed interface to initiate & coordinate the downloading of images from an image database <ul><li>Proxies that are generated automatically by middleware can be optimized to be much more efficient than manual message passing </li></ul><ul><ul><li>e.g., improved memory management, data copying, & compiled marshaling/demarshaling </li></ul></ul>Proxy get_image() Sync Image Xfer get_image() Image Xfer get_image() Image Xfer Service Xfer Proxy Image Database Radiology Client Invoke get_image() call
  72. 72. Pros & Cons of the Proxy Pattern <ul><li>This pattern provides three benefits : </li></ul><ul><li>Decoupling clients from the location of server components </li></ul><ul><ul><li>Clients are not affected by migration of servers or changes in the networking infrastructure since location information & addressing functionality is managed by a proxy </li></ul></ul><ul><li>Separation of housekeeping & functionality </li></ul><ul><ul><li>A proxy relieves clients from burdens that do not inherently belong to the task the client performs </li></ul></ul><ul><li>Potential for time & space optimizations </li></ul><ul><ul><li>Proxy implementations can be loaded “on-demand” & can also be used to cache values to avoid redundant remote calls </li></ul></ul><ul><ul><li>Proxies can also be optimized to improve both type-safety & performance </li></ul></ul><ul><li>This pattern has two liabilities : </li></ul><ul><li>Potential overkill via sophisticated strategies </li></ul><ul><ul><li>If proxies include overly sophisticated functionality, such as caching or replica management, they many introduce overhead that defeats their intended purpose </li></ul></ul><ul><li>Higher overhead due to indirection </li></ul><ul><ul><li>Proxies introduce an additional layer of indirection that can be excessive if the proxy implementation is inefficient </li></ul></ul>
  73. 73. Enabling Client Extensibility (1/2) <ul><li>Context </li></ul><ul><li>Object models define how components import & export functionality </li></ul><ul><ul><li>e.g., UML class diagrams specify well-defined OO interfaces </li></ul></ul>Class X operation 1 () operation 2 () operation 3 () operation n () <ul><li>Problem </li></ul><ul><li>Many object models assign a single interface to each component </li></ul><ul><li>This design makes it hard to evolve components without either </li></ul><ul><ul><li>Breaking existing client interface s </li></ul></ul><ul><ul><li>Bloating client interfaces </li></ul></ul>operation() Object : Class X : Client
  74. 74. Enabling Client Extensibility (2/2) <ul><li>Solution </li></ul><ul><li>Apply the Extension Interface design pattern (P2), which allows multiple interfaces to be exported by a component, to prevent breaking of client code & bloating of interfaces when developers extend or modify component functionality </li></ul>createComponent Factory * * CreateInstance createComponent Component new * 1 queryInterface Root Implemented by 1+ <<extends>> Ask for a reference to an interface Call an operation on an interface initialize uninititialize Server queryInterface service_i Extension Interface i callService Client queryInterface() : Client operation()
  75. 75. Extension Interface Pattern Dynamics : Client Start_client : Factory createInstance(Ext.Intf. 1) new Ref. To Extension1 create create service_1 queryInterface(Extension Interface 2) Ref. To Extension2 Note how each extension interface can serve as a “factory” to return object reference to other extension interfaces supported by a component : Component : Extension 1 : Extension 2 service_2 <ul><li>A common use of the Extension Interface pattern is to support component versioning </li></ul><ul><ul><li>Off-loads versioning protocol to client… </li></ul></ul>service2
  76. 76. Pros & Cons of the Extension Interface Pattern <ul><li>This pattern has five benefits : </li></ul><ul><ul><li>Separation of concerns </li></ul></ul><ul><ul><ul><li>Interfaces are strictly decoupled from implementations </li></ul></ul></ul><ul><ul><li>Exchangeability of components </li></ul></ul><ul><ul><ul><li>Component implementations can evolve independently from clients that access them </li></ul></ul></ul><ul><ul><li>Extensibility through interfaces </li></ul></ul><ul><ul><ul><li>Clients only access components via their interfaces, which reduces coupling to representation & implementation details </li></ul></ul></ul><ul><ul><li>Prevention of interface bloating </li></ul></ul><ul><ul><ul><li>Interfaces need not contain all possible methods, just the ones associated with a particular capability </li></ul></ul></ul><ul><ul><li>No subclassing required </li></ul></ul><ul><ul><ul><li>Delegation—rather than inheritance—is used to customize components </li></ul></ul></ul><ul><li>This pattern also has liabilities : </li></ul><ul><ul><li>Higher overhead due to indirection </li></ul></ul><ul><ul><ul><li>Clients must incur the overhead of several round-trips to obtain the appropriate object reference from a server component </li></ul></ul></ul><ul><ul><li>Complexity & cost for development & deployment </li></ul></ul><ul><ul><ul><li>This pattern off-loads the responsibility for determining the appropriate interface from the component designer to the client applications </li></ul></ul></ul>
  77. 77. Ensuring Platform-neutral & Network-transparent OO Communication (1/2) <ul><li>Problem </li></ul><ul><li>A middleware architecture needs to : </li></ul><ul><ul><li>Support remote method invocation </li></ul></ul><ul><ul><li>Provide location transparency </li></ul></ul><ul><ul><li>Detect & recover from faults </li></ul></ul><ul><ul><li>Allow the addition, exchange, or remove of services dynamically </li></ul></ul><ul><ul><li>Hide system details from developers </li></ul></ul><ul><li>Context </li></ul><ul><li>The Proxy & Extension Interface patterns aren’t sufficient since they don’t address how </li></ul><ul><ul><li>Remote components are located </li></ul></ul><ul><ul><li>Connections are established </li></ul></ul><ul><ul><li>Messages are exchanged across a network </li></ul></ul><ul><ul><li>etc. </li></ul></ul>Client 1 1 Proxy service Service service AbstractService service
  78. 78. Ensuring Platform-neutral & Network-transparent OO Communication (2/2) <ul><li>Solution </li></ul><ul><li>Apply the Broker architectural pattern (P1) to provide OO platform-neutral communication between networked client & server components </li></ul>Wrapper Facade Layers Component internal partitioning Remoting Error Lookup Requestor Object Adapter Container Facade Business Delegate Invoker Client Proxy OS abstraction request issuing request reception error notification Broker configuration component discovery request dispatching request dispatching b roker access component access component access component creation Message Publisher- Subscriber Factory Method request encapsulation publish- subscribe communication Broker
  79. 79. Broker Pattern Dynamics method (proxy) locate_server server port send_request marshal unmarshal dispatch method (impl.) result marshal receive_reply unmarshal result start_up register_service : Broker : Client Proxy : Server Proxy : Client : Server assigned port Broker middleware generates the necessary client & server proxies from higher level interface definitions Proxy Generator Proxy Code Interface Specif.
  80. 80. Applying the Broker Pattern to Image Acquisition <ul><li>Common Broker pattern implementations </li></ul><ul><ul><li>CORBA </li></ul></ul><ul><ul><li>COM+ </li></ul></ul><ul><ul><li>Java RMI </li></ul></ul><ul><ul><li>Med-specific Comm (MSC) </li></ul></ul><ul><li>Brokers define interfaces… </li></ul><ul><ul><li>… not implementations </li></ul></ul><ul><li>Brokers simplify development of distributed applications by automating </li></ul><ul><ul><li>Object location </li></ul></ul><ul><ul><li>Connection management </li></ul></ul><ul><ul><li>Memory management </li></ul></ul><ul><ul><li>Parameter (de)marshaling </li></ul></ul><ul><ul><li>Event & request demuxing </li></ul></ul><ul><ul><li>Error handling </li></ul></ul><ul><ul><li>Object/server activation </li></ul></ul><ul><ul><li>Concurrency </li></ul></ul><ul><li>Brokers help shield distributed applications from environment heterogeneity </li></ul><ul><ul><li>e.g., programming languages, operating systems, networking protocols, hardware, etc. </li></ul></ul>Container OS & Protocols Communication Infrastructure OS & Protocols Client Proxy Server Proxy Object Adapter Image Xfer Component Client Common Services Broker Interface
  81. 81. Pros & Cons of the Broker Pattern <ul><li>This pattern has five benefits : </li></ul><ul><ul><li>Portability enhancements </li></ul></ul><ul><ul><ul><li>A broker hides OS & network system details from clients & servers by using indirection & abstraction layers, such as APIs, proxies, adapters, & bridges </li></ul></ul></ul><ul><ul><li>Interoperability with other brokers </li></ul></ul><ul><ul><ul><li>Different brokers may interoperate if they understand a common protocol for exchanging messages </li></ul></ul></ul><ul><ul><li>Reusability of services </li></ul></ul><ul><ul><ul><li>When building new applications, brokers enable application functionality to reuse existing services </li></ul></ul></ul><ul><ul><li>Location transparency </li></ul></ul><ul><ul><ul><li>A broker is responsible for locating servers, so clients need not know where servers are located </li></ul></ul></ul><ul><ul><li>Changeability & extensibility of components </li></ul></ul><ul><ul><ul><li>If server implementations change without affecting interfaces clients should not be affected </li></ul></ul></ul><ul><li>This pattern also has liabilities : </li></ul><ul><ul><li>Higher overhead </li></ul></ul><ul><ul><ul><li>Applications using brokers may be slower than applications written manually </li></ul></ul></ul><ul><ul><li>Potentially less reliable </li></ul></ul><ul><ul><ul><li>Compared with non-distributed software applications, distributed broker systems may incur lower fault tolerance </li></ul></ul></ul><ul><ul><li>Testing & debugging may be harder </li></ul></ul><ul><ul><ul><li>Testing & debugging of distributed systems is tedious because of all the components involved </li></ul></ul></ul>
  82. 82. Supporting Async Communication (1/2) <ul><li>Context </li></ul><ul><li>Some clients want to send requests, continue their work, & receive the results at some later point in time </li></ul><ul><li>Problem </li></ul><ul><li>Broker implementations based on conventional RPC semantics often just support blocking operations </li></ul><ul><ul><li>i.e., clients must wait until twoway invocations return </li></ul></ul><ul><li>Unfortunately, this design can reduce scalability & complicate certain use-cases </li></ul>
  83. 83. Supporting Async Communication (1/2) <ul><li>Solution </li></ul><ul><li>Apply the Messaging (P4/EIP) pattern to allow asynchronous communication between clients & servers </li></ul><ul><li>Introduce intermediary queue(s) between clients & servers : </li></ul><ul><ul><li>A queue is used to store messages </li></ul></ul><ul><ul><ul><li>A queue can cooperate with other queues to route messages </li></ul></ul></ul><ul><ul><li>Messages are sent from sender to receiver </li></ul></ul><ul><ul><li>A client sends a message, which is queued & then forwarded to a message processor on a server that receives & executes them </li></ul></ul><ul><ul><li>A Message API is provided for clients & servers to send/receive messages </li></ul></ul>
  84. 84. Messaging Pattern Dynamics : Client : Message create store Message forward Message : Message Processor create receive receive Message Message exec send Message : Message API : Local Queue : Remote Queue : Message API Reply store forward Reply recv Reply send Reply recv Other processing
  85. 85. Applying the Messaging Pattern to Image Acquisition <ul><li>We can apply the Messaging pattern to </li></ul><ul><ul><li>Queue up image request messages remotely without blocking the diagnostic/clinical workstation clients </li></ul></ul><ul><ul><li>Execute the requests at a later point & return the results to the client </li></ul></ul><ul><li>This design also enables other, more advanced capabilities, e.g., </li></ul><ul><li>Multi-hop store & forward persistence </li></ul><ul><li>QoS-driven routing, where requests can be delivered to the “best” image database depending on context </li></ul>Local Queue store forward remove Message <<route>> Radiology Client Message API <<send>> Remote Queue store forward remove <<exec>> Message API <<recv>> Image Server Message Processor Image Xfer Service Image Database Radiology Client
  86. 86. Pros & Cons of the Messaging Pattern <ul><li>This pattern provides three benefits : </li></ul><ul><li>Enhances concurrency by transparently leveraging available parallelism </li></ul><ul><ul><li>Messages can be executed remotely on servers while clients perform other processing </li></ul></ul><ul><li>Simplifies synchronized access to a shared object that resides in its own thread of control </li></ul><ul><ul><li>Since messages are processed serially by a message processor target objects often need not be concerned with synchronization mechanisms </li></ul></ul><ul><li>Message execution order can differ from message invocation order </li></ul><ul><ul><li>This allows reprioritizing of messages to enhance quality of service </li></ul></ul><ul><ul><li>Messages can be “batched” & sent wholesale to enhance throughout </li></ul></ul><ul><li>This pattern also has some liabilities : </li></ul><ul><li>Message execution order can differ from message invocation order </li></ul><ul><ul><li>As a result, clients must be careful not to rely on ordering dependencies </li></ul></ul><ul><li>Lack of type-safety </li></ul><ul><ul><li>Clients & servers are responsible for formatting & passing messages </li></ul></ul><ul><li>Complicated debugging </li></ul><ul><ul><li>As with all distributed systems, debugging & testing is complex </li></ul></ul>
  87. 87. Supporting OO Async Communication (1/2) <ul><li>Context </li></ul><ul><li>Some clients want to invoke remote operations, continue their work, & retrieve the results at a later point in time </li></ul><ul><li>Problem </li></ul><ul><li>Using the explicit message-passing API of the Messaging pattern can reduce type-safety & performance </li></ul><ul><ul><li>Similar to motivation for Proxy pattern... </li></ul></ul>Client Server Request messages Request messages Reply messages
  88. 88. Supporting OO Async Communication (2/2) <ul><li>Solution </li></ul><ul><li>Apply the Active Object design pattern (P2) to decouple method invocation from method execution using a strongly-typed OO programming model </li></ul><ul><li>A proxy provides an interface that allows clients to access methods of an object </li></ul><ul><li>A concrete method request is created for every method invoked on the proxy </li></ul><ul><li>A scheduler receives the method requests & dispatches them on the servant when they become runnable </li></ul><ul><li>An activation list maintains pending method requests </li></ul><ul><li>A servant implements the methods </li></ul><ul><li>A future allows clients to access the results of a method call on the proxy </li></ul>Future Scheduler enqueue dispatch MethodRequest guard call * Proxy method_1 method_n Activation List enqueue dequeue Servant method_1 method_n creates creates maintains Concrete MethodRequest1 Concrete MethodRequest2
  89. 89. Active Object Pattern Dynamics <ul><li>A client invokes a method on the proxy </li></ul><ul><li>The proxy returns a future to the client, & creates a method request, which it passes to the scheduler </li></ul><ul><li>The scheduler enqueues the method request into the activation list (not shown here) </li></ul><ul><li>When the method request becomes runnable, the scheduler dequeues it from the activation list (not shown here) & executes it in a different thread than the client </li></ul><ul><li>The method request executes the method on the servant & writes results, if any, to the future </li></ul><ul><li>Clients obtain the method’s results via the future </li></ul>Clients can obtain result from futures via blocking, polling, or callbacks : Future method enqueue : Proxy : Scheduler : Servant : Method Request dispatch call method read write : Client
  90. 90. Applying the Active Object Pattern to Image Acquisition <ul><li>OO developers often prefer method-oriented request/response semantics to message-oriented semantics </li></ul><ul><li>The Active Object pattern supports this preference via strongly-typed async method APIs: </li></ul><ul><ul><li>Several types of parameters can be passed: </li></ul></ul><ul><ul><ul><li>Requests contain in/inout arguments </li></ul></ul></ul><ul><ul><ul><li>Results carry out/inout arguments & results </li></ul></ul></ul><ul><ul><li>Callback object or poller object can be used to retrieve results </li></ul></ul>get_image() future results Future Scheduler enqueue dispatch MethodRequest guard call * Proxy method_1 method_n Activation List enqueue dequeue Servant method_1 method_n creates creates maintains get_image() put_image() Image Xfer Service Image Database Radiology Client
  91. 91. Pros & Cons of the Active Object Pattern <ul><li>This pattern provides four benefits : </li></ul><ul><li>Enhanced type-safety </li></ul><ul><ul><li>Cf. async forwarder/receiver message passing </li></ul></ul><ul><li>Enhances concurrency & simplifies synchronized complexity </li></ul><ul><ul><li>Concurrency is enhanced by allowing client threads & asynchronous method executions to run simultaneously </li></ul></ul><ul><ul><li>Synchronization complexity is simplified by using a scheduler that evaluates synchronization constraints to serialized access to servants </li></ul></ul><ul><li>Transparent leveraging of available parallelism </li></ul><ul><ul><li>Multiple active object methods can execute in parallel if supported by the OS/hardware </li></ul></ul><ul><li>Method execution order can differ from method invocation order </li></ul><ul><ul><li>Methods invoked asynchronous are executed according to the synchronization constraints defined by their guards & by scheduling policies </li></ul></ul><ul><ul><li>Methods can be “batched” & sent wholesale to enhance throughput </li></ul></ul><ul><li>This pattern also has some liabilities : </li></ul><ul><li>Higher overhead </li></ul><ul><ul><li>Depending on how an active object’s scheduler is implemented, context switching, synchronization, & data movement overhead may occur when scheduling & executing active object invocations </li></ul></ul><ul><li>Complicated debugging </li></ul><ul><ul><li>It is hard to debug programs that use the Active Object pattern due to the concurrency & non-determinism of the various active object schedulers & the underlying OS thread scheduler </li></ul></ul>
  92. 92. Decoupling Suppliers & Consumers (1/2) <ul><li>Problem </li></ul><ul><li>Having each client call a specific server is inefficient & non-scalable </li></ul><ul><ul><li>A “polling” strategy leads to performance bottlenecks </li></ul></ul><ul><ul><li>Work lists could be spread across different servers </li></ul></ul><ul><ul><li>More than one client may be interested in work list content </li></ul></ul><ul><li>Context </li></ul><ul><li>In large-scale electronic medical imaging systems, radiologists may share “work lists” of patient images to balance workloads effectively </li></ul>Image Database Radiology Client Radiology Client Radiology Client Radiology Client Radiology Client
  93. 93. Decoupling Suppliers & Consumers (2/2) <ul><li>Decouple suppliers (publishers) & consumers (subscribers) of events: </li></ul><ul><ul><li>An Event Channel stores/forwards events </li></ul></ul><ul><ul><li>Publishers create events & store them in a queue maintained by the Event Channel </li></ul></ul><ul><ul><li>Consumers register with event queues, from which they retrieve events </li></ul></ul><ul><ul><li>Events are used to transmit state change info from publishers to consumers </li></ul></ul><ul><ul><li>For event transmission push-models & pull-models are possible </li></ul></ul><ul><ul><li>Filters can filter events for consumers </li></ul></ul><ul><li>Solution </li></ul><ul><li>Apply the Publisher-Subscriber architectural pattern (P1) to decouple image suppliers from consumers </li></ul>Event * Subscriber consume creates receives Event Channel attachPublisher detachPublisher attachSubscriber detachSubscriber pushEvent Filter filter Publisher produce
  94. 94. Publisher-Subscriber Pattern Dynamics <ul><li>The Publisher-Subscriber pattern helps keep the state of cooperating components synchronized </li></ul><ul><li>To achieve this it enables one-way propagation of changes: one publisher notifies any number of subscribers about changes to its state </li></ul>attachSubscriber produce pushEvent event event pushEvent detachSubscriber : Event : Subscriber : Event Channel : Publisher <ul><li>Key design considerations for the Publisher-Subscriber pattern include: </li></ul><ul><li>Push vs. pull interaction models </li></ul><ul><li>Control vs. data event notification models </li></ul><ul><li>Multicast vs. unicast communication models </li></ul><ul><li>Persistence vs. transient queueing models </li></ul>consume
  95. 95. Applying the Publisher-Subscriber Pattern to Image Acquisition * creates receives Event Channel attachPublisher detachPublisher attachSubscriber detachSubscriber pushEvent <ul><li>Radiologists can subscribe to an event channel to receive notifications produced when modalities publish events indicating the arrival of new images & studies </li></ul><ul><li>This design enables a group of distributed radiologists to collaborate effectively in a networked environment </li></ul>Event Radiologist consume Filter filter Modality produce Image Database Radiology Client Radiology Client Radiology Client Radiology Client Radiology Client Event Channel
  96. 96. Pros & Cons of the Publisher-Subscriber Pattern <ul><li>This pattern has two benefits : </li></ul><ul><li>Decouples consumers & producers of events </li></ul><ul><ul><li>All an event channel knows is that it has a list of consumers, each conforming to the simple interface of the Subscriber class </li></ul></ul><ul><ul><li>The coupling between the publishers & subscribers is therefore abstract, anonymous, & minimal </li></ul></ul><ul><li>n:m communication models are supported </li></ul><ul><ul><li>Unlike an ordinary sync/async request/response invocation, the notification that a publisher sends needn’t designate its receiver, which enables a broader range of communication topologies, including multicast & broadcast </li></ul></ul><ul><li>There are also liabilities : </li></ul><ul><li>Must be careful with potential update cascades </li></ul><ul><ul><li>Since subscribers have no knowledge of each other’s presence, applications may not recognize the ultimate cost of publishing events through an event channel </li></ul></ul><ul><ul><li>A seemingly innocuous operation on the subject may therefore cause a cascade of updates to observers & their dependent objects </li></ul></ul><ul><li>Performance degradation relative to point-to-point request/response interactions </li></ul>
  97. 97. Locating & Creating Components Scalably (1/2) <ul><li>Context </li></ul><ul><li>Our electronic medical imaging system contains many components distributed in a network </li></ul><ul><li>Problem </li></ul><ul><li>How to create new components and/or find existing ones </li></ul><ul><ul><li>Simple solutions appropriate for stand-alone applications don’t scale </li></ul></ul><ul><ul><li>“ Obvious” distributed solutions also don’t scale </li></ul></ul>Modalities e.g., MRI, CT, CR, Ultrasound, etc.
  98. 98. Locating & Creating Components Scalably (2/2) <ul><li>An Abstract Home declares an interface for operations that find and/ or create abstract instances of components </li></ul><ul><li>Concrete Homes implement s the abstract Home interface to find specific instances and/or create new ones </li></ul><ul><li>Abstract Comp declare s interface for a specific type of component class </li></ul><ul><li>Concrete Comp define instances </li></ul><ul><li>A Primary Key is associated with a component </li></ul><ul><li>Solution </li></ul><ul><li>Apply the Factory/Finder (SCP) design pattern to separate the management of component lifecycle s from their use by client applications </li></ul>AbstractC omp operation ConcreteC omp operation Primary Key Concrete Home find create Abstract Home find create
  99. 99. Factory/Finder Pattern Dynamics <ul><li>Homes enable the creation & location of components, but we still need some type of general-purpose naming/directory service to locate the homes </li></ul><ul><li>The Factory/Finder pattern is supported by distributed component models </li></ul><ul><ul><li>e.g., EJB, COM+, & the CCM </li></ul></ul>find (“ImageXYZ”); Primary Key Component operation lookup : Client : Home : Component : Primary Key create Node Binding Directory * resolve listNodes navigate newBinding newSubDir remove getName getObject Client
  100. 100. Applying the Factory/Finder Pattern to Image Acquisition Image Xfer Interface Factory Proxy <ul><li>We can apply the Factory/Finder pattern to create/locate image transfer components for images needed by radiologists </li></ul><ul><li>If a suitable component already exists the component home will use it, otherwise, it will create a new component </li></ul>AbstractC omp operation ImageXferC omp operation Primary Key ImageXfer Home find create Abstract Home find create 1. Deploy 2. Bind Factory 4. Intercept & delegate 6. Find Image Factory/Finder Naming Service 3. Find Factory Image Database Radiology Client 5.New Configuration Container
  101. 101. Pros & Cons of the Factory/Finder Pattern <ul><li>This pattern has three benefits : </li></ul><ul><ul><li>Separation of concerns </li></ul></ul><ul><ul><ul><li>Finding/creating individual components is decoupled from locating the factories that find/create these components </li></ul></ul></ul><ul><ul><li>Improved scalability </li></ul></ul><ul><ul><ul><li>e.g., general-purpose directory mechanisms need not manage the creation & location of large amounts of finer-grained components whose lifetimes may be short </li></ul></ul></ul><ul><ul><li>Customized capabilities </li></ul></ul><ul><ul><ul><li>The location/creation mechanism can be specialized to support key capabilities that are unique for various types of components </li></ul></ul></ul><ul><li>This pattern also has some liabilities : </li></ul><ul><ul><li>Overhead due to indirection </li></ul></ul><ul><ul><ul><li>Clients must incur the overhead of several round-trips to obtain the appropriate object reference </li></ul></ul></ul><ul><ul><li>Complexity & cost for development & deployment </li></ul></ul><ul><ul><ul><li>There are more steps involved in obtaining object references, which can complicate client programming </li></ul></ul></ul>
  102. 102. Extending Components Transparently <ul><li>Context </li></ul><ul><li>Component developers may not know a priori the context in which their components will execute </li></ul><ul><li>Thus, containers are introduced to: </li></ul><ul><ul><li>Shield clients & components from the details of the underlying middleware, services, network, & OS </li></ul></ul><ul><ul><li>Manage the lifecycle of components & notify them about lifecycle events </li></ul></ul><ul><ul><ul><li>e.g., activation, passivation, & transaction progress </li></ul></ul></ul><ul><ul><li>Provide components with uniform access to middleware infrastructure services </li></ul></ul><ul><ul><ul><li>e.g., transactions, security, & persistence </li></ul></ul></ul><ul><ul><li>Register & deploy components </li></ul></ul>Declarative Programming Server Component Transaction Security Resources ... Server Component Transaction Security Resources ... ... Imperative Programming Client Client Container
  103. 103. Extending Components Transparently (cont‘d) <ul><li>Problem </li></ul><ul><li>Developers should be able to specify declaratively what type of execution environment components need </li></ul><ul><ul><li>e.g., in configuration files or databases </li></ul></ul><ul><li>Containers must be able to transparently provide the right execution environment </li></ul><ul><ul><li>e.g., by creating a new transaction or new servant when required </li></ul></ul><ul><li>Framework represents the concrete framework to which we attach interceptors </li></ul><ul><li>Concrete Interceptors implement the event handler for the system-specific events they have subscribed for </li></ul><ul><li>Context contains information about the event & allows modification of system behavior after interceptor completion </li></ul><ul><li>The Dispatcher allows applications to register & remove interceptors with the framework & to delegate events to interceptors </li></ul><ul><li>Solution </li></ul><ul><li>Apply the Interceptor architectural pattern (P2) to attach interceptors to a framework that can handle particular events by invoking associated interceptors automatically </li></ul>Context ConcreteInterceptor handle_event * callback provide Dispatcher attach Framework attach_interceptor manage_interceptors AbstractInterceptor handle_event
  104. 104. Interceptor Pattern Dynamics <ul><li>Interceptor are a “ meta-programming mechanism ,” along with </li></ul><ul><ul><li>Smart proxies </li></ul></ul><ul><ul><li>Pluggable protocols </li></ul></ul><ul><ul><li>Gateways/bridges </li></ul></ul><ul><ul><li>Interface repositories </li></ul></ul><ul><li>These mechanisms provide building-blocks to handle (often unanticipated) variation translucently & reflectively </li></ul><ul><li>More information on meta-programming mechanisms can be found at </li></ul><ul><li>Interception is commonly used to handle security & transactions transparently from the perspective of a component implementation </li></ul><ul><li>It can also enable performance enhancement strategies </li></ul><ul><ul><li>e.g., just-in-time activation, object pooling, load balancing, & caching </li></ul></ul>: Application : Framework : Interceptor create run_event_loop attach interceptor Place interceptor in internal interceptor map event Look for registered interceptors : Context create context handle_event : Dispatcher delegate www.cs.wustl.edu/~schmidt/PDF/IEEE.pdf
  105. 105. Applying the Interceptor Pattern to Image Acquisition <ul><li>A container provides generic interfaces to a component that it can use to access container functionality </li></ul><ul><ul><li>e.g., transaction control, persistence, security,load balancing etc. </li></ul></ul><ul><li>A container intercepts all incoming requests from clients, e.g., </li></ul><ul><ul><li>It can read the component ’ s requirements from a XML configuration file </li></ul></ul><ul><ul><li>It can then do some pre-processing before actually delegating the request to the component </li></ul></ul><ul><li>A component provides interfaces that its container invokes automatically when particular events occur </li></ul><ul><ul><li>e.g., activation or passivation </li></ul></ul>Interceptors are used for many other middleware tasks, as well Context Container handle_event * callback provide Dispatcher attach Image Server Framework attach_interceptor manage_interceptors AbstractInterceptor handle_event Container Component XML config
  106. 106. Pros & Cons of the Interceptor Pattern <ul><li>This pattern has five benefits : </li></ul><ul><li>Extensibility & flexibility </li></ul><ul><ul><li>Interceptors allow an application to evolve without breaking existing APIs & components </li></ul></ul><ul><li>Separation of concerns </li></ul><ul><ul><li>Interceptors decouple the “functional” path from the “meta” path </li></ul></ul><ul><li>Support for monitoring & control of frameworks </li></ul><ul><ul><li>e.g., generic logging mechanisms can be used to unobtrusively track application behavior </li></ul></ul><ul><li>Layer symmetry </li></ul><ul><ul><li>Interceptors can perform transformations on a client-side whose inverse are performed on the server-side </li></ul></ul><ul><li>Reusability </li></ul><ul><ul><li>Interceptors can be reused for various general-purpose behaviors </li></ul></ul><ul><li>This pattern also has liabilities : </li></ul><ul><li>Complex design issues </li></ul><ul><ul><li>Determining interceptor APIs & semantics is non-trivial </li></ul></ul><ul><li>Malicious or erroneous interceptors </li></ul><ul><ul><li>Mis-behaving interceptors can wreak havoc on application stability </li></ul></ul><ul><li>Potential interception cascades </li></ul><ul><ul><li>Interceptors can result in infinite recursion </li></ul></ul>
  107. 107. Minimizing Resource Utilization (1/2) <ul><li>Problem </li></ul><ul><li>It may not feasible to have all image server implementations running all the time since this ties up end-system resources unnecessarily </li></ul><ul><li>Context </li></ul><ul><li>Image servers are simply one of many services running throughout a distributed electronic medical image system </li></ul>
  108. 108. Minimizing Resource Utilization (2/2) <ul><li>Solution </li></ul><ul><li>Apply the Activator (PLoP12/P4) design pattern to automate scalable on-demand activation & deactivation of service execution contexts to run services accessed by many clients without consuming resources unnecessarily </li></ul>www.cs.wustl.edu/~schmidt/PDF/Activator.pdf <ul><li>When incoming requests arrive, the Activator looks up whether a target object is already active & if the object is not running it activates the Service Execution Context </li></ul><ul><li>The Activation Table stores associations between services & their physical location </li></ul><ul><li>The Client uses the Activator to get service access </li></ul><ul><li>A Service implements a specific type of functionality that it provides to clients </li></ul>
  109. 109. Activator Pattern Dynamics <ul><li>An Activator can be used to activate & passivate a server </li></ul><ul><ul><li>e.g., after each method call, after each transaction, etc. </li></ul></ul><ul><li>A container/component in a server can also passivate the server itself </li></ul>: Activator : Client getService : Implementation activate lookupEntry [not active] changeEntry object service result port onShutdown changeEntry : Activation Table
  110. 110. Applying the Activator Pattern to Image Acquisition Activator createService() findService() activate() deactivate() addService() remService() Activation Table lookup() insert() delete() getService useService() Server (ringil:5500) 2.1 start <ul><li>The Activator pattern is available in various COTS technologies: </li></ul><ul><ul><li>UNIX Inetd “super server” </li></ul></ul><ul><ul><li>CORBA Implementation Repository </li></ul></ul><ul><li>We can use the Activator pattern to launch image transfer servers on-demand </li></ul>iiop://ringil:5500/poa_name/object_name ImR (ringil:5000) Client ringil:4500 plane.exe airplane_poa server.exe poa_name ringil:5500 iiop://ringil:5000/poa_name/object_name Client ImageXferService service shutdown 1. some_request 4. LOCATION_FORWARD 2. ping 3. is_running 6. some_response 5. some_request
  111. 111. Pros & Cons of the Activator Pattern <ul><li>This pattern has three benefits : </li></ul><ul><li>More effective resource utilization </li></ul><ul><ul><li>Servers can be spawned “on-demand,” thereby minimizing resource utilization until clients actually require them </li></ul></ul><ul><li>Uniformity </li></ul><ul><ul><li>By imposing a uniform activation interface to spawn & control servers </li></ul></ul><ul><li>Modularity, testability, & reusability </li></ul><ul><ul><li>Application modularity & reusability is improved by decoupling server implementations from the manner in which the servers are activated </li></ul></ul><ul><li>This pattern also has liabilities : </li></ul><ul><ul><li>Lack of determinism & ordering dependencies </li></ul></ul><ul><ul><ul><li>This pattern makes it hard to determine or analyze the behavior of an application until its components are activated at run-time </li></ul></ul></ul><ul><ul><li>Reduced security or reliability </li></ul></ul><ul><ul><ul><li>An application that uses the Activator pattern may be less secure or reliable than an equivalent statically-configured application </li></ul></ul></ul><ul><ul><li>Increased run-time overhead & infrastructure complexity </li></ul></ul><ul><ul><ul><li>By adding levels of abstraction & indirection when activating & executing components </li></ul></ul></ul>
  112. 112. Enhancing Server (Re)Configurability (1/2) <ul><li>Certain factors are static , such as the number of available CPUs & operating system support for asynchronous I/O </li></ul><ul><li>Other factors are dynamic , such as system workload </li></ul>Context The implementation of certain image server components depends on a variety of factors: <ul><li>Problem </li></ul><ul><li>Prematurely committing to a particular image server component configuration is inflexible & inefficient: </li></ul><ul><ul><li>No single image server configuration is optimal for all use cases </li></ul></ul><ul><ul><li>Certain design decisions cannot be made efficiently until run-time </li></ul></ul>Image Processing Conn Mgmt Cache Mgmt Threading Demuxing File System I/O
  113. 113. Enhancing Server (Re)Configurability (2/2) <ul><li>This pattern allows an application to link & unlink its component implementations at run-time </li></ul><ul><li>Thus, new & enhanced services can be added without having to modify, recompile, statically relink, or shut down & restart a running application </li></ul><ul><li>Solution </li></ul><ul><li>Apply the Component Configurator design pattern (P2) to enhance server configurability </li></ul><<contains>> components * Component Configurator Component Repository Concrete Component A Concrete Component B Component init() fini() suspend() resume() info()
  114. 114. Component Configurator Pattern Dynamics run_component() run_component() fini() remove() remove() fini() Comp. A Concrete Comp. B Concrete Comp. A Concrete Comp. B <ul><li>Component initialization & dynamic linking </li></ul><ul><li>Component processing </li></ul><ul><li>Component termination & dynamic unlinking </li></ul>: Component Configurator init() : Concrete Component A : Concrete Component B : Component Repository insert() insert() init() Concrete
  115. 115. Applying the Component Configurator Pattern to Image Acquisition <<contains>> components * Component Configurator Component Repository LRU File Cache LFU File Cache Component init() fini() suspend() resume() info() <ul><li>For example , an image server can apply the Component Configurator pattern to configure various Cached Virtual Filesystem strategies </li></ul><ul><ul><li>e.g., least-recently used (LRU) or least-frequently used (LFU) </li></ul></ul>Image servers can use the Component Configurator pattern to dynamically optimize, control, & reconfigure the behavior of its components at installation-time or during run-time Concrete components can be packaged into a suitable unit of configuration, such as a dynamically linked library (DLL) Only the components that are currently in use need to be configured into an image server
  116. 116. Reconfiguring an Image Server Image servers can also be reconfigured dynamically to support new components & new component implementations IDLE RUNNING SUSPENDED CONFIGURE init() RECONFIGURE init() fini() fini() resume() suspend() EXECUTE run_component() SUSPEND RESUME TERMINATE TERMINATE Reconfiguration State Chart LRU File Cache Image Server # Configure an image server. dynamic File_Cache Component * img_server.dll:make_File_Cache() &quot;-t LRU&quot; INITIAL CONFIGURATION AFTER RECONFIGURATION LFU File Cache Image Server # Reconfigure an image server. remove File_Cache dynamic File_Cache Component * img_server.dll:make_File_Cache() &quot;-t LFU&quot;
  117. 117. Pros & Cons of the Component Configurator Pattern <ul><li>This pattern offers four benefits : </li></ul><ul><li>Uniformity </li></ul><ul><ul><li>By imposing a uniform configuration & control interface to manage components </li></ul></ul><ul><li>Centralized administration </li></ul><ul><ul><li>By grouping one or more components into a single administrative unit that simplifies development by centralizing common component initialization & termination activities </li></ul></ul><ul><li>Modularity, testability, & reusability </li></ul><ul><ul><li>Application modularity & reusability is improved by decoupling component implementations from the manner in which the components are configured into processes </li></ul></ul><ul><li>Configuration dynamism & control </li></ul><ul><ul><li>By enabling a component to be dynamically reconfigured without modifying, recompiling, statically relinking existing code & without restarting the component or other active components with which it is collocated </li></ul></ul><ul><li>This pattern also incurs liabilities : </li></ul><ul><li>Lack of determinism & ordering dependencies </li></ul><ul><ul><li>This pattern makes it hard to determine or analyze the behavior of an application until its components are configured at run-time </li></ul></ul><ul><li>Reduced security or reliability </li></ul><ul><ul><li>An application that uses the Component Configurator pattern may be less secure or reliable than an equivalent statically-configured application </li></ul></ul><ul><li>Increased run-time overhead & infrastructure complexity </li></ul><ul><ul><li>By adding levels of abstraction & indirection when executing components </li></ul></ul><ul><li>Overly narrow common interfaces </li></ul><ul><ul><li>The initialization or termination of a component may be too complicated or too tightly coupled with its context to be performed in a uniform manner </li></ul></ul>
  118. 118. Example: High-performance Content Delivery Servers <ul><li>Support many content delivery server design alternatives seamlessly </li></ul><ul><ul><li>e.g., different concurrency & event models </li></ul></ul><ul><li>Design is guided by patterns to leverage time-proven solutions </li></ul>Key Solution Characteristics <ul><li>Implementation based on COTS framework components to reduce effort & amortize prior work </li></ul><ul><li>Open-source to control costs & to leverage technology advances </li></ul><ul><li>Key System Characteristics </li></ul><ul><ul><li>Robust implementation </li></ul></ul><ul><ul><ul><li>e.g., stop malicious clients </li></ul></ul></ul><ul><ul><li>Extensible to other protocols </li></ul></ul><ul><ul><ul><li>e.g., HTTP 1.1, IIOP, DICOM </li></ul></ul></ul><ul><ul><li>Leverage advanced multi-processor hardware & software </li></ul></ul><ul><li>Goal </li></ul><ul><li>Download content scalably & efficiently </li></ul><ul><ul><li>e.g., images & other multi-media content types </li></ul></ul>Graphics Adapter GUI Event Dispatcher Transfer Protocol e.g. , HTTP 1.0 Requester File Cache Protocol Handlers HTML Parser HTTP Client HTTP Server GET /index.html HTTP/1.0 <H1>POSA page</H1>... www.posa.uci.edu TCP/IP Network OS Kernel & Protocols OS Kernel & Protocols
  119. 119. JAWS Content Server Framework <ul><li>Key Sources of Variation </li></ul><ul><li>Concurrency models </li></ul><ul><ul><li>e.g., thread pool vs. thread-per-connection </li></ul></ul><ul><li>Event demultiplexing models </li></ul><ul><ul><li>e.g., sync vs. async </li></ul></ul><ul><li>File caching models </li></ul><ul><ul><li>e.g., LRU vs. LFU </li></ul></ul><ul><li>Content delivery protocols </li></ul><ul><ul><li>e.g., HTTP 1.0+1.1 vs. IIOP </li></ul></ul><ul><li>Operating system APIs </li></ul><ul><ul><li>e.g., Windows, UNIX, RTOS </li></ul></ul><ul><li>Event Dispatcher </li></ul><ul><li>Accepts client connection request events, receives HTTP GET requests, & coordinates JAWS’s event demultiplexing strategy with its concurrency strategy </li></ul><ul><li>Protocol Handler </li></ul><ul><li>Performs parsing & protocol processing of HTTP request events. </li></ul><ul><li>Cached Virtual Filesystem </li></ul><ul><li>Improves Web server performance by reducing the overhead of file system accesses when processing HTTP GET requests </li></ul>
  120. 120. Applying Patterns to Resolve Key JAWS Design Challenges Patterns help resolve the following common design challenges: <ul><li>Efficiently demuxing asynchronous operations & completions </li></ul><ul><li>Enhancing server (re)configurability </li></ul><ul><li>Transparently parameterizing synchronization into components </li></ul><ul><li>Ensuring locks are released properly </li></ul><ul><li>Minimizing unnecessary locking </li></ul><ul><li>Synchronizing singletons correctly </li></ul><ul><li>Logging access statistics efficiently </li></ul><ul><li>Encapsulating low-level OS APIs </li></ul><ul><li>Decoupling event demuxing & connection management from protocol processing </li></ul><ul
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×