SOAで利用されるパターン２つ
前回、システム分析アプローチについて記述しましたが、 これにひき続いてSOAの中でもよく使われるパターンが有るなって思ったので追記です。
SOAは元がオブジェクト指向設計（OOA／OOD）であることから、ソフトウェア開発のデザインパターンを適応できそうだな～って前々から思っていたので、ちょっとだけ描いてみます。
その① Facade型
インタフェースに用意された機能が複数のサービスを呼び出し、一連の業務を遂行するパターンです。
例えば、「販売」みたいな機能があった場合、「在庫引当」サービスと「会計計上」サービスを呼び出すみたいな感じ。
一人の事務員が一連の事務手続きを行う姿に似てます。
ユーザからはサービスが隠蔽されますので、サービス内容や利用するサービスの種類が変わったとしてもインタフェースで差異を吸収できる形となります。
反面、インタフェースとサービスとの間のつながりがN:N構造となっており、複雑度が高い関係となっており、保守性がその分低下する恐れがあります。
その② Chain of Responsibility型
インタフェースから呼びだされるサービスは最小限なものの、そこから発生されたデータが複数のサービスに連携され業務処理を行うパターン。
例えば、「売上サービス」から、売上データをバスに送出。バスではそれらを複数のサービスに伝播し、引き続き「会計計上」や「在庫引当」を行うといった形となります。
営業マンが売上伝票を作成し、それを複写、会計担当や在庫担当などに渡して、それぞれの担当者が処理をするような感じです。お役所などの窓口業務をイメージしてもらうとわかりやすいと思います。
GoFデザインパターンのChain of Responsibilityに似た処理構造となってます。
インタフェースとサービスとの関係はシンプルとなっており、保守しやすい形となってます。また、バス側の情報伝達は送信側と受信側で疎な関係となっており、例えば新たなサービスを追加して処理を行う場合でも、他のサービスは影響を気にする必要がありません。
反面、処理は原則非同期となるため、複数のサービスが処理を完了させるまでに時間がかかるおそれがあること、同期が必要となる処理の場合、対応ができないなどの問題があります。
まとめ
もうちょっとパターンを分析できそうな気もしましたが、力尽きたのでこのくらいで。
個人的な感想としてオブジェクト指向プログラミングとオブジェクト指向設計アプローチでは、構造などの部分で相似関係を持てそうだなって気がします。
となると、SOAの設計ではOOPでよく使われる技法を応用できそうだなって思ってます。まあ、システムとプログラミングなんで、クラスとインスタンスみたいな関係は持ちづらいですし、全く適応可能かって言うわけではないのですけど。
※システムは基本全て実態ですしね。。
以上
