平成25年度春期 データベーススペシャリスト 午前Ⅱ 問25

与えられた条件と前提を区別する

サービス設計について考える際は、与えられた条件と、自分が補っている前提を区別しましょう。知っている用語から結論を急がず、判断の根拠が与えられた情報にあるかを確かめることに集中します。

この問題で問われていること

検討の焦点は、判断に使う前提の出所です。考えを進める途中で、明示された条件に基づいているのか、自分の経験や記憶で条件を足しているのかを振り返り、根拠と推測が混ざっていないか確認しましょう。

視点

前提とは、考えを進めるときに土台としている条件です。明示された情報と、自分が補った想定を分けて整理すると、どこまでが根拠に支えられた考えなのかを見直せます。

確認ポイント

• 判断の土台にした条件を把握できているか
• その条件がどの情報に基づくか確かめたか
• 自分で補った想定を明示された条件と区別したか

正解

ウ

解説

正解はウです。SOAでは業務機能をサービスとして分割し、組み合わせて利用します。サービス間を疎結合にして依存を抑えると、変更の影響を限定でき、業務の変化に対応しやすくなります。

理由

ウの疎結合とは、サービス同士が相手の内部実装に強く依存しない関係です。公開されたインタフェースを保ち、その契約に従って変更すれば、あるサービスの内部処理を変えても他のサービスへの影響を抑えられます。そのため、業務の変化に応じてサービスを変更したり、組合せを見直したりしやすくなります。

比較

アのステートフルな設計では、障害時の切替えや実行先の追加に状態の引継ぎ・共有が必要となり、可用性の確保が難しくなる場合があります。イは、業務からの独立性を目的としている点が誤りです。SOAのサービスは業務の単位に合わせて設計し、業務上の役割が分かる名前を付けるのが基本です。エは、SOAが重視する再利用性に反し、再利用を避けること自体はセキュリティ向上の根拠にもなりません。安全性は認証・認可や通信の保護などで確保します。

選択肢ア

これは不正解だよ。ステートフルなインタフェースでは、利用者とのやり取りの状態をサービス側で保持します。障害時に別の実行先へ切り替えるには状態の引継ぎが必要となり、負荷に応じて実行先を増やすことも難しくなります。そのため、ステートフルにすれば可用性が高まるとはいえません。

選択肢イ

これは不正解だよ。SOAでは、業務の単位に合わせてサービスを設計し、その業務上の役割が分かる名前を付けるのが基本です。役割を表す命名は適切ですが、その目的を「業務からの独立性を確保するため」としている点が誤りです。サービスは業務機能を表すものであり、業務との対応を切り離すことを目指しません。

選択肢ウ（正解）

これは正解だよ。サービス間を疎結合にすると、互いの内部実装への依存を抑えられます。共通のインタフェースを保てば、一つのサービスの処理内容を変更しても、他のサービスへの影響を限定できます。そのため、業務の変化に応じたサービスの変更や組合せの見直しを行いやすくなります。

選択肢エ

これは不正解だよ。SOAでは、開発したサービスを複数の業務やシステムで再利用し、重複開発を減らすことを重視します。再利用しないこと自体に、セキュリティを高める根拠はありません。安全性は、サービスの再利用を避けることでなく、認証・認可や通信の保護などで確保します。

学習のポイント

疎結合が変更への対応を容易にする理由と、状態保持・業務との対応・再利用に関する設計上の考え方を理解しましょう。