Arch stylesandpatternsmi

Architecture Styles & Patterns

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 requirement dependent

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

Some Architectural Styles

Independent Components

Communicatingprocesses

Implicitinvocation

Explicitinvocation

Event systems

Call / ReturnVirtual Machine

Interpreter Rule-basedsystem

Main program& subroutine

Object-oriented

Layered

Data-Centered

Repository Blackboard

Data Flow

Batchsequential

Pipesand filters

RPC

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

Main Program/Subroutine Style

Early goals: reuse, independent developmentExample: hierarchical call/return style

Main Program

Subroutine 1 Subroutine 2 Subroutine 3

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

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

Data-Centered Style

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.

Shared Data

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

Blackboard Architecture Algorithm

1. Start Control::loop2. Control::nextSource 3. determine potential knowledge sources by calling Blackboard::inspect4. Invoke KnowledgeSource::execCondition of each candidate knowledge source5. Each candidate knowledge source invokes Blackboard::inspect to determine if/how it can contribute to current state of solution6. Control chooses a knowledge source to invoke by calling KnowledgeSource::execAction7. Executes KnowledgeSource::updateBlackboard8. Calls Blackboard::inspect 9. Calls Blackboard::update

Blackboard: Hearsay- A Speech Recognition System

Input: waveform representation of speech Output: machine representation of phrases

Virtual Machine Style - Interpreters

Interpretation Engine

InternalState

Program beingInterpreted

Data (Program State)

Data UpdatesState data

ProgramInstructions

outputs Selected instructionSelected data

inputs

Goal: Simulate non-native functionality for portability or prototypingExamples

- Interpreters, e.g. Perl - Rule-based systems, e.g. Prolog - Command language processors - JVM (Intermediate language)

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

Microkernel

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

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

Microkernel

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 ProcessesPossible topologies (ring, star, etc) Peer to Peer Client /Server.

Event Systems: Implicit Invocation: based on change notification Explicit Invocation Tight coupling

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

Win2K Linux LynxOS

Solaris VxWorks

Middleware

MiddlewareServices

MiddlewareApplications

MIDDLEWARE ARCH

RTP

DNS

HTTP

UDP TCP

IP

TELNET

Ethernet ATM FDDI

Fibre Channel

FTP

INTERNETWORKING ARCH

TFTP

21st Century20th Century

Middleware: A More Effective Approach

Common Services

Distribution Middleware

InfrastructureMiddleware

Domain-Specific Services

Applications

Endsystem Networks

Operating System

Sensors

Applications

Endsystem

Operating System

Applications

Endsystem

Operating System

Actuators

Networks

Controllers

Common Services

Distribution Middleware

InfrastructureMiddleware

Domain-Specific Services

Common Services

Distribution Middleware

InfrastructureMiddleware

Domain-Specific Services

Middleware: A More Effective Approach

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

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

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

Common Object Request Broker Architecture (CORBA)

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

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)

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.

Common Object Request Broker Architecture (CORBA): Details 3

How to Implement Remote Procedure Calls

Clientj Servant

Proc1

Proc4

Proc2

Proc3

Invoke request

Locate serviceRemember Client jGet address of service

Return RPC address to j

Invoke RPC

Result

Execute

Ship Result to Client j

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.

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

IDL Use Example HelloWorld: Interface, Component and Home

interface Hello { void sayHello (in string username);};

component HelloWorld supports Hello {};

home HelloHome manages HelloWorld {};

IDL Definitions for

• Interface Hello

•Component: HelloWorld

•Home Management: HelloHome

(You also need a Client for HelloWorld component)

Simple HelloWorld & HelloHome Executors

class HelloWorld_Impl : public virtual HelloWorld, public virtual CORBA:: LocalObject { public: HelloWorld_Impl () {} ~HelloWorld_Impl () {}

void sayHello (const char *usern) { cout << “Hello World from ” << usern << endl; }};

• Implement behaviors of HelloWorld component

• Implement a lifecycle management strategy of HelloWorld component

• Client will call HelloWorld Component

interface Hello { void sayHello (in string username);};component HelloWorld supports Hello

{};home HelloHome manages HelloWorld {};

class HelloHome_Impl : public virtual HelloHome, public virtual CORBA::LocalObject { public: HelloHome_Impl () {} ~HelloHome_Impl () {}

Components::EnterpriseComponent_ptr

create () { return new HelloWorld_Impl (); }};

CLIENT for Helloworld Component

Int main (int argc, char *argv[])

{CORBA::ORB_var orb = CORBA::ORB_init (argc, argv);

CORBA::Object_var obj = orb->resolve_initial_references ("NameService");CosNaming::NamingContextExt_var nc CosNaming::NamingContextExt:: _narrow(obj);obj = nc->resolve_str ("HelloHome");HelloHome_var hh = HelloHome::_narrow(obj);

HelloWorld_var hw = hh->create ();

hw->sayHello (“John”);

hw->remove ();

return 0;}

1. Obtain object reference to home

2. Create component

3. Invoke remote method

4. Remove component instance

5. Clients don’t always manage component lifecycle directly

OUTPUT

$>./hello-client

Hello World from John

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

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++

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)

Other Brokers: Component Object Model (COM, DCOM)

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.

Component Object Model (COM, DCOM)

All COM objects are registered with the component database.

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.

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

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

Client/Server Architectures

Advantages- Users only get information on demand - Design addresses presentation details - Different ways to view the same data

Disadvantages- Need for more sophisticated security, systems management- Applications development requires more resources to implement - Distribution Problems

Types:Tier 1: User system interface Tier 2: Middle-tier provides

Process management (business logic and rules execution) and Functions (e.g: queuing, application execution, and database staging)

Tier 3: Database management services

One & Two Tier Client/Server Architectures

Processing management split between user system interface environment and database management server environment. Tier 1: user system interface: In user's desktop environment Tier 2: database management services: In a server Limitations

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

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

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

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

Proxy Pattern - Components

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.

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)

Broker Pattern - Components

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

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

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

Broker Pattern – Runtime (High-level)

Broker Pattern – Runtime (Detailed)

Observer Pattern

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.

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.

Pipe & Filter example: Compiler

Lexical Analyzer

Syntax Analyzer

Semantic Analyzer

Intermediate Code Generator

ASCII program text

token stream

abstract syntax tree

program

optimized program

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

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.

Process Control (Closed Loop)

Feedback control system Measures a controlled variable Adjusts the process accordingly to keep it

near an acceptable set point

Process Control (Closed Loop)

Feedforward control system Anticipate changes to controlled variables

by monitoring other process variables.

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

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

Example: Locational Heterogeneity

A-7E used a cooperating process style in function drivers and call/return style elsewhere.

Example: Hierarchical Heterogeneity

Event system is a Blackboard, but, when decomposed, the component shows a layered style

Example: Simultaneous Heterogeneity

A-7E simultaneously used layered, cooperating process, and object-based styles