Blog: James Taylor

« Decision Services - A Pattern for SOA | Main | First Look - SeeWhy »

Introducing SOA Design Patterns

Thomas was back on talking about the catalog of 85 SOA Design Patterns that he is publishing this year - SOA Design Patterns. Design patterns are a field-testing or proven design solution to a common design problem. Some are compound, most are atomic. These SOA Patterns overcome common design challenges for the successful adoption of SOA and range from high-level ones like the boundary of services for an enterprise to very low level ones about contracts etc. The patterns are classified as service inventory, service design, service composition and some compound design patterns. The service design patterns, as a set, represent almost a basic approach or methodology to service design based on the core ideas of separation of concerns.

The patterns have relationships with the design principles and architecture types (discussed here) as well as with each other. One he particularly wanted to highlight was “Domain Inventory”. This pattern addresses the issues that arise with trying to inventory services enterprise-wide such as global data models, organizational issues and governance. The pattern involves establishing domains within the enterprise, typically related to lines of business, and then creating a service inventory within that domain. This approach reduces organizational issues but will require the use of some integration patterns to overcome the differences that will result from domain-specific inventories. While not ideal it does address a big issue without devolving down into very siloed initiatives. Standardizing and governing these domain by domain can be very effective in organizations that struggle with enterprise initiatives.

He also talked about process layer services (non-reusable logic), entity services(based around a business entity) and utility services(technical functionality with no business model). Clearly decision services are a form of entity service (Is this claim valid for instance) while the technical aspects of, say, using a BRMS might be utility services.

He spent some time discussing the set of patterns related to Enterprise Service Buses. This compound pattern consists of a number of patterns identifying the capabilities and features of an ESB such as broker, messaging, event-driven messaging, policy centralization etc. A similar set of patterns relate to Orchestration and this set includes Rules Centralization (highly compatible with Decision Services about which I presented and that Thomas plugged very nicely).

The site for the book also has candidate patterns that did not make the book. These mostly did not have enough real-world proof points (yet).

ShareThis

Share: