S90.09 試験問題を無料オンラインアクセス
| 試験コード: | S90.09 |
| 試験名称: | SOA Design & Architecture Lab |
| 認定資格: | SOA |
| 無料問題数: | 40 |
| 更新日: | 2026-09-11 |
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 text 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 a task service that completes an entire business task on its own without having
to compose other services. However, you have received many complaints about the
reliability of Service A . Specifically, it has three problems. First, when Component B
accesses Database A, it may not receive a response for several minutes when the
database is being accessed by other applications in the IT enterprise. Secondly, the legacy
system accessed by Component C frequently crashes and therefore becomes unavailable
for extended periods of time. Third, for Component D to respond to Component A, it must
first wait for the batch import of the files to occur. This can take several minutes during
which Service Consumer A remains stateful and consumes excessive memory. What steps
can be taken to address these three problems?
Service A sends a message to Service B (1). After Service B writes the message contents
to Database A (2) it issues a response message back to Service A (3). Service A then
sends a message to Service C (4). Upon receiving this message, Service C sends a
message to Service D (5), which then writes the message contents to Database B (6) and
issues a response message back to Service C (7).
Service A and Service D are in Service Inventory A.
Service B and Service C are in Service Inventory B.
You are told that in this service composition architecture, all four services are exchanging
invoice-related data in an XML format. However, the services in Service Inventory A are
standardized to use a different XML schema for invoice data than the services in Service
Inventory B.
Also, Database A can only accept data in the Comma Separated Value (CSV)
format and therefore cannot accept XML formatted data. Database B only accepts XML
formatted data. However, it is a legacy database that uses a proprietary XML schema to
represent invoice data that is different from the XML schema used by services in Service
Inventory A or Service Inventory B.
What steps can be taken to enable the planned data exchange between these four services?
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.
Before the message arrives with Service A, it is intercepted by Service Agent A (1). which checks the message for
compliance to Policy A that is required by Service A.
If the message fails compliance, Service Agent A will not allow it to proceed and will instead write the message contents to a
log. If the message does comply to the policy, it continues to be transmitted toward Service
A, but before it arrives it is intercepted by Service Agent B (2), which validates the security
credentials in the message header. If the security credential validation fails, the message is
rejected and a runtime exception is raised. If the security credentials are validated, the
message is sent to Service A.
Upon receiving the message, Service A retrieves a data value from a database and
populates the message header with this data value (3) prior to forwarding the message to
Service B.
Before the message arrives at Service B.
it is intercepted by Service Agent C (4) which checks the message for compliance with two policies: Policy B and Policy C.
Policy
B is identical to Policy A that was checked by Service Agent A.
To check for compliance to Policy C.
Service Agent C uses the data value added by Service A.
If the message complies with both of the policies, it is forwarded to Service B (5), which stores the message contents in its own database.
You are told that Policy B and Policy C have changed. Also, in order to carry out the
compliance check of Policy C, Service Agent C will now require a new data value from the
Service B database. How can this service composition architecture be changed to fulfill
these new requirements?
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?