Intro

It is a pattern of component types and their interactions.
Define constraints: how things are allowed to interact.
Architectural pattern is synonym for style.
Defining features:
- Component types: e.g data store, processes etc.
- Component layout: e.g. which process is allowed to access data store.
- Connectors: e.g how are they connected ? RPC, Data stream ?
- Constraints: On components - e.g. data store cant modify itself, On connections - no P2P communication allowed.

Data Centred

Characterised by the access/update of a central data store.
The data store can be passive (e.g. a file) or be active (e.g. blackboard)
Good for integration and extensibility. There is a low coupling - only the data is shared.
E.g. Transactional DB, Blackboard, CASE Tools.

If the current state of the central data is the main trigger for processes to execute, then the repository can be a blackboard.
A common knowledge base, the "blackboard", is iteratively updated by a diverse group of specialist knowledge sources, starting with a problem specification and ending with a solution.
Each knowledge source updates the blackboard with a partial solution when its internal constraints match the blackboard state.
In this way, the specialists work together to solve the problem.
Invocation of a KS is triggered by the state of the blackboard.

Characterized by viewing the system as a series of transformations on successive pieces of input data.
Orderly motion of data. Explicit pattern of data flow.
No direct interactions b/w components.
Objectives: Modifiability - plug in/out components. Reusability - sequence of components plugged together.

Similar to batch sequential, except that the computations (filters) work incrementally on the data.
Data is immediately passed - i.e. it is streamed and not batched.
No state is retained between computations.
Pipes carry data from output of one computation (filter) to another.
e.g. Unix Shell - ls | grep "java" | wc -l