The Social Side of Services／サービスの社会的な側面

SOAの成功のために

   先日、私が目にしたあるWebサイトの記事によると、7社に1社はサービス指向アーキテクチャ（SOA）の試みが失敗しているということでした。そのとき、この調査の詳細と正当性について次のような疑問点が浮かびました。

   IT開発者にとってSOAの導入がプロジェクトを成功に導いているかどうかは関心の高いところです。つまり、単にサービス指向的なアプローチを採用しただけでは、プロジェクトが成功することを保証できないことは皆さんもご存知でしょう。

   仮に、SOAの導入に際して直面する技術的な問題を事前に十分に把握していても、プロジェクトが必ず成功する保証はありません。特に技術者はプロ ジェクトが成功するか失敗するかは、単にその背後にあるテクノロジーがうまく動くかどうかが重要であると思いこむ傾向があるからです。技術面以外の要因 は、実は技術者が考えているよりもずっと大きな影響をプロジェクトの成否に与えるものなのです。

サービスを集める

   「サービス指向」の考え方について議論することは容易ではありません。なぜなら、ITの基盤として包含関係（エンキャプスレーション）、情報隠蔽 （インフォメーション・ハイディング）、インターフェースと実装の分離、低い結合度、高い透過性など、表向きではあまり必要とされない要素を表立って提案 ／議論しなければならないからです。

   そういったこともあり、SOAの導入では、企業がその必要性を納得することが難しいと言われています。

   ネットワークが企業全体や組織の中で利用されてきたように、サービス指向がITの問題を解決するために必要なアプローチだと理解されつつあるように 思います。ただし、SOAの成功は、サービス指向から生まれたサービスのクリティカルマス（一定以上の意味のある数量）に依存します。

   サービスの数がこのクリティカルマスに達して、さらに、維持運用していくために必要な技術的な基準は次のようなものになります。

   ここで「サービスの生成」との関連を無視していると、SOAに関する議論はたいてい失敗します。サービスは互いに連携するものであり、生成された新 しいサービスをその中へ組み込むときに、この連携のメカニズムをサポートする最新のレジストリが必要となるからです。

   私はこの数年間、いくつもの洗練されたレジストリ製品の計画や提案を目にしてきました。それらは拡張可能なサービスのプロパティをすべて登録して参 照する機能を持っているもの、設計時に要求されたすべての機能を有したものもありました。また、中には非常に複雑で、誰もこれらの機能を利用するユーザを 考えられないようなものもありました。

   サービス指向システムでは、アプリケーションが直接名前を指定して検索するようなシンプルなサービスレジストリを使っているケースが多くあります。 将来的には今のようにサービスそのものが、直接レジストリを参照してネットワークを構築するのではなく、SOAの基盤として展開することで導入／実行／レ ジストリへの登録の一連の操作の結果としてサービスがスムーズに連携できることが課題です。

   もしSOAを、さらに展開し続けるであれば、これらを利用する人間の立場で考えて運用していかなければなりません。人間が直接テクノロジーを意識しているようでは、SOA環境が、様々な異なるテクノロジーをサポートするようなことはできないでしょう。