特集 開発現場からの提言（前編） サービス指向アーキテクチャ（SOA）の実際 有限会社アークウェイ　黒石 高広 2005/10/15

Page1 Page2

　ここ最近、サービス指向アーキテクチャ（SOA：Service-Oriented Architecture）に関する記事や書籍が増え、開発者の間だけでなくエンド・ユーザーの間でもSOAに対する関心は非常に高まってきている。しかしその一方で、SOAの概念や考え方は理解できるが、どのように実装すればよいか分からないという意見も出始めている。

　エンタープライズ・アプリケーション統合（EAI：Enterprise Application Integration）に代表されるアプリケーション統合の世界では、SOAに対する取り組みが数年前から始まっており、すでにいくつかの実証実験なども行われ、SOAに対するさまざまな教訓が得られている。

　本特集では、このような現在のSOAの問題点を整理し、特にアプリケーション統合の観点からSOAに対してどのように取り組めばよいかについて、2回にわたり解説していく。

1. 人によって異なるSOAの解釈と主張

　多くの意見をまとめると、一般的にSOAとは、

「再利用性の高いサービスを組み合わせてアプリケーションを柔軟に構築できるアーキテクチャである」

といわれているようである。ちなみに、SOAを最初に提唱したガートナー社では、SOAを

「業務を完結する機能としてのサービスと、サービスを呼び出して利用するサービス・コンシューマから構成される」
（出典：「SOAテクノロジ分類：SOA理解のために」 K.Iijima, 2004 Research Note）

と定義している。

　前述したように「SOAをどのように実装すればよいか分からない」と指摘される原因は、確かにこのようなSOA自体の定義があいまいなこともあるが、根本的な原因は、SOAで用いられる「サービス」の定義があいまいな点にあると筆者は考える。

　実際、SOAではサービスの実装方法まで具体的に定義されているわけではない。そのため、サービスの粒度や実装技術などをめぐって、各所で開発者に多くの混乱をもたらしている。また同様の理由から、人によって異なるSOAの解釈や主張を生み出しているのである。

　次の図は、経営者や業務分析者、システム管理者、開発者などSOAに取り組む人々の立場（ステークホルダーごとの視点）によってSOAのとらえ方が異なっていることを示したものだ。

ステークホルダーごとに異なるSOAのとらえ方

　まず経営者や業務分析者の多くは、「ビジネス・プロセスを柔軟に変更できるもの」としてSOAをとらえている。例えば、企業内外にまたがるビジネス・プロセスをどのように管理できるかをSOAで解決しようとしているのだが、これはビジネス・プロセス管理（BPM：Business Process Management）と呼ばれる領域から見たSOAの姿であるといえよう。

　一方システム管理者は、経営者や業務分析者に視点が近く、かつ技術的な知識も持ち合わせているため、「SOAにより複数のアプリケーション上で動作するビジネス・プロセスをどのように連携できるか」という点に関心を持つことが多い。

　これは、アプリケーション統合と呼ばれる領域から見たSOAであり、このような領域に向けては、さまざまなベンダから多くのEAI製品やアプリケーション間連携のためのミドルウェアが提供されている。ちなみに、EAIの領域はBPMも含んでいるので、多くのEAI製品が、（現時点でBPELに対応しているかは別にして）BPM機能を含んでいる。

　そして開発者は、SOAを1つのアプリケーションを開発する際の拡張性や柔軟性を高めるためのアーキテクチャとしてとらえていることが多い。アプリケーション開発の際、どのように実装すれば拡張性や柔軟性を高められるかという点に開発者は関心を持つのである（ちなみにSOA以外で拡張性や柔軟性を高めるアプローチとしては、オブジェクト指向プログラミングやコンポーネント技術、アスペクト指向などさまざまなものが存在している）。

　このように、SOAの定義（特にそこで用いられるサービスの定義）があいまいなため、またSOAに取り組む人の立場によって関心が異なるため、人によってさまざまなSOAの解釈や主張を生み出しているわけである。

　一口にSOAを実現したいといっても、それだけではビジネス・プロセスを柔軟に変更したいのか、単純にアプリケーションの画面の流れを柔軟に変更したいのか、ワーク・フローを実現したいのか、あるいはアプリケーション内の処理の流れを柔軟に変更したいのかまでは分からない。それらのアプローチはまったく異なったものなので、結果として実装方法で悩むことにもつながってくる。

　従ってSOAを議論するに当たっては、まず自身の立場や視点を明確にし、エンド・ユーザーが何を求めているのか、どのレベルでの柔軟性が必要なのかを理解することが重要である。まずはこの点をよく肝に銘じておいていただきたい。

　SOAの技術解説の多くは、このステークホルダーの視点によるSOAのとらえ方の違いをあまり意識せずに語られているため、SOAに対する混乱をより深めてしまっているように思う。そこで本稿では、アプリケーション統合という業務プロセス・レベル（主にシステム管理者）の視点でSOAを解説していく。つまり本稿では、開発者の視点によるSOAのアーキテクチャを持ったアプリケーションの構築については触れないので注意してほしい。

　それでは以降、SOAの特徴や問題点などについてより深く掘り下げて解説していく。まずは、「なぜいまSOAに注目が集まっているのか？」について考えてみよう。

2. なぜいまSOAが求められているのか？

　SOAが最初に登場したのは、1996年にガートナー社が発表したレポート「Service-Oriented Architecture, Part 1 & 2」であるとされている。つまりSOAという言葉自体は10年近く前から存在したことになる。にもかかわらず最近になってSOAが脚光を浴びるようになったのはなぜなのだろうか？

　その理由として、まずビジネス環境の急激な変化が挙げられる。読者も記憶に新しいであろうメガバンクの合併やテレビ局の敵対的買収（結局、買収は実現しなかったが）など、企業レベルでの統合も非常に活発になっている。また、アウトソーシングやオフショア開発などのように、業務の一部分を外部の企業に委託する形態も多くなってきている。

　このように、近年ではビジネス環境の変化は非常に速く、業務の形態も複雑化している。そのため企業内のアプリケーションにも、ビジネス環境の変化に迅速に対応できるように柔軟性や拡張性が強く求められるようになってきている。そのようなビジネス的な側面からSOAが渇望されているわけである。

　また技術的な背景もSOAが注目される大きな理由の1つだ。

　2000年にWebサービスが標準技術として登場し、.NETやJavaなどの業務アプリケーション開発の主要プラットフォームも次々とWebサービスに対応した。これは、プラットフォームの違いにかかわらず適用可能な相互運用性（Interoperability）の高いミドルウェア技術が登場し、SOAのサービスを実装する環境がそろったことを意味している。

　確かにミドルウェア技術としては、CORBAやDCOM、Java RMI（Java Remote Method Invocation：Javaオブジェクトのリモート・メソッド呼び出し機能）など、多くのものが以前から存在していた。しかし、それらは導入コストの問題や特定プラットフォームに依存した技術であるといった問題などから、なかなか普及が進まなかった。そのような状況の中でのWebサービスの登場は、SOAのサービスを実装する現実的なミドルウェア技術として受け入れられたわけである。

　以上のような背景から、SOAが脚光を浴びるようになり、SOAのサービスを実現するための技術としてWebサービスを使うことが一般的になりつつあるのが現状である。

　それでは本当にWebサービスを使うだけでSOAのサービスを実現できるのだろうか？ 本当にそれですべての問題は解決するのだろうか？ 次はSOAのサービスとしてWebサービスを用いる場合に起こり得る問題点について考察していこう。

INDEX
	[特集]
	開発現場からの提言（前編）
	サービス指向アーキテクチャ（SOA）の実際
	1．なぜいまSOAが求められているのか？
	2．「SOA＝Webサービス」だけではうまくいかない
	開発現場からの提言（後編）
	SOAの導入を成功させる現実的な方法とは？
	1．アプリケーション間連携の現状（AS-IS）とあるべき姿（TO-BE）
	2．メッセージ・バスによるSOAシステムの構築方法
	3．メッセージ・バスだけでは難しい問題

　

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）