エンタープライズ・サービス・バスのための、USB に似たユニバーサル・ポート・タイプ: 第 1 回 ESB が現在抱えている問題

ESB の基本機能と ESB が現在抱えている問題

連載の第 1 回である今回の記事では、始めにエンタープライズ・サービス・バス (Enterprise Service Bus: ESB) の基本機能について説明し、その後で ESB を使用する上での現在の問題をいくつか紹介します。連載の今後の記事では、ユニバーサル・ポート・タイプという、ESB のための新しい概念について説明します。ユニバーサル・ポートは現在 ESB を使用している人々が経験している多くの問題に対するソリューションとなります。ユニバーサル・ポートは、コンピューターに多様な機器を接続するための USB ポートと役割が似ています。USB ポートと同じように、ユニバーサル・ポートを使用することで任意のアプリケーションを ESB に接続することができ、また間接的に、他のアプリケーションに接続することもできます。それらのアプリケーションは、まったく異なる形式のサービスを使用して機能の一部またはすべてを公開するかもしれませんが、その場合にも 1 つのポート・タイプを使用することができます。

Dr. Waseem Roshen, Master IT Architect, IBM  

Waseem RoshenWaseem Roshen 博士は米オハイオ州コロンバスのオハイオ州立大学 (The Ohio State University) で博士号を取得し、IT 分野で 18 年を超える実践経験があります。彼は現在、IBM の Enterprise Architecture and Technology Center of Excellence の IT アーキテクトです。彼は SOA (Service-Oriented Architecture) などの分散コンピューティングを幅広く経験してきています。また、カスタム開発、統合アーキテクチャー、J2EE (現在の JEE) にも専門知識があります。彼が現在関心を持っている分野には、SOA と Web サービス、量子コンピューター、クラウド・コンピューティングなどがあります。Roshen 博士は 60 点を超える出版物を執筆し、37 件の特許を持ち、IEEE と IEEE Computer Society の会員でもあります。彼は『SOA-Based Enterprise Integration: A step-by-step guide to services-based application integration』を単著として執筆しました。



2011年 9月 30日

はじめに

SOA (Service Oriented Architecture) において、エンタープライズ・サービス・バス (Enterprise Service Bus: ESB) はインフラストラクチャーを構成する極めて重要なコンポーネントです。ESB は、図 1 に示すように、まったく異なる形式のサービスを用いる複数のアプリケーションを間接的に接続するために使用されます。こうした異なる形式のサービスには、Web サービス、RESTful なサービス、非同期サービスなどがあり、これらのサービスでは、MQ、CORBA ベースのサービス、DCOM ベースのサービス、Java RMI などが使用されています。これらのサービスは異なる通信プロトコルやメッセージ形式を使用します。例えば、Web サービスは通信プロトコルとして HTTP を使用し、メッセージ・フォーマットの形式として SOAP を使用する一方、非同期サービスは通信プロトコルとして MQ を使用し、メッセージ・フォーマットとして XML を使用するかもしれません。

ESB には現在、まったく異なる形式のサービスを用いるアプリケーション同士を接続するためのコア機能がいくつも用意されていますが、それぞれのアプリケーションが ESB に接続するために使用しているのはアプリケーションごとに固有のポート・タイプです (図 1)。あるアプリケーションが使用するポート・タイプは、そのアプリケーションが使用する通信プロトコルとメッセージ・フォーマットのタイプによって決まります。アプリケーションがそれぞれに固有のポート・タイプを使用することに関しては、いくつかの問題があります。これらの問題とそれに伴う不都合については、連載第 1 回の今回の記事の後ろの方で説明します。

図 1. アプリケーションごとに固有のポート・タイプを使用して ESB に接続する
ESB を介して接続されたアプリケーション

次のセクションでは、ESB を紹介します。その一環として、アプリケーション間をポイント・ツー・ポイントで接続することによる必然的な問題と、そうした問題を解決するには ESB を使用するのがいかに有効であるかを概説します。その次のセクションでは、現在の ESB が抱える問題として、さまざまなアプリケーションがそれぞれ異なるポート・タイプを使用して ESB に接続することに伴う各種の問題について説明します。そして最後のセクションでは、この記事の締めくくりとして、記事で説明した内容をいくつかに簡単にまとめます。

ESB のコア機能

ESB について紹介するこのセクションでは、ESB の 3 つのコア機能について簡単に説明するのに加え、異なるサービスを提供するアプリケーション同士が、ポイント・ツー・ポイント接続で接続することに関連する問題についても簡単に説明します。

接続のスケーラビリティーとルーティング

ここで、6 つのアプリケーションの統合を必要とする中規模の企業について考えてみましょう。これら 6 つのアプリケーションを互いに接続するための接続概略図を図 2 に示します。

図 2. ポイント・ツー・ポイントの統合方式で 6 つのアプリケーションを接続する
ポイント・ツー・ポイント接続で互いに接続されたアプリケーション

この図を見ると、この場合に必要な接続数が 15 であることがわかります。15 という数は、これらのアプリケーションを統合する際のアプリケーションのペアの数と同じです。同様に、アプリケーションの数が 10 の場合には、必要な接続数が 45 であると示すことができます。このようにアプリケーションの数と必要な接続数との関係は、アプリケーションの数が増加するにつれて、必要な接続数は非直線的な形で瞬く間に爆発的に増加する、と言うことができます。これではどのようなネットワークもふさがってしまうため、(猫などが飲み込んだ毛が胃や腸にたまってできる塊の「毛球」になぞらえて) この問題は毛球問題と呼ばれています。実際、ある企業が N 個のアプリケーションを統合する場合、ポイント・ツー・ポイント方式に必要な接続数は以下のように表すことができます。

N(N-1)/2

アプリケーションのペアの数も N(N-1)/2 であるため、上記は容易に理解することができます。従って、ポイント・ツー・ポイントの統合方式は大規模な企業での統合には適しておらず、スケーラビリティーに優れた別のソリューションを見つける必要があると言えます。

ESB は接続のスケーラビリティーの問題に対する優れたソリューションとなるため、大量のアプリケーションの統合を必要とする中規模から大規模の企業に適しています。ESB を介したやり取りでは、アプリケーション同士が直接やり取りすることはありません。直接やり取りする代わりに、さまざまなアプリケーションがバスに接続され、バスがアプリケーション間の接続手段となります。この間接的なやり取りを示したものが図 1 です。図 1 には、ESB を介して互いにやり取りする 6 つのアプリケーションが示されています。図 1 で注目すべき最も重要な点は、必要な接続数が 6 のみであることです。この数はポイント・ツー・ポイント方式で 6 つのアプリケーションを接続する場合に必要な接続数 (つまり 15) よりも大幅に少なくなっています。図 1 でもう 1 つ重要な点は、必要な接続数が統合対象のアプリケーションの数と同じであるということです。そのため、アプリケーションが 10 個の場合には、必要な接続数は 10 のみとなります。これはポイント・ツー・ポイント方式で必要な接続数 (つまり 45) よりも非常に小さな数です。

ESB はコンテンツ・ベースでコンテキスト・ベースのルーティングを提供することで、アプリケーションを間接的に接続することができます。従って、リクエスト側のアプリケーションはターゲット・アプリケーションのアドレスを知る必要がなく、さらには、どのアプリケーションがサービスを提供しているのかを知る必要すらありません。

プロトコルの不一致とプロトコルの変換

大規模な企業では、異なるアプリケーションには異なる通信プロトコルを使用するのが通常であるため、通信プロトコルの不一致の問題が起こります。つまり、大規模な企業では実際に、HTTP、HTTPS、JRMP、IIOP、JMS を始めとする、さまざまな通信プロトコルが使われているということです。そのため、サービス・コンシューマー・アプリケーションとサービス・プロバイダー・アプリケーションとの間でプロトコルが一致しない場合があり、1 つの通信プロトコルを別の通信プロトコルに変換する機能がない限り、サービス・コンシューマー・アプリケーションはサービス・プロバイダー・アプリケーションが提供するサービスを呼び出すことができません。この問題を図に示したものが図 3 です。

図 3. プロトコルの不一致の問題
プロトコルの不一致の問題

従って、ESB に必要なもう 1 つのコア機能は、あるプロトコルを別のプロトコルに変換することができるプロトコル変換機能です。この変換機能により、異なるプロトコルを使用するアプリケーションが互いにやり取りすることができます。重要な注意点として、現在入手可能な商用の ESB では、既にプロトコル変換機能がサポートされています。例えば、同期メッセージ交換に使用される HTTP を MQ 非同期メッセージに変換することは非常に一般的です。この場合には相関 ID を使用してリクエストとレスポンスの MQ メッセージを結びつけます。

メッセージとデータに関するフォーマットの不一致と変換

異種混成によるもう 1 つの問題として、データとメッセージに関するフォーマットの不一致の問題があります。この問題は、サービス・コンシューマーが提供するデータ・フォーマットとサービス・プロバイダー・アプリケーションが必要とするデータのフォーマットとが完全に一致しない場合がある、という事実を指します。この問題がある場合、アプリケーション同士がやり取りすることはできません。これを図に示したものが図 4 です。

図 4. データ・フォーマットの不一致の問題
データ・フォーマットの不一致の問題

従って、ESB に必要なさらにもう 1 つのコア機能は、データまたはメッセージの変換機能です。入手可能な商用の ESB の大部分では、さまざまな手法を使用してこの機能を提供しています。例えば、XML スタイルシートを使用することで、SOAP を含むさまざまな形式の XML 間の変換をすることができます。この機能と ESB が持つ他の 2 つの機能と組み合わせると、たとえインターフェースやプロトコルが完全には一致しない場合でも、複数のアプリケーションを容易に接続することができ、それらのアプリケーション同士は容易にやり取りできるようになります。

他の多種多様な機能

これら 3 つの機能要件を満たすことに加え、ESB はパフォーマンスと信頼性、監査、セキュリティーなど、非機能要件を満たすためのサービスも実装します。さらに商用 ESB 製品の多くは、他にも、データ強化、メッセージの配布、相関、モニタリングなどのオプション・サービスを提供しています。

これらの機能要件や非機能要件は、1 つの製品で満たすことも、一連の製品によって満たすこともできます。つまり ESB は基本的に 1 つのパターンであり、必ずしも 1 つの製品として実装しなければならないものではありません。

現在の ESB が抱える問題

現在の ESB では、図 1 のように各アプリケーションはアプリケーションごとに固有のポート・タイプを使用して ESB に接続されます。ポート・タイプは、アプリケーションが機能を公開するために使用するサービスのタイプによって決まります。例えば Web サービスを通じて機能を公開するアプリケーションの場合、そのアプリケーションで使用するポート・タイプは、通信プロトコルが HTTP に対応し、メッセージ・フォーマットが SOAP に対応していなければなりません。言い換えると、アプリケーションはアプリケーションごとに固有のポート・タイプを使用して ESB に接続する必要があり、そのポート・タイプはアプリケーションで使用される通信プロトコルとメッセージ・フォーマットによって決定されます。この方法、つまりアプリケーションごとに固有のポート・タイプを使用してアプリケーションを接続する方法は、さまざまな理由から面倒な上に不都合です。その理由の一例を以下に記載します。

  • 要件やランタイム環境の変更により、アプリケーションの通信プロトコルを切り換えたい場合がよくあります。しかしそのためには ESB 側のポート・タイプも変更する必要があり、またほとんど必ずと言ってよいほど、別のポート・タイプも作成する必要があります。当然ですが、そのためには時間とリソースが必要になります。
  • さまざまな機能を公開するために、アプリケーションに複数のプロトコルを使いたい、という状況がよくあります。こうした状況は、メインフレームの COBOL アプリケーションによく見られます。この場合では、アプリケーションは Web サービスを使用して一部の機能を公開する一方、同時に MQ などのメッセージング・プロトコルを使用して別の一連の機能を公開します。この場合にも、ESB 側に新しいポート・タイプを作成することで両方のプロトコル・タイプに対応する必要があります。この方法は時間とリソースの両方が必要なため、非常に不都合です。
  • 現在の ESB では、新たに作成された通信プロトコルを使用できるように ESB を拡張することは極めて困難です。なぜなら、アプリケーション側と ESB 側の両方に変更が必要なためです。ESB 側では、まったく新しいポート・タイプを作成する必要があります。
  • 各アプリケーションは特定のポート・タイプを使用して ESB に接続する必要があるため、アプリケーションで使用できるように ESB を構成するためには、かなりの作業が必要です。具体的な作業として、新しいポート・タイプを作成して ESB にデプロイし、その特定のポートを使用できるように ESB を構成する必要があります。こうしたことから、ESB を使用して大量のアプリケーションを接続するのは困難であり、そのためスケーラビリティーの問題に突き当たります。
  • また、各ポートを別々にデプロイして構成する必要があるため、ESB の保守や更新が困難です。

まとめ

今回の記事では、まったく異なる形式の SOA サービスを使用するアプリケーションを統合する際の問題について説明し、そうした問題に現在の ESB のコア機能はどのように対処しているかを説明しました。さらに、現在の ESB にはさまざまなポート・タイプを使用することに関連する問題があることも説明しました。現在の ESB は、これらの問題に対応できていません。

次回の記事では、現在の ESB の欠点を克服するための方法として、新しいタイプの ESB について説明します。この新しいタイプの ESB は 1 つのユニバーサル・ポート・タイプを使用します。このユニバーサル・ポート・タイプは、まったく異なるサービス・タイプを使用して機能の一部またはすべてを公開するようなアプリケーションの大部分またはすべてに対応することができます。そのため、新しいタイプのアプリケーションごとに新しいポート・タイプを作成、デプロイする必要がなくなるか、もしくはその必要性が大幅に低下します。この新しいユニバーサル・ポート・タイプには、従来よりもコードの再利用が大幅に増えるなど、数多くのメリットがあります。ユニバーサル・ポート・タイプを使用することによるメリットについては、今後の記事で詳細に説明します。

参考文献

学ぶために

製品や技術を入手するために

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=SOA and web services
ArticleID=758650
ArticleTitle=エンタープライズ・サービス・バスのための、USB に似たユニバーサル・ポート・タイプ: 第 1 回 ESB が現在抱えている問題
publish-date=09302011