architecture styles patterns

1. Architecture Styles & Patterns

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. Some Architectural Styles 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. 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.

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. Main Program/Subroutine Style Early goals: reuse, independent development Example: hierarchical call/return style 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 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.

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 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 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).

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 don't make it evidently clear

9. Data-Centered Style 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 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.

10. Blackboard Architecture Applications Complex data interpretation (signal processing, speech/pattern recognition) Shared access to data with loosely coupled agents Components: Blackboard: To manage Central data Knowledge Sources Evaluate their applicability Compute a result Update Blackboard Control Monitor Blackboard Schedule Knowledge Sources activities

11. Blackboard Architecture Algorithm

12. Blackboard: Hearsay- A Speech Recognition System Input: waveform representation of speech Output: machine representation of phrases

13. Virtual Machine Style - Interpreters 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.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.

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 resourcese.g. process creation and cloning. Examples of Microkernals Chorus Windows NT – offers external servers for, OS/2, POSIX, Win32 applications Mach

15. Microkernel

16. Microkernel Components Internal Server: Extends the microkernel Implements additional services Encapsulates some system specifics Example: Drivers: device, comm etc External 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. 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. Microkernel

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. 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 Group's Common Object Request Broker Architecture (CORBA), Microsoft's Component Object Model (COM), DCOM

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. 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. 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); }

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. 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. 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. Common Object Request Broker Architecture (CORBA): Details 3 How to Implement Remote Procedure Calls

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. Common Object Request Broker Architecture (CORBA): Details 4 Dynamic Skeleton Interface (DSI) – Server side Allows an ORB to deliver requests to an object implementation that does not have compile-time knowledge of the type of the object it is implementing. The client making the request has no idea whether the implementation is using the type-specific IDL skeletons or is using the dynamic skeletons. Object Adapter Assists the ORB with delivering requests to the object and activating the object. The Adapter hides the details of the object, e.g. whether it is a DB object or a library object.

33. IDL Use Example HelloWorld: Interface, Component and Home

34. Simple HelloWorld & HelloHome Executors

35. CLIENT for Helloworld Component

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. 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. 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. Other Brokers: Component Object Model (COM, DCOM)

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. Component Object Model (COM, DCOM) All COM objects are registered with the component database.

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. 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 don't know which components are affected No assumption about order of processing Uses: Integrate tools Ensure database consistency

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. Client/Server Architectures

46. One & Two Tier Client/Server Architectures

47. Three Tier Client/Server Architecture

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. 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. Proxy Pattern - Components

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. 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. Broker Pattern - Components

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. 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. 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. Broker Pattern – Runtime (High-level)

58. Broker Pattern – Runtime (Detailed)

59. Observer Pattern

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. 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. Pipe & Filter example: Compiler

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. Process Control Architectures Open Loop system doesn't 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. Process Control (Closed Loop) Feedback control system Measures a controlled variable Adjusts the process accordingly to keep it near an acceptable set point

66. Process Control (Closed Loop) Feedforward control system Anticipate changes to controlled variables by monitoring other process variables.

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. Domain-Specific Architectures Library of different architecture styles Provides information for new systems in the same area Avoids rework on already known assumptions and relationships Heterogeneous systems. Locational Simultaneous Hierarchical

69. Example: Locational Heterogeneity A-7E used a cooperating process style in function drivers and call/return style elsewhere. 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.

70. Example: Hierarchical Heterogeneity Event system is a Blackboard, but, when decomposed, the component shows a layered style 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.

71. Example: Simultaneous Heterogeneity A-7E simultaneously used layered, cooperating process, and object-based styles 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.