この記事の目的は、ESB (Enterprise Service Bus) の機能テストの方法とパフォーマンス・テストの方法を紹介することです。このテストの方法は、実際の顧客のプロジェクトの例を基にまとめたものであり、実証済みの方法です。

Yu Hong Song, Test Lead, IBM

Yu Hong SongYu Hong Song は IBM China のテスト・リーダーです。彼女は 2007年に修士のソフトウェエア・エンジニアとして IBM に入社しました。彼女は GBS の Global Business Solution Center (GBSC) のメンバーです。現在は ITS ソリューションのテストに従事しています。



Tao (Jerry) Liu, Advisory I/T Architect, IBM

Tao (Jerry) LiuTao (Jerry) Liu は IBM China 認定の IT アーキテクトです。彼は 2003年に修士の研究エンジニアとして IBM に入社しました。彼は GBS の Global Business Solution Center (GBSC) のメンバーです。現在は一般技術実用化イニシアチブの ESB 資産の業務に従事しています。



Jingfeng Zhang , Software Engineer, IBM

Jingfeng Zhang Jingfeng Zhang は IBM China のソフトウェア・エンジニアです。彼はソフトウェア開発に 7 年以上の経験があり、IBM には 2007年に入社しました。彼の主な担当領域は、J2EE、MQ、WMB、SOA、ESB、EAI です。彼は Global Business Solution Center (GBSC) のメンバーです。



2009年 11月 30日

ESB の機能テストの方法

図 1 に示すように、サービス指向アーキテクチャーの内部では、サービス・リクエスターとサービス・プロバイダーが ESB を介して互いに通信します。ESB の主な機能は、メッセージの変換、プロトコルの変換、そしてサービスのルーティングです。この ESB をミドルウェアとして使用した統合ルーチンを作成すれば、このルーチンを使用してサービス・リクエスターとサービス・プロバイダーを仲介することができます。この記事では、これらの統合ルーチンをテストする方法として、ESB の機能検証テストを行うさまざまな方法をまとめました。ESB ミドルウェアの例としては、WebSphere Message Broker を取り上げ、私達がテストを行う上で従った指針について説明します。

図 1. SOA でのサンプル・メッセージとネットワーク・プロトコル
SOA でのサンプル・メッセージとネットワーク・プロトコル

JMS から Web サービスへのメッセージ・フロー

図 2 は、ESB 内での JMS (コンシューマー) と Web サービス (プロバイダー) との相関関係に関するメッセージ・フローを表しています。サービス・リクエスターが ESB にリクエストを送信すると、ESB はそのリクエストを SOAP メッセージに変換し、目的の Web サービスへ転送することで、Web サービス (プロバイダー) を呼び出します。プロバイダーが SOAP レスポンス・メッセージを ESB に送信すると、ESB はそのメッセージを XML に変換してリクエスターのレスポンス・キューに返送します。

図 2. メッセージ・フロー 1
メッセージ・フロー 1

メッセージ・フローの機能をテストするには、まず始めに、メッセージ・フローのテスト・ブランチを特定する必要があります。図 2 には 2 つの有効なブランチがあります。1 つのブランチはリクエスターのリクエスト・キューにメッセージを送信し、リクエスターのレスポンス・キューからレスポンス・メッセージを受信しています。もう 1 つのブランチは、リクエスターのリクエスト・キューにメッセージを送信し、リクエスターのレスポンス・キューからフォルト・メッセージを受信しています。

次に、異なるそれぞれのブランチに対し、異なる種類の入力メッセージを作成する必要があります。例えば第 1 のブランチの場合、作成する入力 XML メッセージは、それぞれが異なる種類の SOAP メッセージに変換されるようなものにし、異なるレスポンスをサービスから受信するようにします。テスト入力を設計する際には、入力の境界と分類を考慮する必要があります。第 2 のブランチの場合、無効な入力 XML メッセージを作成し、そのメッセージがサービスに対して無効な SOAP メッセージに変換されるようにします。

そして最後に、メッセージ・フローの機能を検証するためにテスト・ケースを作成します。テスト・ケースでは、まず始めにリクエスターのリクエスト・キューをクリアーし、そのキューに入力メッセージを送信します。入力メッセージは ESB で SOAP リクエスト・メッセージに変換され、図 2 のチェックポイント 1 では、その SOAP メッセージが想定どおりのメッセージに変換されているかどうかを検証します。図 2 のチェックポイント 2 では、テスト・クライアントはリクエストのレスポンス・キューからレスポンス/フォルト・メッセージを取得し、そのメッセージが想定されたとおりのものであるかどうかをチェックします。

Web サービスから JMS へのメッセージ・フロー

Web サービスから JMS への相関メッセージ・フローを図 3 に示します。Web サービス (コンシューマー) が SOAP リクエスト・メッセージを ESB に送信すると、ESB はその SOAP メッセージを XML メッセージに変換し、そのメッセージをプロバイダーのリクエスト・キューに送信します。リクエスト・メッセージを取得したサービス・プロバイダーは、レスポンス・メッセージを ESB に送信します。ESB はレスポンス・メッセージを Web サービスの SOAP レスポンスとして SOAP メッセージに変換します。この種のフローのテストを自動で行えるようにするために、プロバイダーのレスポンス・メッセージを返送するプロバイダー・シミュレーターを実装します。

図 3. メッセージ・フロー 2
メッセージ・フロー 2

図 3 のメッセージ・フローは 2 つのテスト・ブランチと考えることができます。1 つのブランチでは、SOAP リクエスト・メッセージが無効であり、ESB は例外を処理し、リクエストに失敗したという結果をレスポンスとして送信します。もう 1 つのブランチでは、Web サービスは ESB を介して有効な SOAP リクエスト・メッセージを送信し、有効な SOAP レスポンス・メッセージを受信します。

例外ブランチに対する入力メッセージは、さまざまな例外の状況をカバーするように作成する必要があります。そして有効なブランチに関しては、カバレッジに対する入力 SOAP メッセージを作成する際に入力境界と分類を考慮する必要があります。

図 3 に示すように、有効なフローに対するテスト・ケースには 2 つのチェックポイントがあります。SOAP リクエストが XML メッセージに変換されると、テスト・クライアントはそのメッセージを取得し、XML が適切に変換されているかどうか、その内容がサービス・プロバイダーの要件を満たしているかどうかを検証します。そしてもう 1 つのチェックポイントは、変換された SOAP レスポンス・メッセージが正しいかどうかを検証します。無効なブランチの場合には、チェックポイント 2 を検証する必要があります。テスト・クライアントは、フォルト・レスポンスという結果が適切に生成されたかどうかを検証する必要があります。

MQ/JMS から MQ/JMS へのメッセージ・フロー

メッセージを ESB によって、あるキューから別のキュー (Local/Remote) に転送することもできます。図 4 は、片方向のメッセージ・フローを示しています。この場合の入力メッセージは、メッセージが適切に転送されることを検証できるように作成します。入力メッセージがコンシューマーのリクエスト・キューに送信されると、ESB によって変換、転送が行われます。テスト・クライアントはプロバイダーのリクエスト・キューからメッセージを取得し、そのフォーマットが適切に変換されていること、またメッセージの内容が正常に転送されていることを検証します。

図 4. メッセージ・フロー 3
Message Flow 3

ESB 内での相関メッセージのフローを図 5 に示します。サービス・コンシューマーが JMS によるサービス・リクエストを送信すると、そのリクエスト・メッセージは ESB によって変換、転送が行われます。サービス・プロバイダーはプロバイダーのリクエスト・キューからメッセージを取得し、それに対するレスポンス・メッセージをプロバイダーのレスポンス・キューに返送します。すると、ESB はレスポンス・メッセージをサービス・コンシューマーに転送します。テスト・ケースは、このフローをカバーするように作成します。

入力メッセージは契約スキーマに基づいて作成されます。テスト・クライアントは、プロバイダーが適切なメッセージを受信したかどうかをチェックポイント 1 で検証します。テスト・クライアントはレスポンス・メッセージを返送するために作成したシミュレーターを使用します。チェックポイント 2 では、コンシューマーのレスポンス・キューから取得したメッセージに関して、フォーマットと内容が想定どおりかどうかを検証します。

図 5. メッセージ・フロー 4
メッセージ・フロー 4

FTP から FTP へのメッセージ・フロー

コンシューマーからプロバイダーに対し、ESB を介して FTP でファイルを転送することができます (図 6)。テスト・クライアントは専用のソース・フォルダーからファイルをアップロードします。ESB はそのファイルを、想定される宛先に転送します。テスト・クライアントはそれらのファイルを宛先から取得し、それらのファイルが入力ファイルと同じかどうかをバイト比較によってチェックします。変換機能を検証するために、サイズ 0 のファイル、通常のファイル、大きなサイズのファイルという 3 種類の入力ファイルを作成します。

図 6. メッセージ・フロー 5
メッセージ・フロー 5

FTP から JMS へのメッセージ・フロー

図 7 は、FTP から JMS に変換する例を示しています。ESB は FTP によってファイルを受け取り、そのファイルをメッセージに変換してプロバイダーのキューに送信します。テスト・クライアントは、異なる種類のファイル (サイズ 0、通常のサイズ、大きなサイズ) を入力として作成する必要があります。そして、変換されたメッセージを 2 つのキューから取得し、それらのファイルが正常に変換、転送されているかどうかを検証します。

図 7. メッセージ・フロー 6
Message Flow 6

ESB のパフォーマンス・テストの方法

並行ワークロードの制御

このパフォーマンス・テストでは、非常に厳しい条件下で対象メッセージ・フローのテストを行います。その条件とは、テストが開始されると同時にメッセージ・フローのすべてのリクエストがメッセージ・ブローカーに送信されるような状況です。例えば、IRS_CRM_AccountCreationRequest というメッセージ・フローにはピーク時間中に 1000 件のリクエストがあります。そしてテストが開始されると、この 1000 件のリクエストがすべて、続けざまにメッセージ・フローの入力キューに送信されます。同時に、それ以外に 20 件以上のメッセージ・フローから成るリクエスト・メッセージが、指定された宛先に送信されます。そのため、テスト開始時のメッセージ・フローには非常に高いストレスがかります。

片方向のメッセージ・フロー

片方向のメッセージ・フローには通常、1 つの MQ 入力ノードと 1 つの MQ 出力ノードが含まれています (図 8)。

図 8. 片方向のメッセージ・フロー
片方向のメッセージ・フロー

このテスト・スクリプトでは、リクエスト・キューに対して、あるリクエスト・メッセージの送信を開始した時のタイムスタンプを t0 と記録し、レスポンス・キューからレスポンス・メッセージを取得した時のタイムスタンプを t1 と記録します。他のリクエスト・メッセージも同様に記録し、メッセージ・フロー全体の応答時間を ∑ (t1-t0) として計算します。このフローで合計 m 件のメッセージを送信した場合、平均応答時間 (ast) は ast= ∑ (t1-t0)/m と計算することができます。

相関メッセージのフロー

相関メッセージのフローには通常、2 つの MQ 入力ノードと 2 つの MQ 出力ノードが含まれています (図 9)。

図 9. 相関メッセージのフロー
Correlation message flow

図の右側には、リクエスト・メッセージが与えられるとレスポンス・メッセージを作成する 1 つのシミュレーターが示してあります。このシミュレーターは、単純にリクエスト・メッセージの ID を使ってレスポンス・メッセージの相関 ID を設定し、そのレスポンス・メッセージをプロバイダーのレスポンス・キューに入れます。片方向のメッセージ・フローの場合と同様に、タイムスタンプ t0 と t1 を記録します。また、シミュレーターでメッセージを取得してからレスポンス・メッセージを作成して返送するまでにかかった合計時間を ds と記録します。このフローで合計 m 件のメッセージを送信するとします。すると平均応答時間は ast= (∑ (t1-t0)-ds) /m と計算することができます。

Web サービス・プロバイダーのメッセージ・フロー

Web サービス・プロバイダーのメッセージ・フローでは通常、SOAP リクエスト・メッセージを SOAP 入力ノードに送信し、SOAP レスポンス・メッセージを SOAP 応答ノードから受信します (図 10)。MQ 入力ノードと MQ 出力ノードは、変換されたメッセージをサービス・コンシューマーに送信するために、またコンシューマーからレスポンス・メッセージを受信するために使われます。

図 10. Web サービス・プロバイダーのメッセージ・フロー
Web サービス・プロバイダーのメッセージ・フロー

シミュレーターは、相関メッセージのフローの場合と同じようにサービス・コンシューマーとして動作し、レスポンス・メッセージを作成します。このフローでは、SOAP リクエスト・メッセージが送出される時のタイムスタンプ t0 と、SOAP 応答ノードからレスポンスを受信する時のタイムスタンプ t1 を記録します。そして、シミュレーターでメッセージを取得してからレスポンス・メッセージを作成して返送するまでにかかった合計時間を ds と記録します。すると、このフローで合計 m 件のメッセージを送信した場合、平均応答時間 (ast) は ast= (∑ (t1-t0)-ds) /m と計算することができます。

Web サービス・コンシューマーのメッセージ・フロー

Web サービス・コンシューマーのメッセージ・フローには通常、1 つの MQ 入力ノードと 1 つの MQ 出力ノードが含まれています (図 11)。Web サービス・ノードは MQ リクエスト・メッセージを受信し、MQ レスポンス・メッセージを MQ 出力ノードに送信します。

図 11. Web サービス・コンシューマーのメッセージ・フロー
Web サービス・コンシューマーのメッセージ・フロー

片方向メッセージ・フローの場合と同様に、タイムスタンプ t0 と t1 を記録します。Web サービス・シミュレーターでメッセージを取得してからレスポンス・メッセージを作成して返送するまでにかかった合計時間を ws と記録します。このフローで合計 m 件のメッセージを送信した場合、平均応答時間 (ast) は ast= (∑ (t1-t0)-ws) /m と計算することができます。


まとめ

この記事では機能テストとパフォーマンス・テストの方法について説明しました。このテスト方法は JUnit を使用して実装することができ、また自動的に実行することができます。この ESB システムは顧客の Road User Charging プロジェクトにデプロイされており、プロジェクトの中で重要な役割を果たしています。

参考文献

学ぶために

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

議論するために

コメント

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=460691
ArticleTitle=ESB をテストするためのベスト・プラクティス
publish-date=11302009