Termination Notification
By David Orchard, Chris Riley
How can the scheduled expiry of a service contract be communicated to consumer programs?
Table 16.3. Profile summary for the Termination Notification pattern.
Problem |
Consumer programs may be unaware of when a service or a service contract version is scheduled for retirement, thereby risking runtime failure. |
Solution |
Service contracts can be designed to express termination information for programmatic and human consumption. |
Application |
Service contracts can be extended with ignorable policy assertions or supplemented with human-readable annotations. |
Impacts |
The syntax and conventions used to express termination information must be understood by service consumers in order for this information to be effectively used. |
Principles |
Standardized Service Contract |
Architecture |
Composition, Service |
Problem
As services evolve over time, various conditions and circumstances can lead to the need to retire a service contract, a portion of a service contract, or the entire service itself.
Examples include:
- the service contract is subjected to a non-backwards-compatible change
- a compatible change is applied to a service contract but strict versioning policies require the issuance of an entirely new version of the service contract
- a service's original functional scope is no longer applicable in relation to how the business has changed
- a service is decomposed into more granular services or combined together with another service
In larger IT enterprises and especially when making services accessible to external partner organizations, it can be challenging to communicate to consumer owners the pending termination of a service or any part of its contract in a timely manner.
Failure to recognize a scheduled retirement will inevitably lead to runtime failure scenarios, where unaware consumer programs that attempt to invoke the service are rejected (Figure 16.7).
Figure 16.7 The consumer program (right) invokes a service via its contract as usual today, but when the contract is terminated on the next day, the attempted invocation fails.
Solution
Service contracts are equipped with termination details, thereby allowing consumers to become aware of the contract retirement in advance (Figure 16.8).
Figure 16.8 The service contract includes a standardized statement that communicates when it is scheduled for termination. As a result, the consumer does not attempt to invoke it after the contract has been terminated.
Application
This pattern is most commonly applied by supplementing technical contract content with human-readable annotations that simply provide the termination date. However, with Web service contracts, there is also the option of leveraging the WS-Policy language to express termination notifications via ignorable policy assertions. This enables consumer programs to be designed to programmatically check for termination information.
It is also worth noting that in addition to expressing service contract termination, there are other purposes for which Termination Notification can be applied, such as:
- Indicating the retirement of a specific capability or operation– This is especially relevant when choosing one of the transition techniques described in Compatible Change (465) where an original operation is preserved and a similar, but changed, operation is added.
- Indicating the retirement of an entire service– This same approach can be used to communicate that an entire service program itself is scheduled for retirement.
- Indicating the retirement of a message schema– Although policy assertions may not be suitable for this purpose, regular annotations can be added to schemas to explain when the schema version will be terminated and/or replaced.
Note also that governance standards can be put in place as part of an overarching Canonical Versioning (286) strategy to express termination notification information via standardized annotations or non-ignorable policy assertions. In the latter case, this can require that all Web service contracts contain termination assertions, regardless of whether they are due for termination. For those contracts that are not being terminated, a pre-defined value indicating this is placed in the assertion instead of a date (or the assertion is left empty).
Impacts
All of the techniques explained in this pattern description require the use of non-standardized extension content for service contracts. This is because there is no industry standard for expressing termination information. Termination Notification relies on the existence and successful enforcement of governance standards and therefore has a direct dependency on Canonical Versioning (286).
Relationships
As just mentioned, how this pattern is applied is often governed by Canonical Versioning (286). Both Compatible Change (465) and Proxy Capability (497) can lead to the need for Termination Notification.
Figure 16.9 Termination Notification relates primarily to other versioning patterns but also can support Proxy Capability (497).