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

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

（2006年02月23日）

EAI/BPM系

　もともとEAI/BPMはシステム連携のための基盤製品であり、メッセージングやデータ・フォーマット変換などの形で、「あるシステムから別のシステムを利用する」ことを可能するものだった。それゆえ、SOAとEAIの違いを訴求しにくいところがあり、「今までEAIと言っていた製品をSOAに言いかえたにすぎないのではないか」と見る向きも多い。

　こうした疑問点について、EAIとSOAの違いを明確に打ち出しているのがソニックソフトウェアである。同社は「Sonic ESB」というアプリケーション統合プラットフォーム製品の投入によって、従来のEAIが提唱していたハブ&スポーク型のシステム連携アーキテクチャの限界を打ち破る構えだ。

■SOAとESBの関係

　ここで、ESBとは何かを整理しておこう。ESBという言葉はソニックソフトウェアのほか、IBMやBEAシステムズ、さらにSAPでも使っている。

　多くのベンダーはESBを標準的な通信技術を実装するレイヤとし、アーキテクチャの1つと位置づけているが、ソニックソフトウェアの場合は、ESBが持つべき機能要件として「メッセージング」「サービスの仲介」「サービスのホスティング」「サービス」の4つを定義している。このうち、メッセージングとサービスの仲介は従来のEAIがつかさどっていた機能であり、サービスのホスティングとサービスそのものはアプリケーション・サーバが得意とする分野だ。ソニックソフトウェアによると、両者の“いいとこ取り”をしたのがSonicESBというわけで、当初はこの製品を「次世代EAI」と呼んでいたという。

　同社の言うところのESBが従来のEAIと異なるのは、ハブ&スポークの形ではなく、ESBに各サービスがぶら下がり、システムはアダプタを通じてそのサービスと連携するという点だ（図2）。

図2：EAI、アプリケーション・サーバ、ESBの違い

　アプリケーション・サーバもEAIと同じく、1つの環境の中にサービスとサービス仲介の機能を持つが、「そうしたアーキテクチャだとサーバに極端に負荷がかかり、柔軟なスケールアップが望めない」というのが同社の主張だ。

　では、ここで言うサービスとは何か。同社は、SOAにおけるサービスを「業務を構成するプロセスであり、エンドユーザーに見える単位のもの」と位置づけている。

　「受注/出荷」という業務のプロセスを例に挙げよう（図3）。アプリケーションの機能としては、受注を受けた際に、「データベースにアクセス」し、「在庫数を確認」する。在庫があれば「引き当て」、なければ「ほかの在庫センターを調べる」。それでも在庫がない場合は、「生産指示」を出す。その後、出荷・納期について、「納期回答」を受け取ったり、「納期時期を画面に表示」させたりする。

図3：業務を構成するプロセス

　このように、アプリケーションの機能をエンドユーザーにわかりやすいプロセスで区切った単位を同社では、サービスと定義している。

　こうして新しく定義されたプロセスを、ソニックソフトウェアでは「コンポジット・アプリケーション」と呼ぶこともある。なお、この呼称は同社のほかにもいくつかのベンダーが使っているが、その意味は一様ではないことに注意されたい。

　Sonic ESBは、このように定義されたサービスを仲介・実行するための機能（これもサービスの形で提供される）と、実際にシステム間でメッセージやデータをやり取りするための通信レイヤなどから成る。また、定義されたサービスの稼働状況を一元管理するモニタリング機能により、SOA環境のスムーズな運用も可能としている。

　さて、そのほかのEAI製品はどうか。これまでEAIの主要機能と言えばメッセージングやルーティング、データ変換機能だったが、今日ではむしろBPELなどの技術を適用したビジネス・プロセス管理機能にシフトしてきている。

　SOAの登場以前にも、ほとんどのEAIベンダーが積極的にBPM機能を打ち出した時期もあったが、SOAの登場により、「新しいビジネス・プロセスをEAIとBPMで作り上げる」というのがEAI製品のトレンドとなっている。

　例えばアイオナテクノロジーは、同社のWebサービス統合ソフト「Artix」シリーズにおいて、システムどうしをつなぐレイヤとなるメッセージングやルーティング、データ変換層に加えて、新しいビジネス・プロセスを定義するレイヤとしてBPM層を提供している。SOAの現実的な実現手段として、まずは「つなぐ」部分を整え、その一段上のBPM層で、あるべきビジネス・プロセスを定義・実行するという形だ。つまり現実のシステムの姿の上に、BPMという抽象化レイヤを組み合わせるというアプローチである。

　ただし、こうした“真っ当”なSOAの実現には非常に時間がかかることに注意したい。そもそも、プラットフォーム/アーキテクチャが異なるシステムを連携させるのがそれほど容易ではないうえ、「あるべき姿」を描いてからアプリケーションの機能をサービスとして切り出し、ビジネス・プロセスの記述に取りかかることになるからだ。ここでサービスの粒度をどのように設計するか、という問題も発生する。ユーザー企業のビジネス・プロセスごとに、サービスの粒度も異なってくるからである。

アプリケーション系

　ユーザーに最もわかりやすくSOAを訴求できるのがこの分野の製品だろう。ユーザーにとっては「サービス=アプリケーションの機能」という目に見える形で提供されるからだ。

　SAP R/3だけに閉じた従来のアーキテクチャを捨て、SOAとよく似た概念であるESAを提唱しているのがSAPだ。同社ではESAを「R/3と他システムとの疎結合を実現する次世代アプリケーションの姿」とし、今後はこのポリシーにのっとって製品開発を進めるとしている。その具体例の一つがESA実現のための連携ミドルウェアとなる「NetWeaver」である。

　同社は、1つのトランザクション処理をサービスとして想定している。例えば「在庫確認」という処理を1つのトランザクションとして定義し、別のシステムからこれを呼び出して使えるようにするわけだ。

　とはいえ、同社は決してESAを「手軽なもの」と考えているわけではない。サービスの切り出しやシステムどうしの連携は、入念なIT戦略の下で初めて可能になるものである。こうした意味では、EAI系の製品でSOAを目指すのとそれほど大きな差はないと言えるだろう。

データベース系、OS系

　昨年秋からSOAへの対応を積極的に打ち出し始めたのがオラクルである。言うまでもなく、同社はデータベース製品のリーディング・ベンダーであるが、最近の動きを見ると、データベース製品を中核とした統合プラットフォーム・ベンダーへと方向性をシフトしつつあり、SOA対応は同社にとって不可欠であると思われる。同社のアプローチは、ビジネス・プロセスを規定するBPELと、企業内のデータを統合する「Enterprise Data Hub」という構想の下で、アプリケーション・ロジックとデータの両方を共有・利用できるようにするものだ。

　一方、OS系ではマイクロソフトが、来年登場予定のLonghorn（開発コード名）にサービス指向の通信アーキテクチャ「Indigo」（開発コード名）を組み込むという。

　Indigoでは「相互にメッセージ交換を行うプログラム」をサービスと定義しており、このサービスが集まったものがシステムとなる。Indigoは.NET FrameworkやCOM、COM+など同社のWebサービス技術の共通インフラとして機能する。よって、マイクロソフトは、同社のアーキテクチャのみでSOAを実現することを前提としているように見えるが、実はSOAの実現に向け、オラクルとの技術協力関係を結んでおり、今後の動向が注目される。

SOA導入事例 1──米国トランスアメリカ生命
レガシー・システムをコンポーネント化し、柔軟なシステム連携を実現

レオン・アーランガー／InfoWorld米国版

　SOAに基づいたシステム構築によって得られるメリットには、既存のレガシー・システムを、再利用可能なWebサービスのコンポーネントとすることで、新しいビジネス・プロセスを容易に構築したり、業務システムの迅速な開発を実現したりすることなどが挙げられる。こうしたメリットは、米国トランスアメリカ生命が、同社の基幹システムにリアルタイムでアクセスできるサービスを代理店に提供する際に必要とされていた要件だ。

　トランスアメリカは全米各地の代理店とネットワークを介して多くのデータをやり取りしているが、そのほとんどはバッチ処理によるファイル転送である。同社の年金商品&サービス部門のIT戦略担当ディレクター、ジェフ・グリーソン氏は、競合他社に対する競争力を維持するためには、ビジネス・パートナーである販売代理店に、膨大な数のレガシー・バックエンド・システムにリアルタイムでアクセスさせる必要があると考えていた。

　そこで同社では、バックエンドのメインフレーム・トランザクションをWebサービスとして公開するため、J2EEベースの統合基盤製品「ICAN（Integration Composite Application Network）Suite」（シービヨンド・テクノロジー製）を導入し、SOAに基づいたシステムの構築を行った（図A）。ICAN Suiteは、メインフレームで使用されるデータ・フォーマットを変換する機能や複雑なメッセージ・ルーティングを処理する「代理店ハブ」を作成するBPM機能を提供している。

図A：米国トランスアメリカ生命のシステム概要図

　一方、代理店側のアプリケーションには、ACORD（Association for Cooperative Operations Research and Development）という非営利の標準化団体が開発した保険業界向けのXMLスキーマを採用した。代理店側から送信されるXMLデータは、トランスアメリカのバックエンド・レガシー・システムに対応したフォーマットに変換される。

　グリーソン氏はSOAを実装しようという企業に対して、できるだけ十分な計画に基づいて準備しておくことを勧めている。

　「われわれがもう一度、同じチャレンジに取り組むとしたなら、事前にアーキテクチャの検証や標準となるプロトタイプの作成に加え、テストやセット・アップにもっと多くの時間をかけるだろう。精査が不十分なままサービスに変更を加えてしまうと、あるシステムには有用でもそれ以外のシステムでは使えなくなってしまうおそれもあるからだ」（グリーソン氏）

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