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.

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.