Morearchitectural styles      Paolo Ciancarini
Agenda•    Examples of distributed systems•    POSA: Pattern oriented sw architecture•    Architectural pattern for distri...
Complex architectural styles•  The basic architectural styles (layers, tiers,   pipes, repository, MVC, client-server, pee...
Pattern oriented software architecture
References•  Buschmann et al. Pattern-Oriented Software   Architecture: a system of patterns, Wiley 1996   (POSA1)•  Schmi...
POSA 1
The POSA2 Pattern Language                  Pattern Benefits                   • Preserve crucial design                  ...
POSA2 Pattern AbstractsService Access & Configuration Patterns                 Event Handling PatternsThe Wrapper Facade d...
POSA2 Pattern AbstractsSynchronization Patterns                   Concurrency PatternsThe Scoped Locking C++ idiom        ...
POSA 3 patterns (resource management)
POSA 4patterns
Enterprise application patterns (Fowler)•  See pattern Layers in [POSA]•  Here: applied to enterprise   applications•  Pre...
EA PatternsData Source Domain Presentation             Page Controller               Template View                        ...
J2EE patternswww.corej2eepatterns.com!
MotivationTrends • Hardware keeps getting smaller, faster, & cheaper • Software keeps getting larger, slower, & more expen...
Mission-Critical ApplicationsLarge-scale Switching Systems    IOM                                 IOM                     ...
Examples of Distributed              Systems•    Automatic Teller Machine (ATM)•    Web-based travel site•    Stock transa...
Automatic Teller Machine                     (“bancomat”)•    Client-server, server knows all clients•    Simple reply-res...
Web-Based Travel Site•  Multi-tiered  –  Client  –  Travel site  –  Vendors’ reservation systems  –  Referred to as n-tier...
Stock Transaction Processing•    Peer-to-peer communication•    Lots of clients (QoS: isochrony)•    Different markets•   ...
Search Engine Service•  Example: Google toolkit•  Language-neutral service•  Freely available•  Easy to write program expl...
DiscussWhat do these applications all need?
What They All Need•  Communication infrastructure•  Remote references to objects and   methods•  Remote method invocation ...
Special Needs•  Transactions  –  ATM  –  Stock transaction processing•  Asynchronous Messaging  –  Stock transaction proce...
Synchronous communication•  Remote procedure call (RPC)•  Remote method invocation (RMI)•  Client waits until server respo...
Asynchronous communication•  Messaging  –  Client sends a message and moves on  –  If a response is needed, the client has...
Message-Oriented Middleware•  IBM MQ Series•  Oracle AQS•  JMS – Java Messaging Service  –  Part of the J2EE standard  –  ...
Some patterns for concurrency and           distribution (POSA2)•    Broker•    Microkernel•    Pipes and filters•    Reac...
Broker•  A broker is a party which mediates   between a buyer and a seller•  In computing, a broker can be:  –  A message ...
Broker
Basic Pattern Format•    Name and summary description•    Example•    Context•    Problem, including forces•    Solution• ...
Description of the Broker pattern•  Goal: structure distributed sw systems  –  with decoupled components  –  that interact...
Broker pattern: contextYour environment is a distributed and possibly heterogeneous system with independent cooperating co...
Broker pattern: problem•  Build a complex sw system as a set of   decoupled, interoperating components   (rather than a mo...
Broker pattern: problem•  Need services for adding, removing,   exchanging, activating, and locating   components  –  Must...
Broker pattern: forcesBroker pattern balances the following forces•  Components access others’ services via   remote, loca...
Broker pattern: solution•  Introduce a broker component to achieve better   decoupling of clients and servers  –  Servers:...
Broker pattern: solution•  Reduces the complexity involved in developing   distributed applications.   –  Introduces objec...
Broker pattern: structure•  Participating components  –  Clients  –  Servers  –  Brokers  –  Bridges  –  Client-side proxi...
Class                  Collaborators      Class                    CollaboratorsClient                Client-side proxy   ...
Class                  CollaboratorsBroker                ClientResponsibility        Server                      Client-s...
Broker class diagram                       43
Server Registration
Client requests a service
Broker forwards a request
Broker pattern: implementation1.  Define an object model or use an existing one2.  Decide which kind of component-interope...
Broker pattern: known uses•  CORBA•  Microsoft s OLE•  WWW – Hypertext browsers such as   Mosaic and Netscape act as broke...
Broker Pattern: consequences•  Benefits   –  Location transparency   –  Changeability and extensibility of components   – ...
Object request broker•  An object request broker (ORB) is a piece   of software that allows to make program   calls from o...
Object Request Broker (CORBA)
Microkernel pattern•  Found in POSA 1, pp. 171-192   (also found in Real-Time Design Patterns)•  The Microkernel architect...
Context & Problem•  Context: The development of several   applications that use similar programming   interfaces that buil...
Forces•  Application platform must cope with continuous hw and   sw evolution•  Application platform should be portable, e...
Solution•  Encapsulate fundamental services in a microkernel   component•  Internal servers contain core functionality tha...
CRC Cards                                        Class               Collaborators                                        ...
CRC cardsClass             Collaborators   Class           Collaborators Client          Adapter          Adapter       ...
Static RelationshipsExternal Server                    Microkernel                          Internal ServerreceiveRequest ...
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 o...
Consequences•  Benefits   –  portability   –  flexibility and extensibility   –  separation of policy and mechanism   –  s...
Self test questions•  How many architectural styles (or   patterns) do exist?•  What is the relationship between style and...
References•  M. Fowler Patterns of Enterprise Application   Architecture, Addison Wesley, 2003•  L.Bass and P. Clemens and...
Useful sites•    www.bredemeyer.com/links.htm!•    www.opengroup.org/architecture/!•    www.iasahome.org!•    java.sun.com...
Questions?
10 - Architetture Software - More architectural styles
10 - Architetture Software - More architectural styles
10 - Architetture Software - More architectural styles
Upcoming SlideShare
Loading in …5
×

10 - Architetture Software - More architectural styles

1,917 views

Published on

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,917
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
61
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

10 - Architetture Software - More architectural styles

  1. 1. Morearchitectural styles Paolo Ciancarini
  2. 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. 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)
  4. 4. Pattern oriented software architecture
  5. 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)
  6. 6. POSA 1
  7. 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. 8. POSA2 Pattern AbstractsService Access & Configuration Patterns Event Handling PatternsThe Wrapper Facade design pattern The Reactor architectural pattern allows event-encapsulates the functions and data provided by driven applications to demultiplex and dispatchexisting non-object-oriented APIs within more service requests that are delivered to anconcise, robust, portable, maintainable, and application from one or more clients.cohesive object-oriented class interfaces. The Proactor architectural pattern allowsThe Component Configurator design pattern event-driven applications to efficientlyallows an application to link and unlink its demultiplex and dispatch service requestscomponent implementations at run-time without triggered by the completion of asynchronoushaving to modify, recompile, or statically relink the operations, to achieve the performanceapplication. Component Configurator further benefits of concurrency without incurringsupports the reconfiguration of components into certain of its liabilities.different application processes without having to The Asynchronous Completion Token designshut down and re-start running processes. pattern allows an application to demultiplexThe Interceptor architectural pattern allows and process efficiently the responses ofservices to be added transparently to a asynchronous operations it invokes onframework and triggered automatically when services.certain events occur. The Acceptor-Connector design patternThe Extension Interface design pattern allows decouples the connection and initialization ofmultiple interfaces to be exported by a cooperating peer services in a networkedcomponent, to prevent bloating of interfaces and system from the processing performed by thebreaking of client code when developers extend peer services after they are connected andor modify the functionality of the component. initialized.
  9. 9. POSA2 Pattern AbstractsSynchronization Patterns Concurrency PatternsThe Scoped Locking C++ idiom The Active Object design pattern decouples methodensures that a lock is acquired when execution from method invocation to enhance concurrencycontrol enters a scope and released and simplify synchronized access to objects that reside inautomatically when control leaves the their own threads of control.scope, regardless of the return path The Monitor Object design pattern synchronizes concurrentfrom the scope. method execution to ensure that only one method at a timeThe Strategized Locking design pattern runs within an object. It also allows an object’s methods toparameterizes synchronization cooperatively schedule their execution sequences.mechanisms that protect a component’s The Half-Sync/Half-Async architectural pattern decouplescritical sections from concurrent access. asynchronous and synchronous service processing inThe Thread-Safe Interface design concurrent systems, to simplify programming without undulypattern minimizes locking overhead and reducing performance. The pattern introduces twoensures that intra-component method intercommunicating layers, one for asynchronous and onecalls 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 anthe component already. efficient concurrency model where multiple threads takeThe Double-Checked Locking turns sharing a set of event sources in order to detect,Optimization design pattern reduces demultiplex, dispatch, and process service requests thatcontention and synchronization occur on the event sources.overhead whenever critical sections of The Thread-Specific Storage design pattern allows multiplecode 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 lockingexecution. overhead on each object access.
  10. 10. POSA 3 patterns (resource management)
  11. 11. POSA 4patterns
  12. 12. 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
  13. 13. EA PatternsData 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/
  14. 14. J2EE patternswww.corej2eepatterns.com!
  15. 15. MotivationTrends • Hardware keeps getting smaller, faster, & cheaper • Software keeps getting larger, slower, & more expensive AbstractServiceHistorical 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
  16. 16. Mission-Critical ApplicationsLarge-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 AvionicsIndustrial Process Control Theater Missile Defense 17
  17. 17. Examples of Distributed Systems•  Automatic Teller Machine (ATM)•  Web-based travel site•  Stock transaction processing system•  Search service•  Multiplayer games
  18. 18. Automatic Teller Machine (“bancomat”)•  Client-server, server knows all clients•  Simple reply-response•  Transactions•  Tightly controlled distributed system•  High security
  19. 19. 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
  20. 20. Stock Transaction Processing•  Peer-to-peer communication•  Lots of clients (QoS: isochrony)•  Different markets•  Publish/subscribe model for many interactions
  21. 21. Search Engine Service•  Example: Google toolkit•  Language-neutral service•  Freely available•  Easy to write program exploiting its services•  Low support overhead
  22. 22. DiscussWhat do these applications all need?
  23. 23. What They All Need•  Communication infrastructure•  Remote references to objects and methods•  Remote method invocation or remote procedure call
  24. 24. 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
  25. 25. 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
  26. 26. 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)
  27. 27. 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
  28. 28. Some patterns for concurrency and distribution (POSA2)•  Broker•  Microkernel•  Pipes and filters•  Reactor•  Pool of threads•  ….
  29. 29. 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
  30. 30. Broker
  31. 31. 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
  32. 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
  33. 33. Broker pattern: contextYour environment is a distributed and possibly heterogeneous system with independent cooperating components. 34
  34. 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
  35. 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
  36. 36. Broker pattern: forcesBroker 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
  37. 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
  38. 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
  39. 39. Broker pattern: structure•  Participating components –  Clients –  Servers –  Brokers –  Bridges –  Client-side proxies –  Server-side proxies 40
  40. 40. Class Collaborators Class CollaboratorsClient Client-side proxy Server Server-side proxyResponsibility Broker Responsibility Broker- implements user - implementsfunctionality services- sends requests - registers itself with the local brokerto servers through - Send responsesa client-side proxy and exceptions back to clients via a server-side proxy
  41. 41. Class CollaboratorsBroker ClientResponsibility Server Client-side proxy- registers servers Server side proxy- offers API Bridge- sends requests- transfer msgs- error recovery- locates servers-interoperates withother brokersthrough bridges
  42. 42. Broker class diagram 43
  43. 43. Server Registration
  44. 44. Client requests a service
  45. 45. Broker forwards a request
  46. 46. Broker pattern: implementation1.  Define an object model or use an existing one2.  Decide which kind of component-interoperability the system should offer3.  Specify the APIs the broker component provides for collaborating with clients and servers4.  Use proxy objects to hide implementation details from clients and servers5.  Design the broker component in parallel with steps 3 and 4 •  broken down into nine steps6.  Develop IDL compilers 47
  47. 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
  48. 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
  49. 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
  50. 50. Object Request Broker (CORBA)
  51. 51. 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
  52. 52. 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
  53. 53. 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
  54. 54. 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
  55. 55. CRC Cards Class Collaborators Internal server MicrokernelClass Collaborators ResponsibilityMicrokernel Internal server  ImplementsResponsibility additional services Provides core  Encapsulatesmechanisms some system Offers communi- dependenciescation facilities Encapsulates sys- Class Collaboratorstem dependencies External server Microkernel Manages andcontrols resources Responsibility •  Provides programming interfaces for its clients 58
  56. 56. CRC cardsClass Collaborators Class Collaborators Client Adapter  Adapter External server Microkernel ResponsibilityResponsibility Hides system depen- Represents an dencies such asapplication communication facilities from the client. Invokes methods of external servers on behalf of clients 59
  57. 57. Static RelationshipsExternal Server Microkernel Internal ServerreceiveRequest executeMechanism receiveRequestdispatchRequest initCommunication executeServiceexecuteService findReceiver createHandle sendMessage callInternalServer initializes communication Adapter Client createRequest doTask calls service callService sends request 60
  58. 58. Microkernel
  59. 59. Scenario I 62
  60. 60. Scenario II 63
  61. 61. 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
  62. 62. Consequences•  Benefits –  portability –  flexibility and extensibility –  separation of policy and mechanism –  scalability –  reliability –  transparency•  Liabilities –  performance –  complexity of design and implementation 65
  63. 63. 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
  64. 64. 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/
  65. 65. Useful sites•  www.bredemeyer.com/links.htm!•  www.opengroup.org/architecture/!•  www.iasahome.org!•  java.sun.com/blueprints/corej2eepatterns/!
  66. 66. Questions?

×