img
Home > Candidate Patterns > UI Agnostic Service

UI Agnostic Service

How can services that encapsulate legacy assets be designed in a user interface independent manner?

Problem

Legacy APIs or messages often mirror the contents of a user interface. These APIs expect inputs and provide output information corresponding to the input fields and output display fields on user interface screens. Any attempt to service-enable these assets by wrapping the APIs or messages with Web services is likely to result in services with incorrect granularity and poor reuse potential.

Solution

Instead of offering a very coarse-grained, screen-centric service, expose self-contained, independent business services individually to the consumers and shift the responsibility of aggregating information from unrelated business services to the presentation tier.

Application

Analyze the input and output data of legacy APIs or messages to determine the extent of user interface dependence. If the input and output data mirror the contents of specific screens decompose those APIs or messages into a collection of cohesive, logical business services. These services will have to be fulfilled by appropriate APIs or messages from the legacy system.

Impacts

Minor enhancements or modifications may be necessary on the legacy systems to expose business logic with appropriate granularity as APIs or messages.

Tool driven legacy service enablement strategies pose greater risks of UI centric services, and therefore this approach needs strict governance and joint analysis sessions between business and IT.

Status

Under Review

Contributors

Satadru Roy

Problem

First generation legacy systems running on mainframes (zOS) or midrange computers (iSeries) were characterized by a tight coupling between presentation logic and business logic. Access to business functions was possible only through 3270 or 5250 green screens, a key reason why they became known as terminal-based applications. In response to the Web revolution, the next generation legacy technologies moved away from this model and made it possible to invoke business logic via means of APIs (e.g., through CICS COMMAREA) or messages (e.g., MQ).

However, the consumer applications were still largely centered around those same green screens, albeit web-enabled, and unfortunately, for many applications, the APIs to the outside world were modeled based on the requirements of those consumers. As a result, UI elements now crept into APIs as the input and output data got tied to entire contents of screens even when the output content was essentially an aggregation of information obtained from possibly unrelated business functions. Ironically, even when different business functions (e.g., customer portfolio summary, new product offers for a customer etc.) were fulfilled by discrete legacy programs or routines, they were often not exposed directly via APIs and instead, components known as 'transaction handlers' or adapters were built on the backend that orchestrated the calls to business logic components, aggregated the information before returning them back to the callers. These handler interfaces became the de facto APIs.

img

Figure 1 - Legacy transaction handlers received API calls and aggregated information as per the requirements of a user interface by calling different business logic components. The API reflected the granularity of the user interface instead of the business transactions.

All this resulted in APIs or messages that were tied with specific screens, had incorrect business granularity and almost zero reuse potential. Straightforward service-enablement of such assets by wrapping them adds no value and jeopardizes the entire legacy service enablement effort.

Solution

The solution involves building self-contained, wrapper hybrid services that reflect the discrete business functionality required and moving the orchestration of unrelated business functions to the presentation tier. The necessary orchestration of the business functions is quite unique to the consumer and is unlikely to be a candidate for a reusable composite service and hence, the orchestration is best left to the consumer.

img

Figure 2 - UI independent, self-contained wrapper services are made available to the consumers. UI related aggregation of data from unrelated business services is handled by orchestration of the wrapper service calls in the presentation tier.

Application

A logical mapping needs to determine how legacy interfaces with UI dependencies correspond to aggregation of business functions. If it is determined that suitable transaction handlers for these business functions already exist then legacy interface can be eliminated altogether and service consumer applications can orchestrate and aggregate individual business services as per their requirements - we should emphasize the fact that we are excluding composite services from the scope of this discussion such as what was covered in Multi-Channel Endpoint.

If all of the logical business services required are not currently available, wrapper hybrid services need to be built for each of them so that they can be invoked from any consumer application without any dependency on a specific context. However, implementation of the wrapper services will be dependent on legacy system APIs or messages that may or may not be available as described in the problems section. In situations where the business components are not directly exposed via APIs additional transaction handlers may have to be built on the legacy side to wrap the components and offer an appropriate interface to the consumers.

Impact

Applying this pattern may have rework consequences for the existing service consumers as well as the legacy systems themselves. Service consumers that were relying on UI dependent services now need to be implemented differently to handle the orchestration and aggregation of data at their end.

There is potential rework implication on the legacy side as well where business functions are not exposed via APIs or messages at right level of granularity and changes need to be made to ensure appropriate interfaces are made available. If such changes are deemed impractical, wrapper services will need to call existing legacy APIs, albeit with incorrect granularity, but filter out the information that may not be required by the consumer. If retention of legacy assets is a strategic objective, incremental enhancements to introduce appropriate legacy interfaces will bring long term benefits that are likely to outweigh short-term costs.

Case Study Example

Business partners of [X] are demanding that product offers for common customers be made available through an automated service. However, analysis of the existing legacy assets at [X] reveals that the legacy system in question does not expose an API at this level of granularity. However, further investigation leads to a surprising discovery - an MQ based interface is offered for self-serve and in-branch channel applications that combine the customer portfolio information with recommended offers for that customer.

At the time this interface was designed the customer summary screens for both of these channel applications were derived from previous generation green screens which combined the portfolio information with recommended offers. Because of the green screen legacy the backend already had the adapter to handle this request and it was decided to expose an API at this level of granularity to save development time such that channel applications could directly consume this API.

The architects realized this was a classic case of a UI centric service and it was decided to break down the interface into logically independent, discrete business services - a customer portfolio service and a recommended customer offers service. Fortunately, a separate legacy program to generate the recommended offers was already available but it was not exposed via any APIs. The lead architect decided it was a worthwhile investment to create a separate adapter on the legacy system to expose this service to the consumers.

The presentation tier applications were also refactored to handle the orchestration of two separate calls at their end. This ensured that future consumer applications could directly call the independent business services and handle the orchestration and data aggregation as per their own unique requirements.