Architecture Styles Instructor: Yongjie Zheng February 7, 2017 CS 5553: Software Architecture and Design
Architecture styles: a named collection of architecture design decisions that (1) are applicable in a given development context, (2) constrain architectural design decisions that are specific to a particular system within that context, and (3) elicit beneficial qualities in each resulting system. 2
Architecture Styles Traditional languageinfluenced styles Main program and subroutines Object-oriented Layered Virtual machines Client-server Data flow styles Batch-sequential Pipe-and-filter Shared memory Blackboard Rule-based Interpreter Interpreter Mobile code Implicit invocation Publish-subscribe Event-based Peer-to-Peer Derived styles C2 3
Example: the Lunar Lander (LL) video game 4
LL: Main program and subroutines. 5
LL in the object-oriented style. 6
Layered Styles An architecture is separated into ordered layers, and each layer exposes an interface to be used by above layers. Advantages Changes in a layer affect at most the adjacent two layers. Different implementations of layer are allowed as long as interface is preserved. Disadvantages Performance 7
LL in the virtual machines style. A layer offers a set of services ( a machine with a bunch of buttons and knobs ) that may be accessed by programs residing within the layer above it. In a strictly virtual machines style, programs at a given level may only access the services provided by the layer immediately below it. Benefits: clear dependence structure. Typical uses: network protocol stacks, database management systems. 8
9 A multiplayer version of LL in the clientserver style. Can be simply understood as a two-layer virtual machine with network connections. Servers do not know number or identities of clients. Client-to-client communication prohibited. Benefits: Centralization of data and computation.
Data Flow Styles Concerns the movement of data between independent processing elements. Batch Sequential: separate programs are executed in order; data is passed as an aggregate from one program to the other. Pipe and Filter: separate programs are executed, potentially concurrently; data is passed as a stream from one program to the next. 10
LL: Batch-sequential - an example of poor design. Constraints Linear topology. One program runs at a time, to completion. Benefits Simplicity, easy to control. Typical uses: transaction processing in financial systems. 11
LL in the pipe-and-filter style. Filters transform input data streams into output data streams. Pipes transmit outputs of one filter to inputs of another. Constraints Filters are mutually independent and do not share state; Filters have no knowledge of up- or down-stream filters. Benefits Filters can be easily composed for a large variety of tasks. Typical uses: Unix shells (e.g. ls -a grep 5553 more) 12
Shared State Styles Multiple components have access to the same data store, and communicate through that data store. Blackboard style: two kinds of components Central data structure - blackboard. Components operating on the blackboard. Rule-based style: Inference engine parses user input and determines whether it is a fact/rule or a query. If it is a fact/rule, it adds this entry to the knowledge base. Otherwise, it queries the knowledge base for applicable rules and attempts to resolve the query. 13
LL in the blackboard style. 14
The Blackboard Style Two kinds of components Central data structure. A collection of independent components that operate on the central data. Constraints The current state of the central data structure is the main trigger of selecting processes to execute. Benefits Ease of adaptation, enhanced scalability Examples AI systems Compiler
LL in a rule-based style. Constraints: all accesses to Knowledge Base must go through Inference Engine. Benefits: easy to change (e.g. add/remove rules). Typical uses: when the system can be understood as resolving a set of predicates (a logical programming language such as Prolog is usually used to build such a system.). 16
Interpreter Styles The distinctive characteristic of interpreter styles is dynamic, on-the-fly interpretation of commands. Basic Interpreter: the execution of commands one at at time. Mobile Code: the execution of one chunk of code at a time, usually at a remote host. Code moves to be interpreted on another host; depending on the variant, state does also. Variant: code-on-demand, remote evaluation, and mobile agent. 17
Basic Interpreter: interpreter parses and executes input commands, updating the state maintained by the interpreter. Benefits: highly dynamic with the set of commands dynamically modifiable. Typical uses: end-user programmability Examples: Microsoft Excel. LL in the interpreter style. 18
LL as code-on-demand. Code-on-demand: the initiator has resources and state but downloads code from another site to be executed locally. Remote evaluation: the initiator has the code but lacks the resources to execute the code. Thus, it transmits code to be processed to a remote host. For example, grid computing. Mobile agent: the initiator has the code and the state but some resources are located elsewhere. 19
Implicit Invocation Styles Calls are invoked indirectly and implicitly as a response to a notification or an event. No knowledge of what components will respond to event. No knowledge of order of responses. Advantages: ease of adaptation, enhanced scalability Publish-Subscribe: subscribers register/deregister to receive specific messages or specific content. Publishers broadcast messages to subscribers either synchronously or asynchronously. Event-Based: independent components asynchronously emit and receive events communicated over event buses. 20
Implicit Invocation Instead of invoking a procedure directly, a component can announce (or broadcast) one or more events. Other components in the system can register an interest in an event by associating a procedure with the event. When the event is announced the system itself invokes all of the procedures that have been registered for the event. Thus an event announcement ``implicitly'' causes the invocation of procedures in other modules. Variations: Publish-Subscribe, Event-Based.
Implicit Invocation Usually requires the external support (e.g. operating systems, middleware, programming language features) to handle generation/notification of events. Constraints Announcers of events do not know which components will be affected by those events. Benefits ease of adaptation, enhanced scalability. Example User interface development
LL in the publish-subscribe style. Publish-Subscribe: subscribers register/deregister to receive specific messages or specific content. Publishers broadcast messages to subscribers either synchronously or asynchronously. 23
LL in the event-based style. Event-Based: independent components asynchronously emit and receive events communicated over event buses. 24
Peer-to-Peer Style State and behavior are distributed among peers which can act as either clients or servers. Peers: independent components, having their own state and control thread. Topology: Network (may have redundant connections between peers); can vary arbitrarily and dynamically. Resource discovery is an important issue for P2P applications due to absence of centralization. 25
LL as a P2P application. 26