Working With SOA: Pattern Relationships

Today's Best Tech Deals

Picked by PCWorld's Editors

Top Deals On Great Products

Picked by Techconnect's Editors

Design patterns have been part of the IT world for many years. An entire patterns community has even emerged to foster the evolution of new patterns and to establish guidelines around how patterns should be documented and related.

Yes, that's right, patterns relate to other patterns. To work with design patterns, you need to understand these relationships. These relationships are especially important with respect to SOA because the scope of an SOA implementation tends to be larger than traditional applications. Therefore, SOA design patterns tend have a broader reach and, as a result, a greater impact.

Let's start with the basics and get back to how one pattern can relate to another. There are many different types of relationships, but two of the most important ones pertain to dependency and support.

In order to apply one pattern, you may be required to apply (or have already applied) another. That's a pretty straightforward dependency relationship, but it's still helpful to understand why the dependency exists. For example, in the SOA design pattern catalog there is a pattern called Logic Centralization. It essentially establishes a rule whereby, for any given reusable body of solution logic, only one official service can exist. This reduces the risk of redundancy and maximizes reuse potential among services within a given domain. It also forms the basis of Agnostic Context, a design pattern that is applied to an individual service in order to give it a multi-purpose functional scope (because it is "agnostic" to any logic that is limited to a single-purpose).

Agnostic Context and Logic Centralization share the common goal of fostering reuse within services. While Logic Centralization establishes distinct units of logic, Agnostic Context ensures that any units with reuse potential will be limited to multi-purpose logic only. This way, they become purely reusable services.

In short, you could make a case that Agnostic Context is dependent on Logic Centralization because without centralizing distinct bodies of logic, it would be difficult to segment them into agnostic units. It wouldn't make much sense to apply Agnostic Context until after the Logic Centralization pattern has been applied.

The other type of relationship we mentioned is where the application of one pattern supports another. So unlike the dependency relationship, there is no direct reliance in this case, which means that these types of relationships are easy to miss (as are their benefits). A supportive relationship simply means that one pattern helps realize the goals or ultimate purpose of another.

Let's revisit our Logic Centralization example. The objective of this pattern is to foster reuse within services. However, the history of application integration has taught us that achieving connectivity via multiple point-to-point integration channels leads to a fragile architecture and, ultimately, an enterprise that is burdensome to evolve, especially in the face of business change.

What does this have to do with Logic Centralization? Well, imagine a service that encapsulates several databases and a legacy system. Even if we centralize the logic represented by the service, we are still not doing anything to prevent all of these underlying resources from being accessed directly via traditional-style integration channels. This is where Contract Centralization enters the picture.

The Contract Centralization design pattern limits external access to a service to its published technical contract (or interface or API), which means that the underlying resources cannot be touched by outside programs or applications (which we can refer to as service consumers), because the sole point of entry is the service contract.

This simple limitation increases service reusability in the long run. Over time, the service can be effectively evolved in response to business change by extending or even replacing its underlying resources while minimizing the impact of these improvements upon external service consumers (because they are not directly connected to the resources due to Contract Centralization). The greater the service's longevity, the greater its long term reuse potential.

1 2 Page 1
Page 1 of 2
Shop Tech Products at Amazon