Architectural Pattern⌗

An architectural pattern is a proven structural organisation organisation schema for software systems.

LAYERS PATTERN⌗

The Layer pattern helps to structure applications that can be decomposed into groups of subtasks, each of which is at a particular level of abstraction. Each layer provides services to the next higher layer.

  • This pattern has the following benefits:

    • A lower layer can be used by different higher layers. The TCP layer from TCP/IP connections, for instance, can be resued without changes by various applications, such as telnet or FTP.

    • Layers make standardisation easier clearly defined and commonly accepted levels of abstraction make it possible to develop standard-ised tasks and interfaces.

    • Dependencies are kept local.

A result of the above is that layers may easily be replcaed by a different implementation.

  • Issues in the Layers pattern

The most stable abstractions are in the lower layer: a change in the behaviour of a layer has no effect on the layers below it. The opposite is true as well: a change in the behaviour of a lower layer has an effect on the layers above it, so this should be avoided.

CLIENT-SERVER PATTERN⌗

In the Client-Server pattern, a server component provides services to multiple client components. A client component requests services from the server component. Servers are permanently active, listening for clients.

In fact, you can see the Client-Server pattern as a variant of the Layered pattern, crossing process or machine boundaries: clients from the higher level and the server froms the lower level.

  • State in the Client-Server pattern Clients and servers are often involved in sessions. This can be achieved in two different ways.
    • a stateless server, the session state is managed by the client.
    • a stateful server, the session state is maintained by the server and is associated with a client ID.

Master-Slave PATTERN⌗

The Master-Slave pattern supports fault tolerance and parallel computation. The master component distributes the work among identical slave components and computes a final result from the results the slaves return.

The Master-Slave pattern is applied, for instance, in process control, in embedded systems, in large-scale parallel computations and in fault-tolerant systems.

The Master-Slave pattern is an example of the divide-and-conquer principle. The pattern can only be applied to a problem that is decomposable.

PIPE-FILTER PATTERN (管道过滤模式)⌗

The Pipe-Filter pattern provides a structure for systems that produce a stream of data.

BROKER PATTERN (经纪人模式)⌗

The Broker pattern is used to structure distributed systems with decoupled components, which interact by remote service invocations. Such systems are very inflexible when components have to know each other’s location and other details.

Servers publish their capabilities (services and characteristics) to a broker. Clients request a service from the broker, and the broker then redirects the client to a suitable service from its registry.

PEER-TO-PEER PATTERN⌗

The Peer-to-Peer pattern can be seen as a symmetric(对称) Client-server patern: peers many function both as a client, requesting services from other peers, and as a server, providing services to other peers.

EVENT-BUS PATTERN⌗

The Event-Bus pattern is a pattern that deals with events. It works as follows: event sources publish messages to particular channels on an event bus. Event listeners subscribe to particular channels. Listeners are notified of messages that are published to a channel to which they have subscribed.

MODEL-VIEW-CONTROLLER PATTERN⌗

In the Model-View-Conyroller pattern, or MVC pattern, an interactive application is divided into three parts: the model contains the core functionality and data, the view displays the information to the user (more than one view may be defined) and the controller handles the input from the user.

BLACKBOARD PATTERN⌗

The Blackboard pattern is useful for probelms for which no deterministic solution strategies are available. Serveral specialised subsystems assem-ble their knowledge to build a possibly partial or approximate solution.

All components have access to a shared data store, the blackboard. Components may produce new data objects that are added to the black-board. Components look for particular kinds of data on the blackboard and may find these by pattern matching.

INTERRETER PATTERN⌗

The Interpreter pattern is used for designing a component that interprets programs written in a dedicated language. The interpreted program can be replaced easily.

Architectural styles⌗

Patterns have all been developed bottom-up: for a given problem, after a certain kind of solution has been used time and time again, this solution is written down in the form of a pattern.

Architectural styles, on the other hand, have all been formulated top-down: when you see a software system as a configuration of components and connectors, you can classify them according to the nature of the components and connectors.