In order to achieve __________ we have traditionally required __________ projects. With service- orientation, we aim to establish an intrinsic level of __________ within each service so as to reduce…

Question

Options

• Avendor diversity, integration, vendor diversity, design
• Bagility, development, scalability, development
• Cinteroperability, integration, interoperability, integration
• Dautonomy, integration, statelessness, integration

• A
  2% (1)
• B
  2% (1)
• C
  91% (39)
• D
  5% (2)

Explanation

Option C is correct because it captures a foundational SOA principle: traditionally, making disparate systems work together (interoperability) demanded costly, custom integration projects (e.g., middleware, adapters, ESBs). Service-orientation solves this by designing each service to be inherently interoperable - using standard contracts, protocols, and data formats - so that bolt-on integration effort becomes unnecessary.

Why the distractors fail:

• A (vendor diversity) is irrelevant - SOA's goal isn't vendor diversity, and "reduce design effort" is nonsensical in this context.
• B (agility/scalability) swaps in real SOA benefits, but the sentence logic breaks - development projects weren't traditionally required to achieve agility, and scalability isn't something you embed intrinsically per-service to replace development effort.
• D (autonomy/statelessness) mixes valid SOA terms but incorrectly implies we historically built integration projects to achieve autonomy, and that embedding statelessness replaces integration work - neither holds.

Memory tip: Think of the word that appears twice - the correct answer repeats the same word in both blanks (interoperability...interoperability, integration...integration). The sentence structure is a problem/solution pair where the same concepts appear before and after the SOA fix.

No community discussion yet for this question.