サービス指向アーキテクチャ
業務機能を独立したサービスとして提供し、それらを組み合わせてシステムを構築する考え方。呼出し側が内部実装に依存しすぎないよう、機能と利用条件を明確にする。
イマシルちゃんの解説
旅行の準備なら、乗り物の手配も宿の予約も必要だよね。
全部を一つのお店で最初から作る代わりに、それぞれ得意な窓口へ頼むんだ。
窓口への頼み方が決まっていれば、中の仕事の進め方まで知らなくていい。
必要な窓口をつなぐと、一つの旅行の手続きにできるんだよ。
より深い解説
業務の機能を境界にする
サービス指向アーキテクチャはSOAと略される。受注、在庫確認、決済など、業務上の意味をもつ機能を独立したサービスとして提供する。
利用者は、どの入力を渡すと、何が実行され、どの結果が返るかを知ればよい。提供者の内部のプログラミング言語やデータ構造をすべて知る必要はない。このように実装への依存を抑える性質を疎結合という。
利用の約束を明確にする
| 定める項目 | 例 |
|---|---|
| 入出力 | 商品番号と数量を受け取り、在庫の有無を返す |
| 処理の意味 | 在庫を確認するだけか、取り置きまで行うか |
| 失敗時の扱い | 品切れや通信断をどのように通知するか |
| 利用条件 | 本人確認、応答時間、呼出し回数の制約 |
同じ形式のデータを送れても、処理の意味が違えば連携は成立しない。構文だけでなく、業務上の契約を共有することが重要である。
既存の機能を活用する
既存の在庫確認や決済機能を再利用すれば、販売経路が増えたときにも共通部分を作り直す負担を減らせる。ただし、共通化した機能に障害が起きると、複数の業務に影響する。
| 利点 | 注意点 |
|---|---|
| 機能を組み合わせて新しい業務を構成できる | 呼出しが増えると通信遅延や部分的な失敗が発生する |
| 内部の変更を境界内に収めやすい | 公開したインタフェースの互換性を保つ必要がある |
| 共通の業務ルールを集約できる | 提供者と利用者の責任範囲を定める必要がある |
たとえば決済が成功し、在庫確保が失敗したときには、取消しなどの業務上の後始末を設計する。単にネットワークで呼び出せるようにしただけでは、処理全体の整合性は保証されない。
関連する用語との区別
| 用語 | 役割 |
|---|---|
| サービス指向アーキテクチャ | システムを構成する設計思想 |
| SOAP | メッセージを交換するためのプロトコル |
| WSDL | 呼出しのインタフェースなどを記述する仕様 |
| UDDI | 提供先の情報を登録・検索する仕様 |
| SLA | 提供内容や品質についての合意 |
SOAPやUDDIは実現手段の一つであり、必須の組合せではない。HTTPを使うWeb APIなどで実装することもできる。
なお、DNSのSOAレコードのSOAはStart of Authorityの略であり、本記事の設計思想とは別の用語である。
状態をどこに持つか
サービスを呼ぶたびに必要な情報を渡し、特定の処理サーバに利用者の会話状態を抱え込ませない設計にすると、別のサーバへ振り分けやすくなる。状態を持つ設計が常に誤りというわけではないが、可用性を高める際には、障害時に状態をどう引き継ぐかを考える必要がある。
また、サービス名やインタフェースは、その機能が果たす業務上の役割を理解できる形にする。業務の意味をなくすことが疎結合なのではなく、意味のある境界を保ちながら、相手の内部実装への依存を減らすことが重要である。再利用する際の安全性は、認証や権限、入力の検証などによって確保する。