Working With SOA: Pattern Relationships

An Environment that Promotes Agility

So while Logic Centralization does not need Contract Centralization, it certainly benefits from its application. In fact, when these two fundamental patterns are consistently applied to an inventory (collection) of services, they establish an environment highly capable of promoting business agility. Because services can be repeatedly reused, we are required to build less redundant logic with each new solution (reducing the time and cost of solution delivery). And because services can only be accessed via their contracts, we avoid forming integration channels that will be difficult to change. As a result, we end up with services that can be effectively reused and evolved in tandem with the business.

Of course, there's much more to realizing the strategic goals of SOA than just applying these two patterns. However, it's the foundation established by SOA design patterns such as these that is critical to achieving successful SOA. Even the most powerful, scalable, and sophisticated infrastructure can't help you turn poorly designed services into high-value IT assets with repeatable return in an ever-changing business climate. Services need to be designed from the ground up to expect and adapt to change, which is what service-orientation is all about.

Before we conclude, let's briefly introduce the concepts of a pattern application sequence and a pattern language. We just explained how Contract Centralization supports Logic Centralization, but when designing services, which pattern do you apply first? Although there is no absolute rule, you might have a preference. For example, when modeling a collection of services at the same time, it would probably make sense to begin with Logic Centralization in order to properly partition services into distinct units of logic. Then you can apply Contract Centralization so that each of these units (services) is given a technical contract as its official entry point.

What we've just described is a pattern application sequence consisting of two patterns applied in a specific order. A pattern catalog is ideally structured so that you can come up with many creative application sequences depending on your requirements, preferences, and constraints. Some catalogs even provide recommended pattern sequences where as much as individual patterns are considered proven design solutions, the application sequences themselves are also considered proven.

The freedom to combine patterns into endless sequences is what makes a pattern catalog more than just a documentation of design patterns; it's what makes it a "pattern language." As with any written language, you have words that can be strung together into sentences that are further combined into paragraphs, essays, and so on. Think of a pattern language in the same way. When you take a pen to paper you will, depending on your skills, create a great or not-so-great work of literature. Similarly, the key to working with a language of patterns also lies in your knowledge and insight of the patterns themselves. A big part of this insight can be gained by understanding how patterns relate.