エンタープライズ・サービス・バスのための、USB に似たユニバーサル・ポート・タイプ: 第 2 回 概念、プロセス、そして実装

ESB のためのユニバーサル・ポートの概念と実装について学ぶ

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

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年 12月 09日

はじめに

SOA (Service Oriented Architecture) において、エンタープライズ・サービス・バス (Enterprise Service Bus: ESB) はインフラストラクチャーを構成する極めて重要なコンポーネントです。ESB はアプリケーション同士を接続するための効率的な手段です。ESB を介して接続されるアプリケーションは、まったく異なる形式のサービスを使用して、そのアプリケーションの機能の一部またはすべてを公開します。現在の ESB を図で示したものが図 1 です。この図で注目すべき最も重要な点は、各アプリケーションが固有のポート・タイプを使用して ESB に接続されている点です。つまり、各ポート・タイプは特定のタイプのアプリケーション専用であり、それらのアプリケーションは特定の通信プロトコルとメッセージまたはデータ・フォーマットを使用して、そのアプリケーションの機能を公開します。

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

この連載の第 1 回の記事では、現在の ESB の基本機能について説明しました。これらの機能には、コンテンツ・ベースでコンテキスト・ベースのルーティング、プロトコル変換、データやメッセージのフォーマット変換などがあります。また第 1 回では、現在の ESB を使用する上での一般的な問題のいくつかについても説明しました。これらの問題や不都合としては、1 つのアプリケーションで複数の通信プロトコルを使用する場合や 1 つのアプリケーションで複数の通信プロトコルを切り換える場合への対応、新しい通信プロトコルを使用できるように ESB の使い方を拡張する方法、大量のアプリケーションに対応するためのスケーラビリティー、ESB に関する一般的な保守と更新の問題、などがあります。

第 2 回となる今回の記事では、ユニバーサル・ポート・タイプを使用する新しいタイプの ESB を紹介します。それぞれのセクションで説明する内容としては、次のセクションではユニバーサル・ポートの基本概念について、その次のセクションでは ESB を実装するための一般的なプロセスについて、さらに次のセクションでは接続されるアプリケーションに使用される通信プロトコルを検出するための 2 つの方法について、そして最後のセクションではこの記事の締めくくりとして、記事で説明した内容を簡単にまとめます。

ユニバーサル・ポートの概念

この連載の前回の記事、第 1 回で概要を説明した現在の ESB の欠点を克服するために、ここでは新しいタイプの ESB を提案します。この新しいタイプの ESB では、ほとんどのタイプのアプリケーション、またはすべてのタイプのアプリケーションに対応可能な、1 つのユニバーサル・ポート・タイプを使用します (図 2)。このユニバーサル・ポート・タイプにより、新しいタイプのアプリケーションごとに新しいポート・タイプを開発してデプロイする必要がなくなり、コードの再利用を大幅に増やすことができます。

図 2. 複数のアプリケーションが 1 つのポート・タイプ (ユニバーサル・ポート) を使用して ESB に接続する様子
複数のアプリケーションが 1 つのポート・タイプ (ユニバーサル・ポート) を使用して ESB に接続する様子

ユニバーサル・ポート・タイプの概念を理解するために、PC などのコンピューターのハードウェアを考えてみるとわかりやすいでしょう。USB ポートが登場する前には、さまざまな機器 (プリンター、フラッシュ・メモリー、リムーバブル・ハードディスクなど) をコンピューターに接続するために、さまざまなタイプのポートがコンピューターに必要でした。それぞれのタイプのポートは特定の種類の機器に専用でした。そのため、プリンターをコンピューターに接続するためには専用のタイプのポートをコンピューターに用意する必要がありました。同様に、追加のハードディスクを接続するためには異なるタイプのポートがコンピューター上に必要でした。しかし最近では、USB ポートが発明されたことにより、機器の種類ごとに別のタイプのポートを用意する必要がなくなり、今やほとんどすべての機器を USB ポートという 1 つのタイプのポートを使用してコンピューターに接続することができます。

プロセス

ユニバーサル・ポートを備えた ESB を扱うための一般的なプロセスを示したものが図 3 です。このプロセスは以下のステップで構成されています。

  1. あるアプリケーションが USB ポートに似たポートを介して ESB に接続してメッセージを送信すると、プロセスが開始されます。このメッセージのフォーマットは任意であり、またこのメッセージの送信に使用されるプロトコルも任意です。
  2. このメッセージはプロトコルを検出するソフトウェア・コンポーネントによってインターセプトされ、このメッセージを基にアプリケーションでどの通信プロトコルを使用するかが決定されます。
  3. 通信プロトコルが決定されると、インターセプトされたメッセージは適切なプロトコル処理コンポーネントに送信されます。システムには、指定されたプロトコルごとに 1 つのプロトコル処理コンポーネントが用意されることに注意してください。つまり、HTTP、SMTP、IIOP、等々のプロトコルごとに別個のプロトコル処理プログラムを用意することになります。これらのプロトコル処理プログラムの目的は、アプリケーションで使用されるプロトコルには依存しない、メッセージの本体を抽出することです。
  4. 抽出されたメッセージは次に、フォーマット・ディテクターと呼ばれる別のソフトウェア・コンポーネントに送られます。このソフトウェア・コンポーネントがメッセージ・フォーマットを判定します。メッセージ・フォーマットの例としては、SOAP、(生の) XML、copybook 等々があります。
  5. フォーマット・ディテクター・コンポーネントはメッセージ・フォーマットを判定すると、そのメッセージを (一般的な) 正規フォーマットに変換する適切なコンポーネントに転送します。
  6. 次に、その正規フォーマットは変換ソフトウェア・コンポーネントによってターゲット・フォーマットに変換されます。このターゲット・フォーマットは対象となるアプリケーションのタイプに依存します。
  7. 次に、変換ソフトウェア・コンポーネントは、そのメッセージをターゲット・プロトコル生成コンポーネントに送信します。そのメッセージを受信すると、ターゲット・プロトコル生成コンポーネントはターゲット・フォーマットになったメッセージを使用してターゲット・プロトコルを生成します。
  8. 最後に、ターゲット・プロトコル生成コンポーネントはそのメッセージをターゲット・アプリケーションに送信します。
図 3. ユニバーサル・ポート・タイプを使用して ESB を実装するプロセス
ユニバーサル・ポート・タイプを使用して ESB を実装するプロセス

クリックして大きなイメージを見る

図 3. ユニバーサル・ポート・タイプを使用して ESB を実装するプロセス

ユニバーサル・ポート・タイプを使用して ESB を実装するプロセス

上記のステップの大部分 (3 から 8) は、ポート・コンポーネントの外で、しかも ESB の本体内で実行できることに注意してください。ステップ 3 から 8 を ESB 本体内に移動すると、より多くのコードを再利用できるようになります。ユニバーサル・ポートに残された仕事は、接続されるアプリケーションで使用される通信プロトコルを判断することのみです。これを図で示したものが図 4 です。つまりユニバーサル・ポートは非常に軽量のコンポーネントです。次のセクションでは通信プロトコルを判断するための 2 つの方法について説明します。

図 4. ユニバーサル・ポートは軽量のコンポーネントであり、ほとんどの処理が ESB 本体内で行われる様子
軽量のコンポーネントであるユニバーサル・ポート

通信プロトコルを検出する

では、ユニバーサル・ポートを軽量のソフトウェア・コンポーネントとして実装するための 2 つの新しい方法について説明します。

スーパー・プロトコルによる方法

第 1 の方法では、上位レベルの各プロトコルに対するエンベロープとして使用されるスーパー・プロトコル、つまりメタ・プロトコルを導入します。スーパー・プロトコルのエンベロープには、アプリケーションに使用される上位レベルのプロトコルのタイプ (HTTP、IIOP、JRMP、JMS/MQ など) に関する情報を含むヘッダーが含まれています。このヘッダーは、接続されるアプリケーションによってメッセージの最初の行に含められます。メッセージのそれ以外の部分には、上位レベルのプロトコルのヘッダーと、実際のメッセージの内容が含まれます。このスーパー・プロトコルを使用する場合には、ユニバーサル・ポートは受信したメッセージの最初の行のみを構文解析すればよく、その解析により、接続されるアプリケーションに使用される上位レベルのプロトコルを判断することができます。上位レベルのプロトコルを判断したら、ユニバーサル・ポートを構成するソフトウェア・コンポーネントは ESB 本体内で処理を行う適切なプロトコル・リスナーに対し、そのメッセージを単純に転送します。つまりユニバーサル・ポートは、メッセージの最初の行を読み取らなければならないというだけの非常に軽量のソフトウェア・コンポーネントです。また、上位レベルのプロトコルのリスナーは、そのそれぞれが ESB 本体の一部であり、任意の数のユニバーサル・ポート・コンポーネントで使用できるため、それらリスナーのコードを十分再利用することができます。この方法による小さな欠点として、このスーパー・プロトコルを使用できるようにアプリケーションのコードを少し変更する必要があります。

上位レベル・プロトコル (HTTP) のエンベロープとしてスーパー・プロトコルを使用する例を以下に示します。

リスト 1. HTTP など上位レベル・プロトコルのエンベロープとしてスーパー・プロトコルを使用するコードの例
Protocol: HTTP   Format: SOAP
GET /intro.html HTTP/1.1
User-Agent: Mozilla/5.0 (Windows;en-GB;...
Accept: text/*,image/jpeg, */*
Accept-Language: en-gb
...
...

必要な情報は最初の行に含まれているため、ユニバーサル・ポートのコードは最初の行を構文解析するだけで、使用されている上位レベルのプロトコルを判断することができます。この情報を検出すると、ユニバーサル・ポートのコードは単純に ESB 本体内にある適切なプロトコル処理プログラムを呼び出します (図 4)。

ソケット・レベルの検出

最初のセクションで触れた問題に対応するための第 2 の方法は、HTTP、IIOP、JRMP、JMS/MQ などの上位レベルのプロトコルがすべて TCP/IP の上に構築されていることに着目します。つまりこれらのプロトコルはすべて、その下位レベルでは TCP/IP ソケットを使用することによってアプリケーションと ESB との間の通信を実現しています。また、これらのプロトコルにはすべてヘッダーが含まれており、これらのヘッダー内の情報を利用することで、接続されるアプリケーションに使用される上位レベルのプロトコルを検出することができます。受信したメッセージをソケット・レベルで読み取れば、これらのヘッダーを読み取って明らかにすることができます。つまりこの方法では、受信したメッセージをソケット・レベルでリッスンすることによってプロトコルを検出します。ユニバーサル・ポートは、メッセージの最初のヘッダーまたは最初の行を読み取って、そのメッセージを ESB 本体内の適切なプロトコル・リスナーに転送するだけでよいため、非常に軽量のコンポーネントになります。最初に紹介した方法と同様、この方法の場合もコードの再利用を大幅に増やすことができます。各プロトコル・リスナーは ESB 本体内の一部であり、同じプロトコル・リスナーを任意の数のユニバーサル・ポートで使用することができるからです。

この方法の使い方を説明するために、使い方の例を紹介しましょう。この例ではリクエストを HTTP で受信するものとします。ソケット・レベルでリクエストを読み取る場合、受信する HTTP リクエストのヘッダーは以下のようになります。

リスト 2. ソケット・レベルで検出する
GET /intro.html HTTP/1.1
User-Agent: Mozilla/5.0 (Windows;en-GB;...
Accept: text/*,image/jpeg, */*
Accept-Language: en-gb
...
...

これらのヘッダーの中で注目すべき最も重要な項目は、1 行目にある最初のヘッダーです。このプロトコルでは、このヘッダーは必須です。このヘッダーの中に HTTP という文字列があることも必須です。つまり、最初の行を見ただけで、このプロトコルが HTTP であると判断することができます。また、この特定のプロトコルは短い特別な単語で始まります。そうした特別な単語には、GET、PUT、DELETE などがあります。つまり、受信したリクエストの最初の行の最初の単語を調べ、その単語が一連の短い単語の 1 つである場合には、受信したリクエストが HTTP プロトコルを使用していると判断することができます。

ソケット・レベルでのメッセージの読み取りは、一般的なほとんどのプログラミング言語 (Java や C++ など) で非常に容易に行うことができます。ここではサンプル・コードとして、この目的に使用できる Java コードのスニペットを以下に示します。

リスト 3. ソケット・レベルでメッセージを読み取るためのコード
import java.io.*;
import java.net.*;

public class testServer {

//declare a socket server and a socket //client
SocketServer myServer = null;
ClientServer myClient = null;

//declare an input stream and an output //stream
DataInputStream in;
PrintStream out;

//declare a variable to hold the first //line of the incoming message
String firstLine = null;

//open a socket for listening at the port //number 8080
myServer = new ServerSocket (8080);
//accept connection
myClient = myServer.accept();

//get the incoming message
in = new DataInputStream ( myClient.getInputStream());

//store the first line of the message in a //local variable
firstLine = in.getLine();


...
...

}

上記のコードで、接続されるアプリケーションに使用される上位レベルのプロトコルを判断するために必要なヘッダー情報は、変数 firstLine に含まれていることに注意してください。この単純で簡潔なコードによってユニバーサル・ポートは軽量になり、図 4 に示すように、ユニバーサル・ポートは ESB 本体内にある適切なプロトコル・リスナー兼プロトコル処理プログラムを呼び出します。またこの結果、各プロトコル・リスナー兼プロトコル処理プログラムを多くの異なるユニバーサル・ポートで使用できるようになるため、コードの再利用を大幅に増やすことができます。

まとめ

今回の記事では、ESB のためのユニバーサル・ポートの概念について説明しました。ユニバーサル・ポートを使用することで、ほとんどすべてのアプリケーションを ESB に接続することができるため、これにより、ESB に接続される他の任意のアプリケーションにも間接的に接続することができます。アプリケーションは任意のタイプの通信プロトコルやメッセージ・フォーマットを使用できる一方、使用するポートは、このユニバーサル・ポートという 1 つのタイプのみです。

また今回の記事ではユニバーサル・ポートの実装プロセスについても説明しました。このプロセスの中で、ユニバーサル・ポートは軽量のコンポーネントであり、接続するアプリケーションで使われている通信プロトコルを検出する機能しかない、という重要な点を忘れないでください。また今回の記事では、アプリケーションで使われている通信プロトコルを検出するための 2 つの異なる方法についても説明しました。

次回の記事では、ESB にユニバーサル・ポートを使用することによる数多くのメリットについて説明します。

参考文献

コメント

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=778796
ArticleTitle=エンタープライズ・サービス・バスのための、USB に似たユニバーサル・ポート・タイプ: 第 2 回 概念、プロセス、そして実装
publish-date=12092011