S90-09A · Question #1
Service A is an entity service with a functional context dedicated to invoice-related processing. Service B is a utility service that provides generic data access to a database. In this service…
The correct answer is B. The service composition can be redesigned so that Service Consumer A sends the invoice. Option B is correct because, under Contract Centralization (without Logic Centralization), the solution must eliminate schema mismatches through redesign rather than runtime transformation. Redesigning the composition so that Service Consumer A sends the invoice directly to…
Question
Service A is an entity service with a functional context dedicated to invoice-related processing. Service B is a utility service that provides generic data access to a database. In this service composition architecture, Service Consumer A sends a SOAP message containing an invoice XML document to Service A(1). Service A then sends the invoice XML document to Service B (2), which then writes the invoice document to a database. The data model used by Service Consumer A to represent the invoice document is based on XML Schema A. The service contract of Service A is designed to accept invoice documents based on XML Schema B. The service contract for Service B is designed to accept invoice documents based on XML Schema A. The database to which Service B needs to write the invoice record only accepts entire business documents in Comma Separated Value (CSV) format. Due to the incompatibility of the XML schemas used by the services, the sending of the invoice document from Service Consumer A through to Service B cannot be accomplished using the services as they currently exist. Assuming that the Contract Centralization pattern is being applied and that the Logic Centralization is not being applied, what steps can be taken to enable the sending of the invoice document from Service Consumer A to the database without adding logic that will increase the runtime performance requirements of the service composition?
Exhibit
Options
- AService Consumer A can be redesigned to use XML Schema B so that the SOAP message it
- BThe service composition can be redesigned so that Service Consumer A sends the invoice
- CService Consumer A can be redesigned to write the invoice document directly to the database.
- DNone of the above.
How the community answered
(27 responses)- A15% (4)
- B70% (19)
- C4% (1)
- D11% (3)
Explanation
Option B is correct because, under Contract Centralization (without Logic Centralization), the solution must eliminate schema mismatches through redesign rather than runtime transformation. Redesigning the composition so that Service Consumer A sends the invoice directly to Service B is valid because both already use XML Schema A - removing the incompatible Service A hop entirely. Service B's responsibility to write to the CSV database is pre-existing logic, not new runtime overhead, so no additional performance burden is introduced.
Option A fails because even if Consumer A adopts XML Schema B to match Service A's contract, a mismatch still exists between Service A (Schema B) and Service B (Schema A) - one schema problem is traded for another, and the CSV conversion issue remains unresolved.
Option C is wrong because having Consumer A write directly to the database violates the SOA principle of separation of concerns, bypasses the utility service entirely, and embeds data access logic into a service consumer - this contradicts the architecture's design intent.
Option D is eliminated because Option B provides a valid, architecturally sound solution.
Memory tip: Think of it as "fix the path, not the pipe." Contract Centralization means you standardize who talks to whom and on what contract terms - if two services already share a compatible contract (Consumer A and Service B both use Schema A), redesign the composition flow to use that compatible path directly instead of adding transformation middleware.
Topics
Community Discussion
No community discussion yet for this question.