Service Façade

How can a service be designed to support multiple contracts while maintaining logic-to-contract coupling?

Problem Services with standardized contracts will have high logic-to-contract coupling which can conflict with requirements to support multiple contracts.
Solution The underlying service implementation can contain a façade component which corresponds to a contract and enables the abstraction of a core body of service logic, allowing for additional facades and contracts to be added to the same service.
Application A separate façade component is established during the initial service design.	Impacts The addition of the façade component adds design effort and performance overhead.
Principles Standardized Service Contract, Service Loose Coupling	Architecture Service

Table 8.12 – Profile summary for the Service Logic Façade pattern.

Problem

When applying the Standardized Service Contract principle, we are encouraged to tailor service logic in support of the custom contract, resulting in a high level of logic-to-contract coupling. Although this is generally considered desirable for regular services, it can introduce design challenges when a service is required to support multiple contracts.

For example, new underlying logic may need to be added in order to facilitate unique processing requirements of the existing service logic. This can impact the original service logic design, requiring regression testing against all existing service consumers.

Alternatively, to avoid this impact, redundant service logic may be introduced for the new contract, leading to a bloated and denormalized service implementation. Neither of the these results is desirable.

Figure 8.45 – Two undesirable design options for supporting multiple service contracts with just a base unit of service logic. The first (left) requires a new version of the service logic, while the second (right) requires the development of a new service altogether.

Solution

Using the proven façade pattern popularized by object-oriented design, core service logic can be cleanly abstracted from logic that is specific to the processing requirements of a service contract.

A service initially designed with this separation can more easily accommodate new contracts by repeating this pattern to introduce new façade components. This leads to a service architecture comprised of core service logic that is interfaced by multiple service contracts via multiple façades.

Figure 8.46 – The abstraction achieved through the use of façade components allows for the addition of multiple service contracts without major impact to the core service logic.

Application

The key design consideration is the core body of service logic. It needs to be shaped in preparation for multiple component access, which translates into a requirement for a well defined, generic, and flexible component interface.

Impacts

Creating façade components results in an increased amount of physical logic decomposition. This naturally introduces additional design and development effort, as well as extra cross-component communication requirements. Although some performance overhead is expected, it is generally minor as long as façade and core service components are located on the same physical server.

Some governance overhead can also be expected, due to the increased amount of components per service.

Relationships

The structural solution provided by Service Façade helps support the application of several other patterns, including Service Refactoring, Service Decomposition, Proxy Capability, Agnostic Sub-Controller, Inventory Endpoint, Distributed Capability, Concurrent Contracts, and Contract Denormalization. This pattern is ideally combined with Decoupled Contract in order to provide the maximum amount of design flexibility throughout a serviceÕs lifespan.

Figure 8.47 – The Service Façade pattern establishes a key part of the service logic that ends up supporting several other service design patterns.

Case Study Example

Case study content is not available on this Web site.