S90-09A · Question #24
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…
The correct answer is C. The Legacy Wrapper pattern can be applied together with the Standardized Service Contract. Option C is correct because the Legacy Wrapper pattern is specifically designed to encapsulate a legacy system's proprietary interface behind a new, standardized service facade - handling the file format conversion internally and exposing a clean contract that Services B, C…
Question
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?
Exhibit
Options
- AThe Service Abstraction, Service Reusability, and Service Autonomy principles need to be applied
- BThe Standardized Service Contract and Service Loose Coupling principles can be applied in order
- CThe Legacy Wrapper pattern can be applied together with the Standardized Service Contract
- DNone of the above.
How the community answered
(34 responses)- A32% (11)
- B15% (5)
- C44% (15)
- D9% (3)
Explanation
Option C is correct because the Legacy Wrapper pattern is specifically designed to encapsulate a legacy system's proprietary interface behind a new, standardized service facade - handling the file format conversion internally and exposing a clean contract that Services B, C, and future services can rely on. Combined with the Standardized Service Contract principle, the wrapper's contract is properly decoupled from the legacy implementation, so when the legacy system is replaced, only the wrapper needs to change, leaving all consumers untouched.
Why A is wrong: Service Abstraction, Reusability, and Autonomy are general design principles but don't provide a concrete mechanism to shield consumers from a legacy system's proprietary internals - they don't solve the replacement-impact problem directly.
Why B is wrong: Standardized Service Contract and Service Loose Coupling are necessary principles, but applying them alone (without the Legacy Wrapper pattern) leaves no structural isolation layer between the legacy system and its consumers - the "how" is missing.
Why D is wrong: C is clearly applicable, so "none of the above" is incorrect.
Memory tip: Think of the Legacy Wrapper as a diplomatic translator - it speaks the legacy system's proprietary language internally, but presents a standardized, stable face to the outside world. When the legacy system is swapped out, only the translator needs retraining, not every service that talked to it.
Topics
Community Discussion
No community discussion yet for this question.