S90-09A · Question #13
Service A is an entity service that provides a set of generic and reusable service capabilities. In order to carry out the functionality of any one of its service capabilities, Service A is required…
The correct answer is B. The Service Statelessness principle can be applied with the help of the State Repository pattern in. Option B is correct because the root cause of Service A's instability is its stateful behavior - it holds data in memory during synchronous processing from Service B, Service C, and three shared databases, which creates resource pressure and failure risk under heavy reuse…
Question
Service A is an entity service that provides a set of generic and reusable service capabilities. In order to carry out the functionality of any one of its service capabilities, Service A is required to compose Service B (1) and Service C (2) and Service A is required to access Database A (3), Database B (4), and Database C (5). These three databases are shared by other applications within the IT enterprise. All of service capabilities provided by Service A are synchronous, which means that for each request a service consumer makes. Service A is required to issue a response message after all of the processing has completed. Depending on the nature of the service consumer request, Service A may be required to hold data it receives in memory until its underlying processing completes. This includes data it may receive from either Service A or Service B or from any of the three shared databases. Service A is one of many entity services that reside in a highly normalized service inventory. Because Service A provides agnostic logic, it is heavily reused and is currently part of many service compositions. You are told that Service A has recently become unstable and unreliable and several of the service consumers that access it have had to raise runtime exceptions due to these problems. What steps can be taken to solve these problems without compromising the normalization of the service inventory?
Exhibit
Options
- AThe Service Autonomy principle can be applied to increase the physical isolation of Service A and
- BThe Service Statelessness principle can be applied with the help of the State Repository pattern in
- DThe Service Loose Coupling and Standardized Service Contract principles can be applied by
- ENone of the above.
How the community answered
(42 responses)- A17% (7)
- B69% (29)
- D10% (4)
- E5% (2)
Explanation
Option B is correct because the root cause of Service A's instability is its stateful behavior - it holds data in memory during synchronous processing from Service B, Service C, and three shared databases, which creates resource pressure and failure risk under heavy reuse. Applying the Service Statelessness principle via the State Repository pattern offloads that in-memory state to an external repository between processing steps, reducing Service A's runtime burden and making it more resilient without touching service boundaries or database ownership.
Option A is wrong because applying Service Autonomy to increase physical isolation would require dedicating shared infrastructure (e.g., the three enterprise databases) exclusively to Service A - directly compromising the normalized, shared service inventory the question explicitly asks to preserve.
Option D is wrong because Service Loose Coupling and Standardized Service Contract address dependency style and interface design, not runtime state management; they don't resolve the instability caused by excessive in-memory data retention.
Option E is wrong because B provides a valid, targeted solution.
Memory tip: When a scenario describes a service that must "hold data in memory" during processing and is becoming unstable under reuse, that's the SOA exam's signal phrase for the State Repository pattern - stateless services delegate their memory problem to a purpose-built store.
Topics
Community Discussion
No community discussion yet for this question.