Dataflow Architectural Styles (Styles 2) CPSC 410.
-
Upload
marjory-benson -
Category
Documents
-
view
218 -
download
0
Transcript of 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 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