S90-09A · Question #15
Service A is an entity service that provides a Get capability that returns a data value that is frequently changed. Service Consumer A invokes Service A in order to request this data value (1). For…
The correct answer is D. None of the above. Option D is correct because the scenario presents multiple compounding problems - wasteful polling, unpredictable legacy updates, and intermittent availability between Service A and Service B - that no single pattern from the listed choices fully resolves on its own. Options A…
Question
Service A is an entity service that provides a Get capability that returns a data value that is frequently changed. Service Consumer A invokes Service A in order to request this data value (1). For Service A to carry out this request, it must invoke Service B (2), a utility service that interacts (3.4) with the database in which the data value is stored. Regardless of whether the data value changed, Service B returns the latest value to Service A (5), and Service A returns the latest value to Service Consumer A (6). The data value is changed when the legacy client program updates the database (7) When this change happens is not predictable. Note also that Service A and Service B are not always available at the same time. Any time the data value changes. Service Consumer A needs to receive it as soon as possible. Therefore, Service Consumer A initiates the message exchange shown in the Figure several times a day. When it receives the same data value as before, the response from Service A is ignored. When Service A provides an updated data value, Service Consumer A can process it to carry out its task. The current service composition architecture is using up too many resources due to the repeated invocation of Service A by Service Consumer A and the resulting message exchanges that occur with each invocation. What steps can be taken to solve this problem?
Exhibit
Options
- AThe Event-Driven Messaging pattern can be applied by establishing a subscriber-publisher
- BThe Event-Driven Messaging pattern can be applied by establishing a subscriber-publisher
- CThe Asynchronous Queuing pattern can be applied so that messaging queues are established
- DNone of the above.
How the community answered
(39 responses)- A13% (5)
- B23% (9)
- C5% (2)
- D59% (23)
Explanation
Option D is correct because the scenario presents multiple compounding problems - wasteful polling, unpredictable legacy updates, and intermittent availability between Service A and Service B - that no single pattern from the listed choices fully resolves on its own.
Options A and B both suggest applying the Event-Driven Messaging pattern (subscriber-publisher model), which would eliminate the polling waste by notifying Service Consumer A only when data changes; however, this doesn't address the availability mismatch between Service A and Service B, nor does it account for the legacy client that writes directly to the database outside any service interface, making event publication non-trivial to implement cleanly.
Option C proposes Asynchronous Queuing, which helps decouple services with mismatched availability, but it does not eliminate the root cause of the polling problem - Service Consumer A would still need to repeatedly initiate requests rather than being notified proactively.
The correct solution requires a combination of patterns (e.g., Event-Driven Messaging + Asynchronous Queuing + possibly a State Repository or Caching pattern to bridge the legacy gap), and since no single listed option captures that full picture, "None of the above" is the right answer.
Memory tip: When an SOA exam scenario lists multiple distinct problems (polling waste + availability gaps + legacy coupling), watch for answer choices that solve only one - if none solve all of them together, reach for "None of the above."
Topics
Community Discussion
No community discussion yet for this question.