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

Refer to Exhibit.

Service A is a SOAP-based Web service with a functional context dedicated to invoice-related processing. Service B is a REST-based utility service that provides generic data access to a database.
In this service composition architecture, Service Consumer A sends a SOAP message containing an invoice XML document to Service A (1). Service A then sends the invoice XML document to Service B (2), which then writes the invoice document to a database (3).
The data model used by Service Consumer A to represent the invoice document is based on XML Schema A.
The service contract of Service A is designed to accept invoice documents based on XML Schema B. The service contract for Service B is designed to accept invoice documents based on XML Schema A. The database to which Service B needs to write the invoice record only accepts entire business documents in a proprietary Comma Separated Value (CSV) format.
Due to the incompatibility of the XML schemas used by the services, the sending of the invoice document from Service Consumer A through to Service B cannot be accomplished using the services as they currently exist. Assuming that the Contract Centralization pattern is being applied and that the Logic Centralization pattern is not being applied, what steps can be taken to enable the sending of the invoice document from Service Consumer A to the database without adding logic that will increase the runtime performance requirements?

• A.The service composition can be redesigned so that Service Consumer A sends the invoice document directly to Service B.
  Because Service Consumer A and Service B use XML Schema A, the need for transformation logic is avoided. This naturally applies the Logic Centralization pattern because Service Consumer A is not required to send the invoice document In a format that is compliant with the database used by Service B.
• B.The service composition can be redesigned so that Service Consumer A sends the invoice document directly to Service B after the specialized invoice processing logic from Service A is copied to Service B.
  Because Service Consumer A and Service B use XML Schema A, the need for transformation logic is avoided. This naturally applies the Service Loose Coupling principle because Service Consumer A is not required to send the invoice document In a format that is compliant with the database used by Service B.
• C.Service Consumer A can be redesigned to write the invoice document directly to the database. This reduces performance requirements by avoiding the involvement of Service A and Service B.
  It further supports the application of the Service Loose Coupling principle by ensuring that Service Consumer A contains data access logic that couples it directly to the database.
• D.Service Consumer A can be redesigned to use XML Schema B so that the SOAP message it sends is compliant with the service contract of Service A.
  The Data Model Transformation pattern can then be applied to transform the SOAP message sent by Service A so that it conforms to the XML Schema A used by Service B. The Standardized Service Contract principle must then be applied to Service B and Service Consumer A so that the invoice XML document is optimized to avoid unnecessary validation.

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 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.
• 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 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.

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 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.
• B.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.
• 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.