It is interesting to note that the four fundamental design characteristics of a service-oriented architecture (established back in Chapter 4) are closely related to the application of the design patterns in this chapter, as shown in Table 6.1. The nature of these relationships will become clear when reading the pattern descriptions.

Table 6.1 How fundamental inventory design patterns (left) relate to the required base characteristics (top) of service-oriented architecture.

How Foundational Inventory and Service Patterns Relate

As mentioned earlier, this chapter provides a structured collection of patterns provided in a recommended application sequence. Chapter 11 provides a similarly organized set of patterns arranged in a suggested application sequence focused solely on service design. The fact that this chapter precedes Chapter 11 is not meant to indicate that the process established by this pattern application sequence should be completed prior to service design. Inventory design patterns are simply covered first in this book because they tend to be broader and coarser-grained in nature than those specific to service design.

In most modern SOA methodologies, iterative modeling and design processes are used to allow the design of an inventory architecture to be accomplished concurrently with service modeling and identification so that the definition of one can lead to the refinement of the other. It is completely up to you as to how these pattern groups are used in incorporated into project delivery cycles.

How Case Studies are Used in this Chapter

It’s been a few chapters since we introduced the case study backgrounds, so it’s worth a reminder that each of the upcoming design patterns is supplemented with a brief case study example. For this particular chapter, all examples relate back to the Alleywood Lumber Company environment established in the Case #2 Background: Alleywood Lumber Company section in Chapter 2.

As described in that chapter, Alleywood is facing an overhaul of their existing environment. An enterprise SOA initiative will require them to produce a collection of services that continue to represent their existing business lines, while also providing native interconnectivity with existing Tri-Fold services. By progressing through the upcoming sequence of patterns, Alleywood’s service-oriented technology architecture and a preliminary service inventory are defined.

6.1 Inventory Boundary Patterns

As explained in Chapters 3 and 4, a service inventory represents an independently standardized and governed collection of related services, and each such inventory is supported by its own, individual service-oriented technology architecture implementation. Therefore, a fundamental step in the creation of any service inventory is the definition of its scope in relation to the enterprise within which it resides.

The design patterns Enterprise Inventory (116) and Domain Inventory (123) shown in Figure 6.2 establish the boundary of the service inventory. Only one of these two patterns can be applied within a given IT enterprise.

Figure 6.2 These inventory boundary patterns establish well-defined perimeters that determine the physical scope of an inventory.

Table 6.2 Profile summary for the Enterprise Inventory pattern.

Problem

Throughout an enterprise, services can be delivered as part of various on-going development projects. Because each project has its own priorities and goals, services and supporting implementation architectures can easily be designed in isolation, optimized to fulfill tactical requirements.

The result is a collection of potentially disparate service clusters and technology architectures. The differences in these implementation environments can lead to serious problems when attempting to compose services into new configurations that span the initial architectural boundaries (Figure 6.3).

Figure 6.3 All services are built with the same vendor platform, but they are delivered via separate projects without taking into account a common architectural boundary. The end-result is an environment reminiscent of a silo-based enterprise that relies on constant integration effort to enable interoperability.

Solution

A service-oriented enterprise architecture is established to form the basis for a single enterprise service inventory. Services delivered as part of any project are designed specifically for implementation within the enterprise inventory’s supporting architecture, guaranteeing wide-spread standardization and intrinsic interoperability.

Figure 6.4 An enterprise service inventory establishes an enterprise-wide architectural boundary that promotes native interoperability and recomposition among all services.

Application

If the planned enterprise service inventory is significant in scope, then the organization needs to ensure it is capable of carrying out the corresponding SOA adoption effort.

Various factors come into play, each of which may introduce the need to reduce the scope or explore an alternative approach:

• the maturity of available technology for the planned services (especially for services being positioned as highly reusable enterprise resources)

• the maturity of governance technology platforms required to manage and evolve the service inventory as it is being built and after it is in place

• the order of magnitude associated with the amount of change and disruption brought on by the adoption

• the amount of legacy environments that are expected to constrain service encapsulation

• the financial resources required to carry out the adoption

• cultural and political obstacles that may arise as a result of the proposed changes and the required standardization effort

Therefore, this pattern is recommended for the following types of environments:

• small-to-medium-sized organizations with sufficient resources

• medium-to-large-sized organizations with highly controlled IT environments, a history of enterprise-wide standardization, or with the cultural flexibility to successfully adopt the required level of standardization

• medium-to-large-sized organizations that have the resources to build an enterprise service inventory while concurrently operating and maintaining their existing legacy systems

• new organizations that have no legacy systems and no IT history (and can therefore build an IT enterprise with a clean slate)

An enterprise service inventory does not need to encompass an entire enterprise. The purpose of this pattern is to establish a single service inventory with a scope sufficiently meaningful to warrant its creation.

Furthermore, the application of this pattern does not result in the creation of physical services. It establishes the concept of a service inventory on an enterprise-wide scale, for which services are conceptually defined through a planning and analysis effort that ties into the definition of a service inventory blueprint. To accomplish all of this typically requires a top-down analysis project that is completed by iteratively carrying out the service-oriented analysis and service modeling processes.

The following steps provide a suggested process:

1. Carry out planning and analysis stages to determine a preliminary scope for the service inventory that appears to be manageable based on the previously listed factors.

2. Collect all of the necessary enterprise business specifications that document business models and requirements that fall within the scope of the planned inventory (as well as those that are enterprise-wide). These specifications can include business entity models, logical data models, ontologies, taxonomies, business process definitions, and numerous other information and business architecture documents.

3. Using the enterprise-wide business models collected in Step 2, apply Entity Abstraction (175) and Process Abstraction (182) to establish a base set of business service layers.

4. Carry out the service-oriented analysis process iteratively by decomposing business process definitions that fall within the scope of the planned inventory. This results in the definition of service candidates that are continually refined. (See SOAMethodology.com for an example of a top-down process that iterates through the service-oriented analysis stage.)

Note

Several of the previously listed steps also apply to the upcoming pattern Domain Inventory (123). The primary distinctions are scope and quantity. The ultimate goal of Enterprise Inventory is to establish a single service inventory that spans as much of the IT enterprise as possible, whereas Domain Inventory (123) allows for multiple (usually smaller) inventories to exist within an enterprise.

Impacts

To achieve unity across an enterprise-wide service inventory, a large (and sometimes monumental) amount of top-down analysis may be required so that service candidates can be modeled and aligned with each other prior to their actual delivery. This can lead to an expensive and time-consuming up-front analysis project.

Alternative methodologies can be employed to phase in the delivery of services with less initial analysis. One example is the “meet-in-the-middle” approach that allows for analysis to occur on an on-going basis while services are built and implemented. There is then a commitment to “re-align” the services at a later point after the analysis produces a mature enterprise-wide inventory blueprint. Although a proven strategy that overcomes the time-burden of top-down approaches, this method can introduce additional complexities and increased expense.

Common issues that challenge the creation of an enterprise service inventory are documented in the Problem section of the pattern description for Domain Inventory (123) because this pattern provides an alternative approach that directly addresses concerns associated with Enterprise Inventory.

Relationships

Enterprise Inventory establishes an architectural boundary with a physical structure that is further subject to the application of a series of additional inventory-related patterns. Inventory Endpoint (260) in particular can complement this pattern by providing standardized access to consumers outside the enterprise. Domain Inventory (123) provides the primary alternative to this pattern.

Figure 6.5 Enterprise Inventory determines scope, but it relies on other patterns to establish the inventory structure.

Case Study Example

Armed with enterprise architecture standards that dictate technical constraints and further establish a centralized, Web services-centric communications framework, Alleywood and Tri-Fold teams have been able to incorporate strategic business requirements and goals to define a target inventory architecture.

To further set its physical boundary, additional analysis is required to determine what logic the planned service inventory will actually be required to encompass. Business analysts and subject matter experts are employed to participate in a series of service-oriented analysis and service modeling processes where existing and extended business processes are studied and used as a source from which to derive a variety of services.

These processes are carried out iteratively to produce a service inventory blueprint for the collection of services Alleywood is planning to deliver. By performing these processes and applying the service definition patterns described in Chapter 11, a set of initial service candidates is defined (Figure 6.6).

Figure 6.6 The initial set of services that comprise an enterprise service inventory that spans Alleywood and Tri-Fold environments. Gray services belong to Alleywood while purple-colored services originated with Tri-Fold.

Table 6.3 Profile summary for the Domain Inventory pattern.

Problem

In larger environments it can be impractical or even unrealistic to define and maintain a single service inventory for an entire enterprise. Standardization and governance issues can raise numerous concerns, most of which tend to be organizational in nature (Figure 6.7).

Figure 6.7 Common organizational issues that hinder efforts to establish a single enterprise service inventory.

Note

Several of the issues raised in Figure 6.7 relate to the governance of SOA projects and implementations. Organizational and technology-related governance topics (and patterns) will be covered separately in the upcoming title SOA Governance as part of this book series.

Solution

Multiple service inventories are created for one enterprise. The scope of each represents a well-defined enterprise domain. Within domains, service inventories are standardized and governed independently (Figure 6.8).

Figure 6.8 An enterprise partitioned into domain service inventories, each representing a pre-defined domain.

Application

Whether or not to apply this pattern is tied to the question of whether an enterprise service inventory is feasible within a given environment. Many factors (most of which are specific to the organization) weigh in on this decision point. However, some general guidelines are available.

For example, domain service inventories are an appropriate alternative when any of the following supporting factors exist:

• The implementation environment is a large enterprise without strong executive sponsorship and wide-spread support for the SOA initiative.

• The enterprise does not have an established, global data models and creating them is considered unrealistic.

• The organization is incapable of changing the complexion of its IT departments in support of a more centralized governance model.

The application of this pattern can bypass these obstacles and accelerate the transition toward service-orientation in that an enterprise-level migration can be delivered in phases that each result in the creation of a manageable collection of services. For many organizations, this pattern provides the only realistic option for adopting SOA.

The key to creating effective domain inventories is to clearly define the domains in advance, thereby establishing a sub-divided view of an enterprise prior to building any one inventory.

Organizations will often have options as to how the domains are defined. Here are some common examples:

• Organizational business areas represented by specific IT departments or groups. These business areas would then establish the basis for business domains.

• Organizational business domains not represented by separate IT departments or groups. These domains can still form the basis of service inventory boundaries but require cooperation across IT departments.

• Remote offices, each with its own IT department and development center. This can result in geographical-based domains.

Ideally, domain inventories correspond to enterprise business domains, such as those based on an organization’s lines of business. This allows each inventory to be tuned to and evolve with its corresponding set of business models in full support of establishing the business-driven architecture characteristic.

Impacts

Multi-domain service inventory implementations make some impositions, in that they allow for individual inventories to be standardized differently. This generally results in the need to introduce targeted transformation for cross-domain interoperability as part of the overall enterprise architecture.

The ultimate benefits associated with achieving a unified and federated enterprise service-oriented architecture are scaled back to whatever extent domain inventories are created.

Transformation requirements that emerge to enable cross-domain data exchange impact the development and design effort of corresponding service compositions and also add performance overhead to their runtime execution. Furthermore, the independence by which each inventory can be built and evolved will often lead to the creation of redundant services across domains.

Relationships

The same design patterns that structure an enterprise inventory will end up structuring an inventory defined via Domain Inventory (only the scope will be smaller). However, unlike Enterprise Inventory (116), the application of this pattern will generally result in the need for transformation patterns, such as Protocol Bridging (687) and Data Model Transformation (671). Inventory Endpoint (260) will also play a more prominent role to facilitate cross-inventory communication.

Figure 6.9 Domain Inventory shares many of the same relationships as Enterprise Inventory (116) but introduces new requirements that can be fulfilled by additional patterns more specific to a domain-based environment.

Case Study Example

The original goal of McPherson enterprise architects was to establish a global collection of services that would span Alleywood and Tri-Fold platforms. Although it was understood that this would require an unprecedented standardization and federation effort, the strategic benefits seemed to justify it.

However, subsequent to the creation of a more detailed transition plan and associated metrics and cost estimates, many further discussions with management and key IT personnel within Alleywood, Tri-Fold, and other McPherson departments resulted in the identification of several concerns:

• The cost of the standardization effort is much higher than expected, primarily due to the outstanding data architectures that need to be defined.

• Incompatibilities have been identified between some of the preliminary data remodeling that has been performed by Alleywood and the schemas that have already been implemented as part of Tri-Fold’s ERP environment. To bring these into alignment would require changing existing Tri-Fold service implementations.

• Alleywood management has complained about several design standards that have been imposed upon them in order to deliver services in compliance with Tri-Fold requirements. Due to the difference in implementation technology, Alleywood feels these standards introduce awkward and inefficient design characteristics into their planned service designs.

• Alleywood and Tri-Fold use different business modeling methodologies. This has resulted in different forms of business model specifications. Furthermore, meetings between analysts from each organization have been strained due to differences in philosophy and conventions associated with business analysis processes.

These and other reasons have prompted a change in the original strategic plan. Instead of creating a single pool of federated services, separate domain inventories will be established (Figure 6.10). This will allow Alleywood and Tri-Fold teams to design and govern their services independently from each other.

Figure 6.10 Alleywood and Tri-Fold establish physically separate service inventories. Note how the quantity of overall services increases when compared to the previous Enterprise Inventory (116) case study example due to the need to create redundant logic across the physical domains.

6.2 Inventory Structure Patterns

Once the inventory boundary is determined, the complexion and organization of the inventory itself needs to be determined on a fundamental level. The next set of patterns helps define the underlying inventory structure by establishing basic service boundaries and classifications.

As shown in Figure 6.11, Service Normalization (131) and Logic Centralization (136) influence the inventory structure by requiring that future services be in alignment with each other and that future agnostic services in particular be positioned as the sole endpoint for the logic they represent.

Figure 6.11 The inventory structure patterns align and position services within an inventory and further organize the inventory into logical abstraction layers.

There is no proposed sequence within this pattern group. These patterns simply establish modeling and design parameters on an inventory-wide basis.

Table 6.4 Profile summary for the Service Normalization pattern.

Problem

The boundary of a service is defined by its functional context and the collective boundaries of its capabilities. Even within a pre-defined inventory boundary, when services are delivered by multiple project teams there is a risk that some will provide functionality that will overlap with others.

This leads to a denormalization of the inventory (Figure 6.12), which can cause several problems, such as:

• an inability to establish service capabilities as the official endpoints for bodies of agnostic logic

• a more convoluted architecture wherein services with overlapping functionality can become out of synch, providing the same functions in different ways

Figure 6.12 A service inventory containing services with overlapping functional boundaries that introduce denormalization.

Solution

Services are collectively modeled before their individual physical contracts are created. This provides the opportunity for each service boundary to be planned out so as to ensure that it does not overlap with other services. The result is a service inventory with a higher degree of functional normalization (Figure 6.13).

Figure 6.13 When services are delivered with complementary and well-aligned boundaries, normalization across the inventory is attained. Note also how the quantity of required services is reduced.

Relationships

Service Normalization lays the foundation for Contract Centralization (409) by ensuring that no two services share the same functionality. This allows contracts to be positioned as the sole entry point into service logic and further enables those services to be independently evolved, as per Service Refactoring (484). Schema Centralization (200) and Policy Centralization (207) further support this pattern by avoiding contract-related redundancy.

To successfully preserve a normalized inventory requires the consistent enforcement of Logic Centralization (136), making these two patterns very closely related.

Contract Denormalization (414) is referred to in Figure 6.14 only to indicate that, despite its name, it does not interfere with the goals of this pattern. As explained in Chapter 16, Proxy Capability (497) must violate this pattern out of necessity when services require post implementation decomposition.

Figure 6.14 Service Normalization fundamentally organizes a service inventory but relies on the successful application of other patterns to retain this state.

Case Study Example

Because the initial version of the Alleywood inventory service blueprint was defined via a collaborative effort comprised of different groups of architects and business analysts delivering different service candidates, there is a risk that some of the proposed service contexts functionally overlap with others.

A blueprint-wide review is conducted to look for any potential denormalization of the established service boundaries. A few are detected and subsequently corrected by adjusting the parent contexts of the affected services. One such example is shown in Figure 6.15.

Figure 6.15 Those who modeled the Region service assumed it would encompass area-related processing. However, an Area service was also being delivered by a separate modeling team. As a result, the Region service capabilities associated with area record processing are removed to avoid functional overlap and increase overall inventory normalization.

As we established in earlier chapters, reuse represents a key characteristic that typically needs to be realized on a broad scale for some of the more strategic goals associated with service-orientation to be attained. However, even if well-designed agnostic services are consistently delivered into a service inventory, it does not guarantee that project teams building new solutions will use them.

For various reasons, it may be easier, simpler, or just more practical to avoid involving reusable services in order to concentrate on the fulfillment of short-term, tactical delivery goals. This approach may be convenient, but it eventually results in a denormalized service inventory where functional redundancy is common (Figure 6.16).

Figure 6.16 Different project teams delivering services with redundant logic leads to functional overlap among services in the inventory.

To pursue the strategic goals associated with service reuse, the characteristic of reuse itself must form the basis of supporting internal design standards. The foremost of these standards needs to dictate that services classified as agnostic must become a primary (or even sole) means by which the logic they represent is accessed. This forms the basis for Logic Centralization, as depicted in Figure 6.17. The level to which the centralization of logic succeeds as an enterprise-wide standard determines the extent to which the repeated ROI of services can be realized.

Figure 6.17 Service consumers are required to reuse functionality provided by a single designated agnostic service.

When services are built by different project teams, there is always the risk that one team will develop a service with new logic that exists as part of an already-implemented agnostic service.

Common reasons for this are:

While the former scenario can be avoided through the application of Metadata Centralization (280), the latter is where an inventory-wide design standard is required. In fact, the manner in which this pattern is applied is through the creation and enforcement of a standard that requires that services act as the sole entry point for the functional boundaries they represent within a given inventory.

This type of standard essentially dictates that agnostic services must always be used as intended, even if they do not yet possess all required functions. For example, if a new capability needed by a project team clearly falls within the boundary of an existing service, the corresponding functionality needs to be added to that service instead of ending up elsewhere (Figure 6.18).

Figure 6.18 In this case, only one service is considered the “official” entry point for invoice-related processing.

As straightforward as Logic Centralization may sound, it can be difficult to achieve, especially with broadly scoped service inventories. For larger organizations working toward an enterprise service inventory attaining a state where all development project teams agree to not build redundant logic and instead use existing services may seem like an unattainable ideal.

Introducing Logic Centralization into an organization that does not have a history of fostering reuse or using design standards in general will almost always raise cultural issues with people and IT departments affected by service delivery projects.

For example:

These concerns need to be addressed prior to the delivery of agnostic services to avoid compromising the strategic value of a service inventory. If only partial support for the delivery and usage of reusable services is received within an IT division, the risk of ending up with a denormalized and potentially convoluted inventory architecture is significant.

Logic Centralization is a core design pattern very much focused on centralizing agnostic logic, which is why it is commonly associated with Entity Abstraction (175) and Utility Abstraction (168) and also why its application is influenced by Agnostic Context (312) and Agnostic Capability (324).

Whereas Service Normalization (131) primarily solves a service modeling problem, Logic Centralization addresses service usage concerns. In a way, Logic Centralization helps attain the goals of Service Normalization (131).

Contract Centralization (409) also has a very close relationship with Logic Centralization because together they position official services that can only be accessed via official entry points (contracts), which is fundamental to establishing a healthy federated endpoint layer.

There are also numerous peripheral relationships with additional specialized patterns, such as Metadata Centralization (280), which supports the discovery of services to which Logic Centralization has been applied, and Redundant Implementation (345), which supports the scalability demands that tend to fall upon centralized services. Additional examples are shown at the top and bottom of Figure 6.19.

Figure 6.19 Logic Centralization supports the goals of many design patterns but is itself also supported by others.

Perhaps its most important relationship is with Capability Composition (521), a pattern that introduces the fundamental rule that logic outside of a service’s boundary must be composed.

Design patterns and design standards were defined as two separate but related parts of a typical design framework back in Chapter 4. A design pattern provides a proven solution to a common design problem, and a design standard is a mandatory convention applied across multiple systems. Whereas a design pattern is industry-recognized, a design standard is internal and specific to an IT enterprise.

Even though they are distinct, design standards are a lot like design patterns. In fact, design standards can be seen as “pre-solving” specific design issues in order to ensure consistent system designs. It is therefore not uncommon for a design pattern to become the basis of design standard, which is essentially what this group of patterns is all about.

These next patterns (Figure 6.25) do not just propose possible solutions to common problems, but they propose that to solve this set of specific problems, the solutions themselves must become actual design standards.

Figure 6.25 The two standardization patterns enforce fundamental design conventions in support of fostering intra-inventory interoperability.

Though there is no particular order in which these patterns need to be applied, it is sometimes necessary for Canonical Protocol to be established prior to the Canonical Schema because the communications technology represents the fundamental medium by which data (and associated data models) are delivered and processed.

Each service exists as a standalone software program. When these programs need to exchange information, they have to form a connection using a communications technology. When programs are designed to use different communications technologies, they are incompatible and cannot exchange information without involving a separate program that can translate one communications technology to another, as per Protocol Bridging (687).

Building services with different implementation technologies is not uncommon, but allowing services based on different communication technologies to exist within the same architecture can result in limitations. For example, groups of services based on the same communication framework are likely to be delivered as part of the same project. The day any of these services needs to be pulled into a new composition consisting of services delivered by a different project (and using different communication protocols), incompatibility issues could make their connectivity and reuse challenging and perhaps impossible (Figure 6.26).

Figure 6.26 Different groups of services (likely delivered via different projects) establish communication boundaries through the use of incompatible communication protocols.

The technology architecture is designed to limit enablement of cross-service interaction to a single or primary communications protocol or protocol version. All other technologies associated with supporting the protocol’s underlying communications framework are also standardized. This guarantees baseline technological compatibility across services (Figure 6.27).

Figure 6.27 Though still delivered by different projects via different vendor platforms, these services conform to one centralized communications technology, making them technologically compatible.

To ensure that all services an inventory architecture is intended to support can effectively interact and be repeatedly recomposed requires that a centralized communications technology be carefully chosen.

A common framework that fulfills this role is the Web services platform because it leverages industry-standard transport and messaging protocols (e.g., HTTP and SOAP) that are widely supported yet still vendor-neutral. However, even when using Web services, this design standardization pattern must still be applied to overcome possible disparity resulting from the mismatch of protocol-related versions (as illustrated in Figure 6.28). The WS-I Basic Profile is therefore likely a key part of applying this pattern as a means of ensuring technological compatibility among the various versions of Web service technology standards.

Figure 6.28 All parts of the Web service contract are affected by this design pattern.

Alternative communication options can also be explored within controlled environments. For example, a proprietary vendor protocol can be chosen, as long as all services within its inventory are standardized to conform to its use.

Some key considerations when standardizing on one communication protocol are:

When the preferred protocol imposes constraints in any of these areas, Dual Protocols (227) can be viewed as a viable alternative to (or even a first step toward) this pattern.

Canonical Protocol’s architectural focus naturally results in relationships with other architecture-centric design patterns, such as Canonical Resources (237), Enterprise Inventory (116), and Domain Inventory (123).

By standardizing the medium by which services exchange business and activity data, a foundation for service interoperability is established. Therefore, this pattern is closely related to Service Messaging (533), Messaging Metadata (538), and also Schema Centralization (200).

Figure 6.29 Canonical Protocol proposes an inventory-wide design standard that solves foundational interoperability issues and therefore relates to inventory and messaging patterns.

Case Study Example

Alleywood’s IT environment has historically been Java-based. The services planned as part of the current project were naturally going to be developed and implemented using Java technologies. The importance of Canonical Protocol was acknowledged as architects determined that it would make the most sense for all services to be accessible via a central JMS messaging framework.

However, subsequent discussions with Tri-Fold architects and enterprise architects from McPherson resulted in a requirement to move toward a Web services-based communications framework instead.

This was a strategic decision based primarily on the fact that Tri-Fold’s services are comprised of endpoints into a larger ERP, plus a set of custom .NET components. Neither environment supports JMS, but both support Web services, as does Alleywood’s Java-based platform (Figure 6.30).

Figure 6.30 Although the application of this pattern was already considered when attempting to standardize on JMS, subsequent requirements broadened the scope of the centralized communications framework to encompass three platforms. This led to the decision to standardize on the use of Web services.