(57)【要約】【課題】従来のラッピングシステムに対し、クライアントのリクエストに対し毎回シナリオ最初からの処理実行が不要であり、また過去に保存した操作履歴の状態を復元し、そこから再開するシナリオを実行する場合も、クライアント側はサーバに保存された操作履歴の認識不要なラッピング装置を提供する。【解決手段】セッション履歴記憶部２１０部は定義実行部２３０と既存システム３００とのセッション履歴を持つ。制約定義記憶部２６０は制約定義をもつ。クライアント１００の処理要求で実行定義記憶部２７０の持つ実行定義が決まり、実行定義から制約定義が決まる。制約定義にはセッション履歴が利用可能かを示す制約条件が定義されている。定義実行部２３０はクライアント１００から処理要求を受けると対応する制約定義を参照し、利用可能なセッション履歴があればそのセッション履歴を利用する。これにより既存システム３００とのセッションが不要となる。【選択図】図３
2009193512.tif 000002
【特許請求の範囲】
【請求項１】
他の装置と第１プロトコルで通信を行なう所定のシステム装置を対象とするセッション要求であって、前記第１プロトコルとは異なる第２プロトコルによるセッション要求を受信するセッション要求受信部と、
前記セッション要求受信部が受信する前記セッション要求に対応し、かつ、前記所定のシステム装置に対するセッションが定義された実行定義を記憶する実行定義記憶部と、
情報を記憶する情報記憶部と、
前記セッション要求受信部が前記セッション要求を受信すると、受信された前記セッション要求に対応する前記実行定義に基づいて前記第１プロトコルにより前記所定のシステム装置との間でセッションを実行するとともに、実行したセッションにおける前記所定のシステム装置との接続状態を、前記所定のシステム装置と接続することなく復元可能な履歴情報として前記情報記憶部に保存する実行保存部と
を備えたことを特徴とするセッション実行装置。
【請求項２】
前記セッション実行装置は、さらに、
前記実行定義に対応し、かつ、前記履歴情報が前記実行定義に定義されたセッションに利用可能かどうかが定義された制約定義を記憶する制約定義記憶部を備え、
前記実行保存部は、
前記セッション要求受信部が前記セッション要求を受信すると対応する前記実行定義を参照することにより前記実行定義に定義されたセッションに対応する前記履歴情報が前記情報記憶部に保存されているかどうかを判定し、保存されていると判定すると対応する前記制約定義を参照することにより前記履歴情報が前記実行定義に定義されたセッションに利用可能かどうかを判定し、利用可能と判定すると前記履歴情報の示す前記接続状態を復元し、復元した接続状態から前記実行定義に定義されたセッションを開始することを特徴とする請求項１記載のセッション実行装置。
【請求項３】
前記セッション要求受信部は、
複数の前記セッション要求を受信し、
前記実行定義記憶部は、
複数の前記セッション要求のそれぞれに対応する複数の前記実行定義を記憶していることを特徴とする請求項１または２のいずれかに記載のセッション実行装置。
【請求項４】
コンピュータを
第１プロトコルで通信を行なう所定のシステム装置を対象とするセッション要求であって、前記第１プロトコルとは異なる第２プロトコルによるセッション要求を受信するセッション要求受信部、
前記セッション要求受信部が受信する前記セッション要求に対応し、かつ、前記所定のシステム装置に対するセッションが定義された実行定義を記憶する実行定義記憶部、
情報を記憶する情報記憶部、
前記セッション要求受信部が前記セッション要求を受信すると、受信された前記セッション要求に対応する前記実行定義に基づいて前記第１プロトコルにより前記所定のシステム装置との間でセッションを実行するとともに、実行したセッションにおける前記所定のシステム装置との接続状態を、履歴情報として前記情報記憶部に記憶する実行保存部
として機能させることを特徴とするセッション実行プログラム。
【請求項５】
請求項４のセッション実行プログラムを記録したコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、既存システムとの連携をプロトコル変換により、別なサービスインタフェースとして提供するラッピング装置に関し、特にクライアントが表示する画面情報を既存システムが送信し、サービスを利用するのに複数画面の遷移が必要となるシステムのラッピング装置（セッション実行装置）に関する。
【背景技術】
【０００２】
従来の既存システムとの連携を行うラッピングシステムでは、既存システムとの一連の処理をシナリオとして定義し、これを実行することで、クライアントからの１回のリクエストに対して既存システムの提供する複数画面に渡る一連の処理を実現している。また、既存システムとの連携処理を最初から再実行するのではなく、過去に保存した状態を復元し、再開することで、処理を効率化するといった仕組みがある（例えば、特許文献１）。
【特許文献１】特開２０００−０２０３４９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
従来のスクリーンラッピングシステムにおいて、クライアントからのリクエストに対して毎回、シナリオの最初から処理を実行するために、効率的に処理を行うことができなかった。または、過去に保存した操作履歴の状態を復元し、そこから再開するシナリオを選択実行することで処理を効率化することができるが、要求を出すクライアント側で、サーバ上に保存された操作履歴を認識している必要のあることや、復元した状態が例えばセッションタイムアウトなどで利用不可となっていた場合に、エラー通知をクライアント側に通知し、クライアント側で別の地点から再開するシナリオを選択して実行する必要があるという課題があった。
【０００４】
本発明は、上記の課題を解決するためのものであり、クライアントが、過去に保存した操作履歴であるヒストリを管理するヒストリ管理部にどの状態が保存されているのか、また、それが利用可なのかを判断する必要がなく、最適な再開ポイントを自動選択可能とすることでラッピング処理を効率的に実施する装置の提供を目的とする。また、異なるシナリオ（実行定義）においても、途中までの処理が同じであれば、別シナリオでのヒストリを利用し、ラッピング処理を効率的に実施することを目的とする。
【課題を解決するための手段】
【０００５】
この発明のセッション実行装置は、
他の装置と第１プロトコルで通信を行なう所定のシステム装置を対象とするセッション要求であって、前記第１プロトコルとは異なる第２プロトコルによるセッション要求を受信するセッション要求受信部と、
前記セッション要求受信部が受信する前記セッション要求に対応し、かつ、前記所定のシステム装置に対するセッションが定義された実行定義を記憶する実行定義記憶部と、
情報を記憶する情報記憶部と、
前記セッション要求受信部が前記セッション要求を受信すると、受信された前記セッション要求に対応する前記実行定義に基づいて前記第１プロトコルにより前記所定のシステム装置との間でセッションを実行するとともに、実行したセッションにおける前記所定のシステム装置との接続状態を、前記所定のシステム装置と接続することなく復元可能な履歴情報として前記情報記憶部に保存する実行保存部と
を備えたことを特徴とする。
【発明の効果】
【０００６】
この発明により、クライアント装置から処理要求に対して、処理の高速化、効率化を図るセッション実行装置を提供することができる。
【発明を実施するための最良の形態】
【０００７】
実施の形態１．
図１は、コンピュータで実現されるスクリーンラッピング装置２００の外観の一例を示す図である。図１は、サーバ（コンピュータ）であるスクリーンラッピング装置２００と、後述のクライアント１００の機能を有するクライアント端末装置と、既存システム３００とが、ネットワーク（インターネット）に接続している状態を示している。図１において、コンピュータで実現されるスクリーンラッピング装置２００は、システムユニット８３０、ＣＲＴ（Ｃａｔｈｏｄｅ・Ｒａｙ・Ｔｕｂｅ）やＬＣＤ（液晶）の表示画面を有する表示装置８１３、キーボード８１４（Ｋｅｙ・Ｂｏａｒｄ：Ｋ／Ｂ）、マウス８１５、ＦＤＤ８１７（Ｆｌｅｘｉｂｌｅ・Ｄｉｓｋ・  Ｄｒｉｖｅ）、コンパクトディスク装置８１８（ＣＤＤ：Ｃｏｍｐａｃｔ  Ｄｉｓｋ  Ｄｒｉｖｅ）、プリンタ装置８１９などのハードウェア資源を備え、これらはケーブルや信号線で接続されている。
【０００８】
図２は、コンピュータで実現されるスクリーンラッピング装置２００のハードウェア資源の一例を示す図である。図２において、スクリーンラッピング装置２００は、プログラムを実行するＣＰＵ８１０（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ：中央処理装置、処理装置、演算装置、マイクロプロセッサ、マイクロコンピュータ、プロセッサともいう）を備えている。ＣＰＵ８１０は、バス８２５を介してＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）８１１、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）８１２、表示装置８１３、キーボード８１４、マウス８１５、通信ボード８１６、ＦＤＤ８１７、ＣＤＤ８１８、プリンタ装置８１９、磁気ディスク装置８２０と接続され、これらのハードウェアデバイスを制御する。磁気ディスク装置８２０の代わりに、光ディスク装置、フラッシュメモリなどの記憶装置でもよい。
【０００９】
ＲＡＭ８１２は、揮発性メモリの一例である。ＲＯＭ８１１、ＦＤＤ８１７、ＣＤＤ８１８、磁気ディスク装置８２０等の記憶媒体は、不揮発性メモリの一例である。これらは、記憶装置あるいは記憶部、格納部、バッファの一例である。通信ボード８１６、キーボード８１４、ＦＤＤ８１７などは、入力部、入力装置の一例である。また、通信ボード８１６、表示装置８１３、プリンタ装置８１９などは、出力部、出力装置の一例である。
【００１０】
通信ボード８１６は、ネットワーク（ＬＡＮ等）に接続されている。通信ボード８１６は、ＬＡＮに限らず、インターネット、ＩＳＤＮ等のＷＡＮ（ワイドエリアネットワーク）などに接続されていても構わない。
【００１１】
磁気ディスク装置８２０には、オペレーティングシステム８２１（ＯＳ）、ウィンドウシステム８２２、プログラム群８２３、ファイル群８２４が記憶されている。プログラム群８２３のプログラムは、ＣＰＵ８１０、オペレーティングシステム８２１、ウィンドウシステム８２２により実行される。
【００１２】
上記プログラム群８２３には、以下に述べる実施の形態の説明において「〜部」として説明する機能を実行するプログラムが記憶されている。プログラムは、ＣＰＵ８１０により読み出され実行される。
【００１３】
ファイル群８２４には、以下に述べる実施の形態の説明において、「実行定義」（実行定義は、シナリオともいう。）、「制約定義」、「セッション履歴」などとして説明する情報や、「〜の判定結果」、「〜の算出結果」、「〜の抽出結果」、「〜の生成結果」、「〜の処理結果」として説明する情報や、データや信号値や変数値やパラメータなどが、「〜ファイル」や「〜データベース」の各項目として記憶されている。「〜ファイル」や「〜データベース」は、ディスクやメモリなどの記録媒体に記憶される。ディスクやメモリなどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してＣＰＵ８１０によりメインメモリやキャッシュメモリに読み出され、抽出・検索・参照・比較・演算・計算・処理・出力・印刷・表示などのＣＰＵの動作に用いられる。抽出・検索・参照・比較・演算・計算・処理・出力・印刷・表示のＣＰＵの動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリやキャッシュメモリやバッファメモリに一時的に記憶される。
【００１４】
また、以下に述べる実施の形態の説明においては、データや信号値は、ＲＡＭ８１２のメモリ、ＦＤＤ８１７のフレキシブルディスク、ＣＤＤ８１８のコンパクトディスク、磁気ディスク装置８２０の磁気ディスク、その他光ディスク、ミニディスク、ＤＶＤ（Ｄｉｇｉｔａｌ・Ｖｅｒｓａｔｉｌｅ・Ｄｉｓｋ）等の記録媒体に記録される。また、データや信号は、バス８２５や信号線やケーブルその他の伝送媒体によりオンライン伝送される。
【００１５】
また、以下に述べる実施の形態の説明において、「〜部」として説明するものは、「手段」、「〜回路」、「〜機器」であってもよく、また、「〜ステップ」、「〜手順」、「〜処理」であってもよい。すなわち、「〜部」として説明するものは、ＲＯＭ８１１に記憶されたファームウェアで実現されていても構わない。或いは、ソフトウェアのみ、或いは、素子・デバイス・基板・配線などのハードウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせ、さらには、ファームウェアとの組み合わせで実施されても構わない。ファームウェアとソフトウェアは、プログラムとして、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ミニディスク、ＤＶＤ等の記録媒体に記憶される。プログラムはＣＰＵ８１０により読み出され、ＣＰＵ８１０により実行される。すなわち、プログラムは、以下に述べる「〜部」としてコンピュータを機能させるものである。あるいは、以下に述べる「〜部」の手順や方法をコンピュータに実行させるものである。
【００１６】
図３は、実施の形態１におけるスクリーンラッピングシステム１０００を示す図である。
【００１７】
（システム構成）
スクリーンラッピングシステム１０００は、クライアント１００（クライアント端末装置、あるいはクライアント端末装置に組み込まれたクライアント機能を有するクライアントプログラム）、スクリーンラッピング装置２００（セッション実行装置）、既存システム３００（システム装置）から構成される。
【００１８】
クライアント１００は、スクリーンラッピング装置２００と、例えば、ＳＯＡＰ（Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）（第２のプロトコル）で通信する。また、既存システム３００は、例えば、スクリーンラッピング装置２００とＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）（第１のプロトコル）でセッションする。
【００１９】
（接続関係）
クライアント１００とスクリーンラッピング装置２００とは、ネットワーク４０１により接続されてもよいし、あるいは、クライアント１００とスクリーンラッピング装置２００とは同一マシン上において構成されてもよい。また、スクリーンラッピング装置２００と既存システム３００との間も同様に、ネットワーク４０２により接続されてもよいし、同一マシン上において構成されてもよい。すなわち、スクリーンラッピング装置２００は、クライアント１００と既存システム３００とを接続する装置であるので、スクリーンラッピング装置２００はクライアント側に組み込まれてもよいし、既存システム３００側に組み込まれても構わない。
【００２０】
クライアント１００は、スクリーンラッピング装置２００に対して、例えばＳＯＡＰ通信による要求で、特定のシナリオの実行要求を行う。
【００２１】
（スクリーンラッピング装置２００）
スクリーンラッピング装置２００は、受信したＳＯＡＰメッセージに対応するシナリオ（実行定義）を判別し、シナリオ、後述のセッション履歴、後述の制約定義からシナリオの再開ポイントを判別し、セッション履歴に格納されたセッション状態を復元し、対応するシナリオの再開ポイントから処理を再開し、例えばブラウザＩＦ（Ｉｎｔｅｒ  Ｆａｃｅ）を提供する既存システム３００に対してＨＴＴＰ通信による処理要求を行う。
【００２２】
（既存システム３００）
既存システム３００は、受信したＨＴＴＰリクエストに対して応答を返す。スクリーンラッピング装置２００は、シナリオに定義された一連の処理が完了した時点で、ＳＯＡＰ通信の応答をクライアントに返す。
【００２３】
（スクリーンラッピング装置２００の構成）
スクリーンラッピング装置２００は、セッション履歴を記憶するセッション履歴記憶部２１０、ヒストリ管理部２２０、定義実行部２３０、メッセージ処理部２４０、通信部２５０、制約定義を格納する制約定義記憶部２６０、実行定義を格納する実行定義記憶部２７０とから構成される。また、ヒストリ管理部２２０と定義実行部２３０とは実行保存部２８０を構成する。
【００２４】
（各構成要素の機能）
（１．メッセージ処理部２４０）
メッセージ処理部２４０は、ＷｅｂサービスのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）を開示し、クライアントからのＳＯＡＰリクエスト（セッション要求）を受信する。ＳＯＡＰリクエストメッセージには、シナリオを実行するためのパラメータ（ログインＩＤ，パスワード，検索キーワードなど）が含まれる。メッセージ処理部２４０は、提供するサービスのＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）やリクエストメッセージに含まれるパラメータ情報から対応するシナリオを特定し、定義実行部２３０にシナリオ実行要求を送信する。
（２．定義実行部２３０）
定義実行部２３０は、メッセージ処理部２４０からシナリオ実行要求を受信し、実行定義記憶部２７０から対応する実行要求に対応するシナリオを検索し、制約定義記憶部２６０から検索対象のシナリオに対応する制約定義を検索し、そして、ヒストリ管理部２２０を用いてセッション履歴記憶部２１０から制約定義を満たすセッション履歴を検索し、保存されたセッション状況（セッション履歴）を復元し、シナリオを当該セッションの状況から再開する。
（３．通信部２５０）
既存システム３００へのリクエストは、定義実行部２３０が通信部２５０を経由して実施する。通信部２５０は、既存システム３００から受信する画面情報（ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）など）の解析機能や、画面へのデータ設定機能、およびボタン押下時の送信データの生成機能などを有する。この通信部２５０は、「ブラウザエンジン」（ブラウザ機能を持ちＡＰＩでの操作機能を提供）相当の機能を有している。
【００２５】
定義実行部２３０は、シナリオを実行し、セッション状況が更新されたときには、ヒストリ管理部２２０に対して、最新のセッション状況を保存するようにリクエストを行う。例えばＪａｖａ（登録商標）によってスクリーンラッピング装置２００（プログラムの場合）を実装している場合には、セッション状況（接続状態）の保存、復元は、セッションを管理するオブジェクトのシリアライズ、デシリアライズにより実現することができる。
【００２６】
定義実行部２３０は、シナリオを最後まで実行すると、既存システム３００から取得した画面情報から必要なデータを抽出してＳＯＡＰレスポンスメッセージを作成し、メッセージ処理部２４０を経由してクライアント１００に応答を返す。
【００２７】
結果画面からＳＯＡＰの戻り値を抽出するルールは、シナリオの一部として定義してもいいし、ＳＯＡＰリクエストメッセージに含めて要求を行ってもいい。
【００２８】
（スクリーンラッピング装置２００の処理フローの概要）
図４は、スクリーンラッピング装置２００の動作を示すフローチャートである。図４を参照してスクリーンラッピング装置２００の動作を説明する。図４ではスクリーンラッピング装置２００の一般的な動作を説明し、具体的な場合は図６〜図９で説明する。
【００２９】
（シナリオの特定）
クライアント１００が送信したＳＯＡＰリクエストメッセージを、メッセージ処理部２４０が受信する（Ｓ２０１）。メッセージ処理部２４０は、受信したＳＯＡＰリクエストから対応するシナリオを特定する（Ｓ２０２）。シナリオの特定には、予め公開しているＷｅｂサービスごとに対応するシナリオを設定することで行う。または、ＳＯＡＰリクエストメッセージ内のパラメータとして、シナリオの識別子を格納することで行う。
【００３０】
（定義実行部２３０の動作）
定義実行部２３０は、メッセージ処理部２４０からシナリオ実行要求を受信し、実行定義記憶部２７０からシナリオを取得する（Ｓ２０３）。また、定義実行部２３０は、シナリオに対応する制約定義を制約定義記憶部２６０から取得する（Ｓ２０４）。定義実行部２３０は、シナリオの内容を解釈し、戻り値を抽出する最終画面を実行定義の終了時点から逆順に辿り取得する（Ｓ２０５）。定義実行部２３０は、ヒストリ管理部２２０に、取得した画面（接続した際のセッション状態）の履歴情報があるかを問い合わせる（Ｓ２０６）。画面を特定する方法としては、ＵＲＬや画面タイトルなどを識別子として用い、実際に通信を行うＪａｖａ（登録商標）オブジェクトの情報とセットで保存する。セッション履歴にヒストリとして履歴が残っている場合、定義実行部２３０は、その画面（セッション状態）が再開ポイントとして利用可能かを制約定義と比較し判定する（Ｓ２０７）。利用可能であれば、定義実行部２３０は、履歴を復元し（Ｓ２１０）、その時点からシナリオを再開する（Ｓ２１１）。利用不可の場合、定義実行部２３０は、更に前の画面を実行定義を参照することで取得し（Ｓ２０８）、シナリオの開始画面でなければ（Ｓ２０９）、先ほどと同様にヒストリ管理部２２０への履歴の問い合わせ（Ｓ２０６）、制約定義との適合の判断（Ｓ２０７）などを実施する。
【００３１】
（シナリオの実行）
図５は、定義実行部２３０がシナリオを実行する動作を示すフローチャートである。定義実行部２３０によるシナリオの実行は、シナリオの開始点、またはセッション履歴を元に復元した再開ポイントから始動するものであり、定義実行部２３０は、シナリオに定義されているコマンドを取得する（Ｓ３０１）。コマンドには画面の入力フィールドへのインプットや、サブミットボタンの押下など通信処理を伴うものがある。定義実行部２３０は、コマンドを解析し、対応する処理を実施する（Ｓ３０２）。定義実行部２３０は、通信部２５０を用いた通信を行うとともに画面遷移が伴い、かつ、ヒストリとしてセッション状態を保存する場合には（後述の図７）、ヒストリ管理部２２０に対して、セッション状態の保存を依頼し（Ｓ３０３）、ヒストリ管理部２２０に保存させる（Ｓ３０４）。ヒストリ管理部２２０による保存は、全画面の状態を保存してもいいし、実行定義としてのシナリオに保存するポイントを指定しても構わない。定義実行部２３０は、実行したコマンドがシナリオの最後であれば、処理を完了し（Ｓ３０５）、最後でなければ、コマンド取得（Ｓ３０１）の処理から繰り返し実行する。
【００３２】
図６は、定義実行部２３０が、実行定義（１）と実行定義（２）とを実行する場合を示す図である。図６において、破線の矢印は実行定義（１）を示し、実線の矢印は実行定義（２）を示す。実行定義（１）は、画面Ｐ１→Ｐ２→Ｐ３→Ｐ４の画面遷移のあるセッションが定義されている。実行定義（２）は、画面Ｐ１→Ｐ２→Ｐ５→Ｐ６の画面遷移のあるセッションが定義されている。
画面Ｐ１、画面Ｐ２は、実行定義（１）と実行定義（２）とに共通である。
画面Ｐ１は、ログイン画面である。
画面Ｐ２は、メニュー画面である。
画面Ｐ３は、入力画面（１）である。
画面Ｐ４は、結果画面（１）である。
画面Ｐ５は、入力画面（２）である。
画面Ｐ６は、結果画面（２）である。
初期状態では、セッション履歴記憶部２１０には履歴情報であるセッション履歴（既存システムとの接続状態）が記憶されていない。従って初期状態では、スクリーンラッピング装置２００は、定義実行部２３０により実行定義（１）、実行定義（２）に従って、画面Ｐ１、Ｐ２、Ｐ３、Ｐ４及び画面遷移Ｐ１、Ｐ２、Ｐ５、Ｐ６が実行される。なお各画面の遷移は、フィールドへの入力＋ボタン押下により実施されるものとする。
【００３３】
（シナリオ１の１回目の実行）
図７は、シナリオ１（実行定義（１））の１回目の実行の処理シーケンスである。この図７は、図６の場合の初期状態における各構成要素間のシーケンス図である。図７を参照して、図６の場合の初期状態の動作を説明する。
【００３４】
（動作の概要）
定義実行部２３０は、クライアント１００からメッセージ処理部２４０を介してシナリオ１（実行定義（１））の実行要求を受信する。各画面の遷移は、フィールドへの入力＋ボタン押下により実施されるものとする。
定義実行部２３０は、最終画面である画面Ｐ４から最初の画面Ｐ１に向かって、順次ヒストリを検索する。
１回目の実行では、セッション履歴記憶部２１０にはヒストリには何も保存されていないため、定義実行部２３０は、画面Ｐ１の処理からシナリオを実行する。図７におけるＰＯＳＴ要求は、画面上のテキストフィールドへのデータ入力はボタン押下による既存システムへの通信要求などを示す。
【００３５】
図７を具体的に説明する。
（１）クライアント１００がＳＯＡＰリクエストを送信すると、メッセージ処理部２４０が受信する（ステップ１）。
（２）メッセージ処理部２４０は、ＳＯＡＰリクエストからＳＯＡＰリクエストに対応するするシナリオ１を特定し、「シナリオ１についての実行要求」を定義実行部２３０に送信する（ステップ１．１）。
（３）定義実行部２３０は、実行定義記憶部２７０を検索してシナリオ１を取得する（ステップ１．１．１）。（４）定義実行部２３０は、制約定義記憶部２６０を検索して、シナリオ１に対応する制約定義を取得する（ステップ１．１．２）。制約定義とシナリオとは対応付けがされており、あるシナリオからは対応する制約定義を特定することができる。
（５）シナリオ１は、図６で述べたよう、画面Ｐ１→Ｐ２→Ｐ３→Ｐ４の画面遷移が定義されている。このため、定義実行部２３０は、最終画面である画面Ｐ４から順次、セッション履歴を検索する。上記のように、シナリオ１の最初の実行（初期状態からの実行）では、セッション履歴記憶部２１０にはヒストリには何も保存されていない。定義実行部２３０は、ヒストリ管理部２２０を用いて、画面Ｐ４から画面Ｐ１の全部についてセッション履歴を確認する。まず、定義実行部２３０は、ヒストリ管理部２２０に、画面Ｐ４（すなわち既存システムに接続しているとすれば、接続した際の接続状態である画面Ｐ４）があるかどうかを問い合わせる（ステップ１．１．３）。ヒストリ管理部２２０は、定義実行部２３０からの問い合わせに応答してセッション履歴記憶部２１０を検索する（ステップ１．１．３．１）。この場合、セッション履歴は存在しないので、ヒストリ管理部２２０は、定義実行部２３０に存在しないことを送信する。
（６）定義実行部２３０は、ヒストリ管理部２２０から画面Ｐ４のセッション履歴が存在しない通知を受けると、次に画面Ｐ３の履歴があるかどうかをヒストリ管理部２２０に問い合わせる（ステップ１．１．４）。以下の処理は画面Ｐ４の場合と同様である。
（７）セッション履歴記憶部２１０にはヒストリは何も保存されていないため、上記と同様の処理が画面Ｐ１まで繰り返される（ステップ１．１．５．１）。
（８）画面Ｐ１〜Ｐ４の全てのセッション履歴が存在しないことを知った定義実行部２３０は、まず、画面Ｐ１の取得要求を通信部２５０を介して既存システム３００に送信し、画面Ｐ１を取得する（ステップ１．１．６及びステップ１．１．６．１）。定義実行部２３０は、取得した画面Ｐ１の保存をヒストリ管理部２２０に依頼する（ステップ１．１．７）。ヒストリ管理部２２０は、画面Ｐ１をセッション履歴記憶部２１０にセッション履歴として保存する（ステップ１．１．７．１）。
（９）以下、同様にして、定義実行部２３０は、通信部２５０、ヒストリ管理部２２０を用いて、画面Ｐ２、面Ｐ３、面Ｐ４をセッション履歴として保存する（ステップ１．１．８〜ステップ１．１．１３．１）。
【００３６】
（シナリオ１の２回目の実行）
図８は、シナリオ１の２回目の実行の場合のシーケンス図である。すなわち、図８は、初期状態からシナリオ１が実行され、さらにその次に、２回目のシナリオ１の実行の場合を示すシーケンスである。
【００３７】
（動作の概要）
定義実行部２３０は、ヒストリ管理部２２０を介してセッション履歴を検索する。図８の例では、画面Ｐ３が制約定義に合致した場合を記述している。制約定義を満たした画面Ｐ３のセッション状態を履歴から検索し、復元することで、その時点からの処理を再開する。画面１から画面３までの画面遷移にかかる処理を省略することができる。
【００３８】
図８を具体的に説明する。
（１）クライアント１００がＳＯＡＰリクエストを送信（ステップ１）してから、定義実行部２３０がヒストリ管理部２２０に画面Ｐ４の履歴があるかどうかを検索（ステップ１．１．３．１）させるまでの流れは、図７の場合と同様である。
（２）図８の場合は、シナリオ１の２回目の実行なので、画面Ｐ１〜画面Ｐ４の履歴はセッション履歴記憶部２１０に存在する。このため、ヒストリ管理部２２０は、定義実行部２３０に画面Ｐ４の履歴が存在することを通知する。
（３）定義実行部２３０は、セッション履歴として保存されている画面Ｐ４が、シナリオ１の２回目の実行に利用可能かどうかを、制約定義記憶部２６０から読み込んでいる制約定義と比較し判定する（ステップ１．１．４）。この例では、画面Ｐ４は、制約定義を満たさないとする。
（４）画面Ｐ４が制約定義を満たさないので、次に、定義実行部２３０は、画面Ｐ３の履歴があるかどうかをヒストリ管理部２２０に問い合わせる（ステップ１．１．５）。画面Ｐ３のセッション履歴は存在するので、ヒストリ管理部２２０は、定義実行部２３０に存在することを通知する。定義実行部２３０は、セッション履歴として保存されている画面Ｐ３が、シナリオ１の２回目の実行に利用可能かどうかを制約定義と比較し判定する（ステップ１．１．６）。この例では、画面Ｐ３は、制約定義を満たすとする。
（５）定義実行部２３０は、制約定義をみたすセッション履歴である画面Ｐ３を復元する（ステップ１．１．７）。画面Ｐ３は復元されるので、画面Ｐ３の利用に関しては、スクリーンラッピング装置２００は、既存システム３００と通信は不要である。
（６）シナリオ１は、画面Ｐ１〜画面Ｐ４に向かって画面遷移するので、次に、定義実行部２３０は、画面Ｐ４を既存システム３００から取得する。すなわち、定義実行部２３０は、通信部２５０を用いて既存システム３００とＨＴＴＰにて画面Ｐ４への遷移要求を実施し、２回目のシナリオ１に使用する画面Ｐ４を取得（ステップ１．１．８、ステップ１．１．８．１）し、取得した画面Ｐ４を実行する。
（７）そして、定義実行部２３０は、取得した画面Ｐ４の保存をヒストリ管理部２２０に依頼（ステップ１．１．９）し、ヒストリ管理部２２０は、画面Ｐ４をセッション履歴としてセッション履歴記憶部２１０に保存する（ステップ１．１．９．１）。以上が図８のシーケンスである。
【００３９】
（シナリオ２の１回目の実行）
図９は、シナリオ２の１回目の実行の場合のシーケンス図である。過去にシナリオ１を実行したことで、ヒストリ管理部２２０により、画面Ｐ１〜画面Ｐ４が保存されている。一方、シナリオ２は、シナリオ１と画面Ｐ１、画面Ｐ２が共用である。従って、シナリオ２については利用可能性のあるセッション履歴として画面Ｐ２を取得できるので、画面Ｐ２が、シナリオ２に対応する制約定義に合致する場合には、そのセッション状態を復元し、処理を再開することができる。これによって画面１から画面２までの画面遷移にかかる処理を省略することができる。図９の場合は、画面Ｐ２は制約定義を満足するものとする。
【００４０】
図９を具体的に説明する。
（１）図９において、クライアント１００がＳＯＡＰリクエストを送信（ステップ１）してから、定義実行部２３０が制約定義記憶部２６０からシナリオ２に対応する制約定義を取得（ステップ１．１．２）するまでの処理は、図７、図８と同じである。
（２）シナリオ２は、図６で述べたよう、画面Ｐ１→Ｐ２→Ｐ５→Ｐ６の画面遷移が定義されている。このため、定義実行部２３０は、最終画面である画面Ｐ６から順次、セッション履歴を検索する。まず、定義実行部２３０は、ヒストリ管理部２２０に、画面Ｐ６があるかどうかを問い合わせる（ステップ１．１．３）。セッション履歴記憶部２１０に画面Ｐ６は保存されていないので、この後の処理は、図７の画面Ｐ１等の場合と同様である。次に定義実行部２３０は、ヒストリ管理部２２０に、画面Ｐ５があるかどうかを問い合わせるが（ステップ１．１．４）、やはり画面Ｐ５のセッション履歴も存在しないので、この後の処理は、図７の画面Ｐ１等の場合と同様である。
（３）さらに、定義実行部２３０は、ヒストリ管理部２２０に、画面Ｐ２があるかどうかを問い合わせる（ステップ１．１．５）。画面Ｐ２のセッション履歴は存在するので、ヒストリ管理部２２０は、定義実行部２３０に存在することを通知する。定義実行部２３０は、セッション履歴として保存されている画面Ｐ２が、シナリオ２の１回目の実行に利用可能かどうかを、シナリオ２に対応する制約定義と比較し判定する（ステップ１．１．６）。この例では、画面Ｐ２は、制約定義を満たすとする。
（５）定義実行部２３０は、制約定義をみたすセッション履歴である画面Ｐ２を復元する（ステップ１．１．７）。
（６）シナリオ１は、画面Ｐ１→画面Ｐ２→画面Ｐ５→画面Ｐ６に向かって画面遷移するので、次に、定義実行部２３０は、画面Ｐ５を既存システム３００から取得する。すなわち、定義実行部２３０は、通信部２５０を用いて既存システム３００とＨＴＴＰにてセッションし、１回目のシナリオ２に使用する画面Ｐ５を取得（ステップ１．１．８、ステップ１．１．８．１）し、取得した画面Ｐ５を実行する。
（７）そして、定義実行部２３０は、取得した画面Ｐ５の保存をヒストリ管理部２２０に依頼（ステップ１．１．９）し、ヒストリ管理部２２０は、画面Ｐ５をセッション履歴としてセッション履歴記憶部２１０に保存する（ステップ１．１．９．１）。
（８）さらに、定義実行部２３０は、画面Ｐ５と同様に、画面Ｐ６を既存システム３００から取得する。画面Ｐ６についての動作は画面Ｐ５の場合と同様であるので、説明は省略する。
以上が図９のシーケンスである。
【００４１】
図１０〜図２９を参照して、以上の処理についてのデータの具体例を説明する。
【００４２】
（ＳＯＡＰリクエストの例）
図１０は、クライアント１００が送信するＳＯＡＰリクエストの例を示す図である。クライアント１００は、スクリーンラッピング装置２００の提供するＷｅｂサービスに対して、図１０に示すようなＳＯＡＰリクエストを送信する。
【００４３】
（シナリオ定義例）
図１１、図１２は、実行定義記憶部２７０に記憶されるシナリオ（実行定義）の一例を示す図である。図１２は、図１１の続きの部分である。定義実行部２３０は、クライアント１００からの図１１、図１２のＳＯＡＰリクエストに対応するシナリオ（実行）を、実行定義記憶部２７０から取得する。
（１）シナリオでは、ＩＮＰＵＴ要素にてＳＯＡＰメッセージに格納されるパラメータを定義する。本例ではＳＯＡＰ  ＢＯＤＹ内の要素名と型によって指定している。
（２）ＯＵＴＰＵＴ要素にて、最終画面から戻り値を抽出するためのルールを定義する。図１１、図１２の例では、ＸＰＡＴＨ（ＸＭＬ  Ｐａｔｈ  Ｌａｎｇｕａｇｅ）を用いて、最終画面から必要なデータを抽出する。ＸＳＬＴ（ＸＭＬ  Ｓｔｙｌｅｓｈｅｅｔ  Ｌａｎｇｕａｇｅ  Ｔｒａｎｓｆｏｒｍａｔｉｏｎｓ）、ＸＱｕｅｒｙなどの方式を用いてもよい。
（３）また、ＳＥＱＵＥＮＣＥ要素から既存システムと連携する手続きを記述する。定義実行部２３０は、上位に記述されたものから順次実施し、ＧＥＴ要素は指定されたＵＲＬに対してＨＴＴＰ  ＧＥＴにより接続する処理を行う。ＡＳＳＩＧＮ要素は画面に対する入力を指定し、変数から画面の入力フィールド、またはその逆の入力処理を実施する。ＷＡＩＴ要素は、画面タイトルや特定の位置に表示される文字列などから、画面遷移が完了したことを確認（遷移が完了するまで待機）する。遷移が完了した時点でヒストリ管理部に対して、セッション状態の保存を要求する。セッション状態のほかに、シナリオで定義される変数なども合わせて保存し、制約定義として利用することができる。保存の実施有無は、ＷＡＩＴ要素の属性として指定してもよい。
【００４４】
（制約定義）
図１３〜図１６は、制約定義の例を示す図である。これらの図を参照して制約定義を説明する。定義実行部２３０は、制約定義記憶部２６０からシナリオに対応する制約定義を取得する。
（１）図１３は、ＦＯＲＭ要素をシナリオに登場する画面にあわせて設定している（利用不可の画面は省略してもよい）。どの画面に対応するかはｕｒｉ属性にて指定し、シナリオのＷＡＩＴ要素のＩｄ属性に対応する。Ａｖａｉｌａｂｌｅ属性によって、ヒストリとして復元し、再利用していいかどうかを指定する。上記の例ではＰ４で指定される画面は再利用不可であり、Ｐ４までの画面遷移は毎回実行しないといけない。Ｐ３、Ｐ２、Ｐ１で指定される画面はヒストリにあれば再利用可能である。単にセッション履歴に対してセッション情報があるか／ないかだけでなく、変数のユーザＩＤが一致するなら利用可能である場合や、リクエスト日がヒストリへの保存日と同じ日にちならば利用可能などの指定を行うには、ｆｏｒｍ要素の子要素に付加情報を設定する。
（２）図１４は、Ｐ３画面がヒストリに存在し、ＵｓｅｒＩｄの変数がヒストリ内の情報と今回のリクエストとで一致すれば利用可能な定義の例を示している。ＣＯＮＤＩＴＩＯＮ要素にて変数および一致／不一致／範囲指定などの条件を指定する。
（３）図１５は、Ｐ３画面がヒストリに存在し、保存日とリクエスト日が一致すれば利用可能な定義の例を示している。変数以外の予約語として「＠・・・」で記述している。
（４）図１６は、Ｐ３画面がヒストリに存在し、かつＰ２，Ｐ１画面もヒストリに存在する場合に利用可能な定義の例示している。ＤＥＰＥＮＤＳ要素にて、依存関係のある画面を指定する。
【００４５】
（ＨＴＴＰ通信）
図１７〜図２８を参照して、既存システム３００とスクリーンラッピング装置２００との間のＨＴＴＰ通信の例を以下に示す。
（１）ログイン画面への接続：
図１７は、ログイン画面への接続におけるＨＴＴＰリクエストの例である。また図１８は、ＨＴＴＰレスポンスの例である。また、図１９は、ブラウザにて表示した場合のイメージを示す図である。
（２）ログイン処理（初期画面への遷移）：
図２０は、ログイン処理（初期画面への遷移）におけるＨＴＴＰリクエストの一例を示す図である。ユーザＩＤ，パスワードは、ＳＯＡＰリクエストにおいて指定されたものを利用する。図２１は、図２０のＨＴＴＰリクエストへのＨＴＴＰレスポンスの例を示す図である。また、図２２は、ブラウザにて表示した場合のイメージを示す図である。
（３）検索実行（一覧画面への遷移）：
図２３は、検索実行（一覧画面への遷移）におけるＨＴＴＰリクエストの例である。検索キーワードは、ＳＯＡＰリクエストに指定されたものを利用する。また、図２４は、このＨＴＴＰリクエストに対するＨＴＴＰレスポンスの例である。また、図２５は、ブラウザにて表示した場合のイメージを示す図である。
（４）詳細表示（詳細画面への遷移）：
図２６は、詳細表示（詳細画面への遷移）におけるＨＴＴＰリクエストの例である。また、図２７は、このＨＴＴＰリクエストに対するＨＴＴＰレスポンスの例である。また、図２８は、ブラウザにて表示した場合のイメージを示す図である。
【００４６】
（ＳＯＡＰレスポンス）
図２９は、（ＳＯＡＰレスポンス）の例を示す図である。最終画面から、戻り値の抽出ルールに従って作成したＳＯＡＰレスポンスの例を示している。
【００４７】
以上説明したように、実施の形態１のスクリーンラッピング装置２００は、保存したセッション履歴（接続状態）を復元し、その時点から処理を再開することができるので、クライアント１００から処理要求に対して、処理の高速化、効率化を図ることができる。また、実施の形態１のスクリーンラッピング装置２００は、複数のシナリオ（実行定義）を実施する際に、どの実行定義からもセッション履歴を共有して利用できる構成としている。すなわち、図９で述べたように、シナリオ１のセッション履歴である画面Ｐ２を、シナリオ２も利用できる構成としているので、更なる処理の高速化、効率化を図ることができる。
【００４８】
以上の実施の形態１では、クライアントからのリクエストに対して既存システムとの連携を実行定義に従い実施するとともに、既存システムとの接続状態を履歴情報として保存することを特徴とするスクリーンラッピングシステムを説明した。
【００４９】
以上の実施の形態１では、保存した接続状態を復元し、その時点から処理を再開することで、処理の高速化、効率化を行うことを特徴とするスクリーンラッピングシステムを説明した。
【００５０】
以上の実施の形態１では、複数の実行定義を実施する際に、どの実行定義からも履歴情報を共有して利用できることを特徴とするスクリーンラッピングシステムを説明した。
【００５１】
以上の実施の形態１では、実行定義、制約定義および履歴情報（セッション履歴）から、過去において実行定義に基づき実施した処理を省略し、処理の効率化を実現できる再開ポイントを自動判別することを特徴とするスクリーンラッピングシステムを説明した。
【００５２】
以上の実施の形態１で説明したスクリーンラッピングシステムは、
スクリーンラッピング装置に対するリクエストを作成するクライアントと、
クライアントからのリクエストを受信するメッセージ処理部、リクエストに対応する実行定義（シナリオ）を抽出し、実行定義、セッション履歴、制約定義情報から処理を再開するセッション履歴を判別し、セッションを復元し、再開ポイントからシナリオを実行する定義実行部、
セッション履歴を管理するヒストリ管理部、
既存システムに対する通信を管理する通信処理部を備えたスクリーンラッピング装置と、
クライアントに対してＨＴＴＰ画面などのＩ／Ｆを提供する既存システムを備え、
クライアントにセッション履歴の状態や再開ポイントを意識させることなく、シナリオ間で履歴情報を共有し、最適な再開ポイントを自動判別することで、不要な処理をスキップし、効率的な処理を実現することを特徴とするものである。
【００５３】
このスクリーンラッピングシステムにより、過去に実施した処理をスキップすることで、ラッピング処理の高速化、効率化を実現することが可能となる。
【図面の簡単な説明】
【００５４】
【図１】実施の形態１におけるスクリーンラッピング装置２００を実現するコンピュータシステムの外観の一例。
【図２】実施の形態１におけるスクリーンラッピング装置２００を実現するコンピュータシステムのハードウェア構成の一例。
【図３】実施の形態１におけるスクリーンラッピングシステム１０００の構成ブロック図。
【図４】実施の形態１におけるスクリーンラッピング装置２００の動作を示すフローチャート。
【図５】実施の形態１における定義実行部２３０によるシナリオ実行のフローチャート。
【図６】実施の形態１における定義実行部２３０によるシナリオ１、シナリオ２の実行の具体例を示す図。
【図７】図６の場合におけるシナリオ１の１回目の実行のシーケンス。
【図８】図６の場合におけるシナリオ１の２回目の実行のシーケンス。
【図９】図６の場合におけるシナリオ２の１回目の実行のシーケンス。
【図１０】実施の形態１におけるＳＯＡＰリクエストの例。
【図１１】実施の形態１におけるシナリオ定義の例。
【図１２】図１１の続きであるシナリオ定義。
【図１３】実施の形態１における制約定義の例１。
【図１４】実施の形態１における制約定義の例２。
【図１５】実施の形態１における制約定義の例３。
【図１６】実施の形態１における制約定義の例４。
【図１７】実施の形態１におけるログイン画面への接続のＨＴＴＰリクエスト。
【図１８】図１７へのＨＴＴＰレスポンス。
【図１９】図１８に対応するブラウザによる表示のイメージ。
【図２０】実施の形態１におけるログイン処理へのＨＴＴＰリクエスト。
【図２１】図２０へのＨＴＴＰレスポンス。
【図２２】図２１に対応するブラウザによる表示のイメージ。
【図２３】実施の形態１における検索実行へのＨＴＴＰリクエスト。
【図２４】図２３へのＨＴＴＰレスポンス。
【図２５】図２４に対応するブラウザによる表示のイメージ。
【図２６】実施の形態１における実施の形態１における詳細表示へのＨＴＴＰリクエスト。
【図２７】図２６へのＨＴＴＰレスポンス。
【図２８】図２７に対応するブラウザによる表示のイメージ。
【図２９】実施の形態１におけるＳＯＡＰレスポンスの例。
【符号の説明】
【００５５】
１０００  スクリーンラッピングシステム、１００  クライアント、２００  スクリーンラッピング装置、２１０  セッション履歴記憶部、２２０  ヒストリ管理部、２３０  定義実行部、２４０  メッセージ処理部、２５０  通信部、２６０  制約定義記憶部、２７０  実行定義記憶部、２８０  実行保存部、３００  既存システム。
【図１】
2009193512.tif 000003
【図２】
2009193512.tif 000004
【図３】
2009193512.tif 000005
【図４】
2009193512.tif 000006
【図５】
2009193512.tif 000007
【図６】
2009193512.tif 000008
【図７】
2009193512.tif 000009
【図８】
2009193512.tif 000010
【図９】
2009193512.tif 000011
【図１０】
2009193512.tif 000012
【図１１】
2009193512.tif 000013
【図１２】
2009193512.tif 000014
【図１３】
2009193512.tif 000015
【図１４】
2009193512.tif 000016
【図１５】
2009193512.tif 000017
【図１６】
2009193512.tif 000018
【図１７】
2009193512.tif 000019
【図１８】
2009193512.tif 000020
【図１９】
2009193512.tif 000021
【図２０】
2009193512.tif 000022
【図２１】
2009193512.tif 000023
【図２２】
2009193512.tif 000024
【図２３】
2009193512.tif 000025
【図２４】
2009193512.tif 000026
【図２５】
2009193512.tif 000027
【図２６】
2009193512.tif 000028
【図２７】
2009193512.tif 000029
【図２８】
2009193512.tif 000030
【図２９】
2009193512.tif 000031