現在、多くのWebサイトを訪問すると、たいていの場合、複数のサーバー・ソフトウェア・アプリケーション・パッケージが使用されています。ユーザー毎にカストマイズされたコンテンツを提供する動的Webサイトでは、特にそうです。会社の内部ポータルの人事Webページにサイン・インする場合に、製造業者の出荷報告を調べるときと同じサイン・インが有効でしょうか?

舞台裏では、エンジニアたちのチームが、バックエンド・システムで相互操作を継続させるために懸命に努力しています。新規ハードウェア (ルーター、サーバー、およびストレージ) やサーバー・ソフトウェア (アプリケーション・サーバー、データベース、およびERPソリューション) の改訂版が、目まぐるしい頻度で登場します。ソフトウェア・エンジニアは、システムでデータを共用し続けるための、高価で保守の難しいカスタム・ソフトウェアを絶えず作成しています。

SOAPのフレームワーク

SOAPは、サーバー間通信用のリングア・フランカ (国際共通語) を開発するための、現時点における最大の期待の星です。他のサーバー、プラットフォーム、およびハードウェアと自由に通信できるサーバー・アプリケーションを書けることには、多くの利点があります。コードの保守に費やす時間が少なくて済むため、プログラマーはより大きな問題の解決に専念することができます。オペレーション・マネージャーは、広範囲のプラットフォームおよびハードウェアの中から、使用したいものを選択することができます。また、ユーザーにとっては、より進んだアプリケーションを使用できるという利点があります。

SOAPを使用してソフトウェアを相互操作可能にするためのツールは、安価で、自由に使用することができ、広くサポートされています。どのようなツール、ハードウェア、およびネットワーク機器を使用するかにより、配備するSOAPベースWebサービスのパフォーマンスとスケーラビリティーの可能性が大きく左右されます。その点を考慮したうえで、Webサービスを開発するためのスケーラブルなフレームワークと、パフォーマンス上の問題を回避するための戦略を説明し、パフォーマンスとスケーラビリティーのテストに役立つ、Loadというテスト・オブジェクトとスクリプト言語のオープン・ソース・セットを提案したいと思います。

上に戻る

Webサービスを開発するためのフレームワーク

SOAPはユーザーの既存のWebアプリケーション・インフラストラクチャーに適合するように作られた、軽量プロトコルです。スケーラブルなSOAPベースWebサービスを開発するための新興のフレームワークでは、ロード・バランサーによってアクセスされる多数の小型サーバーを使用するWebアーキテクチャーを採用して、強力なデータベース・サーバーへのフロントエンドを提供することが好まれています。

SOAPベースのWebサービスをJavaで構築するためのフレームワークでは、以下のコンポーネントを使用します (ここにリストされたコンポーネントへのリンクは、参考文献を参照してください)。

1. Apache SOAP
   Apache SOAPはIBMによるSOAPへの貢献を基礎としたもので、Java用の 全機能のSOAPインプリメンテーションを提供するオープン・ソースのプロジェクトです。Apache SOAPはほとんどのSOAP v1.1仕様をインプリメントしており、SOAPのメッセージと、サーバーおよびクライアントのインプリメンテーションをサポートし、Apacheスタイルのライセンスに基づく完全なソース・コードが付いています (つまり、コードを変更したり、その変更内容を使用して所有権を主張できるソフトウェア・プロダクトを配置したりすることができます)。
2. JDOM
   SunがJDOMをJSR102として受け入れましたので、JDOMはJavaの一部となる可能性があります (参考文献を参照)。Apache SOAPにはXerces XMLパーサーが付いています。しかし実際には、SAXに準拠する任意のXMLパーサーを使用することができます。JDOMは、Java開発者にとって、SOAPのXML文書を操作するための、より簡単で親しみやすいAPIであり、これを使用すると、SOAPアプリケーションをコーディングし直さなくても、基礎になっているXMLパーサーを変更することができます。このような柔軟性があるため、特定のXMLパーサーにおけるスケーラビリティーまたはパフォーマンス上の問題を解決しようとするときに、選択肢が多くなります。JDOMもApacheスタイルのオープン・ソース・ライセンスのもとで配布されます。
3. SSLサポートを行うロード・バランサー
   SOAP 1.1プロトコルでは、まだ暗号化方式と認証方式が定義されていません。SOAPで認証方式が定義されるまで、SOAPフレームワークでは、ユーザーのサーブレットに独自のビジネス・ロジックを組み込み、基礎になっているWebサーバーのSSLサポートを使用して、Webサービス に対するHTTPS要求を行うことを推奨しています。ロード・バランサーのSSLサポートは要求を暗号解除し、それを暗号化されていないSOAP呼び出しとしてWebサービスに渡します。これにより、Webサービス・サーバーはSSLの計算オーバーヘッドから解放されます。
   図2: 障害個所
   
   
4. cookieベースのセッション・トラッキングを行うロード・バランサー
   SOAP 1.1ではまだセッション管理メカニズムが定義されていません。ロード・バランスが取られている環境では、SOAP要求のうちのいくつかがステートフルな情報を伝達する必要があります。たとえば、Webサービスとの通信では、連続する複数の要求および応答が必要になることがあります (ロード・バランサーは、セッション中に要求を同じWebサービス・サーバーに送り込めるようになっている必要があります)。今日のほとんどのロード・バランサーはcookieベースのセッション・トラッキングをサポートします。

このフレームワークには、多くの利点があります。常時実行されるスレッドの数が比較的少ないため、Javaエンジニアにとって、デバッグの複雑さが軽減します。巨大なシステムの購入を避けて、多数の小型で安いサーバーを購入することができるため、このアーキテクチャーは会社の財務管理者に気に入られています。また、こうした小型サーバーのもたらす柔軟性は、ネットワーク・マネージャーに気に入られています。

ところで、1つ疑問が残っています。SOAPは実稼働環境に対応しているのでしょうか?

上に戻る

パフォーマンスおよびスケーラビリティーを考慮した設計

SOAPはまだ非常に新しいシステムであり、実地に立証されていません。SOAP内部には、パフォーマンスおよびスケーラビリティーの問題の温床となる個所が多数あります。実稼働に適しているかどうかを判断するためには、装置レベルとシステム・レベルの両方でテストを行う必要があります。

SOAPプロトコルは通信トランザクションを完結させるために多段階プロセスを利用します。SOAP要求は、アプリケーションのビジネス・ロジック呼び出しから取り掛かり、呼び出す必要のあるメソッドおよびパラメーターを、Web Services Description Language (WSDL) 文書から調べ出します。

たとえば、リスト1 は、アメリカの郵便番号を入力すると現在の天気を戻す、一般的に使用可能なWebサービスを表すWSDLの一部です (完全なWSDLへのリンクは、参考文献を参照してください)。

                
<message name = "getTempRequest">
 <part name = "zipcode" type = "xsd:string"/>
</message>
<message name = "getTempResponse">
 <part name = "return" type = "xsd:float"/>
</message>

この天気サービスは、zipcode 値をストリング形式で渡してgetTempRequest メソッドを呼び出し、それに対する応答として浮動小数点値による気温を受け取ります。

WSDLが変更されることはめったにありませんので、多くの開発者は、WSDLを毎回入手するオーバーヘッドを避けるためにWSDL定義をコードに組み込んでいます。このようにすると、パフォーマンスは向上しますが、WSDLが変更されたときには、保守を行う際に頭痛の種になります。

保守の問題を避けるためのよりよい方法として、集中管理されたデータベースにWSDLをキャッシュし、定期的にWSDLのタイム・スタンプやバージョン番号を検査して、新しいWSDLが使用可能であるかどうかを調べることができます。

パフォーマンスを向上させるための別の方法として、XMLの妥当性検査をオフにするやり方があります。この場合、アプリケーションで応答の結果を簡単に妥当性検査する必要があります。たとえば、リスト2 のWSDLでは、応答のスキーマが定義されています。

                
<element name="zipcode" type="int"/>
<element name="temperature" type="float"/>
<element name="remarks" type="string"/>

このサービスへの呼び出しの結果は、リスト3 のようになります。

                
<zipcode>95008</zipcode>
<temperature>65 F</temperature>
<remarks>Storm warning</remarks>

気温の値は浮動小数点型ではなく文字列ですから、この応答は、例外をスローするはずです。応答を読者自身で妥当性検査すると、通常は、DTDまたはXMLスキーマ・コードで応答を妥当性検査するよりもはるかに高速で行なえます。

SOAPのパラメーター型は、スケーラビリティーの問題を起こす可能性があります。SOAPは、String、Int、Float、およびNegativeIntegerという単純なデータ型を定義しています。このWSDLには、見逃すことのできない新しいデータ型が含まれることがあります。たとえば、気温を教えるWebサービスで、地図も検索されるものと仮定します。この呼び出しのスキーマはリスト4 のようになります。

                
<message name = "getTempRequest">
 <part name = "zipcode" type = "xsd:string"/>
</message>
<message name = "getTempResponse">
 <part name = "return" type = "xsd:float"/>
 <part name = "map" type = "xsd:
http://www.pushtotest.com/wsdl/mapformat"/>
</message>

応答を読み取る一方で、妥当性検査を行うXMLパーサーは、pushtotest.comホストに接続して、mapformat のXMLスキーマ定義を入手します。妥当性検査を行うパーサーがスキーマ定義をキャッシュに入れない場合、この要求のオーバーヘッドが原因でシステムがスケーラブルでなくなる可能性があります。

一般的なパフォーマンス・ルールでは、やむを得ず別のデータ型を使用する必要がない限り、単純なSOAPデータ型を使用し続ける方がよいといえます。それぞれの新規データ型は、XML値からJava値への変換、およびその反対方向の変換を行うためのシリアライザーを備えています。このシリアライザーがパフォーマンス上の問題の原因となったり、バグを含んでいたりすることがあります。たとえば、ApacheおよびMicrosoftのSOAPインプリメンテーションは、ともにBigDecimalデータ型を含んでいます。ただし、互いの互換性はありません。XMLのプラットフォームの相違点をマップする、Glueという商用製品があります。Glueおよびその関連ページへのリンクは、参考文献を参照してください。

SOAPは、既存のWebアプリケーション環境で作動するように設計されていますが、プロトコルが原因となってファイアウォールおよびルーティングの問題が生じる可能性があります。HTTPを使用する通常のWebサーバーとは異なり、すべてのSOAPメッセージは、HTTPフォームのサブミットと同等です。呼び出しによって移動するデータは、平均的なHTTP GETまたはPOST呼び出しに比べてはるかに多く、ネットワークのパフォーマンスに影響を与えがちです。

ファイアウォールおよびルーティング装置の特別なテストを行う必要があります。たとえば、読者のファイアウォールのセキュリティー・ポリシーが、SOAP要求をWebトラフィックとしてモニターしないようになっていることを確認する必要があります。SOAP要求をWebトラフィックとしてモニターしてしまうと、一見サービス妨害 (DoS) 攻撃と似たトラフィックとしてファイアウォールが遮ってしまうことがあります。

初期のWebサービスは非常に簡単にできていて、SOAP呼び出しを行うと応答が得られるようになっていました。より進んだSOAPアプリケーションでは、トランザクションが終了するまで、一連のget呼び出しおよび応答呼び出しが行なわれます。トランザクションのSOAP呼び出しは、セッションを識別し、その状態をキャッシュに入れる必要があります。SOAPトランザクションのキャッシング・メカニズムでは、スケーラビリティーの問題が起こる可能性があります。

スケーラビリティーおよびパフォーマンス上の問題の原因となる可能性のある個所が分かりましたので、SOAPベースのWebサービスを実際にテストして、スケーラビリティーとパフォーマンスを調べることができます。

上に戻る

Loadを使用するテスト戦略

SOAPベースのWebサービスを実稼働環境に移すためには、可用性が高く、常にパフォーマンスが良好であることが保証される必要があります。以下に、Java開発者がWebサービスのテストを計画する際に考慮すべきチェックリストを示します。

1. ステートフル・テスト
   SOAPを使用してサーバー値を設定した後で、サーバーが正しく応答するようになっていますか?
2. 特権テスト
   一般のユーザーが、アドミニストレーターだけに許可されている制御にアクセスしようとしたときに、どのようなことが起こりますか?
3. 速度テスト
   Webサービスの応答に要する時間が長すぎませんか?
4. 境界タイミング・テスト
   読者のWebサービスの要求がタイムアウトになったり、応答にかなりの時間を要したりするときに、どのようなことが起こりますか?
5. レグレッション・テスト
   新規のビルドによって既存のWebサービス機能が中断しましたか?

どのようなソフトウェア・アプリケーションにもかなり共通するテストがあります。しかし、これはWebサービスですので、次のWebサービス・テスト・スイートに示すように、テスト対象は多岐にわたります。

読者の会社によるテストがいい加減で、テスト・ソフトウェアに投資していない場合であっても、かつてのWebアプリケーションの場合は、Webブラウザー を使用して読者自身でテストすることが可能でした。SOAPベースのWebサービスでは、そのようなわけにはいきません。SOAPトランザクション中に発行されたXML文書を手作業で読み取っていたのでは、時間がかかって仕方がありません。自動化されたテスト・スイートを開発してそれを利用することが欠かせません。

フリーのオープン・ソースのユーティリティーであるLoadが、私の会社のサイトPushtotest、およびIBM developerWorksのOpen sourceゾーンから入手可能です (リンクについては、参考文献を参照)。Loadを使用すると、SOAPベースのWebサービスのパフォーマンスおよびスケーラビリティーをテストするための、テスト自動化スイートを作成することができます。このユーティリティーは、テスト・オブジェクトのライブラリーを操作するスクリプト言語を提供し、Webサービスを駆動するインテリジェント・スクリプトを開発できるようにします。並行して実行される複数のスクリプトのコピーを使って、Webサービスが、シミュレートされた稼動状態で実行されているのかどうかを示すことができます。

前に挙げた気温サービスを呼び出すためにLoadがどのように使用されるのかを見てみましょう。リスト5 は、全体的なスクリプトです。

                
<load>
<script>
<!-- Tells where to find the weather service -->
<variable name="serviceurl"
  value="http://services.xmethods.net/soap/servlet/rpcrouter"/>
<!-- Establishes a variable to hold the zip code -->
<variable name="thezip" value="95008" />
<!-- Identify the source of the delimited data -->
<soapsource name="temperature" target="urn:xmethods-Temperature"
  method="getTemp" url="$serviceurl;"/>
<soapsource name="temperature" action="addparameter"
  parameter="zipcode" value="$thezip;"/>
<soapsource name="temperature" action="call"/>
<echo message="The temperature is $soapsource[ temperature, 0];" />
<echo message="That request took $soapsource[ temperature, totaltime];
milliseconds" />
</script>
</load>

ここで、個々の機能の働きを見てみましょう。

<load>
<script>

これらは、この後にLoadプログラムが処理するスクリプト要素が続くことを示す前書きです。

<!-- Tells where to find the weather service -->
<variable name="serviceurl"
  value="http://services.xmethods.net/soap/servlet/rpcrouter"/>
<!-- Establishes a variable to hold the zip code -->
<variable name="thezip" value="95008" />

2つの変数を作成します。最初の変数にはWebサービスへのURIが入り、2番目の変数には郵便番号の値が入ります。

<!-- Identify the source of the delimited data -->
<soapsource name="temperature" target="urn:xmethods-Temperature"
  method="getTemp" url="$serviceurl;"/>

次に、temperature という新しいSOAPソープ・オブジェクトを作成します。temperatureオブジェクトは、URLで定義されたマシンにあるxmethods-Temperature WebサービスでgetTemp メソッドを呼び出します。

<soapsource name="temperature" action="addparameter"
  parameter="zipcode" value="$thezip;"/>

これにより、temperatureオブジェクトに郵便番号パラメーターが追加されます。addparameter アクションを使用して、必要なだけパラメーターを追加することができます。WebサービスのWSDLで、予期されるパラメーターを定義します。

<soapsource name="temperature" action="call"/>

このWebサービスを呼び出すと、ターゲット・サーバーへのhttp接続が開始され、要求および追加されたパラメーターによってXML文書が整えられ、応答を待つようになります。

<echo message="The temperature is $soapsource[ temperature, 0];" />

Loadは応答文書を調べ、位置0から応答フィールドを見つけます。このフィールドの値はLoadのGUIで表示され、見ることができるようになります。

<echo message="That request took $soapsource[ temperature, totaltime];
milliseconds" />

temperatureオブジェクトのtotaltime メソッドは、要求を行なって完了させるまでに要する、ミリ秒単位の時間を戻します。

このスクリプトが満足のいくものである場合、スクリプトと並行してLoadを実行し、シミュレートされたロードのもとでWebサービスをテストすることができます。

<load>
<script sessions="25">
. . .
</script>
</load>

これにより、スクリプトのコピーが25部作られ、並行して実行されます。Loadには、ループ、ランダム値、ダミー・テキストの記入、および他の20のテスト・オブジェクトへのアクセスを行うコマンドが含まれています。

Loadは、Apache Webサーバーの場合と似た条件のもとでライセンス交付されます。Loadプログラムは、そのすべてのソース・コードとともにダウンロードされます。Loadを変更して、バグを修正したり、新規機能を追加したりすることができます。このライセンスでは、このコードを基にして、商用に利用可能な新規製品を作成することも許されます。

上に戻る

結論

実稼動に適した品質のWebサービスをプログラミングし、公開すると、複数の並行した要求による重点を置いた品質テストを、簡単かつ迅速に行なえるようになります。オープン・ソースのLoadユーティリティーのスクリプト言語およびテスト・オブジェクトを使用すると、SOAPベースのWebサービスのテストを、より効率的に行なえるようになります。

参考文献

• 一般に使用可能なWebサービスのリスト。
  
  
• SunはJDOMをJSR102として受け入れました。
  
  
• Apache SOAP について学習してください。
  
  
• Apache SOAP をダウンロードしてください。
  
  
• Apache SOAPおよびその他のApache関連のソフトは、Apacheライセンスのもとで発行されています。
  
  
• IBMのSOAPプロジェクトについてさらに調べてください。
  
  
• Microsoft SOAP関連文献はこちらです。
  
  
• Web Services Definition Language (WSDL) 仕様を調べてください。
  
  
• SOAPプロトコル仕様を参照してください。
  
  
• Load は、SOAPベースのWebサービスのスケーラビリティーおよびパフォーマンスをテストするための、フリーなオープン・ソースのユーティリティーです。
  
  
• Cape ClearのCapeStudioは、SOAPおよびWSDLリソースで使用するグラフィック・ツールです。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• SOAPのフレームワーク
• Webサービスを開発するためのフレームワーク
• パフォーマンスおよびスケーラビリティーを考慮した設計
• Loadを使用するテスト戦略
• 結論
• 参考文献
• 著者について
• コメント