目次


BPEL と ESB の比較: どちらを使うべきか

Comments

概要

図 1 に示す IBM® SOA リファレンス・アーキテクチャーでは、機能別に分類されたサービスがエンタープライズ・サービス・バス (以降、ESB と略称) を介して通信します。理想の世界では、関心事 (コンサーン) を分離するために、プロセス・サービス (Process Services) などの各機能分野が「純粋」に 1 つのクラスのサービスだけを提供することになります。

図 1. SOA リファレンス・アーキテクチャー
SOA リファレンス・アーキテクチャー
SOA リファレンス・アーキテクチャー

しかし現実の世界では、どんな製品セットにも重複する機能分野があるものです。その一例が、WebSphere Process Server (以降、Process Server と略称) です。上記のリファレンス・アーキテクチャーでプロセス・サービスを提供するこのソフトウェア・コンポーネントは、WebSphere MQ Workflow、WebSphere Interchange Server、そして WebSphere Business Integration Server Foundation から進化しました。そのため、前の世代の製品を使うユーザーが容易にアップグレードできるように、以前の製品にあった機能に相当する機能が含まれています。例えば Interchange Server にはビジネス・オブジェクト・マッピング機能が備わっていますが、Process Server にはこの機能がインターフェース・マップという形で存在します。

ビジネス・プロセスを出入りするビジネス・オブジェクトはマッピングすることが可能です。マッピングは、ESB における主要な機能の 1 つでもあります。つまり Process Server と ESB とではマッピングという機能分野が重複するため、この 2 つの製品がある場合には、特定のビジネス問題を解決するのに相応しい製品がどちらであるかを判断しなければなりません。

Process Server と ESB のどちらを使うこともできるというケースは他にもあります。例えば、2 相コミットを使って既存の 3 つのサービスを呼び出さなければならないとします。これは複合サービスとして知られるサービスです。この場合、ESB のメディエーション・フローを使用してサービスを呼び出すことが考えられます。メディエーション・フローはトランザクションとしてコミット、あるいはロールバックされるからです。その一方、同じくトランザクションとしての処理を可能にする WS-BPEL マイクロ・フローによってこの 3 つのサービスを呼び出すこともできます。このように、両方の製品をソリューションとして使用できるわけですが、どちらが適切な製品かを判断するにはどうすればいいのでしょうか?

ESB の概要

ESB はソフトウェア製品ではなく、1 つのアーキテクチャー・パターンです。そのため、さまざまなソフトウェア製品が ESB を構成することができます。場合によっては企業が複数の製品を異なる分野で使用し、その固有の要件を満たすために特定の機能を利用することがありますが、これらの各種製品を 1 つに連合させて ESB パターンを実現することが可能です。

大まかに分けると、ESB には以下の 4 つの主要な機能があります。

  • メッセージ・ルーティング: 入力メッセージをハードワイヤード・ロジック、または内容に基づいて動的に決定された宛先に送信します。ルーティングは、サービスの仮想化を可能にする重要な機能です。呼び出し側とサービスとの関係を直接的なものでなくすることによって、呼び出し側に認識させなくても、サービスの位置を移動できるようにします。
  • メッセージ・フォーマット変換: 入力メッセージのフォーマットを変換します。例えば、コンマ区切りメッセージを SOAP に再フォーマット設定して、データを Web サービスに渡せるようにするなどです。
  • プロトコル・メディエーション: 入力メッセージを元のプロトコルとは異なるプロトコルで送信します。例えば、入力メッセージでは HTTP を使用する一方、出力メッセージでは WebSphere MQ を使用する場合などが考えられます。
  • イベント処理: イベントに対する入力メッセージを数々のエンドポイントに配信します。この配信には通常、パブリッシュ・サブスクライブ・モデルが使用されます。

上記の主要な機能は大抵の場合、ある特定のトランザクションの中で組み合わせられます。例えば、入力メッセージが SOAP/HTTP を使用した Web サービス呼び出しで、その宛先が WebSphere MQ を使用した固定長のメッセージ・フォーマットを必要とするレガシー・システムだとします。この場合、メッセージのフォーマット変換、プロトコルのメディエーション、そして正しい宛先へのルーティングが必要となります。

ESB のプログラミングには、ロジックを ESB に接続されているアクティビティーのフロー (メッセージ・フロー、またはメディエーション・フロー) として表すビジュアル環境が必要となるのが一般です。これらのフローは 2 相コミットなどのメカニズムを使用して処理されるため、失敗した場合にはフロー全体をロールバックし、成功した場合にはコミットすることができます。これらのフローはステートレスです。つまり通常は、メッセージが着信するとフローがそのメッセージに対して各種の操作を実行し、それから出力メッセージが送信されます。

ESB はそのステートレスなトランザクションという性質のため、ハイパフォーマンスになります。大規模な組織では、ESB が 1 日に何百万件にも及ぶメッセージを処理することも珍しくありません。

IBM では、ESB の分野でさまざまなソフトウェア・オファリングを用意しています。WebSphere Application Server Network Deployment プラットフォームをベースに作られた WebSphere ESB は、Web サービス、JMS、XML などの標準をサポートできるようになっています。WebSphere Message Broker (以降、Message Broker と略称) は非 J2EE 製品で、WebSphere ESB での Web サービスなどの標準に加え、非標準ベースのプロトコルおよびデータ・フォーマットをサポートします。また、WebSphere DataPower はワイヤー・スピードで ESB 機能を実行できるハードウェア機器です。この 3 つのオファリングは、まとめて ESB の基礎として使用することができます。

BPEL の概要

OASIS 標準機構では、複数のサービスを 1 つのビジネス・プロセスに編成する標準ベースの方法として BPEL (Business Process Execution Language) を定義しています。WS-BPEL 2.0 は 2007年に標準として批准されました。WS-BPEL は実行言語として、フロー制御ロジック、データ、メッセージ相関関係、例外処理などと併せ、ビジネス・プロセス内でのアクティビティーを表現する方法を定義しています。

この WS-BPEL に基づくフロー・エンジンである、ビジネス・プロセス・コレオグラファーを組み込んでいるのが、IBM の WebSphere Process Server (以降、Process Server と略称) です。WebSphere Business Integration Server Foundation と呼ばれていた前のバージョンにも WS-BPEL サポートが組み込まれています。

Process Server の主要な機能には以下のものが含まれます。

  • ビジネス・プロセス: プロセスはステートフルに長時間実行することも、トランザクションのマイクロ・フローにすることも可能です。長時間のプロセスはマイクロ・フローのようにはロールバックできませんが、補償ハンドラーによって前に実行したアクティビティーを取り消すことはできます。複合サービスを実装するには、プロセスを使用することができます。
  • ヒューマン・タスク: ビジネス・プロセスの重要な部分は、人々をプロセスに介入させる能力です。ヒューマン・タスク・マネージャーは、人々が関わるステップをサービスとして呼び出せるようにします。ワークフロー・パターンは外部 (参加) タスク、または BPEL 拡張機能を使用したインライン・タスクによってサポートされます。
  • ビジネス・ルール: 統合されたルール・エンジンにより、決定をビジネス・プロセスにハード・コーティングするのではなく、ビジネス・ルールを作成して評価することが可能です。許可されたユーザーが Web ブラウザーでルールを更新し、管理者がそれらの更新を有効にして、開発環境とランタイムとの同期を維持できるように更新をエクスポートすることができます。
  • 統合 ESB: Process Server には完全な WebSphere ESB 製品が組み込まれています。この記事では、Process Server の BPEL エンジン・コンポーネントにのみ目を向けます。
  • SCA: Process Server でのサービス呼び出しは、SCA (Service Component Architecture) の仕様に従って行われます。SCA インターフェース・マップを使用すると、呼び出し側コンポーネントとは異なるインターフェースでサービスを呼び出すことができます。また、インターフェース・マップはリレーションシップなどの高度な機能もサポートします。システム A では顧客 ID として「123」を使用している一方、システム B では「ABC」を使用している場合、システム間を行き来するときにリレーションシップを利用して「123」を「ABC」に、あるいはその逆にするように仲介することができます。

どちらのランタイムを使用するかを決める方法

前述したように、Process Server と ESB には重複する機能があります。どちらもアダプターを使った動作が可能であり、データの変換も可能です。また、複合サービス・パターンをサポートするという点でも共通しています。そのため、特定のビジネス問題に最適なソフトウェアを決める際には、まずは Process Server と ESB のどちらを使用するかを決めなければなりません。

アーキテクトとしては、両方のソフトウェア・プラットフォームの機能を十分に理解する必要があります。すべての要件を洗い出した後に、決定のプロセスに取り掛かることができます。

第一に行わなければならないことは、要件をひと通り調べ、プラットフォームのいずれかが要件を満たす上でより適しているかどうかを判断することです。例えば、ステートフルなプロセスが必要であれば、すぐに ESB を除外できます。一方、メッセージ・フォーマットの変換を 0.2 秒以内に行うことが必要条件である場合には、ESB を選択すべきことは明らかです。とは言うものの、現実世界でのすべてのプロジェクトがそう単純であるとは限りません。複数の基準を検討しなければ最善の選択肢を判断できないという場合はよくあります。

ESB の利点

ESB の主な強みの 1 つはメッセージの処理です。メッセージの入出力には、おそらくプロトコルまたはフォーマットのメディエーションが適用されます。メッセージ処理が明らかな要求事項であれば、非常に複雑なフォーマット変換を処理できることをはじめ、ESB にはいくつか有利な点があります。このように、メッセージ・ルーティング、フォーマット変換、またはプロトコル・メディエーションなどの基本的な ESB 機能の 1 つが要求されている場合には、ESB を選ぶのが正解です。

パフォーマンスも ESB の強みです。ESB は大量のメッセージを処理できるように設計されているため、例えば 1 日につき 200,000 件のメッセージを処理するという要件があれば、明らかに ESB のほうが適しています。

このように、データ中心の要件には ESB を選択して然るべきです。

BPEL の利点

BPEL エンジンの主な強みは、ビジネス・プロセスを編成できる点です。したがって、複雑なロジックを使用したプロセスが必要とされている場合には、BPEL のほうが適しています。WS-BPEL には、ESB がサポートしていない while ループやスコープなどといったコンテナー・アクティビティーがあります。ESB のロジックは一般的に単純明快なものですが、WS-BPEL ではより複雑なケースを処理することも可能です。

WebSphere Process Server などの WS-BPEL エンジンには、状態が維持される長時間のビジネス・プロセスを使用できるという強みもあります。状態を必要とする場合には、ESB を使用すべきではありません。ESB が状態を維持するためには、多くのカスタム・コードが必要になるからです。ステートフルな処理が要件であれば、ESB を選択肢から除外することができます。

このように、プロセス中心の要件には WS-BPEL を選択するのが当然となります。

機能についての考慮事項

特定のプロジェクトに関する詳細な要件は、そのプロジェクトに最適な環境を判断する際の重要な要因となります。以下に、プロジェクトの要件に関して答えなければならない重要な質問のいくつかを挙げます。

  • 必要なトランスポート・プロトコルは何か。 Process Server と Message Broker はどちらも WebSphere MQ をサポートしますが、例えば IP Multicast をサポートするのは Message Broker だけです。JMS を使用する場合は、特定の JMS プロバイダーがサポートされるかどうかを把握することも同じく重要です。
  • 必要な標準は何か。 要件で、例えば WS-Security や複雑な業界標準スキーマのサポートが求められる場合があります。これらの標準がサーバーでサポートされるかどうかを調べてください。Message Broker は、型のないメッセージ処理などのサポートに優れている一方、Process Server は J2EE コンテナー内で実行されることから、J2EE セキュリティーを使用することができます。両方の環境がある特定の標準をサポートすることがあっても、そのサポート・レベルは異なります。したがって、必ずすべての詳細を確認してから決定してください。
  • サービス品質 (QoS) 要件の内容。 システムに高可用性が求められるかどうかということです。Message Broker が可用性の高い環境にインストールされる一方、Process Server はそうでなければ、その点が決定を左右する可能性があります。QoS が確保されるかどうかを把握するためには、使用している環境を調べなければなりません。パフォーマンス要件、ならびに保証されたメッセージ配信などの要件を考慮する必要があります。
  • どのようなルーティングおよびメッセージング・スタイルが必要か。 システムでは同期または非同期、要求/応答、一方向、そしてパブリッシュ/サブスクライブなどさまざまなメッセージング・スタイルを使用できます。そのため、どのスタイルが必要なのかを考えなければなりません。それは 1 つのメッセージング・スタイルである場合も、複数のメッセージング・スタイルの組み合わせである場合もあります。どのようなスタイルが特定の環境でサポートされるかを調べてください。Process Server では JMS トピックによってメッセージのパブリッシュを実行できます。一方、Message Broker にはコンテンツ・ベースのサブスクライブといった高度な機能が備わっています。これらの要件が、ランタイムの選択を絞り込む際に役立つことがあります。

機能以外の考慮事項

機能要件に加え、すべてのシステムには適切なランライムを選択する際に考慮しなければならない一連の非機能要件もあります。例えば、以下の要件です。

  • 所有権の総コスト。 ソフトウェアの初期コストだけでなく、長期的な関連コストも考慮に入れる必要があります。例えば顧客が J2EE プラットフォームでソリューションを実装した場合のほうがコストを下げられるとしたら、Process Server を決定する方向に傾くはずです。
  • 管理コストとしては何があるか。すべてのシステムには管理者が必要です。新規プロジェクトの管理者として採用できる人材が会社にすでにいるため、新しいリソースを加える必要がないのであれば、そのことが所有権の総コストに影響するはずです。例えば、MQ 管理者は Message Broker には馴染みがあるかもしれませんが、J2EE ベースのランタイムとなると、彼らにとっては急峻な学習曲線となる可能性があります。また、環境を監視する上での容易性、そして管理者が扱うセキュリティーの側面についても考慮してください。
  • 必要となるスキル。 管理者の他、開発者、テスター、そしてその他の役割も必要になってきます。すでに揃っているスキルを利用できるのであれば、関連する時間とコストの節約につながります。一方、プロジェクトに向けて新しいスキル・セットを学ぶための訓練が必要となったり、あるいはメンター・サービスを契約したりしなければならない場合もあります。
  • 既存の環境はどのようなものか。 ミドルウェア環境がすでに稼動しているか、ユーザーは設定されたツールに十分慣れているか、そして新しいツールが必要な場合には現行のツール環境との相性はどうかについて考えます。前提条件となるソフトウェアに対して現行のバージョン・レベルは対応しているのか、あるいは既存のアセットをアップグレードする必要があるのかを判断するとともに、マイグレーションを行わなければシステムを使うことができないのかどうかを調べてください。
  • オプションのいずれかが固有の機能を提供するか。 いずれかの環境にある固有の機能が決定を左右する場合があります。例えば、マッピングは ESB で行うことも、Process Server でインターフェース・マップを使用して行うこともできます。ですが、リレーションシップのマッピングが可能なのは Process Server のインターフェース・マップのみです。この機能が必要であれば、Process Server が唯一、それを提供します。

Process Server と ESB のどちらも有力候補のようであれば、非機能要件によって選択を絞り込める場合がよくあります。

パターン

e-ビジネスのパターンは、e-ビジネス・アプリケーションの開発とデプロイを迅速化するために使用できる、実証済みの再利用可能なアセットです。IBM では、さまざまな技術を利用したパターンの使用法について説明している Redbook のシリーズを発行しています。その一例としては、「Patterns: SOA Design Using WebSphere Message Broker and WebSphere ESB」があります。

要件を検討すると、それらの要件を実装するためにパターンを使えるかどうかを判断できます。既存の 1 つのパターンや、パターンの組み合わせが特定のランタイムに対して実証されていれば、そのランタイムは要件に対応可能であるということです。リスク対策は既に施されているため、リスクは低くなり、さらにパターンを適用することによって開発時間も短縮されます。パターンが 1 つのランタイムにしかなければ、それが判断をする上での手掛かりとなります。

典型的なパターンには以下のものがあります。

  • メッセージの集約と分解 (N 対 1 および 1 対 N)
  • 1 対 N の応答 (複数の要求を送信して 1 つの応答を選択)
  • サービスの仮想化 (場所および ID)
  • コンテンツ・ベースのルーティング
  • アダプターの相互作用
  • メッセージ強化
  • 動的なレジストリー検索
  • イベント伝搬
  • ゲートウェイ (内部ドメイン境界と外部ドメイン境界の間での制御されたセキュアな対話動作)

例えば、前述の Redbook ではゲートウェイ・パターンによる DataPower の使用について説明しています。XS40 XML Security Gateway は、このパターンをサポートするための機能要件および非機能要件を満たします。ゲートウェイ・パターンを実装するためにどのソリューションを使用するかを検討している場合には、この点が決定要因になるはずです。

曖昧な部分

これまでのセクションに挙げた基準によって最終的な決定段階にまで絞り込んだとしても、ESB と Process Server のいずれもプロジェクトのランタイムとして選択できる場合があります。そのような場合には、他にも検討できる事項がいくつかあります。

設計理念

一部の会社には、すべてのプロジェクトの指針となる全体的な設計理念があります。設計理念により、例えばすべてのフォーマット変換は ESB で行うようにする一方、すべてのビジネス・ロジックは Process Server に常駐させると決定する場合も考えられます。

顧客がオンラインで注文を行う場合、顧客が無料配送の対象となるかどうかのビジネス判断は、Process Server で動作するビジネス・ロジック層に属することになります。一方、適切な配送サービスへのメッセージのルーティングが行われるのは ESB 層です。そのため、会社は統合ロジックを変更せずにビジネス・ロジックを変更することができます (その逆の場合も当てはまります)。

この全体的な設計理念を決定要因としてください。つまり、戦略上の方針を考慮するということです。他のすべてが同じであれば、全体的な設計理念を判断基準として使用することができます。

コスト

デプロイする WS-BPEL プロセス、またはメディエーション・フローのそれぞれが、そのデプロイ場所となるサーバーの CPU 容量を消費します。ハードウェア・コスト、サポート・コスト、そして管理などと併せ、実行されるミドルウェアにも当然コストがかかります。どの環境を使用したらよいかはっきりしない場合は、コストによってデプロイする場所を決めることができます。

保守

特定のビジネス問題にどのプラットフォームが適切かを判断するときには、システム全体の長期にわたる保守を考慮に入れなければなりません。WS-BPEL の相関セットを使用したほうが、同様の機能を提供するためのコードを ESB で作成して保守するよりも簡単であるなら、ソリューションを短時間で構築できるだけでなく、保守も容易になるはずです。組み込み基本関数が利用できる場合は常に、カスタム・コードを作成するよりも賢い設計手段となります。保守しやすいソリューションをぜひ、選択してください。

保守のもう 1 つの側面は、ミドルウェア製品の進化に合わせて、将来的にソリューションをどれだけ簡単にアップグレードできるかという点にあります。一般に、主要な新規リリースでは前のリリースでの成果物を使用することができます。WebSphere Process Server V6 のツールである WebSphere Integration Developer では、前のプロジェクトを出発点として使用するために WebSphere Business Integration Server Foundation V5.1 のインテグレーション・プロジェクトをインポートすることが可能です。WS-BPEL プロセスのロジックは新しい環境に取り入れられますが、プロセスの Java™ コードを更新するために何らかの手作業が必要となる場合があります。大抵はソフトウェア製品の組み込み関数を使用したほうが、その後のアップグレードが容易になります。

再利用性

SOA のアセットを構成するときには常に、そのアセットをどのように再利用していくかを考えてください。何らかのものを作成すれば、それでビジネス問題は解決しますが、それが再利用可能なものであれば、開発の時間とコストの大幅な節約を実現できます。

前述のオンライン注文を例に用いると、ジョブ全体を実行するには ESB を使うことも、WS-BPEL マイクロ・フロー・プロセスを使うこともできます。ビジネス・ロジックを WS-BPEL に切り離し、ルーティング・ロジックを ESB に維持すれば、再利用できる可能性は大きくなります。両方の関数が 1 つの環境にあるとすると、サービスはそれが設計された特定の目的のために 1 度しか使えません。その一方、関数を分離させれば、いずれか一方を再利用できる可能性が大きくなるというわけです。その一例として、店内の配送システムがルーティング・サービスを利用することが考えられます。決定を行う際には、作成しているソリューションに潜在する再利用性を考慮してください。

スキルの強み

IT スタッフのスキルという点で、他の製品よりも、ある特定の製品が優位な場合があります。プロジェクトを長期間サポートするためには、より強力なスキル・セットが決定を左右すると考えられます。例えば、3 人の優秀な ESB 開発者がいる一方、Process Server に関しては 1 人しかいないのであれば、ESB を使用してプロジェクトを構築するのが妥当でしょう。

リスク

成功しているプロジェクトとは、リスクが軽減され、プロジェクトが失敗する可能性はわずかしかないプロジェクトのことです。Process Server に 5 つのモジュールを実装済みである一方、Message Broker については手をつけ始めたばかりであるという場合、経験を積んでいる Process Server を使用したほうが、よりリスクが少ないと判断できます。

同様に、実装しなければならないシステムと同じようなシステムに関するリファレンスと事例研究を見つけられる場合もあります。Message Broker を使って実装に成功した顧客が他にいるとしたら、それは、製品の限界を広げているのではないという保証になります。他に同様のプロジェクトに成功している顧客がいるならば、リスクは低くなります。

プロジェクトでのリスクに関わるすべての要因を評価し、リスクの低さを基準にして最終的な決定を行える場合もあります。

まとめ

この記事では ESB と WS-BPEL プロセス・エンジンの概要、そして環境に応じて ESB と WS-BPEL のどちらが最適なソリューションとなるのかを判断する方法を説明しました。また、ESB と WS-BPEL それぞれの長所や、機能要件および非機能要件などの基準を考慮する方法、パターンを適用する方法を学べたはずです。どちらのソリューションも要件を満たせるように思える場合には、最後に説明した追加の判断基準を手掛かりとしてソリューションを決定してください。


ダウンロード可能なリソース


関連トピック

  • WebSphere SOA ゾーン: 記事、チュートリアル、ダウンロードをはじめ、WebSphere SOA ソリューションに関する最新の技術資料を入手してください。
  • WebSphere Web services ゾーン: WebSphere Web サービス・ソリューションに関する記事、チュートリアル、ダウンロードなどの最新の資料は、ここから入手できます。
  • Patterns: Implementing an SOA Using an Enterprise Service Bus: この IBM Redbook では、Process Integration パターンのサービス指向アーキテクチャー・プロファイルを利用して Enterprise Service Bus によるサービス指向アーキテクチャーの実装に取り掛かる方法に焦点を当てています。
  • Patterns: SOA Design Using WebSphere Message Broker and WebSphere ESB: この IBM Redbook では、WebSphere ESB と WebSphere Message Broker を統合するためのパターンについて説明しています。また、これらの製品の設計、開発、デプロイメントに役立つシナリオも記載しています。

コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=WebSphere, SOA and web services
ArticleID=300217
ArticleTitle=BPEL と ESB の比較: どちらを使うべきか
publish-date=03122008