1 A View of Distributed Architecture Styles

Distributed Processing is classified into nine styles

from the viewpoint of the location of data and the
processing type between client and server.
Data is classified as Centralized or Distributed
Processing as either synchronous or asynchronous
Transaction Type
Atomic, Consistency, Isolation, Durability
Query Type
A reply from the server is synchronized with a request from the client
For Asynchronous processing:
A Notification type indicates that the server process is not synchronized with a
client request
 A View of Distributed Architecture Styles Cont:
2
Transaction Types
• Centralized: Single DB, Single Server
• Distributed: Multiple DBs on Multiple Servers with Synchronous processing
between Servers.
• Asynchronous: Multiple DB on Multiple Servers with Asynchronous processing
between Servers.
Query Types
• Centralized: Query and Reply Processing
• Distributed: Simultaneous access to to multiple data bases and support query
intensive immediate processing
• Asynchronous: Suited to asynchronous sharing of data (partial DB downloads)
Notification Types
Centralized: Automation of simple workflow, shipping memos, etc.
Distributed: Distributed transaction and data processing from mobile clients
Asynchronous: Supports loose integration of independent multiple applications
or systems.
3 Process Interaction in Distributed Programs Cont.
Asynchronous Message Passing
Channel has unlimited capacity
Send & receive do not block
Different communication channels are used for different kinds of messages.
Synchronous Message Passing
Channel has fixed capacity
Sending process waits for receiving process ready to receive, hence synchronized
Buffered Message Passing
Channel has fixed capacity
Send is delayed only when the channel is full
Generative Communication
Send & Receive processes share a single communication channel called tuple space.
Associative naming distinguishes message types in the tuple space
Remote Procedure Call & Rendezvous
Calling process delays until the request is serviced and results returned.
4 PIPD: Requests & Replies between clients & Servers
Server vs. monitors
A server is active, whereas a monitor is passive
Clients communicate with a server by sending and receiving messages,
whereas clients call monitor procedures.

A monitor is a synchronization mechanism that encapsulates permanent variables that record the
state of some resource and exports a set of procedures that are called to access the resource.
The procedures execute with mutual exclusion; they use condition variables for internal synchronization.
5 A View of Distributed Processing Styles Cont.
Architectural Styles for Transaction Types
Centralized vs. Distributed vs. Asynchronous Transaction Messages
Architectural Styles for Query Types
Centralized vs. Distributed vs. Asynchronous Query Messages
Architectural Styles for Notification Types
Centralized vs. Distributed vs. Asynchronous Notification Messages

Distributed
Location of Data
Centralized
Processing Types Processing Type Synchronous Asynchronous
between C/S Between Servers
Msg. Type
Synchronous Processing Transaction Type Centralized Transactions Distributed Asynchronous
(ACID) Transactions Transactions

Query Type Centralized Distributed Query Asynchronous Query

Query

Asynchronous Processing Notification Type Centralized Notification Distributed Asynchronous Notification

Notification
6 Process Interaction in Distributed Programs (PIDP)
Cooperating Message Passing Processes:
One way Data Flow Through a Network of Filters
Request & Replies between clients & servers
Heartbeat Interaction between neighboring processes
Probes & Echoes in Graphs
Broadcasts between processes in complete graphs
Token passing along edges in a graph
Coordination between centralized server processes
Replicated workers sharing a bag of tasks
7 Distributed Processes Architecture Styles

Other familiar architectures

Distributed processes –
have developed a number of common organizations for multi-process systems.
Some are defined by their topology (e.g. ring, star)
Others are characterized in terms of the kind of inter-process protocols that are used (e.g. heartbeat algorithms).
A common form of distributed system architecture is client-server.
A server provides services to the clients.
The server does not usually know the number or identity of the clients which will access it.
The clients know the identity of the server (or can find it out through another name-server) and access it through a remote
procedure call.
Main program/subroutine organizations: The primary organization of many systems mirrors the programming
language in which the system is written.
Domain Specific Software Architectures (DSSA)
State-transition systems: A common organization for many reactive systems. Define in terms of a set of states
and a set of named transitions
8 Process Control Architecture Styles
Process Control
Process Control Paradigms
Usually associated with real-time control of physical processes. The system maintains specified properties
of the output process near a reference value
Open Loop Systems: If the process is completely defined, repeatable, and the process runs without
surveillance
Space Heater
Closed Loop Systems: Output is used to control the inputs to maintain a monitored value
Speed Control, etc. Feed back and Feed Forward controller.
General Constructs:
Computational Elements
Data Elements
Control Loop Paradigm
Concerns
We need to worry about the physical control laws (s-domain) versus the time sampled control laws
(Z-Domain) and the introduction of poles and zeroes into the transfer function.
9 Heterogeneous Architecture Styles

Heterogeneous Architectures
Most systems involve the combination of several styles.
Components of a hierarchical system may have an internal structure
developed using a different method.
Connectors may also be decomposed into other systems (e.g. pipes can be
implemented internally as FIFO queues).
A single component may also use a mixture of architectural connectors.
An example of this is Unix pipes-and-filter system in which the file system acts as
the repository, receives control through initialization switches, and interacts with
other components through pipes.
10 Case Studies
Key Word in Context
The System accepts a ordered set of lines, each line is an ordered set of words, each word an ordered set of
characters.
Any line may be circularly shifted by repeatedly removing the first word and appending it at the end of the
line.
The system outputs a listing of all circular shifts of all lines in alphabetical order.
How does an architecture change wrt to changes in
Processing Algorithm
Data representation
Data Flow
Control Flow
How are these changes evaluated wrt:
System enhancements?
Performance?
Reuse?
Other Quality Attributes ?
11 Main Program with Shared Data
Master Control
Subroutine Calls

Input Circular Shift Alphabetizes Output

DM
Input Characters Index A Alphabetized Index Output
Mediu
Mediu
m
m

Disadvantages:
–Change in data storage format
affects all modules
– Ease of Upgrade to different
algorithms?
– Reusable in different domains? Fall 2002
12 Abstract Data Types
Master Control Subroutine Calls

Input Output

Set Char

Set Char
Input

Word

Setup

Word

Alpha
Char

Char
Output

Ith
Mediu
Mediu
m
m

Characters Circular Shift Alphabetic Shifts

Data is no longer shared by the modules
Each module provides an interface that permits other modules to access data only by invoking procedures in its
interface.
Advantages:
Both algorithms and data representations can be changed in each module without affecting the other modules.
Better reuse as the modules make few assumptions about the others in which they interact.
Disadvantages:
Adding new functions requires the other modules to be modify existing
modules or add new modules.
13 Implicit Invocation
Master Control Subroutine Calls
Input Circular Shift Alphabetizer Output

Outp

Delete

Delete
Insert

Insert
Input ut

I th

I th
Medi Medi
um um

Lines Lines
Data Interface is more abstract: Accesses data as a list or set of lines
Computations invoked implicitly as data is modified
New lines causes events to the shift module, producing data shifts in a separate data store, which in turn causes an event to the
alphabetizer to alphabetize the lines.
Note that NEW modules can be added to the system and they register for the events of interest. Reuse is enhanced as modules only
respond to registered events.

Disadvantage: May be difficult to control the processing order and activation of the event driven modules. Data driven
invocation tend to use more memory.
One of the problems I have encountered with the blackboard, in that if you are not specific in the events and trigger activation conditions
you get all kinds of computational activity happening when you least expect it or want it.
14 Pipes & Filters
Outp
ut
Input Circular Shift Alphabetizer Output Medi
Input um
Medi
um

Advantages:
Maintains the intuitive processing flow
Each filter can function in isolation
New functions easily added to the processing flow
Filters are logically independent of one another
Disadvantages:
Impossible to modify the design for interaction
Data design is inefficient as all data must be copied throughout the system.
15 Suggested Comparisons
Shared Data Abstract Data Implicit Pipe & Filter (The other
Type Invocation styles)

Algorithm - - + + :
Changes

Data - + - - :
Representation
Changes

Function Changes + - + + :
Performance + + - - :
Reuse - + - + :
Control + + + - :
Score 0 +2 0 0 :
16 Instrumentation Software
Instrumentation Software
An OO Model
How does the data and model fit together which led to issues on partitioning and
measuring.
How does the user interact with it ?
A Layered Model
Nice at first thought, however the boundaries of abstraction enforced by the layers,
conflicted with the needs for interaction between the wave form processing functions.
A Pipe & Filter Model
Corresponded well with the engineers understanding of signal processing and data
flow between signal processing functions.
How does the user interact with it ?
17 Case Studies
Instrumentation Software
A Modified Pipe & Filter
Added a control interface to the architecture to allow an external entity to set parameters of operation for the filters.
This is especially true in signal processing domains where we have a flow of data through a series of algorithms at
break-neck speeds and we want to conduct real-time performance enhancements and tuning.
A Control interface addresses the ability to interact with the processing and tailor the processing dynamically.
Decouples the signal processing software from changes in the control parameters.
Further Specialization
Introduced several kinds of pipes and filters to address different waveforms to address the memory requirements of the waveforms and
constraints of the system.
Summary
Know the benefits of each architectural style
Know how to tailor each style to address your particular needs

Filter
(n)
Acquir To:X-
Couple Clip
e Y
Control Variables
18 Ch. 3 Case Studies
Mobile Robotics
Design Considerations
– Req. (1) Architecture must Accommodate Deliberate and Reactive Behavior
Robot (system) must coordinate the actions to achieve the desired objectives based on the constraints
and its operating environment.
– Req. (2) Architecture must allow for Uncertainty
– Robot (system) actions are never fully predictable
– Robot (system) must be able to operate (decide) with incomplete and unreliable information.
– Req. (3) Architecture must account for dangers present in its environment or its operation
– Robot architecture must balance fault-tolerance, safety, performance
– (Especially when people are placed in harms way or do not have immediate access to emergency
services)
– Robot must be able to understand how to maintain its integrity, operators, and environment (you really
don’t want it to go bang (or cause a bang) in an explosive, corrosive, or contaminated environment)
..I.e power conservation, detect unexpected failures, etc.
– Req. (4) Architecture must provide designer flexibility in application development, experimentation, and
reconfiguration (new uploads)
19 Case Studies
Control Loop Approach
Req. (1) Architecture must:
Accommodate Deliberate and Reactive Behavior
– Closed Loop (real-time) feedback systems are very simple.
– (Book:) Note that feedback control loops assume changes in the environment are
continuous and require continuous reactions.
– (Note that this is Not necessarily true -> Some feedback systems (especially weather
prediction systems) can take months of sample and analysis before we are able to update
predicted data.
If the system is required to have an immediate reaction to an environment then we should consider
this approach.
We will find that there are better architecture approaches (I.e. simplified BB) for control of this
type of problem, even for the control of real-time video.
20 Case Studies
Req. (2) Architecture must allow for Uncertainty
– In a control loop approach, the expected output signal is fed back to the input.
– The difference between the input signal and the predicted output signal generates an error signal that
drives the control loop algorithm.
– This is the only uncertainty allowed.
– If more detailed uncertainty in the observed sampled inputs are required to be used in the control laws then we
might go to an optimal estimator.

– However if “Uncertainty” implies that we want “Emergent” as of yet undefined behavior from our
system in response to unplanned or unforeseen inputs, then a simple control loop architecture will not be
able to handle the requirement.
– “I.e I want the Mars Rover to “Investigate” any situation that appears “interesting”.

– (Dynamic task prioritization)

21 Case Studies
Control Loop Approach
Req. (3) Architecture must account for dangers present in its environment or its operation
– Fault-tolerance and safety are supported by this architecture style to the extent that it is
“SIMPLE” and therefore reduces the errors that can enter the system.
– This is often not the case -> sensors fail, redundancy and voting logic must now be incorporated
into the system, adding weight, power, and cost.

Req. (4) Architecture must provide designer flexibility in application development, experimentation,
and reconfiguration (new uploads)
– As is the case hardware components can often be easily replaced… What would you have to do control
this architecture in order to update a new software load?

Conclusion:
– Control Loop Architecture appears to be the best for SIMPLE robotic systems that handle a few number
and types of inputs within a PREDICTABLE environment
22 Case Studies
Layered Architecture
Define Levels of Control: This in essence delegates the control and design to an appropriate level.
Level 1: Manage Robot Actuators
Level 2: Manage Inputs (A/D, DI/O, D/A)
Level 3: manage Sensor Integration
Level 4: Maintain Robot Situation Awareness
Level 5: Navigates the Robot
Level 6: Schedule Robot Activities
Level 7: Re-Plan Robot Activities
Req. (1) Architecture must Accommodate Deliberate and Reactive Behavior
Nice breakout and localization of complexity
Note however that it does not separate the control and the data hierarchy.
Also note that each command must traverse ALL the layers.
There is really no straightforward way to do Immediate commanding.
23 Case Studies
Req. (2) Architecture must allow for Uncertainty
Note that we localize uncertainty management into the Situation Awareness Level.

Req. (3) Architecture must account for dangers present in its environment or its
operation
We can easily add a Fault-Detection and Isolation Layer, however this addition adds to the
complexity fo each command and each received input.
We can easily isolate processing that discovers interesting relationships in the domain to a level.
Req. (4) Architecture must provide flexibility in application development,
experimentation, and reconfiguration (new uploads)
If the layers are dependent on each other, then minor tweaks in one layer can have major adverse
impact on the processing at the next layer, especially if the layer dependencies are complex !!
24 Case Studies
Implicit Invocation
This architecture uses events to coordinate the interactions between tasks .
Tasks communicate by registering for certain events.
Tasks can then be separated into Exception handlers, Monitors, and Observers (Wiretapping in
your book).
Req. (1) Architecture must Accommodate Deliberate and Reactive Behavior
– Allows the tasks to be concurrent !! The other model do not address concurrency
directly.
Req. (2) Architecture must allow for Uncertainty
Not to clear how to build and control a task tree to handle uncertainty
Need to define what we man by uncertainty. It is mechanical components that fail to
operate correctly, or is it unexpected observations in the environment of interest.
Ie. Is a High temperature, or sudden increase in temperature “interesting”.
One approach is to define sensor LIMITS, and correlations between data that are
“Interesting” and then direct the processing according to the observations.
25 Case Studies
Implicit Invocation
Req. (3) Architecture must account for dangers present in its environment or its operation
Fault-Tolerance can be handled by redundant task trees and
A task tree that contains the voting logic between the redundant tasks can be added
(More hardware, -> more cost, more power, you must now also know how the hardware will typically fail.)
In some systems I have worked anywhere between 50-80% of the code is spent on error detection, handling, and
recovery.

Req. (4) Architecture must provide designer flexibility in application development, experimentation,
and reconfiguration (new uploads)
Making everything even driven makes the incremental development and replacement of functionality quite
easy.
We just register new components with the events they are interested in monitoring.
Note !!! Existing architecture is NOT Affected… True..
Yes but we often get unexpected behavior (and rather humorous ones) when we do not fully account for the
interaction between events, the processing, and the events they cause when system state is updated.
26 Case Studies
Blackboard Architecture
Req. (1) Architecture must Accommodate Deliberate and Reactive Behavior
“Control Flow has to be coerced into the database mechanisms… One way to avoid this pitfall and ensure that all processing
gets a chance to run is using the simple control approach I showed you earlier.
By taking control in this manner you are taking control over (or ignoring all together) the actual processing of the events.
You can write a single (or several) Control Knowledge sources (KS) that are scheduled to run just like all the other KS.
These control KS maintain the system state and assess the situation just as easily as any other KS that gets scheduled to run.
Req. (2) Architecture must allow for Uncertainty
Individual KSs can be developed to look for aberrancies and trends in the environment.
Am I overheating ?
Why am I overheating ?
What are the common failures and do I have the functionality to detect them?
Have I designed the system to be able to isolate the faults or provide an override value?
What tasks or behavior need to be reprioritized so as to not overheat ?
27 Case Studies
Blackboard Architecture
Req. (3) Architecture must account for dangers present in its environment or its operation
One can easily construct a KS like before to look for events that require immediate action.
Req. (4) Architecture must provide designer flexibility in application development,
experimentation, and reconfiguration (new uploads)
This architecture supports concurrency and decouples all the functionality, thus facilitating maintenance, and
field upgrades to individual KS.
This is especially true when you have limited bandwidth to perform remote updates.
Your program may be several HUNDRED MEGABYTES, sending all that over a Modem takes SO LONG.. So
…Consider sending only send the updates you need.
So we write an update KS that disables the offending KS, accepts and verifies the updates, and then links the
new KS into the task Lists !!
28 Case Studies

Cruise Control
OO Approach vs. Control Loop Architecture
Note that the difference in the approaches requires a restatement of the problem so that we are open to consider architecture alternatives.
Often a customer tells you what he wants in terms of indirect remarks at their view of an expected solution, rarely in terms of real requirements that would then
permit you the freedom to design the best solution.
Be brave enough to really take the time time to understand the requirements and then make the necessary architectural tradeoffs and the right decisions.

What are the expected INPUTS ?

What are the expected OUTPUTS?
What is the user or system expected to do with the INPUTS?
What is the user or system expected to do with the OUTPUTS?
Object View of Cruise Control
Based on Parnas.. Is the decomposition and the resultant Objects for the Object Correct ?
Why or Why Not ?
In controls a System is defined as being Observable and Controllable.. Does the the decomposition and
the resultant Objects support this definition of a System?
Does the Decomposition Directly Address the Requirements?
29 Case Studies
Cruise Control
Process View of Cruise Control
Computational Elements
Process Definition
Control Algorithm
Data Elements
Controlled Variables
Manipulated Variables
Set Points:
Input Sensor Variables
Notice the Restatement of the Problem and how it was developed
Whenever the system is active, determine the desired speed
Control the Engine the engine throttle to maintain the speed
How where we able to restate the problem ? What did we do to give us the proper insight ?
30 Case Studies
Analysis & Discussion
NOTE:
The selection of the Architecture commits the Designer to a particular View of a Problem.
How does your answer change for a local vs distributed homogeneous vs distributed heterogeneous system ?

First… Understand the requirements, then select and morph the architecture into one that best address the
requirements.
DO NOT TRY TO FORCE a square peg solution on a round hole problem !!!!
If you do, you will not adequately address the Quality Attributes for your specific system’s requirements.
Often your resultant architecture will be a blend of several techniques.
Notice the OO Approach:
An Object is an entity that is characterized by actions that is performs and that it required of other objects.
The Primary Criteria for decomposition is that each module in the system represents a major step in the overall
process.
So Which ABSTRACTION of the Problem is most appropriate.
Was the proper abstraction selected, Why or why not ? Select a Different Abstraction and discuss the alternatives?
How do I control or guarantee a given sequence in the OO approach?
31 Case Studies
Control View
Leads us to specify the output as the actual speed of the vehicle.
(Observable)
Separation of Control from Processing makes output explicit and supports
validation (Controllable)
Permits explicit decisions concerning the control decisions and algorithms to
be used. (EIA-632)
Control Paradigm discriminates between input types and make the feedback
loop more obvious (Controllable)
Clear separation between manual and automatic operations
Set point determination explicit and easier to verify (Observable)
See Issue with Booch’s design in your text.
32 Case Studies
Methodology Implications
Choose the Control Principle
Timing Synchronization ? Especially in Distributed Systems !…
Allowable Control Errors?
Choose the Control Variables
Local or Global ?
If Global how do we keep the state of these variables synchronized ?
Choose the Measured Variables
How ? What are is our criteria for selecting these variables?
Create the Subsystems (See Below)
Choose the Data Distribution, Organization, and Maintenance Policies ?
Global Status vs. Local Status ?
Incremental State Update vs. Global State Update ?

Choose the Task Allocation, Organization and Maintenance Policies ?

How Controlled ? (Local or Global)
How Updated ?

Chose the Failure Detection, Handling, and Recovery Policies ?

How Updated ?

Identify the QA impacts to the architecture at each level.