はじめに

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

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

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

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

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

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

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

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

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

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

上位レベル・プロトコル (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 リクエストのヘッダーは以下のようになります。

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 コードのスニペットを以下に示します。

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 にユニバーサル・ポートを使用することによる数多くのメリットについて説明します。

参考文献

• 最新の書籍『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 が提供する支援について知ることができます。
  
  

著者について

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

この記事を評価する

コメント

上に戻る

目次

• はじめに
• ユニバーサル・ポートの概念
• プロセス
• 通信プロトコルを検出する
• まとめ
• 参考文献
• 著者について
• コメント