JP2009193512A - セッション実行装置及びセッション実行プログラム及び記録媒体 - Google Patents
セッション実行装置及びセッション実行プログラム及び記録媒体 Download PDFInfo
- Publication number
- JP2009193512A JP2009193512A JP2008036083A JP2008036083A JP2009193512A JP 2009193512 A JP2009193512 A JP 2009193512A JP 2008036083 A JP2008036083 A JP 2008036083A JP 2008036083 A JP2008036083 A JP 2008036083A JP 2009193512 A JP2009193512 A JP 2009193512A
- Authority
- JP
- Japan
- Prior art keywords
- session
- definition
- execution
- screen
- scenario
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Computer And Data Communications (AREA)
Abstract
【課題】従来のラッピングシステムに対し、クライアントのリクエストに対し毎回シナリオ最初からの処理実行が不要であり、また過去に保存した操作履歴の状態を復元し、そこから再開するシナリオを実行する場合も、クライアント側はサーバに保存された操作履歴の認識不要なラッピング装置を提供する。
【解決手段】セッション履歴記憶部210部は定義実行部230と既存システム300とのセッション履歴を持つ。制約定義記憶部260は制約定義をもつ。クライアント100の処理要求で実行定義記憶部270の持つ実行定義が決まり、実行定義から制約定義が決まる。制約定義にはセッション履歴が利用可能かを示す制約条件が定義されている。定義実行部230はクライアント100から処理要求を受けると対応する制約定義を参照し、利用可能なセッション履歴があればそのセッション履歴を利用する。これにより既存システム300とのセッションが不要となる。
【選択図】図3
【解決手段】セッション履歴記憶部210部は定義実行部230と既存システム300とのセッション履歴を持つ。制約定義記憶部260は制約定義をもつ。クライアント100の処理要求で実行定義記憶部270の持つ実行定義が決まり、実行定義から制約定義が決まる。制約定義にはセッション履歴が利用可能かを示す制約条件が定義されている。定義実行部230はクライアント100から処理要求を受けると対応する制約定義を参照し、利用可能なセッション履歴があればそのセッション履歴を利用する。これにより既存システム300とのセッションが不要となる。
【選択図】図3
Description
この発明は、既存システムとの連携をプロトコル変換により、別なサービスインタフェースとして提供するラッピング装置に関し、特にクライアントが表示する画面情報を既存システムが送信し、サービスを利用するのに複数画面の遷移が必要となるシステムのラッピング装置(セッション実行装置)に関する。
従来の既存システムとの連携を行うラッピングシステムでは、既存システムとの一連の処理をシナリオとして定義し、これを実行することで、クライアントからの1回のリクエストに対して既存システムの提供する複数画面に渡る一連の処理を実現している。また、既存システムとの連携処理を最初から再実行するのではなく、過去に保存した状態を復元し、再開することで、処理を効率化するといった仕組みがある(例えば、特許文献1)。
特開2000−020349号公報
従来のスクリーンラッピングシステムにおいて、クライアントからのリクエストに対して毎回、シナリオの最初から処理を実行するために、効率的に処理を行うことができなかった。または、過去に保存した操作履歴の状態を復元し、そこから再開するシナリオを選択実行することで処理を効率化することができるが、要求を出すクライアント側で、サーバ上に保存された操作履歴を認識している必要のあることや、復元した状態が例えばセッションタイムアウトなどで利用不可となっていた場合に、エラー通知をクライアント側に通知し、クライアント側で別の地点から再開するシナリオを選択して実行する必要があるという課題があった。
本発明は、上記の課題を解決するためのものであり、クライアントが、過去に保存した操作履歴であるヒストリを管理するヒストリ管理部にどの状態が保存されているのか、また、それが利用可なのかを判断する必要がなく、最適な再開ポイントを自動選択可能とすることでラッピング処理を効率的に実施する装置の提供を目的とする。また、異なるシナリオ(実行定義)においても、途中までの処理が同じであれば、別シナリオでのヒストリを利用し、ラッピング処理を効率的に実施することを目的とする。
この発明のセッション実行装置は、
他の装置と第1プロトコルで通信を行なう所定のシステム装置を対象とするセッション要求であって、前記第1プロトコルとは異なる第2プロトコルによるセッション要求を受信するセッション要求受信部と、
前記セッション要求受信部が受信する前記セッション要求に対応し、かつ、前記所定のシステム装置に対するセッションが定義された実行定義を記憶する実行定義記憶部と、
情報を記憶する情報記憶部と、
前記セッション要求受信部が前記セッション要求を受信すると、受信された前記セッション要求に対応する前記実行定義に基づいて前記第1プロトコルにより前記所定のシステム装置との間でセッションを実行するとともに、実行したセッションにおける前記所定のシステム装置との接続状態を、前記所定のシステム装置と接続することなく復元可能な履歴情報として前記情報記憶部に保存する実行保存部と
を備えたことを特徴とする。
他の装置と第1プロトコルで通信を行なう所定のシステム装置を対象とするセッション要求であって、前記第1プロトコルとは異なる第2プロトコルによるセッション要求を受信するセッション要求受信部と、
前記セッション要求受信部が受信する前記セッション要求に対応し、かつ、前記所定のシステム装置に対するセッションが定義された実行定義を記憶する実行定義記憶部と、
情報を記憶する情報記憶部と、
前記セッション要求受信部が前記セッション要求を受信すると、受信された前記セッション要求に対応する前記実行定義に基づいて前記第1プロトコルにより前記所定のシステム装置との間でセッションを実行するとともに、実行したセッションにおける前記所定のシステム装置との接続状態を、前記所定のシステム装置と接続することなく復元可能な履歴情報として前記情報記憶部に保存する実行保存部と
を備えたことを特徴とする。
この発明により、クライアント装置から処理要求に対して、処理の高速化、効率化を図るセッション実行装置を提供することができる。
実施の形態1.
図1は、コンピュータで実現されるスクリーンラッピング装置200の外観の一例を示す図である。図1は、サーバ(コンピュータ)であるスクリーンラッピング装置200と、後述のクライアント100の機能を有するクライアント端末装置と、既存システム300とが、ネットワーク(インターネット)に接続している状態を示している。図1において、コンピュータで実現されるスクリーンラッピング装置200は、システムユニット830、CRT(Cathode・Ray・Tube)やLCD(液晶)の表示画面を有する表示装置813、キーボード814(Key・Board:K/B)、マウス815、FDD817(Flexible・Disk・ Drive)、コンパクトディスク装置818(CDD:Compact Disk Drive)、プリンタ装置819などのハードウェア資源を備え、これらはケーブルや信号線で接続されている。
図1は、コンピュータで実現されるスクリーンラッピング装置200の外観の一例を示す図である。図1は、サーバ(コンピュータ)であるスクリーンラッピング装置200と、後述のクライアント100の機能を有するクライアント端末装置と、既存システム300とが、ネットワーク(インターネット)に接続している状態を示している。図1において、コンピュータで実現されるスクリーンラッピング装置200は、システムユニット830、CRT(Cathode・Ray・Tube)やLCD(液晶)の表示画面を有する表示装置813、キーボード814(Key・Board:K/B)、マウス815、FDD817(Flexible・Disk・ Drive)、コンパクトディスク装置818(CDD:Compact Disk Drive)、プリンタ装置819などのハードウェア資源を備え、これらはケーブルや信号線で接続されている。
図2は、コンピュータで実現されるスクリーンラッピング装置200のハードウェア資源の一例を示す図である。図2において、スクリーンラッピング装置200は、プログラムを実行するCPU810(Central Processing Unit:中央処理装置、処理装置、演算装置、マイクロプロセッサ、マイクロコンピュータ、プロセッサともいう)を備えている。CPU810は、バス825を介してROM(Read Only Memory)811、RAM(Random Access Memory)812、表示装置813、キーボード814、マウス815、通信ボード816、FDD817、CDD818、プリンタ装置819、磁気ディスク装置820と接続され、これらのハードウェアデバイスを制御する。磁気ディスク装置820の代わりに、光ディスク装置、フラッシュメモリなどの記憶装置でもよい。
RAM812は、揮発性メモリの一例である。ROM811、FDD817、CDD818、磁気ディスク装置820等の記憶媒体は、不揮発性メモリの一例である。これらは、記憶装置あるいは記憶部、格納部、バッファの一例である。通信ボード816、キーボード814、FDD817などは、入力部、入力装置の一例である。また、通信ボード816、表示装置813、プリンタ装置819などは、出力部、出力装置の一例である。
通信ボード816は、ネットワーク(LAN等)に接続されている。通信ボード816は、LANに限らず、インターネット、ISDN等のWAN(ワイドエリアネットワーク)などに接続されていても構わない。
磁気ディスク装置820には、オペレーティングシステム821(OS)、ウィンドウシステム822、プログラム群823、ファイル群824が記憶されている。プログラム群823のプログラムは、CPU810、オペレーティングシステム821、ウィンドウシステム822により実行される。
上記プログラム群823には、以下に述べる実施の形態の説明において「〜部」として説明する機能を実行するプログラムが記憶されている。プログラムは、CPU810により読み出され実行される。
ファイル群824には、以下に述べる実施の形態の説明において、「実行定義」(実行定義は、シナリオともいう。)、「制約定義」、「セッション履歴」などとして説明する情報や、「〜の判定結果」、「〜の算出結果」、「〜の抽出結果」、「〜の生成結果」、「〜の処理結果」として説明する情報や、データや信号値や変数値やパラメータなどが、「〜ファイル」や「〜データベース」の各項目として記憶されている。「〜ファイル」や「〜データベース」は、ディスクやメモリなどの記録媒体に記憶される。ディスクやメモリなどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してCPU810によりメインメモリやキャッシュメモリに読み出され、抽出・検索・参照・比較・演算・計算・処理・出力・印刷・表示などのCPUの動作に用いられる。抽出・検索・参照・比較・演算・計算・処理・出力・印刷・表示のCPUの動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリやキャッシュメモリやバッファメモリに一時的に記憶される。
また、以下に述べる実施の形態の説明においては、データや信号値は、RAM812のメモリ、FDD817のフレキシブルディスク、CDD818のコンパクトディスク、磁気ディスク装置820の磁気ディスク、その他光ディスク、ミニディスク、DVD(Digital・Versatile・Disk)等の記録媒体に記録される。また、データや信号は、バス825や信号線やケーブルその他の伝送媒体によりオンライン伝送される。
また、以下に述べる実施の形態の説明において、「〜部」として説明するものは、「手段」、「〜回路」、「〜機器」であってもよく、また、「〜ステップ」、「〜手順」、「〜処理」であってもよい。すなわち、「〜部」として説明するものは、ROM811に記憶されたファームウェアで実現されていても構わない。或いは、ソフトウェアのみ、或いは、素子・デバイス・基板・配線などのハードウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせ、さらには、ファームウェアとの組み合わせで実施されても構わない。ファームウェアとソフトウェアは、プログラムとして、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ミニディスク、DVD等の記録媒体に記憶される。プログラムはCPU810により読み出され、CPU810により実行される。すなわち、プログラムは、以下に述べる「〜部」としてコンピュータを機能させるものである。あるいは、以下に述べる「〜部」の手順や方法をコンピュータに実行させるものである。
図3は、実施の形態1におけるスクリーンラッピングシステム1000を示す図である。
(システム構成)
スクリーンラッピングシステム1000は、クライアント100(クライアント端末装置、あるいはクライアント端末装置に組み込まれたクライアント機能を有するクライアントプログラム)、スクリーンラッピング装置200(セッション実行装置)、既存システム300(システム装置)から構成される。
スクリーンラッピングシステム1000は、クライアント100(クライアント端末装置、あるいはクライアント端末装置に組み込まれたクライアント機能を有するクライアントプログラム)、スクリーンラッピング装置200(セッション実行装置)、既存システム300(システム装置)から構成される。
クライアント100は、スクリーンラッピング装置200と、例えば、SOAP(Simple Object Access Protocol)(第2のプロトコル)で通信する。また、既存システム300は、例えば、スクリーンラッピング装置200とHTTP(HyperText Transfer Protocol)(第1のプロトコル)でセッションする。
(接続関係)
クライアント100とスクリーンラッピング装置200とは、ネットワーク401により接続されてもよいし、あるいは、クライアント100とスクリーンラッピング装置200とは同一マシン上において構成されてもよい。また、スクリーンラッピング装置200と既存システム300との間も同様に、ネットワーク402により接続されてもよいし、同一マシン上において構成されてもよい。すなわち、スクリーンラッピング装置200は、クライアント100と既存システム300とを接続する装置であるので、スクリーンラッピング装置200はクライアント側に組み込まれてもよいし、既存システム300側に組み込まれても構わない。
クライアント100とスクリーンラッピング装置200とは、ネットワーク401により接続されてもよいし、あるいは、クライアント100とスクリーンラッピング装置200とは同一マシン上において構成されてもよい。また、スクリーンラッピング装置200と既存システム300との間も同様に、ネットワーク402により接続されてもよいし、同一マシン上において構成されてもよい。すなわち、スクリーンラッピング装置200は、クライアント100と既存システム300とを接続する装置であるので、スクリーンラッピング装置200はクライアント側に組み込まれてもよいし、既存システム300側に組み込まれても構わない。
クライアント100は、スクリーンラッピング装置200に対して、例えばSOAP通信による要求で、特定のシナリオの実行要求を行う。
(スクリーンラッピング装置200)
スクリーンラッピング装置200は、受信したSOAPメッセージに対応するシナリオ(実行定義)を判別し、シナリオ、後述のセッション履歴、後述の制約定義からシナリオの再開ポイントを判別し、セッション履歴に格納されたセッション状態を復元し、対応するシナリオの再開ポイントから処理を再開し、例えばブラウザIF(Inter Face)を提供する既存システム300に対してHTTP通信による処理要求を行う。
スクリーンラッピング装置200は、受信したSOAPメッセージに対応するシナリオ(実行定義)を判別し、シナリオ、後述のセッション履歴、後述の制約定義からシナリオの再開ポイントを判別し、セッション履歴に格納されたセッション状態を復元し、対応するシナリオの再開ポイントから処理を再開し、例えばブラウザIF(Inter Face)を提供する既存システム300に対してHTTP通信による処理要求を行う。
(既存システム300)
既存システム300は、受信したHTTPリクエストに対して応答を返す。スクリーンラッピング装置200は、シナリオに定義された一連の処理が完了した時点で、SOAP通信の応答をクライアントに返す。
既存システム300は、受信したHTTPリクエストに対して応答を返す。スクリーンラッピング装置200は、シナリオに定義された一連の処理が完了した時点で、SOAP通信の応答をクライアントに返す。
(スクリーンラッピング装置200の構成)
スクリーンラッピング装置200は、セッション履歴を記憶するセッション履歴記憶部210、ヒストリ管理部220、定義実行部230、メッセージ処理部240、通信部250、制約定義を格納する制約定義記憶部260、実行定義を格納する実行定義記憶部270とから構成される。また、ヒストリ管理部220と定義実行部230とは実行保存部280を構成する。
スクリーンラッピング装置200は、セッション履歴を記憶するセッション履歴記憶部210、ヒストリ管理部220、定義実行部230、メッセージ処理部240、通信部250、制約定義を格納する制約定義記憶部260、実行定義を格納する実行定義記憶部270とから構成される。また、ヒストリ管理部220と定義実行部230とは実行保存部280を構成する。
(各構成要素の機能)
(1.メッセージ処理部240)
メッセージ処理部240は、WebサービスのAPI(Application Program Interface)を開示し、クライアントからのSOAPリクエスト(セッション要求)を受信する。SOAPリクエストメッセージには、シナリオを実行するためのパラメータ(ログインID,パスワード,検索キーワードなど)が含まれる。メッセージ処理部240は、提供するサービスのURL(Uniform Resource Locator)やリクエストメッセージに含まれるパラメータ情報から対応するシナリオを特定し、定義実行部230にシナリオ実行要求を送信する。
(2.定義実行部230)
定義実行部230は、メッセージ処理部240からシナリオ実行要求を受信し、実行定義記憶部270から対応する実行要求に対応するシナリオを検索し、制約定義記憶部260から検索対象のシナリオに対応する制約定義を検索し、そして、ヒストリ管理部220を用いてセッション履歴記憶部210から制約定義を満たすセッション履歴を検索し、保存されたセッション状況(セッション履歴)を復元し、シナリオを当該セッションの状況から再開する。
(3.通信部250)
既存システム300へのリクエストは、定義実行部230が通信部250を経由して実施する。通信部250は、既存システム300から受信する画面情報(HTML(HyperText Markup Language)など)の解析機能や、画面へのデータ設定機能、およびボタン押下時の送信データの生成機能などを有する。この通信部250は、「ブラウザエンジン」(ブラウザ機能を持ちAPIでの操作機能を提供)相当の機能を有している。
(1.メッセージ処理部240)
メッセージ処理部240は、WebサービスのAPI(Application Program Interface)を開示し、クライアントからのSOAPリクエスト(セッション要求)を受信する。SOAPリクエストメッセージには、シナリオを実行するためのパラメータ(ログインID,パスワード,検索キーワードなど)が含まれる。メッセージ処理部240は、提供するサービスのURL(Uniform Resource Locator)やリクエストメッセージに含まれるパラメータ情報から対応するシナリオを特定し、定義実行部230にシナリオ実行要求を送信する。
(2.定義実行部230)
定義実行部230は、メッセージ処理部240からシナリオ実行要求を受信し、実行定義記憶部270から対応する実行要求に対応するシナリオを検索し、制約定義記憶部260から検索対象のシナリオに対応する制約定義を検索し、そして、ヒストリ管理部220を用いてセッション履歴記憶部210から制約定義を満たすセッション履歴を検索し、保存されたセッション状況(セッション履歴)を復元し、シナリオを当該セッションの状況から再開する。
(3.通信部250)
既存システム300へのリクエストは、定義実行部230が通信部250を経由して実施する。通信部250は、既存システム300から受信する画面情報(HTML(HyperText Markup Language)など)の解析機能や、画面へのデータ設定機能、およびボタン押下時の送信データの生成機能などを有する。この通信部250は、「ブラウザエンジン」(ブラウザ機能を持ちAPIでの操作機能を提供)相当の機能を有している。
定義実行部230は、シナリオを実行し、セッション状況が更新されたときには、ヒストリ管理部220に対して、最新のセッション状況を保存するようにリクエストを行う。例えばJava(登録商標)によってスクリーンラッピング装置200(プログラムの場合)を実装している場合には、セッション状況(接続状態)の保存、復元は、セッションを管理するオブジェクトのシリアライズ、デシリアライズにより実現することができる。
定義実行部230は、シナリオを最後まで実行すると、既存システム300から取得した画面情報から必要なデータを抽出してSOAPレスポンスメッセージを作成し、メッセージ処理部240を経由してクライアント100に応答を返す。
結果画面からSOAPの戻り値を抽出するルールは、シナリオの一部として定義してもいいし、SOAPリクエストメッセージに含めて要求を行ってもいい。
(スクリーンラッピング装置200の処理フローの概要)
図4は、スクリーンラッピング装置200の動作を示すフローチャートである。図4を参照してスクリーンラッピング装置200の動作を説明する。図4ではスクリーンラッピング装置200の一般的な動作を説明し、具体的な場合は図6〜図9で説明する。
図4は、スクリーンラッピング装置200の動作を示すフローチャートである。図4を参照してスクリーンラッピング装置200の動作を説明する。図4ではスクリーンラッピング装置200の一般的な動作を説明し、具体的な場合は図6〜図9で説明する。
(シナリオの特定)
クライアント100が送信したSOAPリクエストメッセージを、メッセージ処理部240が受信する(S201)。メッセージ処理部240は、受信したSOAPリクエストから対応するシナリオを特定する(S202)。シナリオの特定には、予め公開しているWebサービスごとに対応するシナリオを設定することで行う。または、SOAPリクエストメッセージ内のパラメータとして、シナリオの識別子を格納することで行う。
クライアント100が送信したSOAPリクエストメッセージを、メッセージ処理部240が受信する(S201)。メッセージ処理部240は、受信したSOAPリクエストから対応するシナリオを特定する(S202)。シナリオの特定には、予め公開しているWebサービスごとに対応するシナリオを設定することで行う。または、SOAPリクエストメッセージ内のパラメータとして、シナリオの識別子を格納することで行う。
(定義実行部230の動作)
定義実行部230は、メッセージ処理部240からシナリオ実行要求を受信し、実行定義記憶部270からシナリオを取得する(S203)。また、定義実行部230は、シナリオに対応する制約定義を制約定義記憶部260から取得する(S204)。定義実行部230は、シナリオの内容を解釈し、戻り値を抽出する最終画面を実行定義の終了時点から逆順に辿り取得する(S205)。定義実行部230は、ヒストリ管理部220に、取得した画面(接続した際のセッション状態)の履歴情報があるかを問い合わせる(S206)。画面を特定する方法としては、URLや画面タイトルなどを識別子として用い、実際に通信を行うJava(登録商標)オブジェクトの情報とセットで保存する。セッション履歴にヒストリとして履歴が残っている場合、定義実行部230は、その画面(セッション状態)が再開ポイントとして利用可能かを制約定義と比較し判定する(S207)。利用可能であれば、定義実行部230は、履歴を復元し(S210)、その時点からシナリオを再開する(S211)。利用不可の場合、定義実行部230は、更に前の画面を実行定義を参照することで取得し(S208)、シナリオの開始画面でなければ(S209)、先ほどと同様にヒストリ管理部220への履歴の問い合わせ(S206)、制約定義との適合の判断(S207)などを実施する。
定義実行部230は、メッセージ処理部240からシナリオ実行要求を受信し、実行定義記憶部270からシナリオを取得する(S203)。また、定義実行部230は、シナリオに対応する制約定義を制約定義記憶部260から取得する(S204)。定義実行部230は、シナリオの内容を解釈し、戻り値を抽出する最終画面を実行定義の終了時点から逆順に辿り取得する(S205)。定義実行部230は、ヒストリ管理部220に、取得した画面(接続した際のセッション状態)の履歴情報があるかを問い合わせる(S206)。画面を特定する方法としては、URLや画面タイトルなどを識別子として用い、実際に通信を行うJava(登録商標)オブジェクトの情報とセットで保存する。セッション履歴にヒストリとして履歴が残っている場合、定義実行部230は、その画面(セッション状態)が再開ポイントとして利用可能かを制約定義と比較し判定する(S207)。利用可能であれば、定義実行部230は、履歴を復元し(S210)、その時点からシナリオを再開する(S211)。利用不可の場合、定義実行部230は、更に前の画面を実行定義を参照することで取得し(S208)、シナリオの開始画面でなければ(S209)、先ほどと同様にヒストリ管理部220への履歴の問い合わせ(S206)、制約定義との適合の判断(S207)などを実施する。
(シナリオの実行)
図5は、定義実行部230がシナリオを実行する動作を示すフローチャートである。定義実行部230によるシナリオの実行は、シナリオの開始点、またはセッション履歴を元に復元した再開ポイントから始動するものであり、定義実行部230は、シナリオに定義されているコマンドを取得する(S301)。コマンドには画面の入力フィールドへのインプットや、サブミットボタンの押下など通信処理を伴うものがある。定義実行部230は、コマンドを解析し、対応する処理を実施する(S302)。定義実行部230は、通信部250を用いた通信を行うとともに画面遷移が伴い、かつ、ヒストリとしてセッション状態を保存する場合には(後述の図7)、ヒストリ管理部220に対して、セッション状態の保存を依頼し(S303)、ヒストリ管理部220に保存させる(S304)。ヒストリ管理部220による保存は、全画面の状態を保存してもいいし、実行定義としてのシナリオに保存するポイントを指定しても構わない。定義実行部230は、実行したコマンドがシナリオの最後であれば、処理を完了し(S305)、最後でなければ、コマンド取得(S301)の処理から繰り返し実行する。
図5は、定義実行部230がシナリオを実行する動作を示すフローチャートである。定義実行部230によるシナリオの実行は、シナリオの開始点、またはセッション履歴を元に復元した再開ポイントから始動するものであり、定義実行部230は、シナリオに定義されているコマンドを取得する(S301)。コマンドには画面の入力フィールドへのインプットや、サブミットボタンの押下など通信処理を伴うものがある。定義実行部230は、コマンドを解析し、対応する処理を実施する(S302)。定義実行部230は、通信部250を用いた通信を行うとともに画面遷移が伴い、かつ、ヒストリとしてセッション状態を保存する場合には(後述の図7)、ヒストリ管理部220に対して、セッション状態の保存を依頼し(S303)、ヒストリ管理部220に保存させる(S304)。ヒストリ管理部220による保存は、全画面の状態を保存してもいいし、実行定義としてのシナリオに保存するポイントを指定しても構わない。定義実行部230は、実行したコマンドがシナリオの最後であれば、処理を完了し(S305)、最後でなければ、コマンド取得(S301)の処理から繰り返し実行する。
図6は、定義実行部230が、実行定義(1)と実行定義(2)とを実行する場合を示す図である。図6において、破線の矢印は実行定義(1)を示し、実線の矢印は実行定義(2)を示す。実行定義(1)は、画面P1→P2→P3→P4の画面遷移のあるセッションが定義されている。実行定義(2)は、画面P1→P2→P5→P6の画面遷移のあるセッションが定義されている。
画面P1、画面P2は、実行定義(1)と実行定義(2)とに共通である。
画面P1は、ログイン画面である。
画面P2は、メニュー画面である。
画面P3は、入力画面(1)である。
画面P4は、結果画面(1)である。
画面P5は、入力画面(2)である。
画面P6は、結果画面(2)である。
初期状態では、セッション履歴記憶部210には履歴情報であるセッション履歴(既存システムとの接続状態)が記憶されていない。従って初期状態では、スクリーンラッピング装置200は、定義実行部230により実行定義(1)、実行定義(2)に従って、画面P1、P2、P3、P4及び画面遷移P1、P2、P5、P6が実行される。なお各画面の遷移は、フィールドへの入力+ボタン押下により実施されるものとする。
画面P1、画面P2は、実行定義(1)と実行定義(2)とに共通である。
画面P1は、ログイン画面である。
画面P2は、メニュー画面である。
画面P3は、入力画面(1)である。
画面P4は、結果画面(1)である。
画面P5は、入力画面(2)である。
画面P6は、結果画面(2)である。
初期状態では、セッション履歴記憶部210には履歴情報であるセッション履歴(既存システムとの接続状態)が記憶されていない。従って初期状態では、スクリーンラッピング装置200は、定義実行部230により実行定義(1)、実行定義(2)に従って、画面P1、P2、P3、P4及び画面遷移P1、P2、P5、P6が実行される。なお各画面の遷移は、フィールドへの入力+ボタン押下により実施されるものとする。
(シナリオ1の1回目の実行)
図7は、シナリオ1(実行定義(1))の1回目の実行の処理シーケンスである。この図7は、図6の場合の初期状態における各構成要素間のシーケンス図である。図7を参照して、図6の場合の初期状態の動作を説明する。
図7は、シナリオ1(実行定義(1))の1回目の実行の処理シーケンスである。この図7は、図6の場合の初期状態における各構成要素間のシーケンス図である。図7を参照して、図6の場合の初期状態の動作を説明する。
(動作の概要)
定義実行部230は、クライアント100からメッセージ処理部240を介してシナリオ1(実行定義(1))の実行要求を受信する。各画面の遷移は、フィールドへの入力+ボタン押下により実施されるものとする。
定義実行部230は、最終画面である画面P4から最初の画面P1に向かって、順次ヒストリを検索する。
1回目の実行では、セッション履歴記憶部210にはヒストリには何も保存されていないため、定義実行部230は、画面P1の処理からシナリオを実行する。図7におけるPOST要求は、画面上のテキストフィールドへのデータ入力はボタン押下による既存システムへの通信要求などを示す。
定義実行部230は、クライアント100からメッセージ処理部240を介してシナリオ1(実行定義(1))の実行要求を受信する。各画面の遷移は、フィールドへの入力+ボタン押下により実施されるものとする。
定義実行部230は、最終画面である画面P4から最初の画面P1に向かって、順次ヒストリを検索する。
1回目の実行では、セッション履歴記憶部210にはヒストリには何も保存されていないため、定義実行部230は、画面P1の処理からシナリオを実行する。図7におけるPOST要求は、画面上のテキストフィールドへのデータ入力はボタン押下による既存システムへの通信要求などを示す。
図7を具体的に説明する。
(1)クライアント100がSOAPリクエストを送信すると、メッセージ処理部240が受信する(ステップ1)。
(2)メッセージ処理部240は、SOAPリクエストからSOAPリクエストに対応するするシナリオ1を特定し、「シナリオ1についての実行要求」を定義実行部230に送信する(ステップ1.1)。
(3)定義実行部230は、実行定義記憶部270を検索してシナリオ1を取得する(ステップ1.1.1)。(4)定義実行部230は、制約定義記憶部260を検索して、シナリオ1に対応する制約定義を取得する(ステップ1.1.2)。制約定義とシナリオとは対応付けがされており、あるシナリオからは対応する制約定義を特定することができる。
(5)シナリオ1は、図6で述べたよう、画面P1→P2→P3→P4の画面遷移が定義されている。このため、定義実行部230は、最終画面である画面P4から順次、セッション履歴を検索する。上記のように、シナリオ1の最初の実行(初期状態からの実行)では、セッション履歴記憶部210にはヒストリには何も保存されていない。定義実行部230は、ヒストリ管理部220を用いて、画面P4から画面P1の全部についてセッション履歴を確認する。まず、定義実行部230は、ヒストリ管理部220に、画面P4(すなわち既存システムに接続しているとすれば、接続した際の接続状態である画面P4)があるかどうかを問い合わせる(ステップ1.1.3)。ヒストリ管理部220は、定義実行部230からの問い合わせに応答してセッション履歴記憶部210を検索する(ステップ1.1.3.1)。この場合、セッション履歴は存在しないので、ヒストリ管理部220は、定義実行部230に存在しないことを送信する。
(6)定義実行部230は、ヒストリ管理部220から画面P4のセッション履歴が存在しない通知を受けると、次に画面P3の履歴があるかどうかをヒストリ管理部220に問い合わせる(ステップ1.1.4)。以下の処理は画面P4の場合と同様である。
(7)セッション履歴記憶部210にはヒストリは何も保存されていないため、上記と同様の処理が画面P1まで繰り返される(ステップ1.1.5.1)。
(8)画面P1〜P4の全てのセッション履歴が存在しないことを知った定義実行部230は、まず、画面P1の取得要求を通信部250を介して既存システム300に送信し、画面P1を取得する(ステップ1.1.6及びステップ1.1.6.1)。定義実行部230は、取得した画面P1の保存をヒストリ管理部220に依頼する(ステップ1.1.7)。ヒストリ管理部220は、画面P1をセッション履歴記憶部210にセッション履歴として保存する(ステップ1.1.7.1)。
(9)以下、同様にして、定義実行部230は、通信部250、ヒストリ管理部220を用いて、画面P2、面P3、面P4をセッション履歴として保存する(ステップ1.1.8〜ステップ1.1.13.1)。
(1)クライアント100がSOAPリクエストを送信すると、メッセージ処理部240が受信する(ステップ1)。
(2)メッセージ処理部240は、SOAPリクエストからSOAPリクエストに対応するするシナリオ1を特定し、「シナリオ1についての実行要求」を定義実行部230に送信する(ステップ1.1)。
(3)定義実行部230は、実行定義記憶部270を検索してシナリオ1を取得する(ステップ1.1.1)。(4)定義実行部230は、制約定義記憶部260を検索して、シナリオ1に対応する制約定義を取得する(ステップ1.1.2)。制約定義とシナリオとは対応付けがされており、あるシナリオからは対応する制約定義を特定することができる。
(5)シナリオ1は、図6で述べたよう、画面P1→P2→P3→P4の画面遷移が定義されている。このため、定義実行部230は、最終画面である画面P4から順次、セッション履歴を検索する。上記のように、シナリオ1の最初の実行(初期状態からの実行)では、セッション履歴記憶部210にはヒストリには何も保存されていない。定義実行部230は、ヒストリ管理部220を用いて、画面P4から画面P1の全部についてセッション履歴を確認する。まず、定義実行部230は、ヒストリ管理部220に、画面P4(すなわち既存システムに接続しているとすれば、接続した際の接続状態である画面P4)があるかどうかを問い合わせる(ステップ1.1.3)。ヒストリ管理部220は、定義実行部230からの問い合わせに応答してセッション履歴記憶部210を検索する(ステップ1.1.3.1)。この場合、セッション履歴は存在しないので、ヒストリ管理部220は、定義実行部230に存在しないことを送信する。
(6)定義実行部230は、ヒストリ管理部220から画面P4のセッション履歴が存在しない通知を受けると、次に画面P3の履歴があるかどうかをヒストリ管理部220に問い合わせる(ステップ1.1.4)。以下の処理は画面P4の場合と同様である。
(7)セッション履歴記憶部210にはヒストリは何も保存されていないため、上記と同様の処理が画面P1まで繰り返される(ステップ1.1.5.1)。
(8)画面P1〜P4の全てのセッション履歴が存在しないことを知った定義実行部230は、まず、画面P1の取得要求を通信部250を介して既存システム300に送信し、画面P1を取得する(ステップ1.1.6及びステップ1.1.6.1)。定義実行部230は、取得した画面P1の保存をヒストリ管理部220に依頼する(ステップ1.1.7)。ヒストリ管理部220は、画面P1をセッション履歴記憶部210にセッション履歴として保存する(ステップ1.1.7.1)。
(9)以下、同様にして、定義実行部230は、通信部250、ヒストリ管理部220を用いて、画面P2、面P3、面P4をセッション履歴として保存する(ステップ1.1.8〜ステップ1.1.13.1)。
(シナリオ1の2回目の実行)
図8は、シナリオ1の2回目の実行の場合のシーケンス図である。すなわち、図8は、初期状態からシナリオ1が実行され、さらにその次に、2回目のシナリオ1の実行の場合を示すシーケンスである。
図8は、シナリオ1の2回目の実行の場合のシーケンス図である。すなわち、図8は、初期状態からシナリオ1が実行され、さらにその次に、2回目のシナリオ1の実行の場合を示すシーケンスである。
(動作の概要)
定義実行部230は、ヒストリ管理部220を介してセッション履歴を検索する。図8の例では、画面P3が制約定義に合致した場合を記述している。制約定義を満たした画面P3のセッション状態を履歴から検索し、復元することで、その時点からの処理を再開する。画面1から画面3までの画面遷移にかかる処理を省略することができる。
定義実行部230は、ヒストリ管理部220を介してセッション履歴を検索する。図8の例では、画面P3が制約定義に合致した場合を記述している。制約定義を満たした画面P3のセッション状態を履歴から検索し、復元することで、その時点からの処理を再開する。画面1から画面3までの画面遷移にかかる処理を省略することができる。
図8を具体的に説明する。
(1)クライアント100がSOAPリクエストを送信(ステップ1)してから、定義実行部230がヒストリ管理部220に画面P4の履歴があるかどうかを検索(ステップ1.1.3.1)させるまでの流れは、図7の場合と同様である。
(2)図8の場合は、シナリオ1の2回目の実行なので、画面P1〜画面P4の履歴はセッション履歴記憶部210に存在する。このため、ヒストリ管理部220は、定義実行部230に画面P4の履歴が存在することを通知する。
(3)定義実行部230は、セッション履歴として保存されている画面P4が、シナリオ1の2回目の実行に利用可能かどうかを、制約定義記憶部260から読み込んでいる制約定義と比較し判定する(ステップ1.1.4)。この例では、画面P4は、制約定義を満たさないとする。
(4)画面P4が制約定義を満たさないので、次に、定義実行部230は、画面P3の履歴があるかどうかをヒストリ管理部220に問い合わせる(ステップ1.1.5)。画面P3のセッション履歴は存在するので、ヒストリ管理部220は、定義実行部230に存在することを通知する。定義実行部230は、セッション履歴として保存されている画面P3が、シナリオ1の2回目の実行に利用可能かどうかを制約定義と比較し判定する(ステップ1.1.6)。この例では、画面P3は、制約定義を満たすとする。
(5)定義実行部230は、制約定義をみたすセッション履歴である画面P3を復元する(ステップ1.1.7)。画面P3は復元されるので、画面P3の利用に関しては、スクリーンラッピング装置200は、既存システム300と通信は不要である。
(6)シナリオ1は、画面P1〜画面P4に向かって画面遷移するので、次に、定義実行部230は、画面P4を既存システム300から取得する。すなわち、定義実行部230は、通信部250を用いて既存システム300とHTTPにて画面P4への遷移要求を実施し、2回目のシナリオ1に使用する画面P4を取得(ステップ1.1.8、ステップ1.1.8.1)し、取得した画面P4を実行する。
(7)そして、定義実行部230は、取得した画面P4の保存をヒストリ管理部220に依頼(ステップ1.1.9)し、ヒストリ管理部220は、画面P4をセッション履歴としてセッション履歴記憶部210に保存する(ステップ1.1.9.1)。以上が図8のシーケンスである。
(1)クライアント100がSOAPリクエストを送信(ステップ1)してから、定義実行部230がヒストリ管理部220に画面P4の履歴があるかどうかを検索(ステップ1.1.3.1)させるまでの流れは、図7の場合と同様である。
(2)図8の場合は、シナリオ1の2回目の実行なので、画面P1〜画面P4の履歴はセッション履歴記憶部210に存在する。このため、ヒストリ管理部220は、定義実行部230に画面P4の履歴が存在することを通知する。
(3)定義実行部230は、セッション履歴として保存されている画面P4が、シナリオ1の2回目の実行に利用可能かどうかを、制約定義記憶部260から読み込んでいる制約定義と比較し判定する(ステップ1.1.4)。この例では、画面P4は、制約定義を満たさないとする。
(4)画面P4が制約定義を満たさないので、次に、定義実行部230は、画面P3の履歴があるかどうかをヒストリ管理部220に問い合わせる(ステップ1.1.5)。画面P3のセッション履歴は存在するので、ヒストリ管理部220は、定義実行部230に存在することを通知する。定義実行部230は、セッション履歴として保存されている画面P3が、シナリオ1の2回目の実行に利用可能かどうかを制約定義と比較し判定する(ステップ1.1.6)。この例では、画面P3は、制約定義を満たすとする。
(5)定義実行部230は、制約定義をみたすセッション履歴である画面P3を復元する(ステップ1.1.7)。画面P3は復元されるので、画面P3の利用に関しては、スクリーンラッピング装置200は、既存システム300と通信は不要である。
(6)シナリオ1は、画面P1〜画面P4に向かって画面遷移するので、次に、定義実行部230は、画面P4を既存システム300から取得する。すなわち、定義実行部230は、通信部250を用いて既存システム300とHTTPにて画面P4への遷移要求を実施し、2回目のシナリオ1に使用する画面P4を取得(ステップ1.1.8、ステップ1.1.8.1)し、取得した画面P4を実行する。
(7)そして、定義実行部230は、取得した画面P4の保存をヒストリ管理部220に依頼(ステップ1.1.9)し、ヒストリ管理部220は、画面P4をセッション履歴としてセッション履歴記憶部210に保存する(ステップ1.1.9.1)。以上が図8のシーケンスである。
(シナリオ2の1回目の実行)
図9は、シナリオ2の1回目の実行の場合のシーケンス図である。過去にシナリオ1を実行したことで、ヒストリ管理部220により、画面P1〜画面P4が保存されている。一方、シナリオ2は、シナリオ1と画面P1、画面P2が共用である。従って、シナリオ2については利用可能性のあるセッション履歴として画面P2を取得できるので、画面P2が、シナリオ2に対応する制約定義に合致する場合には、そのセッション状態を復元し、処理を再開することができる。これによって画面1から画面2までの画面遷移にかかる処理を省略することができる。図9の場合は、画面P2は制約定義を満足するものとする。
図9は、シナリオ2の1回目の実行の場合のシーケンス図である。過去にシナリオ1を実行したことで、ヒストリ管理部220により、画面P1〜画面P4が保存されている。一方、シナリオ2は、シナリオ1と画面P1、画面P2が共用である。従って、シナリオ2については利用可能性のあるセッション履歴として画面P2を取得できるので、画面P2が、シナリオ2に対応する制約定義に合致する場合には、そのセッション状態を復元し、処理を再開することができる。これによって画面1から画面2までの画面遷移にかかる処理を省略することができる。図9の場合は、画面P2は制約定義を満足するものとする。
図9を具体的に説明する。
(1)図9において、クライアント100がSOAPリクエストを送信(ステップ1)してから、定義実行部230が制約定義記憶部260からシナリオ2に対応する制約定義を取得(ステップ1.1.2)するまでの処理は、図7、図8と同じである。
(2)シナリオ2は、図6で述べたよう、画面P1→P2→P5→P6の画面遷移が定義されている。このため、定義実行部230は、最終画面である画面P6から順次、セッション履歴を検索する。まず、定義実行部230は、ヒストリ管理部220に、画面P6があるかどうかを問い合わせる(ステップ1.1.3)。セッション履歴記憶部210に画面P6は保存されていないので、この後の処理は、図7の画面P1等の場合と同様である。次に定義実行部230は、ヒストリ管理部220に、画面P5があるかどうかを問い合わせるが(ステップ1.1.4)、やはり画面P5のセッション履歴も存在しないので、この後の処理は、図7の画面P1等の場合と同様である。
(3)さらに、定義実行部230は、ヒストリ管理部220に、画面P2があるかどうかを問い合わせる(ステップ1.1.5)。画面P2のセッション履歴は存在するので、ヒストリ管理部220は、定義実行部230に存在することを通知する。定義実行部230は、セッション履歴として保存されている画面P2が、シナリオ2の1回目の実行に利用可能かどうかを、シナリオ2に対応する制約定義と比較し判定する(ステップ1.1.6)。この例では、画面P2は、制約定義を満たすとする。
(5)定義実行部230は、制約定義をみたすセッション履歴である画面P2を復元する(ステップ1.1.7)。
(6)シナリオ1は、画面P1→画面P2→画面P5→画面P6に向かって画面遷移するので、次に、定義実行部230は、画面P5を既存システム300から取得する。すなわち、定義実行部230は、通信部250を用いて既存システム300とHTTPにてセッションし、1回目のシナリオ2に使用する画面P5を取得(ステップ1.1.8、ステップ1.1.8.1)し、取得した画面P5を実行する。
(7)そして、定義実行部230は、取得した画面P5の保存をヒストリ管理部220に依頼(ステップ1.1.9)し、ヒストリ管理部220は、画面P5をセッション履歴としてセッション履歴記憶部210に保存する(ステップ1.1.9.1)。
(8)さらに、定義実行部230は、画面P5と同様に、画面P6を既存システム300から取得する。画面P6についての動作は画面P5の場合と同様であるので、説明は省略する。
以上が図9のシーケンスである。
(1)図9において、クライアント100がSOAPリクエストを送信(ステップ1)してから、定義実行部230が制約定義記憶部260からシナリオ2に対応する制約定義を取得(ステップ1.1.2)するまでの処理は、図7、図8と同じである。
(2)シナリオ2は、図6で述べたよう、画面P1→P2→P5→P6の画面遷移が定義されている。このため、定義実行部230は、最終画面である画面P6から順次、セッション履歴を検索する。まず、定義実行部230は、ヒストリ管理部220に、画面P6があるかどうかを問い合わせる(ステップ1.1.3)。セッション履歴記憶部210に画面P6は保存されていないので、この後の処理は、図7の画面P1等の場合と同様である。次に定義実行部230は、ヒストリ管理部220に、画面P5があるかどうかを問い合わせるが(ステップ1.1.4)、やはり画面P5のセッション履歴も存在しないので、この後の処理は、図7の画面P1等の場合と同様である。
(3)さらに、定義実行部230は、ヒストリ管理部220に、画面P2があるかどうかを問い合わせる(ステップ1.1.5)。画面P2のセッション履歴は存在するので、ヒストリ管理部220は、定義実行部230に存在することを通知する。定義実行部230は、セッション履歴として保存されている画面P2が、シナリオ2の1回目の実行に利用可能かどうかを、シナリオ2に対応する制約定義と比較し判定する(ステップ1.1.6)。この例では、画面P2は、制約定義を満たすとする。
(5)定義実行部230は、制約定義をみたすセッション履歴である画面P2を復元する(ステップ1.1.7)。
(6)シナリオ1は、画面P1→画面P2→画面P5→画面P6に向かって画面遷移するので、次に、定義実行部230は、画面P5を既存システム300から取得する。すなわち、定義実行部230は、通信部250を用いて既存システム300とHTTPにてセッションし、1回目のシナリオ2に使用する画面P5を取得(ステップ1.1.8、ステップ1.1.8.1)し、取得した画面P5を実行する。
(7)そして、定義実行部230は、取得した画面P5の保存をヒストリ管理部220に依頼(ステップ1.1.9)し、ヒストリ管理部220は、画面P5をセッション履歴としてセッション履歴記憶部210に保存する(ステップ1.1.9.1)。
(8)さらに、定義実行部230は、画面P5と同様に、画面P6を既存システム300から取得する。画面P6についての動作は画面P5の場合と同様であるので、説明は省略する。
以上が図9のシーケンスである。
図10〜図29を参照して、以上の処理についてのデータの具体例を説明する。
(SOAPリクエストの例)
図10は、クライアント100が送信するSOAPリクエストの例を示す図である。クライアント100は、スクリーンラッピング装置200の提供するWebサービスに対して、図10に示すようなSOAPリクエストを送信する。
図10は、クライアント100が送信するSOAPリクエストの例を示す図である。クライアント100は、スクリーンラッピング装置200の提供するWebサービスに対して、図10に示すようなSOAPリクエストを送信する。
(シナリオ定義例)
図11、図12は、実行定義記憶部270に記憶されるシナリオ(実行定義)の一例を示す図である。図12は、図11の続きの部分である。定義実行部230は、クライアント100からの図11、図12のSOAPリクエストに対応するシナリオ(実行)を、実行定義記憶部270から取得する。
(1)シナリオでは、INPUT要素にてSOAPメッセージに格納されるパラメータを定義する。本例ではSOAP BODY内の要素名と型によって指定している。
(2)OUTPUT要素にて、最終画面から戻り値を抽出するためのルールを定義する。図11、図12の例では、XPATH(XML Path Language)を用いて、最終画面から必要なデータを抽出する。XSLT(XML Stylesheet Language Transformations)、XQueryなどの方式を用いてもよい。
(3)また、SEQUENCE要素から既存システムと連携する手続きを記述する。定義実行部230は、上位に記述されたものから順次実施し、GET要素は指定されたURLに対してHTTP GETにより接続する処理を行う。ASSIGN要素は画面に対する入力を指定し、変数から画面の入力フィールド、またはその逆の入力処理を実施する。WAIT要素は、画面タイトルや特定の位置に表示される文字列などから、画面遷移が完了したことを確認(遷移が完了するまで待機)する。遷移が完了した時点でヒストリ管理部に対して、セッション状態の保存を要求する。セッション状態のほかに、シナリオで定義される変数なども合わせて保存し、制約定義として利用することができる。保存の実施有無は、WAIT要素の属性として指定してもよい。
図11、図12は、実行定義記憶部270に記憶されるシナリオ(実行定義)の一例を示す図である。図12は、図11の続きの部分である。定義実行部230は、クライアント100からの図11、図12のSOAPリクエストに対応するシナリオ(実行)を、実行定義記憶部270から取得する。
(1)シナリオでは、INPUT要素にてSOAPメッセージに格納されるパラメータを定義する。本例ではSOAP BODY内の要素名と型によって指定している。
(2)OUTPUT要素にて、最終画面から戻り値を抽出するためのルールを定義する。図11、図12の例では、XPATH(XML Path Language)を用いて、最終画面から必要なデータを抽出する。XSLT(XML Stylesheet Language Transformations)、XQueryなどの方式を用いてもよい。
(3)また、SEQUENCE要素から既存システムと連携する手続きを記述する。定義実行部230は、上位に記述されたものから順次実施し、GET要素は指定されたURLに対してHTTP GETにより接続する処理を行う。ASSIGN要素は画面に対する入力を指定し、変数から画面の入力フィールド、またはその逆の入力処理を実施する。WAIT要素は、画面タイトルや特定の位置に表示される文字列などから、画面遷移が完了したことを確認(遷移が完了するまで待機)する。遷移が完了した時点でヒストリ管理部に対して、セッション状態の保存を要求する。セッション状態のほかに、シナリオで定義される変数なども合わせて保存し、制約定義として利用することができる。保存の実施有無は、WAIT要素の属性として指定してもよい。
(制約定義)
図13〜図16は、制約定義の例を示す図である。これらの図を参照して制約定義を説明する。定義実行部230は、制約定義記憶部260からシナリオに対応する制約定義を取得する。
(1)図13は、FORM要素をシナリオに登場する画面にあわせて設定している(利用不可の画面は省略してもよい)。どの画面に対応するかはuri属性にて指定し、シナリオのWAIT要素のId属性に対応する。Available属性によって、ヒストリとして復元し、再利用していいかどうかを指定する。上記の例ではP4で指定される画面は再利用不可であり、P4までの画面遷移は毎回実行しないといけない。P3、P2、P1で指定される画面はヒストリにあれば再利用可能である。単にセッション履歴に対してセッション情報があるか/ないかだけでなく、変数のユーザIDが一致するなら利用可能である場合や、リクエスト日がヒストリへの保存日と同じ日にちならば利用可能などの指定を行うには、form要素の子要素に付加情報を設定する。
(2)図14は、P3画面がヒストリに存在し、UserIdの変数がヒストリ内の情報と今回のリクエストとで一致すれば利用可能な定義の例を示している。CONDITION要素にて変数および一致/不一致/範囲指定などの条件を指定する。
(3)図15は、P3画面がヒストリに存在し、保存日とリクエスト日が一致すれば利用可能な定義の例を示している。変数以外の予約語として「@・・・」で記述している。
(4)図16は、P3画面がヒストリに存在し、かつP2,P1画面もヒストリに存在する場合に利用可能な定義の例示している。DEPENDS要素にて、依存関係のある画面を指定する。
図13〜図16は、制約定義の例を示す図である。これらの図を参照して制約定義を説明する。定義実行部230は、制約定義記憶部260からシナリオに対応する制約定義を取得する。
(1)図13は、FORM要素をシナリオに登場する画面にあわせて設定している(利用不可の画面は省略してもよい)。どの画面に対応するかはuri属性にて指定し、シナリオのWAIT要素のId属性に対応する。Available属性によって、ヒストリとして復元し、再利用していいかどうかを指定する。上記の例ではP4で指定される画面は再利用不可であり、P4までの画面遷移は毎回実行しないといけない。P3、P2、P1で指定される画面はヒストリにあれば再利用可能である。単にセッション履歴に対してセッション情報があるか/ないかだけでなく、変数のユーザIDが一致するなら利用可能である場合や、リクエスト日がヒストリへの保存日と同じ日にちならば利用可能などの指定を行うには、form要素の子要素に付加情報を設定する。
(2)図14は、P3画面がヒストリに存在し、UserIdの変数がヒストリ内の情報と今回のリクエストとで一致すれば利用可能な定義の例を示している。CONDITION要素にて変数および一致/不一致/範囲指定などの条件を指定する。
(3)図15は、P3画面がヒストリに存在し、保存日とリクエスト日が一致すれば利用可能な定義の例を示している。変数以外の予約語として「@・・・」で記述している。
(4)図16は、P3画面がヒストリに存在し、かつP2,P1画面もヒストリに存在する場合に利用可能な定義の例示している。DEPENDS要素にて、依存関係のある画面を指定する。
(HTTP通信)
図17〜図28を参照して、既存システム300とスクリーンラッピング装置200との間のHTTP通信の例を以下に示す。
(1)ログイン画面への接続:
図17は、ログイン画面への接続におけるHTTPリクエストの例である。また図18は、HTTPレスポンスの例である。また、図19は、ブラウザにて表示した場合のイメージを示す図である。
(2)ログイン処理(初期画面への遷移):
図20は、ログイン処理(初期画面への遷移)におけるHTTPリクエストの一例を示す図である。ユーザID,パスワードは、SOAPリクエストにおいて指定されたものを利用する。図21は、図20のHTTPリクエストへのHTTPレスポンスの例を示す図である。また、図22は、ブラウザにて表示した場合のイメージを示す図である。
(3)検索実行(一覧画面への遷移):
図23は、検索実行(一覧画面への遷移)におけるHTTPリクエストの例である。検索キーワードは、SOAPリクエストに指定されたものを利用する。また、図24は、このHTTPリクエストに対するHTTPレスポンスの例である。また、図25は、ブラウザにて表示した場合のイメージを示す図である。
(4)詳細表示(詳細画面への遷移):
図26は、詳細表示(詳細画面への遷移)におけるHTTPリクエストの例である。また、図27は、このHTTPリクエストに対するHTTPレスポンスの例である。また、図28は、ブラウザにて表示した場合のイメージを示す図である。
図17〜図28を参照して、既存システム300とスクリーンラッピング装置200との間のHTTP通信の例を以下に示す。
(1)ログイン画面への接続:
図17は、ログイン画面への接続におけるHTTPリクエストの例である。また図18は、HTTPレスポンスの例である。また、図19は、ブラウザにて表示した場合のイメージを示す図である。
(2)ログイン処理(初期画面への遷移):
図20は、ログイン処理(初期画面への遷移)におけるHTTPリクエストの一例を示す図である。ユーザID,パスワードは、SOAPリクエストにおいて指定されたものを利用する。図21は、図20のHTTPリクエストへのHTTPレスポンスの例を示す図である。また、図22は、ブラウザにて表示した場合のイメージを示す図である。
(3)検索実行(一覧画面への遷移):
図23は、検索実行(一覧画面への遷移)におけるHTTPリクエストの例である。検索キーワードは、SOAPリクエストに指定されたものを利用する。また、図24は、このHTTPリクエストに対するHTTPレスポンスの例である。また、図25は、ブラウザにて表示した場合のイメージを示す図である。
(4)詳細表示(詳細画面への遷移):
図26は、詳細表示(詳細画面への遷移)におけるHTTPリクエストの例である。また、図27は、このHTTPリクエストに対するHTTPレスポンスの例である。また、図28は、ブラウザにて表示した場合のイメージを示す図である。
(SOAPレスポンス)
図29は、(SOAPレスポンス)の例を示す図である。最終画面から、戻り値の抽出ルールに従って作成したSOAPレスポンスの例を示している。
図29は、(SOAPレスポンス)の例を示す図である。最終画面から、戻り値の抽出ルールに従って作成したSOAPレスポンスの例を示している。
以上説明したように、実施の形態1のスクリーンラッピング装置200は、保存したセッション履歴(接続状態)を復元し、その時点から処理を再開することができるので、クライアント100から処理要求に対して、処理の高速化、効率化を図ることができる。また、実施の形態1のスクリーンラッピング装置200は、複数のシナリオ(実行定義)を実施する際に、どの実行定義からもセッション履歴を共有して利用できる構成としている。すなわち、図9で述べたように、シナリオ1のセッション履歴である画面P2を、シナリオ2も利用できる構成としているので、更なる処理の高速化、効率化を図ることができる。
以上の実施の形態1では、クライアントからのリクエストに対して既存システムとの連携を実行定義に従い実施するとともに、既存システムとの接続状態を履歴情報として保存することを特徴とするスクリーンラッピングシステムを説明した。
以上の実施の形態1では、保存した接続状態を復元し、その時点から処理を再開することで、処理の高速化、効率化を行うことを特徴とするスクリーンラッピングシステムを説明した。
以上の実施の形態1では、複数の実行定義を実施する際に、どの実行定義からも履歴情報を共有して利用できることを特徴とするスクリーンラッピングシステムを説明した。
以上の実施の形態1では、実行定義、制約定義および履歴情報(セッション履歴)から、過去において実行定義に基づき実施した処理を省略し、処理の効率化を実現できる再開ポイントを自動判別することを特徴とするスクリーンラッピングシステムを説明した。
以上の実施の形態1で説明したスクリーンラッピングシステムは、
スクリーンラッピング装置に対するリクエストを作成するクライアントと、
クライアントからのリクエストを受信するメッセージ処理部、リクエストに対応する実行定義(シナリオ)を抽出し、実行定義、セッション履歴、制約定義情報から処理を再開するセッション履歴を判別し、セッションを復元し、再開ポイントからシナリオを実行する定義実行部、
セッション履歴を管理するヒストリ管理部、
既存システムに対する通信を管理する通信処理部を備えたスクリーンラッピング装置と、
クライアントに対してHTTP画面などのI/Fを提供する既存システムを備え、
クライアントにセッション履歴の状態や再開ポイントを意識させることなく、シナリオ間で履歴情報を共有し、最適な再開ポイントを自動判別することで、不要な処理をスキップし、効率的な処理を実現することを特徴とするものである。
スクリーンラッピング装置に対するリクエストを作成するクライアントと、
クライアントからのリクエストを受信するメッセージ処理部、リクエストに対応する実行定義(シナリオ)を抽出し、実行定義、セッション履歴、制約定義情報から処理を再開するセッション履歴を判別し、セッションを復元し、再開ポイントからシナリオを実行する定義実行部、
セッション履歴を管理するヒストリ管理部、
既存システムに対する通信を管理する通信処理部を備えたスクリーンラッピング装置と、
クライアントに対してHTTP画面などのI/Fを提供する既存システムを備え、
クライアントにセッション履歴の状態や再開ポイントを意識させることなく、シナリオ間で履歴情報を共有し、最適な再開ポイントを自動判別することで、不要な処理をスキップし、効率的な処理を実現することを特徴とするものである。
このスクリーンラッピングシステムにより、過去に実施した処理をスキップすることで、ラッピング処理の高速化、効率化を実現することが可能となる。
1000 スクリーンラッピングシステム、100 クライアント、200 スクリーンラッピング装置、210 セッション履歴記憶部、220 ヒストリ管理部、230 定義実行部、240 メッセージ処理部、250 通信部、260 制約定義記憶部、270 実行定義記憶部、280 実行保存部、300 既存システム。
Claims (5)
- 他の装置と第1プロトコルで通信を行なう所定のシステム装置を対象とするセッション要求であって、前記第1プロトコルとは異なる第2プロトコルによるセッション要求を受信するセッション要求受信部と、
前記セッション要求受信部が受信する前記セッション要求に対応し、かつ、前記所定のシステム装置に対するセッションが定義された実行定義を記憶する実行定義記憶部と、
情報を記憶する情報記憶部と、
前記セッション要求受信部が前記セッション要求を受信すると、受信された前記セッション要求に対応する前記実行定義に基づいて前記第1プロトコルにより前記所定のシステム装置との間でセッションを実行するとともに、実行したセッションにおける前記所定のシステム装置との接続状態を、前記所定のシステム装置と接続することなく復元可能な履歴情報として前記情報記憶部に保存する実行保存部と
を備えたことを特徴とするセッション実行装置。 - 前記セッション実行装置は、さらに、
前記実行定義に対応し、かつ、前記履歴情報が前記実行定義に定義されたセッションに利用可能かどうかが定義された制約定義を記憶する制約定義記憶部を備え、
前記実行保存部は、
前記セッション要求受信部が前記セッション要求を受信すると対応する前記実行定義を参照することにより前記実行定義に定義されたセッションに対応する前記履歴情報が前記情報記憶部に保存されているかどうかを判定し、保存されていると判定すると対応する前記制約定義を参照することにより前記履歴情報が前記実行定義に定義されたセッションに利用可能かどうかを判定し、利用可能と判定すると前記履歴情報の示す前記接続状態を復元し、復元した接続状態から前記実行定義に定義されたセッションを開始することを特徴とする請求項1記載のセッション実行装置。 - 前記セッション要求受信部は、
複数の前記セッション要求を受信し、
前記実行定義記憶部は、
複数の前記セッション要求のそれぞれに対応する複数の前記実行定義を記憶していることを特徴とする請求項1または2のいずれかに記載のセッション実行装置。 - コンピュータを
第1プロトコルで通信を行なう所定のシステム装置を対象とするセッション要求であって、前記第1プロトコルとは異なる第2プロトコルによるセッション要求を受信するセッション要求受信部、
前記セッション要求受信部が受信する前記セッション要求に対応し、かつ、前記所定のシステム装置に対するセッションが定義された実行定義を記憶する実行定義記憶部、
情報を記憶する情報記憶部、
前記セッション要求受信部が前記セッション要求を受信すると、受信された前記セッション要求に対応する前記実行定義に基づいて前記第1プロトコルにより前記所定のシステム装置との間でセッションを実行するとともに、実行したセッションにおける前記所定のシステム装置との接続状態を、履歴情報として前記情報記憶部に記憶する実行保存部
として機能させることを特徴とするセッション実行プログラム。 - 請求項4のセッション実行プログラムを記録したコンピュータ読み取り可能な記録媒体。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2008036083A JP2009193512A (ja) | 2008-02-18 | 2008-02-18 | セッション実行装置及びセッション実行プログラム及び記録媒体 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2008036083A JP2009193512A (ja) | 2008-02-18 | 2008-02-18 | セッション実行装置及びセッション実行プログラム及び記録媒体 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2009193512A true JP2009193512A (ja) | 2009-08-27 |
Family
ID=41075443
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2008036083A Pending JP2009193512A (ja) | 2008-02-18 | 2008-02-18 | セッション実行装置及びセッション実行プログラム及び記録媒体 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2009193512A (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2012117950A1 (ja) * | 2011-03-01 | 2012-09-07 | 日本電気株式会社 | 履歴管理装置、システム、方法およびプログラム |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH11149450A (ja) * | 1997-11-19 | 1999-06-02 | Nec Corp | トランザクションエージェントシステム |
JP2002334058A (ja) * | 2001-05-10 | 2002-11-22 | Beacon Information Technology:Kk | メインフレームのアプリケーション実行方法、アプリケーション実行システム、プログラム |
JP2004246747A (ja) * | 2003-02-17 | 2004-09-02 | Hitachi Ltd | 既存サービスのラッピング方法および装置 |
-
2008
- 2008-02-18 JP JP2008036083A patent/JP2009193512A/ja active Pending
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH11149450A (ja) * | 1997-11-19 | 1999-06-02 | Nec Corp | トランザクションエージェントシステム |
JP2002334058A (ja) * | 2001-05-10 | 2002-11-22 | Beacon Information Technology:Kk | メインフレームのアプリケーション実行方法、アプリケーション実行システム、プログラム |
JP2004246747A (ja) * | 2003-02-17 | 2004-09-02 | Hitachi Ltd | 既存サービスのラッピング方法および装置 |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2012117950A1 (ja) * | 2011-03-01 | 2012-09-07 | 日本電気株式会社 | 履歴管理装置、システム、方法およびプログラム |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
KR100705411B1 (ko) | 로컬 컴퓨터 검색 시스템 및 이를 이용한 로컬 컴퓨터 검색방법 | |
US8230336B2 (en) | Efficient discovery, display, and autocompletion of links to wiki resources | |
US9459888B2 (en) | Implementing browser based hypertext transfer protocol session storage | |
US11265394B2 (en) | Systems and methods for a bidirectional multi-function communication module | |
JP2006172442A (ja) | インターネットベースおよびローカルのヘルプコンテンツ用の統合クライアントヘルプビューア | |
US20110191431A1 (en) | Method and system for updating display screens | |
JP2009003802A (ja) | 情報表示装置及び情報表示方法 | |
JP2007149074A (ja) | コンテキスト・ベースのナビゲーション | |
US20090172107A1 (en) | Proxy content for submitting web service data in the user's security context | |
US8271582B2 (en) | Relay device, relay method, and computer program product | |
US20180321984A1 (en) | Virtual graph nodes | |
US9846605B2 (en) | Server-side minimal download and error failover | |
US20110035433A1 (en) | Webpage display method, computer system, and program | |
US8332377B2 (en) | Method for controlling search controller and system thereof | |
JP5398270B2 (ja) | 管理装置、ログ処理方法及びプログラム | |
CN109428872B (zh) | 数据传输方法、设备、服务器及启动方法、系统 | |
CN102004729A (zh) | 一种网站网页的展现方法、系统及网站服务器 | |
JP2009031960A (ja) | クライアント装置およびサーバ装置の間の通信を中継する技術 | |
JP5703352B2 (ja) | アプリケーションシステム、携帯端末、サーバコンピュータおよびコンピュータプログラム | |
JP2009193512A (ja) | セッション実行装置及びセッション実行プログラム及び記録媒体 | |
US8402367B1 (en) | Smart reload pages | |
US8127026B2 (en) | User operation acting device, user operation acting program, and computer readable recording medium | |
JP2007272443A (ja) | 開発支援装置、開発支援方法および開発支援プログラム | |
JP2009122985A (ja) | サブプロセス実行システム及びサブプロセス実行プログラム | |
JP3979021B2 (ja) | WebアプリケーションサーバとWebアプリケーションサーバシステムおよびWebページデータ処理方法ならびにプログラム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20101203 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20130118 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20130212 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20130611 |