(57)【要約】【課題】複数回のクライアントとのメッセージのやりとりによって処理が行われる既存のサーバの提供するサービスを、一回のメッセージのやりとりに集約して形式で該サービスをラッピングして提供する。【解決手段】ＳＯＡＰラッパ装置１０は、ＳＯＡＰクライアント２０から送信されるＳＯＡＰリクエストメッセージ２１に応じて、ＷＷＷアプリケーションサーバ３０の提供するサービスに１回以上のＨＴＴＰ通信により該サービスに処理を行わせ、該サービスの処理の結果から得られるＨＴＴＰレスポンス情報を元に、ＳＯＡＰレスポンスメッセージ２２を作成し、作成した該ＳＯＡＰメッセージ２２を該ＳＯＡＰクライアント２０に送信する。【選択図】図１
2004246747.tif 000002
【特許請求の範囲】
【請求項１】
ラッピングサービスの対象となる既存のサービスに複数回以上の通信により該既存のサービスに処理を実行する手段と、
該サービスの処理結果から得られる情報を元にクライアント向けメッセージを作成する手段と、
作成したメッセージをクライアントに送信する手段を備えたことを特徴とする既存サービスのラッピング装置。
【請求項２】
請求項１において、更に前記既存サービスの処理実行結果から得られる情報に基づき既存サービスに複数回以上の通信によりサービスを行わせるためのシナリオ情報を保持する手段を備え、
前記メッセージ作成手段は、前記シナリオ情報に基づいてメッセージを作成することを特徴とする既存サービスのラッピング装置。
【請求項３】
前記シナリオ情報は、前記クライアントからの要求情報からアクセス先のラッピング対象のサービスを提供するサーバを特定する定義と、前記クライアントからの要求情報から前記ラッピング対象のサービスにアクセスする際に必要となる情報を特定する定義と、該ラッピング対象のサービスの処理結果の情報から該クライアントに返信するメッセージを作成する方法を示す定義とを含むことを特徴とする請求項２の既存サービスのラッピング装置。
【請求項４】
前記シナリオ情報を、前記ラッピング対象のサービスと、該ラッピング対象のサービスをそのまま利用することのできるクライアントとの間の通信ログ情報から作成することを特徴とする請求項３の既存サービスのラッピング装置。
【請求項５】
クライアント装置および既存サービスを行うサーバと接続したラッピング装置における既存サービスのラッピング方法であって、
ラッピングサービスの対象となる既存のサービスに複数回以上の通信により該既存のサービスに処理を実行するステップと、
該サービスの処理結果から得られる情報を元にクライアント向けメッセージを作成するステップと、
作成したメッセージをクライアントに送信するステップとを有することを特徴とする既存サービスのラッピング方法。
【請求項６】
請求項５において、更に前記既存サービスの処理実行結果から得られる情報に基づき既存サービスに複数回以上の通信によりサービスを行わせるためのシナリオ情報を作成するステップを備え、
前記メッセージ作成ステップは、前記シナリオ情報に基づいてメッセージを作成することを特徴とする既存サービスのラッピング方法。
【請求項７】
前記シナリオ情報は、前記クライアントからの要求情報からアクセス先のラッピング対象のサービスを提供するサーバを特定する定義と、前記クライアントからの要求情報から前記ラッピング対象のサービスにアクセスする際に必要となる情報を特定する定義と、該ラッピング対象のサービスの処理結果の情報から該クライアントに返信するメッセージを作成する方法を示す定義とを含むことを特徴とする請求項６の既存サービスのラッピング方法。
【請求項８】
前記シナリオ情報を、前記ラッピング対象のサービスと、該ラッピング対象のサービスをそのまま利用することのできるクライアントとの間の通信ログ情報から作成することを特徴とする請求項７の既存サービスのラッピング方法。
【請求項９】
既存サービスをラッピングするプログラムを格納する情報処理装置により読み取り可能な記憶媒体であって、前記プログラムは
前記クライアントの要求に応じて、ラッピングサービスの対象となる既存のサービスに複数回以上の通信により該既存のサービスに処理を行わせるステップと、
該サービスの処理の結果から得られる情報を元にメッセージを作成するステップと、
該作成したメッセージを該クライアントに送信するステップを有することを特徴とする記憶媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は既存サーバのラッピング方法に関し、特に既存のサーバのサービスの形式が、ネットワークなどを介してクライアントにサービスを提供する際に、クライアントが表示すべき画面情報を送信する形式のものであり、かつ、サービスを利用するには複数の画面遷移が必要になる場合に、これを単一の異種のメッセージのやりとりに集約するラッピング方法と装置に関する。
【０００２】
【従来の技術】
ネットワークと、それにつながれた複数のシステムとで構成される分散システムにおいて、特定システム（サーバ）が提供するサービスを他のシステム（クライアント）からネットワークを介して利用するクライアント・サーバの形式のシステムが、銀行の口座操作システム（ＡＴＭ）や、ＷＷＷ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ）等、多くのネットワークシステム環境で利用されている。
【０００３】
クライアント・サーバの形式でサービスを提供する場合、クライアントシステムとサーバシステムとの間で、サービスの提供をする際の通信の方式や通信電文の形式をあらかじめ定めておく必要がある。この通信方式および通信電文の形式は標準団体等で定められたものがいくつかあり、ＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）やＣＯＲＢＡ（Ｃｏｍｍｏｎ  Ｏｂｊｅｃｔ  Ｒｅｆｅｒｅｎｃｅ  Ｂｒｏｋｅｒ  Ａｒｃｈｉｔｅｃｈｅｒ）をその例としてあげることができる。この通信方式や通信電文の形式がサーバとクライアントで異なっているとサーバはクライアントにサービスを正常に提供することが出来ない。
【０００４】
また、もともと、クライアント・サーバの形式でサービスを提供することを前提に作られていない既存のプログラムは、そのままではクライアント・サーバの形式のサービスで利用することは出来ない。
【０００５】
このような問題に対処すべく、あるひとつの通信方式や通信電文の形式のサービスを、別の通信方式や通信電文方式に対応したクライアントにも利用できるように、既存のサービスに専用のプログラムを追加して通信方式や通信電文の変換を行ったり、通信方式や通信電文の形式をもたない既存のプログラムに専用のプログラムを追加して通信方式や通信電文の形式をあたえ、特定のクライアントから利用できるようにする、ラッピングとよばれる技術があり、その一例として、特開平１１−３５３１８１号（特許文献１）に、既存プログラムのラッピング方法が開示されている。
【０００６】
この方法は、既存のシステム上で作成した既存のプログラム部品をネットワークを介して新規に作成したアプリケーションプログラムから起動させ、ユーザからの要求処理を行うアプリケーションラッピング方法であって、新規に作成したアプリケーションプログラムがユーザからの要求を処理する際に必要となるプログラム部品を既存のプログラム部品から抽出して前記既存のプログラム部品と新規に作成したアプリケーションプログラムをマッピングし、ユーザの処理要求の応じて前記マッピングした各プログラム部品の処理の遷移順序を決定し、前記遷移順序に基づいて各プログラム部品の処理を遷移させ、新規に作成したアプリケーションプログラムと各プログラム部品間でそれぞれリモートプロシジャーコールによってその処理内容を通信し、ユーザの要求処理を新規に作成したアプリケーションプログラムから既存のシステム上で作成したプログラム部品を起動させて行う、ラッピング方法である。
【０００７】
【特許文献１】特開平１１−３５３１８１号公報
【発明が解決しようとする課題】
このようなラッピング技術を用いることで、既存プログラムをクライアント・サーバの形式で利用することができるようになったり、特定の通信方式や通信電文の形式のサーバを異なる通信方式や通信電文の形式で利用できるようにすることができる。
【０００８】
しかしながら、従来のラッピング方法では、ラッピングを実現するための、開発者によるプログラムの作成は非常に複雑である。ラッピングを実現するためのプログラムを開発するには、対象となるプログラムの仕様および、ラッピング後の通信方式および通信電文の形式の仕様について詳細に調査し、その上でコーディングを行わなければならず、大きな開発工数が問題であった。
【０００９】
本発明の目的はラッピングプログラムを開発する工数を減らせるラッピング方法を提供することにある。
【００１０】
本発明の他の目的は、既存のサービスでの処理のサービスを実行することによりラッピングプログラムに必要な情報を収集してラッピングプログラムの開発を支援することである。
【００１１】
より具体的には、既存のＷＷＷアプリケーションサーバがＨＴＴＰとよばれる通信方式および通信電文の形式で提供するサービスを、ＳＯＡＰ（ＳｉｍｐｌｅＯｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）と呼ばれる通信方式および通信電文の形式で利用できるようにする（ＳＯＡＰで利用できるサービスを一般にＷｅｂサービスと呼ぶ）ラッピングプログラムを、その開発者に複雑なプログラムや開発作業を行わせることなく作成できるようにすることである。
【００１２】
【課題を解決するための手段】
上記の課題を解決するために、本発明では、クライアントの要求に応じて、ラッピングサービスの対象となる既存のサービスに１回以上の通信により既存のサービスの処理を行わせ、そのサービスの処理の結果から得られる情報にもとづいて、メッセージを作成してクライアントに送信する。
【００１３】
また、既存のサービスの処理の結果から得られる情報に基づいて、既存サービスに複数の処理を連続して行わせるためのシナリオ情報を作成しておき、シナリオ情報に基づいてラッピング処理を行う。
【００１４】
更に、本発明の既存ＷＷＷアプリケーションをＷｅｂサービス化する方法では、対象となるＷＷＷアプリケーションの、通常のＷＷＷブラウザによる画面遷移による処理の流れを代行するＳＯＡＰラッパ装置を、ＷＷＷアプリケーションサーバと、Ｗｅｂサービスを利用するＳＯＡＰクライアントプログラムの間に配置し、ＳＯＡＰクライアントから送信されるＳＯＡＰリクエストメッセージから該画面遷移に必要な情報を得て、該情報を用いてＷＷＷアプリケーションサーバにアクセスすることで画面遷移を代行し、該画面遷移の結果えられた情報からＳＯＡＰレスポンスメッセージを生成し、該ＳＯＡＰレスポンスメッセージを要求元のＳＯＡＰクライアントに返送する。
【００１５】
このとき、本来は複数の画面遷移の間でその画面遷移の都度必要となる入力情報をひとつのＳＯＡＰリクエストメッセージに集約することで、従来複数の通信が必要であったものを、一回のＳＯＡＰメッセージのやりとりに集約する。
【００１６】
また、該ＳＯＡＰラッパ装置の、画面遷移を代行する処理手順は、既存のＷＷＷブラウザと対象となるＷＷＷアプリケーションサーバとの間の通信ログ情報を用いることで作成する。
【００１７】
この方法によれば、既存のＷＷＷアプリケーションサーバのＷｅｂサービス化を、開発者に複雑なプログラムミングなどの作業を行わせることなく実現することが出来る。また、ＷＷＷアプリケーションサーバが提供しているサービスが複数の画面遷移を必要とするものであってもひとつのメッセージのやりとりに集約することができる。
【００１８】
【発明の実施の形態】
以下、本発明の実施の形態について図面を参照して説明する。図１は本発明による機能構成を表す機能ブロック図である。図１中、３０はＷＷＷページによるアプリケーションのサービスを提供するＷＷＷアプリケーションサーバである。通常、ＷＷＷアプリケーションサーバ３０は、ＷＷＷクライアント（通常はＷＷＷブラウザ）によって送信されるＨＴＴＰリクエストメッセージによってサービスの提供を要求され、その要求に応じて処理を行い、その処理の結果をＷＷＷページを生成し、生成したＷＷＷページの内容を含んだＨＴＴＰレスポンスメッセージをＷＷＷクライアントに返信するサーバプログラムである。
【００１９】
２０は、通常はＳＯＡＰサーバによって提供されるＷｅｂサービスを利用するクライアントプログラムであり、これをＳＯＡＰクライアントと呼ぶ。
【００２０】
Ｗｅｂサービスとは、インターネット上でシステムを連携させるための技術のひとつである。、ＨＴＴＰやＳＭＴＰ等のインターネット上の標準的なアプリケーション層のプロトコロルで接続されているネットワーク環境上に、さらにもうひとつ上の階層上でＳＯＡＰ（Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）と呼ばれるＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）をベースにしたプロトコルを使用し、ＳＯＡＰに従ったＸＭＬ形式のデータ交換によりシステム連携を行うことができる。また、ＳＯＡＰは標準団体Ｗ３Ｃ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ  Ｃｏｎｓｏｔｉｕｍ）によって標準化された規格である。
【００２１】
１０は該ＷＷＷアプリケーションがＨＴＴＰの形式で提供しているサービスを、Ｗｅｂサービスの形式で利用できるように変換し、ＳＯＡＰクライアントから該サービスを利用できるように処理を行う機能をもつＳＯＡＰラッパ装置である。
【００２２】
該ＳＯＡＰラッパ装置１０はインターネット等のネットワーク上において、ＷｅｂサービスのクライアントとなるＳＯＡＰクライアント２０と、ＷＷＷアプリケーションサーバ３０との間に位置し、ＷＷＷアプリケーションサーバ３０の提供するＷＷＷアプリケーションを、Ｗｅｂサービスで提供すべく、ＳＯＡＰクライアント２０から送信されるＳＯＡＰリクエストメッセージに応じて、あらかじめ定めておいたアクセスの方法によって、ＷＷＷアプリケーションにアクセスし、アクセスの結果得られた情報を元に、ＳＯＡＰレスポンスメッセージを作成し、当該ＳＯＡＰレスポンスメッセージを当該ＳＯＡＰクライアントに返送する。
【００２３】
ＳＯＡＰラッパ装置１０は、プロセッサ１０５、記憶装置１０６、表示装置１０７、入力装置１０８、媒体読取装置１０９からなり、該記憶装置１０６には、ＳＯＡＰラッパとして動作するためのＯＳ、および各種アプリケーションプログラムが格納されている。
【００２４】
該ＳＯＡＰラッパ装置１０は、本発明に特有のソフトウェアモジュールとして、ＳＯＡＰクライアント２０からのＳＯＡＰリクエストメッセージを受信し、生成したＳＯＡＰレスポンスメッセージをＳＯＡＰクライアント２０に返信するＳＯＡＰメッセージ通信部１０１、ＷＷＷアプリケーションサーバ３０とＨＴＴＰ通信処理を行うＨＴＴＰ通信部１０４、ＳＯＡＰメッセージ通信部１０１が受信したＳＯＡＰリクエストメッセージに応じてシナリオ表１０３にあらかじめ指定された方法でＨＴＴＰ通信部１０４を制御しＷＷＷアプリケーションサーバ３０にアクセスし、処理を行うことでＳＯＡＰクライアント２０に返信するＳＯＡＰレスポンスメッセージ２２を作成するシナリオ実行部１０２を有する。
【００２５】
ＨＴＴＰ通信部１０４は、ＷＷＷアプリケーションサーバ３０にＨＴＴＰのリクエストメッセージを送信するＨＴＴＰリクエスト処理部１０４１と、ＷＷＷアプリケーションサーバ３０からＨＴＴＰのレスポンスメッセージを受信するＨＴＴＰレスポンス処理部１０４２から構成される。
【００２６】
ＳＯＡＰメッセージ通信部１０１、シナリオ実行部１０２、ＨＴＴＰ通信部はそれぞれモジュール化されたプログラムがプロセッサ１０５に実行されることによりそれぞれの機能を果たす。それぞれのプログラムはＣＤ−ＲＯＭ等の情報処理装置によって読み取り可能な記憶媒体に格納されて取引されることが通常であり、媒体読み取り装置１０９により媒体から読み込まれ、記憶装置１０６に格納されてＳＯＡＰラッパ装置１０にインストールされる。プロセッサ１０５が記憶装置１０６からプログラムを順次読み出して実行することでそれぞれの機能を果たす。シナリオ表１０３は上記のプログラムと同様に記憶装置１０６に格納される。
【００２７】
図２はＷＷＷアプリケーションサーバ３０が提供するサービスによるＷＷＷページの画面遷移の様子の一例を示したものである。
【００２８】
図３はＳＯＡＰクライアント２０から、ＳＯＡＰラッパ装置※に送信されるＳＯＡＰリクエストメッセージの一例を示したものである。ただし説明のために左端に行数を示してある。
【００２９】
図４は、ＳＯＡＰラッパ装置１０によって、該ＳＯＡＰリクエストメッセージによる要求に応じて生成され、ＳＯＡＰクライアント２０に送信されるＳＯＡＰレスポンスメッセージの一例を示したものである。ただし説明のために左端に行数を示してある。
【００３０】
図５は、ＳＯＡＰラッパ装置が有するプログラムモジュールであるシナリオ実行部１０２が参照するシナリオ表１０３の一例を示している。
【００３１】
本実施の形態では、ＳＯＡＰラッパ装置１０が、ＷＷＷアプリケーションサーバが提供する図２で示される画面遷移を行うサービスを、Ｗｅｂサービスとして利用できるように処理を行い、図３および図４で示されるＳＯＡＰメッセージのやりとりによって行われるＷｅｂサービスの形式で、ＳＯＡＰクライアント２０にＷＷＷアプリケーションサーバ３０の提供するサービスを提供する。
【００３２】
以下図６にそって、ＳＯＡＰラッパ装置１０の処理の流れを詳細に説明する。
【００３３】
ＳＯＡＰラッパ装置１０が行う、ＷＷＷアプリケーションサーバ３０の提供するＷＷＷアプリケーションの形式のサービスのＳＯＡＰラッピング処理はシナリオ実行部１０２が全体の制御を行うことで動作する。
【００３４】
ＳＯＡＰメッセージ通信部１０１はＳＯＡＰクライアント２０からのＳＯＡＰリクエストメッセージ２１を受信すると、該ＳＯＡＰリクエストメッセージをシナリオ実行部１０２に受け渡す（ステップ４０１）。シナリオ実行部はシナリオ表１０３を参照し、ＳＯＡＰメッセージ通信部２０から受け渡された該ＳＯＡＰリクエストメッセージの名前と一致するシナリオを実行すべきシナリオとして選択する（ステップ４０２）。ここで、ＳＯＡＰリクエストメッセージ２１の名前は図３の８行目の＜ｓｗ：ｎａｍｅ＞タグで囲まれた部分で表されている。図５に示すシナリオ表１０３の例では、「ｅｎｑｕｅｔｅ＿ｒｅｑｕｅｓｔ」の名前を持つＳＯＡＰリクエストメッセージに対応したシナリオが示されている。該シナリオは４行分のシナリオの情報によって構成されている。シナリオ実行部１０２は選択したシナリオのｒｅｑｕｅｓｔ／ｒｅｓｐｏｎｓｅ項目と設定情報を上から順に行ごとに読み取り、読み取った行の情報を元に以下説明する処理を行う。このとき、該シナリオの行をすべて読み込み終わると、後述するとシナリオの終了処理を行う。
【００３５】
シナリオ実行部＊は、シナリオ表１０３の行の情報を読み込むと、まずはじめにｒｅｑｕｅｓｔ／ｒｅｓｐｏｎｓｅの項目を読み、その項目の値がｒｅｑｕｅｓｔなのかｒｅｓｐｏｎｓｅなのかを判定する（ステップ４０３）。
【００３６】
該ｒｅｑｕｅｓｔ／ｒｅｓｐｏｎｓｅの項目の値がｒｅｑｕｅｓｔの場合（図５に示すシナリオ表１０３の例では最初および三番目の行のｒｅｑｕｅｓｔ／ｒｅｓｐｏｎｓｅの項目の値はｒｅｑｕｅｓｔとなっているため、この場合に該当する）、以下説明するｒｅｑｕｅｓｔ用の処理を行う。
【００３７】
シナリオ実行部１０２は、ｒｅｑｕｅｓｔ／ｒｅｓｐｏｎｓｅの項目の値がｒｅｑｕｅｓｔであった場合、シナリオ表１０３の参照している行の設定情報から、ＨＴＴＰによってアクセスすべきＷｅｂアプリケーションのＵＲＬと、アクセス方式を取得する（図５に示すシナリオ表１０３の例の最初の行では、アクセスすべきＷｅｂアプリケーションのＵＲＬはｈｔｔｐ：／／ｗｗｗ．ｆｏｏ．ｃｏｍ／ａｐｐ１．ｃｇｉ、アクセス方式はＰＯＳＴと読み取ることができる）。シナリオ実行部１０２は、次に、ＳＯＡＰメッセージ通信部１０１から受け渡された該ＳＯＡＰリクエストメッセージ（図３）を読み込み、ＨＴＴＰアクセス時のパラメータやクッキーの情報を取得する。ＨＴＴＰアクセス時のパラメータやクッキーの情報の情報は、図３の９行目から１７行目、および１８行目から２３行目の＜ｓｗ：ｒｅｑｕｅｓｔ＞で囲まれた部分で表されている。シナリオ実行部１０２は、該ｒｅｑｕｅｓｔ用の処理を複数会行う場合は、該ＳＯＡＰリクエストメッセージにひとつ以上含まれる＜ｓｗ：ｒｅｑｕｅｓｔ＞を上から順に読み込み、処理を行う。
【００３８】
ＨＴＴＰアクセス時のパラメータは、図３の１０行目から１３行目の＜ｓｗ：ｐａｒａｍｅｔｏｒ＞タグで囲まれた部分で表されている。シナリオ実行部１０２は該＜ｓｗ：ｐａｒａｍｅｔｏｒ＞タグで囲まれた部分を読み取り、パラメータの情報を取得する。該＜ｓｗ：ｐａｒａｍｅｔｏｒ＞タグで囲まれた部分では、タグ名がパラメータ名、タグで囲まれた部分が該パラメータ名で示されるパラメータの値を示しており、シナリオ実行部１０２はこれをＨＴＴＰアクセス時のパラメータとして取得する。
【００３９】
また、ＨＴＴＰアクセス時のクッキー情報は、図３の１４行目から１６行目の＜ｓｗ：ｃｏｏｋｉｅ＞タグで囲まれた部分で表されている。シナリオ実行部１０２は該＜ｓｗ：ｃｏｏｋｉｅ＞タグで囲まれた部分を読み取り、クッキーの情報を取得する。該＜ｓｗ：ｃｏｏｋｉｅ＞タグで囲まれた部分では、タグ名がクッキー名、タグで囲まれた部分が該クッキー名で示されるクッキーの値を示しており、シナリオ実行部１０２はこれをＨＴＴＰアクセス時のクッキーとして取得する。
【００４０】
上記手段によりシナリオ実行部１０２は、ＨＴＴＰアクセス時に必要なＵＲＬ、アクセス方式、パラメータ、クッキーの情報を得る。シナリオ実行部１０２はこれらのＨＴＴＰアクセス時に必要な情報をＨＴＴＰリクエスト処理部１０４１に受け渡し、ＨＴＴＰリクエスト処理部１０４１は、シナリオ実行部１０２より受け渡された該ＨＴＴＰアクセス時に必要な情報を用いてＷＷＷアプリケーションサーバ３０にＨＴＴＰリクエストメッセージを作成する（ステップ４０４）。
【００４１】
シナリオ実行部１０２はＨＴＴＰリクエスト処理部１０４１にＨＴＴＰリクエストを作成させた後に、実際にリクエスト送信を行うべきかどうかのチェックを行う（ステップ４０５）。
【００４２】
シナリオ実行部１０２は、このようなＷＷＷアプリケーションの特性をもちいて、ＨＴＴＰリクエストメッセージの送信を行うべきかどうかをチェックする。すなわち、ひとつ前のＨＴＴＰリクエストによってＷＷＷアプリケーションサーバ３０から受け取った画面（通常はＨＴＭＬ）内に、次にアクセスを行おうとしているＵＲＬが含まれているかどうかを検出し、含まれていない場合は、ＨＴＴＰリクエストメッセージを送信せず、後述するエラー処理を行う。逆に、該ひとつ前の画面に該ＵＲＬが含まれている場合はＨＴＴＰリクエストメッセージの送信を行い、処理を続ける。ただし、通常、一番最初のＨＴＴＰリクエスト送信時には、ひとつ前の画面は存在し得ないため、上記のようなＨＴＴＰリクエストメッセージを送信すべきかどうかのチェック処理は行わず、すぐにＨＴＴＰリクエストメッセージの送信を行う。
【００４３】
ＨＴＴＰレスポンス処理部１０４２は、ＨＴＴＰリクエスト処理部１０４１がＷＷＷアプリケーションサーバ３０に該ＨＴＴＰリクエストメッセージを送信した後、ＷＷＷアプリケーションサーバ３０の処理結果であるＨＴＴＰレスポンスメッセージを受信し、シナリオ実行部の次の処理に利用するため、該ＨＴＴＰレスポンスメッセージを保持する。
【００４４】
上記シナリオ実行部１０２におけるＨＴＴＰリクエストメッセージの送信を行うべきどうかをチェックする処理において、ＨＴＴＰリクエストメッセージを送信すべきでないと判定された場合、シナリオ実行部１０２は、ＳＯＡＰメッセージ通信部１０１を用いて、ＳＯＡＰクライアント２０に実行エラーが起きたことを通知するＳＯＡＰレスポンスメッセージを送信する（ステップ４０７）。
【００４５】
シナリオ実行部１０２によるｒｅｑｕｅｓｔ用の処理はＨＴＴＰリクエスト処理部１０４１にＨＴＴＰリクエストメッセージを送信させると終了し、次のシナリオ情報の行の処理に移る。
【００４６】
シナリオ実行部１０２は、参照しているシナリオ表１０３の行のｒｅｑｕｅｓｔ／ｒｅｓｐｏｎｓｅの項目の値がｒｅｓｐｏｎｓｅ場合（図５に示すシナリオ表１０３の例では二番目および四番目の行のｒｅｑｕｅｓｔ／ｒｅｓｐｏｎｓｅの項目の値はｒｅｓｐｏｎｓｅとなっているため、この場合に該当する）、以下説明するｒｅｓｐｏｎｓｅ用の処理を行う。
【００４７】
シナリオ実行部１０２は、ｒｅｑｕｅｓｔ／ｒｅｓｐｏｎｓｅの項目の値がｒｅｓｐｏｎｓｅであった場合、シナリオ表１０３の参照している行の設定情報から、直前に行われたＨＴＴＰリクエスト処理によってＨＴＴＰレスポンス処理部１０４２が受け取る、ＷＷＷアプリケーションサーバ３０が行った処理の結果であるＨＴＴＰレスポンスメッセージから、ＳＯＡＰクライアント２０に対して返信するＳＯＡＰレスポンスメッセージ２２を作成する処理を行うための情報を取得する。例えば、図５に示すシナリオ表１０３の例の二番目の行では、ＷＷＷアプリケーションサーバ３０から処理結果として取得したＨＴＴＰレスポンスメッセージに含まれるＨＴＭＬのうち、＜ｈｔｍｌ＞タグのあとに現れる＜ｈ１＞タグに囲まれる文字列を、図４に示すＳＯＡＰクライアントに対して返信するＳＯＡＰレスポンスメッセージ２２の７行目に示す、＜ｆｏｏ１＞タグに含まれる＜ｂａｒ１＞タグが囲む文字列として設定する、ということを示している。シナリオ実行部１０２は上記のようなＳＯＡＰレスポンスメッセージの作成処理情報に基づき、ＨＴＴＰレスポンスメッセージからＳＯＡＰレスポンスメッセージ２２を作成する（ステップ４０８）。シナリオ実行部１０２は、シナリオ実行中に上記のｒｅｓｐｏｎｓｅ用の処理が複数回行われる場合でも、ひとつのシナリオを実行している間はひとつのＳＯＡＰレスポンスメッセージ２２に対して作成処理を行い、複数個のＨＴＴＰレスポンスメッセージから、複数の情報を取得して、該取得した複数の情報をひとつのＳＯＡＰレスポンスメッセージ２２に取り入れて、最終的にＳＯＡＰクライアント２０に対して返信するＳＯＡＰレスポンスメッセージ２２を作成する。
【００４８】
シナリオ実行部１０２は、その実行処理を始めるにあたってＳＯＡＰメッセージ通信部１０１が受信したＳＯＡＰリクエストメッセージ２１に対応させて選択した、実行対象のシナリオ表１０３中のシナリオの行をすべて読み終わると、シナリオを終了したとし、シナリオ実行中に作成したＳＯＡＰレスポンスメッセージ２２を、ＳＯＡＰメッセージ通信部１０１に受け渡し、ＳＯＡＰメッセージ通信部１０１はシナリオ実行部１０２から受け渡された該ＳＯＡＰレスポンスメッセージ２２を、要求元のＳＯＡＰクライアント２０に返送する（ステップ４０９）。
【００４９】
ＳＯＡＰクライアント２０は、ＳＯＡＰラッパ装置１０に対して送信したＳＯＡＰリクエストメッセージ２１に対するＳＯＡＰラッパ装置１０の処理結果として、ＳＯＡＰレスポンスメッセージ２２を受信する。
【００５０】
本実施の形態によれば、ＳＯＡＰラッパ装置１０および、対象となるＷＷＷアプリケーションサーバ３０の提供するサービスに対応したシナリオ表１０３を用いることで、既存のＷＷＷアプリケーションサーバ３０に直接手を加えることなく、ＷＷＷアプリケーションの形式で提供していたサービスを、ＳＯＡＰの形式でラッピングし、Ｗｅｂサービスとして提供することができる。また、ＷＷＷアプリケーションサーバ３０が、ＷＷＷアプリケーションの形式で提供していたサービスでは、ＷＷＷクライアント（ＷＷＷブラウザ）と複数回のやりとりによって最終的に結果が得られるような処理を、ＳＯＡＰラッパ装置１０がＷＷＷアプリケーションサーバとの複数回のやりとりをＷＷＷクライアントに代わって行うことにより、要求元となるＳＯＡＰクライアント側からは１回だけのＳＯＡＰメッセージのやりとりによって、所望の処理を行うことができる。
【００５１】
また、本実施の形態ではＷＷＷアプリケーションサーバ３０の提供するサービスに対応したシナリオ１０３を用意することにより、シナリオ実行部１０２がシナリオ表１０３に応じて動作しＳＯＡＰラッピング処理を行っているが、以下、シナリオ表１０３を作成するための装置および方法を説明する。
【００５２】
図７は、シナリオ表１０３を作成するための開発環境の機能構成を表す機能ブロック図である。
【００５３】
図７中、６０は通常時はＷＷＷアプリケーションサーバ３０にアクセスしてＷＷＷアプリケーションを利用するためのＷＷＷクライアントとなるＷＷＷブラウザである。
【００５４】
図７中、５０は、ＷＷＷブラウザとＷＷＷアプリケーションサーバ３０との間の通信のやりとりの情報ログを取得し、取得した該情報ログを元にシナリオ表１０３を作成する、シナリオ作成装置である。
【００５５】
該シナリオ作成装置５０は、プロセッサ５０４、記憶装置５０５、表示装置５０６、入力装置５０７、媒体読取装置５０８からなり、該記憶装置５０５には、シナリオ作成装置として動作するためのＯＳ、および各種アプリケーションプログラムが格納されている。
【００５６】
該シナリオ作成装置５０は、本発明に特有のソフトウェアモジュールとして、ＷＷＷブラウザ６０とＷＷＷアプリケーションサーバ３０の間の通信の間に入り、通信のやりとりの情報を取得する入出力ログ取得用プロキシ５０１と、入出力ログ取得用プロキシ５０１が取得する入出力ログ情報５０２を参照してシナリオを作成するシナリオ作成部５０３を有する。
【００５７】
入出力ログ取得用プロキシ５０１とシナリオ作成部５０３はそれぞれモジュール化されたプログラムがプロセッサ５０４に実行されることによりそれぞれの機能を果たす。それぞれのプログラムはＣＤ−ＲＯＭ等の情報処理装置によって読み取り可能な記憶媒体に格納されて取引されることが通常であり、媒体読み取り装置５０８により媒体から読み込まれ、記憶装置５０５に格納されてシナリオ作成装置５０にインストールされる。プロセッサ５０４が記憶装置５０５からプログラムを順次読み出して実行することでそれぞれの機能を果たす。入出力ログ情報５０２は上記のプログラムと同様に記憶装置５０５に格納される。
【００５８】
図８は入出力ログ取得用プロキシ５０１が取得するＷＷＷブラウザ６０とＷＷＷアプリケーションサーバ３０との間の通信のやりとりの情報である入出力ログ情報の一例を示したものであり、図２に示したＷＷＷアプリケーションサーバ３０が提供するサービスをＷＷＷブラウザ６０から利用した際の入出力ログ情報が示されている。
【００５９】
以下シナリオ作成装置５０の、シナリオ作成処理の流れを詳細に説明する。
【００６０】
シナリオを作成する開発者が、シナリオ作成装置５０を用いて、シナリオを作成するとき、はじめに、入出力ログ取得用プロキシ５０１をＷＷＷブラウザ６０のＨＴＴＰアクセス時のＨＴＴＰプロキシサーバとして設定する。
【００６１】
ここで、ＨＴＴＰプロキシとは、一般的には企業内ユーザのインターネットアクセスのためのアクセスコントロールや、アクセスデータのキャッシュなどの目的で使われ、限られたユーザのみにインターネットアクセスを許したり、ユーザのアクセスログ情報を蓄積するために利用される、仲介サーバである。本発明ではこのＨＴＴＰプロキシの機能を、シナリオを作成する際に参照する、ＷＷＷブラウザ６０とＷＷＷアプリケーションサーバ３０との間の通信ログを取得するために利用する。
【００６２】
次に、シナリオを作成する開発者は、ＷＷＷブラウザ６０を用いて、通常の操作と同じ操作により、ＷＷＷアプリケーションサーバ３０にアクセスし、シナリオ作成の対象となるアプリケーションを利用する。このとき、ＷＷＷブラウザ６０のＨＴＴＰプロキシとして動作する入出力ログ取得用プロキシ５０１は、そのアプリケーションの利用の間に生じたＷＷＷブラウザ６０とＷＷＷアプリケーションサーバ３０との間の通信の情報を入出力ログ情報５０２に記録する（図８）。
【００６３】
図８に示した入出力ログ情報は、上から順に、一回目のＷＷＷブラウザ６０からＷＷＷアプリケーションサーバ３０に対するＨＴＴＰリクエスト、一回目のＷＷＷアプリケーションサーバ３０からＷＷＷブラウザ６０に対するＨＴＴＰレスポンス、二回目のＷＷＷブラウザ６０からＷＷＷアプリケーションサーバ３０に対するＨＴＴＰリクエスト、二回目のＷＷＷアプリケーションサーバ３０からＷＷＷブラウザ６０に対するＨＴＴＰレスポンス、の情報を示している。
【００６４】
例えば、一回目のＨＴＴＰリクエストでは、アクセス先のｕｒｌが「ｈｔｔｐ：／／ｗｗｗ．ｆｏｏ．ｃｏｍ／ａｐｐ１．ｃｇｉ」であり、アクセス方式が「ＰＯＳＴ」であり、その際のパラメータｘの値は「１９８００」であり、パラメータｙの値は「ｋｏｊｉｍａ」であり、クッキーａの値が「ａａａ」であったことが示されている。また、一回目のＨＴＴＰレスポンスでは、アクセス先のｕｒｌが「ｈｔｔｐ：／／ｗｗｗ．ｆｏｏ．ｃｏｍ／ａｐｐ１．ｃｇｉ」であり、アクセス方式が「ＰＯＳＴ」であり、クッキーａの値が「ｘｘｘ」であり、クッキーｂの値が「ｙｙｙ」であったことが示されており、かつＷＷＷブラウザ６０が表示すべきＨＴＭＬの内容が示されている。
【００６５】
シナリオ作成部５０３は、該入出力ログ情報５０２を順に読み取り、そのｒｅｑｕｅｓｔ／ｒｅｓｐｏｎｓｅに対応するようにシナリオ表１０３を作成する。シナリオ作成部５０３は、シナリオ表１０３におけるｒｅｑｕｅｓｔ側の設定情報は、アクセス先のｕｒｌおよびアクセス方式のみで構成されるため、入出力ログ情報５０２におけるｒｅｑｕｅｓｔの情報をそのまま参照して作成する。
【００６６】
シナリオ表１０３におけるｒｅｓｐｏｎｓｅ側の設定情報はＷＷＷアプリケーションサーバ３０から送られるＨＴＴＰレスポンスに含まれるＨＴＭＬから、ＳＯＡＰレスポンスメッセージを構成するための情報が必要となる。これはシナリオ表を作成する開発者が、入出力ログ情報５０２におけるｒｅｓｕｐｏｎｓｅの情報を参照して、ＳＯＡＰレスポンスメッセージを構成する情報として必要な部分を参照するように設定情報をシナリオ作成部５０３に入力し設定する。設定情報の作成方法はシナリオ実行部１０２の実行処理に記述したとおりである。
【００６７】
上記のような手順により、シナリオ作成部５０３は、入出力ログ情報５０２からシナリオ表１０３を作成することができる。
【００６８】
本実施の形態によれば、シナリオ作成装置５０を用いて、ＷＷＷブラウザ６０とＷＷＷアプリケーションサーバ３０との間の通信から取得した入出力ログ情報５０２を用いて、開発者に複雑なプログラミングなどを強いることなくシナリオ表１０３を作成することができ、該作成したシナリオ表１０３を設定したＳＯＡＰラッパ装置１０を用いることで、ＷＷＷアプリケーションサーバ３０がＷＷＷアプリケーションの形式で提供している既存のサービスを、該サービスに手を加えることなくＳＯＡＰラッピングすることでＷｅｂサービスの形式で提供することができる。
【００６９】
第１の実施の形態では、ＳＯＡＰラッパ装置１０はインターネット等のネットワーク上において、ＷｅｂサービスのクライアントとなるＳＯＡＰクライアント２０と、ＷＷＷアプリケーションサーバ３０との間に位置していたが、これを実装する際は、ＳＯＡＰクライアント２０と同じコンピュータ上のプログラムあるいは、ＷＷＷアプリケーションサーバ３０と同じコンピュータ上のプログラムとして配置することも可能である。
【００７０】
また、第１の実施の形態における、シナリオ作成装置５０では、そのシナリオ表１０３の作成処理において、ｒｅｓｐｏｎｓｅ側の設定処理は、シナリオ表１０３の開発者が、シナリオ作成部５０３に設定情報を入力することにより設定処理を行っていたが、これをより単純化し、開発者が設定処理を行わず、シナリオ作成部５０３が自律的にシナリオ表１０３を作成する第２の実施の形態を以下説明する。
【００７１】
第２の実施の形態は、第１の実施の形態と比べシナリオ作成部５０３の処理方法のみが異なる。第２の実施の形態におけるシナリオ作成部５０３は、そのシナリオ表１０３の作成処理において、入出力ログ情報５０２のｒｅｓｐｏｎｓｅの情報に含まれるＨＴＭＬの内容全体を、ＳＯＡＰクライアント２０に返送するＳＯＡＰレスポンスメッセージ２２に含ませるように処理を行う。このような処理方式にすることで、シナリオ表１０３の開発者はシナリオ作成装置５０を用いてシナリオ表１０３を作成する際に、ＷＷＷブラウザ６０を用いて、ＳＯＡＰラッパ装置を適用させる対象となるＷＷＷアプリケーションサーバ３０のサービスを利用して、シナリオ作成装置５０に入出力ログ情報５０２を記録させる処理を行うだけで、シナリオ作成部５０３に対し追加の入力情報を必要とすることなくシナリオ表１０３を作成することができる。
【００７２】
ただし、この第２の実施の形態におけるシナリオ作成装置５０の処理方式の場合、ＳＯＡＰラッパ装置１０がＳＯＡＰクライアント２０に返送するＳＯＡＰレスポンスメッセージ２２にＷＷＷアプリケーションサーバ３０の処理結果のＨＴＭＬがすべて含まれることになるため、第１の実施の形態にくらべ、ＳＯＡＰクライアント２０がＳＯＡＰレスポンスメッセージ２２を受信したあとの処理負荷が高くなるものと考えられる。したがって、該ＳＯＡＰクライアント２０におけるＳＯＡＰレスポンスメッセージ２２を受信したあとの負荷を低減させる必要がある場合は、第１の実施の形態による処理方式を選択するべきである。
【００７３】
【発明の効果】
本発明によれば、シナリオ作成装置を用いて、既存サービスでのサービス実行処理の結果取得した入出力ログ情報等の処理情報を用いることで、開発者に複雑なプログラミングを強いることなくラッピングに必要なシナリオ表を作成することができ、作成したシナリオ表を用いてラッピング処理を行うことで既存のサービスに手を加えることなく新しいプロトコルに応じたサービスが実現できる。
【図面の簡単な説明】
【図１】本発明の一実施形態の機能構成を示す機能ブロック図。
【図２】ＷＷＷアプリケーションサーバ３０が提供するサービスによるＷＷＷページの画面遷移の一例を示す図。
【図３】ＳＯＡＰリクエストメッセージの一例を示す図。
【図４】ＳＯＡＰレスポンスメッセージの一例を示す図。
【図５】シナリオ表の一例を示す図。
【図６】ＳＯＡＰラッパ装置の処理フローを表すフローチャート。
【図７】ＳＯＡＰラッパ用シナリオ表開発環境の機能構成を示す機能ブロック図。
【図８】入出力ログ情報の一例を示す図。
【符号の説明】
１０：ＳＯＡＰラッパ装置、１０１：ＳＯＡＰメッセージ通信部、１０２：シナリオ実行部、１０３：シナリオ表、１０４：ＨＴＴＰ通信部、１０４１：ＨＴＴＰリクエスト処理部、１０４２：ＨＴＴＰレスポンス処理部、１０５：プロセッサ、１０６：記憶装置、１０７：表示装置、１０８：入力装置、１０９：媒体読取装置、２０：ＳＯＡＰクライアント、２１：ＳＯＡＰリクエストメッセージ、２２：ＳＯＡＰレスポンスメッセージ、３０：ＷＷＷアプリケーションサーバ、５０：シナリオ作成装置、５０１：入出力ログ取得用プロキシ、５０２：入出力ログ情報、５０３：シナリオ作成部、６０：ＷＷＷブラウザ。
【図１】
2004246747.tif 000003
【図２】
2004246747.tif 000004
【図３】
2004246747.tif 000005
【図４】
2004246747.tif 000006
【図５】
2004246747.tif 000007
【図６】
2004246747.tif 000008
【図７】
2004246747.tif 000009
【図８】
2004246747.tif 000010