JP2007026150A - Ｗｅｂサービスを提供する方法、装置、プログラム - Google Patents

Abstract

【課題】既存のＷｅｂアプリケーションをＷｅｂサービスとして提供する方法において、複数ページにまたがってユーザセッションを保つＷｅｂアプリケーションに対応でき、変換プロキシとＷｅｂサービス・クライアントにとって簡便な方法が求められている。
【解決手段】Ｗｅｂアプリケーションを格納するＨＴＴＰサーバから送られるＨＴＴＰレスポンスから、典型的に用いられるセッション管理手法によって埋め込まれたセッション情報を抽出する。これら抽出された情報を、ＨＴＴＰサーバから返されるユーザセッション情報として、Ｗｅｂサービスのレスポンスに含める。また、Ｗｅｂサービスのリクエストにこのユーザセッション情報を含めて送れるようにし、Ｗｅｂサービス・クライアントから受け取ったユーザセッション情報を、該当するセッション管理手法を用いてＨＴＴＰリクエストに埋め込んでＨＴＴＰサーバに送る。
【選択図】 図１

Description

本発明は、Ｗｅｂサービスを提供する方法、装置、プログラムに関する。さらに具体的には、ＷｅｂアプリケーションをＷｅｂサービスとして提供する方法、プロキシ装置、およびその制御プログラムに関する。

近年、ＷｅｂアプリケーションをＷｅｂサービスとして提供する方法（Ｗｅｂサービス化）が知られている。ここで、Ｗｅｂアプリケーションとは、ユーザがＷｅｂブラウザなどを介してアクセスするＷｅｂサーバ上のアプリケーション・ソフトウェアであり、主としてユーザとＷｅｂサーバ上のアプリケーションとのインターフェースを中心とした技術で構築されている。一方、Ｗｅｂサービスとは、ある情報システムから他の情報システムをネットワークを通じて利用できるようにするシステム間のインターフェースを中心とした技術であり、または、それらの技術を使って作成され、展開されたソフトウェアの集合体を意味する。

既存のＷｅｂアプリケーションをＷｅｂサービスとしてシステム間で利用することができれば、Ｗｅｂサービスの提供者、Ｗｅｂアプリケーションの開発者、利用者にとって有用である。例えば、ＷｅｂアプリケーションとＷｅｂサービスを両方提供するような場合においては、まず先に通常のＷｅｂアプリケーションに注力して開発した後、Ｗｅｂサービスを提供するようなケースが多く存在する。需要が多いなどの理由で、まず必須要件となるＷｅｂアプリケーションを素早く開発した後に、Ｗｅｂサービスを提供して、開発コストを下げたいとの要求があるからである。また、第三者によって提供されているＷｅｂアプリケーションを利用するようなアプリケーションの開発では、その第三者のＷｅｂアプリケーションをＷｅｂサービスとして利用することにより、充実しているＷｅｂサービス開発のノウハウや開発環境を活用できるといった利点もある。

そのため、Ｗｅｂアプリケーションを変更することなく、Ｗｅｂサービスに変換する技術が知られている（例えば特許文献１、２）。
特開２００５−１４９１３１公報 特開２００５−５６０５８公報

しかしながら、従来技術では、Ｗｅｂアプリケーションの中で単一のユーザセッションのみを対象とし、複数のＷｅｂページにまたがってユーザセッションを保つ、いわゆるステートフル(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リクエストに変換され、[数３]のＨＴＴＰレスポンスが[数４]のＳＯＡＰレスポンスに変換されている。

＜Ｗｅｂサービスを構成する例＞
以下、単純なステートフルＷｅｂアプリケーションから本発明に係るＷｅｂサービス化プロキシを利用して得られる複数のＷｅｂサービスポートを、ＢＰＥＬ４ＷＳを用いて組み合わせて、単一のＷｅｂサービスを構成する例を示す。図２３は、対象とするＷｅｂアプリケーション「Ｓｈｏｐ」の画面（ページ）遷移図である。ただし、ここでは、Ｗｅｂサービス化上興味のないページは省かれており、また、Ｗｅｂサービス化上興味のないページ遷移（点線で示してある）は以降の説明には用いない。

このＷｅｂアプリケーションは、次のような動作をする。
１）ユーザが公開されているＵＲＩにアクセスするとログイン・ページ（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指定の評価結果などにより）抽出される。

この得られた５つのＷｅｂサービスポートにアクセスして、１つのＷｅｂサービスを提供するようなＢＰＥＬ４ＷＳプログラムは次のように書くことができる。

このＢＰＥＬ４ＷＳプログラムにより構成されるＷｅｂサービス（オペレーション名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オペレーションのメッセージ例を示す図である。 単純なＷｅｂアプリケーション例「Ｓｈｏｐ」の画面遷移図である。 Ｗｅｂアプリケーション「Ｓｈｏｐ」に本発明に係る手法を適用してできる５つのＷｅｂサービスポートを示す図である。 Ｗｅｂサービス・クライアント上でのＢＰＥＬ４ＷＳプログラム・リスト例 ＢＰＥＬ４ＷＳプログラム・リスト例中のデータフローを示す図である。

符号の説明

１０ プロキシ装置
１１ａ リクエスト解析部
１１ｂ ＳＯＡＰリクエスト受信部
１２ａ ＨＴＴＰリクエスト生成部
１２ｂ ＨＴＴＰリクエスト送信部
１３ａ ＨＴＴＰレスポンス解析部
１３ｂ ＨＴＴＰレスポンス受信部
１４ａ レスポンス生成部
１４ｂ ＳＯＡＰレスポンス送信部
１５ 制御部
２０ インターネット
３０ Ｗｅｂサービス・クライアント
４０ Ｗｅｂアプリケーション・サーバ
５０ 通信路
６０ ユーザ
６１ Ｗｅｂブラウザ
６２ Ｗｅｂアプリケーション
６３ ＷＳクライアント
６４ 変換プロキシ
１００ ＳＯＡＰリクエスト
１０１ ＳＯＡＰ エンベロープ
１０２ ユーザ入力をエミュレートする情報
１０３ ＨＴＭＬから抽出した情報
１０４ セッション情報
７０１ ログイン・ページ
７０４ カタログ・ページ
７０６ 商品情報ページ
７０７ 在庫切れページ
７０８ 買い物かごページ
７０９ 発注情報ページ

Claims (14)

1. Ｗｅｂサービス・クライアントのリクエストに対して、プロキシ装置が、Ｗｅｂアプリケーション・サーバにアクセスし、Ｗｅｂサービスを提供する方法であって、
   前記Ｗｅｂサービス・クライアントのリクエストに応じて、前記アプリケーション・サーバに対して、ＨＴＴＰリクエストを送るステップと、
   前記Ｗｅｂアプリケーション・サーバからの応答であるＨＴＴＰレスポンス中のエンティティ・ボディから抽出したアプリケーション情報に加え、前記ＨＴＴＰレスポンス中のエンティティ・ヘッダとエンティティ・ボディから抽出したユーザセッション情報を、前記Ｗｅｂサービス・クライアントヘのレスポンスに含めるステップと、
   前記Ｗｅｂサービス・クライアントからのリクエストに含まれた前記ユーザセッション情報を、ＨＴＴＰリクエスト中のエンティティ・ヘッダとアプリケーション・データの一部としてエンティティ・ボディに含め、前記Ｗｅｂアプリケーション・サーバに送るステップと、
   を備えるＷｅｂサービスを提供する方法。
2. 前記Ｗｅｂサービス・クライアントのリクエストが、ＳＯＡＰリクエストであり、このリクエストに対する応答がＳＯＡＰレスポンスである請求項１に記載のＷｅｂサービスを提供する方法。
3. 前記ユーザセッション情報が、ＵＲＩ情報、Ｓｅｔ−Ｃｏｏｋｉｅヘッダ情報、およびｈｉｄｄｅｎタグ情報である請求項１に記載のＷｅｂサービスを提供する方法。
4. 前記プロキシ装置が、ユーザからあらかじめ与えられたコンフィギュレーション情報に基づき、Ｗｅｂサービス・インターフェース情報としてＷＳＤＬを生成するステップを備える請求項３に記載のＷｅｂサービスを提供する方法。
5. 前記コンフィギュレーション情報は、Ｗｅｂアプリ−ションが複数セッションを含むかどうかを前記プロキシ装置に指示する情報を含む請求項４に記載のＷｅｂサービスを提供する方法。
6. 前記ＷＳＤＬに、前記ＨＴＴＰリクエストに含める前記ユーザセッション情報を、前記ＳＯＡＰリクエストの一部として含める記述を追加する請求項４に記載のＷｅｂサービスを提供する方法。
7. 前記ＷＳＤＬに、前記ＨＴＴＰレスポンス中の、前記ユーザセッション情報を、前記ＳＯＡＰレスポンスの一部として含める記述を追加する請求項４に記載のＷｅｂサービスを提供する方法。
8. Ｗｅｂサービス・クライアントのリクエストに対して、Ｗｅｂアプリケーション・サーバにアクセスし、Ｗｅｂサービスを提供するプロキシ装置であって、
   前記Ｗｅｂアプリケーション・サーバからの応答であるＨＴＴＰレスポンス中のエンティティ・ボディから抽出したアプリケーション情報に加え、前記ＨＴＴＰレスポンス中のエンティティ・ヘッダとエンティティ・ボディから抽出したユーザセッション情報を、前記Ｗｅｂサービス・クライアントヘのレスポンスに含めるレスポンス生成部と、
   前記Ｗｅｂサービス・クライアントのリクエストに含まれた前記ユーザセッション情報を、ＨＴＴＰリクエスト中にエンティティ・ヘッダとアプリケーション・データの一部としてエンティティ・ボディに含めるＨＴＴＰリクエスト生成部と、
   前記ＨＴＴＰリクエスト生成部によって生成された前記ＨＴＴＰリクエストを、前記Ｗｅｂサービス・クライアントのリクエストに応じて、前記Ｗｅｂアプリケーション・サーバに送るＨＴＴＰリクエスト送信部と、
   を備えるプロキシ装置。
9. 前記Ｗｅｂサービス・クライアントのリクエストが、ＳＯＡＰリクエストであり、このリクエストに対する応答がＳＯＡＰレスポンスである請求項８に記載のプロキシ装置。
10. 前記ユーザセッション情報が、ＵＲＩ情報、Ｓｅｔ−Ｃｏｏｋｉｅヘッダ情報、およびｈｉｄｄｅｎタグ情報である、請求項８に記載のプロキシ装置。
11. Ｗｅｂサービス・クライアントのリクエストに対して、Ｗｅｂアプリケーション・サーバにアクセスし、Ｗｅｂサービスを提供するためのコンピュータ・プログラムであって、コンピュータに、
    前記Ｗｅｂサービス・クライアントのリクエストに応じて、前記アプリケーション・サーバに対して、ＨＴＴＰリクエストを送るステップと、
    前記Ｗｅｂアプリケーション・サーバからの応答であるＨＴＴＰレスポンス中のエンティティ・ボディから抽出したアプリケーション情報に加え、前記ＨＴＴＰレスポンス中のエンティティ・ヘッダとエンティティ・ボディから抽出したユーザセッション情報を、前記Ｗｅｂサービス・クライアントヘのレスポンスに含めるステップと、
    前記Ｗｅｂサービス・クライアントのリクエストに含まれた前記ユーザセッション情報を、ＨＴＴＰリクエスト中にエンティティ・ヘッダとアプリケーション・データの一部としてエンティティ・ボディに含め、前記Ｗｅｂアプリケーション・サーバに送るステップと、
    を実行させる、コンピュータ・プログラム。
12. 前記Ｗｅｂサービス・クライアントのリクエストが、ＳＯＡＰリクエストであり、このリクエストに対する応答がＳＯＡＰレスポンスである請求項１１に記載のコンピュータ・プログラム。
13. 前記ユーザセッション情報が、ＵＲＩ情報、Ｓｅｔ−Ｃｏｏｋｉｅヘッダ情報、およびｈｉｄｄｅｎタグ情報である、請求項１１に記載のコンピュータ・プログラム。
14. 請求項１１、１２または１３に記載のコンピュータ・プログラムを格納した記録媒体。

Images