Inventory Endpoint

How can a collection of services be shielded from external access while still offering their capabilities to external consumers?

Problem A group of services delivered for a specific inventory may provide capabilities that are useful to services outside of that inventory. However, for security and governance reasons, it may not be desirable to expose all services or all service capabilities to the external consumer base.
Solution Abstract the relevant capabilities into an endpoint service that acts as a faŤade dedicated to a specific set of external consumers.
Application The endpoint service can expose a contract with the same capabilities as its underlying services, but augmented with policies or other characteristics to accommodate external consumer interaction requirements.	Impacts Endpoint services can increase the governance freedom of underlying services but also increase governance effort by introducing redundant service logic and contracts into an inventory.
Principles Standardized Service Contract, Service Loose Coupling, Service Abstraction	Architecture Inventory

Table 6.12 – Profile summary for the Inventory Endpoint pattern.

Problem

As described in Chapter 4, a service inventory represents a collection of independently standardized and governed services. Because individual service inventories are usually owned by specific groups, departments, or organizations, they are particular to the technical environments also owned by those same custodians.

When opportunities arise for services to share their capabilities with other services that reside outside of the inventory (whether they are services within the same organization but part of a different inventory or service consumers external to the organization itself), interoperability, privacy, and security-related concerns often arise, making the option of simply exposing internal inventory services to external consumers less than desirable.

Figure 6.56 – External service consumers accessing native inventory services can impose different requirements and may introduce new risks.

Solution

A special type of intermediary service is positioned as the official entry point for any interaction required by external consumers and the native services within the inventory. This endpoint service essentially provides a contract that establishes an API specific to a group of consumer programs.

Figure 6.57 – A new service introduced to facilitate external consumer requirements and can ensure that other native inventory services are not affected.

By abstracting capabilities from a collection services into a single contract, inventory endpoint services offer several benefits, including:

•     Increased governance freedom for the underlying services, as they can be changed and extended without affecting the endpoint service contract. Even if underlying service functionality needs to be altered, logic could be introduced into the endpoint service to accommodate for the changes so that external consumers remain unaffected and unaware.

•     The endpoint service contract can be fully customized for the external consumer programs. This allows for the addition of data and security constraints, policy assertions and alternatives, and even the support of additional transport protocols unique to the consumer interaction requirements. By abstracting these implementation requirements into a single service, underling inventory service implementations are not required to change.

•     A separate endpoint service can be created for each group of external consumers. This allows the aforementioned mentioned customization to be specific to a range of user types. For example, one endpoint service can be created for consumers from a different domain inventory and a separate endpoint service can be positioned for consumer programs residing outside of the organization itself.

•     Beyond providing alternative contract representation for inventory services, this endpoint can also provide protocol transformation functionality (as per the Protocol Bridging pattern) so that consumers that use disparate protocols or data exchange technologies can access inventory functionality via a specialized endpoint.

Application

Endpoint services are typically single-purpose with non-agnostic functional contexts, and are therefore generally classified as task services. Some organizations, however, prefer to consider the endpoint service as its own service model, especially since they may be required to encapsulate inventory-specific task services.

Although they are often delivered and owned by the custodian of the inventory for which they act as endpoints, they are not always considered members of that inventory because they are required to conform to different design standards and are not made available for native compositions. Endpoint services are often literally maintained at the periphery of inventory boundaries.

Therefore, the first step to working with endpoint services is to establish an effective ownership structure that will allow these services to evolve with both their underlying inventories and their consumers.

For endpoint services created to interact with consumers from external organizations, special implementation requirements are almost always needed. These can include the need for deployment within a DMZ on an isolated server and various infrastructure extensions associated with security and sometimes scalability.

The core service logic for an endpoint service is generally comparable to logic shaped by the Service FaŤade pattern in that it is mostly comprised of routines that relay data requests and responses to and from the external consumers and the underlying inventory services. However, when endpoint services are required to provide new polices or enforce new constraints, additional logic is needed. Furthermore, endpoint services are commonly relied upon to act as brokers by carrying out Data Model Transformation, Data Format Transformation, and even Protocol Bridging patterns.

Impacts

While endpoint services increase the freedom with which inventory services can be evolved and governed over time, they do result in the introduction of new services and service contracts that will need to be maintained as an addition to the service inventory itself. This governance responsibility and the associated ownership issues that need to be addressed can introduce a significant amount of cost and effort because of the on-going maintenance required to keep them in-synch with internal service and external consumer requirements. This pattern may even lead to the need for a new IT group altogether (especially if multiple endpoint services are produced).

Relationships

The use of the Inventory Endpoint pattern raises both contract design and architectural issues, which therefore relates this pattern to service design patterns, such as Service FaŤade and Concurrent Contracts, as well as implementation-related patterns like Composition Autonomy and Redundant Implementation.

In fact, this pattern can sometimes appear as a specialized variation of the Concurrent Contracts pattern in that it introduces the need to establish a new service (with a new contract) that functionally overlaps with existing inventory services (and therefore also violates the Service Normalization pattern to some extent).

As shown by the relationships to broker patterns on the right side of Figure 6.x, one of the most common responsibilities of the inventory endpoint service is to overcome the communication disparity between inventory services and external consumers. This is simply because consumers outside of the inventory are generally subject to different design standards and conventions.

Figure 6.58 – The Inventory Endpoint pattern provides a specialized design solution that touches on a range of design issues.

Case Study Example

Case study content is not available on this Web site.