Pattern name

Broker.

Aliases

Object Broker, Object Request Broker.

Context

Software architectural design, distributed systems.

Problem

Distributed application in which multiple clients communicate with multiple servers. Clients do not know locations of servers.

Summary of solution

Use broker. Servers register their services with broker. Clients send service requests to broker. Broker acts as intermediary between client and server.

Strengths of solution

Location transparency: Servers may relocate easily. Clients do not need to know locations of servers.

Weaknesses of solution

Additional overhead because broker is involved in message communication. Broker can become a bottleneck if there is a heavy load at the broker. Client may keep outdated service handle instead of discarding.

Applicability

Distributed environments: client/server and distribution applications with multiple servers.

Related patterns

Broker Forwarding, Broker Handle.

Reference

Chapter 10, Section 10.2.4; Mowbray and Ruh 1997; Orfali et al. 1996.

Pattern name

Centralized Control.

Aliases

Centralized Controller, System Controller.

Context

Centralized application where overall control is needed.

Problem

Several actions and activities are state-dependent and need to be controlled and sequenced.

Summary of solution

There is one control component, which conceptually executes a statechart and provides the overall control and sequencing of the system or subsystem.

Strengths of solution

Encapsulates all state-dependent control in one component.

Weaknesses of solution

Could lead to overcentralized control, in which case decentralized control should be considered.

Applicability

Real-time control systems, state-dependent applications.

Related patterns

Distributed Control, Hierarchical Control.

Reference

Chapter 10, Section 10.2.6.

Pattern name

Client/Agent/Server.

Aliases

Distributed Agents, Multi-Agent.

Context

Distributed applications.

Problem

Client/server application in which negotiation between clients and servers is required.

Summary of solution

Agents negotiate with servers on behalf of their clients. Server might itself have an agent act on its behalf, in which case a client agent acts on behalf of the client and a server agent acts on behalf of the server.

Strengths of solution

Offloads negotiation details from clients and servers.

Weaknesses of solution

Negotiation may take longer by involving third party. Negotiation may be lengthy and inconclusive.

Applicability

Distributed environments: client/server and distribution applications with multiple servers.

Related patterns

Often used in conjunction with broker patterns (Broker Forwarding, Broker Handle, Discovery).

Reference

Chapter 10, Section 10.2.5.

Pattern name

Client/Server.

Aliases

Multiple-Client/Single-Server

Context

Software architectural design, distributed systems.

Problem

Distributed application in which multiple clients require services from a single server.

Summary of solution

Server is a provider of services, and client requests services. Server provides services for multiple clients. Server responds to requests and does not initiate requests.

Strengths of solution

Good way for client to communicate with server when it needs a reply. Very common form of communication in client/server applications.

Weaknesses of solution

Client can be held up indefinitely if there is a heavy load at the server.

Applicability

Distributed processing: client/server and distribution applications with multiple servers.

Related patterns

Variations of this pattern include Multiple-Client/Multiple-Server and Multitier Client/Server.

Reference

Chapter 10, Section 10.2.3; Orfali et al. 1996.

Pattern name

Distributed Control.

Aliases

Distributed Controller.

Context

Distributed application with real-time control requirement.

Problem

Distributed application with multiple locations where real-time localized control is needed at several locations.

Summary of solution

There are several control components, such that each component controls a given part of the system by conceptually executing a statechart. Control is distributed among the various control components; no single component has overall control.

Strengths of solution

Overcomes potential problem of overcentralized control.

Weaknesses of solution

Does not have an overall coordinator. If this is needed, consider using Hierarchical Control pattern.

Applicability

Distributed real-time control, distributed state-dependent applications.

Related patterns

Hierarchical Control, Centralized Control.

Reference

Chapter 10, Section 10.2.7.

Pattern name

Hierarchical Control.

Aliases

Multilevel Control.

Context

Distributed application with real-time control requirement.

Problem

Distributed application with multiple locations where both real-time localized control and overall control are needed.

Summary of solution

There are several control components, each controlling a given part of a system by conceptually executing a statechart. There is also a coordinator component, which provides high-level control by deciding the next job for each control component and communicating that information directly to the control component.

Strengths of solution

Overcomes potential problem with Distributed Control pattern by providing high-level control and coordination.

Weaknesses of solution

Coordinator may become a bottleneck when the load is high.

Applicability

Distributed real-time control, distributed state-dependent applications.

Related patterns

Distributed Control, Centralized Control.

Reference

Chapter 10, Section 10.2.8.

Pattern name

Kernel.

Aliases

Microkernel.

Context

Software architectural design.

Problem

A small core of essential functionality that can be used by other components is needed.

Summary of solution

Kernel provides a well-defined interface consisting of operations (procedures or functions) that can be called by other parts of the software system.

Strengths of solution

Kernel can be designed to be highly efficient.

Weaknesses of solution

If care is not taken, kernel can become too large and bloated. Alternatively, essential functionality could be left out in error.

Applicability

Operating systems, software product lines.

Related patterns

Can be lowest layer of Layers of Abstraction architecture.

Reference

Chapter 10, Section 10.2.2; Bacon 1997; Buschmann et al. 1996.

Pattern name

Layers of Abstraction.

Aliases

Hierarchical Layers, Levels of Abstraction.

Context

Software architectural design.

Problem

A software architecture that encourages design for ease of extension and contraction is needed.

Summary of solution

Components at lower layers provide services for components at higher layers. Components may use only services provided by components at lower layers.

Strengths of solution

Promotes extension and contraction of software design.

Weaknesses of solution

Could lead to inefficiency if too many layers need to be traversed.

Applicability

Operating systems, communication protocols, software product lines.

Related patterns

Kernel can be lowest layer of Layers of Abstraction architecture. Variations of this pattern include Flexible Layers of Abstraction.

Reference

Chapter 10, Section 10.2.1; Hoffman and Weiss 2001; Parnas 1979.

Pattern name

Asynchronous Message Communication.

Aliases

Loosely Coupled Message Communication.

Context

Concurrent or distributed systems.

Problem

Concurrent or distributed application has concurrent components that need to communicate with each other. Producer does not need to wait for consumer. Producer does not need a reply.

Summary of solution

Use message queue between producer component and consumer component. Producer sends message to consumer and continues. Consumer receives message. Messages are queued FIFO if consumer is busy. Consumer is suspended if no message is available. Producer needs timeout notification if consumer node is down.

Strengths of solution

Consumer does not hold up producer.

Weaknesses of solution

If producer produces messages more quickly than consumer can process them, the message queue will eventually overflow.

Applicability

Centralized and distributed environments: real-time systems, client/server and distribution applications.

Related patterns

Asynchronous Message Communication with Callback.

Reference

Chapter 10, Section 10.3.1.

Pattern name

Asynchronous Message Communication with Callback.

Aliases

Loosely Coupled Communication with Callback.

Context

Concurrent or distributed systems.

Problem

Concurrent or distributed application in which concurrent components need to communicate with each other. Client does not need to wait for server but does need to receive a reply later.

Summary of solution

Use loosely coupled communication between client components and server component. Client sends service request to server, which includes client operation (callback) handle. Client does not wait for reply. After server services the client request, it uses the handle to call the client operation remotely (the callback).

Strengths of solution

Good way for client to communicate with server when it needs a reply but can continue executing and receive reply later.

Weaknesses of solution

Suitable only if the client does not need to send multiple requests before receiving the first reply.

Applicability

Distributed environments: client/server and distribution applications with multiple servers.

Related patterns

Consider Bidirectional Asynchronous Message Communication as alternative pattern.

Reference

Chapter 10, Section 10.3.4.

Pattern name

Bidirectional Asynchronous Message Communication.

Aliases

Bidirectional Loosely Coupled Message Communication.

Context

Concurrent or distributed systems.

Problem

Concurrent or distributed application in which concurrent components need to communicate with each other. Producer does not need to wait for consumer, although it does need to receive replies later. Producer can send several requests before receiving first reply.

Summary of solution

Use two message queues between producer component and consumer com-ponent: one for messages from producer to consumer, and one for messages from consumer to producer. Producer sends message to consumer on P→C queue and continues. Consumer receives message. Messages are queued if consumer is busy. Consumer sends replies on C→P queue.

Strengths of solution

Producer does not get held up by consumer. Producer receives replies later, when it needs them.

Weaknesses of solution

If producer produces messages more quickly than consumer can process them, the message (P→C) queue will eventually overflow. If producer does not service replies quickly enough, the reply (C→P) queue will overflow.

Applicability

Centralized and distributed environments: real-time systems, client/server and distribution applications.

Related patterns

Asynchronous Message Communication with Callback.

Reference

Chapter 10, Section 10.3.2.

Pattern name

Broadcast.

Aliases

Broadcast Communication.

Context

Distributed systems.

Problem

Distributed application with multiple clients and servers. At times, servers need to send the same message to several clients.

Summary of solution

Crude form of group communication in which server sends a message to all clients, regardless of whether clients want the message or not. Client decides whether it wants to process the message or just discard the message.

Strengths of solution

Simple form of group communication.

Weaknesses of solution

Places an additional load on the client, because the client may not want the message.

Applicability

Distributed environments: client/server and distribution applications with multiple servers.

Related patterns

Similar to Subscription/Notification, except that it is not selective.

Reference

Chapter 10, Section 10.3.8.

Pattern name

Broker Forwarding.

Aliases

White Pages Broker Forwarding, Broker with Forwarding Design.

Context

Distributed systems.

Problem

Distributed application in which multiple clients communicate with multiple servers. Clients do not know locations of servers.

Summary of solution

Use broker. Servers register their services with broker. Client sends service request to broker. Broker forwards request to server. Server services request and sends reply to broker. Broker forwards reply to client.

Strengths of solution

Location transparency: Servers may relocate easily. Clients do not need to know locations of servers.

Weaknesses of solution

Additional overhead because broker is involved in all message communica-tion. Broker can become a bottleneck if there is a heavy load at the broker.

Applicability

Distributed environments: client/server and distribution applications with multiple servers.

Related patterns

Similar to Broker Handle; more secure, but performance is not as good.

Reference

Chapter 10, Section 10.3.6.

Pattern name

Broker Handle.

Aliases

White Pages Broker Handle, Broker with Handle-Driven Design.

Context

Distributed systems.

Problem

Distributed application in which multiple clients communicate with multi-ple servers. Clients do not know locations of servers.

Summary of solution

Use broker. Servers register their services with broker. Client sends service request to broker. Broker returns service handle to client. Client uses service handle to make request to server. Server services request and sends reply directly to client. Client can make multiple requests to server without broker involvement.

Strengths of solution

Location transparency: Servers may relocate easily. Clients do not need to know locations of servers.

Weaknesses of solution

Additional overhead because broker is involved in initial message communication. Broker can become a bottleneck if there is a heavy load at the broker. Client may keep outdated service handle instead of discarding.

Applicability

Distributed environments: client/server and distribution applications with multiple servers.

Related patterns

Similar to Broker Forwarding, but with better performance.

Reference

Chapter 10, Section 10.3.6.

Pattern name

Discovery.

Aliases

Yellow Pages Broker, Broker Trader.

Context

Distributed systems.

Problem

Distributed application in which multiple clients communicate with multiple servers. Client knows the type of service required but not the specific server.

Summary of solution

Use broker's discovery service. Servers register their services with broker. Client sends discovery service request to broker. Broker returns names of all services that match discovery service request. Client selects a service and uses broker handle or forwarding service to communicate with server.

Strengths of solution

Location transparency: Servers may relocate easily. Clients do not need to know specific service, only the service type.

Weaknesses of solution

Additional overhead because broker is involved in initial message com-munication. Broker can become a bottleneck if there is a heavy load at the broker.

Applicability

Distributed environments: client/server and distribution applications with multiple servers.

Related patterns

Other broker patterns (Broker Forwarding, Broker Handle).

Reference

Chapter 10, Section 10.3.7.

Pattern name

Negotiation.

Aliases

Agent-Based Negotiation, Multi-Agent Negotiation.

Context

Distributed multi-agent systems.

Problem

Client needs to negotiate with multiple servers to find best available service.

Summary of solution

Client agent acts on behalf of client and makes a proposal to server agent, who acts on behalf of server. Server agent attempts to satisfy client's pro-posal, which might involve communication with other servers. Having determined the available options, server agent then offers client agent one or more options that come closest to matching the original client agent proposal. Client agent may then request one of the options, propose further options, or reject the offer. If server agent can satisfy client agent request, client agent accepts the request; otherwise, it rejects the request.

Strengths of solution

Provides negotiation service to complement other services.

Weaknesses of solution

Negotiation may be lengthy and inconclusive.

Applicability

Distributed environments: client/server and distribution applications with multiple servers.

Related patterns

Often used in conjunction with broker patterns (Broker Forwarding, Broker Handle, Discovery).

Reference

Chapter 10, Section 10.3.9.

Pattern name

Subscription/Notification.

Aliases

Multicast.

Context

Distributed systems.

Problem

Distributed application with multiple clients and servers. Clients want to receive messages of a given type.

Summary of solution

Selective form of group communication. Clients subscribe to receive messages of a given type. When server receives message of this type, it notifies all clients who have subscribed to it.

Strengths of solution

Selective form of group communication. Widely used on the Internet and in World Wide Web applications.

Weaknesses of solution

If client subscribes to too many servers, it may unexpectedly receive a large number of messages.

Applicability

Distributed environments: client/server and distribution applications with multiple servers.

Related patterns

Similar to Broadcast, except that it is more selective.

Reference

Chapter 10, Section 10.3.8.

Pattern name

Synchronous Message Communication with Reply.

Aliases

Tightly Coupled Message Communication with Reply.

Context

Concurrent or distributed systems.

Problem

Concurrent or distributed application in which multiple clients communi-cate with a single server. Client needs to wait for reply from server.

Summary of solution

Use tightly coupled communication between client components and server component. Client sends message to server and waits for reply. Use message queue at server because there are many clients. Server services message FIFO. Server sends reply to client. Client is activated when it receives reply from server.

Strengths of solution

Good way for client to communicate with server when it needs a reply. Very common form of communication in client/server applications.

Weaknesses of solution

Client can be held up indefinitely if there is a heavy load at the server.

Applicability

Distributed environments: client/server and distribution applications with multiple servers.

Related patterns

Asynchronous Message Communication with Callback.

Reference

Chapter 10, Section 10.3.3.

Pattern name

Synchronous Message Communication without Reply.

Aliases

Tightly Coupled Message Communication without Reply.

Context

Concurrent or distributed systems.

Problem

Concurrent or distributed application in which concurrent components need to communicate with each other. Producer needs to wait for consumer to accept message. Producer does not want to get ahead of consumer. There is no queue between producer and consumer.

Summary of solution

Use tightly coupled communication between producer and consumer. Pro-ducer sends message to consumer and waits for consumer to accept message. Consumer receives message. Consumer is suspended if no message is available. Consumer accepts message, thereby releasing producer.

Strengths of solution

Good way for producer to communicate with consumer when it wants confirmation that consumer received the message and producer does not want to get ahead of consumer.

Weaknesses of solution

Producer can be held up indefinitely if consumer is busy doing something else.

Applicability

Distributed environments: client/server and distribution applications with multiple servers.

Related patterns

Consider Synchronous Message Communication with Reply as alternative pattern.

Reference

Chapter 10, Section 10.3.5.

Pattern name

Compound Transaction.

Aliases

Context

Distributed systems.

Problem

Client has a transaction requirement that can be broken down into smaller, separate flat transactions.

Summary of solution

Break down compound transaction into smaller atomic transactions, where each atomic transaction can be performed separately and rolled back separately.

Strengths of solution

Provides effective support for transactions that can be broken into two or more atomic transactions. Effective if a rollback or change is required to only one of the transactions.

Weaknesses of solution

More work is required to make sure that the individual atomic transactions are consistent with each other. More coordination is required if the whole compound transaction needs to be rolled back or modified.

Applicability

Transaction processing applications, distributed databases.

Related patterns

Two-Phase Commit Protocol, Long-Living Transaction.

Reference

Chapter 10, Section 10.4.2.

Pattern name

Long-Living Transaction.

Aliases

Context

Distributed systems.

Problem

Client has a long-living transaction requirement that has a human in the loop and that could take a long and possibly indefinite time to execute.

Summary of solution

Split a long-living transaction into two or more separate atomic transactions such that human decision making takes place between each successive pair of atomic transactions.

Strengths of solution

Provides effective support for long-living transactions that can be broken into two or more atomic transactions.

Weaknesses of solution

Situations may change because of long delay between successive atomic transactions that constitute the long-living transaction, resulting in an unsuccessful long-living transaction.

Applicability

Transaction processing applications, distributed databases.

Related patterns

Two-Phase Commit Protocol, Compound Transaction.

Reference

Chapter 10, Section 10.4.3.

Pattern name

Two-Phase Commit Protocol.

Aliases

Atomic Transaction.

Context

Distributed systems.

Problem

Clients generate transactions and send them to the server for processing. A transaction is atomic (i.e., indivisible). It consists of two or more operations that perform a single logical function, and it must be completed in its entirety or not at all.

Summary of solution

For atomic transactions, services are needed to begin, commit, or abort the transaction. The two-phase commit protocol is used to synchronize updates on different nodes in distributed applications. The result is that either the transaction is committed (in which case all updates succeed) or the transaction is aborted (in which case all updates fail).

Strengths of solution

Provides effective support for atomic transactions.

Weaknesses of solution

Effective only for short transactions; that is, there are no long delays between the two phases of the transaction.

Applicability

Transaction processing applications, distributed databases.

Related patterns

Compound Transaction, Long-Living Transaction.

Reference

Chapter 10, Section 10.4.1.