SOA Design Patterns: A Gentle Introduction

If you’ve been around the IT world, chances are that you’ve heard of or even worked with design patterns. There’s nothing too mysterious about them; a design pattern is simply a proven design solution that solves a common problem. It’s referred to as a pattern because it provides a solution that we expect to be able to apply repeatedly.

For example, consider a hammer. It’s a tool designed to solve a specific problem. Furthermore, it’s a proven design that has been field tested and validated for decades. Of course, it’s so commonplace now that we take the hammer for granted. But imagine if there were design solutions as useful and successful as the hammer that we could apply to the design of our IT systems.

For architects and developers building new solutions (especially when working with modern technologies), designs patterns can be lifesavers. Each can provide a pearl of wisdom that not only helps solve problems as they occur, but can help you design your systems to avoid problems that are likely to occur in the future. As a result, design patterns can save time and money and can further increase the overall robustness and effectiveness of a given system. And, as an added bonus, you don’t need to hire expensive consultants to get them; you just need to buy a book and invest some study time.

Design patterns have been widely adopted over the years and each major programming or computing discipline has assembled its own “pattern catalog.” The best patterns are those that are documented after a technology platform has matured to a reasonable extent and many pioneering efforts have gone through various cycles of trial and error to determine what techniques and approaches do truly work better than others.

The fact that a design pattern catalog for SOA has now emerged is testament to the level of maturity that SOA has attained. Since SOA first emerged a few years ago, many projects have come and gone, and collections of best practices, pitfalls, and methodologies have been produced and proposed by various practitioners and vendors. SOA design patterns essentially leverage all of this information and synthesize it into a set of design solutions that are consistently documented in a formal catalog.

A great example is associated with determining the appropriate scope of a service-oriented architecture. Many past projects attempted to adopt SOA on an enterprise-wide basis, viewing SOA as an all-or-nothing proposition. In some environments, this can succeed, especially when there’s strong support from management. However, more often than not, the odds are against you. Cultural and organizational issues have been difficult and sometimes even impossible to overcome when attempting a wholesale transition toward SOA. Hence we have a very important problem that needs to be solved.

The Domain Inventory design pattern (REF-1) proposes a solution whereby the IT enterprise is sub-divided into logical domains. We then limit the scope of our SOA project to one of these domains, which is another way of saying that we simply avoid biting off more than we can chew. Because we have the freedom to determine the scope and size of these domains, we can tune any given SOA adoption initiative to an order of magnitude that we are comfortable with. This makes the delivery of all services for that project manageable and allows us to work out the cultural and organizational issues ahead of time, as they pertain only to that limited scope.

Domain Inventory has been an extremely successful pattern in the SOA world. It has not only changed IT’s perception of what constitutes SOA, it has essentially empowered numerous organizations to proceed with adoption without following a “big bang” approach that brings with it massive amounts of analysis, investment, and unprecedented (and perhaps unattainable) levels of inter-departmental cooperation.

The term “inventory” in this pattern name refers to a collection of physical services that are subjected to the same design and technology standards. The objective is for services within a service inventory to be intrinsically interoperable so that they can be assembled into various aggregates (called “service compositions”) without each such assembly turning into an expensive integration project. In fact, successful applications of this pattern together with other supporting patterns, makes the notion of integration actually fade. No need to integrate something that is already compatible and interoperable.

Another benefit of Domain Inventory is that it allows IT to phase SOA into an enterprise in a controlled manner. Because you take on the overall adoption on a domain-by-domain basis, you can take things one step at a time and build on previous experiences. Over time you can establish a collection of service inventories, each representing their own domain, and each delivered successfully because the overall scope of delivery was limited to be manageable.

It all sounds exceptionally promising, and it certainly can be. However, as with anything in life, there are usually trade-offs. Just about any design pattern comes with its own set of impacts. These impacts are commonly associated with time, money, and disruption. Therefore, it is important that the overall consequences of proceeding with a design pattern be carefully considered in advance. This consideration is important not just because of immediate impacts, but because of the long-term commitment you may find yourself making to the use of a pattern that has been successfully applied.

For example, a pattern such as Domain Inventory will be used repeatedly within the same IT environment (once for each domain). In fact, it can actually establish the foundation of your overall SOA strategy. Therefore, you better be pretty sure it’s what you want for the long-term. One of its primary impacts is that it does introduce the need for transformation technologies. Because domain service inventories represent collections of services that are independently owned and governed, they will also tend to be independently standardized. This generally restricts the benefits of native compatibility and interoperability to the domain. When you need to begin connecting services across domains, you now have to overcome their disparity by incorporating brokers.

This may seem reminiscent of the EAI era where integration was the default solution to business change; however, this is actually not the case. As long as the scope of the domains are meaningful, this pattern can help any organization take a big step toward service-orientation as long as you consider the long-term impacts and plan for them.

Of course, we’ve just scratched the surface of SOA design patterns. Domain Inventory is one of nearly a hundred patterns that are being published this fall after three years in development and with the support and participation of hundreds of SOA professionals.

In Part 2 of this article series we’ll take a closer look at some more SOA design patterns and we’ll discuss how they can be applied together as part of pattern application sequences.