Template for Communication-Protocol Patterns

Jump to: navigation, search

To document the patterns in CommDP, we have developed a template, loosely based on the way Gamma, Helm, Johnson and Vlissides documented their patterns [1], referred to here as the GoF template. The main goal is to keep the documentation as simple as possible, while still capturing the details of the pattern. Following are the elements of CommDP pattern template: Name, Intent, Description: (Problem, Context, Solution), Consequences, Known uses, Aliases and Related Patterns (Related work), Examples of Application, References.

Name and Overview

The name should be descriptive, precise, and concise. The name will become part of the vocabulary for the pattern language. As with the GoF template, the name uniquely identifies the pattern, it is important that it captures the essence of the pattern, and distinguishes it from other patterns.


The intent is an abstract for the pattern. It summarizes the problem, the context, and the solutions, particularly in terms of reliability, synchronicity, longevity, and adaptability for scalable distribution.


The description should explain the intent of the pattern in terms of general explanation of the problem. It should highlight the key contributions of the solution, given the specified context, and explain what part of the pattern can be varied or not.

The description consists of three subsections that explain the problem, context, and solution.


The problem subsection relates closely to the Motivation part in the GoF template. This subsection needs to characterize the nature of reoccurring communication-protocol design requirements. It is important to remember that this pattern language deal with communication protocol design, not software structure or software component design. The problem description needs to focus on requirements or issues directly related to message communications.

This subsection should highlight the problem’s needs for reliable communications, synchronization, long-running conversations, or scalable distribution. There may be other needs of a communication problem.


The context subsection is like the Applicability in the GoF template, capturing information when the pattern may or may not be applicable and assumptions about distributed systems in which the communications will take place. The context identifies constraints or assumptions, these assumptions are not directly part of the problem but may impact the choice of a solution.


The solution is analogous to the Structure in the GoF template. It focuses on describing protocol design ideas and how they can be adapted.

For ACPs, the solution is a partial protocol design. It specifies key aspects of a protocol definition that represent a proven solution to the communication problem in the specified context, while leaving other part of the definition open. In general, the solution will specify:

  1. Participants (process roles, at the least the initiator and the responder)
  2. Messages
  3. Scenarios (Possible message sequences)
    1. Natural Language representation
    2. UML Sequence Diagram
  4. Constraints on participants’ behavior, if any
  5. Variations, if any

The name, intent and description should be sufficient to give the reader a high-level understanding of the pattern.


the consequences are important part of CommDP pattern definitions because developers will use them to determine if the pattern is a good fit for a particular situation. The consequences are identified under four distributed systems characteristics:

  1. Degree of Reliability - Reliability can be characterized on spectrum from unreliable to total reliability
  2. Degree of Synchronicity - Exists to the degree a process knows something about the state of another process
  3. Degree of Longevity - Exists to the degree of the presence of long-running processes
  4. Degree of Adaptability for Scalable Distribution - The tasks of the communication protocol interaction are shared among the participants.

Developers will identify whether the pattern is a good fit or not for a particular situation conceived under the aforesaid qualities.

Known uses

This part references known instances of the pattern in production systems. i.e. protocols or systems that implement the specific pattern.

Aliases and Related Work


This section lists any aliases that exist for the pattern. It combines two elements of different pattern languages by similar names, they may or may not exist.

Related Work

This section contains books, pattern languages, or articles where the pattern has been used to solve specific reoccurring problems by different authors. i.e. Relevant to the aliases or related patterns.

Examples of Application

This section shows actual examples of how the pattern is being or can be applied or adapted. It describes the example and a scenario.


This section contains a bibliography for the citations made elsewhere in the pattern definition.

-> Return to COMMDP <-


  1. E. Gamma, R. Helm, R. Johnson, J. Vlissides, and G. Booch, Design Patterns: Elements of Reusable Object-Oriented Software, 1 edition. Addison-Wesley Professional, 1994.