Arch stylesandpatternsmi


Published on


Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • This diagram shows a small catalog of architectural styles, organized by is-a relations. Each related group shows a different style type and its substyles. For example, in the box at the top of the diagram,  event systems  is a substyle of  independent components.  Event systems themselves have two substyles: implicit and explicit invocation. In the next section of the lecture, we will take a closer look some of these styles.
  • The main-program-and-subroutine architecture, as shown in the figure above, is the classical programming paradigm. The goal is to decompose a program into smaller pieces to help achieve modifiability and enable reuse. A program is decomposed hierarchically. There is typically a single thread of control and each component in the hierarchy gets this control (optionally along with some data) from its parent and passes it along to its children. In addition to facilitating modifiability, this hierarchy of subroutines also enables independent development of various parts of the program to be developed separately by different work teams.
  • The object-oriented or abstract data types systems, as shown in the figure above, are the modern version of call-and-return architectures. The object-oriented paradigm, like the abstract data type paradigm from which it evolved, emphasizes the bundling of data and the knowledge of how to manipulate and access that data. The goal is to achieve the quality of modifiability. This bundle is an encapsulation that hides its internal secrets from its environment. Access to the object is allowed only through provided operations, typically known as methods, which are constrained forms of procedure calls. This encapsulation promotes reuse and modifiability, principally because it promotes separation of concerns: the user of a service need not know, and should not know, anything about how that service is implemented. The main features that distinguish the object-oriented paradigm from abstract data types are inheritance (the hierarchical sharing of definitions and code) and polymorphism (the ability to determine the semantics of an operation at runtime).
  • The data-centered style shown here has a passive repository (you can tell this because no control enters it). At the heart of this style is a centralized data store that communicates with a number of clients. The means of communication (sometimes called the coordination model) distinguishes the two subtypes: repository (the one shown above) and blackboard. A blackboard sends notification to subscribers when data of interest changes, and thus, is active. A blackboard differs from the figure shown above in that it would be drawn with control arrows emanating from the shared data. Note that when the clients are built as independently executing processes, what we have is a client-server style that belongs in the independent-component section of the style catalog. Thus, we see that styles are not rigidly separated from one another.
  • The figure shows three kinds of data: the program being interpreted, the program  s data (such as the values of variables assigned in the execution of the program), and the internal state of the interpreter (such as the values of registers or the current statement being executed). The interpretation engine selects an instruction from the program being interpreted, updates its internal state, and based on the instruction, potentially updates the program  s data. Executing a program via an interpreter adds flexibility through the ability to interrupt and query the program and introduce modifications at runtime, but there is a performance cost because of the additional computation involved in execution.
  • Systems are seldom built from a single style; rather, most systems use a mixture of styles, and we say that such systems are heterogeneous. There are three types of heterogeneous systems: locational, simultaneous, and hierarchical. The following three slides examine each of these types in turn.
  • Systems are seldom built from a single style; rather, most systems use a mixture of styles, and we say that such systems are heterogeneous. There are three types of heterogeneous systems: locational, simultaneous, and hierarchical. The following three slides examine each of these types in turn.
  • Systems are seldom built from a single style; rather, most systems use a mixture of styles, and we say that such systems are heterogeneous. There are three types of heterogeneous systems: locational, simultaneous, and hierarchical. The following three slides examine each of these types in turn.
  • Arch stylesandpatternsmi

    1. 1. Architecture Styles & Patterns
    2. 2. Architecture Styles & PatternsArchitectural Styles  Defines ways of selecting and presenting architectural building blocksArchitectural Design Patterns  Tried and tested high-level designs of architectural building blocks.Choice of style and patterns used is requirementdependent
    3. 3. Families of Architectural styles Call/Return  Main Program/Subroutine  Remote Procedure Call (RPC)  Layered (API)  Object Oriented Virtual Machine  Interpreter  Rule-based e.g. Prolog System Data-Flow  Batch Sequential  Pipe and Filter Data-Centered  Repository  Blackboard Independent Components (Loosely Coupled)  Communicating Processes  Event Based  Implicit Invocation, Explicit Invocation
    4. 4. Some Architectural Styles Independent Components Communicating Event systems processes Implicit Explicit invocation invocation Data Flow Data-Centered Batch Pipes sequential Repository Blackboard and filters Virtual Machine Call / Return Main program Layered & subroutineInterpreter Rule-based system RPC Object- oriented
    5. 5. Call and Return architectures Achieve modifiability and scalability. Sub-styles:  Main Program and Subroutine  hierarchically decompose a program  each component get control and data from its parent and pass it to children.  Remote Procedure Call  Main Program and Subroutine where parts are distributed on a network.  Increase performance (multiple processors).  Layered (accessed via API)  Object Oriented
    6. 6. Main Program/Subroutine StyleEarly goals: reuse, independent developmentExample: hierarchical call/return style Main Program Subroutine 1 Subroutine 2 Subroutine 3
    7. 7. Object-Oriented/Abstract Data Style Goals  More natural modelling of real world  Reuse by refinement (sub-classing & polymorphism) Encapsulation: Information hiding Objects  Maintain data integrity  Hide data representation  Communicate through messages Advantages  System is a set of independent agents  Improve maintenance and evolution  Good for reuse. Disadvantages  For interaction, an objects must know the identity of the target  Scale up can be inefficient and slow
    8. 8. Layered Hierarchies Goals: Increased Cohesion, Portability, Packaging, Standardization Examples: ISO Open Systems, 7 Layer model, TCP/IP, Motif Components: Hierarchical organization in layers  Each layer provides services to the one outside it  Each layer acts as a client to the layer inside it  Some cases all layers have access to all or some other layers  Other systems constrain access only to close layers Connectors: API and the protocols between layers. Advantages:  Supports design by abstraction levels.  Supports evolution: Easy to add and/or modify a current layer Disadvantages:  System performance may suffer from unnecessary layering overhead (function calls)  Not always easy to structure in clean layers.  Requirements dont make it evidently clear
    9. 9. Data-Centered Style Shared Data Client Client Client• Goals: Integrability, Scalability (new clients/data)• Components - Central data store - current state. - Independent components operating on the data store. • Data Centered Repository: Traditional Database Transaction type selects and triggers the process for execution. • Blackboard Data Store’s State selects and triggers the process for execution.
    10. 10. Blackboard ArchitectureApplications  Complex data interpretation (signal processing, speech/pattern recognition)  Shared access to data with loosely coupled agentsComponents: Blackboard: To manage Central data Knowledge Sources  Evaluate their applicability  Compute a result  Update Blackboard Control  Monitor Blackboard  Schedule Knowledge Sources activities
    11. 11. Blackboard Architecture Algorithm 1. Start Control::loop 2. Control::nextSource 3. determine potential knowledge sources by calling Blackboard::inspect 4. Invoke KnowledgeSource::execCondition of each candidate knowledge source 5. Each candidate knowledge source invokes Blackboard::inspect to determine if/how it can contribute to current state of solution 6. Control chooses a knowledge source to invoke by calling KnowledgeSource::execAction 7. Executes KnowledgeSource::updateBlackboard 8. Calls Blackboard::inspect 9. Calls Blackboard::update
    12. 12. Blackboard: Hearsay- A Speech Recognition System Input: waveform representation of speech Output: machine representation of phrases
    13. 13. Virtual Machine Style - InterpretersGoal: Simulate non-native functionality for portability orprototypingExamples - Interpreters, e.g. Perl - Rule-based systems, e.g. Prolog - Command language processors - JVM (Intermediate language) inputs Data Program being (Program State) Interpreted State data Data Updates Program Instructions outputs Interpretation Selected instruction Internal Engine Selected data State
    14. 14. Microkernel Allows adaptability to changing system requirements Separates the functional core from extended functionality and customer-specific parts Selects and uses primitives to provide and implement new interfaces Offers communication facilities Encapsulates system dependencies Manages and control resources e.g. process creation and cloning.Examples of Microkernals Chorus Windows NT – offers external servers for, OS/2, POSIX, Win32 applications Mach
    15. 15. Microkernel
    16. 16. Microkernel ComponentsInternal Server: Extends the microkernel  Implements additional services  Encapsulates some system specifics Example: Drivers: device, comm etcExternal Server:  Uses Microkernel for implementing its own view of application domain (layer of abstraction on top of mechanisms), i.e.  Provides programming interfaces for its clients  Implement an existing application platform Example: OS/2 external server, UNIX external server
    17. 17. Microkernel Components Client An application associated with exactly one external server Adapter - An interface between clients and their external servers - Hides system dependencies from clients (e.g: Comm facilities) - Invokes methods of external servers on behalf of clients Example: External server implements OS/2, Adapter implements OS/2 programming interface
    18. 18. Microkernel
    19. 19. Independent Components Consists of independent processes or objects communicating through messages. No control between components. Achieve modifiability (decouple various portions of the computation). Include:  Communicating Processes Possible topologies (ring, star, etc)  Peer to Peer  Client /Server.  Event Systems:  Implicit Invocation: based on change notification  Explicit Invocation  Tight coupling
    20. 20. Middle Tier infrastructure (Middle-Ware) Connectivity software  consists of a set of enabling services  allow multiple processes running on one or more machines to interact across a network Examples:  Object Management Groups Common Object Request Broker Architecture (CORBA),  Microsofts Component Object Model (COM), DCOM
    21. 21. Middleware: A More Effective Approach INTERNETWORKING ARCH MIDDLEWARE ARCHRTP TFTP FTP HTTP Middleware Applications DNS TELNET Middleware Services UDP TCP IP Middleware Fibre Channel Solaris VxWorks Ethernet ATM FDDI Win2K Linux LynxOS 20th Century 21st Century
    22. 22. Middleware: A More Effective Approach Applications Applications Applications Sensors Controllers Actuators Domain-Specific Domain-Specific Domain-Specific Services Services Services Common Common Common Services Services Services Distribution Distribution Distribution Middleware Middleware Middleware Infrastructure Infrastructure Infrastructure Middleware Middleware MiddlewareOperating Operating OperatingSystem System System Endsystem Networks Endsystem Networks Endsystem
    23. 23. Middle Tier Infrastructure (Middle-ware) Application Programming Interfaces (API) allow applications:  Location transparently across the network, providing interaction with another application or service  To be independent from network services  To be reliable and available  To scale up in capacity without losing functionality
    24. 24. Common Object Request Broker Architecture (CORBA)  Specification of a standard architecture for Object Request Brokers (ORBs)  Purpose  Allow ORB products development that support  Application portability and inter-operability  Across different programming languages, hardware platforms, operating systems, and ORB implementations
    25. 25. Common Object Request Broker Architecture (CORBA)  All objects defined in CORBA use an Interface Definition Language (IDL).  Language mappings are defined from IDL  C, C++, Ada95, and Smalltalk80.  Allows language heterogeneity IDL C++ Interface MineToCee Class MineToCee: { void myOper (long ArgA); public vitural CORBA::Object } { virtual void myOper (CORBA::long ArgA); }
    26. 26. Common Object Request Broker Architecture (CORBA)
    27. 27. Common Object Request Broker Architecture (CORBA)  ORB Core - CORBA runtime infrastructure.  ORB Interface - Standard interface (defined in IDL) to functions provided by all CORBA- compliant ORBs.  IDL Stubs  Generated by the IDL processor for each interface defined in IDL  Hide low-level networking details of object communication from the client,  Present a high-level, object type-specific application programming interface (API).
    28. 28. Common Object Request Broker Architecture (CORBA): Details 1  Object Request Broker (ORB): - Decouples Client from Service  Location and Functional Transparency - Client requests appear to him to be local procedure calls. When a client invokes an operation, the ORB is responsible for finding the object implementation, transparently activating it if necessary, delivering the request to the object, and returning any response to the caller.  ORB Interface – A set of tasks and libraries providing functions for - Converting object references to strings and vice versa, - Creating argument lists for requests made through the Dynamic Invocation Interface (DII)
    29. 29. Common Object Request Broker Architecture (CORBA): Details 2 CORBA IDL Stubs and Skeletons: - Client Side is called IDL Stub - Server Side is called IDL Skeleton + Produced by IDL Compiler in the target programming language + Stubs and the Skeleton are the ``glue between the client and server applications, and the ORB. + Only allows remote invocation through RPC (Remote Procedure Calls). RPC’s can be implemented by providing the address pointer to the client to the (server) procedure it needs to invoke.
    30. 30. Common Object Request Broker Architecture (CORBA): Details 3How to Implement Remote Procedure Calls Clientj Servant Invoke request Locate service Return RPC address to j Remember Client j Get address of service Invoke RPC Execute Proc1 Proc2 Ship Result to Client j Result Proc3 Proc4
    31. 31. Common Object Request Broker Architecture (CORBA): Details 4 Dynamic Invocation Interface (DII) Client Side This interface allows a client to directly access services provided by the ORB. Applications use the DII to dynamically issue requests to objects without requiring IDL interface-specific stubs to be linked in. Unlike IDL stubs (which only allow RPC-style requests), the DII also allows clients to make -Non-blocking requests -Oneway (send-only) calls.
    32. 32. Common Object Request Broker Architecture (CORBA): Details 4Dynamic Skeleton Interface (DSI) – Server sideAllows an ORB to deliver requeststo an object implementation thatdoes not have compile-time knowledge ofthe type of the object it is implementing.The client making the request has no idea whetherthe implementation is using the type-specificIDL skeletons or is using the dynamic skeletons.Object AdapterAssists the ORB with delivering requests to the object andactivating the object. The Adapter hides the details of theobject, e.g. whether it is a DB object or a library object.
    33. 33. IDL Use Example HelloWorld: Interface, Component and Home IDL Definitions forinterface Hello{ • Interface Hello void sayHello (in string username);}; •Component: HelloWorldcomponent HelloWorld supports Hello{}; •Homehome HelloHome manages HelloWorld Management:{ HelloHome}; (You also need a Client for HelloWorld component)
    34. 34. Simple HelloWorld & HelloHome Executorsinterface Hello class HelloHome_Impl{ void sayHello : public virtual HelloHome, (in string username); public virtual}; CORBA::LocalObjectcomponent HelloWorld supports Hello { public: HelloHome_Impl () {}{}; ~HelloHome_Impl () {}home HelloHome manages HelloWorld{};class HelloWorld_Impl Components::EnterpriseComponent_ptr : public virtual HelloWorld, public virtual create () CORBA:: LocalObject { return new HelloWorld_Impl ();{ public: } HelloWorld_Impl () {} }; ~HelloWorld_Impl () {} • Implement behaviors of HelloWorld void sayHello (const char *usern) component { cout << “Hello World from ” << usern • Implement a lifecycle management << endl; strategy of HelloWorld component } • Client will call HelloWorld}; Component
    35. 35. CLIENT for Helloworld ComponentInt main (int argc, char *argv[]) 1. Obtain object reference{CORBA::ORB_var orb = to home CORBA::ORB_init (argc, argv); 2. Create componentCORBA::Object_var obj = 3. Invoke remote method orb->resolve_initial_references ("NameService"); 4. Remove componentCosNaming::NamingContextExt_var instancenc CosNaming::NamingContextExt:: 5. Clients don’t always _narrow(obj); manage componentobj = nc->resolve_str ("HelloHome"); lifecycle directlyHelloHome_var hh = HelloHome::_narrow(obj); HelloWorld_var hw = hh->create (); OUTPUT hw->sayHello (“John”); $>./hello-client hw->remove (); Hello World from John return 0;}
    36. 36. Other Brokers: Microsoft’s Component Object Model (COM, DCOM) COM  Framework for integrating components.  Allows developers to build systems by assembling reusable components from different vendors. Distributed COM (DCOM)  For distributed network-based interactions. OLE (Object Linking & Embedding), ActiveX, MTS  Higher-level application services built on top of COM
    37. 37. MS, Component Object Model (COM, DCOM) OLE Provides services (Object Linking and Embedding) used in the creation of compound documents (documents generated from multiple tool sources) ActiveX extension to allow components to be embedded in Web sites. MTS extension with enterprise services (e.g: transaction, security) to allow Enterprise Information Systems (EIS) to be built using COM components. COM+  Integrates MTS services and message queuing into COM, and makes COM programming easier  integration with Visual Basic, Visual C++, J++
    38. 38. MS, Component Object Model (COM, DCOM) Services implemented by COM objects are exposed through a set of interfaces  COM defines a binary structure for the interface between the client and the object.  COM objects and interfaces specified using Microsoft Interface Definition Language (IDL)
    39. 39. Other Brokers: Component Object Model (COM, DCOM)
    40. 40. Component Object Model (COM, DCOM) Every COM object runs inside a server:  In-process server: client and server execute in the same process  Local Object Proxy: server running in a different process but on the same machine.  Communication through inter-process communication.  Remote Object Proxy: remote server on another machine.  Communication through DCE RPC (supported by DCOM).  All COM objects are registered with a component database.
    41. 41. Component Object Model (COM, DCOM)All COM objects are registered with the componentdatabase.
    42. 42. Peer-to-Peer Architecture No distinction between processes (nodes) Each maintain  its own data-store, as well as  a dynamic routing table of addresses of other nodes Examples: gnutella, freenet.
    43. 43. Event-Based (Implicit Invocation) Some components announce (broadcast) events Other components register interest in events  Associate a routine to each event, automatically executed when the event is produced. A part of the system is in charge of transmitting events between producers and consumers. Semantic constraints  Announcers of events dont know which components are affected  No assumption about order of processing Uses:  Integrate tools  Ensure database consistency
    44. 44. Event-Based (Implicit Invocation) Advantages  High reuse potential  Ease evolution Disadvantages  Components/Procedures have to register for an event  No insurance that an event will be treated  Exchange of data  a shared repository is often needed.  Difficult to reason about system correctness.  Compiler can no longer do early detection  Difficulty to trace without debugging tools  Data typing becomes very weak
    45. 45. Client/Server ArchitecturesAdvantages - Users only get information on demand - Design addresses presentation details - Different ways to view the same dataDisadvantages - Need for more sophisticated security, systems management - Applications development requires more resources to implement - Distribution ProblemsTypes:Tier 1: User system interfaceTier 2: Middle-tier provides Process management (business logic and rules execution) and Functions (e.g: queuing, application execution, and database staging)
    46. 46. One & Two Tier Client/Server ArchitecturesProcessing management split between user system interfaceenvironment and database management server environment.Tier 1: user system interface: In users desktop environmentTier 2: database management services: In a serverLimitations Performance deteriorate when number of clients is large (>100 users) Flexibility and choice of DBMS for applications reduced (by process management at server level – stored procedures) Limited flexibility in moving program functionality between servers
    47. 47. Three Tier Client/Server Architecture• Centralizes process logic• Improve performance, flexibility, maintainability, reusability, and scalability• Changes must only be written once and placed on the middle tier server to be available throughout the system• Distributed database integrity more easily enforced• Access to resources based on names
    48. 48. Proxy Pattern Proxy: Is a representative, surrogate or placeholder for another object (a server object) Allows:  transparency and simplicity of access to servers  e.g: to make calls to remote objects with the same syntax as a local call  run-time efficiency, cost-effectiveness, safety
    49. 49. Proxy Pattern - Components Client  uses interface provided by proxy to request services Original (RealSubject)  implements a service Proxy  provides the interface of the original to clients  ensures a safe, efficient and correct access to the original AbstractOriginal (Subject)  abstract base class for proxy and original
    50. 50. Proxy Pattern - Components
    51. 51. Proxy Pattern - Variants Remote Proxy  Local representative for an object in a different address space Cache Proxy  Local clients can share results from remote components Protection Proxy  Controls access to the original object Firewall Proxy  Controls access from outside world.
    52. 52. Broker Pattern Client-Server pattern to:  hide system/implementation details from clients  allow remote, location-transparent service access  allow exchange, addition, deletion of components at run-time Examples of implementations  CORBA  OLE (On Line Extension)  COM/DCOM (MS Component Object Model)
    53. 53. Broker Pattern - Components
    54. 54. Broker Pattern - Components Client  Implements user functionality  Sends requests to servers through a client-side proxy Server  Implements services  Registers itself with the local broker  Sends responses and exceptions back to client through server-side proxy
    55. 55. Broker Pattern - Components Broker:  (un-)register servers  offers APIs  transfers messages  ensures error recovery  interoperates with other brokers  locates servers Related Pattern, Bridge:  encapsulates network-specific functionality  mediates between local broker and remote broker
    56. 56. Broker Pattern - Components Client-side Proxy  Encapsulates system-specific functionality  Mediates between client and broker Server-side Proxy  Calls services within server  Encapsulates system-specific functionality  Mediates between server and broker
    57. 57. Broker Pattern – Runtime (High-level)
    58. 58. Broker Pattern – Runtime (Detailed)
    59. 59. Observer Pattern
    60. 60. Data Flow Patterns Achieve reuse and modifiability System is a succession of transformations on pieces of input data Include:  Batch Sequential  Components, independent programs, execute and complete one after the other.  Data transmitted as a whole between steps.  Pipes and Filters  incremental transformation of data by successive components.  Data flows as a stream between between components.
    61. 61. Pipes and Filters Filters Read a stream of data on its inputs and produce a stream of data on its outputs. Connectors (pipes) Transmit output produced by filters to other filters.
    62. 62. Pipe & Filter example: Compiler ASCII program text Lexical Analyzer token stream Syntax Analyzer abstract syntax tree Semantic Analyzer program Intermediate Code Generator optimized program
    63. 63. Process Control Systems Continually running system used for maintaining correct values. The errors are compensated for through feedback. Examples  Temperature control system  Power plant control system Variables  Process variables  properties of the process that can be measured  value obtained by sensors  Controlled variables  process variables whose value the system intend to control  Reference value (set point)  desired value for a controlled variable
    64. 64. Process Control Architectures Open Loop system  doesnt use information about process variables to adjust the system.  rarely suited to physical processes in the real world. Closed Loop system  uses information about process variables to manipulate process variables in order to compensate for variations in process variables and operation conditions.
    65. 65. Process Control (Closed Loop) Feedback control system  Measures a controlled variable  Adjusts the process accordingly to keep it near an acceptable set point
    66. 66. Process Control (Closed Loop) Feedforward control system  Anticipate changes to controlled variables by monitoring other process variables.
    67. 67. Process Control - Issues Computational elements  process definition (include mechanisms for changing process variables)  control algorithm (how to decide when and how to make changes) Data elements (process variables, set point) Control loop scheme (open-loop, closed-feedback, closed-feed forward)Drawbacks - One must decide What variables to monitor What sensors to use How to calibrate them How to deal with timing of sensing and control
    68. 68. Domain-Specific Architectures Library of different architecture styles Provides information for new systems in the same area Avoids rework on already known assumptions and relationshipsHeterogeneous systems.  Locational  Simultaneous  Hierarchical
    69. 69. Example: Locational Heterogeneity A-7E used a cooperating process style in function drivers and call/return style elsewhere.
    70. 70. Example: Hierarchical Heterogeneity Event system is a Blackboard, but, when decomposed, the component shows a layered style
    71. 71. Example: Simultaneous Heterogeneity A-7E simultaneously used layered, cooperating process, and object-based styles
    1. A particular slide catching your eye?

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