Web アプリケーションの Web サービス変換に関する研究
2002MT014 林 佑亮

2002MT030 加藤 房良

指導教員 青山 幹雄

1. はじめにWeb サービス変換プログラムを作成する．

近年，Web サービスの基盤技術(SOAP，WSDL，UDDI)が成熟しつつある．しかし，利用可能な Web サービスが少ないため普及に至っていない．そこで本研究では既存に存在する豊富な Web アプリケーションに着目した．それをWeb サービスとして利用可能にする変換方法を提案する．

(2) Proxy サーバによるラッピング
サービスリクエスタと Web アプリケーションの間に Proxyサーバを設置する．Proxy サーバに仲介機能(ラッパー)を置いて，変換を実現する．ProxyサーバとWebアプリケーシ
ョンを 1 つのサービスプロバイダと見なす．

2. Web サービスの問題点と解決策

方法(2)は，Web アプリケーションの HTML レスポンスを利用して変換する方法をとるため，Web アプリケーションの実装言語に依存しない．また，方法(1)のように直接 Web サーバ内に変換プログラムを作成しなくて済むため，Web アプリケーションを一切変更せずに再利用できる．そこで本研究では，図 1 に示すように Proxy サーバによるラッピングアーキテクチャを用いる[2]．

2.1. Web サービスとは
Web サービスは，コンピュータ同士が連携することによってネットワーク上に分散している複数のサービスを統合して扱うことを目的とした技術であり，プログラミング言語，OS，通信プロトコル等に依存しない特徴がある．
2.2. Web サービスの問題点
現在の Web サービスの問題点として，我々は Web サー
ビスの実装にかかる開発コストに着目した．実際に利用・連携したい Web アプリケーションが，その開発コストのためにWeb サービス化されていない．両者のインタフェースが異なるため，既存の Web アプリケーションと同内容のシステムを Web サービスにするには，一からシステムを再構築しなければならない場合がある．
2.3. 解決策の提案
前述した問題の解決策として，Web アプリケーションの入出力を Web サービスの入出力と対応できるようにマッピングする方法を考えた．Web アプリケーションのインタフェー
スは，HTTP によって受信される HTML に限定されており，人がブラウザを利用して扱うことが前提である．これを Web
サービスとして扱えるようにするための変換方法を提案す
る．

3. Web アプリケーション Web サービス変換
3.1. 変換アーキテクチャの提案
Web アプリケーションを Web サービスに変換するアーキテクチャとして，以下の 2 つの方法が考えられる．
(1) Web アプリケーションに直接変換機能の追加
Web アプリケーションを構築しているサーバ上に，直接SOAP

Webサービス
インタフェース

Webサーバ

サービス
変換ルール
HTTP
ラッパー

Webアプリケーション

サービスリクエスタ
Proxyサーバ

サービスプロバイダ

図 1 ： ラッピングアーキテクチャ
3.2. インタフェースの変換方法
ラッピングアーキテクチャを実現するためには以下の 2つの要素が必要となる．
(1) ラッピングタスク
ラッピングタスクは，Web アプリケーションと Web サービスのインタフェースの違いを克服するため，Web アプリケーションとの通信を可能にするインタフェースを持つ．さらにWeb アプリケーションからの HTML レスポンスを Web サー
ビスのレスポンスとして扱える機能が必要となる[3]．
(2） Web サービス変換ルール
Web サービス変換ルールでは Web アプリケーションとの通信手順や Web アプリケーションと Web サービスのリクエスト，レスポンスの対応方法を規定する．
3.3. ラッピングタスク
図 1 で示したアーキテクチャの詳細を図 2 に表す．

また，ラッピングタスクによるデータフローを図 4 に示す．

Webサービスプロバイダ

CGIやPHP等の任意のアプリケー
ション

Proxyサーバ
ラッピングタスク

SOAP

Webサービス
インタフェース

サービス変換
ルール群

Webサーバ
ラッパー

HTTP

サービス
リクエスタ

HTTPリクエストの送信
リクエストジェネレータ
リクエスト
変換された
メッセージ Webアプリケーションへと メッセージ
Webアプリケーション
送信できるようなと通信を行うメッセージ形式へと変換

Web
アプリケーション
インタフェース

アプリケーションで処理されたHTMLレスポンス

変換に必要な主要素

整形化された抽出された サービスリクエスタ
HTMLレスポンスを整形化されたHTML レスポンス
HTML
へ送信すべきレスポンスパーサでからサービスリクエスタ
オブジェクト構造解釈可能な形に整形化へのレスポンスを抽出へとマッピング

Webサービス変換ルール
・Webアプリとの通信手順
・抽出・マッピング方法を記述

ラッピングタスク・Webアプリと通信機能
・レスポンス抽出・マッピング機能

HTMLTidyによるレスポンスの整形化

図 2 ： インタフェース変換の詳細レスポンスパーサ

レスポンスマッピング

図 4 ： ラッピングタスクによるデータフロー

Webアプリケーションとの通信

データモデルインタラクション
ルール<INTPUT name=“～～” value=“……”>・・・

リクエストメッセージをWebアプリケー
ションのパラメータにマッピング

サービス変換ルール群
レスポンス
マッピング
抽出ルール
プロトコル ルール
テンプレート変換ルール入力
Webサーバリクエストジェネレータ
Webサービス
インタフェース
リクエストの送信へリクエスト / レスポンス
レスポンスの整形化

HTMLレスポンスを整形化

レスポンスパーサ
レスポンスマッピング

・レスポンス要素を解析
・目的の要素を抽出

ラッパー

リクエスト / レスポンス
・final・形容詞・最終の～・ファイナル

WEB
アプリ

抽出した値を、サービスリクエスタが処理可能な形にマッピング

図 3： ラッピングタスクの処理

4. Web サービス変換ルール
4.1. 変換ルールの構成
Web サービス変換のために必要なルールを XML で記述する[3][4][5]．また，変換ルールの関連を図 5 に示す．
（1）データモデル

入力レスポンス
ドキュメントHTTPクライアント

リクエストジェネレータ

リクエスト
ドキュメント(2)プロトコルテプレート<parameter name = “destination”><value><xsl:value-of
select=“DataModel/…/text()”/></value></parameter>(3)インタラクションルール
<method type = “POST” url=“http://~~.cgi”><request name =“~~”/><response type = “final”></method>HTML対応

ラッピングタスクとして持つ機能を以下に示す(図 3)．
(1) リクエストジェネレータ
サービスリクエスタから受け取ったリクエストメッセー
ジから Web アプリケーションへ送信する要素を抽出する．次に，Web アプリケーションの入力インタフェースである HTML 文の FORM 要素の子要素のパラメータへ，対応づけて代入する．
(2) HTTP リクエストの送信(1)で生成したリクエストを Web アプリケーションへ送信する．送信パターンは以下の 2 通りである．
1) リクエスト送信・レスポンス受信を一度だけ行う
2) 複数回にわたって送信・受信を繰り返す(3) HTML Tidy によるレスポンスの整形化
HTML を走査し，文法的な誤りを検出・修正し，XHTML に整形化する．(2)によって得られた HTML レスポンスを抽出可能な形式にするために HTML 文書を整形式にする．本研究では，HTMLTidy をプログラム途中で呼び出し，HTML を整形化する．
(4) レスポンスパーサ(3)によって整形化された XHTML文書からサービスリクエスタへのレスポンス要素を抽出する．
(5) レスポンスマッピング(4)で抽出した求められる要素をサービスリクエスタが処理可能な形にマッピングする．

(5)レスポンス マッピングルール（呼び出しメソッドの返り値オブジェクト構造）
<～～>
<～～>

<～～>
<～～>

(4)レスポンス抽出ルール<extraction><train name>html/body/…
</train name>
レスポンスメッセージ <train Num>html/body/…
</train Num>との対応付け</extraction>

抽出要素を渡す

図 5 ：Web サービス変換ルールの関連変換ルールとして以下のものを考えた．
(1) データモデル
Web アプリケーション上で使用されるデータを We サービスで使用可能なデータ形式に変換時に用いられる
モデル(2)プロトコルテンプレート
Web アプリケーションのリクエスト，レスポンスと Webサービスリクエスタとの通信と対応づけるルール(3)インタラクションルール
Web アプリケーションとの通信順序を定めたルール(4)レスポンス抽出ルール
Web アプリケーションからの HTML レスポンスから目的の要素を抽出するためのルール(5) (2)と同様

4.2. 変換ルールの具体例
変換ルールを英単語検索の Web アプリケーションを例として説明する．
(1) データモデル
Webアプリケーションで使用されるデータを Webサービスで使用可能な形のモデルとして記述する．データモデル
例を図 6 に示す．

(4) レスポンス抽出ルール
Web アプリケーションから得た HTML レスポンスから，サービスリクエスタへのレスポンス要素が存在する場所をXPath で記述する．この時の HTML レスポンスは XHTML文書へと整えられる．
(5) レスポンスマッピングルール
HTML レスポンスから抽出した各要素をサービスリクエ
スタへのレスポンスとしてマッピングするため，抽出した要素との対応関係を記述する．

5. 実装方法

図 6： データモデル例(2) プロトコルテンプレート
Web アプリケーションへ送信すべきリクエストを規定する．
サービスリクエスタのリクエストを Web アプリケーションのリクエストであるパラメータ変数と対応するようにマッピングする．オブジェクトモデルを図 7 に示す．

図 7 ： プロトコルテンプレート(3) インタラクションルール
Proxy と Web アプリケーションとの通信を規定する．

図 8 ： インタラクションルール

ラッパー開発者が既存の Web アプリケーションをラッピングし，Web サービスに変換するための実装方法を以下に示す．
(1) データモデルの作成とサービス定義
ラッパー開発者は，ラッピングする Webアプリケーションが使用するパラメータを抽出する．次に HTML レスポンスを解析し，目的のHTMLレスポンスを得るまでの通信の流れを解析する．そして，HTML レスポンスから抽出され得る要素の集合をデータモデルとして定義する．
(2) Web アプリケーションの挙動の解析
次にサービスリクエスタから送られてくるリクエストメッセージと Web アプリケーションへ送信するパラメータとの互換性を確立する．それを基にして，プロトコルテンプレートを作成する．また，通信の流れをインタラクションルールとして記述する．
(3) HTML レスポンスの解析と抽出ルールの規定
サービスリクエスタへ提供するレスポンス内容を含んでいる HTML レスポンスの中で，目的の要素がどこに存在しているかを把握する．把握した内容を基にして，レスポンス抽出ルールを記述する．
(4) 抽出した要素のマッピング
レスポンス抽出ルールから得た要素を，サービスリクエスタが求めている形にマッピングするためにレスポンスマッピングルールを記述する．
(5) Proxy サーバ内にラッパーを構築
前述までに生成したルールを利用してラッパーを作成する．ラッパーはラッピングタスクを基にして作られる．例として Java を用いたラッパーを作成する方法を示す．
Proxy サーバ内にラッパークラスを作成する．ラッパーク
ラスとは別に，サービスを供給するためのメソッドを含むサービスクラスを公開する．サービスクラスでは，ラッパークラスのラッピングメソッドを利用して，Web アプリケーションから目的のレスポンスを抽出し，目的のサービスを提供するメソッドを公開する(図 9)．

待できる．
サービス定義機能、getWordMean(引数：検索単語、返り値：単語の意味、用法)を作成しよう。

7. 考察と今後の課題

Webアプリケーションの挙動
入力(パラメータ)
挙動の確認
日・英単語を入力するとその意味や用法が出力

出力(HTML)
日・英単語の意味や用法など

図 9 ： ラッパー開発者の作業

6. プロトタイプによる評価
6.1. Web サービス変換ルールの妥当性検証
本研究で提案した5種類の各変換ルールの妥当性や必要性を検証する．検証内容は以下の 3 つである．
(1)データモデルの効果
適切な変換のためにはサービスリクエスタより送られてきたリクエストデータや送り返すレスポンスデータの意味を知る必要がある．そのため，Web アプリケーションのデータ構造をモデル化した．この結果，意味定義をしたために，Web アプリケーションのデータを Web サービス上でのオブジェクトとして扱えるようになった．
(2)プロトコルテンプレートとインタラクション分割の効果
一つの Web アプリケーションがタイプの異なる機能を提供する場合，リクエスト送信パターンが異なる場合がある．そこで，上記ルールを分割することにより，リクエストを独立に送信可能となり，適時に送信内容を決められる効果がある．
(3)抽出ルールとマッピングルールの分割の効果
抽出ルールとマッピングルールを分割して定義する
ことで，マッピングルールにレスポンスオブジェクトの構造を定義し，複数の抽出ルールを組み合わせて利用可能となる．これにより抽出ルールを追加する場合，マッピングルールは変更せずに済む．

Web アプリケーション作成者でなくともラッピング可能にするために，サービスリクエスタが求めるレスポンスをWebアプリケーションの HTML レスポンスから抽出する方法を提案した．この方法は HTML レスポンスのみに着目すれば良いので，ラッパー開発者はWebアプリケーションの実装を知らなくても良い．よって，既存の Web アプリケーションを変更せずに再利用可能なため，開発コストの削減が期待できる．
関連研究として，スクリプト言語を用いてラッピングをする方法がある[1]． これは変換ルール記述がその実装言語に依存する．本研究では実装言語に依存しない変換ルールを表現するため，XML で記述した．
今後は以下の課題を検討する必要がある．
(1) ラッパー開発者のルール作成時の負担の軽減
ラッパーを開発する場合に，開発支援環境を充実させ，変換ルールの半自動生成を考える．
(2) 複数の Web アプリケーションのラッピング
類似のサービスを提供している複数の Web アプリケーションを同一の Proxy サーバ内で統合し，組み合わせたサービスを実現するラッピングの応用が考えられる．

8. まとめ本研究では Web アプリケーションを Web サービスとして扱える仕組みとして，変換アーキテクチャ，ラッピングタスク，サービス変換ルールを提案した．またそれに伴い，考えられる問題点や今後の課題も提示した．今後は，提示した問題点や課題を解決していくことを目指す．

参考文献

6.2. 本研究によるコストダウンの検証
本研究で提案した変換方法を実現するラッパーのプロトタイプを Java で実装した．ここでは英単語の辞書 Web アプリケーションを例題とした．ラッパーと変換ルールのコー
ド行数を表 1 に示す．

[1]

表 1 ： ラッパーと変換ルールの実装規模

[3]
[4]

サブシステム
コード行数ラッパー
ラッピングタスク
サービス実現クラス
432 行
442 行

変換
ルール

[2]

101 行

ラッピングタスクは再利用できる．異なる Web アプリケー
ションを変換する際には変換ルールとサービス実現クラスのみを書き換えるだけで良いので，開発コストの削減が期[5]

藤原 克哉ほか，フォーム自動記入のためのWebサー
ビス変換フレームワークの開発，情報処理学会研究報
告ソフトウェア工学，2004，pp 61-66.
高橋 健一ほか，プロキシサーバによる WEB アプリケーションの WEB サービス変換，情報処理学会ウィンタ
ーワークショップ 2005 論文集，2005，pp.95-96.
TaMeX，http://www.cs.ualberta.ca/~stroulia/TAMEX/.
S. Jabbour and A. Vercoustre，Wrapping Web Pages into
XML Documents : A Practical Experience andComparison of Two Tools，AusWeb'02，2002.
Y. Jiang and E. Stroulia，Towards Reengineering Web
Sites to Web-services Providers, CSMR ' 04, 2004, p.296.