今回は，企業内のアプリケーション構築の手法として注目を集め始めている「サービス指向アーキテクチャ」について解説しよう。

　前回，説明した「ハブ・アンド・スポーク・アーキテクチャ」は企業内にすでに存在するアプリケーションの設計の多様性を，現実的なやり方でできるだけ解消するためのアーキテクチャであったが，サービス指向アーキテクチャは，どちらかといえば，これから開発する新規アプリケーションにおいて，将来の拡張や変更を容易にするためのアーキテクチャであるといえる。

◆そもそも「サービス」とは何か？

　サービス指向アーキテクチャの基本的考え方は，アプリケーションの中の共通的機能をソフトウエア部品として切り出し，多くのアプリケーションから同時並行的に呼び出して使えるようにしようということであり，何ら新しいものではない。

　しかし，考え方が昔からあるとはいえ，現時点で，全社的なアーキテクチャにおける普及が進んでいるというわけではない。1つのアプリケーションの中で共通機能を共用するのは当たり前だが，複数のアプリケーションをまたがって共用している事例は多いとはいえない。

　また，「サービス指向」という言葉の意味がなかなか理解しにくいという人も多いようだ。これは，サービスという言葉のイメージがあいまいであることが大きな理由だろう。

　実際，ITの世界では「サービス」という言葉は多くの意味で使用されている。コンサルティング，保守，SIなどの人手による労働力の提供によるビジネスもサービスと呼ぶし，OSが提供するシステム機能をサービスと呼ぶこともある。和製英語ではあるが，値引きや無償提供のことをサービスと呼ぶこともあるだろう。

　サービス指向アーキテクチャにおける「サービス」とは，（粒度が比較的粗い）ソフトウエア部品のことである。Webサービスにおける「サービス」も同じ意味と考えてよい。

◆重要なのはブラック・ボックス化

　サービス指向における最も重要な考え方はブラックボックス化である。つまり，データ設計を外部に見せないようにして，あらかじめ定められたインタフェースを通じてのみ処理を行うという考え方である。ブラックボックス化により，ソフトウエアの部品化が促進され，再利用が促進され，全体的な保守性（つまり，変化への対応の俊敏性）が向上する。

　ブラックボックス化の考え方も全く新しいものではなく，オブジェクト指向プログラミングの世界でいわれる情報隠ぺい，抽象化，カプセル化などという考え方と同様である。

　違う点は，サービス指向アーキテクチャにおけるサービスは，オブジェクト指向プログラミングにおけるオブジェクトよりも，はるかに粒度が粗いという点である。例えば，レガシー・アプリケーションをラッピング（付加的なソフトウエアにより，外部から呼び出し可能なインタフェースを設けること）してサービス化した場合には，そのレガシー・アプリケーション全体が1つのソフトウエア部品ということになる。

　なお，サービス指向アーキテクチャにおける「再利用」とは，同じ部品を多くのアプリケーションから共用するという意味の再利用が中心であり，オブジェクト指向プログラミングにおける既存の機能を継承して新しい機能を開発するというような，設計開発時の再利用は主眼ではない。

　アプリケーションをまたがったデータ設計の標準化が困難である（その理由は，このシリーズの第3回で述べた）ならば，せめてアプリケーション間のやり取りのインタフェースだけでも共通化すべきという考え方がサービス指向アーキテクチャの根底にある。その意味では，「サービス指向アーキテクチャ」というよりも，「インタフェース指向アーキテクチャ」と呼んだ方が適切な名称であるかもしれない。

　通常，サービスの呼び出しは，要求・応答形式つまりRPC[用語解説]的に行われることが多い。呼び出しのための具体的なテクノロジは何でもよい（例えば，DBMSのストアド・プロシジャであってもよい）が，今後は，Webサービス（SOAP[用語解説] ）を使用するケースが増えていくであろう。また，サービス指向アーキテクチャを前提としたアプリケーション統合向けミドルウエアも提供されていくことになるだろう。

　ガートナーでは，2006年までに企業の60％以上が，自社の基幹系アプリケーションの設計において，サービス指向アーキテクチャを重要な規範として検討するようになると予測している。

　次回はビジネス・アーキテクチャとITアーキテクチャの関係について考えてみたい。