Service A is a utility service that provides generic data access logic to a database that
contains data that is periodically replicated from a shared database (1). Because the
Standardized Service Contract principle was applied to the design of Service A, its service
contract has been fully standardized.
Service A is being accessed by three service consumers. Service Consumer A accesses a
component that is part of the Service A implementation by invoking it directly (2). Service
Consumer B invokes Service A by accessing its service contract (3). Service Consumer C
directly accesses the replicated database that is part of the Service A implementation (4).

You've been told that the reason Service Consumers A and C bypass the published
Service A service contract is because, for security reasons, they are not allowed to access
a subset of the operations in the WSDL definition that expresses the service contract. How
can the Service A architecture be changed to enforce these security restrictions while
avoiding negative forms of coupling?

• A. The Concurrent Contracts pattern can be applied to Service A in order to establish one
  or more alternative service contracts. This allows service consumers with different levels of
  security clearance to continue accessing the service logic via its published service
  contracts.
• B. The Contract Centralization pattern can be applied to force service consumers to access
  the Service A architecture via its published service contract only. The Service Loose
  Coupling principle can then be applied to ensure that the centralized service contract does
  not contain any content that is dependent on or derived from the underlying service
  implementation.
• C. The Contract Centralization pattern can be applied to force all service consumers to
  access the Service A architecture via its published service contract. This will prevent
  negative forms of coupling that could lead to problems when the database is replaced. The
  Service Abstraction principle can then be applied to hide underlying service architecture
  details so that future service consumers cannot be designed to access any part of the
  underlying service implementation.
• D. None of the above.

Service A is an entity service that provides a set of generic and reusable service
capabilities. In order to carry out the functionality of any one of its service capabilities,
Service A is required to compose Service B (1) and Service C (2) and Service A is required
to access Database A (3), Database B (4), and Database C (5). These three databases are
shared by other applications within the IT enterprise.
All of service capabilities provided by Service A are synchronous, which means that for
each request a service consumer makes. Service A is required to issue a response
message after all of the processing has completed.
Depending on the nature of the service consumer request, Service A may be required to
hold data it receives in memory until its underlying processing completes. This includes
data it may receive from either Service A or Service B or from any of the three shared
databases.
Service A is one of many entity services that reside in a highly normalized service
inventory. Because Service A provides agnostic logic, it is heavily reused and is currently
part of many service compositions.

You are told that Service A has recently become unstable and unreliable and several of the
service consumers that access it have had to raise runtime exceptions due to these
problems. What steps can be taken to solve these problems without compromising the
normalization of the service inventory?

• A. The Service Autonomy principle can be applied to increase the physical isolation of
  Service A and to reduce dependencies Service A has on external resources. In support of
  this, the Service Data Replication pattern can be applied in order to establish a dedicated
  database that contains replicated data from shared Databases A, B, and C . Furthermore,
  the Redundant Implementation pattern can be applied so that the logic Service A requires
  from Services B and C can be redundantly placed inside of Service A . This way, Service A
  avoids having to separately compose Services B and C
• B. The Service Statelessness principle can be applied with the help of the State Repository
  pattern in order to establish a state database that Service A can use to defer state data it
  may be required to hold for extended periods. The Service Autonomy principle can also be
  applied in order to increase the physical isolation of Service A and to reduce dependencies
  Service A has on external resources. In support of this, the Service Data Replication
  pattern can be applied in order to establish a dedicated database that contains replicated
  data from shared Databases A, B, and C.
• C. None of the above.
• D. The Service Loose Coupling and Standardized Service Contract principles can be
  applied by introducing a separate utility service that provides centralized data access to the
  Databases A, B, and C, and exposes a standardized service contract that can be used by
  Service A . This will prevent Service A from direct dependencies on the shared databases
  in case any of them are replaced in the future. By following this approach, the Legacy
  Wrapper pattern is effectively applied via the introduction of the new utility service.

Upon reviewing these requirements it becomes evident to you that the Orchestration
compound pattern will need to be applied. However, there are additional requirements that
need to be fulfilled. To build this service composition architecture, which patterns that is not
associated with the Orchestration compound pattern need to also be applied? (Be sure to
choose only those patterns that relate directly to the requirements described above.
Patterns associated with the Orchestration compound pattern include both the required or
core patterns that are part of the basic compound pattern and the optional patterns that can
extend the basic compound pattern.)

• A. Reliable Messaging
• B. Compensating Service Transaction
• C. State Repository
• D. Event-Driven Messaging
• E. Intermediate Routing
• F. Redundant Implementation
• G. Data Format Transformation
• H. Policy Centralization
• I. Process Centralization
• J. Service Data Replication
• K. Data Model Transformation
• L. Protocol Bridging
• M. Atomic Service Transaction