Service A . Service B . and Service C are each designed to access the same shared legacy system. The service contracts for Service A, Service B, and Service C are standardized and decoupled from the underlying service logic. Service A and Service B are agnostic services that are frequently reused by different service compositions. Service C is a non-agnostic task service that requires access to the legacy system in order to retrieve business rules required for the service to make runtime decisions that determine its service composition logic. The legacy system uses a proprietary file format that Services A, B, and C need to convert to and from. Service A is an agnostic utility service that is used by other services to gain access to the legacy system. Services B and C were not designed to access the legacy system via Service A because the Service A service contract was derived from the legacy system API and is therefore not standardized and exhibits negative contract-to-implementation coupling. You are told that additional services need to be created, all of which need access to the legacy system. You are also told that the legacy system may be replaced in the near future. What steps can be taken to ensure that the replacement of the legacy system has a minimal impact on Services B and C and any future services that are designed to rely upon it?
Currently there are no comments in this discussion, be the first to comment!