本番の雰囲気に慣れておくことは、当日の実力発揮につながります。2026年のS90.09試験に向けて、GoShikenのテストエンジンは制限時間付きの模擬試験モードを備え、SOA Design & Architecture Labの出題形式を繰り返し体験できます。

SOA S90.09 試験概要:

SOA S90.09 試験シラバストピック:

S90.09受験者からよく寄せられる質問

SOA Design & Architecture Lab 認定 S90.09 試験問題：

問題 #1

It has been confirmed that Policy A and Policy B are, in fact, the same policy and that the
security credential check performed by Service Agent B also needs to be carried out on
messages sent to Service B .

How can this service composition architecture be changed to reduce the redundancy of
policy content and fulfill the new security requirement?

A. The Policy Centralization pattern can be applied so that Policy A and Policy B are
combined into the same policy. The policy enforcement logic is removed from Service
Agent C and Service Agent A is then used to enforce the policy for messages sent to
Service A and Service B . Service Agent B can be used to perform the security credential
check for Service A and Service B .
B. The Policy Centralization pattern can be applied so that Service Agent A is changed to
enforce the policy for messages sent to Service A and Service B and to perform the
security credential check for Service A and Service B .
C. The Policy Centralization pattern can be applied so that Policy A and Policy B are
combined into the same policy. The Service Agent pattern is then applied to introduce a
new service agent (called Service Agent D) which carries out the validation and
enforcement of Policy A and Policy B.
Service Agent B can be moved so that it performs
the security credential check for Service B, but not for Service A .
D. None of the above.

問題 #2

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. 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.
B. None of the above.
C. 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.
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.

問題 #3

Service A is an orchestrated task service that is invoked by a separate composition initiator
(1) and then sends a request message to Service C (2). Service C queries Database B to
retrieve a large data record (3) and provides this data in a response message that is sent
back to Service A.
Service A temporarily stores this data in a central state database (4) and
then sends a request message to Service D (5), which accesses a legacy system API to
retrieve a data value (6). Service D then sends this data value in a response message back
to Service A.
The data in the state database is subsequently retrieved by Service A (7) and
merged with the newly received data value. This combined data is written to Database A
(8), which triggers an event that results in the invocation of Service B (9).
Service B is an orchestrated task service that sends a request message to Service D (10).
which accesses a legacy system API to retrieve a data value (11) and then sends this data
value in a response message back to Service B.
Service B temporarily stores this data in a
central state database (12) and then sends a request message to Service E (13), which
performs a runtime calculation and then responds with the calculated data value back to
Service B.
The data in the state database is then retrieved by Service B (14) and merged
with the calculated data value. Service B then uses the merged data to complete its
business task.
The following specific problems and requirements exist:
* Database B uses a proprietary data format that is not compliant with the XML
format used by all of the services in this service composition architecture This
incompatibility needs to be solved in order to enable the described service
message exchanges.
* The service contract provided by Service D does not comply with the data model
standards that were applied to the other services and therefore uses a different
data model to represent the same type of data that is exchanged. This
incompatibility needs to be solved in order to enable communication with Service
D.
* Database B is a shared database that can be accessed by other services and
applications within the IT enterprise, which causes unpredictable runtime
performance. This performance problem needs to be solved in order to make the
runtime behavior of Service C more predictable.
* For performance and maintenance reasons, Service A and Service B need to be
deployed in the same physical environment where they can share a common state
database.

Upon reviewing these requirements it becomes evident to you that the Enterprise Service
Bus compound pattern will need to be applied. However, there are additional requirements
that need to be fulfilled. To build this service composition architecture, which patterns that
is not associated with the Enterprise Service Bus compound pattern need to also be
applied? (Be sure to choose only those patterns that relate directly to the requirements
described above. Patterns associated with the Enterprise Service Bus compound pattern
include both the required or core patterns that are part of the basic compound pattern and
the optional patterns that can extend the basic compound pattern.)

A. Atomic Service Transaction
B. Data Format Transformation
C. Process Centralization
D. State Repository
E. Redundant Implementation
F. Policy Centralization
G. Reliable Messaging
H. Protocol Bridging
I. Intermediate Routing
J. Service Data Replication
K. Data Model Transformation
L. Event-Driven Messaging
M. Compensating Service Transaction

問題 #4

Service A is a task service that is required to carry out a series of updates to a set of
databases in order to complete a task. To perform the database updates Service A must
interact with three other services, each of which provides standardized data access
capabilities.
Service A sends its first update request message to Service B (1), which then responds
with a message containing a success or failure code (2). Service A then sends its second
update request message to Service C (3), which also responds with a message containing
a success or failure code (4). Finally, Service A sends a request message to Service D (5),
which responds with its own message containing a success or failure code (6).

You've been given a requirement that all database updates must either be completed
successfully or not at all. This means that if any of the three response messages received
by Service A contain a failure code, all of the updates carried out until that point must be
reversed. Note that if Service A does not receive a response message back from Services
B, C, or D, it must assume that a failure has occurred. How can this service composition
architecture be changed to fulfill these requirements?

A. The Reliable Messaging pattern can be applied to guarantee the delivery of positive or
negative acknowledgements. This way, Service A will always be informed of whether a
failure condition has occurred with any of the database updates performed by Services B,
C, and D.
Furthermore, the Service Loose Coupling principle can be applied to ensure that
the request and response messages exchanged by the services do not contain any
implementation details that would indirectly couple Service A to any of the databases.
B. The Atomic Service Transaction pattern can be applied individually to Services B, C,
and D so that each of these services performs its own database update within the scope of
an atomic transaction. If anyone update fails, that change can be rolled back on that
database. Furthermore, the Service Loose Coupling principle can be applied to ensure that
Service A is kept out of the scope of the atomic transaction so that it is not negatively
coupled to the proprietary database technologies that are required to enable the atomic
transaction functionality.
C. The Compensating Service Transaction can be applied to Service A so that when any
one response message containing a failure code is received by Service A, it can invoke
exception handling logic that will log the failed database updates. The Service Loose
Coupling principle can be further applied to ensure that Services B, C, or D are not
indirectly coupled to the exception handling logic, especially if Service A requires additional
access to Services B, C, or D in order to collect more information for logging purposes.
D. None of the above.

解説：