あらためてSOAに挑む！
PART03：【識者の目】継続的改善が成功への道
■初めから完璧などない～継続的改善が成功への道
ここ数年、IT関連のセミナーや雑誌でSOAというキーワードを見聞きする機会が減っている。 しかし、SOAの意義は決して薄れていない。 本パートでは、SOAの本質を改めて整理するとともに、導入する際に考慮すべきポイントを洗い出す。
2009 年1月5日、IT調査会社である米バートングループのバイスプレジデント兼リサーチディレクターであるアン・トーマス・メインズ氏のブログに「SOA is Dead; Long Live Services（SOAは死んだ；サービス万歳）」というエントリーが上がり、たちまち話題を呼んだ。ご記憶の方も多いだろう。これに呼応するように、米ガートナーのアナリストがブログに「Ahh Shucks, SOA Is A Failure（嗚呼、SOAは失敗だ）」と題して「SOAにより、コストはむしろ上昇し、プロジェクトは長期化し、システムはより脆弱になった」と書き込んだ。これらの意見をめぐって、ネット上で賛否両論、様々な意見が飛び交った。
SOAは無意味なバズワードだったのだろうか。答えは「No」だ。この話題に入るには、SOAとは何かを今一度、整理する必要がある。
■SOAの本質はソフトウェアの部品化
近年、「不確実性の時代」や「戦略のパラドックス」という言葉で表現されるように、企業を取り巻く環境の変化はあまりにも急激である。こうした変化のスピードにシステムが追随できず、むしろビジネスの足を引っ張るリスクになりかねないという不安がIT部門の間で拡大している。SOAは、こうした不安を解決するために有効な手法として登場した。SOAにより、アプリケーションの重複開発を排除できるほか、開発の柔軟性が高まるメリットを期待できるからだ。
では、そもそもSOAとは何か。ITRは、SOAを「ソフトウェアをサービスという部品に分割し、それらを組み合わせてシステムを構成する手法」と定義している（図3-1）。つまり、SOAの本質はソフトウェアの部品化である。そう考えれば、SOAは新しい概念ではないし、何かの突然変異で現れたものでもない。構造化プログラミングをはじめ、古くから同様の発想はあった。
 |
| 図1：ITRが考えるSOA 出典：ITR |
SOAの基本構造はシンプルだ。(1)サービスを組み合わせて必要な処理を行うプログラム（サービスコンシューマ）、(2)汎用的に利用できる1つの機能を持つプログラム（サービス）、(3)サービスコンシューマとサービスを接続する通信とメッセージ、という大きく3つの要素から成る（図3-2）。
 |
| 図2：SOAの基本構造 出典：ITR |
実際にSOAを用いたシステムを構築する際には、こうした基本構造に加えて、複数のサービスコンシューマが、サービスの在処や接続方法を知らなくてもサービスを呼び出せる環境を提供する技術を利用する。具体的には、サービスを検索・照会するためのイエローページ（UDDI）、標準化した通信を行うためのメッセージ言語（XML）や通信プロトコル（SOAP）、基盤としてESB（Enterprise Service Bus）などである。
ただし、SOAは構築手法であるので、必ずしも特定の技術や製品を利用しなければならないわけではない。SOAにおいて、技術や製品はあくまでも手段であって目的ではない。
