Increased Intrinsic Interoperability
Increased Vendor Diversification Options
Increased Business and Technology Alignment
All of the design patterns in this book provide design solutions in support of service-orientation. As first explained in Chapter 4, the end-result of successfully realizing service-orientation is a target state defined by a specific set of strategic goals. This chapter revisits these goals and highlights some of the key patterns that relate to their attainment.
Note
The patterns mentioned in each of the upcoming sections are not the only patterns that are recommended or required to achieve a given strategic goal. These sections simply provide examples in order to demonstrate how SOA design patterns can be mapped to the strategic goals of service-oriented computing. The unique requirements, environments, and constraints faced by individual IT enterprises will almost always warrant the use of additional patterns and practices. Furthermore, it’s important to understand that these goals are inter-related. The attainment of one supports the attainment of others.
As previously explained, federation can be classified as the unification of disparate environments while continuing to allow them to be independently governed. Within the context of service-orientation, this results in an emphasis on establishing endpoints as standardized, official “points of contact” for services (Figure 23.1).
Service-orientation is focused on service contract content and the positioning of the service contract as an architectural element. This eventually results in a federated environment that needs to be attainable and maintainable by the underlying architecture. As a result, every type of service-oriented technology architecture tends to be contract-centric.
Examples of related patterns:
• Both Enterprise Inventory (116) and Domain Inventory (123) result in concrete architectural boundaries within which contract-related design standards are applied. Therefore, these two patterns establish the scope in which federation is typically pursued.
• Logic Centralization (136), Contract Centralization (409), and, as a result, Official Endpoint (711) directly support this goal by producing clear design standards that ensure that each service that is part of a federated inventory has a well-defined functional scope and can only be accessed via its standardized contract. This is further aided by Service Normalization (131), which ensures that service boundaries do not overlap.
• It is important to single out Decoupled Contract (401) as a contributor as well, as it is the physical separation of contract from implementation which helps preserve federation over time (in relation to the considerations raised by the Service Abstraction design principle).
• Service Layers (143) and its three variations tie into federation by assisting with the organization and classification of services within a federated service inventory.
• The inherent standardization that is required by contracts for a collection of services to establish a united endpoint layer is supported by patterns such as Canonical Schema (158), Canonical Protocol (150), and Canonical Expression (275). Even Canonical Versioning (286) plays a factor, especially when attempting to maintain a federated state as services continue to evolve over time.
• Of course, Federated Endpoint Layer (713) is directly based on the target state advocated by this goal, but another compound pattern that can be applied more so from an infrastructure perspective in pursuit of maintaining federation is Canonical Schema Bus (709).
In many enterprises, the extent of attainable federation can be maximized by applying these patterns to services built as Web services, primarily due to the native realization of Decoupled Contract (401) that Web service implementations naturally provide.
The goal of increasing native interoperability represents a core state where units of service-oriented solution logic (services) are inherently compatible and therefore able to exchange data without the need to be separately integrated (Figure 23.2).
Figure 23.2. Message data travels throughout services to enable the automation of a composition. The smoother this communication, the more efficient the composition logic executes. Intrinsic interoperability strives to establish an environment in which data can be passed without constraint among numerous variations of aggregated services.
This intrinsic level of inter-connectivity relies on the federated contract-related requirements already described and can place further demands on the underlying technology architecture.
Examples of related patterns:
• On the most fundamental level, Capability Recomposition (526) establishes the baseline expectation that different services can incorporate into different compositions, thereby requiring the target state envisioned by this goal.
• From a practical perspective, contract design standards-centric patterns, such as Canonical Schema (158), Canonical Protocol (150), and Schema Centralization (200) each directly enable and enhance interoperability. Canonical Schema Bus (709) further assists this goal by enforcing contract design standards in ESB-centric environments.
• The preceding patterns and others that relate to the exchange of information between services benefit from the successful application of patterns that help position the technical service contract as an independent, yet standardized part of the service architecture. Decoupled Contract (401) and Contract Centralization (409) relate to this, as do more specialized patterns like Contract Denormalization (414) which can enhance interoperability by catering to different types of service consumers.
• Of course, Enterprise Inventory (116) and Domain Inventory (123) establish the extent to which services are expected to be natively interoperable, but Cross-Domain Utility Layer (267) is also worth mentioning as a means of improving baseline interoperability across domain boundaries.
These are just examples of patterns that help foster baseline interoperability. Because this goal is so foundational to service-orientation, in some way or another, the majority of patterns in this book support interoperability between services.
It is not a goal of service-orientation to increase the vendor diversity within enterprises. Instead, the objective is to provide a constant option for diversification so that when existing products and technologies are no longer adequate, they can be extended or even replaced with whatever else the marketplace has to offer without disrupting the established, federated service layer (Figure 23.3).
The key is to allow this option to exist without having to replace a technology architecture when vendor diversification is required. This essentially imposes the requirement that architecture models remain as vendor-neutral as possible.
Examples of related patterns:
• A key design-time factor in support of this goal is how a service architecture is structured internally. For example, Service Façade (333) can help establish a healthy decoupling of various, vendor-specific resources from the core service logic so as to allow those resources to be more easily changed and replaced, as per Service Refactoring (484). On the other hand, Service Agent (543) can lead to less desirable dependencies on vendor platforms when over-applied.
• Sometimes the best solution is to wrap proprietary technology resources into non-business-centric services so as to maintain an extent of decoupling of business logic and vendor technology. For this purpose, Utility Abstraction (168) and Legacy Wrapper (441) can be applied.
• How a service relates to its underlying resources is generally determined by how it interfaces with them. Legacy-related patterns, such as File Gateway (457), can be useful in addition to the intra-service application of the transformation patterns Data Model Transformation (671), Data Format Transformation (681), and Protocol Bridging (687).
• Several patterns are simply applied via the purchase and deployment of vendor products. Examples of this include State Repository (242), Metadata Centralization (280), Service Data Replication (350), and Partial State Deferral (356).
• Patterns associated with middleware platforms, such as those established by Enterprise Service Bus (704), Orchestration (701), and Service Grid (254), can inhibit the attainment of this goal due to the fact that such platforms can encompass large portions of the infrastructure that underlie a service inventory architecture, which can lead to the architecture as a whole becoming overly dependent on supporting vendor technology.
• The preceding point ties into more specialized patterns, such as Process Centralization (193), Policy Centralization (207), Intermediate Routing (549), Asynchronous Queuing (582), Reliable Messaging (592), Event-Driven Messaging (599), Atomic Service Transaction (623), Compensating Service Transaction (631), as well as security-related patterns including Data Confidentiality (641), Data Origin Authentication (649), Direct Authentication (656), and Brokered Authentication (661). However, it is worth noting that all of these patterns can be applied with the support of industry standards which can naturally increase the freedom to diversify vendor technologies.
• One pattern that can be considered in opposition with this goal is Canonical Resources (237). It advocates keeping underlying service implementation technologies the same in order to reduce diversity. However, the objectives of this pattern are expected to yield to the need to diversify vendor technology when having to maintain business alignment or when attempting to maximize business requirements fulfillment.
Several additional patterns can also be applied via (and are even inspired by) industry technology standards.
The motivation behind building a technology environment that is synchronized with the current state of a business but also designed to continuously adapt to how the business changes over time is to avoid having to reach a decision point where we have to choose between living with an outdated automation environment and replacing it altogether.
Service-orientation fosters design characteristics that enable service-oriented solutions to be extended, reconfigured, or replaced using already available resources (services) without disrupting the already established layer of federated service endpoints (Figure 23.4).
Examples of related patterns:
• In their earliest stages, services can be aligned with business intelligence as a result of service modeling processes in which foundational patterns, such as Functional Decomposition (300), Service Encapsulation (305), Agnostic Context (312), Non-Agnostic Context (319), and Agnostic Capability (324) first surface to help define the functional contexts and boundaries of services.
• The definition of services in relation to business logic is further supported by the application Service Layers (143), in particular Process Abstraction (182) and Entity Abstraction (175).
• Canonical Schema (158) and Schema Centralization (200) can also be considered supporting patterns in that they allow for the definition of independent data models for business documents that are then used and shared by business-centric services.
• From a broader and more strategic perspective, however, Capability Recomposition (526) represents the key to maintaining alignment with the business in that it is through the ability to repeatedly compose services into new aggregates that changing or new business requirements can be continually fulfilled in an effective manner.
The majority of services for a given inventory are expected to be agnostic, which means they are delivered as IT assets capable of providing repeated value to the organization over time. This leads to cost savings and a measurable return on the initial investment that was required to deliver them (Figure 23.5).
However, the extent to which each service can realize its ROI potential is directly related to its supporting service, composition, and inventory architectures.
Examples of related patterns:
• On a basic level, this goal is fundamentally supported when agnostic services and their capabilities are first defined via Agnostic Context (312) and Agnostic Capability (324).
• Agnostic services are then further formalized via the application of Entity Abstraction (175) and Utility Abstraction (168), but it’s important to also acknowledge Process Abstraction (182) as means by which non-agnostic logic can be separated in support of agnostic service definition.
• Both Logic Centralization (136) and Service Normalization (131) position a body of agnostic service logic as a reusable resource while reducing the chances of overlapping logic from being introduced into the service inventory.
• Numerous patterns help establish a service architecture and supporting infrastructure that enables a given service to be reliably reused and scaled in response to increasing usage demands. Examples include Redundant Implementation (345), Service Data Replication (350), State Repository (242), Stateful Services (248), and Service Grid (254).
• Additionally, patterns like Metadata Centralization (280) and Canonical Expression (275) that help establish governance infrastructure further support the design-time identification and interpretation of services for reuse purposes.
• Finally, it is through Capability Recomposition (526) that reuse and the attainment of increased returns on initial investments are achieved.
Several other more specialized patterns can also play a key part in maximizing reuse by solving design problems specific to creating agnostic services or in relation to their runtime usage.
Organizational agility refers to a state at which an enterprise is sufficiently service-oriented so that it can adapt to business change more responsively. This enables the organization as a whole to respond to new requirements or challenges with less time and effort (Figure 23.6). The result is a measurable advantage that increases its efficiency and even its overall competitiveness. To achieve this level of organizational agility, all types service-oriented technology architectures must themselves be inherently flexible and agile.
Because this strategic goal is reliant upon the attainment of several of the previously listed goals, it also benefits from the previously listed patterns that apply to those goals.
For example:
• During their inception, services modeled and designed as per Agnostic Context (312) and Agnostic Capability (324) and further shaped by variations of Service Layers (143) fundamentally establish the ability to continually apply Capability Recomposition (526) in response to new and changing business requirements
• Service Refactoring (484) and the various governance-related patterns further enable services to be more efficiently evolved and adapted.
• Runtime platform patterns, such as Orchestration (701), Enterprise Service Bus (704), and Service Grid (254), can establish effective levels of centralized operation and maintenance in addition to providing sophisticated infrastructure that allows services to be scaled and increases the overall robustness of an inventory architecture.
• The standardization realized by the successful application of canonical patterns, such as Canonical Schema (158), Canonical Protocol (150), and Canonical Versioning (286), is fully leveraged when needing to maximize organizational responsiveness with reduced solution delivery effort.
This ultimate strategic benefit is the result of the combined attainment of increased ROI and increased organizational agility. A service-oriented IT enterprise can essentially offer its parent organization more responsiveness with less effort and cost.
This benefit is strategic in that for it to be continuously realized, the supporting technology environment needs to be properly governed and evolved to keep up with both business change and technology innovation. Providing the maximum business value to the organization in a manner that reduces the impact of IT is the ultimate target state of service-oriented computing. This state is achieved by realizing flexible and effective service, composition, and inventory architectures in full support of strategic business goals—and—maintaining this flexibility and effectiveness by fully leveraging every iteration of the business-technology cycle, thereby allowing both business and IT communities to evolve in support of each other (Figure 23.7).
Figure 23.7. The strategic goals of service-oriented computing represent a target state that service-orientation provides a method of achieving. The successful application of service-orientation helps shape and define requirements for different types of service-oriented architectures that end up establishing an IT automation model designed to fully support the endless two-way cycle of change through which business and IT communities continually transition. Amidst all of this, SOA design patterns introduce a critical success factor by providing proven design solutions and practices that support (and are supported by) service-orientation.
