Dataflow Architectural Styles(Styles 2)CPSC 410

Dataflow Styles

• Focus is on Process View

Req 1. The output of one component passes to the input of another component▫ Without the use of shared storage

Req 2. System execution (control) always moves data forward▫ No central coordination▫ Contrast to layered styles

Dataflow Formats•Data processing is primary focus of

architecture•Often a single data format is mandated for

input/output•Simplifies composibility•e.g.

Document sort(Document in)Document find(Document in, String searchWord)Document head(Document in, int lines)Document tail(Document in, int lines)

Common Dataflow Arch.•Audio streams

e.g. Jipes signal processing libraries•Text streams

e.g. UNIX pipes: stdin/stdout•Image manipulation

e.g. rotate -> scale -> blur -> mask -> etc…

•RSS Feedse.g. Yahoo! Pipes

Relationship to Decorator chains•Often decorators exhibit dataflow style

characteristics▫Not always▫e.g. GUI Window decorator

•Not surprising because …▫Decorator chains can help with moving

data between two components

•Decorators do not consider Process View

Batch Sequential Style

•Each component completes transformation of input before passing to output

•Dataflow is equivalent to function compositionsink(c2(c1(source())))

Batch-Sequential: A Financial Application

Citation: Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

Batch Sequential Consequences+ Supports easy reuse of components+ Easy to reason about composition+ Easy to maintain by adding/removing

components– Each component has to wait for the

output of the previous component to begin▫No parallelism

Bad Dataflow Architecture Exampletransfer(Account from, Account to, double

amt){

boolean ok = from.withdraw(amt);if(ok) {

to.deposit(amt);}

} ????

A better design?•Seems correct but …•Provides no useful composibility•Some problems just aren’t good with

dataflow arch.

transfer

Account DB

from account

to account

amount

New Account

DB

Bad Dataflow Architecture Problems1. Data is persistent/shared

Data does not flow through the system

Account data stays in one place

2. Control is centrally coordinatedtransfer uses result of withdraw to decide on flow of execution

Pipe and Filter Style

Components run asynchronously; don’t wait before outputting data

Pipe and Filter Example

Unix pipesecho -e “My World\nHello World\nFriends” |grep World

Pipe and Filter Consequences

+ Parallelization efficient, and concurrency easy to reason about (no resource contention)

– Harder to program, debugNeed to manage chunking and

buffering using stream libraries

Why not parallelism?

1. FundamentalSimply not possible to break up data into smaller unitse.g. sort vs. grep

2. AccidentalDevelopers did not spend time to program concurrency

Fundamental Parallelism BottleneckUnix pipes

echo -e “My World\nHello World\nFriends” |grep World | sort

Conclusion (1/3)

•Not all systems make good dataflow architectures

•But …

•Not making a dataflow architecture when it is possible is a missed opportunity▫To simplify composition

Conclusion (2/3)

•Not all dataflow systems make good pipe-and-filter architectures

•But …

•Not making a pipe-and-filter architecture when possible is a missed opportunity▫To improve performance

Conclusion (3/3)

•More on dataflow architecture when we learn about Business Process Models