Architecture Styles

1

• Architecture Styles Patterns

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

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
Virtual Machine
Call / Return
Main program subroutine
Layered
Interpreter
Rule-based system
Object- oriented
RPC
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

Main Program
Subroutine 3
Subroutine 1
Subroutine 2
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
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
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 Stores State selects and
  triggers the process for execution.

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
1. Start Controlloop 2. ControlnextSource 3.
determine potential knowledge sources by
calling Blackboardinspect 4. Invoke
KnowledgeSourceexecCondition of each
candidate knowledge source 5. Each candidate
knowledge source invokes Blackboardinspect
to determine if/how it can contribute to
current state of solution 6. Control chooses a
knowledge source to invoke by calling
KnowledgeSourceexecAction 7. Executes
KnowledgeSourceupdateBlackboard 8. Calls
Blackboardinspect 9. Calls Blackboardupdate
12
Blackboard Hearsay- A Speech Recognition System

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

13
Virtual Machine Style - Interpreters
Goal Simulate non-native functionality for
portability or prototyping Examples -
Interpreters, e.g. Perl - Rule-based
systems, e.g. Prolog - Command language
processors - JVM (Intermediate language)
inputs
Program being Interpreted
Data (Program State)
State data
Data
Updates
Program Instructions
Interpretation Engine
outputs
Internal State
Selected instruction
Selected data
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

21
Middleware A More Effective Approach
22
Middleware A More Effective Approach
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
  CORBAObject
• virtual void myOper (CORBAlong ArgA)

26
Common Object Request Broker Architecture (CORBA)
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). RPCs 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

• IDL Definitions for
• Interface Hello
• Component HelloWorld
• Home Management HelloHome
• (You also need a Client for HelloWorld component)

interface Hello void sayHello (in string
username) component HelloWorld supports Hello
home HelloHome manages HelloWorld
34
Simple HelloWorld HelloHome Executors
interface Hello void sayHello (in string
username)component HelloWorld supports Hello
home HelloHome manages HelloWorld
class HelloHome_Impl public virtual
HelloHome, public virtual
CORBALocalObject public HelloHome_Impl
() HelloHome_Impl ()
ComponentsEnterpriseComponent_ptr create ()
return new HelloWorld_Impl ()
class HelloWorld_Impl public virtual
HelloWorld, public virtual CORBA
LocalObject public HelloWorld_Impl ()
HelloWorld_Impl () void sayHello (const char
usern) cout ltlt Hello World from
ltlt usern ltlt endl

• Implement behaviors of HelloWorld component
• Implement a lifecycle management strategy of
  HelloWorld component
• Client will call HelloWorld Component

35
CLIENT for Helloworld Component
Int main (int argc, char argv) CORBAORB_var
orb CORBAORB_init (argc,
argv) CORBAObject_var obj
orb-gtresolve_initial_references
("NameService")CosNamingNamingContext
Ext_var nc CosNamingNamingContextExt
_narrow(obj)obj
nc-gtresolve_str ("HelloHome")HelloHome_var hh
HelloHome_narrow(obj) HelloWorld_var hw
hh-gtcreate () hw-gtsayHello (John)
hw-gtremove () return 0

• Obtain object reference to home
• Create component
• Invoke remote method
• Remove component instance
• Clients dont always manage component lifecycle
  directly

OUTPUT gt./hello-client Hello World from John
36
Other Brokers Microsofts 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
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
46
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 (gt100 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
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
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
ASCII program text
Lexical Analyzer
token stream
Syntax Analyzer
abstract syntax tree
Semantic Analyzer
program
Intermediate Code Generator
optimized program
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.

70
Example Hierarchical Heterogeneity

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

71
Example Simultaneous Heterogeneity

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