The simplest way to describe a pattern is that it provides a proven solution to a common problem individually documented in a consistent format and usually as part of a larger collection.
The notion of a pattern is already a fundamental part of everyday life. Without acknowledging it each time, we naturally use proven solutions to solve common problems each day. Patterns in the IT world that revolve around the design of automated systems are referred to as design patterns.
Design patterns are helpful because they:
- represent field-tested solutions to common design problems
- organize design intelligence into a standardized and easily “referencable” format
- are generally repeatable by most IT professionals involved with design
- can be used to ensure consistency in how systems are designed and built
- can become the basis for design standards
- are usually flexible and optional (and openly document the impacts of their application and even suggest alternative approaches)
- can be used as educational aids by documenting specific aspects of system design (regardless of whether they are applied)
- can sometimes be applied prior and subsequent to the implementation of a system
- can be supported via the application of other design patterns that are part of the same collection
- enrich the vocabulary of a given IT field because each pattern is given a meaningful name
Furthermore, because the solutions provided by design patterns are proven, their consistent application tends to naturally improve the quality of system designs.
Note that even though design patterns provide proven design solutions, their mere use cannot guarantee that design problems are always solved as required. Many factors weigh in to the ultimate success of using a design pattern, including constraints imposed by the implementation environment, competency of the practitioners, diverging business requirements, and so on. All of these represent aspects that affect the extent to which a pattern can be successfully applied.
What’s a Design Pattern Language?
A pattern language is a set of related patterns that act as building blocks in that they can be carried out in one or more pattern application sequences where each subsequent pattern builds upon the former. The notion of a pattern language originated in building architecture as did the term “pattern sequence” used in association with the order in which patterns can be carried out.
The SOA design pattern catalog, in its entirety, provides an open-ended, master pattern language for SOA. The extent to which different patterns are related can vary, but overall they share a common objective, and endless pattern sequences can be explored.
What’s a Compound Pattern?
A compound pattern is a coarse-grained pattern comprised of a set of finer-grained patterns. Singled out in this catalog are some of the more common and important combinations of the patterns, each of which is classified as a compound design pattern.
“Compound Pattern” vs.” Composite Pattern”
A “composite” is generally something that is comprised of interconnected parts. For example, you could legitimately refer to a service composition as a composite of services because the individual parts need to be designed into an aggregate in order to act as a whole. A “compound,” on the other hand, can simply be considered the result of combining a specific set of things together. A chemical compound consists of a combination of ingredients that result in something new when mixed together.
The patterns in this chapter are referred to as “compound patterns” because they document the effects of applying multiple patterns together. One of the most interesting parts of this exploration is that certain combinations of patterns result in design solutions that we are already familiar with, such as with the Enterprise Service Bus and Service Broker.
Compound Patterns and Pattern Relationships
Every pattern profile in the previous chapters includes a Relationships section that provides some insight into interpattern dependencies and how the application of one pattern can affect another.
Compound patterns are also about relationships, but in a different way. The patterns that comprise a compound pattern have a relationship with the compound pattern itself. Whether these patterns have dependencies with or impact each other is immaterial. When studying them as members of a compound pattern, we are only interested in the results of their combined application.
Joint Application vs. Coexistent Application
When we discuss the notion of combining patterns into compounds, it is important to clarify how patterns can be combined.
A compound pattern can represent a set of patterns that are applied together to a particular program or implementation in order to establish a specific set of design characteristics. This would be referred to as joint application.
Alternatively, the patterns that comprise a compound pattern can represent a set of related features provided by a particular program or environment. In this case, a coexistent application of patterns establishes a “solution environment” that may be realized by a combination of tools and technologies.
The notation used to express compound patterns comprised of patterns that are jointly applied versus those applied in a coexistent manner differs, as shown here:
Compound patterns comprised of patterns that are applied to coexist are expressed in a hierarchy, whereas those that are made up of patterns that are applied jointly are represented via a formula-style notation.