Our service inventory contains the following three services that provide invoice-related data access capabilities: Invoice, InvProc, and Proclnv. These services were created at different times by different project teams and were not required to comply to any design standards. Therefore each of these services has a different data model for representing invoice data.
Currently each of these three services has one service consumer: Service Consumer A accesses the Invoice service(1). Service Consumer B (2) accesses the
InvProc service, and Service Consumer C (3) accesses the Proclnv service. Each service consumer invokes a data access capability of an invoice-related service, requiring that service to interact with the shared accounting database that is used by all invoice-related services (4, 5, 6).
Additionally, Service Consumer D was designed to access invoice data from the shared accounting database directly (7). (Within the context of this architecture.
Service Consumer D is labeled as a service consumer because it is accessing a resource that is related to the illustrated service architectures.)
A project team recently proclaimed that it has successfully applied the Contract Centralization pattern to the service inventory in which the Invoice service, InvProc service, and ProcInv service reside. Upon reviewing the previously described architecture you have doubts that this is true. After voicing your doubts to a manager, you are asked to provide specific evidence as to why the Contract Centralization is not currently fully applied. Which of the following statements provides this evidence?
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?
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?
Service A is an entity service that provides a Get capability that returns a data value that is frequently changed.
Service Consumer A invokes Service A in order to request this data value (1). For Service A to carry out this request, it must invoke Service B (2), a utility service that interacts (3.4) with the database in which the data value is stored. Regardless of whether the data value changed, Service B returns the latest value to Service
A (5), and Service A returns the latest value to Service Consumer A (6).
The data value is changed when the legacy client program updates the database (7) When this change happens is not predictable. Note also that Service A and
Service B are not always available at the same time.
Any time the data value changes. Service Consumer A needs to receive it as soon as possible. Therefore, Service Consumer A initiates the message exchange
shown in the Figure several times a day. When it receives the same data value as before, the response from Service A is ignored. When Service A provides an updated data value, Service Consumer A can process it to carry out its task.
The current service composition architecture is using up too many resources due to the repeated invocation of Service A by Service Consumer A and the resulting message exchanges that occur with each invocation. What steps can be taken to solve this problem?
Service A is an entity service that provides a Get capability that returns a data value that is frequently changed.
Service Consumer A invokes Service A in order to request this data value (1). For Service A to carry out this request, it must invoke Service B (2), a utility service
that interacts (3.4) with the database in which the data value is stored, Regardless of whether the data value changed. Service B returns the latest value to Service
A (5), and Service A returns the latest value to Service Consumer A (6).
The data value is changed when the legacy client program updates the database (7). When this change happens is not predictable. Note also that Service A and
Service B are not always available at the same time.
Any time the data value changes. Service Consumer A needs to receive it as soon as possible. Therefore, Service Consumer A initiates the message exchange
shown in the Figure several times a day. When it receives the same data value as before, the response from Service A is ignored. When Service A provides an
updated data value, Service Consumer A can process it to carry out its task.
Because Service A and Service B are not always available at the same times, messages are getting lost and several invocation attempts by Service Consumer A
fail. What steps can be taken to solve this problem?
Service Consumer A sends a message to Service A (1), which then forwards the message to Service B (2). Service B forwards the message to Service C (3), which finally forwards the message to Service D (4).
Services A, B, and C each contain logic that reads the content of the message and, based on this content, determines which service to forward the message to. As a result, what is shown in the Figure is one of several possible runtime scenarios.
You are told that the current service composition architecture is having performance problems because of two specific reasons. First, too many services need to be explicitly invoked in order for the message to arrive at its destination. Secondly, because each of the intermediary services is required to read the entire message
contents in order to determine where to forward the message to, it is taking too long for the overall task to complete. What steps can be taken to solve these problems without sacrificing any of the functionality that currently exists?
Service Consumer A sends a message to Service A (1), which then forwards the message to Service B (2). Service B forwards the message to Service C (3), which finally forwards the message to Service D (4).
Services A, B, and C each contain logic that reads the content of the message and, based on this content, determines which service to forward the message to. As a result, what is shown in the Figure is one of several possible runtime scenarios.
Currently, this service composition architecture is performing adequately, despite the number of services that can be involved in the transmission of one message.
However, you are told that new logic is being added to Service A that will require it to compose one other service in order to retrieve new data at runtime that Service
A will need access to in order to determine where to forward the message to. The involvement of the additional service will make the service composition too large and slow. What steps can be taken to improve the service composition architecture while still accommodating the new requirements and avoiding an increase in the
amount of service composition members?
Services A, B, and C are non-agnostic task services. Service A and Service B use the same shared state database to defer their state data at runtime.
An assessment of these three services reveals that each contains some agnostic logic, but because it is bundled together with the non-agnostic logic, the agnostic logic cannot be made available for reuse.
The assessment also determines that because Service A and Service B and the shared state database are each located in physically separate environments, the remote communication required for Service A and Service B to interact with the shared state database is causing an unreasonable decrease in runtime performance.
You are asked to redesign this architecture in order to increase the opportunity for agnostic service logic to be reused and in order to decrease the runtime processing demands so that performance can be improved. What steps can be taken to achieve these goals?
Services A, B, and C are non-agnostic task services. Service A and Service B use the same shared state database to defer their state data at runtime.
An assessment of these three services reveals that each contains some agnostic logic, but because it is bundled together with the non-agnostic logic, the agnostic logic cannot be made available for reuse.
The assessment also determines that because Service A and Service B and the shared state database are each located in physically separate environments, the remote communication required for Service A and Service B to interact with the shared state database is causing an unreasonable decrease in runtime performance.
How can the application of the Orchestration pattern improve this architecture?
Service A has become increasingly difficult to maintain. Its core service logic has become bloated and convoluted because it has been updated numerous times during which additional functionality was added to interact with the database and the legacy system and to support interaction with Service Consumers A and B (via the two service contracts) as well as interaction directly with Service Consumer C.
What steps can be taken to solve these problems and to prevent them from happening again in the future?