Project Team Alpha delivers Service A for Solution 1. Project Team Beta delivers Service B for Solution 2. Some time later, Project Team Omega wants to reuse Service A and Service B for its new…

Question

Options

• AServices always require the use of transformation technologies in order to communicate.
• BServices A and B need to reside on the same physical server or workstation, thereby allowing them to
• CServices A and B need to be standardized and designed with an emphasis on intrinsic interoperability
• DService A needs to be designed using a different vendor platform than ServiceB. This enables vendor

• A
  6% (1)
• B
  6% (1)
• C
  71% (12)
• D
  18% (3)

Explanation

Option C is correct because a core principle of service-oriented design is intrinsic interoperability - services are built from the start using common, agreed-upon standards (protocols, data formats, interfaces) so any authorized consumer can use them without custom glue code or a dedicated integration project. When Services A and B were originally built with standardization in mind, Team Omega can simply invoke them as-is for Solution 3.

Why the distractors are wrong:

• A is wrong because standardized services are specifically designed to avoid mandatory transformation layers - needing transformations is a symptom of poor interoperability, not a universal requirement.
• B is wrong because physical co-location is irrelevant; services communicate over networks and must be location-independent by design.
• D is wrong because using different vendor platforms increases integration friction, not decreases it - vendor heterogeneity is an obstacle to reuse, not an enabler.

Memory tip: Think of standardization as the "common plug socket" principle - if every service is built to the same standard outlet shape, any device (solution) can plug in without an adapter (integration project).

No community discussion yet for this question.