S90.01 Sample Questions & Answers

The Service Façade pattern is specifically designed to introduce a coarse-grained service that provides a simplified, unified interface to a collection of finer-grained or disparate backend systems. In this case, a PatientDataFacade service would accept a patient ID and then orchestrate calls to the Appointments, Billing, and Medical Records systems, aggregating the results into a single response. This perfectly matches the requirement to hide backend complexity and provide a simple contract for the new portal.

The Process Centralization pattern, often implemented using concepts like sagas and compensation, is designed to manage long-running transactions that span multiple autonomous services. To solve the race condition, the orchestrator could first place a 'hold' on the inventory item (a reservation). If the payment fails, a compensation logic (e.g., ReleaseInventoryHold) is triggered to revert the business transaction. This ensures consistency without requiring distributed ACID transactions, which are generally avoided in SOA.

This statement is false. The 'contract-first' approach advocates for designing and standardizing the service contract before the development of the underlying service logic begins. This allows for parallel development, as service consumers can build against the stable, published contract while the service provider team works on the implementation. It prioritizes the interface over the implementation details.

Service Statelessness is the principle that services should not manage or retain state information specific to any ongoing consumer activity. By not retaining history, the service treats every request as a brand-new interaction. This design greatly enhances scalability and resilience, as any instance of the service can handle any request, simplifying load balancing and failover.

For long-running processes like video encoding, a synchronous (blocking) call is impractical as it would lock up the client application and likely time out. Asynchronous messaging is the ideal pattern. The client submits an encoding job to a message queue and immediately gets a confirmation (e.g., a job ID). The VideoEncoding service processes jobs from the queue at its own pace. Once a job is complete, the service can notify the client via a callback URL or the client can periodically poll a status endpoint using the job ID.

In a top-down service-oriented analysis, the workflow starts from the business requirements. After identifying the core business processes, the next logical step is to decompose these processes into their constituent steps or sub-processes. This decomposition helps to reveal the specific business capabilities that are required to execute the process, which in turn become the primary candidates for services.

The Service Registry and Repository is the central catalog for a service inventory. The registry provides the discoverability mechanism (how to find services), while the repository stores the service contracts, policies, and other metadata. This infrastructure is essential for governance and for promoting the key SOA goal of service reuse.

The requirement to call operations in a specific order (InitializeCache first) introduces temporal coupling. This makes the service difficult and unreliable to compose into larger business processes. An orchestrator or another service consumer must now be aware of this non-standard, stateful behavior, which complicates its design and increases the likelihood of errors. A well-composed service should have operations that are as independent as possible.