5分で絶対に分かるSOA：5分で絶対に分かる（4/7 ページ）

[吉村哲樹，＠IT]

3分 − 汎用部品を柔軟に組み合わせる

　もう1度、先ほどの例に戻ってみましょう。在庫照会機能が、受注システムから簡単に再利用できるようになっていれば、問題はなかったはずです。

　しかし前節で説明したとおり、在庫照会機能は在庫管理システムの内部でしか使用されることを想定していません。いってみれば、そのシステムにとっての「専用部品」です。従って、処理の呼び出し方やデータ受け渡しの方法などは、そのシステムの中でしか通用しないものになっています。いわば、親しい仲間内での約束事のようなものです。

　このように、狭い閉鎖的な世界で密接に結び付いている形態を「密結合」（みつけつごう）と呼びます。

　しかし、ここでは在庫照会機能を特定システムの「専用部品」ではなく、さまざまなシステムから使用可能な「汎用部品」にしたいのです。仲間内だけではなく、他人からの要求にも応じられるようにしておく必要があります。

　たとえていうなら、いままでは親しい身内の間でだけこっそり開いていたお店の看板を、往来に堂々と掲げるようなものです。お店を公開した以上、いつ、どんなお客さんが来店するか分かりません。従っていままでとは違い、あらかじめ取引の手順を示しておく必要があります。例えば飲食店であれば、メニューで値段を確認し、店員に注文し、食事が終わった後にレジで現金またはカードで支払いを行う、といった具合です。仲間内だけにお店を開いていたときは当たり前だった時価やツケ払い、一見さんお断りは、もう通用しません。

　お客さんの側から見ると、こうした取引の手順さえ分かっていれば、誰でもそのお店で食事をすることができます。それ以上のことを知る必要はありません。お店のオーナーが誰なのか、厨房で誰がどのように調理をしているのか、食材がどこから仕入れられてどこに保管されているのか……、そういったことはまったく知らなくても、料理を注文して食事をすることができます。

　お店を公開する前と比べると、1人1人のお客さんとの関係は疎遠になりましたが、その分不特定多数のお客さんに対しては間口が広がったわけです。

　同じく在庫照会機能の処理も、どこで、どのようなデータを、どんな手順でやりとりすればよいか、という約束事を外部に公開しておきます。この約束事のことを、インターフェイスと呼びます。このインターフェイス（例： 照会したい商品の品番を整数値で渡して、在庫数を文字列で受け取る）に従えば、誰でも在庫照会機能を利用できるようにします。利用する側は、在庫照会機能の中でどんな処理が行われているのかを知る必要はありません。インターフェイスさえ分かっていればよいのです。

　このように、お互いの依存度が低い緩やかな結び付きの形態を「疎結合」と呼びます。

　在庫照会機能を疎結合の形で作っておけば、受注システムだけではなく、あらゆるシステムから利用できるようになります。これなら、最小の手間とコストで受注業務に在庫照会を追加できそうです。さらに、もしほかの業務で在庫照会が新たに必要になったとしても、比較的容易に対応できそうです。

　さらに考えを進めると、在庫照会機能だけでなく、ほかの機能もすべて同じように疎結合による汎用部品として作っておけば、それらの機能がほかで必要になったときに、大変便利ではないでしょうか。これがまさに、SOAの考え方なのです。