S90.01 Fundamental SOA & Service-Oriented Computing (S90-01A) Practice Questions

A service inventory blueprint, which includes a map of dependencies between services and compositions, is the essential tool for performing impact analysis. By consulting this map, the project manager can visually trace all the consumers of the Invoice service and proactively identify every service and process that would be affected by a contract change, allowing for coordinated updates and testing.

Sharing a database schema is a classic anti-pattern that severely compromises service autonomy. If the schema is changed to accommodate one service, it risks breaking all other services that share it. This creates a high degree of implementation coupling and prevents the service from being changed, deployed, or scaled independently. A truly autonomous service should encapsulate and own its data store.

The proposed architecture directly supports the bank's goals. By creating separate CustomerService, AccountService, and TransferService, it breaks down the monolithic logic into independent, reusable units. This promotes agility, as the AccountService can be updated without impacting the CustomerService. The use of an orchestrator (AccountOrchestrator) is appropriate for managing the stateful, multi-step business process of opening an account, providing a clear and maintainable implementation of the process logic.

Increased business and technology alignment is achieved when the software assets (services) directly correspond to the functional building blocks of the business. By performing service-oriented analysis and modeling services that represent real-world business capabilities (like 'Check Credit Score' or 'Manage Customer Profile'), the IT landscape begins to mirror the business landscape. This makes it easier for the technology to evolve in lockstep with the business.

Using a proprietary format violates the Standardized Service Contract principle, which relies on widely adopted, open standards (like XML or JSON). This in turn harms Service Loose Coupling. Any service consumer must now be tightly coupled to this specific binary format and the logic required to parse it, making it difficult to integrate with services built on different platforms. This creates a barrier to intrinsic interoperability.

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.