3 Webサービス開発における問題点

1 Webサービスの開発

稼働中のWebサービスを一つ以上利用して，新しいアプリケーションを構築する ものとする．

プロバイダはサービスのインタフェースのみを公開しており，その情報はWSDLで記述されて いる．したがって，リクエスタが得られる情報は，プロバイダのWSDLに依存する．

通常，リクエスタはプロバイダの内部動作の詳細を知る必要はなく，インタフェー スの規約のみを遵守すればよい．これは，コンポーネント指向の抽象プログラミ ングの観点から見ると，リクエスタは実装に関知せずにアプリケーションを構築 できるという利点がある．

しかし，実際の開発においては，特にデバッグやテストの段階において，利用す るサービスの内部動作を知りたいという要求がある．すなわち，いわゆるホワイ トボックステストをWebサービス開発で実現したいという要求である．

スタンドアロンアプリケーションであれば，利用するコンポーネントはライブラ リとして提供されるので，デバッガ等で追跡可能である．しかし，Webサービス は実装を公開しないので，リクエスタサイドからはいわゆるブラックボックステ ストしか行えない．

企業内システムなど，利用者の身元が特定可能で，かつ閉鎖的なネットワークに おける運用であれば，開発段階の措置という前提の上で，プロバイダの実装に 対する一定のアクセスを許容してもよい．この場合，プロバイダはテスト用にイ ンタフェースを拡張し，テストに必要な実装をプロバイダに組み込む必要が 生じる．このことに伴うコストは，プロバイダ管理者に課せられる．

一方で，リクエスタはプロバイダの想定するテスト要件から外れた，独自のテス トケースを自由に構築したいという要求がある．しかし，リクエスタの新規開発，ま たは既存リクエスタの仕様変更がなされるたびに，プロバイダ管理者に依頼してテ スト要件に対応してもらうことは，プロバイダ管理者の負担を増大させるので， 現実的ではない．また，サービスのコードを静的に変更しなければならないので， コードの品質低下に繋がる．

複合Webサービスをテストする場合は，更に問題が複雑化する．テスト対象となるプロバイ ダ間に依存関係が存在する場合，リクエスタはテストケースのシー ケンスに沿ってサービス要求の順序を制御する必要がある．このとき，サービス 間の依存関係が正常に解決済みであると，リクエスタが確認できなければならな い．しかし，この手続きはサービス間で直接行われるので，インタフェースから 得られる情報のみで手続きの成否を確実に判断することは不可能である．

他，リモートデバッグにおける通信経路についても問題がある．既存のリモート デバッガは，多くの場合独自のプロトコルを使用して通信する．しかし，一般 にWebサービスが稼働するホストはセキュリティ上好ましくない通信経路をファ イアウォール等で遮断することが多いので，必ずしもデバッガを接続できるとは 限らない．

以上の点が，リクエスタ開発における統合的なホワイトボックステストを阻害する要因と なっている．

要点を以下にまとめる． まず，リクエスタからプロバイダに何らかの操作を行う上で嫁せられる，一般的 な制約は以下の通りである．

1. サービスインタフェースの制約上，リクエスタからプロバイダの詳細な 内部動作を知ることは不可能である．
2. サービスインタフェースの制約上，リクエスタからプロバイダを制御す ることは不可能である．
3. サービスインタフェースで定義されたプロトコル以外は，セキュリティ 上の問題から使用不可能である．

これらの事実から，リクエスタサイドにおけるテストにおいて，以下のような不 都合が生じる．

1. リクエスタはプロバイダの内部情報を必要とするテストケースを構築できない．
2. リクエスタはプロバイダの制御権限を必要とするテストケースを構築できない．
3. Webサービス以外のプロトコルを用いて上記の不都合を回避することはで きない．

2 既存のテスティング手法

1 プログラムの振る舞いに関するテスト

近年注目を浴びているExtreme Programming (XP)[8]やRational Unified Process (RUP)に代表され る新しいソフトウェア開発方法論では，特にテスティング方法論および技術 が非常に重要視されている．

これらの方法論は，テスト実行を機械的に自動化してコストを削減することで テスト実行の繰り返しを促し，より安定かつ洗練されたコードへと改善すること に役立つ．テストの問題領域はテスト対象となるモ ジュールの粒度および構成の規模によって異なり，細粒度から粗粒度へ，小規模 から大規模へ段階的に実施される．これらの各段階におけるテスト手法の各論に ついては多くの既存研究がある．

Webサービスに対し既存のテスティング方法論および技術の適用を検討すること は，前節で述べたホワイトボックステストの阻害要因がテストシーケンスにおいて表面化 する箇所を明らかにすることに繋がる．以下，既存のテスティング方法論と それらを実現する技術について述べ，本研究の問題領域への検討を図る．

1 単体テスト

単体テストとは，個々のプログラムモジュールを対象としたテストである． 主にメソッドの引数および返値の型と値が仕様を満たしているかチェックする．

単一のWebサービス全体を一つのプログラムモジュールと見なすと，リクエスタ による単体テストの概念を適用できる．しかし，あくまでWSDLに従ったWebサー ビス全体としての振る舞いのテストであり，Webサービスの内部動作には関与し ない．

2 結合テスト

結合テストとは，プログラムモジュールを組み合わせて行うテストである．単体 テストの次の段階に位置し，複数モジュールからなる総合的な振る舞いが仕様を 満たしているかチェックする．

複合Webサービス開発において，一つ以上のプロバイダからなる一連の処理シー ケンスに対し，リクエスタによる結合テストの概念を適用できる．しかし，単体 テストにおける概念の流用と同じく，WSDLによる規約に依存する．また，プロバ イダ間で直接行われるインタラクションは，リクエスタサイドで把握することは できない．

2 既存の分散型テスト技術

本研究はWebサービスを対象とすることから，特に分散型テストを実現する既存 の技術について調査を行った．

リモートホストに存在するプログラムを変更可能なツールとして DJcutter[10]がある．DJcutterは分散環境でアスペクト指向プログラミングを実現す ることを目的としており，処理の一部をリモートホスト上に存在するプログラム で実行することができる．また，複数ホスト上にある不特定多数のプログラムで 共有可能なプログラム断片を，サーバから配布してプログラムに織り込むことも できる．ただし，プログラム断片を織り込むためには，事前にホスト上のプログ ラムの実装について知らなければならない．すなわち，内部情報を引き出すため の支援機能は持たない．また，プログラム断片の配布に使用するプロトコルは， Webサービスの標準プロトコル(SOAP)ではない．

Webサービスのテストを目的としたフレームワークに，WSUnit[11]があ る．WSUnitは，リクエスタとプロバイダの間にプロキシとして介在し，SOAP要求とそ の結果に介入することができる．しかし，あくまでもWebサービスのMockとして 振る舞うだけなので，Webサービスにおける単体テストや結合テストの実現には 有用であるが，プロバイダの内部動作に干渉することはできない． 他，同種のWebサービスプロキシやApache Axis TCPMon[12]などのSOAPモニタは すべて同様の問題を内包する．