SlideShare a Scribd company logo

10 - Architetture Software - More architectural styles

•
•
Majong DevJfu
Majong DevJfu

The Microkernel pattern partitions an operating system into isolated, minimal components that communicate through a small, fixed message-passing interface, allowing components to be developed and upgraded independently while maintaining overall system stability and security.

1 of 69
Download to read offline
More architectural styles Paolo Ciancarini
Agenda •  Examples of distributed systems •  POSA: Pattern oriented sw architecture •  Architectural pattern for distributed systems: Broker •  Architectural pattern for distributed systems: Microkernel 2
Complex architectural styles •  The basic architectural styles (layers, tiers, pipes, repository, MVC, client-server, peer- to-peer) are not sufficient to describe all current (and future) software systems •  They can be combined in several ways •  They exploit different patterns •  Moreover, some systems expose special styles (eg. mobile code, agent-based, etc)
Pattern oriented software architecture
References •  Buschmann et al. Pattern-Oriented Software Architecture: a system of patterns, Wiley 1996 (POSA1) •  Schmidt et al., Patterns for Concurrent and Networked Objects, Wiley 2000 (POSA2) •  Kircher and Jain, Patterns for Resource Management, Wiley 2004 (POSA3) •  Buschmann et al. Pattern Language for distributed computing, Wiley 2007 (POSA4) •  Buschmann et al. Pattern-Oriented Software Architecture, Wiley 2007 (POSA5)
POSA 1
The POSA2 Pattern Language Pattern Benefits • Preserve crucial design information used by applications & middleware frameworks & components • Facilitate reuse of proven software designs & architectures • Guide design choices for application developers
POSA2 Pattern Abstracts Service Access & Configuration Patterns Event Handling Patterns The Wrapper Facade design pattern The Reactor architectural pattern allows event- encapsulates the functions and data provided by driven applications to demultiplex and dispatch existing non-object-oriented APIs within more service requests that are delivered to an concise, robust, portable, maintainable, and application from one or more clients. cohesive object-oriented class interfaces. The Proactor architectural pattern allows The Component Configurator design pattern event-driven applications to efficiently allows an application to link and unlink its demultiplex and dispatch service requests component implementations at run-time without triggered by the completion of asynchronous having to modify, recompile, or statically relink the operations, to achieve the performance application. Component Configurator further benefits of concurrency without incurring supports the reconfiguration of components into certain of its liabilities. different application processes without having to The Asynchronous Completion Token design shut down and re-start running processes. pattern allows an application to demultiplex The Interceptor architectural pattern allows and process efficiently the responses of services to be added transparently to a asynchronous operations it invokes on framework and triggered automatically when services. certain events occur. The Acceptor-Connector design pattern The Extension Interface design pattern allows decouples the connection and initialization of multiple interfaces to be exported by a cooperating peer services in a networked component, to prevent bloating of interfaces and system from the processing performed by the breaking of client code when developers extend peer services after they are connected and or modify the functionality of the component. initialized.
POSA2 Pattern Abstracts Synchronization Patterns Concurrency Patterns The Scoped Locking C++ idiom The Active Object design pattern decouples method ensures that a lock is acquired when execution from method invocation to enhance concurrency control enters a scope and released and simplify synchronized access to objects that reside in automatically when control leaves the their own threads of control. scope, regardless of the return path The Monitor Object design pattern synchronizes concurrent from the scope. method execution to ensure that only one method at a time The Strategized Locking design pattern runs within an object. It also allows an object’s methods to parameterizes synchronization cooperatively schedule their execution sequences. mechanisms that protect a component’s The Half-Sync/Half-Async architectural pattern decouples critical sections from concurrent access. asynchronous and synchronous service processing in The Thread-Safe Interface design concurrent systems, to simplify programming without unduly pattern minimizes locking overhead and reducing performance. The pattern introduces two ensures that intra-component method intercommunicating layers, one for asynchronous and one calls do not incur ‘self-deadlock’ by for synchronous service processing. trying to reacquire a lock that is held by The Leader/Followers architectural pattern provides an the component already. efficient concurrency model where multiple threads take The Double-Checked Locking turns sharing a set of event sources in order to detect, Optimization design pattern reduces demultiplex, dispatch, and process service requests that contention and synchronization occur on the event sources. overhead whenever critical sections of The Thread-Specific Storage design pattern allows multiple code must acquire locks in a thread- safe manner just once during program threads to use one ‘logically global’ access point to retrieve an object that is local to a thread, without incurring locking execution. overhead on each object access.
POSA 3 patterns (resource management)
POSA 4 patterns
10 - Architetture Software - More architectural styles
Enterprise application patterns (Fowler) •  See pattern Layers in [POSA] •  Here: applied to enterprise applications •  Presentation logic Presentation logic –  Interaction with user –  Command-line or rich client or Web interface •  Domain logic –  Validation of input and calculation of Domain logic results •  Data source logic –  Communication with database and other applications Data source logic
EA Patterns Data Source Domain Presentation Page Controller Template View Front Controller Transform View Domain Model Transaction Script Active Record Table Module Data Mapper Row Data Gateway Table Data Gateway martinfowler.com/eaaCatalog/
J2EE patterns www.corej2eepatterns.com!
Motivation Trends • Hardware keeps getting smaller, faster, & cheaper • Software keeps getting larger, slower, & more expensive AbstractService Historical Challenges service • Building distributed systems is hard Client • Building them on-time & under budget is even harder Proxy Service 1 1 service service New Challenges • Many mission-critical distributed applications require real-time QoS support • e.g., combat systems, online trading, telecom • Building QoS-enabled applications manually is tedious, error-prone, & expensive • Conventional middleware does not support real-time QoS requirements effectively 16
Mission-Critical Applications Large-scale Switching Systems IOM IOM Total Ship Computing Environments IOM BSE BSE BSE IOM Total Ship C&C Center IOM IOM IOM IOM IOM BSE BSE BSE IOM IOM IOM IOM IOM IOM BSE BSE BSE IOM IOM IOM Avionics Industrial Process Control Theater Missile Defense 17
Examples of Distributed Systems •  Automatic Teller Machine (ATM) •  Web-based travel site •  Stock transaction processing system •  Search service •  Multiplayer games
Automatic Teller Machine (“bancomat”) •  Client-server, server knows all clients •  Simple reply-response •  Transactions •  Tightly controlled distributed system •  High security
Web-Based Travel Site •  Multi-tiered –  Client –  Travel site –  Vendors’ reservation systems –  Referred to as n-tiered •  Organization responsible for the site has little or no control over other tiers •  Session-oriented, indefinite seq of msgs
Stock Transaction Processing •  Peer-to-peer communication •  Lots of clients (QoS: isochrony) •  Different markets •  Publish/subscribe model for many interactions
Search Engine Service •  Example: Google toolkit •  Language-neutral service •  Freely available •  Easy to write program exploiting its services •  Low support overhead
Discuss What do these applications all need?
What They All Need •  Communication infrastructure •  Remote references to objects and methods •  Remote method invocation or remote procedure call
Special Needs •  Transactions –  ATM –  Stock transaction processing •  Asynchronous Messaging –  Stock transaction processing •  Session support (shared state) –  Travel site •  Language neutrality – standard interfaces –  Travel site –  Stock transaction processing –  Google search service
Synchronous communication •  Remote procedure call (RPC) •  Remote method invocation (RMI) •  Client waits until server responds, or request times out •  Most distributed processing follows this model •  Is much like normal, non-distributed programming, but… –  Pass by reference is not practical –  Not all data types may be available –  Platform neutrality may be hard to achieve
Asynchronous communication •  Messaging –  Client sends a message and moves on –  If a response is needed, the client has a mechanism that listens for it •  Point-to-point •  Used in publish/subscribe applications, e.g. •  Uses message-oriented middleware (MOM)
Message-Oriented Middleware •  IBM MQ Series •  Oracle AQS •  JMS – Java Messaging Service –  Part of the J2EE standard –  A set of standard interfaces, not a defined implementation –  Many vendors provide JMS wrappers or adapters for their MOM
Some patterns for concurrency and distribution (POSA2) •  Broker •  Microkernel •  Pipes and filters •  Reactor •  Pool of threads •  ….
Broker •  A broker is a party which mediates between a buyer and a seller •  In computing, a broker can be: –  A message broker –  A object request broker
Broker
Basic Pattern Format •  Name and summary description •  Example •  Context •  Problem, including forces •  Solution •  Implementation •  Example Resolved •  Variants •  Known Uses •  Consequences: benefits and liabilities •  Related Patterns and Credits 32
Description of the Broker pattern •  Goal: structure distributed sw systems –  with decoupled components –  that interact by remote service invocations •  Responsible for –  coordinating communication –  transmitting results –  transmitting exceptions 33
Broker pattern: context Your environment is a distributed and possibly heterogeneous system with independent cooperating components. 34
Broker pattern: problem •  Build a complex sw system as a set of decoupled, interoperating components (rather than a monolith) –  Greater flexibility, maintainability, changeability –  Partitioning into independent components makes system distributable and scalable •  Require a means of inter-process communication –  If components themselves handle communication, result has several dependencies and limitations •  System depends on which comm mechanism used •  Clients need to know location of servers 35
Broker pattern: problem •  Need services for adding, removing, exchanging, activating, and locating components –  Must not depend on system-specific details to guarantee portability and interoperability •  An object that uses an object should only see the interface offered by the object – know nothing about implementation 36
Broker pattern: forces Broker pattern balances the following forces •  Components access others’ services via remote, location-transparent service invocations •  Need to exchange, add, or remove components at run-time •  Architecture should hide system-specific and implementation-specific details from users of components and services 37
Broker pattern: solution •  Introduce a broker component to achieve better decoupling of clients and servers –  Servers: register themselves with the broker and make their services available to clients through method interfaces. –  Clients: access the functionality of servers by sending requests via the broker •  A broker s tasks: –  Locating the appropriate server and forwarding a request to that server –  Transmitting results and exceptions back to the client 38
Broker pattern: solution •  Reduces the complexity involved in developing distributed applications. –  Introduces object model where distributed services are encapsulated within objects •  Broker systems offer a path to the integration of two core technologies: –  Distribution –  Object technology •  Extend object models from single applications to distributed applications made of decoupled components that can –  run on heterogeneous machines and –  written in different programming languages 39
Broker pattern: structure •  Participating components –  Clients –  Servers –  Brokers –  Bridges –  Client-side proxies –  Server-side proxies 40
Class Collaborators Class Collaborators Client Client-side proxy Server Server-side proxy Responsibility Broker Responsibility Broker - implements user - implements functionality services - sends requests - registers itself with the local broker to servers through - Send responses a client-side proxy and exceptions back to clients via a server-side proxy
Class Collaborators Broker Client Responsibility Server Client-side proxy - registers servers Server side proxy - offers API Bridge - sends requests - transfer msgs - error recovery - locates servers -interoperates with other brokers through bridges
Broker class diagram 43
Server Registration
Client requests a service
Broker forwards a request
Broker pattern: implementation 1.  Define an object model or use an existing one 2.  Decide which kind of component-interoperability the system should offer 3.  Specify the APIs the broker component provides for collaborating with clients and servers 4.  Use proxy objects to hide implementation details from clients and servers 5.  Design the broker component in parallel with steps 3 and 4 •  broken down into nine steps 6.  Develop IDL compilers 47
Broker pattern: known uses •  CORBA •  Microsoft s OLE •  WWW – Hypertext browsers such as Mosaic and Netscape act as brokers and WWW servers play the role of service providers 48
Broker Pattern: consequences •  Benefits –  Location transparency –  Changeability and extensibility of components –  Portability of a Broker system –  Interoperability between different Broker systems –  Reusability •  Liabilities –  Restricted efficiency –  Lower fault tolerance (server fails, broker fails, ...) –  Testing and debugging 49
Object request broker •  An object request broker (ORB) is a piece of software that allows to make program calls from one computer to another via a network •  ORBs promote interoperability of distributed object systems because they enable users to build systems by piecing together objects from different vendors, so that they communicate with each other via the ORB
Object Request Broker (CORBA)
10 - Architetture Software - More architectural styles
10 - Architetture Software - More architectural styles
Microkernel pattern •  Found in POSA 1, pp. 171-192 (also found in Real-Time Design Patterns) •  The Microkernel architectural pattern applies to software systems that must be able to adapt to changing system requirements •  It separates a minimal functional core from extended functionality and customer-specific parts •  The microkernel also serves as a socket for plugging in these extensions and coordinating their collaboration 54
Context & Problem •  Context: The development of several applications that use similar programming interfaces that build on the same core functionality •  Problem: develop software for a domain that needs to cope with a broad spectrum of similar standards and technologies. Systems like operating systems and GUI’s often have a long life-span. New technologies emerge; old ones change 55
Forces •  Application platform must cope with continuous hw and sw evolution •  Application platform should be portable, extensible, and adaptable to allow easy integration of emerging technologies •  Applications in the domain need to support different but similar application platforms. •  The applications may be categorized into groups –  use the same functional core in different ways –  require the underlying application platform to emulate existing standards. •  Functional core  separate component with minimal memory size and services that consume as little processing as possible 56
Solution •  Encapsulate fundamental services in a microkernel component •  Internal servers contain core functionality that cannot be implemented in the microkernel without causing an unnecessary increase in size or complexity •  External servers implement their own view of the underlying microkernel using mechanisms available through the interfaces of the microkernel –  Every external server is a separate process that represents an application platform •  A microkernel system is an application platform that integrates other application platforms •  Clients communicate with ext. servers using comm facilities provided by microkernel 57
CRC Cards Class Collaborators Internal server Microkernel Class Collaborators Responsibility Microkernel Internal server  Implements Responsibility additional services  Provides core  Encapsulates mechanisms some system  Offers communi- dependencies cation facilities  Encapsulates sys- Class Collaborators tem dependencies External server Microkernel  Manages and controls resources Responsibility •  Provides programming interfaces for its clients 58
CRC cards Class Collaborators Class Collaborators  Client Adapter  Adapter External server Microkernel Responsibility Responsibility Hides system depen-  Represents an dencies such as application communication facilities from the client. Invokes methods of external servers on behalf of clients 59
Static Relationships External Server Microkernel Internal Server receiveRequest executeMechanism receiveRequest dispatchRequest initCommunication executeService executeService findReceiver createHandle sendMessage callInternalServer initializes communication Adapter Client createRequest doTask calls service callService sends request 60
Microkernel
Scenario I 62
Scenario II 63
Examples •  Windows NT, Linux 2.*, MACH, etc. •  Most real time operating systems (RTOS) for embedded systems •  Core set of services include create and delete a task, allocate and de-allocate memory, provide task event & message queues, and schedule/execute a task set •  A developer can link in additional components to provide more services: like bus communications, file services, networking services, and middleware services •  A microkernel RTOS becomes usable in a much wider set of application problems from tiny, highly memory- constrained systems to systems consisting of sets of high-powered networked CPUs 64
Consequences •  Benefits –  portability –  flexibility and extensibility –  separation of policy and mechanism –  scalability –  reliability –  transparency •  Liabilities –  performance –  complexity of design and implementation 65
Self test questions •  How many architectural styles (or patterns) do exist? •  What is the relationship between style and architecture? •  What are the consequences of the broker pattern? •  What are the consequences of the microkrnel pattern? 66
References •  M. Fowler Patterns of Enterprise Application Architecture, Addison Wesley, 2003 •  L.Bass and P. Clemens and R. Kazman, Software Architecture in Practice, 2nd Ed, Addison Wesley, 2003 •  Gardner and Yusuf, Capturing your architectural decisions explicitly, 2006 www.ibm.com/developerworks/library/ar-mdd2/
Useful sites •  www.bredemeyer.com/links.htm! •  www.opengroup.org/architecture/! •  www.iasahome.org! •  java.sun.com/blueprints/corej2eepatterns/!
Questions?

More Related Content

10 - Architetture Software - More architectural styles

  • 1. More architectural styles Paolo Ciancarini
  • 2. Agenda •  Examples of distributed systems •  POSA: Pattern oriented sw architecture •  Architectural pattern for distributed systems: Broker •  Architectural pattern for distributed systems: Microkernel 2
  • 3. Complex architectural styles •  The basic architectural styles (layers, tiers, pipes, repository, MVC, client-server, peer- to-peer) are not sufficient to describe all current (and future) software systems •  They can be combined in several ways •  They exploit different patterns •  Moreover, some systems expose special styles (eg. mobile code, agent-based, etc)
  • 5. References •  Buschmann et al. Pattern-Oriented Software Architecture: a system of patterns, Wiley 1996 (POSA1) •  Schmidt et al., Patterns for Concurrent and Networked Objects, Wiley 2000 (POSA2) •  Kircher and Jain, Patterns for Resource Management, Wiley 2004 (POSA3) •  Buschmann et al. Pattern Language for distributed computing, Wiley 2007 (POSA4) •  Buschmann et al. Pattern-Oriented Software Architecture, Wiley 2007 (POSA5)
  • 7. The POSA2 Pattern Language Pattern Benefits • Preserve crucial design information used by applications & middleware frameworks & components • Facilitate reuse of proven software designs & architectures • Guide design choices for application developers
  • 8. POSA2 Pattern Abstracts Service Access & Configuration Patterns Event Handling Patterns The Wrapper Facade design pattern The Reactor architectural pattern allows event- encapsulates the functions and data provided by driven applications to demultiplex and dispatch existing non-object-oriented APIs within more service requests that are delivered to an concise, robust, portable, maintainable, and application from one or more clients. cohesive object-oriented class interfaces. The Proactor architectural pattern allows The Component Configurator design pattern event-driven applications to efficiently allows an application to link and unlink its demultiplex and dispatch service requests component implementations at run-time without triggered by the completion of asynchronous having to modify, recompile, or statically relink the operations, to achieve the performance application. Component Configurator further benefits of concurrency without incurring supports the reconfiguration of components into certain of its liabilities. different application processes without having to The Asynchronous Completion Token design shut down and re-start running processes. pattern allows an application to demultiplex The Interceptor architectural pattern allows and process efficiently the responses of services to be added transparently to a asynchronous operations it invokes on framework and triggered automatically when services. certain events occur. The Acceptor-Connector design pattern The Extension Interface design pattern allows decouples the connection and initialization of multiple interfaces to be exported by a cooperating peer services in a networked component, to prevent bloating of interfaces and system from the processing performed by the breaking of client code when developers extend peer services after they are connected and or modify the functionality of the component. initialized.
  • 9. POSA2 Pattern Abstracts Synchronization Patterns Concurrency Patterns The Scoped Locking C++ idiom The Active Object design pattern decouples method ensures that a lock is acquired when execution from method invocation to enhance concurrency control enters a scope and released and simplify synchronized access to objects that reside in automatically when control leaves the their own threads of control. scope, regardless of the return path The Monitor Object design pattern synchronizes concurrent from the scope. method execution to ensure that only one method at a time The Strategized Locking design pattern runs within an object. It also allows an object’s methods to parameterizes synchronization cooperatively schedule their execution sequences. mechanisms that protect a component’s The Half-Sync/Half-Async architectural pattern decouples critical sections from concurrent access. asynchronous and synchronous service processing in The Thread-Safe Interface design concurrent systems, to simplify programming without unduly pattern minimizes locking overhead and reducing performance. The pattern introduces two ensures that intra-component method intercommunicating layers, one for asynchronous and one calls do not incur ‘self-deadlock’ by for synchronous service processing. trying to reacquire a lock that is held by The Leader/Followers architectural pattern provides an the component already. efficient concurrency model where multiple threads take The Double-Checked Locking turns sharing a set of event sources in order to detect, Optimization design pattern reduces demultiplex, dispatch, and process service requests that contention and synchronization occur on the event sources. overhead whenever critical sections of The Thread-Specific Storage design pattern allows multiple code must acquire locks in a thread- safe manner just once during program threads to use one ‘logically global’ access point to retrieve an object that is local to a thread, without incurring locking execution. overhead on each object access.
  • 10. POSA 3 patterns (resource management)
  • 13. Enterprise application patterns (Fowler) •  See pattern Layers in [POSA] •  Here: applied to enterprise applications •  Presentation logic Presentation logic –  Interaction with user –  Command-line or rich client or Web interface •  Domain logic –  Validation of input and calculation of Domain logic results •  Data source logic –  Communication with database and other applications Data source logic
  • 14. EA Patterns Data Source Domain Presentation Page Controller Template View Front Controller Transform View Domain Model Transaction Script Active Record Table Module Data Mapper Row Data Gateway Table Data Gateway martinfowler.com/eaaCatalog/
  • 16. Motivation Trends • Hardware keeps getting smaller, faster, & cheaper • Software keeps getting larger, slower, & more expensive AbstractService Historical Challenges service • Building distributed systems is hard Client • Building them on-time & under budget is even harder Proxy Service 1 1 service service New Challenges • Many mission-critical distributed applications require real-time QoS support • e.g., combat systems, online trading, telecom • Building QoS-enabled applications manually is tedious, error-prone, & expensive • Conventional middleware does not support real-time QoS requirements effectively 16
  • 17. Mission-Critical Applications Large-scale Switching Systems IOM IOM Total Ship Computing Environments IOM BSE BSE BSE IOM Total Ship C&C Center IOM IOM IOM IOM IOM BSE BSE BSE IOM IOM IOM IOM IOM IOM BSE BSE BSE IOM IOM IOM Avionics Industrial Process Control Theater Missile Defense 17
  • 18. Examples of Distributed Systems •  Automatic Teller Machine (ATM) •  Web-based travel site •  Stock transaction processing system •  Search service •  Multiplayer games
  • 19. Automatic Teller Machine (“bancomat”) •  Client-server, server knows all clients •  Simple reply-response •  Transactions •  Tightly controlled distributed system •  High security
  • 20. Web-Based Travel Site •  Multi-tiered –  Client –  Travel site –  Vendors’ reservation systems –  Referred to as n-tiered •  Organization responsible for the site has little or no control over other tiers •  Session-oriented, indefinite seq of msgs
  • 21. Stock Transaction Processing •  Peer-to-peer communication •  Lots of clients (QoS: isochrony) •  Different markets •  Publish/subscribe model for many interactions
  • 22. Search Engine Service •  Example: Google toolkit •  Language-neutral service •  Freely available •  Easy to write program exploiting its services •  Low support overhead
  • 23. Discuss What do these applications all need?
  • 24. What They All Need •  Communication infrastructure •  Remote references to objects and methods •  Remote method invocation or remote procedure call
  • 25. Special Needs •  Transactions –  ATM –  Stock transaction processing •  Asynchronous Messaging –  Stock transaction processing •  Session support (shared state) –  Travel site •  Language neutrality – standard interfaces –  Travel site –  Stock transaction processing –  Google search service
  • 26. Synchronous communication •  Remote procedure call (RPC) •  Remote method invocation (RMI) •  Client waits until server responds, or request times out •  Most distributed processing follows this model •  Is much like normal, non-distributed programming, but… –  Pass by reference is not practical –  Not all data types may be available –  Platform neutrality may be hard to achieve
  • 27. Asynchronous communication •  Messaging –  Client sends a message and moves on –  If a response is needed, the client has a mechanism that listens for it •  Point-to-point •  Used in publish/subscribe applications, e.g. •  Uses message-oriented middleware (MOM)
  • 28. Message-Oriented Middleware •  IBM MQ Series •  Oracle AQS •  JMS – Java Messaging Service –  Part of the J2EE standard –  A set of standard interfaces, not a defined implementation –  Many vendors provide JMS wrappers or adapters for their MOM
  • 29. Some patterns for concurrency and distribution (POSA2) •  Broker •  Microkernel •  Pipes and filters •  Reactor •  Pool of threads •  ….
  • 30. Broker •  A broker is a party which mediates between a buyer and a seller •  In computing, a broker can be: –  A message broker –  A object request broker
  • 32. Basic Pattern Format •  Name and summary description •  Example •  Context •  Problem, including forces •  Solution •  Implementation •  Example Resolved •  Variants •  Known Uses •  Consequences: benefits and liabilities •  Related Patterns and Credits 32
  • 33. Description of the Broker pattern •  Goal: structure distributed sw systems –  with decoupled components –  that interact by remote service invocations •  Responsible for –  coordinating communication –  transmitting results –  transmitting exceptions 33
  • 34. Broker pattern: context Your environment is a distributed and possibly heterogeneous system with independent cooperating components. 34
  • 35. Broker pattern: problem •  Build a complex sw system as a set of decoupled, interoperating components (rather than a monolith) –  Greater flexibility, maintainability, changeability –  Partitioning into independent components makes system distributable and scalable •  Require a means of inter-process communication –  If components themselves handle communication, result has several dependencies and limitations •  System depends on which comm mechanism used •  Clients need to know location of servers 35
  • 36. Broker pattern: problem •  Need services for adding, removing, exchanging, activating, and locating components –  Must not depend on system-specific details to guarantee portability and interoperability •  An object that uses an object should only see the interface offered by the object – know nothing about implementation 36
  • 37. Broker pattern: forces Broker pattern balances the following forces •  Components access others’ services via remote, location-transparent service invocations •  Need to exchange, add, or remove components at run-time •  Architecture should hide system-specific and implementation-specific details from users of components and services 37
  • 38. Broker pattern: solution •  Introduce a broker component to achieve better decoupling of clients and servers –  Servers: register themselves with the broker and make their services available to clients through method interfaces. –  Clients: access the functionality of servers by sending requests via the broker •  A broker s tasks: –  Locating the appropriate server and forwarding a request to that server –  Transmitting results and exceptions back to the client 38
  • 39. Broker pattern: solution •  Reduces the complexity involved in developing distributed applications. –  Introduces object model where distributed services are encapsulated within objects •  Broker systems offer a path to the integration of two core technologies: –  Distribution –  Object technology •  Extend object models from single applications to distributed applications made of decoupled components that can –  run on heterogeneous machines and –  written in different programming languages 39
  • 40. Broker pattern: structure •  Participating components –  Clients –  Servers –  Brokers –  Bridges –  Client-side proxies –  Server-side proxies 40
  • 41. Class Collaborators Class Collaborators Client Client-side proxy Server Server-side proxy Responsibility Broker Responsibility Broker - implements user - implements functionality services - sends requests - registers itself with the local broker to servers through - Send responses a client-side proxy and exceptions back to clients via a server-side proxy
  • 42. Class Collaborators Broker Client Responsibility Server Client-side proxy - registers servers Server side proxy - offers API Bridge - sends requests - transfer msgs - error recovery - locates servers -interoperates with other brokers through bridges
  • 45. Client requests a service
  • 46. Broker forwards a request
  • 47. Broker pattern: implementation 1.  Define an object model or use an existing one 2.  Decide which kind of component-interoperability the system should offer 3.  Specify the APIs the broker component provides for collaborating with clients and servers 4.  Use proxy objects to hide implementation details from clients and servers 5.  Design the broker component in parallel with steps 3 and 4 •  broken down into nine steps 6.  Develop IDL compilers 47
  • 48. Broker pattern: known uses •  CORBA •  Microsoft s OLE •  WWW – Hypertext browsers such as Mosaic and Netscape act as brokers and WWW servers play the role of service providers 48
  • 49. Broker Pattern: consequences •  Benefits –  Location transparency –  Changeability and extensibility of components –  Portability of a Broker system –  Interoperability between different Broker systems –  Reusability •  Liabilities –  Restricted efficiency –  Lower fault tolerance (server fails, broker fails, ...) –  Testing and debugging 49
  • 50. Object request broker •  An object request broker (ORB) is a piece of software that allows to make program calls from one computer to another via a network •  ORBs promote interoperability of distributed object systems because they enable users to build systems by piecing together objects from different vendors, so that they communicate with each other via the ORB
  • 54. Microkernel pattern •  Found in POSA 1, pp. 171-192 (also found in Real-Time Design Patterns) •  The Microkernel architectural pattern applies to software systems that must be able to adapt to changing system requirements •  It separates a minimal functional core from extended functionality and customer-specific parts •  The microkernel also serves as a socket for plugging in these extensions and coordinating their collaboration 54
  • 55. Context & Problem •  Context: The development of several applications that use similar programming interfaces that build on the same core functionality •  Problem: develop software for a domain that needs to cope with a broad spectrum of similar standards and technologies. Systems like operating systems and GUI’s often have a long life-span. New technologies emerge; old ones change 55
  • 56. Forces •  Application platform must cope with continuous hw and sw evolution •  Application platform should be portable, extensible, and adaptable to allow easy integration of emerging technologies •  Applications in the domain need to support different but similar application platforms. •  The applications may be categorized into groups –  use the same functional core in different ways –  require the underlying application platform to emulate existing standards. •  Functional core  separate component with minimal memory size and services that consume as little processing as possible 56
  • 57. Solution •  Encapsulate fundamental services in a microkernel component •  Internal servers contain core functionality that cannot be implemented in the microkernel without causing an unnecessary increase in size or complexity •  External servers implement their own view of the underlying microkernel using mechanisms available through the interfaces of the microkernel –  Every external server is a separate process that represents an application platform •  A microkernel system is an application platform that integrates other application platforms •  Clients communicate with ext. servers using comm facilities provided by microkernel 57
  • 58. CRC Cards Class Collaborators Internal server Microkernel Class Collaborators Responsibility Microkernel Internal server  Implements Responsibility additional services  Provides core  Encapsulates mechanisms some system  Offers communi- dependencies cation facilities  Encapsulates sys- Class Collaborators tem dependencies External server Microkernel  Manages and controls resources Responsibility •  Provides programming interfaces for its clients 58
  • 59. CRC cards Class Collaborators Class Collaborators  Client Adapter  Adapter External server Microkernel Responsibility Responsibility Hides system depen-  Represents an dencies such as application communication facilities from the client. Invokes methods of external servers on behalf of clients 59
  • 60. Static Relationships External Server Microkernel Internal Server receiveRequest executeMechanism receiveRequest dispatchRequest initCommunication executeService executeService findReceiver createHandle sendMessage callInternalServer initializes communication Adapter Client createRequest doTask calls service callService sends request 60
  • 64. Examples •  Windows NT, Linux 2.*, MACH, etc. •  Most real time operating systems (RTOS) for embedded systems •  Core set of services include create and delete a task, allocate and de-allocate memory, provide task event & message queues, and schedule/execute a task set •  A developer can link in additional components to provide more services: like bus communications, file services, networking services, and middleware services •  A microkernel RTOS becomes usable in a much wider set of application problems from tiny, highly memory- constrained systems to systems consisting of sets of high-powered networked CPUs 64
  • 65. Consequences •  Benefits –  portability –  flexibility and extensibility –  separation of policy and mechanism –  scalability –  reliability –  transparency •  Liabilities –  performance –  complexity of design and implementation 65
  • 66. Self test questions •  How many architectural styles (or patterns) do exist? •  What is the relationship between style and architecture? •  What are the consequences of the broker pattern? •  What are the consequences of the microkrnel pattern? 66
  • 67. References •  M. Fowler Patterns of Enterprise Application Architecture, Addison Wesley, 2003 •  L.Bass and P. Clemens and R. Kazman, Software Architecture in Practice, 2nd Ed, Addison Wesley, 2003 •  Gardner and Yusuf, Capturing your architectural decisions explicitly, 2006 www.ibm.com/developerworks/library/ar-mdd2/
  • 68. Useful sites •  www.bredemeyer.com/links.htm! •  www.opengroup.org/architecture/! •  www.iasahome.org! •  java.sun.com/blueprints/corej2eepatterns/!