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 are already quite common, such as with Enterprise Service Bus (704) and Service Broker (707).

Every pattern profile in the previous chapters included a Relationships section that provided some insight into inter-pattern 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.

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.

The compound patterns with patterns that are jointly applied are:

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.

Compound patterns comprised of patterns that coexist to establish such an environment are:

The notation used to express compound patterns comprised of patterns that are jointly applied versus those applied in a coexistent manner differs, as shown in Figure 22.1.

Figure 22.1. 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.

Even though this chapter classifies a set of patterns as “compound patterns,” it is important to note that just about any pattern can turn out to be a compound pattern. Every one of the other patterns described in this book can be decomposed into a set of more granular patterns. Their joint or coexistent combination then results in the original pattern, thereby also making it a compound pattern.

For example, Chapter 18 establishes Asynchronous Queuing (582) and Intermediate Routing (549) as providing fundamental, messaging-related solutions. In the upcoming ESB Architecture for SOA book, a set of more granular queuing and routing design patterns are described that can be considered as collectively representing Asynchronous Queuing (582) and Intermediate Routing (549) as compound patterns.

The reason this perspective is important is because whether or not a pattern is labeled as being a compound pattern is always relative. It is just a matter of the granularity at which the pattern is documented in relation to other patterns in the same catalog.

As a result, the compound patterns in this chapter are only classified as such because of the granularity at which the rest of the patterns are defined in this book. In a different publication or context, these patterns may be classified differently.

By Thomas Erl, Brian Loesgen

An orchestration platform is dedicated to the effective maintenance and execution of parent business process logic. Modern-day orchestration environments are especially expected to support sophisticated and complex service composition logic that can result in long-running runtime activities.

Figure 22.2. The base patterns that comprise Orchestration.

The Orchestration compound pattern is comprised of the following design patterns:

Figure 22.3 illustrates how the combination of the first three of these patterns establishes an orchestration environment from an implementation perspective, and Figure 22.4 highlights how this base platform is commonly extended with features that correspond to design solutions provided by other patterns covered in this book.

Figure 22.3. Non-agnostic business process logic is abstracted and then physically centralized into an environment that provides a native state management repository. The logic is executed and managed via an orchestration engine, which may support industry standards, such as WS-BPEL.

Figure 22.4. The extended Orchestration compound pattern shows how solutions provided by other design patterns expand upon the core model.

By Thomas Erl, Mark Little, Thomas Rischbeck, Arnaud Simon

An enterprise service bus represents an environment designed to foster sophisticated inter-connectivity between services. It establishes an intermediate layer of processing that can help overcome common problems associated with reliability, scalability, and communications disparity.

Figure 22.5. The base patterns that comprise Enterprise Service Bus.

Enterprise Service Bus is considered a compound pattern comprised of the following core patterns that coexist to provide a base set of interoperability-enablement features:

How this set of patterns can be combined to establish a middleware-based messaging mechanism is illustrated in Figure 22.6. The expanded pattern hierarchy shown in Figure 22.7 reveals additional patterns that are common, optional extensions of Enterprise Service Bus.

Figure 22.6. A message undergoing various processing steps carried out by an ESB in order to successfully transform and deliver the message contents to their destination. Note that this scenario depicts all three solutions working in tandem to process a single message. Other message transmissions may not require all of this functionality. It is simply the coexistence of specific patterns that constitutes an ESB.

Figure 22.7. The expanded Enterprise Service Bus pattern hierarchy showing the core patterns (top left) and patterns that commonly extend the base ESB (top right), plus the patterns that comprise Service Broker (707) (bottom).

By Mark Little, Thomas Rischbeck, Arnaud Simon

Broker functionality has been a common part of middleware platforms, providing multi-faceted runtime conversion features that enable integration between disparate systems.

Figure 22.8. The patterns that comprise Service Broker.

The Service Broker compound pattern is comprised of Data Model Transformation (671), Data Format Transformation (681), and Protocol Bridging (687). Although all of these patterns are used only out of necessity, establishing an environment capable of handling the three most common transformation requirements can add a great deal of flexibility to a service-oriented architecture implementation, and also has the added bonus of being able to perform more than one transformation function at the same time.

Broker-related features are a fundamental part of ESB platforms, which is why this pattern exists as part of Enterprise Service Bus (704), as depicted in Figure 22.9.

Figure 22.9. The Service Broker pattern hierarchy itself is nested within the hierarchy of Enterprise Service Bus (704).

By Clemens Utschig-Utschig, Berthold Maier, Bernd Trops, Hajo Normann, Torsten Winterberg, Thomas Erl

While Enterprise Service Bus (704) provides a range of messaging-centric functions that help establish connectivity between different services and between services and resources they are required to encapsulate, it does not inherently enforce or advocate standardization. In fact, it can be argued that the native broker functions provided by some ESB platforms can discourage standardization by making it “too convenient” to integrate disparate services.

Figure 22.10. The patterns that comprise Canonical Schema Bus.

Building upon the platform established by Enterprise Service Bus (704), this pattern adds Decoupled Contract (401) and Contract Centralization (409) together with Canonical Schema (158) to position entry points into the logic, data, and functions offered via the service bus environment as independently standardized service contracts (Figure 22.11).

Figure 22.11. This pattern requires that access to ESB encapsulated functions and resources be limited to standardized service contracts.

Canonical Schema Bus restricts entry to points to centralized and canonical service contracts and further limits the use of Service Broker (707) related patterns to intra-service transformation requirements. This places the onus of having to conform to standardized contracts upon any service or program that needs to consume them. The ultimate goal of this pattern is to promote and enforce contract-level standardization throughout a service inventory.

As important as it is to clearly differentiate Logic Centralization (136) from Contract Centralization (409), it is equally important to understand how these two fundamental patterns can and should be used together:

Figure 22.12. The patterns that comprise Official Endpoint.

Applying these two patterns to the same service realizes the Official Endpoint compound pattern (Figure 22.13). The repeated application of Official Endpoint supports the goal of establishing a federated layer of service endpoints, which is why this compound pattern is also a part of Federated Endpoint Layer (713).

Figure 22.13. As per Logic Centralization (136), a consumer program (A) requiring invoice functionality can only access the Invoice service, which is the designated service for this logic. As per Contract Centralization (409), consumer programs (B) can only access the Invoice service via its centralized contract. The combination of these patterns establishes the Invoice service as an “official” endpoint.

Federation, within the context of this compound pattern (and also as it relates to the Increased Federation strategic goal explained in Chapter 4), represents a state where different services combine to form a united front (Figure 22.15), while allowing their respective, underlying environments to continue to be governed independently (Figure 22.16).

Figure 22.14. The patterns that comprise Federated Endpoint Layer.

Figure 22.15. The abstracted view of a federated service inventory, as represented by a series of standardized service contracts.

Figure 22.16. If you were to tip Figure 22.13 over on its side, you might see how, though providing a united front, the federated endpoints each abstract different service implementations.

Federation is an important concept in service-oriented computing. It represents the desired state of the external, consumer-facing perspective of a service inventory, as expressed by the collective contracts of all the inventory’s services. The more federated and unified this collection of contracts (endpoints) is, the more easily and effectively the services can be repeatedly consumed and leveraged.

The various patterns that make up this compound pattern are applied as follows:

This compound pattern is simply comprised of the combined application of the following three fundamental inventory design patterns associated with Service Layers (143).

Figure 22.17. Each service layer represents a type of service based on one of three common service models.

The Three-Layer Inventory exists because the combined application of these three patterns is recommended for the following reasons:

Even if an organization has unique or unconventional business requirements, it is advisable to begin a service inventory blueprint definition effort with this pattern. Once the service modeling process is underway, it will become evident as to whether defined services fit well into the three service models that establish these layers.

Figure 22.18 shows the common view of a service inventory partitioned via these three layers.

Figure 22.18. Each service layer represents a type of service based on one of three common service models.