SOAの「現実解」を探る──ベンダー各社のコンセプトや実装技術を徹底比較

注目のコンセプト、第2フェーズに突入。ユーザー企業はどう準備すべきか

（2006年02月23日）

　分散システムにまつわるさまざまな問題を解決するアーキテクチャとして、昨年よりにわかに注目を集め始めている「SOA（Service Oriented Architecture）」。だが現在、その概念を巡って、IT業界ではさまざまな見解が飛び交っている。ベンダー各社は相次いで自社製品のSOA対応をうたっているものの、その定義が各社によって異なったものとなっているためだ。よって、SOAの真の姿をとらえることが困難になっており、さまざまな疑念と過度の期待をもって語られているというのが現状である。本企画では、ベンダー各社が提唱するSOAのコンセプトや実装技術などを整理・検証し、今、現実のものとして“実現可能なSOA”がどのようなものであるのかを解き明かしてみたい。

岩崎史絵

SOAとは何を意味するのか

　昨年、企業コンピューティングの世界において、いい意味でも悪い意味でも注目されたキーワードと言えば「SOA（Service Oriented Architecture）」だろう。いい意味としては「長らく出てこなかった新しいテクノロジー」として歓迎する動きが高まり、悪いとらえ方としては「またよくわからない3文字略語が出てきた」と閉口する向きもあった。

　確かにここ7、8年を振り返ると、企業コンピューティングの世界では、ERP（Enterprise Resource Planning）やSCM（Supply Chain Management）、CRM（Customer Relationship Management）などの“3文字略語のIT”によって市場が形成されてきた。もちろん一方ではハードウェアやOS、プログラミングなどの分野でも新しい技術が登場したが、先に述べた3文字略語のITはこれらの基盤技術を取り込む側であり、純粋なテクノロジーとは少々位置づけが異なるものだ。乱暴に言うと、3文字略語のITは「企業情報システムの効果」を一般のビジネス・ユーザーにわかりやすく訴求するためのマーケティング用語として扱われてきた感が強い。

　例えばビジネス・ユーザーの多くは、Javaの技術面を深く知らなくても、Javaで開発されたERPパッケージの機能なら理解できる。さらに「経営にこれだけの効果がある」となれば真剣に導入を検討するし、実際にマーケティング側の主導によってERPやSCM、CRMの市場も育ってきた。SOAもこうした3文字略語と同系列のものと見なされたために、さまざまな誤解を招いたのではないかと筆者は考えている。そこで本稿ではいったん、こうした見方を捨て去り、「いま、現実にあるSOAとは何か」を見据えていきたい。

SOAがわかりにくい理由

　本題に入る前に、SOAの実体をわかりにくくしている2つの理由について確認しておきたい。

　1つは冒頭で述べたように、SOAも、ERPやSCM、CRMのような「何か具体的な製品、または経営の問題を解決する手法の名称」だと誤解されていたことだ。

　この種の誤解を受けてきた3文字略語としては、EAI（Enterprise Application Integration）やBPM（Business Process Management）などが過去にある。ちなみにEAIは複数のシステムを連係させるための製品カテゴリーの名であると言えるし、BPMはビジネス上の処理の流れにのっとって複数のシステムを連係・管理する製品カテゴリーの名と言える。だが、SOAは経営の問題を解決するための手法の名称でもなければ、製品カテゴリー名でもない。にもかかわらず、それらと同列に置かれてしまったため、「SOAとは何か」ということが見えにくくなったのではないだろうか。

　もう1つの理由は、SOAで言われているところの“サービス”が具体的に何であるのかが、わかりにくいことが挙げられる。

　一般にサービスと言えば、「何かをしてもらう」「当社のサービス・メニューは......」などのように、一連の“働き”を意味することが多い。4、5年前にWebサービスが登場したときにも、「Webブラウザから『出張手配』をクリックすれば、インターネット上にある旅行代理店サービスが自動的に交通機関やホテルの予約をしてくれる」といったようなことがWebサービスだと思われていた。これと同じ状況がSOAで言うサービスにも起こっている。そこでは、サービスを、あるアプリケーションの一機能、あるいはアプリケーションそのものとしてとらえる向きもいる。

　だがSOAで言われるサービスは、特定のアプリケーション、あるいはその一機能より、もう少し“粒度”の細かい単位のものとなる。そのうえ、システムの世界では、サービスの定義もベンダーによってまちまちのため、「これがSOAで定義されているサービスである」と決めにくい状況にある。つまり一般用語としての「サービス」と、SOAが指す「サービス」との間には大きなギャップがあることに加えて、「サービスとは何か」ということが明確化されていないため、SOAという言葉自体が非常にあいまいなものとなっているのだ。

　逆に言えば、「SOAは経営の問題を解決する手段の名称でも、製品カテゴリー名でもない“何か”である。そして、サービスとはアプリケーションそのものでも、その一機能でもない“何か”である」という認識に立ち、この“何か”について、SOA対応を掲げているベンダーがどう定義しているかをひもといていけば、おのずとSOAの実像が見えてくると思われる。

なぜSOAには複数の解釈が成り立つのか

　SOAについては本誌をはじめ、さまざまなメディアやセミナーでも取り上げられる機会が増えてきており、多くのIT/IS部門の担当者の中に「これまでの3文字略語とは違う」という認識が、漠然とではあるが、かなり広まってきたように思う。それと同時に、SOAという言葉自体、決して最新のキーワードではないことも認知されるようになってきた。

　SOAという言葉は、1996年に発表された米国ガートナーのリポート「SSA Research Note」（注1）に初めて登場したと言われている。同リポートによれば、SOAとは「複数のアプリケーションに存在するビジネス・ロジックやデータを共有・利用できるようにする多層コンピューティングの一形態」だという。つまり、同社の定義を用いれば、SOAとはシステムのアーキテクチャであり、上述したような経営の問題を解決する手法の名称や製品カテゴリー名とはまったく異なるものだ。

注1：SSA Research Note SPA-401-068、同SPA-401-069にservice-oriented architectureの定義が掲載されている。原文は“A service-oriented architecture is a style of multitier computing that helpsorganizations share logic and data among multiple applicationsand usage modes.”。詳しくはhttp://www.gartner.com/DisplayDocument?id=391595を参照されたい

　ただし今日では、ガートナーの定義もベンダーごとに拡大解釈されており、上述した定義をそのまま引用することは難しくなっている。とはいえ、どのベンダーも基本路線として「複数のアプリケーションに存在するビジネス・ロジックやデータの共有・利用を実現する」ということを目指しているのに変わりはない。ビジネス・ロジックやデータを共有・利用するための手段をSOAと呼ぶのか、それとも上記の定義を基にコンセプト化したものをSOAと呼ぶのかという違いがあるだけだ（図1）。

図1：SOAに対する解釈の違い

　ここで言うコンセプトとは、開発手法であったり、EAI/BPMあるいはアプリケーション・サーバなどの具体的な製品であったり、複数のシステムを連携させる要素技術であったりする。さらに最近では「ESB（Enterprise Service Bus）」というキーワード（詳細は後述する）も登場しており、SOAに関連する用語は増えつつある。それだけSOAは、まだ発展途上の段階にあるものと言える。

｜1｜2｜3｜4｜ > 次のページへ