S90.08B 試験問題を無料オンラインアクセス

Refer to Exhibit.

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 and B is minimized? What further step can be taken to avoid consumer-to-implementation coupling with Service Consumer C?

• A.The Service Fagade pattern can be applied to position fagade components between the core service logic and the implementation resources (the database and the legacy system). These fagade components will be designed to insulate the core service logic of Service A from the changes in the underlying implementation resources. The Schema Centralization and Endpoint Redirection patterns can also be applied to force Service Consumer C to access Service A via one of its existing service contracts.
• B.The Service Fagade pattern can be applied to position fagade components between the core service logic and the two service contracts. These fagade components will be designed to regulate the behavior of Service A. The Service Loose Coupling principle can be applied to avoid negative forms of coupling.
• C.The Service Fagade pattern can be applied to position fagade components between the core service logic and Service Consumers A and B. These fagade components will be designed to regulate the behavior of Service A. The Service Abstraction principle can be applied to hide the implementation details of the core service logic of Service A, thereby shielding this logic from changes to the implementation. The Schema Centralization pattern can be applied to force Service Consumer C to access Service A via one of its existing service contracts.
• D.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 Fagade pattern can be applied to position a fagade 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.

Refer to Exhibit.

Service Consumer A and Service A reside in Service Inventory A. Service B and Service C reside in Service Inventory B. Service D is a public service that can be openly accessed via the World Wide Web. The service is also available for purchase so that it can be deployed independently within IT enterprises. Due to the rigorous application of the Service Abstraction principle within Service Inventory B, the only information that is made available about Service B and Service C are the published service contracts. For Service D, the service contract plus a service level agreement (SLA) are made available. The SLA indicates that Service D has a planned outage every night from 11:00pm to midnight.
You are an architect with a project team that is building services for Service Inventory A. You are told that the owners of Service Inventory A and Service Inventory B are not generally cooperative or communicative. Cross-inventory service composition is tolerated, but not directly supported. As a result, no SLAs for Service B and Service C are available and you have no knowledge about how available these services are. Based on the service contracts you can determine that the services in Service Inventory B use different data models and a different transport protocol than the services in Service Inventory A. Furthermore, recent testing results have shown that the performance of Service D is highly unpredictable due to the heavy amount of concurrent access it receives from service consumers from other organizations. You are also told that there is a concern over how long Service Consumer A will need to remain stateful while waiting for a response from Service A.
What steps can be taken to solve these problems?

• A.The Containerization pattern can be applied to establish an environment for Service A to perform its processing autonomously. This gives Service A the flexibility to provide Service Consumer A with response messages consistently. The Asynchronous Queuing pattern can be applied so that a central messaging queue is positioned between Service A and Service B, between Service A and Service C, and between Service A and Service D. The Data Model Transformation and Protocol Bridging patterns can be applied to enable communication between Service A and Service B and between Service A and Service C.
• B.The Asynchronous Queuing pattern can be applied to position a central messaging queue between Service A and Service B and between Service A and Service C and so that a separate messaging queue is positioned between Service A and Service Consumer A. The Data Model Transformation and Protocol Bridging patterns can be applied to enable communication between Service A and Service B and between Service A and Service C. The Redundant Implementation pattern can be applied so that a copy of Service D is brought in-house. The Legacy Wrapper pattern can be further applied to wrap Service D with a standardized service contract that is in compliance with the design standards used in Service Inventory A.
• C.The Event-Driven Messaging pattern can be applied to establish a subscriber-publisher relationship between Service Consumer A and Service A. This gives Service A the flexibility to provide its response to Service Consumer A whenever it is able to collect the three data values without having to require that Service Consumer A remain stateful. The Asynchronous Queuing pattern can be applied to position a central messaging queue between Service A and Service B and between Service A and Service C. The Data Model Transformation and Protocol Bridging patterns can be applied to enable communication between Service A and Service B and between Service A and Service C. The Redundant Implementation pattern can be applied so that a copy of Service D is brought in-house and made part of Service Inventory A.
• D.The Asynchronous Queuing pattern can be applied to position a message queue between Service A and Service B, between Service A and Service C, and between Service A and Service D. Additionally, a separate messaging queue is positioned between Service A and Service Consumer A. The Data Model Transformation and Protocol Bridging patterns can be applied to enable communication between Service A and Service B, between Service A and Service C, and between Service A and Service D. The Redundant Implementation pattern can be applied so that a copy of Service D is brought in-house. The Legacy Wrapper pattern can be further applied to wrap Service D with a standardized service contract that is in compliance with the design standards used in Service Inventory B.

Refer to Exhibit.

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 with any design standards. Therefore, each of these services has a different data model for representing invoice data.
Currently, each of these three services has a different 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.) Assuming that the Invoice service, InvProc service and Proclnv service are part of the same service inventory, what steps would be required to fully apply the Official Endpoint pattern?

• A.One of the invoice-related services needs to be chosen as the official service providing invoice data access capabilities and logic from the other two services needs to be moved to execute within the context of the official Invoice service. Service Consumers A, B, and C then need to be redesigned to only access the chosen invoice-related service. Service Consumer D also needs to be redesigned to not access the shared accounting database directly, but to also perform its data access by interacting with the official invoice-related service. The Service Abstraction principle can be further applied to hide the existence of the shared accounting database and other implementation details from current and future service consumers.
• B.One of the invoice-related services needs to be chosen as the official service providing invoice data access capabilities. Because Service Consumer D does not rely on an invoice-related service, it is not affected by the Official Endpoint pattern and can continue to access the accounting database directly. The Service Loose Coupling principle can be further applied to decouple Service Consumers A, B, and C from the shared accounting database and other implementation details.
• C.Because Service Consumers A, B, and C are already carrying out their data access via published contracts, they are not affected by the Official Endpoint pattern. Service Consumer D needs to be redesigned so that it does not access the shared accounting database directly, but instead performs its data access by interacting with the official invoice-related service. The Service Abstraction principle can be further applied to hide the existence of the shared accounting database and other implementation details from current and future service consumers.
• D.One of the invoice-related services needs to be chosen as the official service providing invoice data access capabilities. Service Consumers A, B, and C then need to be redesigned to only access the chosen invoice-related service. Because Service Consumer D does not rely on an invoice-related service, it is not affected by the Official Endpoint pattern and can continue to access the accounting database directly. The Service Abstraction principle can be further applied to hide the existence of the shared accounting database and other implementation details from current and future service consumers.