はじめに

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 回の今回の記事の後ろの方で説明します。

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

ESB のコア機能

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

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

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

この図を見ると、この場合に必要な接続数が 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 です。

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

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

異種混成によるもう 1 つの問題として、データとメッセージに関するフォーマットの不一致の問題があります。この問題は、サービス・コンシューマーが提供するデータ・フォーマットとサービス・プロバイダー・アプリケーションが必要とするデータのフォーマットとが完全に一致しない場合がある、という事実を指します。この問題がある場合、アプリケーション同士がやり取りすることはできません。これを図に示したものが図 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 つのユニバーサル・ポート・タイプを使用します。このユニバーサル・ポート・タイプは、まったく異なるサービス・タイプを使用して機能の一部またはすべてを公開するようなアプリケーションの大部分またはすべてに対応することができます。そのため、新しいタイプのアプリケーションごとに新しいポート・タイプを作成、デプロイする必要がなくなるか、もしくはその必要性が大幅に低下します。この新しいユニバーサル・ポート・タイプには、従来よりもコードの再利用が大幅に増えるなど、数多くのメリットがあります。ユニバーサル・ポート・タイプを使用することによるメリットについては、今後の記事で詳細に説明します。

参考文献

学ぶために

• 最新の書籍『SOA-Based Enterprise Integration』は、SOA と Web サービスに関して順を追って説明した優れた資料です。
  
  
• developerWorks の SOA and Web Services ゾーンには、技術記事、チュートリアル、技術標準など、Web サービスと SOA のための技術リソースが豊富に用意されています。
  
  
• ESB の基本に関する非常に優れた資料として、『SOA-Based Enterprise Integration』の第 8 章があります。
  
  
• ESB の基本を説明した別の優れた資料として、developerworks の記事、「Services-based enterprise integration patterns made easy, Part 4: Enterprise service bus」があります。
  
  
• IBM の誇る ESB 製品、WebSphere Message Broker (WMB) に関して知るために、Message Broker Information Site を訪れてください。
  
  
• IBM の安価な ESB 製品について知るために、WebSphere Enterprise Service Bus を訪れてください。
  
  
• ハードウェア・ベースの ESB 製品について知るために、WebSphere DataPower SOA アプライアンスを訪れてください。
  
  
• HTTP などの通信プロトコルについて学ぶために、HTTP のサイトを訪れてください。
  
  
• SOAP メッセージ・フォーマットについて知るための優れた資料として、ウィキペディアの SOAP の項目があります。
  
  
• IBM SOA のエントリー・ポイント、IBM SOA Sandbox を試し、実用的で実践的な経験をとおして SOA のスキルを磨いてください。
  
  
• IBM SOA の Web サイトでは、SOA の概要と、SOA を実現するために IBM が提供する支援について知ることができます。
  
  
• Technology bookstore には、この記事や他の技術的な話題に関する本が豊富に取り揃えられています。
  
  

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

• IBM 製品の評価版をダウンロードするか、あるいは IBM SOA Sandbox のオンライン試用版で、DB2、Lotus、Rational、Tivoli、WebSphere などが提供するアプリケーション開発ツールやミドルウェア製品を試してみてください。
  
  

議論するために

• developerWorks blogs から developerWorks のコミュニティーに加わってください。
  
  

著者について

Waseem 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』を単著として執筆しました。

この記事を評価する

コメント

上に戻る

目次

• はじめに
• ESB のコア機能
• 現在の ESB が抱える問題
• まとめ
• 参考文献
• 著者について
• コメント