レベル: 初級 米持 幸寿, テクノロジー・エバンジェリスト, IBM
2005年 9月 09日 SOAの定義が曖昧な原因は、SOAの説明に使われる言葉の定義がなにからなにまで曖昧なことです。今回は疎結合という言葉の定義について考えましょう。
結合とはなんでしょう？
「SOAのサービスは疎結合技術でつなぐのがいい」とよく言われます。疎結合という言葉が流行し始めたのは、Webサービスの登場からです。Webサービスは、疎結合の代表作のように、疎結合という言葉を使うようになりました。しかし、多くのEAI技術も疎結合を謳う（うたう）ようになって久しく経ちます。
疎結合という言葉はとても曖昧な言葉です。結合が密でないということになりますが、そもそも密な結合とは何なのか定義がありません。その前に「結合」とはなにか、ということさえも定義がありません。
結合とはなにか？
プログラマブル・コンピューター初期には、ソフトウェアはひとつのソースコードとして開発されました。しかし、ポインターの限界やら、メモリー空間の制限やらで、ソフトウェアは分けて作る技術が発展しました。分けて作るためには、ソフトウェアを結合する技術が必要となります。これが結合技術です。ソースコード上、ひとつにみえるものを別々にコンパイルしたり、別々にロードしたり、別のコンピューターに搭載したりするために、ソフトウェアを結合するのがソフトウェア結合です。
前回、サービスとコンシューマーを結合する方法を「ソフトウェアの連携」と「ソフトウェアの結合」の二通りとして説明しました。筆者は、「ソフトウェアの連携」は結合されていない状態だと思います。「ものすごく疎」といえないこともないですが、どちらかといえば、非結合連携だと思います。そのようなソフトウェア連携の技術は、どちらかと言えば、「システム結合」といえます。システムは結合されていますが、ソフトウェアは結合されたといえないでしょう。
結合しないソフトウェア
少し例を挙げて説明しましょう。ソースコード1を見て下さい。
ソースコード1 結合されない二つのソースコード
// ここで画面からの入力処理
// ここで送信データの組み立て
// ここで送信
// ここで結果を受信
// ここで画面への出力処理 | // データの受信待機処理
// データを受信して読み取り
// 検索処理
// 返信データの組み立て
// 返信データの送信 |
この二つのソースコードは、なんらかの「ソフトウェア結合技術」を使わなくても連動して動作します。なぜならそもそも分離していることを前提に作られているからです。
この二つのソフトウェアを連動させるために使うのはソフトウェア結合技術ではなく、システム結合技術やネットワーク技術です。MQのようなメッセージ指向ミドルウェア、レガシーなEDI技術、TCPIPなどに直接アクセスするクライアント&サーバー通信、ファイル転送などがこれにあたります。
このようなしくみではソフトウェアは結合されていないわけですから、とても疎結合です。究極の疎結合という人もいますが、結合されてないのです。疎遠と他人は違うということです。多くの場合、ソフトウェアの言語、プラットフォーム、技術への依存性はとても小さいといえます。ただし、ソフトウェア結合をしない、つまり結合技術を使わない（あるいは使えない）分、開発に時間がかかってしまう、というデメリットがあります。
また、中に入れられるデータの型は、意識的にやらないかぎり独自のフォーマットとなります。独立して開発されたサーバーコードとクライアントコードのほとんどは接続できないでしょう。
結合されるソフトウェア
ソフトウェアの結合は、文字どおりソフトウェアそのものがくっついたことになることを意味しています。たとえば、ソースコード2を見てください。
ソースコード2 結合される二つのソースコード
// ここで画面からの入力処理
Result r = search(searchrequest);
// ここで画面への出力処理 | public Result search(SearchRequest sr) {
// ここで検索処理
return result;
} |
この二つのソースコードでは、左側のプログラムコードが右側のプログラムコードを呼び出しています。この二つのソフトウェアはなんらかの方法で結合されなければ動作しません。もし左がわのプログラムと右側のプログラムが別々のマシンにロードされるとしたら、これらのソフトウェアを遠隔結合する方法があって、はじめて動作します。ここではそういう結合方式を「ソフトウェア結合方式」と総称しましょう。
このようなソフトウェアを結合する技術は古くから存在しましたが、多くの場合、二つのソフトウェアは同じ言語、同じプラットフォーム、同じ技術の上になりたっていることを前提にしていました。CORBAは、混在環境をめざした技術でしたが、最近ではトランザクション技術はEJBに、混在技術はWebサービスにその座を譲ったといえます。
ソフトウェア結合方式を使う最大のメリットは結合の簡単さです。どういうしかけでソフトウェアが結合されるかを、その仕掛けを利用するプログラマは知る必要がありません。もちろん、知っていたほうがいいですが、知らなくても使えます。このため、ソフトウェアの結合のためのコストは非常に小さくなり、開発期間も小さく抑えられます。
混在環境に対応した技術が発展すれば、この二つのコードは簡単に接続できます。
ソースコード1のように結合するためのプログラムコードを手で書くのであったら（コーディングするのであったら、という意味）、それは結合されないから結合コードが必要なのです。
ところで、ソフトウェア結合技術が長い間悩んでいたことがあります。それは、混在環境への対応が難しいことです。
コンピューター・システムはどんどん多ベンダー化していきます。コンピューター・プラットフォームは増殖し、様々な種類のソフトウェアが乱立し、ソフトウェア結合方式のほとんどが相互連携に利用できません。相互接続を目標にしたCORBAでさえ、その目標の多くを達成できませんでした。
このため、異機種間接続のシステムでは、ソフトウェア結合を行うことをあきらめ、結合しない方式を選択してきました。これが、EAI、EDI、ファイル転送といったシステム連携の仕組みです。ところが、こちらは開発に時間がかかるというデメリットも持ち合わせました。
結合の壁を取り払うのがSOAソフトウェア構造の目標
ごりごり書かない
SOAアプリケーションは、システムの柔軟性を最大限に活かそうという大きな目標があります。このため、結合コードをごりごり手でコーディングしてはいけません。それでは、柔軟性が大きく失われてしまいます。それでは旧来のEAIとなにもかわりません。
SOAシステム上では、SOAのサービスを結合する環境をSOA基盤が提供することに意義があります。サービスの実装や、サービスを利用するアプリケーションを設計したりプログラミングするアプリケーション開発者には、そのしかけや受け渡しメッセージの詳細な並び方を理解する必要がないようにすべきです。実装者は、データの型と名前にのみ注目して開発できることが望ましいのです。
なにでできたコードを呼ぶか、どうやって呼ぶかを意識させない
今日のSOA基盤では、混在環境を実現していくことも重要です。SOAソフトウェア構造は、CORBAやEJBなどの単一技術だけでも実現できるかもしれません。しかし、それでは今日のIT環境に追随できません。プログラミング言語、ネットワーク技術、ミドルウェアなどのプラットフォーム、OS、ハードウェアなどが混在してもSOAソフトウェア構造を実現し、相互接続できることが望まれています。Webサービスは、これを解決するための切り札と考えられています。ESBは、いろいろな結合方式を混在で使う場合には良い基盤となります。（ESBに関しては別の回に解説します。）
分散と連携を統合してSOAを
重要なのは、結合方法（バインディング）が結合直前まで決まってなくても結合できることを実現することです。これを行うためには、分散オブジェクトがもつスタブ（プロキシー）生成技術に、EAIやEDIなどの連携技術のような技術非依存の性質を併せ持つ必要があります。
SOAシステムを構成するSOAソフトウェア構造を実現するためには、結合コードをアプリケーション開発者に書かせず、プログラミング言語やプラットフォームが混在環境でも利用できる技術を採用しなければいけません。
分散オブジェクトなどが持っていたスタブ／プロキシーの生成技術と、EAIやEDIが持っていたプラットフォーム非依存の特性を併せて使い、SOAソフトウェア構造を作ることでSOAのメリットが最大限に発揮できるはずです。
次回はインターフェースを解説します。
著者について  | | | 1987年に日本アイ・ビー・エム入社。メインフレームOS、ミドルウェアの障害対応、障害解析ソフトウェアの開発、ワークフローシステム開発、オブジェクト指向開発、Web開発など経験。2000年より、ソフトウェアのテクノロジーエバンジェリストとして活動中。 |
記事の評価
| 
