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

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

（2006年02月23日）

現実のものとなり始めたSOA

　上述したようにSOAの定義については複数の解釈が成り立つものの、ベンダー各社によって関連製品の販売がすでに開始されており、SOAの実現へと向けた動きが見え始めている。

　ここでは、各ベンダーが定義するSOAについて見ていく前に、SOAを実現するために必要とされる技術について解説する。

SOAを構成する要素技術

　SOAを実現する技術の筆頭として挙げられるのがWebサービスである。

　Webサービスとは、平たく言えば、SOAP（SimpleObject Access Protocol）やWSDL（Web ServicesDescription Language）などのXML技術を使ったアプリケーション連携技術のことである。これらの技術は高度なメッセージングやデータ・フォーマットの変換機能までは備えていないものの、W3C（WWWコンソーシアム）といった標準化団体や多くのベンダーが共同で規格化を進めている標準技術であり、異なるプラットフォーム上のシステムを連携させる際に利用されることが多い。

　複数のアプリケーションに存在するビジネス・ロジックやデータの共有・利用を実現することから、WebサービスもSOAの同義語ととらえられることがあったが、これについては「SOAを実現するための技術の1つであり、Webサービス=SOAではない」という共通認識が生まれつつあるようだ。

　異なるシステムどうしを連携させるのであれば、J2EE（Java 2 Enterprise Edition）仕様に含まれるJMS（Java Message Service）やJCA（J2EE ConnectorArchitecture）を標準技術として用いることもあるし、昔ながらのメッセージ・キューイング・システムを利用する手もある。

　SOAはこうしたシステム連携技術を用いて、異なるシステムの機能を別の環境から利用できるようにするものだ。

　余談だが、SOAの世界でよく聞かれる「サービス化」とは、SOAPやWSDLを用いて、アプリケーション機能を外部システムから利用できるようにインタフェースを整えることを指す。異なるシステムどうしを連携させるには、これまではAシステムとBシステム、CシステムとAシステム、といったように、個別にインタフェースを整備する必要があったが、標準のWebサービス技術を使用すれば、一度サービス化を施すだけで済む。実際には個別開発が必要になるケースが多いようだが、3つ以上のシステムを連携させる場合などでは、そのための開発工数が削減されることは確かだ。

SOAを実現する製品群

　SOAの基本的な定義と、その実現に必要となる技術を押さえたところで、SOA対応を推進しているベンダーとその製品を表1に挙げてみた。表を見ていくと、Webサービス、J2EE規格、EAI（その技術はメッセージング、データ・フォーマット変換、ルーティングなどから構成される）に関連した製品を販売してきたベンダーが、自社製品のSOA対応を打ち出していることに気づくだろう。

表1：SOA対応を推進する主なソフトウェア・ベンダー

　異色なのはアプリケーション・パッケージ製品の最大手ベンダーであるSAPだ。同社は「ESA（EnterpriseServices Architecture）」というSOAに似たコンセプトを掲げている。ただしESAはSAP独自の用語であり、SOAと完全に同義語というわけではない。その詳細は後述することにして、ここでは各社の打ち出す「SOA」についてもう少し深く見ていくことにしよう。September 2005 Computerworld 83これにより、各社が語るSOA、そして、サービスの実体が何であるのかも見えてくるはずだ（注2）。

注2：オラクルも昨年秋に、Oracle RACやOracle E-Business Suiteなどの同社製品を包括する形でSOAを打ち出しており、「Oracle Application Server」もこの中に入ると思われるが、同社の場合、やはりデータベースを核にしたSOA構想を描いていると思われるため、アプリケーション・サーバ系から外している

アプリケーション・サーバ系

　アプリケーション・サーバ市場で並び立つIBMの「WebSphere Application Server」とBEAシステムズの「WebLogic Server」は、共にいち早くSOA対応を標榜してきた製品である。

　J2EEベースのシステム開発機能と実行・運用機能を備えているアプリケーション・サーバは、それだけで企業情報システムの基盤となりうる。これに加え、IBMなら「WebSphere MQFamily」や「WebSphereBusiness Integration」、BEAシステムズなら「WebLogic Integration」といったインテグレーション基盤を提供し、さらにSOA的な要素を盛り込んでユーザーに訴求している。ただし、両社の方向性には若干の違いがある。

■インフラ統合の手段としてとらえるIBM

　IBMが語るSOAは、「Webサービスなどの標準的な疎結合技術を適用したシステム全体のアーキテクチャ」であり、インフラという意味合いが強いようだ。それを裏打ちする策として、昨年末に発表された最新版のWebSphere 6.0では、異機種システムの通信インフラとして前述したESBという要素を取り入れている。

　ESBについても各ベンダーで見解が異なり、はっきりとした正解を提示できない状態だが、IBMが言うところのESBは、具体的な製品というよりも、WebSphereシリーズを貫く内部構造を指し、「標準的なプロトコルやメッセージ呼び出し技術を実装する通信インフラ」と位置づけられているようだ。

　さらに言えば、同社にとっては、WebSphereによるオープン・スタンダードなシステムだけでなく、既存のメインフレーム運用・保守事業の存在も大きい。こうした新旧システムをSOAという枠組みの中で統合する、というのが同社のSOA戦略における前提となっていると思われる。

　その意味からも、IBMではJ2EE、Webサービス、メッセージ・キューイング、そしてビジネス・プロセスの流れを記述・実行するBPEL（Business Process Execution Language）などの技術を包括し、「企業情報システムのインフラを統合しよう」という形でSOAを訴求している。

　ちなみに同社が言うサービスとは、「在庫確認」や「配送処理」など、あるまとまった業務プロセスを示している。こうした単位ですでに稼働している機能をサービス化し、別のシステムと組み合わせることで新しいビジネス・プロセスを生み出すというのが同社のやり方である。

■コンポーネントの再利用性を強調するBEA

　一方のBEAシステムズは、SOAに対して、「ビジネスの変化に迅速に対応できるシステムの開発技術」という見解を示している。これは、「共通して利用できるアプリケーション機能をコンポーネント（部品）として再利用し、コンポーネントどうしを標準技術で連携させることで迅速にシステムを開発する」という“再利用”の考え方に基づくものだ。

　コンポーネントの再利用は、J2EEに含まれる仕様の1つであるEJB（Enterprise JavaBeans）やマイクロソフトのCOMコンポーネントが登場したころから盛んに言われてきた開発方法論だ。だが、プラットフォーム技術の制約や粒度の問題から、EJBやCOMでもコンポーネントの再利用はさほど容易ではない。コンポーネントの粒度の大きさが適切でないと、再利用のメリットを得られにくくなるからだ。

　そこで、上述したSOAの要素技術を使えば、若干ではあるが再利用の促進が期待できる。Webサービスによる疎結合が可能なためだ。さらにコンポーネント単位でなく、分割した業務プロセスを1つのサービスとし、そのサービスの内容をWSDLで記述してSOAPで連携させれば、EJBなど特定技術に依存せずに済むようになる。

　統合アプリケーション基盤「WebLogic Platform」や開発環境である「WebLogic Workshop」、インテグレーション基盤であるWebLogic IntegrationなどのBEA製品はSOAの要素技術を取り入れ、こうした手法をすでにサポートしている。

　また、同社では、オープンソースのSOAフレームワークと言われる「Apache Beehive（Beehive）」も提供している。これはSOAに適用できる再利用可能なコンポーネントで成り立っているが、実際の内容を見ると「認証」や「アクセス制御」などのように、細かい単位のコンポーネントが大部分を占めている。ビジネス・プロセス単位の「サービス」とはやや異なるが、「すでにあるコンポーネントを再利用し、迅速にシステムを開発すること」をSOAとするならば、Beehiveや同社のプラットフォーム製品で十分に実現可能な段階にあると言えよう。