Fundamental SOA & Service-Oriented Computing (S90-01A) Free Sample Questions

The Service Abstraction principle is violated because the service's internal logic (the different transport methods) is exposed to its consumers. Consumers should interact with a simplified, consistent contract. The best remedy is to create a single track endpoint that accepts a shipment ID. The service itself would then be responsible for looking up the transport method and routing the request internally, completely hiding this complexity from the client.

Service orchestration is the correct choice when a business process requires central control, complex conditional logic, error handling, and transactional integrity across multiple service invocations. A central orchestrator (or composition controller) explicitly defines and executes the workflow, which directly addresses the firm's requirements for management and auditing. Choreography would be unsuitable as it lacks a central point of control and makes tracking the overall process state difficult.

Entity services are designed to manage specific business entities and are typically based on CRUD (Create, Read, Update, Delete) operations. Since Student, Course, and Professor are core business entities, creating corresponding entity services (e.g., Student Service, Course Service) is the standard approach. This promotes high reusability as many different business processes will need to interact with these fundamental entities.

This approach is the most aligned with SOA governance and principles. It centralizes the implementation of the cross-cutting concern (auditing) and applies it declaratively via policy. This preserves service autonomy, as the services themselves are unaware of the auditing logic. It avoids invasive code changes, ensures consistent application of the rule, and allows the policy to be updated in one place. Modifying each service is brittle and violates the principle of separation of concerns.

The Rules Centralization pattern addresses this exact problem. By externalizing the volatile promotion and pricing logic into a dedicated Business Rules Engine (BRE), the core services (ProductCatalog, OrderProcessing) can simply invoke the BRE to get decisions. This allows business analysts to update the rules in the BRE without requiring any code changes or redeployments of the services, thus achieving the goal of extreme agility.

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.