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