Appendix C. SOA Design Patterns Reference

This appendix provides profile tables for the patterns that are documented in SOA Design Patterns and SOA with REST: Principles, Patterns & Constraints for Building Enterprise Solutions with REST, both titles that are part of this book series.

Every profile table contains the following sections:

• Requirement – A requirement is a concise, single-sentence statement that presents the fundamental requirement addressed by the pattern in the form of a question. Every pattern description begins with this statement.

• Icon – Each pattern description is accompanied by an icon image that acts as a visual identifier. The icons are displayed together with the requirement statements in each pattern profile as well as on the inside book cover.

• Problem – The issue causing a problem and the effects of the problem. It is this problem for which the pattern is expected to provide a solution.

• Solution – This represents the design solution proposed by the pattern to solve the problem and fulfill the requirement.

• Application – This part is dedicated to describing how the pattern can be applied. It can include guidelines, implementation details, and sometimes even a suggested process.

• Impacts – This section highlights common consequences, costs, and requirements associated with the application of a pattern and may also provide alternatives that can be considered.

• Principles – References to related service-orientation principles.

• Architecture – References to related SOA architecture types (as described in SOA Design Patterns).

Note that these tables provide only summarized content from the original publication. All pattern profile tables in this book are also published online at SOAPatterns.org.

How can multi-purpose service logic be made effectively consumable and composable?

How can multi-purpose service logic be positioned as an effective enterprise resource?

How can agnostic, cross-entity composition logic be separated, reused, and governed independently?

How can a service and its consumers accommodate isolated failures and avoid unnecessarily locking resources?

How can a transaction with rollback capability be propagated across messaging-based services?

How can a service efficiently verify consumer credentials if the consumer and service do not trust each other or if the consumer requires access to multiple services?

How can service contracts be consistently understood and interpreted?

How can services be designed to avoid protocol bridging?

How can unnecessary infrastructure resource disparity be avoided?

How can services be designed to avoid data model transformation?

While Enterprise Service Bus provides a range of messaging-centric functions that help establish connectivity between different services and between services and resources they are required to encapsulate, it does not inherently enforce or advocate standardization.

Building upon the platform established by Enterprise Service Bus, this pattern positions entry points into the logic, data, and functions offered via the service bus environment as independently standardized service contracts.

Canonical Schema Bus is comprised of the co-existent application of Enterprise Service Bus, Decoupled Contract, Contract Centralization, and Canonical Schema.

How can service contracts within the same service inventory be versioned with minimal impact?

How can a service capability solve a problem that requires logic outside of the service boundary?

How can the same capability be used to help solve multiple problems?

How can a service contract be modified without impacting consumers?

How can composition runtime exceptions be consistently accommodated without requiring services to lock resources?

How can compositions be implemented to minimize loss of autonomy?

How can a service facilitate multi-consumer coupling requirements and abstraction concerns at the same time?

How can a service capability accommodate service consumers with different data format or representation requirements?

How can direct consumer-to-implementation coupling be avoided?

How can a service contract facilitate consumer programs with differing data exchange requirements?

How can redundant utility logic be avoided across domain service inventories?

How can data within a message be protected so that it is not disclosed to unintended recipients while in transit?

How can services interact with programs that communicate with different data formats?

How can services interoperate when using different data models for the same type of data?

How can a service verify that a message originates from a known sender and that the message has not been tampered with in transit?

How can a service be designed to minimize the chances of capability logic deconstruction?

How can a service express its capabilities independently of its implementation?

How can a service verify the credentials provided by a consumer?

How can a service preserve its functional context while also fulfilling special capability processing requirements?

How can services be delivered to maximize recomposition when enterprise-wide standardization is not possible?

How can a service inventory overcome the limitations of its canonical protocol while still remaining standardized?

How can consumers of a specific service endpoint adapt when the service endpoint changes or is removed?

How can services be delivered to maximize recomposition?

Enterprise Service Bus represents an environment designed to foster sophisticated interconnectivity between services. It establishes an intermediate layer of processing that can help overcome common problems associated with reliability, scalability, and communications disparity.

Enterprise Service Bus is fundamentally comprised of the co-existent application of Asynchronous Queuing, Intermediate Routing, and Service Broker, and can be further extended via Reliable Messaging, Policy Centralization, Rules Centralization, and Event-Driven Messaging.

How can agnostic business logic be separated, reused, and governed independently?

How can services expose the inherent relationships between business entities in order to support loosely-coupled composition?

How can service consumers be automatically notified of runtime service events?

How can a service prevent the disclosure of information about its internal implementation when an exception occurs?

Federation is an important concept in service-oriented computing. It represents the desired state of the external, consumer-facing perspective of a service inventory, as expressed by the collective contracts of all the inventory’s services.

The more federated and unified this collection of contracts (endpoints) is, the more easily and effectively the services can be repeatedly consumed and leveraged.

The joint application of Official Endpoint, Service Normalization, Canonical Protocol, Canonical Schema, and Canonical Expression results in Federated Endpoint Layer.

How can service logic interact with legacy systems that can only share information by exchanging files?

How can a large business problem be solved without having to build a standalone body of solution logic?

How can a service capability safely accept multiple copies of the same message to handle communication failure?

How can dynamic runtime factors affect the path of a message?

How can a service inventory be shielded from external access while still offering service capabilities to external consumers?

How can wrapper services with non-standard contracts be prevented from spreading indirect consumer-to-implementation coupling?

How can lightweight units of business logic be positioned as effective reusable enterprise resources?

How can the misuse of redundant service logic be avoided?

How can a service be protected from malformed or malicious input?

How can services be designed to process activity-specific data at runtime?

How can service metadata be centrally published and governed?

How can legacy logic fragmented and duplicated for different delivery channels be centrally consolidated?

How can single-purpose service logic be positioned as an effective enterprise resource?

As important as it is to clearly differentiate Logic Centralization from Contract Centralization, it is equally important to understand how these two fundamental patterns can and should be used together.

Applying these two patterns to the same service realizes the Official Endpoint compound pattern. The repeated application of Official Endpoint supports the goal of establishing a federated layer of service endpoints, which is why this compound pattern is also a part of Federated Endpoint Layer.

The joint application of Logic Centralization and Contract Centralization results in Official Endpoint.

An orchestration platform is dedicated to the effective maintenance and execution of parent business process logic. Modern-day orchestration environments are especially expected to support sophisticated and complex service composition logic that can result in long-running runtime activities.

Orchestration is fundamentally comprised of the co-existent application of Process Abstraction, State Repository, Process Centralization, and Compensating Service Transaction, and can be further extended via Atomic Service Transaction, Rules Centralization, and Data Model Transformation.

How can services be designed to optimize resource consumption while still remaining stateful?

How can unnecessary data validation be avoided?

How can policies be normalized and consistently enforced across multiple services?

How can non-agnostic process logic be separated and governed independently?

How can abstracted business process logic be centrally governed?

How can a service exchange data with consumers that use different communication protocols?

How can a service subject to decomposition continue to support consumers affected by the decomposition?

How can the reliability and availability of a service be increased?

How can services communicate reliably when implemented in an unreliable environment?

How can service consumers compose services without having to couple themselves to service-specific contracts?

How can business rules be abstracted and centrally governed?

How can service contracts be designed to avoid redundant data representation?

How can event-driven logic be separated and governed independently?

Although all of the Service Broker patterns are used only out of necessity, establishing an environment capable of handling the three most common transformation requirements can add a great deal of flexibility to a service-oriented architecture implementation, and also has the added bonus of being able to perform more than one transformation function at the same time.

Service Broker is comprised of the co-existent application of Data Model Transformation, Data Format Transformation, and Protocol Bridging.

How can a service communicate asynchronously with its consumers?

How can service autonomy be preserved when services require access to shared data sources?

How can the granularity of a service be increased subsequent to its implementation?

How can solution logic be made available as a resource of the enterprise?

How can a service accommodate changes to its contract or implementation while allowing the core service logic to evolve independently?

How can deferred service state data be scaled and kept fault-tolerant?

How can consumers contact and interact with service instances without the need for proprietary processing logic?

How can the services in an inventory be organized based on functional commonality?

How can services interoperate without forming persistent, tightly coupled connections?

How can a service inventory avoid redundant service logic?

How can services that run in a private network be made available to external consumers without exposing internal resources?

How can a service be evolved without impacting existing consumers?

How can a service remain stateless while participating in stateful interactions?

How can service state data be persisted for extended periods without consuming service runtime resources?

How can service state data be persisted and managed without consuming service runtime resources?

How can the scheduled expiry of a service contract be communicated to consumer programs?

This compound pattern is simply comprised of the combined application of the three service layer patterns. Three-Layer Inventory exists because the combined application of these three patterns results in common layers of abstraction that have been proven to complement and support each other by establishing services with flexible variations of agnostic and non-agnostic functional contexts.

The joint application of Utility Abstraction, Entity Abstraction, and Process Abstraction results in Three-Layer Inventory.

How can a consumer be prevented from circumventing a service and directly accessing its resources?

How can a service-oriented solution provide a consistent, interactive user experience?

Uniform Contract is a compound pattern comprised of the combined application of Reusable Contract, Lightweight Endpoint, and Entity Linking.

Uniform Contract is considered a specialized variation of Reusable Contract that is applied to all services within a given boundary (usually a service inventory). This compound pattern further requires that service functions are broken down to related individual resources, as per Lightweight Endpoint. It further enables links from one resource to another. Links are followed by service consumers to invoke the capabilities of each resource without foreknowledge of the service that exposes them, as per Entity Linking.

How can common non-business centric logic be separated, reused, and independently governed?

How can service contracts be designed to more easily adapt to validation logic changes?

How can consumers be made aware of service contract version information?