The architecture for Service A displayed in the Figure shows how the core logic of Service
A has expanded over time to connect to a database and a proprietary legacy system (1)
and to support two separate service contracts (2) that are accessed by different service
consumers.
The service contracts are fully decoupled from the service logic. The service logic is
therefore coupled to the service contracts and to the underlying implementation resources
(the database and the legacy system).
Service A currently has three service consumers. Service Consumer A and Service
Consumer B access Service A's two service contracts (3, 4). Service Consumer C
bypasses the service contracts and accesses the service logic directly (5).

You are told that the database and legacy system that are currently being used by Service
A are being replaced with different products. The two service contracts are completely
decoupled from the core service logic, but there is still a concern that the introduction of the
new products will cause the core service logic to behave differently than before. What steps
can be taken to change the Service A architecture in preparation for the introduction of the
new products so that the impact on Service Consumers A, B, and C is minimized?

• A. The Service Abstraction principle can be applied to hide the implementation details from
  the core service logic of Service A, thereby shielding this logic from changes to the
  implementation. In support of this, the Service Facade pattern can be applied to position
  Facade components between the core service logic and Service Consumers A and B.
  These Facade components will be designed to regulate the behavior of Service A . The
  Contract Centralization pattern can be applied to force Service Consumer C to access
  Service A via one of its existing service contracts.
• B. A third service contract can be added together with the application of the Contract
  Centralization pattern. This will force Service Consumer C to access Service A via the new
  service contract. The Service Facade pattern can be applied to position a Facade
  component between the new service contract and Service Consumer C in order to regulate
  the behavior of Service A . The Service Abstraction principle can be applied to hide the
  implementation details of Service A so that no future service consumers are designed to
  access any of Service A's underlying resources directly.
• C. None of the above.
• D. The Service Facade pattern can be applied to position Facade components between the
  core service logic and the two service contracts. These Facade components will be
  designed to regulate the behavior of Service A . The Contract Centralization pattern can
  also be applied to force Service Consumer C to access Service A via one of its existing
  service contracts.

When Service A receives a message from Service Consumer A(1),the message is
processed by Component A.
This component first invokes Component B (2), which uses
values from the message to query Database A in order to retrieve additional data.
Component B then returns the additional data to Component A.
Component A then invokes Component C (3), which interacts with the API of a legacy
system to retrieve a new data value. Component C then returns the data value back to
Component A.
Next, Component A sends some of the data it has accumulated to Component D (4), which
writes the data to a te>X file that is placed in a specific folder. Component D then waits
until this file is imported into a different system via a regularly scheduled batch import.
Upon completion of the import, Component D returns a success or failure code back to
Component A.
Component A finally sends a response to Service Consumer A (5) containing all of the data
collected so far and Service Consumer A writes all of the data to Database B (6).
Components A, B, C.
and D belong to the Service A service architecture. Database A, the
legacy system, and the file folders are shared resources within the IT enterprise.

Service A is an entity service with a service architecture that has grown over the past few
years. As a result of a service inventory-wide redesign project, you are asked to revisit the
Service A service architecture in order to separate the logic provided by Components B, C,
and D into three different utility services without disrupting the behavior of Service A as it
relates to Service Consumer A . What steps can be taken to fulfill these requirements?

• A. The Legacy Wrapper pattern can be applied so that Component B is separated into a
  separate utility service that wraps the shared database. The Legacy Wrapper pattern can
  be applied again so that Component C is separated into a separate utility service that acts
  as a wrapper for the legacy system API. Component D is separated into a separate service
  and the Event-Driven Messaging pattern is applied to establish a publisher-subscriber
  relationship between this new service and Component A.
  The interaction between Service Consumer A and Component A is then redesigned so that Component A first interacts with
  Component B and the new wrapper service. Service A then issues a final message back to
  Service Consumer A.
  The Service Composability principle can be further applied to Service
  A and the three new wrapper utility services so that all four services are optimized for
  participation in the new service composition. This will help make up for any performance
  loss that may result from splitting the three components into separate services.
• B. The Legacy Wrapper pattern can be applied so that Component B is separated into a
  separate utility service that wraps the shared database. The Legacy Wrapper pattern can
  be applied again so that Component C is separated into a separate utility service that acts
  as a wrapper for the legacy system API. The Legacy Wrapper pattern can be applied once
  more to Component D so that it is separated into another utility service that provides
  standardized access to the file folder. The Service Facade pattern can be applied so that
  three Facade components are added: one between Component A and each of the new
  wrapper utility services. This way, the Facade components can compensate for any change
  in behavior that may occur as a result of the separation. The Service Composability
  principle can be further applied to Service A and the three new wrapper utility services so
  that all four services are optimized for participation in the new service composition. This will
  help make up for any performance loss that may result from splitting the three components
  into separate services.
• C. The Legacy Wrapper pattern can be applied so that Component B is separated into a
  separate wrapper utility service that wraps the shared database. The Asynchronous
  Queuing pattern can be applied so that a messaging queue is positioned between
  Component A and Component C, thereby enabling communication during times when the
  legacy system may be unavailable or heavily accessed by other parts of the IT enterprise.
  The Service Facade pattern can be applied so that a Facade component is added between
  Component A and Component D so that any change in behavior can be compensated. The
  Service Autonomy principle can be further applied to Service A to help make up for any
  performance loss that may result from splitting the component into a separate wrapper
  utility service.
• 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. The problem has
been traced to two issues with the current service architecture. First, Service B, which is
also an entity service, is being increasingly reused and has itself become unstable and
unreliable. When Service B fails, the failure is carried over to Service A . Secondly, shared
Database B has a complex data model. Some of the queries issued by Service A to shared
Database B can take a very long time to complete. What steps can be taken to solve these
problems without compromising the normalization of the service inventory?

• A. The Redundant Implementation pattern can be applied to Service B, thereby making
  duplicate deployments of the service available. This way, when one implementation of
  Service B is too busy, another implementation can be accessed by Service A instead. The
  Service Data Replication pattern can be applied to establish a dedicated database that
  contains a copy of the data from shared Database B that is required by Service A . The
  replicated database is designed with an optimized data model in order to improve query
  execution performance.
• B. The Redundant Implementation pattern can be applied to Service B, thereby making
  duplicate deployments of the service available. This way, when one implementation of
  Service B is too busy, another implementation can be accessed by Service A instead. The
  Service Data Replication pattern can be applied to establish a dedicated database that
  contains an exact copy of the data from shared Database B that is required by Service A .
• C. The Redundant Implementation pattern can be applied to Service A, thereby making
  duplicate deployments of the service available. This way, when one implementation of
  Service A is too busy, another implementation can be accessed by service consumers
  instead. The Service Data Replication pattern can be applied to establish a dedicated
  database that contains an exact copy of the data from shared Database B that is required
  by Service A .
• D. None of the above.