(57)【要約】【課題】既存のＷｅｂアプリケーションをＷｅｂサービスとして提供する方法において、複数ページにまたがってユーザセッションを保つＷｅｂアプリケーションに対応でき、変換プロキシとＷｅｂサービス・クライアントにとって簡便な方法が求められている。【解決手段】Ｗｅｂアプリケーションを格納するＨＴＴＰサーバから送られるＨＴＴＰレスポンスから、典型的に用いられるセッション管理手法によって埋め込まれたセッション情報を抽出する。これら抽出された情報を、ＨＴＴＰサーバから返されるユーザセッション情報として、Ｗｅｂサービスのレスポンスに含める。また、Ｗｅｂサービスのリクエストにこのユーザセッション情報を含めて送れるようにし、Ｗｅｂサービス・クライアントから受け取ったユーザセッション情報を、該当するセッション管理手法を用いてＨＴＴＰリクエストに埋め込んでＨＴＴＰサーバに送る。【選択図】        図１
2007026150.tif 000002
【特許請求の範囲】
【請求項１】
Ｗｅｂサービス・クライアントのリクエストに対して、プロキシ装置が、Ｗｅｂアプリケーション・サーバにアクセスし、Ｗｅｂサービスを提供する方法であって、
前記Ｗｅｂサービス・クライアントのリクエストに応じて、前記アプリケーション・サーバに対して、ＨＴＴＰリクエストを送るステップと、
前記Ｗｅｂアプリケーション・サーバからの応答であるＨＴＴＰレスポンス中のエンティティ・ボディから抽出したアプリケーション情報に加え、前記ＨＴＴＰレスポンス中のエンティティ・ヘッダとエンティティ・ボディから抽出したユーザセッション情報を、前記Ｗｅｂサービス・クライアントヘのレスポンスに含めるステップと、
前記Ｗｅｂサービス・クライアントからのリクエストに含まれた前記ユーザセッション情報を、ＨＴＴＰリクエスト中のエンティティ・ヘッダとアプリケーション・データの一部としてエンティティ・ボディに含め、前記Ｗｅｂアプリケーション・サーバに送るステップと、
を備えるＷｅｂサービスを提供する方法。
【請求項２】
前記Ｗｅｂサービス・クライアントのリクエストが、ＳＯＡＰリクエストであり、このリクエストに対する応答がＳＯＡＰレスポンスである請求項１に記載のＷｅｂサービスを提供する方法。
【請求項３】
前記ユーザセッション情報が、ＵＲＩ情報、Ｓｅｔ−Ｃｏｏｋｉｅヘッダ情報、およびｈｉｄｄｅｎタグ情報である請求項１に記載のＷｅｂサービスを提供する方法。
【請求項４】
前記プロキシ装置が、ユーザからあらかじめ与えられたコンフィギュレーション情報に基づき、Ｗｅｂサービス・インターフェース情報としてＷＳＤＬを生成するステップを備える請求項３に記載のＷｅｂサービスを提供する方法。
【請求項５】
前記コンフィギュレーション情報は、Ｗｅｂアプリ−ションが複数セッションを含むかどうかを前記プロキシ装置に指示する情報を含む請求項４に記載のＷｅｂサービスを提供する方法。
【請求項６】
前記ＷＳＤＬに、前記ＨＴＴＰリクエストに含める前記ユーザセッション情報を、前記ＳＯＡＰリクエストの一部として含める記述を追加する請求項４に記載のＷｅｂサービスを提供する方法。
【請求項７】
前記ＷＳＤＬに、前記ＨＴＴＰレスポンス中の、前記ユーザセッション情報を、前記ＳＯＡＰレスポンスの一部として含める記述を追加する請求項４に記載のＷｅｂサービスを提供する方法。
【請求項８】
Ｗｅｂサービス・クライアントのリクエストに対して、Ｗｅｂアプリケーション・サーバにアクセスし、Ｗｅｂサービスを提供するプロキシ装置であって、
前記Ｗｅｂアプリケーション・サーバからの応答であるＨＴＴＰレスポンス中のエンティティ・ボディから抽出したアプリケーション情報に加え、前記ＨＴＴＰレスポンス中のエンティティ・ヘッダとエンティティ・ボディから抽出したユーザセッション情報を、前記Ｗｅｂサービス・クライアントヘのレスポンスに含めるレスポンス生成部と、
前記Ｗｅｂサービス・クライアントのリクエストに含まれた前記ユーザセッション情報を、ＨＴＴＰリクエスト中にエンティティ・ヘッダとアプリケーション・データの一部としてエンティティ・ボディに含めるＨＴＴＰリクエスト生成部と、
前記ＨＴＴＰリクエスト生成部によって生成された前記ＨＴＴＰリクエストを、前記Ｗｅｂサービス・クライアントのリクエストに応じて、前記Ｗｅｂアプリケーション・サーバに送るＨＴＴＰリクエスト送信部と、
を備えるプロキシ装置。
【請求項９】
前記Ｗｅｂサービス・クライアントのリクエストが、ＳＯＡＰリクエストであり、このリクエストに対する応答がＳＯＡＰレスポンスである請求項８に記載のプロキシ装置。
【請求項１０】
前記ユーザセッション情報が、ＵＲＩ情報、Ｓｅｔ−Ｃｏｏｋｉｅヘッダ情報、およびｈｉｄｄｅｎタグ情報である、請求項８に記載のプロキシ装置。
【請求項１１】
Ｗｅｂサービス・クライアントのリクエストに対して、Ｗｅｂアプリケーション・サーバにアクセスし、Ｗｅｂサービスを提供するためのコンピュータ・プログラムであって、コンピュータに、
前記Ｗｅｂサービス・クライアントのリクエストに応じて、前記アプリケーション・サーバに対して、ＨＴＴＰリクエストを送るステップと、
前記Ｗｅｂアプリケーション・サーバからの応答であるＨＴＴＰレスポンス中のエンティティ・ボディから抽出したアプリケーション情報に加え、前記ＨＴＴＰレスポンス中のエンティティ・ヘッダとエンティティ・ボディから抽出したユーザセッション情報を、前記Ｗｅｂサービス・クライアントヘのレスポンスに含めるステップと、
前記Ｗｅｂサービス・クライアントのリクエストに含まれた前記ユーザセッション情報を、ＨＴＴＰリクエスト中にエンティティ・ヘッダとアプリケーション・データの一部としてエンティティ・ボディに含め、前記Ｗｅｂアプリケーション・サーバに送るステップと、
を実行させる、コンピュータ・プログラム。
【請求項１２】
前記Ｗｅｂサービス・クライアントのリクエストが、ＳＯＡＰリクエストであり、このリクエストに対する応答がＳＯＡＰレスポンスである請求項１１に記載のコンピュータ・プログラム。
【請求項１３】
前記ユーザセッション情報が、ＵＲＩ情報、Ｓｅｔ−Ｃｏｏｋｉｅヘッダ情報、およびｈｉｄｄｅｎタグ情報である、請求項１１に記載のコンピュータ・プログラム。
【請求項１４】
請求項１１、１２または１３に記載のコンピュータ・プログラムを格納した記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Ｗｅｂサービスを提供する方法、装置、プログラムに関する。さらに具体的には、ＷｅｂアプリケーションをＷｅｂサービスとして提供する方法、プロキシ装置、およびその制御プログラムに関する。
【背景技術】
【０００２】
近年、ＷｅｂアプリケーションをＷｅｂサービスとして提供する方法（Ｗｅｂサービス化）が知られている。ここで、Ｗｅｂアプリケーションとは、ユーザがＷｅｂブラウザなどを介してアクセスするＷｅｂサーバ上のアプリケーション・ソフトウェアであり、主としてユーザとＷｅｂサーバ上のアプリケーションとのインターフェースを中心とした技術で構築されている。一方、Ｗｅｂサービスとは、ある情報システムから他の情報システムをネットワークを通じて利用できるようにするシステム間のインターフェースを中心とした技術であり、または、それらの技術を使って作成され、展開されたソフトウェアの集合体を意味する。
【０００３】
既存のＷｅｂアプリケーションをＷｅｂサービスとしてシステム間で利用することができれば、Ｗｅｂサービスの提供者、Ｗｅｂアプリケーションの開発者、利用者にとって有用である。例えば、ＷｅｂアプリケーションとＷｅｂサービスを両方提供するような場合においては、まず先に通常のＷｅｂアプリケーションに注力して開発した後、Ｗｅｂサービスを提供するようなケースが多く存在する。需要が多いなどの理由で、まず必須要件となるＷｅｂアプリケーションを素早く開発した後に、Ｗｅｂサービスを提供して、開発コストを下げたいとの要求があるからである。また、第三者によって提供されているＷｅｂアプリケーションを利用するようなアプリケーションの開発では、その第三者のＷｅｂアプリケーションをＷｅｂサービスとして利用することにより、充実しているＷｅｂサービス開発のノウハウや開発環境を活用できるといった利点もある。
【０００４】
そのため、Ｗｅｂアプリケーションを変更することなく、Ｗｅｂサービスに変換する技術が知られている（例えば特許文献１、２）。
【特許文献１】特開２００５−１４９１３１公報
【特許文献２】特開２００５−５６０５８公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、従来技術では、Ｗｅｂアプリケーションの中で単一のユーザセッションのみを対象とし、複数のＷｅｂページにまたがってユーザセッションを保つ、いわゆるステートフル(Stateful)なＷｅｂアプリケーションには対応できていない。つまり、Ｗｅｂページを切り替えるたびにユーザセッションを新たに確立しなおすことを前提としている。例えば、特許文献１ではＷｅｂアプリケーションとＷｅｂサービスとの間のプロトコル分析、変換方法などが開示されているが、ユーザセッションの管理については記載されていない。
【０００６】
さらに、特許文献２は、ステートフルなＷｅｂアプリケーションに対応した例であるが、プロキシサーバでセッション状態を管理する必要があり、プロキシサーバとＷｅｂサービス・クライアントとの間でのセッション管理が複雑になる。また、セッション情報がどのように渡されるかを、明示的に指定してプロキシサーバを構成する必要があり、構成の手間がかかる。さらには、セッション情報は、プロキシサーバからＷｅｂサービス・クライアントへＷｅｂサービスの伝送層（ＨＴＴＰ）を通じて渡されるため、特殊な伝送層に対応したＷｅｂサービス・クライアントが必要になる。
【０００７】
したがって、ＷｅｂアプリケーションをＷｅｂサービスに変換するプロキシサーバに負担が少なく、かつ、サービスを要求するクライアント上で複雑なプログラミングや特殊なミドルウェアを必要としない柔軟なＷｅｂサービス・クライアントが構成できるような簡便な方法が望ましい。
【０００８】
本発明は、上記課題を解決し、ステートフルなＷｅｂアプリケーションに対して簡単で柔軟なＷｅｂサービス・クライアントの構成を可能にする方法を提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明は、Ｗｅｂサービス・クライアントのリクエストに対して、プロキシ装置が、Ｗｅｂアプリケーション・サーバにアクセスし、Ｗｅｂサービスを提供する方法であって、
Ｗｅｂサービス・クライアントのリクエストに応じて、アプリケーション・サーバにたいして、ＨＴＴＰリクエストを送るステップと、Ｗｅｂアプリケーション・サーバからの応答であるＨＴＴＰレスポンス中のエンティティ・ボディから抽出したアプリケーション情報に加え、ＨＴＴＰレスポンス中のエンティティ・ヘッダとエンティティ・ボディから抽出したユーザセッション情報を、Ｗｅｂサービス・クライアントヘのレスポンスに含めるステップと、Ｗｅｂサービス・クライアントからのリクエストに含まれたユーザセッション情報を、ＨＴＴＰリクエスト中のエンティティ・ヘッダとアプリケーション・データの一部としてエンティティ・ボディに含め、前記Ｗｅｂアプリケーション・サーバに送るステップと、を備えるＷｅｂサービスを提供する方法を提案する。
【００１０】
上記発明によれば、Ｗｅｂサービス・クライアントからのリクエストに応じて、プロキシ装置が、Ｗｅｂアプリケーションを格納するＨＴＴＰサーバに対して、ＨＴＴＰリクエストを発行する。ＨＴＴＰサーバからその返答であるＨＴＴＰレスポンスをプロキシ装置が受信すると、そこからユーザセッション情報を抽出して、Ｗｅｂサービス・クライアントへのレスポンスにこのユーザセッション情報を含める。Ｗｅｂサービス・クライアントは以後のリクエストに、そのユーザセッション情報をアプリケーション・データの一部として含め、かつ、他のアプケーション・データと区別可能なかたちで送ることができる。プロキシ装置は、受信したＷｅｂサービス・クライアントからのリクエストに含まれているユーザセッション情報を、ＨＴＴＰリクエストに埋め込んでＨＴＴＰサーバに送信するため、もとのユーザセッションを再開することができる。そのため、Ｗｅｂサービス・クライアント、プロキシ装置共にユーザセッション管理の負担をかけず、容易にＷｅｂサービス化を実現することができる。
【発明の効果】
【００１１】
本発明によれば、複雑なプログラミングなしに、既存のステートフルなＷｅｂアプリケーションをＷｅｂサービス化することができる。また、いったん本発明のＷｅｂサービス化を適用すれば、ＢＰＥＬ４ＷＳ(Business  Process  Execution  Language  for  Web  Service)のような言語で、複数のＨＴＴＰセッションに対応する複数のオペレーションを組み合わせて、１つのサービスとして提供することも可能になる。つまり、複数のＨＴＴＰセッションにまたがるようなＷｅｂアプリケーションの一連の操作を１つのサービスとして簡単に提供できる。
【発明を実施するための最良の形態】
【００１２】
以下、発明の実施形態を通じて本発明を説明する。なお、以下の実施形態は特許請求の範囲にかかる発明を限定するものではない。また、実施形態の中で説明されている構成要素の組み合わせの全てが発明の解決手段に必須であるとは限らない。
【００１３】
図１は、本発明に係るＷｅｂサービスを提供するシステム構成の概略を示す。Ｗｅｂサービスの提供を要求するＷｅｂサービス・クライアント３０はインターネット２０を介して、プロキシ装置１０と通信する。プロキシ装置１０は、Ｗｅｂアプリケーションを提供するＷｅｂアプリケーション・サーバ４０と通信路５０を介して通信する。通信路５０はローカル・エリア・ネットワーク（ＬＡＮ）であってよい。すなわち、プロキシ装置１０は、Ｗｅｂサービス・クライアント３０とＷｅｂアプリケーション・サーバ４０との間を仲介する役割をはたす。プロキシ装置１０とＷｅｂサービス・クライアント３０との間では、通信プロトコルとして、一般にはＳＯＡＰ（Simple  Object  Access  Protocol）を用いるが、他のプロトコル、例えば、ＣＯＲＢＡ(Common  Object  Request  Broker  Architecture)などにも応用が可能である。Ｗｅｂアプリケーション・サーバ４０とプロキシ装置１０の間では一般的なＨＴＴＰプロトコルが用いられる。以下の実施形態では、Ｗｅｂアプリケーション・サーバとのプロトコルはＳＯＡＰを例として説明するが、他のプロトコルであっても基本的な構成は同様である。
【００１４】
プロキシ装置１０は、Ｗｅｂサービス・クライアント３０に対するＳＯＡＰリクエストとそのレスポンスを処理するＳＯＡＰリクエスト受信部１１ｂ、リクエスト解析部１１ａと、レスポンス生成部１４ａ，ＳＯＡＰレスポンス送信部１４ｂを備える。さらに、プロキシ装置１０は、Ｗｅｂアプリケーション・サーバ４０に対するリクエストとレスポンスを処理するＨＴＴＰリクエスト生成部１２ａ、ＨＴＴＰリクエスト送信部１２ｂとＨＴＴＰレスポンス受信部１３ｂ、ＨＴＴＰレスポンス解析部１３ａおよび、全体を制御する制御部１５から構成される。
【００１５】
リクエスト解析部１１aは、ＳＯＡＰリクエスト受信部１１ｂを介して、Ｗｅｂサービス・クライアントからのＷｅｂサービスのリクエストを受信し、そのメッセージ内容を解析する。
【００１６】
ＨＴＴＰリクエスト生成部１２ａは、上記ＳＯＡＰリクエストに応じて、Ｗｅｂアプリケーション・サーバ４０にＨＴＴＰリクエストをＨＴＴＰリクエスト送信部１２ｂを介して送信する。
【００１７】
ＨＴＴＰレスポンス解析部１３aは、Ｗｅｂアプリケーション・サーバからのＨＴＴＰレクエストに対するＨＴＴＰレスポンスに含まれたセッション管理に必要な情報を抽出する。抽出の詳細については、後述する。
【００１８】
レスポンス生成部１４aは、制御部１５を介して、ＨＴＴＰレスポンス解析部１３aによって抽出されたセンション管理に必要な情報をＷｅｂサービス・クライアントへのＳＯＡＰレスポンスの中のＳＯＡＰボディに含める。Ｗｅｂサービス・クライアントは受信したＳＯＡＰレスポンスに含まれる上記ユーザセッション情報を以後のＳＯＡＰリクエストにそのまま含める。また、そのユーザセッション情報は、ＨＴＴＰリクエスト生成部１２aによって以後のＨＴＴＰリクエストに含められる。
【００１９】
上記送受信のプロセスを図４に示す。以下、図１のプロキシ装置１０を変換プロキシ６４、Ｗｅｂサービス・クライアント３０をＷＳクライアント６３、Ｗｅｂアプリケーション・サーバ４０をＷｅｂアプリケーション６２として表記する。比較のため、図２にステートレス（Ｗｅｂページが変わるたびにユーザセッションを確立しなおす）なＷｅｂアプリケーションとＷｅｂブラウザ６１を介したユーザとの送受信のプロセスを示した。ここで示されるように、ユーザが入力、クリックするたびにＷｅｂアプリケーションに対してＨＴＴＰリクエスト（Ｓ０２，Ｓ０６）が発行され、それに対するＨＴＴＰレスポンス（Ｓ０３，Ｓ０７）に応じて、Ｗｅｂブラウザ６１がフォーム表示や結果の表示を行う。
【００２０】
図３には、このようなステートレスなＷｅｂアプリケーションを、従来技術によってＷｅｂサービス化する変換プロキシを介して、ＷＳクライアント６３とＷｅｂアプリケーション６２との送受信のプロセスを示した。図３のプロセスでは、ＳＯＡＰリクエストＳ１１に応じてＨＴＴＰリクエストＳ１２が発行されるが、ＨＴＴＰレスポンスＳ１３からユーザセッション情報を抽出し、ＳＯＡＰレスポンスＳ１４にユーザセッション情報が含まれることはない。一方、図４で示されるプロセスでは、最初のＳＯＡＰリクエストＳ２１に対して、ＨＴＴＰリクエストＳ２２が発行され、Ｗｅｂアプリケーション・サーバから、ＨＴＴＰリクエストＳ２２に対するＨＴＴＰレスポンスＳ２３が返信されると、そのＨＴＴＰレスポンスＳ２３からユーザセッション情報が解析されて（自動的に）抽出される。
【００２１】
また、ＳＯＡＰリクエストＳ２５に含められたユーザセッション情報は（自動的に）ＨＴＴＰリクエストＳ２６に（適切に）埋め込まれる。このため、Ｓ２４で返されたユーザセッション情報がＳ２５に含めて送られると、Ｓ２２−Ｓ２３のセッションを継続してＳ２６−Ｓ２７の送受信を行なうことができるようになる。ＨＴＴＰレスポンスＳ２７からはやはり（自動的に）ユーザセッション情報が抽出され、Ｓ２８に含めて送られる。以降、同様に、送り返されたユーザセッション情報をＳＯＡＰリクエストに含めることにより、それに対応するＨＴＴＰ送受信は、もとのＨＴＴＰ送受信のセッションを継続して行なうことができる。これによって、ＳＯＡＰリクエストのたびにユーザセッションを確立しなおす必要がなくなり、以前のユーザセッションを再開することができるようになる。
【００２２】
ＷＳクライアント６３（図４参照）の機能は、典型的には、ＢＰＥＬ４ＷＳのような、ワークフローエンジン上に構成されたプログラムや、通常のJava(登録商標)のようなプログラミング言語で書かれたりするソフトウェアによって実現される。図５にその送受信プロセスの例を示した。ワークフローエンジン６５は、変換プロキシ６４により提供されるＷｅｂサービスポートから返信（Ｓ３４）されたセッション管理情報をそのまま、Ｗｅｂサービス化プロキシで提供される別のＷｅｂサービスポートに送ればよい（Ｓ３５）。
【００２３】
図６に、本発明に係る変換プロキシの動作を説明するために用いるＨＴＴＰリクエスト・レスポンスのメッセージ構成を示す。本発明に係る変換プロキシでは、すでに述べたようにＨＴＴＰサーバから送られるＨＴＴＰレスポンス７０に含まれるセッション情報を抽出し、ＨＴＴＰサーバから返されるユーザセッション情報として、ＨＴＴＰクライアントへのレスポンスに、その情報をエンティティ・ボディ（Entity-Body）７３中のアプリケーション・データとして、区別可能な一連情報として含める。
【００２４】
Entity-Body中にアプリケーション・データとしてユーザセッション情報を含めることによって、変換プロキシとＷｅｂサービス・クライアントとの間のセッション情報の管理が単純になる。つまり、ＳＯＡＰのトランスポート層であるＨＴＴＰのＣｏｋｋｉｅヘッダや、ＳＯＡＰヘッダのようなメタデータとしてＷｅｂサービス・クライアントと変換プロキシとの間でセッション管理情報が受け渡されることはない。Ｗｅｂサービス・クライアントは、セッション情報の存在自体は意識する必要があるが、その中身までを意識する必要はなく、セッション上連続する一つめのＷｅｂサービスレスポンスから得られたセッション情報をそのまま次のＷｅｂサービスリクエストに含めるだけでよい。これによって、得られたセッション情報を複数のクライアント・アプリケーション間で受け渡して用いるなど、柔軟なＷｅｂサービス・クライアントの構成が可能となる。
【００２５】
セッション情報として抽出するのは以下の３つのである。
１）Ｓｅｔ−Ｃｏｏｋｉｅヘッダ情報、および、エンティティ・ボディ中のＳＣＲＩＰＴ要素をエミュレートしたときに設定されるＣｏｏｋｉｅの値
２）エンティティ・ボディ中のＦＯＲＭ要素に指定されたａｃｔｉｏｎ属性値ＵＲＩ、または、通常のハイパーリンク先のＵＲＩ（以降の説明では、通常のハイパーリンクは、ＩＮＰＵＴコントロールがなくＧＥＴメソッドであるような、特殊なフォームであるとみなす。）
３）ＦＯＲＭ中のｔｙｐｅ属性がｈｉｄｄｅｎに設定されたＩＮＰＵＴコントロールのｎａｍｅ属性値とｖａｌｕｅ属性値のペア群
【００２６】
また、変換プロキシは、抽出したユーザセッション情報をＳＯＡＰレスポンスのＳＯＡＰボディに含めることによって、以後、Ｗｅｂサービス・クライアントがＷｅｂサービスのリクエストにこのユーザセッション情報をそのまま送れるようにし、受け取ったユーザセッション情報を、該当するセッション管理手法を用いてＨＴＴＰリクエスト６０３に埋め込んでＨＴＴＰサーバに送る。
【００２７】
＜データ構造＞
図７に、比較のため、従来のＷｅｂサービス化におけるＳＯＡＰリクエスト１００，ＳＯＡＰレスポンス１１０と、本発明に係るＷｅｂサービス化におけるＳＯＡＰリクエスト・レスポンスのデータ構造を示す。基本的には、セッション情報１０４がＳＯＡＰボディ１０１に加わっているだけと考えればよい。この構造では、セッション情報は常にアプリケーション・データとしてＳＯＡＰリクエスト１００のＳＯＡＰボディ１０１に含まれるため、変換プロキシにおいて内容をチェックする必要がなく、ＨＴＴＰリクエスト中にそのまま含めることができる。
【００２８】
図８に、セッション情報部の構造を示す。これらのうち、ａｃｔｉｏｎ（０か１個）は、Ｆｏｒｍタグのａｃｔｉｏｎ属性の値、Ｃｏｏｋｉｅ（０か１個）は、Ｓｅｔ-ＣｏｏｋｉｅヘッダやＣｏｏｋｉｅヘッダ、スクリプトなどで設定されるＣｏｏｋｉｅの値、ｈｉｄｄｅｎ（０個以上）は、ｈｉｄｄｅｎ属性のＩＮＰＵＴコントロールに設定されている名前（ｎａｍｅ）と値（ｖａｌｕｅ）の組が入る。
【００２９】
上記手法を用いることにより、セッション管理のための情報の設定は全て、変換プロキシにより自動的に行われ、ＵＲＩによるセッション管理の存在をユーザ（Ｗｅｂサービス・クライアント）が明示的に指定する必要はない。また、Ｆｏｒｍのａｃｔｉｏｎ属性値の書換えによるセッション管理や、Ｆｏｒｍの隠しフィールドの書換えによるセッション管理にも対応できる。
【００３０】
＜アルゴリズム＞
図９は、本発明に係るＷｅｂサービス化プロキシにおける、Ｗｅｂサービス化アルゴリズムの概要を示す。まず、ＳＯＡＰリクエストを受信すると（ステップＳ１００）、リクエスト解析部１１a(図１参照)がＳＯＡＰメーセージをデシリアライズ（非直列化）して解析する（ステップＳ１０１）。
【００３１】
次に、ＨＴＴＰリクエスト生成部１２ａ(図１参照)は、ＳＯＡＰリクエストに対してＨＴＴＰリクエストを生成する（ステップＳ１０２）。ここで、ＳＯＡＰメッセージの中にａｃｔｉｏｎエレメントが存在すれば、そのエレメント値に従ってＲｅｑｕｅｓｔ−ＵＲＩを変更する（ステップＳ１０３）。さらに、Ｃｏｏｋｉｅエレメントが存在すれば、Ｃｏｏｋｉｅエレメントの値を用いてＥｎｉｔｙ−Ｈｅａｄｅｒ中にＣｏｏｋｉｅヘッダを加える（ステップＳ１０４）。また、ｈｉｄｄｅｎエレメントが存在すれば、Ｒｅｑｕｅｓｔ−ＵＲＩにｎａｍｅ属性値とＶａｌｕｅ属性値のペアを、ＧＥＴメソッドのときはＲｅｑｕｅｓｔ−ＵＲＩに加え、ＰＯＳＴメソッドのときはＥｎｔｉｔｙ−Ｂｏｄｙに加える（ステップＳ１０５）。その後、ＨＴＴＰリクエストを送信する（ステップＳ１０６）。
【００３２】
次に、ＨＴＴＰレスポンス解析部１３ａ(図１参照)が、上記送信したＨＴＴＰリクエストのレスポンスを受信し（ステップＳ１０７）、内容を解析する（ステップＳ１０８）。このとき、ステータスコードがリダイレクトを示す“３ｘｘ”（ステップＳ１０９：Ｙｅｓ）であれば、リダイレクトＨＴＴＰリクエストの送信を行う（ステップＳ１１１）。また、ステータスコードが正常を示す“２００”であれば（ステップＳ１１０：ＹＥＳ）、レスポンス生成部１４ａ（図１参照）へ処理を渡す。
【００３３】
レスポンス生成部１４ａは、ＳＯＡＰレスポンスを生成し（ステップＳ１１３）、生成したＳＯＡＰレスポンスにセッション情報（sessionInfo部）を加える（ステップＳ１１４）。次に、アプリケーション部本体の情報を加えるために、ＨＴＭＬを解析し、エミュレートする（ステップＳ１１５）。さらに、ハンドルＥｎｔｉｔｙ−Ｈｅａｄｅｒ(ステップＳ１１６)、ハンドルＨＴＭＬ  Ｓｃｒｉｐｔ（ステップＳ１１７）、ハンドル  ＨＴＭＬ  Ｆｏｒｍ（ステップＳ１１８）の各処理（後述）を行う。最後に、ＳＯＡＰレスポンスを送信して（ステップＳ１１９）、処理を終了する。
【００３４】
図１０は、ＨＴＴＰリクエスト生成（ステップＳ１０２）の詳細を示している。まず、アダプター・コンフィギュレーション（後述）の設定に従って、ＨＴＴＰ  Ｒｅｑｕｅｓｔ−Ｌｉｎｅをセットし（ステップＳ１０２ａ）、ＨＴＴＰ  Ｅｎｔｉｔｙ−ＨｅａｄｅｒをＵｓｅｒ−Ａｇｅｎｔのようなヘッダとともにセットする（ステップＳ１０２ｂ）。また、ＨＴＴＰ  Ｅｎｔｉｔｙ−Ｂｏｄｙを空にセットする（ステップＳ１０２ｃ）。次に、アプリケーション部（“sessionInfo”でない部分）からｎａｍｅ属性値とｖａｌｕｅ属性値のペアを抽出する（ステップＳ１０２ｄ）。そして、ＧＥＴメソッドのときは、Ｒｅｑｕｅｓｔ−ＵＲＩにｎａｍｅ属性値とｖａｌｕｅ属性値のペアを加え（ステップＳ１０２ｆ）、ＰＯＳＴメソッドのときは、Ｅｎｔｉｔｙ−Ｂｏｄｙにｎａｍｅ属性値とｖａｌｕｅ属性値のペアを加える（ステップＳ１０２ｇ）。
【００３５】
図１１〜１３は、ａｃｔｉｏｎ，ｃｏｏｋｉｅ，ｈｉｄｄｅｎの各ハンドル（Ｓ１０３、Ｓ１０４、Ｓ１０５）の処理を表したものであるが、図９の説明で既に明らかであるのでここでは説明を省略する。
【００３６】
図１４〜図１６は、受け取ったＨＴＴＰレスポンスからＷｅｂサービスのレスポンスを生成するアルゴリズムの詳細を示している。ハンドルＥｎｔｉｔｙ−Ｈｅａｄｅｒ（ステップＳ１１６）では、Ｅｎｔｉｔｙ−Ｈｅａｄｅｒ中にＳｅｔ−Ｃｏｏｋｉｅヘッダがあれば（ステップＳ１１６ａ：Ｙｅｓ）、そのヘッダに従って、ｃｏｏｋｉｅエレメントを加える（ステップＳ１１６ｂ）。ハンドルＨＴＭＬ  Ｓｃｒｉｐｔ（ステップＳ１１７）では、Ｓｃｒｉｐｔによってセットされたｃｏｏｋｉｅがあれば（ステップＳ１１７ａ：Ｙｅｓ）、そのＳｃｒｉｐｔのエミュレーションの結果に従ってｃｏｏｋｉｅエレメントを加える（ステップＳ１１７ｂ）。ハンドルＨＴＭＬ  Ｆｏｒｍ（ステップＳ１１８）では、ＨＴＭＬ  Ｆｏｒｍ中のａｃｔｉｏｎ属性値に従ってａｃｔｉｏｎエレメントを加える（ステップＳ１１８ａ）。つぎに、ｈｉｄｄｅｎ  ｉｎｐｕｔが存在すれば（ステップＳ１１８ｂ：Ｙｅｓ）、ｈｉｄｄｅｎ  ｉｎｐｕｔに従って、ｈｉｄｄｅｎエレメントを加える（ステップＳ１１８ｃ）。
【００３７】
＜設定方法＞
本発明に係るＷｅｂサービス化プロキシには、図１７のような設定情報（アダプター・コンフィギュレーション）を与える。「HTTP  Server  to  adapt」部５００は、ＨＴＴＰサーバのホスト名またはＩＰアドレスと、ＴＣＰポートを与える。「WSDL  setting」部５０１は、生成するＷＳＤＬ（Web  Service  Description  Language）の名前空間や名前を指定する。ここで、ＷＳＤＬとはＷｅｂサービスの内容を説明するＸＭＬの文法であり、Ｗｅｂサービス・クライアントが参照する。
【００３８】
１つのＨＴＭＬページ内には、複数のフォーム（ＦＯＲＭ要素）を含めることができるが、簡潔にするため、１つのＨＴＭＬページにつき１つのフォームであると仮定して以降は説明する。複数のフォームに対応するためには、１つのフォームにつき、１つのＷｅｂサービス・オペレーションを対応させる。
【００３９】
「Flag  for  State-aware」部５０２は、ステートフル・Ｗｅｂアプリケーションに対応するかどうかを指定する。ここがｆａｌｓｅの場合は、従来型のステートレス・Ｗｅｂアプリケーションのみに対応したＷｅｂサービス化が行なわれ、ｔｒｕｅの場合、本発明に係るステートフルなＷｅｂアプリケーションに対応したＷｅｂサービス化が行なわれる。
【００４０】
ＨＴＴＰのセッション（ＨＴＴＰリクエストとレスポンスの組）ごとに、「HTTP  Request  Method」部５０３、「WSDL  operation  name」部５０４、「Request  setting」部５０５、「Response  setting」部５０６を設定する。これらのうち、「HTTP  Request  Method」部５０３は、ＧＥＴまたはＰＯＳＴを指定し、「WSDL  operation  name」部５０４には、対応させるＷＳＤＬオペレーションの名前を指定する。
【００４１】
「Request  setting」部５０５では、本来ユーザが入力する情報のうちどの部分をＷｅｂサービスのリクエストとして受け取れるようにして、どの部分を固定しておくかを指定する。また、「Response  setting」部５０６では、サーバから帰ってきたＨＴＭＬコンテントのうち、どの部分をＷｅｂサービスのレスポンスとして返すようにするかを指定する。
【００４２】
ＨＴＭＬのどの部分をどのように取り出すかについては、[“A  Brief  Survey  of  Web  Data  Extraction  Tools”,  Alberto  H.  F.  Laender  and  Berthier  A.  Ribeiro-Neto,  ACM  SIGMOD  Record,  Volume  31,  Issue  2,  June  2002.]で紹介されているような既存の技術であるため、ここでは詳細の説明は省略する。また、既存の技術を自由に適用可能である。例えば、あるＸＰａｔｈで指定されたＨＴＭＬ中の部分を、ＸＭＬ（eXtensible  Markup  Language）スキーマの文字列型に変換し、指定した要素で包む、といったことを記述できる。
【００４３】
＜ＷＳＤＬの生成＞
上述の設定情報を元に、場合によっては名前付けのマッピングなどのユーザの指定を追加し、Ｗｅｂサービス化によって得られるサービスのＷＳＤＬを生成する。基本的には、「Request  setting」部５０５で指定された情報をＷｅｂサービスリクエスト中のMessage  Partにマップし、「Response  setting」部５０５で指定された情報をＷｅｂサービスレスポンス中のMessage  Partにマップする。さらに、設定情報に関係なく、エラー時のメッセージを適切に規定する。このような処理は、ＷｅｂアプリケーションのＷｅｂサービス化を行なうツール一般に共通である。
【００４４】
図１８上部は、この一般的なＷＳＤＬ生成系（WSDL  Generator）を示しているが、本発明に係る手法では、図１８下部のように、stateful-awarenessフラグ（５１０）を参照して、これにセッション情報（５２０）を運ぶために必要な部分がＷＳＤＬに追加される。本発明に係る手法では、セッション情報を運ぶためのMessage  Partを自動的に定義し、ＷＳＤＬ記述に追加する。具体的には、図６で示した構造のデータを、通常のMessage  Partの一部、または、別Message  PartとするようなＷＳＤＬを生成する。
【００４５】
図１９にこのアルゴリズムを示した。まず、与えられた設定情報（通常のプロセス）に従ってＷＳＤＬ記述(WSDL  Description)を生成する（ステップＳ５４１）。次に、statefulness-awareオプション(図１７の５０２に相当)をＲｅａｄする（ステップＳ５４２）。そのstatefulness-awareオプションがＴｒｕｅであれば（ステップＳ５４３：Ｔｒｕｅ）、セッション情報(sessionInfo部)をWSDL記述の中のそれぞれのメッセージに対して加える（ステップＳ５４４）。
【００４６】
以下、具体的な例に即して説明する。
＜ＷＳＤＬの生成例＞
図２０に示すような設定情報が与えられたとする。この与えられた設定情報から、図２１に示すようなＷＳＤＬを生成する。
【００４７】
ここでは、セッション情報を別Message  Part（SessionInfo部）とし、本来のフォーム入力や結果相当の情報をそれとは別のMessage  Part（RequrestDocument/ResponseDocument部）としている。別の方法としては、セッション情報要素（html2ws:sessionInfo）とフォーム入力要素(app:searchRequestElement)の内容を内包する１つのパートと、セッション情報要素（html2ws:sessionInfo）と結果要素(app:searchResponseElement)の内容を内包する1つのパートとして、それぞれsearchRequestとsearchResponseメッセージの内容としてもよい。本来、後者の形式のほうが典型的なＷｅｂサービスであり扱いやすいが、ここではセッション情報要素の出現を分かりやすくするために、前者の方法を用いた場合で説明していく。
【００４８】
図２１のＷＳＤＬに従って作られたＷｅｂサービス・クライアントから送られてくるメッセージのうち、ＷＳＤＬのオペレーションsearchに相当するものは、図２２のようになる。
【００４９】
ここでは、本発明に係るプロキシにより、[数１]のＳＯＡＰリクエストが[数２]のＨＴＴＰPリクエストに変換され、[数３]のＨＴＴＰレスポンスが[数４]のＳＯＡＰレスポンスに変換されている。
【数１】
2007026150.tif 000003
【数２】
2007026150.tif 000004
【数３】
2007026150.tif 000005
【数４】
2007026150.tif 000006
【００５０】
＜Ｗｅｂサービスを構成する例＞
以下、単純なステートフルＷｅｂアプリケーションから本発明に係るＷｅｂサービス化プロキシを利用して得られる複数のＷｅｂサービスポートを、ＢＰＥＬ４ＷＳを用いて組み合わせて、単一のＷｅｂサービスを構成する例を示す。図２３は、対象とするＷｅｂアプリケーション「Ｓｈｏｐ」の画面（ページ）遷移図である。ただし、ここでは、Ｗｅｂサービス化上興味のないページは省かれており、また、Ｗｅｂサービス化上興味のないページ遷移（点線で示してある）は以降の説明には用いない。
【００５１】
このＷｅｂアプリケーションは、次のような動作をする。
１）ユーザが公開されているＵＲＩにアクセスするとログイン・ページ（Login）７０１が表示される。
２）ログイン・ページ（Login）７０１で、フォームからユーザ名（Username）７０２とパスワード（Password）７０３を受け取り、ログインに成功するとカタログ・ページ（Catalog）７０４が表示される。
３）カタログ・ページ（Catalog）７０４で、フォームのリストから商品を選ぶ（Item  No.）７０５と、その商品情報を示すページ（Item）７０６が表示される。ただし、その商品の在庫がない場合は、在庫切れを示すページ（No  Stock）７０７が表示される。
４）商品情報ページ（Item）７０６で、フォームの「買う」ボタンを押すと、その商品が入れられた買い物かごを示すページ（Shopping  Cart）７０８が表示される。
５）買い物かごページ（Shopping  Cart）７０８から、フォームの「発注」ボタンを押すと、買い物かごに入っている商品を発注したことになり、発注情報ページ（Order）７０９が表示される。発注情報ページ（Order）７０９には、配達予定日(Delivery  Date)７１０を示す情報が示される。
【００５２】
本発明に係るＷｅｂサービス化プロキシに適切な設定情報（次のページに遷移するのに必要な入力フォームの情報、次のページから抽出されるデータと抽出方法、ＷＳＤＬ上の名前付けなど）を与えると、図２４に示す、点線の四角（７１１〜７１５）に当る部分に相当するＷｅｂサービスポート５つが構成される。各ポートのオペレーションを点線の四角の左に示した。
【００５３】
構成されたＷｅｂサービスポートは上述のＷｅｂアプリケーションの動作に対応した、次の５つである。
1）start()  セッション管理情報(context)を返す（res0）。（実際contextの中身は常に空である。）
２）login()  セッション管理情報（context）、ユーザ名（username）、パスワード（password）を受け取り（req1）、セッション管理情報(context)を返す（res1）。
３）showItem()  セッション管理情報（context）、商品番号（item  number）を受け取り（req2）、セッション管理情報（context）、在庫があるかどうか（is  in  stock?）を返す（res2）。遷移先のページ（ItemまたはNo  Stock）からは在庫切れページであったかどうかが（XPath指定の評価結果などにより）抽出される。
４）putItemIntoCart()  セッション管理情報（context）を受け取り（req3）、セッション管理情報（context）を返す（res3）。
５）orderItemsInCart()  セッション管理情報（context）を受け取り（req4）、セッション管理情報（context）、配送予定日（delivery  date）を返す（res4）。遷移先のページ（Order）からは、配送予定日を示す部分が（XPath指定の評価結果などにより）抽出される。
【００５４】
この得られた５つのＷｅｂサービスポートにアクセスして、１つのＷｅｂサービスを提供するようなＢＰＥＬ４ＷＳプログラムは次のように書くことができる。
【数５】
2007026150.tif 000007
【数６】
2007026150.tif 000008
【００５５】
このＢＰＥＬ４ＷＳプログラムにより構成されるＷｅｂサービス（オペレーション名buyItem）は、商品番号（app2:itemNumber）、ユーザ名（app2:username）、パスワード（app2:password）を受け取り（request変数、行4-5）、配送予定日（app2:deliveryDate）を返す（response変数、行79-80）。詳細の説明は省くが、以降、本発明の応用可能性を示すために重要な部分について説明する。
【００５６】
各invoke部（行7-9、行26-28、行41-43、行57-59、行68-70）で本発明に係るＷｅｂサービス化により得られたＷｅｂサービスポートにアクセスしている。例えば、最初のinvoke部（行7-9）では、operation=“start”として、「start」オペレーションを呼び出している。サービスを呼び出した結果返ってくる値は、outputVariable=“res0”とすることにより、変数res0に格納される。その他の属性の指定は、単なる名前付けやＷＳＤＬ中の記述を指し示すためのものであり、ここでは特に気にしなくてよい。また、最初のinvoke部（行7-9）では用いていないが、inputVariable=“x”とすることにより、変数xに格納されている値をサービスを呼び出す際に受け渡すことができる。
【００５７】
各assign部（行11-24、行30-39、行44-49、行61-66、行72-77）で、前後２つのＷｅｂサービス呼び出し（invoke部）間で受け渡されるデータ（セッション管理情報）、及び、後ろのinvoke部のアクセス時に与えるその他のデータ（ユーザ名、パスワード、商品番号）を設定している。例えば、最初のassign部（行11-24）では、次のような操作をしている。
１）「start」オペレーション（行7-9）と「login」オペレーション（行26-28）の間に位置し、「start」の結果が入った変数res0から「login」に渡す変数req1で示される値中に、セッション情報パート（http2ws:SessionInfo）をコピー（行12-15）する。
２）「login」オペレーション（行26-28）に渡す変数req1で示される値中に、プログラムによって構成されるオペレーションbuyItemの受け取る値の格納された変数requestから、ユーザ名（app2:username）とパスワード（app2:password）をコピー（行16-23）する。
【００５８】
このように、本発明に係る手法を利用すると、受け取ったセッション情報はそのまま次のオペレーション呼び出し時に用いて渡すだけで、ステートフルなＷｅｂアプリケーションをＷｅｂサービス化したものに、問題なくアクセスできるようになる。後の処理は、複数Ｗｅｂサービスを組み合わせる際の通常の処理であり、本発明に係る手法に特有ではない。基本的には、アプリケーション固有の必要な入力をオペレーション呼び出し時に渡し、アプリケーション固有の必要な出力をオペレーション呼び出しから受け取ればよい。
【００５９】
本発明に係る手法を利用して得られたサービスを単純に順番に呼び出すだけでなく、各サービスのオペレーション呼び出しの結果によって制御の流れを変えたり、セッション情報以外の呼び出し結果を後の呼び出しに用いたりすることは自由に行なえる。例えば、「invokeShowItem」invokeと直後のassign部の後ろのswitch部（行51-55）では、switch構文を用いて、showItemオペレーションを呼び出して得られた結果（res2）のうちの、在庫があるかどうかの情報（app:isInStock）を調べて、在庫切れだった場合に、（プログラムで構成されるＷｅｂサービスである）buyItem呼び出しの結果としてＳＯＡＰフォールト  を返すようにしている。
【００６０】
同じプログラムを１つの図中に示したものが図２５である。最初の<receive  name>部８０１が、構成されるＷｅｂサービスの受け取るメッセージを規定し、最後の<reply  name>部８０２が、構成されるＷｅｂサービスの返すメッセージを規定している。９０１〜９０５の<invoke>部が、Ｗｅｂサービスとのやりとりを示している。図２６は、これに、データのフローを示すための矢印を加えたものである。点線の矢印はセッション管理情報のフローを示し、破線の矢印はページから抽出されたデータのフローを示し、一点鎖線の矢印は、フォームの入力に用いられるデータのフローを示している。
【００６１】
セッション管理情報（http2ws:sessionInfo）は、基本的に、プログラムの制御の流れに沿って用いられる。プログラムの制御はここでは一部の分岐を除いて直線的だが、ループや分岐をもっていてもよく、セッション管理情報（http2ws:sessionInfo）は、その流れに沿って用いられることになる。
【００６２】
また、ここでは、ページから抽出されたデータの流れ（点線の矢印）と、フォームの入力に用いられるデータの流れ（一点鎖線の矢印）は、独立であるが、プログラムによっては繋がる（抽出されたデータをフォームの入力に用いる）こともありえる。しかしながら、ユーザのログインを必要とするアプリケーションや、買い物カゴのようなユーザフレンドリな機能を提供しているようなアプリケーション（ステートフルＷｅｂアプリケーション）をＷｅｂサービス化するためには、以下のようなユーザセッションの考慮が必要である。
【００６３】
以上、本発明を実施形態、具体例を用いて説明したが、本発明の技術的範囲は上記実施形態に記載の範囲に限定されない。上記実施形態に、多様な変更または改良を加えることができる。そのような変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。
【００６４】
また、本発明は、ひとつの実施形態として、主にプロキシ装置またはプロキシサーバ上のコンピュータ・プログラムによって実現可能である。上記プログラムを格納する記憶媒体としては、ハードティスクの他、フロッピー（登録商標）ディスクなどの磁気記録媒体、ＣＤ−ＲＯＭ，ＤＶＤやＰＤ等の光学記録媒体、ＭＤ等の光磁気記録媒体、テープ媒体、ＩＣカード等の半導体メモリ等を用いることができる。また、上記プログラムはネットワークに接続されたサーバシステム内に設けたハードディスクまたはＲＡＭ等の記憶装置を媒介として、コンピュータ・システムに提供されてもよい。
【図面の簡単な説明】
【００６５】
【図１】本発明に係るシステム構成図を示す図である。
【図２】ステートレスなＷｅｂアプリケーションとユーザのやりとりを示す図である。
【図３】従来のステートレスなＷｅｂアプリケーションをＷｅｂサービス化した場合を示す図である。
【図４】本発明に係るＷｅｂサービス化を示す図である。
【図５】Ｗｅｂサービス化を利用した２つのＷｅｂサービス間におけるセッション管理情報の送受信プロセス例を示した図である。
【図６】ＨＴＴＰメッセージの構造のメッセージ例を示す図である。
【図７】ＳＯＡＰメッセージの構造（左：従来手法によるもの、右：本発明に係る手法によるもの）を示す図である。
【図８】本発明に係るセッション情報部の構造を示す図である。
【図９】本発明に係るＷｅｂサービス化のアルゴリズムの概略を示す図である。
【図１０】ＨＴＴＰリクエストの生成アルゴリズムを示す図である。
【図１１】リクエスト用ユーザセッション情報の処理アルゴリズム（１）を示す図である。
【図１２】リクエスト用ユーザセッション情報の処理アルゴリズム（２）を示す図である。
【図１３】レスポンス用ユーザセッション情報の処理アルゴリズム（３）を示す図である。
【図１４】レスポンス用ユーザセッション情報の処理アルゴリズム（１）を示す図である。
【図１５】レスポンス用ユーザセッション情報の処理アルゴリズム（２）を示す図である。
【図１６】レスポンス用ユーザセッション情報の処理アルゴリズム（３）を示す図である。
【図１７】本発明に係る手法のＷｅｂサービス化プロキシに与える設定情報を示す図である。
【図１８】ＷＳＤＬ生成系（ＷＳＤＬ  Ｇｅｎｅｒａｔｏｒ）を示す図である。
【図１９】ＷＳＤＬ生成アルゴリズムを示す図である。
【図２０】変換プロキシに対する設定の例を示す図である。
【図２１】与えられた設定から自動生成されたＷＳＤＬ例を示す図である。
【図２２】searchオペレーションのメッセージ例を示す図である。
【図２３】単純なＷｅｂアプリケーション例「Ｓｈｏｐ」の画面遷移図である。
【図２４】Ｗｅｂアプリケーション「Ｓｈｏｐ」に本発明に係る手法を適用してできる５つのＷｅｂサービスポートを示す図である。
【図２５】Ｗｅｂサービス・クライアント上でのＢＰＥＬ４ＷＳプログラム・リスト例
【図２６】ＢＰＥＬ４ＷＳプログラム・リスト例中のデータフローを示す図である。
【符号の説明】
【００６６】
１０    プロキシ装置
１１ａ  リクエスト解析部
１１ｂ  ＳＯＡＰリクエスト受信部
１２ａ  ＨＴＴＰリクエスト生成部
１２ｂ  ＨＴＴＰリクエスト送信部
１３ａ  ＨＴＴＰレスポンス解析部
１３ｂ  ＨＴＴＰレスポンス受信部
１４ａ  レスポンス生成部
１４ｂ  ＳＯＡＰレスポンス送信部
１５    制御部
２０    インターネット
３０    Ｗｅｂサービス・クライアント
４０    Ｗｅｂアプリケーション・サーバ
５０    通信路
６０    ユーザ
６１    Ｗｅｂブラウザ
６２    Ｗｅｂアプリケーション
６３    ＷＳクライアント
６４    変換プロキシ
１００  ＳＯＡＰリクエスト
１０１  ＳＯＡＰ エンベロープ
１０２  ユーザ入力をエミュレートする情報
１０３  ＨＴＭＬから抽出した情報
１０４  セッション情報
７０１  ログイン・ページ
７０４  カタログ・ページ
７０６  商品情報ページ
７０７  在庫切れページ
７０８  買い物かごページ
７０９  発注情報ページ
【図１】
2007026150.tif 000009
【図２】
2007026150.tif 000010
【図３】
2007026150.tif 000011
【図４】
2007026150.tif 000012
【図５】
2007026150.tif 000013
【図６】
2007026150.tif 000014
【図７】
2007026150.tif 000015
【図８】
2007026150.tif 000016
【図９】
2007026150.tif 000017
【図１０】
2007026150.tif 000018
【図１１】
2007026150.tif 000019
【図１２】
2007026150.tif 000020
【図１３】
2007026150.tif 000021
【図１４】
2007026150.tif 000022
【図１５】
2007026150.tif 000023
【図１６】
2007026150.tif 000024
【図１７】
2007026150.tif 000025
【図１８】
2007026150.tif 000026
【図１９】
2007026150.tif 000027
【図２０】
2007026150.tif 000028
【図２１】
2007026150.tif 000029
【図２２】
2007026150.tif 000030
【図２３】
2007026150.tif 000031
【図２４】
2007026150.tif 000032
【図２５】
2007026150.tif 000033
【図２６】
2007026150.tif 000034