The design patterns in this chapter represent the most essential steps required to partition and organize solution logic into services and capabilities in support of subsequent composition. In many ways, these patterns can be considered fundamental service-orientation theory.
As shown in Figure 11.1, the patterns are organized into a proposed application sequence. As much as the individual patterns provide proven solutions, the suggested application sequence itself is also proven, which is why this chapter is structured accordingly.
The patterns are divided into two groups that lead up to the application of the composition patterns in Chapter 17, as follows:
1. Service Identification Patterns– The overall solution logic required to solve a given problem is first defined, and the parts of this logic suitable for service encapsulation are subsequently filtered out.
2. Service Definition Patterns– Base functional service contexts are defined and used to organize available service logic. Within agnostic contexts, service logic is further partitioned into individual capabilities.
3. Capability Composition Patterns– The previous patterns establish the boundaries of capability utilization, which naturally leads to the composition patterns described in Chapter 17.
When you string the service identification and service definition patterns together in their suggested application sequence, you will end up with a sequence of steps that can be considered a primitive service modeling process. The purpose of this process is only to raise the more fundamental considerations when shaping services into candidates for subsequent design. In real-life applications, the steps represented by these patterns would be part of a larger, customized process and methodology.
Note
If you haven’t already, be sure to also read the How Foundational Inventory and Service Design Patterns Relate section at the beginning of Chapter 6.
Case Study Background
Due to the emphasis on the fundamental process established by the pattern sequence, all case study examples in this chapter revolve around a simple business task presenting a modest set of requirements that are fulfilled through the application of these patterns.
The following process description provides the necessary background information for subsequent examples.
The Chain Inventory Transfer Business Process
Whenever Cutit Saws manufactures a new chain, it undergoes a short process that takes the newly assembled chain from the manufacturing to the inventory control departments, as follows:
1. The assembled chain is released by the manufacturing team and delivered to a Quality Inspector.
2. The chain undergoes a manual inspection for defects, which includes endurance and alignment tests.
3. If the chain passes these tests, it is forwarded to the Inventory Controller (a person). If any one of the tests fail, the chain is sent back to the manufacturing team, along with a test report that is not electronically recorded.
4. The Inventory Controller generates an inventory record for the chain to officially add it to the inventory.
5. As part of creating an inventory record, the chain is assigned a predefined model number. If back orders for this model exist, the chain is also associated with the next back order in line.
6. As part of a back order, the chain is then forwarded to the shipping department along with a corresponding order document.
7. If the chain model is not on back order, the chain is simply added to the existing inventory stock.
As illustrated in Figure 11.2, this process consists of a combination of automated and manual steps.
These initial design patterns (Figure 11.3) essentially carry out a separation of concerns in support of service-orientation during which solution logic is decomposed and the portions suitable for service encapsulation are identified. The result is a foundation of unorganized logic ready to be shaped into legitimate services via the application of the subsequent service definition patterns and the principles of service-orientation.
Note
You might notice that these upcoming patterns are the only two design patterns in this book that are not directly related to any service-orientation design principles (as per the Principles field in the upcoming profile summary tables).
These patterns are so foundational that there is not yet an opportunity to involve or connect them with the specific design considerations raised by common service-orientation principles. However, one could argue that because they are so fundamental to establishing services that they are, in fact, related to all parts of service-orientation.
Most business tasks or business processes requiring automation constitute large problems. An accepted approach to solving a large automation problem has been to build an application. Prior to the advent of distributed computing, custom-developed applications were primarily designed as monolithic executables—single, self-contained bodies of solution logic (Figure 11.4).
Repeatedly solving large problems by building monolithic solution logic results in an enterprise comprised of single-purpose applications residing in siloed implementation boundaries.
For many organizations such environments have posed significant challenges associated with extensibility and cross-application connectivity. Furthermore, a siloed technology landscape can become bloated and expensive to maintain and change—so much so that many of these applications have remained in modernized technical environments as entrenched legacy systems that continue to inhibit the overall evolution of the enterprise.
Functional Decomposition is essentially an application of the separation of concerns theory. This established software engineering principle promotes the decomposition of a larger problem into smaller problems (called concerns) for which corresponding units of solution logic can be built.
The rationale is that a larger problem can be more easily and effectively solved when separated into smaller parts. Each unit of solution logic that is built exists as a separate body of logic responsible for solving one or more of the identified, smaller concerns (Figure 11.5). This design approach is well-established and forms the basis for previous and current distributed computing platforms.
Figure 11.5 Distributed computing is based on an approach where a large problem is decomposed and its corresponding solution logic is distributed across individual solution logic units. On its own, this pattern results in the decomposition of the larger problem into smaller problems, as shown in the top part of this figure. The actual definition of solution logic units occurs through the application of subsequent patterns in this chapter.
Note
One of the key considerations when applying this pattern as part of the overall application sequence is that many of the individually defined units of solution logic will eventually be expected to be able to help solve additional large problems in order to achieve the target state explained in the pattern description for Capability Recomposition (526) and illustrated in Figure 17.5.
As previously stated, Function Decomposition is essentially realized by carrying out the separation of concerns in support of service-orientation. A primary means by which service-orientation is distinguished from other distributed design approaches is the manner in which separation is achieved and how units of solution logic are defined.
This pattern is therefore not applied independently. It represents the starting point for a process that begins with functional separation and then continues through to shape separated logic into services, as per the subsequent patterns in this chapter.
In practice, this form of decomposition is generally achieved via a service modeling process that begins with a preliminary identification of individual concerns. The large problem corresponds to a business process that needs to be automated. The functional decomposition of this business process results in the definition of granular process steps, each of which can be considered an individual concern.
Distributed units of solution logic require individual attention with regards to interconnectivity, security, reliability, and maintenance in order to ensure that each chain in the link of runtime activity processing is and remains adequately reliable and self-sufficient. An environment consisting of a large amount of smaller software programs therefore imposes more design complexity and governance challenges than one comprised of a single monolithic application.
Furthermore, the effectiveness of this pattern is limited by the quality of the problem definition. For a business process (representing the larger problem) to be properly decomposed, it needs to be documented in an accurate and detailed manner so that individual process steps are sufficiently granular. If the quality of the business process definition is poor, then the resulting concerns will form a weak foundation for subsequent service definition.
On a fundamental level, you could say that Functional Decomposition forms the basis for all of the patterns in this book. But when identifying direct relationships, the only pattern that really qualifies is Service Encapsulation (305). Functional Decomposition essentially prepares the concerns that are subsequently addressed by solution logic that begins to take shape with the application of Service Encapsulation (305).
A collection of related software programs that represent a larger, decomposed body of solution logic can continue to exist within a siloed application boundary. In fact, many past distributed systems were built this way. The decision to partition the solution logic into smaller units was often motivated by the following considerations:
• increasing scalability by separating the parts of the system more subject to high volume and concurrency
• improving security by isolating specific parts of the system with special access and privacy requirements
• increasing reliability by distributing critical parts of a system across multiple physical servers
• achieving nominal reuse within the system boundary (or within a limited part of the enterprise)
When an enterprise is comprised of siloed (or quasi-siloed) distributed solutions (Figure 11.7), it can encounter many design and governance challenges, such as:
• significant amounts of waste and redundancy
• inefficient application delivery
• bloated, oversized technical environments
• complex infrastructure and convoluted enterprise architecture
• complex and expensive integration
• ever-increasing IT operational costs
Details regarding these issues are documented in the Life Before Service-Orientation section of SOA Principles of Service Design and also at SOAPrinciples.com.
Solution logic suitable for classification as an enterprise resource can be encapsulated by and exposed as a service. This essentially means that the logic itself may form the basis for a new service, or the logic may be encapsulated by an existing service (most likely as a new capability). This results in an environment where services are shared (Figure 11.8).
The first required step is to identify and filter out solution logic that is actually suitable as an enterprise resource. Not all solution logic falls into this category. There will be bodies of logic that are tailored for individual distributed applications and for which other design approaches may be more appropriate.
Here are some guidelines:
|
• |
Does the logic contain functionality that is useful to parts of the enterprise outside of the immediate application boundary? |
|
If it does, the logic has increased value potential that may warrant its classification as an enterprise resource. This type of logic generally forms the basis of an agnostic service, as per Agnostic Context (312). |
|
|
• |
Does logic designed to leverage enterprise resources also have the potential to become an enterprise resource? |
|
This form of logic emerges after evident agnostic logic is initially separated. It may be required for service-orientation to be applied to this type of logic so that it remains uniform with agnostic services and so that some or all of its functionality can also be positioned as an enterprise resource. This option is further explored in Non-Agnostic Context (319). |
|
|
• |
Does the implementation of the logic impose hard constraints that make it impractical or impossible to position the logic as an effective enterprise resource? |
|
Regardless of whether the nature of the logic makes it suitable as an enterprise resource, there may be real-world limitations that prevent it from being effectively encapsulated by a service. |
Using criteria such as this, the solution logic suitable for service encapsulation can be identified, allowing unsuitable logic to be filtered out (Figure 11.9).
For encapsulated solution logic to become an effective member of a service inventory, it needs to be further shaped by other patterns and principles so that it is designed to support the strategic goals associated with service-oriented computing.
A solid knowledge of the service-orientation design paradigm is therefore necessary in order to best determine when logic is and is not suitable for service encapsulation. As a rule of thumb, if service-orientation design principles cannot be applied to a meaningful extent, the logic will not likely warrant service encapsulation.
As previously stated, how this logic is determined is based on the methodology used and the maturity of the existing service inventory. Logic identified as being suitable for service encapsulation may be assigned to an existing service, or it may form the basis of a new service.
Because the application of this pattern results in the identification and filtering of logic (in preparation for the upcoming group of service definition patterns), there is no immediate impact.
However, it should be noted that its application is limited to the filtering process only. Logic that is not considered suitable for service encapsulation is given no further consideration by this or any other patterns in this chapter. Therefore, this pattern sequence must be part of a larger analysis process that encompasses the modeling of solution logic that will not be encapsulated within services.
The identification of logic suitable for service encapsulation and the grouping and distribution of that logic within distinct functional contexts establishes fundamental service boundaries. These boundaries become increasingly important as an inventory of services is assembled and inventory-related patterns, such as Service Normalization (131), are applied to avoid functional overlap.
To define the most suitable boundary for a service requires that the most suitable functional context be established. This determines what functionality belongs within and outside of a service boundary. This next set of patterns (Figure 11.11) help make this determination by providing criteria for whether service logic is to be considered agnostic or non-agnostic and further guidance for how agnostic service logic in particular can be organized into separate capabilities.
Note
For a description of the term “agnostic” and related background information, see the Agnostic Logic and Non-Agnostic Logic section at the beginning of Chapter 7.
The solution logic required to solve a single concern will frequently include logic that is also suitable for solving other concerns. Grouping single and multi-purpose functionality together into one unit of logic will limit or even eliminate the potential for reuse (Figure 11.12).
Figure 11.12 Decomposed units of solution logic will naturally be designed to solve concerns specific to a single, larger problem. Units 1, 3, and 6 represent logic that contains multi-purpose functionality trapped within a single-purpose (single concern) context. Single-purpose (non-agnostic) logic is represented by the striped pattern in this diagram.
Solution logic that is agnostic to the larger problem is separated from logic that is specific to the larger problem. One or more services with distinct agnostic functional contexts are then identified within which the agnostic logic is located (Figure 11.13).
Solution logic is further decomposed and reorganized as a result of carrying out formal analysis and modeling processes. Agnostic logic is defined and continually refined into a set of candidate service contexts. These contexts can be based on pre-defined agnostic service model classifications, such as those that form the basis of Entity Abstraction (175) and Utility Abstraction (168).
The application of this design pattern essentially results in the creation of services with reuse potential, which ties directly into several strategic service-oriented computing benefits, including an increased and repeatable return on investment.
Achieving these benefits tends to increase the overall quantity of services required to solve a given problem, which leads to additional design considerations and performance overhead associated with service compositions.
The governance effort of agnostic services is significantly more than if the corresponding solution logic was dedicated to a single application. Additionally, the governance of the overall architecture is also impacted as the quantity of agnostic services within an inventory grows.
From a service design perspective, Agnostic Context is one of the most distinctive patterns associated with service-orientation. It therefore has several relationships with other patterns that apply specialized variations of Agnostic Context, such as Entity Abstraction (175) and Utility Abstraction (168). The closest relationship is between Agnostic Context and Agnostic Capability (324), as the latter is applied to services that have already been deemed agnostic.
Case Study Example
Cutit analysts and architects review the logic identified as being potentially suitable for service encapsulation and break down this logic into individual actions, as follows:
Solution for Concern 2
• create a new inventory record
• retrieve chain specification information by serial number
• enter chain information, including the assignment of pre-defined model number
• save new inventory record
Solution for Concern 3
• issue a query for back orders keyed on model number
• retrieve a list of outstanding back order records sorted by order date
• if no back orders exist, terminate process
Solution for Concern 4
• retrieve the back order record with the oldest date (the next back order in line)
• change status of order from “back order” to “completed”
• save revised order record
Upon assessing the suitability for these actions to be classified as reusable (and forming the basis of entity or utility-centric agnostic functional contexts), the Cutit team reorganizes the logic into different groupings (Figure 11.15) and comes up with the following preliminary agnostic service contexts:
Inventory Processing
• create a new inventory record
• enter chain information, including the assignment of pre-defined model number
• save new inventory record
Figure 11.15 The agnostic service contexts established as a result of applying this pattern; all three services are based on Entity Abstraction (175).
Chain Information
• retrieve chain specification information by serial number
Order Processing
• issue a query for back orders keyed on model number
• retrieve a list of outstanding back order records (if any) sorted by order date
• retrieve the back order record with the oldest date (the next back order in line)
• change status of order from “back order” to “completed”
• save revised order record
When applying service-orientation, there is a great deal of emphasis on abstracting and positioning solution logic that is agnostic to business tasks and parent business processes. This forms the very basis of the Service Reusability principle and associated patterns.
The result is that non-agnostic logic gets filtered out and often relegated to encapsulation within software programs that are not part of the service inventory but instead exist peripherally as dedicated service consumers (also referred to as “composition initiators”). This is represented by the top part of Figure 11.16.
In this case, service-orientation is not applied to non-agnostic solution logic, which limits its potential to ever become an effective enterprise resource, which can compromise the quality of the service compositions the logic may be responsible for controlling.
Suitable non-agnostic solution logic is encapsulated by a service with a correspondingly non-agnostic functional context (Figure 11.17). This positions the logic as part of a service inventory. A secondary benefit is that, as a service, this logic is further available for any potential unforeseen involvement in service compositions.
Non-agnostic service logic is shaped via the same governing design principles as agnostic services with the exception of Service Reusability and with a lesser initial emphasis on service contract design.
Note
If reusable functionality is discovered within the boundary of a non-agnostic service, it can be made available via Agnostic Sub-Controller (607).
This pattern is most commonly applied in combination with Process Abstraction (182) to establish a standard task service layer. However, it is not limited to encapsulating parent business process logic. Other custom, single-purpose service models can be created and based on a non-agnostic functional context.
There are no rules as to whether this pattern should be applied before or after Agnostic Context (312). The mainstream service modeling process described at SOAMethodology.com suggests identifying agnostic service candidates prior to non-agnostic candidates so that multi-purpose logic can be filtered out first, but it is really up to your preferences and whatever methodology you end up using.
Either way, the end result of completing both Agnostic Context (312) and Non-Agnostic Context is that all of the solution logic considered suitable for service encapsulation ends up organized into a set of well-defined service contexts (Figure 11.18).
Note
As explained in the description for Process Abstraction (182), non-agnostic logic is not required to reside in a service. The assumption when applying this pattern is that the logic allocated for a non-agnostic service was identified as being suitable for encapsulation as per the prior application of Service Encapsulation (305). When applying Non-Agnostic Context as part of a service modeling process, logic designated for a non-agnostic service can still be relocated to a non-service-oriented program. Herbjörn Wilhelmsen published a study at SOAMag.com that compares the pros and cons of abstracting single-purpose logic into services and non-service-oriented applications.
Because service-orientation still needs to be applied to the underlying solution logic of a non-agnostic service, its initial delivery will be more expensive and more time-consuming than if it were to simply exist in a program external to the service inventory. The ultimate return on this investment can therefore be significantly lower than with agnostic services.
Note
It is the application of this pattern to a body of non-agnostic logic that determines whether this logic is considered a composition initiator or a composition controller. The former is a non-service-oriented program generally responsible for triggering composition logic, whereas the latter is a service responsible for encapsulating composition logic.
When studying Non-Agnostic Context, it is important to remember that it is applied subsequent to Service Encapsulation (305). Even though the context is specific to one purpose, it is still considered a service.
The types of services that most commonly require this pattern are those based on task-centric service models. This explains the relationships between Process Abstraction (182) and Process Centralization (193), which are associated with the task service and orchestrated task service models respectively.
A key relationship also defined in Figure 11.19 is that between Non-Agnostic Context and Capability Composition (521). The single-purpose nature of the logic encapsulated by services based on non-agnostic contexts is generally associated with composition logic required to automate a business task. Therefore, this pattern fully supports and even enables Capability Composition (521) and Capability Recomposition (526).
Case Study Example
The definition of a non-agnostic service context for the Chain Inventory Transfer process is quite straightforward primarily because the process is so simple. A parent service context is created to represent the process itself and to assume the responsibility of executing the workflow logic described previously in Figure 11.2.
As shown in Figure 11.20, because this service context is defined by the scope of the business process, it is accordingly named.
Figure 11.20 An intentionally non-agnostic service context representing the parent business process is defined. In the Chapter 17 case study examples, this service will be responsible for composing the agnostic services defined earlier in the example for Agnostic Context (312).
When defining service capabilities that were derived from concerns related to a specific problem, there is the natural tendency for those capabilities to be specific to those concerns, regardless of that fact that they reside within an agnostic service context.
This can result in a set of capabilities that may appear to be agnostic but actually provide functionality that is very specific to the concerns associated with the original large problem (or business process) for which they were originally defined (Figure 11.21).
Agnostic service capabilities are defined and each is subjected to additional analysis beyond its initial definition, allowing it to be refined until it reaches a point where it is sufficiently balanced so that it remains aligned to the parent service’s agnostic context while also accommodating the functional requirements of a range of common service consumers. This enables each service capability to address a concern that is truly common (multi-purpose), thereby allowing it to help solve multiple larger problems (Figure 11.22).
By carrying out service-oriented analysis and service modeling processes, candidate service capabilities are identified, defined, and grouped into candidate service contexts. Through repeated iterations of these processes, the definition and organization of the capabilities are further refined.
This pattern essentially positions each capability as an independent function able to solve a concern that is common to multiple business processes or tasks. Well-defined agnostic capabilities lie at the heart of fundamental service-orientation principles, such as Service Reusability and Service Composability.
The quality of a service capability definition improves with each iteration through a service-oriented analysis process, whereby its functionality and expression (via the service contract) are repeatedly validated or refined. However, all of these iterations add to the up-front analysis time and effort required to produce the service.
Additionally, inadvertent “over modeling” can lead to capabilities that are too vague and too generic or that perhaps offer more functionality than will actually be required. These consequences can be avoided by sticking to analysis processes that are focused on specific business domains.
Agnostic Capability can be considered a continuation of Agnostic Context (312), making these two patterns naturally related. But when studying how services are assembled into compositions, the ultimate role of the defined agnostic capabilities becomes evidently integral to the application of both Capability Composition (521) and Capability Recomposition (526).
Case Study Example
The Cutit team proceeds to establish service capabilities for its three entity services (Figure 11.24), as follows:
• The actions associated with the Inventory Processing context are studied and consolidated into a single capability called “Create Record.”
• The one action allocated to the Chain Information context is shaped into a generic capability called “Retrieve Chain Record.”
• The actions grouped within the Order Processing context are refined into three separate capabilities called “Retrieve Order Record,” “Retrieve Back Order List,” and “Edit Order.”
Although there is an opportunity to proceed into the actual design and development stages with these service definitions, the team insists that they perform some additional service modeling. Several new business processes are analyzed, allowing the functionality (and associated algorithms) behind each capability to be better optimized. Another side-benefit of these additional iterations is the streamlining of the service definitions themselves, as shown in Figure 11.25.
