SOAのメッセージを一言で言えば、「エンティティからサービスへ」ということだと思う。
たとえば、商品情報を管理するシステムがあったとしよう。このシステムは、いくつかのサブシステムで成り立っているはずだ。マスタを管理し、在庫を管理し、発注して、納品して、売上を立てる。これまでのアプローチは、すべてのサブシステムを統合するために、どういうエンティティを作るべきかであった。たとえば、在庫の構造はどうなっているべきかというのは、すべてのサブシステムにおいて大きな関心事だ。
しかし、SOAは、そんなことは言わない。
サブシステムごとに、在庫にどういう情報を与えるのか、どういう情報が欲しいのかというインターフェースだけを規定すればよいのだ。在庫のエンティティが、どう管理されているのかなんて、どのサブシステムも知る必要性はない。ただ、商品Aの本日付の確定在庫が欲しい、とか、商品Bの明日付けの予定在庫が欲しいとか、そういうインターフェースだけを要求すればよい。逆に、商品Bが発注されたから、3日後に在庫が10個増えるはずとか、商品Bが納品されたから在庫を10個増やしてよいとか、そういう情報を与えるだけでよい。
人間が理解でいる範囲なんて限定されている。であればこそ、サブシステムでは、小部屋で閉じた話をすればよい。そして、すべてのサブシステムで円卓につくときは、お互いにどんなインターフェースで情報が欲しいかだけを議論する。
SOAだと、パフォーマンスが気になるだろうか。たしかに、そうかもしれない。しかし、考えてみて欲しい。きちんとインタフェースが決まっていれば、誰が遅いのかは一目瞭然である。パフォーマンスの向上は、パフォーマンス戦略が明確であれば、それほど怖いことはない。そもそも、パフォーマンスは、お金で買える。時間がたてば安くなる。でも、ビジネスロジックの分かりやすいさは、お金で買えない。どうやっても買えない。であれば、パフォーマンスのプライオリティは、2番目でよいはずなのだ。
こう考えると、SOAが目指しているのは、非常に現実的なことだと感じられないだろうか。昔から、こういったことをちゃんとやっていたシステムは、いくらでもあるはずである。
これまでと違うのは、インターフェースのやり取りに共通のプロトコルが用意されていたり、やり取りのキュー管理を行う専門のツールがあったり。だから、特定システム内だけでなく、企業内、企業間で情報のやり取りが可能になるということに過ぎない。
まずは、統合という言葉にだまされないことだ。SOAの統合は、詳細はわからないままで、いかに関係性を保つのかということだ。「エンティティからサービスへ」。SOAとは、分かりやすいことなのだと認識して欲しい。
