S90-09A · Question #19
Services A, B, and C are non-agnostic task services. Service A and Service B use the same shared state database to defer their state data at runtime. An assessment of these three services reveals…
The correct answer is C. The Process Abstraction pattern can be applied, resulting in a redesign effort where agnostic logic. Process Abstraction is correct because it directly addresses both problems simultaneously: by extracting the agnostic logic out of Services A, B, and C into separate, dedicated agnostic services, that logic becomes independently reusable across the enterprise. The redesign also…
Question
Services A, B, and C are non-agnostic task services. Service A and Service B use the same shared state database to defer their state data at runtime. An assessment of these three services reveals that each contains some agnostic logic, but because it is bundled together with the non-agnostic logic, the agnostic logic cannot be made available for reuse. The assessment also determines that because Service A and Service B and the shared state database are each located in physically separate environments, the remote communication required for Service A and Service B to interact with the shared state database is causing an unreasonable decrease in runtime performance. You are asked to redesign this architecture in order to increase the opportunity for agnostic service logic to be reused and in order to decrease the runtime processing demands so that performance can be improved. What steps can be taken to achieve these goals?
Exhibit
Options
- AThe Enterprise Service Bus pattern can be applied to establish an environment whereby the
- BThe Process Centralization pattern can be applied, resulting in a redesign effort where agnostic
- CThe Process Abstraction pattern can be applied, resulting in a redesign effort where agnostic logic
- DNone of the above.
How the community answered
(20 responses)- A5% (1)
- B15% (3)
- C70% (14)
- D10% (2)
Explanation
Process Abstraction is correct because it directly addresses both problems simultaneously: by extracting the agnostic logic out of Services A, B, and C into separate, dedicated agnostic services, that logic becomes independently reusable across the enterprise. The redesign also allows the non-agnostic task logic to be restructured so that state data access can be co-located or optimized, eliminating the costly remote calls to the shared state database that are degrading runtime performance.
Option A (Enterprise Service Bus) is wrong because the ESB pattern addresses communication infrastructure and message mediation - it doesn't decompose mixed logic or solve the fundamental coupling of agnostic and non-agnostic concerns causing the reuse problem.
Option B (Process Centralization) is wrong because centralizing process logic consolidates where orchestration happens, but it doesn't separate agnostic logic from non-agnostic logic - the bundling issue and thus the reuse problem remain unresolved.
Option D is wrong because C is a valid and well-established solution to both stated requirements.
Memory tip: Associate Abstraction with separation - whenever a question describes agnostic logic "trapped" inside a non-agnostic service, Process Abstraction is the pattern that "pulls it out" to make it reusable. If performance is also suffering from remote state access, that restructuring enables co-location fixes as a natural side effect of the redesign.
Topics
Community Discussion
No community discussion yet for this question.