test

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
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
& subroutine
Interpreter Rule-based
system RPC Object-
oriented

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 1 Subroutine 2 Subroutine 3

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 Store’s 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 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. 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 Data Program being
(Program State) Interpreted
State data
Data Updates Program
Instructions
outputs Interpretation Selected instruction
Internal
Engine Selected data
State

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. 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
INTERNETWORKING ARCH
MIDDLEWARE ARCH
RTP 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. 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 Middleware
Operating Operating Operating
System System System
Endsystem Networks Endsystem Networks Endsystem

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

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). 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
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. 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
{ • Interface Hello
void sayHello (in string username);
};
•Component:
HelloWorld
component HelloWorld supports Hello
{
}; •Home
home HelloHome manages HelloWorld Management:
{ HelloHome
};
(You also need a
Client for HelloWorld
component)

34. Simple HelloWorld & HelloHome Executors
interface Hello class HelloHome_Impl
{ void sayHello : public virtual HelloHome,
(in string username); public virtual
}; CORBA::LocalObject
component 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. CLIENT for Helloworld Component
Int main (int argc, char *argv[]) 1. Obtain object reference
{CORBA::ORB_var orb = to home
CORBA::ORB_init (argc, argv); 2. Create component
CORBA::Object_var obj = 3. Invoke remote method
orb->resolve_initial_references
("NameService"); 4. Remove component
CosNaming::NamingContextExt_var instance
nc CosNaming::NamingContextExt:: 5. Clients don’t always
_narrow(obj); manage component
obj = nc->resolve_str ("HelloHome"); lifecycle directly
HelloHome_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. 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
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)

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