(57)【要約】【課題】  アプリケーション作業で、再開時の端末の種類が中断時と異なっていてもアプリケーション処理中断後の継続を可能にするセッション管理装置を得る。【解決手段】  共通アクション検査部により、実行エンジンで動作させたアクションが共通アクションかどうかを検査し、検出された共通アクションを共通アクション記憶部に記憶し、状態遷移図選択部により、入力される端末の種類に応じて状態遷移図を状態遷移図記憶部から選択し、再開処理部が、共通アクション記憶部の情報を基に、アプリケーション処理中断後の再開時状態遷移図上で開始状態を特定するようにした。【選択図】        図１
2005208759.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションの振る舞いを定義した状態遷移図を、端末の種類に応じてそれぞれ記憶する状態遷移図記憶部と、
状態遷移に応じて実行されるアクションを記憶するアクション記憶部と、
アプリケーションの進行状況を示すセッション情報を保存するセッション情報記憶部と、
アプリケーションで利用する変数を記憶するアプリケーションデータ記憶部と、
端末からの入力情報とセッション情報と状態遷移図から、現在状態と遷移および次の状態を特定し、アプリケーションデータを用いて遷移に関連付けられたアクションを動作させ、次の状態に基づき端末に情報を出力する実行エンジンとを備えたセッション管理装置において、
前記実行エンジンで動作させたアクションが共通アクションかどうかを検査する共通アクション検査部と、
検出された共通アクションを記憶する共通アクション記憶部と、
入力される端末の種類に応じて前記状態遷移図記憶部から状態遷移図を選択する状態遷移図選択部と、
前記共通アクション記憶部の情報を基に、アプリケーション処理中断後の再開時状態遷移図上で開始状態を特定する再開処理部と
を備えたことを特徴とするセッション管理装置。
【請求項２】
実行エンジンが共通アクションを動作させた履歴を記憶する履歴記憶部と、
前記履歴を前記履歴記憶部に保存する履歴保存処理部とを備え、
再開処理部が、前記履歴記憶部に保存された共通アクションの情報を基に、アプリケーション処理中断後の再開時状態遷移図上で開始状態を特定するようにしたことを特徴とする請求項１記載のセッション管理装置。
【請求項３】
アクション記憶部に記憶された実行したアクション情報に基づいて、既に実行したアクションの処理を取り消すロールバック処理部を備えたことを特徴とする請求項１または請求項２記載のセッション管理装置。
【請求項４】
状態遷移図記憶部から一意に識別できないアクションを含む状態遷移図を検出するアクション一意性検査処理手段、状態遷移図記憶部から共通アクションを一つも含まない状態遷移図を検出する共通アクション有無検査処理手段、状態遷移図記憶部から共通アクションの実行順序が一致しない状態遷移図の組を検出する共通アクション順序検査処理手段のうちの少なくとも１つを備えたことを特徴とする請求項１から請求項３のうちのいずれか１項記載のセッション管理装置。
【請求項５】
共通アクション検査部は、実行エンジンで実行したアクションがＷｅｂサービス呼び出しを行うものであって、かつ状態遷移図から抽出されたＷｅｂサービス呼び出しの他のアクションと、サービス定義の内容およびＷｅｂサービスの接続先が等しい場合に共通アクションとして検出することを特徴とする請求項１から請求項３のうちのいずれか１項記載のセッション管理装置。
【請求項６】
共通アクション検査部が、リレーショナルデータベースへの問い合わせ文および接続先情報を用いて共通アクションを検出するようにしたことを特徴とする請求項１から請求項３のうちのいずれか１項記載のセッション管理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、クライアント端末の種類に応じて異なる画面フローを提供するアプリケーションにおいて、アプリケーション中断後の再開示時に、異なる種類のクライアント端末での処理の継続を図るセッション管理装置に関するものである。
【背景技術】
【０００２】
クライアント端末に画面および画面フローを提供するアプリケーションにおいて、従来、アプリケーションの進行状況を示す状態情報を、エンド・ユーザ識別子と関連付けてリポジトリに保存しておき、２度目にエンド・ユーザがクライアントを介して自分の識別子をサーバに送信すると、保存された状態情報に基づいてトランザクションの進行を再開する方法を用い、クライアント毎に画面は異なるが、画面フローは同一なアプリケーションにおいては、異なる種類のクライアント端末間で処理の引継ぎを可能にするセッション管理装置があった（例えば、特許文献１参照。）。
【０００３】
【特許文献１】特表２００１−５２５５７４号公報（図２）
【発明の開示】
【発明が解決しようとする課題】
【０００４】
従来のセッション管理装置は、以上のように構成されているが、ＰＣ用にはＰＣ用状態遷移図、携帯端末用には携帯端末用状態遷移図というように、クライアント端末の表示能力に応じて異なる画面フローを提供するアプリケーションにおいて、作業を中断後、中断時と異なる種類のクライアント端末を用いて作業を再開する場合には、中断時状態遷移図と再開時状態遷移図が異なるため、再開時状態遷移図のどの状態を再開時状態とするかを決定する方法がなかった。したがって、複数の異なる種類のクライアント端末間で中断後の処理の継続を行うことができないという問題があった。
【０００５】
この発明は、上記問題点を解決するためになされたもので、アプリケーション作業で、再開時の端末の種類が中断時と異なっていてもアプリケーション処理中断後の継続を可能にするセッション管理装置を得ることを目的とする。
【課題を解決するための手段】
【０００６】
この発明に係るセッション管理装置は、アプリケーションの振る舞いを定義した状態遷移図を、端末の種類に応じてそれぞれ記憶する状態遷移図記憶部と、状態遷移に応じて実行されるアクションを記憶するアクション記憶部と、アプリケーションの進行状況を示すセッション情報を保存するセッション情報記憶部と、アプリケーションで利用する変数を記憶するアプリケーションデータ記憶部と、端末からの入力情報とセッション情報と状態遷移図から、現在状態と遷移および次の状態を特定し、アプリケーションデータを用いて遷移に関連付けられたアクションを動作させ、次の状態に基づき端末に情報を出力する実行エンジンとを備えたセッション管理装置において、実行エンジンで動作させたアクションが共通アクションかどうかを検査する共通アクション検査部と、検出された共通アクションを記憶する共通アクション記憶部と、入力される端末の種類に応じて状態遷移図記憶部から状態遷移図を選択する状態遷移図選択部と、共通アクション記憶部の情報を基に、アプリケーション処理中断後の再開時状態遷移図上で開始状態を特定する再開処理部とを備えたものである。
【発明の効果】
【０００７】
この発明によれば、実行エンジンがアクションを動作させる際に、共通アクション検査部で検出し共通アクション記憶部に記憶した共通アクションを基に、端末からの入力に応じて状態遷移図選択部が選択した状態遷移図上で、再開処理部が再開時開始状態を特定できるので、再開時の端末の種類が中断時と異なっていてもアプリケーション処理中断後の継続を可能にする効果がある。
【発明を実施するための最良の形態】
【０００８】
実施の形態１．
図１はこの発明の実施の形態１によるセッション管理装置の機能構成を示すブロック図である。図において、アプリケーションデータ記憶部１０１は、アプリケーションの変数を記憶する手段である。アクション記憶部１０２は、状態遷移において実行されるアクションを記憶する手段である。セッション情報記憶部１０３は、アプリケーションの進行状況を示すセッション情報を記憶する手段である。状態遷移図記憶部１０４は、アプリケーションの振る舞いを定義した状態遷移図を、端末の種類に応じてそれぞれ記憶する手段である。状態遷移図選択部１０５は、端末の種類に応じて状態遷移図記憶部１０４から適切な状態遷移図を選択する手段である。共通アクション検査部１０６は、アクションの識別子を受け取り、そのアクションが状態遷移図間で共通に使用される共通アクションかどうかを検査する手段である。共通アクション記憶部１０７は、共通アクション検査部１０６が検出した共通アクションの識別子を記憶する手段である。再開処理部１０８は、共通アクション記憶部１０７に含まれる共通アクションの情報に基づきアプリケーション再開時に開始すべき状態を特定する手段である。実行エンジン１０９は、端末からの入力情報とセッション情報と状態遷移図から、現在状態と遷移および次の状態を特定し、遷移に関連付けられたアクションをアプリケーションデータを用いて動作させ、次の状態に基づき端末に情報を出力する手段である。
【０００９】
図２に図１の機能構成部を形成するハードウェア構成を示す。ＰＣ上に本セッション管理装置を実現する。ＰＣは内に記憶装置２０１と制御装置２０３を備える。また、便宜上端末としても使えるように、出力装置２０２および入力装置２０４も備える。アプリケーションデータ記憶部１０１、アクション記憶部１０２、セッション情報記憶部１０３、状態遷移図記憶部１０４および共通アクション記憶部１０７は記憶装置２０１上に置かれる。記憶装置２０１は、ハードディスクドライブ等で実現される。また、状態遷移図選択部１０５、共通アクション検査部１０６、再開処理部１０８および実行エンジン１０９は、ソフトウェアプログラムとして記憶装置２０１上に置かれ、制御装置２０３が実行する。表示装置２０２は、ＣＲＴ、液晶表示装置等である。入力手段２０４としてマウスやキーボードを備える。マウスの代わりに、位置入力装置、例えばトラックボール、タッチパッド、タッチスクリーンなどを適用してもよく。また、キーボードの代りに文字入力装置、例えばペン装置などを用いてもよい。
【００１０】
図３はこの実施の形態１のセッション管理装置３０２が適用される全体のシステム構成例を示すブロック図である。
システムは、セッション管理装置３０２、ＰＣ３０３、携帯電話３０４および携帯端末３０５がネットワーク３０１で接続された構成を有する。ＰＣ３０３はクライアントを搭載しており、携帯電話３０４および携帯端末３０５はＷＷＷ（World Wide Web）ブラウザ機能を持っている。セッション管理装置３０２はサーバであるＰＣに搭載されている。また、このサーバは、ＷＷＷブラウザをクライアントとして用いるために、ＨＴＴＰ（Hyper Text Transfer Protocol）を扱うＷＷＷサーバ、およびＪＳＰ（JavaServer Pages（登録商標））を展開する機能を持つサーブレットエンジンを搭載する。クライアント１，２，３は、サーバに要求を行う端末上のプログラムであり、ＰＣ３０３、携帯電話３０４、携帯端末３０５、その他のハードウェア装置上で動作するソフトウェア、ミドルウェアあるいはファームウェアである。クライアント１，２，３は、具体的な例としては、ＧＵＩ（Graphical User Interface）プログラム、ＷＷＷブラウザ、ＸＭＬ（eXtensible Markup Language）ビューア等である。なお、サーバおよびクライアントプログラムは同じＰＣ上にあってもよい。また、ＷＷＷブラウザ機能を備えた携帯電話３０４、携帯端末３０５は一般に入手可能なものでよい。複数の異なる種類のクライアントを用いる場合、それらの描画能力、例えば表示可能な画面領域の大きさ、フォントの種類、表現できる色および解釈可能な描画命令の形式等はそれぞれ異なる。
【００１１】
図４にアプリケーションデータ記憶部１０１のデータ構造例を示す。アプリケーションデータ記憶部１０１に記憶するデータは、アプリケーションの変数であり、変数名と変数値の組から構成される。変数には、ユーザ固有のものと、アプリケーション全体に共通のものとがある。ユーザに固有の変数については、ユーザを識別できるユーザＩＤ（Identifier）に関連づけて変数を記憶する。また、アプリケーション全体に共通な変数については、特別なユーザＩＤ”Ｓｙｓｔｅｍ”に関連づけて記憶する。アプリケーションデータとしては、例えば現在の状態情報を格納する変数、ユーザの入力を格納する変数、アクションの入出力値を格納する変数などがある。実行エンジン１０９の処理により、アクションが実行された場合などに、アプリケーションデータの値は更新される。アプリケーションデータの変数値は、記憶装置上に記憶可能な形式のデータであり、例えばオブジェクト指向プログラムにおけるオブジェクト、記憶領域のアドレス、構造体、文字列、ファイル識別子、数値などが使用できる。アプリケーションデータ記憶部１０１では、変数名と変数値は、プレーンテキストの形式で記憶する。あるいは、ＸＭＬ（eXtensible Markup Language）形式、ＣＳＶ（Comma Separated Value）形式など構造を持つ記憶形式で記憶されていても構わない。
【００１２】
図５にアクション記憶部１０２のデータ構造例を示す。アクションは、アクションＩＤで識別される。入力、出力のあるアクションにはそれぞれ入力、出力のための変数をとることができる。アクション記憶部１０２には、アクションの実体であるプログラムコード、アクションの入力および出力に結び付けられたアプリケーションデータの変数名が、アクションＩＤに関連づけて記憶される。アプリケーションコードが空の場合、そのアクションはなにも実行しない。以降、空であることを図中では横線で示す。なお、なにも実行しないアクションをダミーアクションと呼ぶ。ダミーアクションは、そのアクションＩＤが”ｄｕｍｍｙ”で始まる。
【００１３】
ここで用いられるプログラムコードは、プログラムインタプリタが解釈可能な言語で記述されたプログラムコードや機械語形式のプログラムコードなど、ＰＣ上の制御装置２０３が実行できるコードである。これらのデータは、プレーンテキストの形式で記憶される（プレーンテキストとして直接扱えない機械語形式のコードは、プレーンテキスト形式に変換した上で記憶する）。あるいはＸＭＬ形式、ＣＳＶ形式などの記憶形式で記憶されていても構わない。
アクションは、データベースからのデータ取得、Ｗｅｂ（World Wide Web）サービスへの問い合わせ、アプリケーションプログラムの関数呼び出し等、状態遷移表上での遷移に伴って実行されるプログラムである。アクションの粒度は、例えばアプリケーションデータの変数値を変更する機械語コードの一つのような小粒度のものであってもよいし、ＷＷＷを介して旅行会社に問い合わせ、希望の旅行プランを選択し、飛行機を予約し、チケットを購入するといった一連のビジネスプロセスを実現する大粒度のものであってもよい。
【００１４】
図６にセッション情報記憶部１０３のデータ構造例を示す。セッション情報は、ユーザを識別できるユーザＩＤ、最後に実行されたアクションのアクションＩＤから構成される。セッション情報記憶部１０３は、セッション情報を、セッションを識別できるセッションＩＤに関連付けて格納する。これらのデータは、プレーンテキストの形式で記憶する。あるいはＸＭＬ形式、ＣＳＶ形式など構造を持つ記憶形式で記憶されていても構わない。
【００１５】
図７に状態遷移図記憶部１０４のデータ構造例を示す。状態遷移図記憶部１０４には、クライアントの種類に応じて定義された状態遷移図が、クライアントの種類を識別できる端末ＩＤに関連づけて記憶される。端末ＩＤとして、一般的なＷＷＷブラウザが処理要求送信時に送信するＵｓｅｒ−Ａｇｅｎｔ属性を使用する。また別途、状態遷移図記憶部１０４は、画面定義を記憶する領域を備える。一つの画面定義は、ファイルシステム上の一つのファイルとして記憶される。画面定義とは、クライアントの表示装置上にアプリケーションの表示画面を描画するための一連の描画命令を定義したものである。なお、図７で示した例では、端末ＩＤと状態遷移図が１対１の関係にあるが、これが多対１であっても構わない。状態遷移図記憶部１０４のデータ構造は、プレーンテキストの形式で記憶する。記憶形式は、ＸＭＬ形式やＣＳＶ形式等であってもよい。
【００１６】
図８にＰＣ用ＷＷＷブラウザ向け状態遷移図の例を、また図９に携帯電話用ＷＷＷブラウザ向け状態遷移図の例を示す。状態遷移図は、各列が状態を識別できる状態ＩＤに対応しており、各行が発生するイベントを識別できるイベントＩＤに対応している。表内の各セルは、その列が示す状態において、行が示すイベントが起きた際に評価される遷移が示されている。遷移は、ガード条件、ターゲット状態およびアクションから構成される。ガード条件は”［  ］”括弧で括られた論理式である。また、ターゲット状態およびアクションは、横線で区切って記述され、横線の上側が遷移先状態の状態ＩＤを、下側がその遷移が発火される際に実行されるアクションのアクションＩＤを示している。遷移の際に特にアクションを実行しない場合は、何も実行しないアクションを示すダミーアクションを定義する。なお、アクションＩＤは各状態遷移図上で一意である。状態遷移図の最下行には、その状態に対応した画面定義のファイルのファイル名を定義する。対応する画面定義を定義しない場合は、ファイル名を空とする。
【００１７】
遷移が評価される際には、まずガード条件が評価され、ガード条件が真の場合は遷移が発火する。すなわち、アクションを実行した上で、ターゲット状態に遷移する。ガード条件が偽の場合は、遷移は発火しない。なお、状態に結び付けられている遷移が複数ある場合、遷移図の上から順に遷移を評価し、遷移が発火した時点で評価を終了する。したがって、複数の遷移が同時に発火することはない。また、イベントＩＤが空の遷移は、イベントに依らずに評価される。ガード条件は定義しなくてもよく、定義されていない場合は、常にガード条件が真であるとみなされる。斜線は、そのイベントによる遷移が定義されていないことを示す。状態遷移図の記憶形式としては、プレーンテキスト形式を使用する。あるいはＸＭＬ形式、ＣＳＶ形式などであってもよい。
【００１８】
図１０にＪＳＰ形式による画面定義の例を示す。この画面定義は前記サーブレットエンジンによりＨＴＭＬ（Hyper Text Markup Language）に変換されてＷＷＷサーバを介して出力され、クライアントであるＰＣ用ＷＷＷブラウザ上で表示画面を構成する。本画面定義の８行目では、”ログイン”というタイトルを表示することを定義している。１３〜１４行目では、ユーザの名前を入力するテキストボックスを表示すること、ユーザの名前をアプリケーションデータの変数ｕｓｅｒＩＤに代入することを示している。同様に１６〜１７行目ではユーザのパスワードを入力するテキストボックスを表示すること、および、前記パスワードをアプリケーションデータの変数ｐａｓｓｗｏｒｄに代入することを定義している。また、２０行目では、”ログイン”ボタンの定義と、前記ボタンが押下された時に”ＬｏｇｉｎＰＣ”というイベントが発行され、サーバにイベントＩＤ”ＬｏｇｉｎＰＣ”が送付されることを定義している。また、前記ボタン押下時に、アプリケーションデータの変数の送付も行われる。送信するアプリケーションデータの変数は”（変数名）＝（変数値）”の形式である。例えば、前記ｕｓｅｒＩＤの場合、”ｕｓｅｒＩＤ＝（ユーザの名前）”となる。この形式は、端末の種類に応じて異なってもよく、変数名と変数値の組を機械的に認識できる形式であればよい。アプリケーションデータの変数値は複数個送信してもよい。画面定義の形式および内容は、使用するクライアントの種類に依存する。例えば、クライアントがＧＵＩプログラムであれば、画面定義は前記ＧＵＩ用プログラムコードである。クライアントがＷｅｂブラウザであれば、画面定義はＪＳＰ、ＨＴＭＬなどである。クライアントがＸＭＬビューアであれば、画面定義はＸＭＬデータである。このような形式で記述された画面定義は前記状態遷移図記憶部にファイルとして格納される。なお、図８に含まれる画面定義は、ＨＴＭＬを出力するＪＳＰである。また、図９に含まれる画面定義はＣＨＴＭＬ（Compact Hyper Text Markup Language）を出力するＪＳＰである。
【００１９】
図１１および図１２は、図８および図９を画面定義も含めてそれぞれ視覚化したものである。以降、状態遷移図の例は、便宜上、これらの図のように状態遷移図を視覚化した形式で表記する。これらの視覚化した状態遷移図は、それぞれ、ＰＣ用ＷＷＷブラウザ向け状態遷移図、および、携帯電話用ＷＷＷブラウザ向け状態遷移図である。これらの状態遷移図は異なる画面および異なる遷移を持つものの、共に同じ機能を果たすアプリケーション（電話帳検索アプリケーション）の振る舞いを定義している。状態遷移図上の黒丸は初期状態を表す。白丸はＵＭＬ（Unified Modeling Language）における接合状態を示す。画像は画面定義に結びついた一つの状態を表す。矢印は、その状態から矢先方向の状態への遷移が定義されていることを示す。矢印に付随する記述は、遷移を発火するイベントのイベントＩＤおよび遷移中に実行するアクションのＩＤを示しており、”イベントＩＤ［ガード条件］／アクションＩＤ”の形式で記述される。初期状態に結び付けられているイベントＩＤおよびアクションＩＤの記述が無い遷移は、無条件に発火する。その他の表記についてはＵＭＬ等におけるステートチャートの一般的な表記法に従う。
【００２０】
図１１のＰＣ用ＷＷＷブラウザ向け状態遷移図について説明する。本状態遷移図は、初期状態（ＳＣ１０１）、ログイン状態（ＳＣ１０２）、接合状態（ＳＣ１０３）、電話帳検索状態（ＳＣ１０４）、検索結果表示状態（ＳＣ１０５）、ログアウト状態（ＳＣ１０６）から構成される。それぞれの状態には、画面定義が関連づけられているものがあり、状態ＳＣ１０２にはログイン画面、状態ＳＣ１０４には電話帳検索画面、状態ＳＣ１０５には検索結果表示画面、状態ＳＣ１０６にはログアウト画面が関連づけられている。状態ＳＣ１０１および状態ＳＣ１０３のように、画面定義に関連付けられていない状態もある。
【００２１】
次に、図１２の携帯電話用ＷＷＷブラウザ向け状態遷移図について説明する。本状態遷移図は、初期状態（ＳＣ２０１）、ログイン状態（ＳＣ２０２）、接合状態（ＳＣ２０３）、電話帳検索状態（ＳＣ２０４）、検索結果概要表示状態（ＳＣ２０５）、検索結果詳細表示状態（ＳＣ２０６）、ログアウト状態（ＳＣ２０７）から構成される。それぞれの状態には、画面定義が関連づけられているものがあり、状態ＳＣ２０２にはログイン画面、状態ＳＣ２０４には電話帳検索画面、状態ＳＣ２０５には検索結果表示概要画面、状態ＳＣ２０６には検索結果詳細画面、状態ＳＣ２０７にはログアウト画面が関連づけられている。携帯電話は画面サイズが小さいため、ＰＣでは１画面で表示可能だった検索結果表示画面が、携帯電話では、検索結果概要表示画面および検索結果詳細表示画面の２画面に分割されて定義されている。
【００２２】
以上のように、図１１および図１２に示す２つの状態遷移図は、同じ機能を果たすアプリケーションの振る舞いを定義するものであるが、クライアントの表示能力の違いにより異なる状態遷移図となっている。ただし、内部的に行う処理はどちらの遷移図でも変わらないため、大部分のアクションのプログラムコードは共用できる。たとえば、前記２つの状態遷移図間では、”ＬｏｇｉｎＡｕｔｈ”、”ＳｅａｒｃｈＤＢ”、”Ｌｏｇｏｕｔ”で識別されるアクションが、共用されている。
【００２３】
図１３は状態遷移図選択部１０５の処理の流れを示すフローチャートである。
実行エンジンより端末ＩＤを受け取ると、状態遷移図選択部１０５は、状態遷移図記憶部１０４を、端末ＩＤを用いて対応する状態遷移図を検索する（ステップＳＴ１０１）。そして、検出された状態遷移図を実行エンジンに返す（ステップＳＴ１０２）。
【００２４】
図１４は共通アクション検査部１０６の処理の流れを示すフローチャートである。
まず、実行エンジン１０９より検査対象となるアクションのアクションＩＤおよび状態遷移図記憶部１０４に記憶されている状態遷移図の集合が与えられる。次に、アクションＩＤを変数ａ１に格納する（ステップＳＴ２０１）。そして、変数ａ１がダミーアクションかどうかを検査する（ステップＳＴ２０２）。ダミーアクションの場合は、共通アクションではないとの結果をＦＡＬＳＥ値として実行エンジンに返し（ステップＳＴ２０３）、本処理部を終了する。ダミーアクションでなければ、ステップＳＴ２０４に進む。状態遷移図ループ（ステップＳＴ２０４〜ＳＴ２１１）の始端であるステップＳＴ２０４では、与えられた前記状態遷移図の集合の中で、まだ調査していない状態遷移図（実行中の状態遷移図は除く）があるかどうかを検査する。もし、まだ検査していない状態遷移図があれば、ステップＳＴ２０５に進む。もし、前記状態遷移図の集合に実行中の状態遷移図以外の状態遷移図が含まれていなかったり、あるいは前記実行中の状態遷移図以外の全ての状態遷移図が調査済みであれば、ループを終了し、ステップＳＴ２１２へ進む。ステップＳＴ２０５では、まだ調査済みでない状態遷移図を一つ抽出し、変数ｓ１に格納する。
【００２５】
次に、アクションループ（ステップＳＴ２０６〜ＳＴ２１０）の始端であるステップＳＴ２０６では、状態遷移図ｓ１に登録済みのアクションの中から、まだ調査していないアクションがあるかどうかを検査する。まだ調査していないアクションがあれば、ステップＳＴ２０７に進む。そうでなければ前記アクションループは終了し、ステップＳＴ２０３に進む。ステップＳＴ２０７では、まだ調査していないアクションのアクションＩＤを一つ抽出し変数ａ２に格納する。そして、変数ａ１とａ２が等しいかどうかを比較する等価性評価処理を起動する（ステップＳＴ２０８）。そして、等価性評価処理の結果がＴＲＵＥかどうかを検査し（ステップＳＴ２０９）、結果がＦＡＬＳＥであれば、ステップＳＴ２１０に進む。前記アクションループの終端であるステップＳＴ２１０では、変数ａ２に格納されたアクションは調査済みとし、ステップＳＴ２０６に戻る。ステップＳＴ２０９にて、ＴＲＵＥであれば前記アクションループを脱出し、状態遷移図ループの終端であるステップＳＴ２１１に進み、状態遷移図ｓ１は調査済みとした上で、ステップＳＴ２０４に戻る。ステップＳＴ２０４にて、状態遷移図ループが終了し、ステップＳＴ２１２に進んだ場合、ＴＲＵＥを前記実行エンジンに返して、本処理を終了する。
【００２６】
図１５に実施の形態１に係る等価性評価処理（ステップＳＴ２０８）の詳細な流れを示すフローチャートである。
まず、アクションａ１とａ２のアクションＩＤを比較する（ステップＳＴ３０１）。そして、等しければＴＲＵＥを返して終了する（ステップＳＴ３０２）。等しくなければＦＡＬＳＥを返して終了する（ステップＳＴ３０３）。
実施の形態１における共通アクション検査部１０６は、全ての状態遷移図で共通に使用され、かつそれぞれの状態遷移図上で一意に識別できるアクションを共通アクションとして検出する。なお、この処理により、図１１および図１２における共通アクションとして、”ＬｏｇｉｎＡｕｔｈ”、”ＳｅａｒｃｈＤＢ”、”Ｌｏｇｏｕｔ”が検出される。
図１６に共通アクション記憶部１０７のデータ構造例を示す。共通アクション記憶部１０７には、共通アクション検査部１０６が検出した共通アクションのアクションＩＤが、セッションＩＤに関連付けて格納される。これらのデータは、プレーンテキストの形式で記憶される。あるいは、ＸＭＬ形式、ＣＳＶ形式など構造を持つ記憶形式で記憶しても構わない。
【００２７】
図１７は再開処理部１０８の処理の流れを示すフローチャートである。
まず、実行エンジン１０９から、セッションＩＤ、実行中の状態遷移図、共通アクション記憶部１０７の情報が与えられる（ステップＳＴ４０１）。次に、共通アクション記憶部１０７からセッションＩＤに対応する共通アクションのアクションＩＤを抽出した上で、実行中の状態遷移図を、アクションＩＤを用いて検索する（ステップＳＴ４０２）。そして、アクションＩＤが状態遷移図上で定義されているかどうかを検査する（ステップＳＴ４０３）。該当するアクションがあれば、そのアクションの直後の状態を再開時開始状態として実行エンジンに返し（ステップＳＴ４０４）、再開処理を終了する。もし、ステップＳＴ４０３にて該当する共通アクションがなければ、新規にセッションＩＤを生成する（ステップＳＴ４０５）。この場合、前期実行中の状態遷移図の初期状態を再開時開始状態として実行エンジンに返し（ステップＳＴ４０６）、再開処理を終了する。
再開処理部１０８では、アプリケーション処理再開時のクライアントの種類が中断時と異なる場合の処理の再開を実現する。中断時と再開時では異なる状態遷移図が使用されるが、共通アクションは両状態遷移図上に共通に存在するため、そのアクションＩＤを用いて再開時開始状態を特定することができる。
【００２８】
図１８は実行エンジン１０９の処理の流れを示すフローチャートである。
実行エンジン１０９は、ＷＷＷサーバを介してクライアントから処理要求を受信すると起動する。処理要求には、端末ＩＤ、ユーザＩＤ、セッションＩＤ、イベントＩＤおよびアプリケーションデータの変数値が含まれる。なお、セッションＩＤは空の場合がある。実行エンジン１０９はクライアントから受信する（ステップＳＴ５０１）と、まず、前記受信したアプリケーションデータの変数名と一致する変数がアプリケーションデータ記憶部１０１に存在するかどうかを検査し、存在すれば、アプリケーションデータ記憶部１０１の変数値として前記受信したアプリケーションデータの変数値を代入する。次に、前記端末ＩＤを用いて状態遷移図選択部１０５における状態遷移図選択処理を起動する（ステップＳＴ５０２）。そして状態遷移図記憶部１０５が選択した状態遷移図を、実行中の状態遷移図として記憶装置２０１に記憶する（ステップＳＴ５０３）。次に、セッションＩＤが空かどうかを調べる（ステップＳＴ５０４）。空でない場合には、セッション情報記憶部１０３からセッションＩＤに対応するセッション情報を抽出する（ステップＳＴ５０５）。そして、セッション情報から最後に実行したアクションのアクションＩＤを抽出する（ステップＳＴ５０６）。
【００２９】
次に、この最後に実行したアクションのアクションＩＤを用いて、実行中の状態遷移図を検索する（ステップＳＴ５０７）。そして、該当するアクションがあるかどうかを検査する（ステップＳＴ５０８）。もし、該当するアクションが実行中の状態遷移図上に存在すれば、当該アクションの直後の状態を現在状態として記憶装置２０１に格納し（ステップＳＴ５０９）、ステップＳＴ５１６に進む。ステップＳＴ５０８において、該当するアクションが存在しなければ、共通アクション記憶部１０７の情報、セッションＩＤおよび実行中の状態遷移図を用いて再開処理部１０８の再開処理を起動する（ステップＳＴ５１０）。再開処理部１０８は再開時開始状態を返すので、この状態を現在状態として記憶装置２０１に格納し（ステップＳＴ５１１）、ステップＳＴ５１６に進む。
【００３０】
また、一方、ステップＳＴ５０４において、セッションＩＤが空の場合には、前記ユーザＩＤを用いてセッション情報記憶部１０３を検索する（ステップＳＴ５１２）。そして、ユーザＩＤに対応するセッションＩＤがセッション記憶部に存在するかどうか検査する（ステップＳＴ５１３）。もし、セッションＩＤが存在すれば、ユーザＩＤに対応するセッションＩＤを取得した上で、ステップＳＴ５０５に進む。また、セッションＩＤが存在しなければ、新たにセッションＩＤを生成し（ステップＳＴ５１４）、状態遷移図の初期状態を現在状態として記憶装置２０１に記憶した上（ステップＳＴ５１５）で、ステップＳＴ５１６に進む。
【００３１】
次に、ステップＳＴ５１６において、現在状態とイベントＩＤに基づいて実行中の状態遷移図を検索する。そして、現在状態にそのイベントＩＤに対応する遷移があるかどうかを検査し（ステップＳＴ５１７）、対応する遷移があればステップＳＴ５１８に、一方、対応する遷移がなければステップＳＴ５２５に進む。ステップＳＴ５１８において、まだ評価していない遷移の内で、最初に定義されているものを抽出し、そのガード条件を評価する。なお、ガード条件が定義されていない場合、常に真と判定する。そして、ガード条件の評価結果が真であればステップＳＴ５２０に、真でなければステップＳＴ５１９に進む。ステップＳＴ５１９では、ステップＳＴ５１７で検出された遷移の内に、まだ評価されていない遷移があれば、ステップＳＴ５１８に戻る。もし、ステップＳＴ５１７で検出された遷移が全て評価済みであれば、ステップＳＴ５２５に進む。
【００３２】
一方、ステップＳＴ５２０では、遷移を発火する処理である遷移処理を起動する。次に、遷移処理中に実行したアクションのアクションＩＤを取得する（ステップＳＴ５２１）。そして、取得したアクションＩＤを用いて共通アクション検査部１０６の共通アクション検査処理を起動する（ステップＳＴ５２２）。共通アクション検査処理は、取得したアクションが共通アクションかどうかを真偽値で返す。次に、前記共通アクション検査処理の結果の真偽値、および、実行したアクションのアクションＩＤを用いて、セッション情報保存処理を起動する（ステップＳＴ５２３）。次に、現在状態において、イベントＩＤに関連付けられていない遷移が定義されているかどうかを検査し（ステップＳＴ５２４）、イベントＩＤに関連付けられていない遷移があればステップＳＴ５１８に戻る。一方、そのような遷移がなければ、現在状態の状態ＩＤを用いて状態遷移図を検索し、現在状態に対応する画面定義のファイル名を抽出して、そのファイル名に対応する画面定義を状態遷移図記憶部１０４から取得する（ステップＳＴ５２５）。
【００３３】
次に、取得した画面定義に必要な変換等を施した後、セッションＩＤと共にクライアントに渡す（ステップＳＴ５２６）。まず、画面定義内のアプリケーションデータの評価処理を行う。例えば、画面定義がＪＳＰやＨＴＭＬの場合、画面定義内に”〈ｖａｌｕｅ：Ｎａｍｅ〉”との表記があれば、アプリケーションデータ記憶部１０１から変数名”Ｎａｍｅ”に対応する変数値を取得し、”〈ｖａｌｕｅ：Ｎａｍｅ〉”と前記変数値を置き換える。次に、例えば画面定義がプログラムコードである場合は、それを実行する。また、画面定義がＨＴＭＬ形式やＸＭＬ形式であれば、それをＷＷＷサーバを介してクライアントに送信する。あるいは、画面定義がＪＳＰ形式であれば、それをサーブレットエンジンに渡して実行させる。サーブレットエンジンは実行した結果を、ＷＷＷサーバを介してクライアントに送信する。なお、クライアントが、本装置と同一のプロセスのＧＵＩプログラムの時は、そのプログラムの関数を呼び出す。
【００３４】
図１９は上述した遷移処理（ステップＳＴ５２０）およびセッション情報保存処理（ステップＳＴ５２３）の詳細な流れを示すフローチャートである。
最初に、遷移処理の流れを図１９（ａ）で説明する。まず、遷移による遷移先の状態を次状態とする（ステップＳＴ６０１）。次に、遷移に含まれるアクションのアクションＩＤを遷移から抽出し、そのアクションＩＤを用いてアクション実行処理を起動する（ステップＳＴ６０２）。そして、次状態を現在状態に設定して、遷移処理を終了する（ステップＳＴ６０３）。
【００３５】
次に、ステップＳＴ６０２に対応するアクション処理の流れを図１９（ｂ）で説明する。アクション実行処理では、まず、実行すべきアクションのアクションＩＤを遷移から取得する（ステップＳＴ６０４）。次に、実行エンジンは、アクション記憶部１０２をアクションＩＤを用いて検索し、対応するプログラムコードを取得する（ステップＳＴ６０５）。次に、アクションに入力のための変数が結び付けられているかどうか検査する（ステップＳＴ６０６）。もし結び付けられている場合には、実行エンジンはアプリケーションデータから当該変数の値を読み出し、アクションの入力値として与える（ステップＳＴ６０７）。次に、実行エンジン１０９は、アクションのプログラムコードを実行する（ステップＳＴ６０８）。最後に、アクションに出力の変数が結び付けられているかどうか検査し（ステップＳＴ６０９）、結び付けられている場合は、アクションの結果の値を結び付けられた変数に代入する（ステップＳＴ６１０）。以上でアクション処理を終了する。
【００３６】
次に、セッション情報保存処理（ステップＳＴ５２３）の流れについて図１９（ｃ）で説明する。まず、セッションＩＤを用いてセッション情報記憶部１０３を検索する（ステップＳＴ６１１）。そして、セッションＩＤに対応するセッション情報がすでに登録されているかどうか検査する（ステップＳＴ６１２）。登録されていた場合、ステップＳＴ６１４に進む。一方、登録されていなかった場合には、セッション情報記憶部１０３に一行分のデータ構造を追加し、そのデータ構造にユーザＩＤおよびセッションＩＤを記憶して（ステップＳＴ６１３）、ステップＳＴ６１４に進む。ステップＳＴ６１４では、実行エンジン１０９が実行したアクションのアクションＩＤを、セッション情報記憶部１０３上のセッションＩＤに対応するセッション情報に記憶する。
【００３７】
次に、共通アクション検査処理が、真を返したかどうかを検査する（ステップＳＴ６１５）。真を返さなかった場合、セッション情報保存処理を終了する。一方、真を返した場合、セッションＩＤを用いて、共通アクション記憶部１０７を検索する（ステップＳＴ６１６）。そして、セッションＩＤに対応する共通アクションがすでに登録されているかどうか検査し（ステップＳＴ６１７）、登録されていた場合、ステップＳＴ６１９に進む。また、登録されていなかった場合には、共通アクション記憶部１０７上に一行分の共通アクション記憶用のデータ構造を追加し、そのデータ構造にセッションＩＤを記憶して（ステップＳＴ６１８）、ステップＳＴ６１９に進む。ステップＳＴ６１９では、実行エンジン１０９が実行したアクションＩＤを、共通アクション記憶部１０７上のセッションＩＤに対応するデータ構造に記憶し、セッション情報保存処理を終了する。
【００３８】
次に、図１１および図１２を使用して、この実施の形態１の動作を説明する。
まず、ユーザは、ＰＣ用ＷＷＷブラウザをクライアントとして使用し、サーバにアクセスする。すると、実行エンジン１０９が起動する。状態遷移図選択部１０５は、端末ＩＤに基づきＰＣ用ＷＷＷブラウザ向け状態遷移図（図１１）を選択する。ユーザは必要な入力とボタンの押下をクライアントにて実施し、ログイン状態（ログイン画面）および検索結果表示状態（結果表示画面）まで処理を進行し、アプリケーションを中断する（クライアントを終了させる）。このとき、共通アクション記憶部１０７には、共通アクション検査部１０６が最後に検出した共通アクションのアクションＩＤである”ＳｅａｒｃｈＤＢ”が記録されている。
【００３９】
次に、ユーザが、携帯電話のＷＷＷブラウザを用いて、本セッション管理装置にアクセスする。状態遷移図選択部１０５は、端末ＩＤに基づき携帯電話用ＷＷＷブラウザ向け状態遷移図（図１２）を選択する。そして、再開処理部１０８は、前記共通アクション記憶部１０７に格納された共通アクションのアクションＩＤである”ＳｅａｒｃｈＤＢ”に基づき、状態遷移図を検索する。すると、再開処理部１０８は、電話帳検索画面から検索結果概要画面への遷移において、”ＳｅａｒｃｈＤＢ”アクションが実行されることを検出する。これにより、再開処理部１０８は、アクション実行直後の状態である検索結果概要状態（検索結果概要画面）を再開時の開始状態と決定する。そして、実行エンジン１０９は、再開処理部１０８が特定した開始状態を現在状態として設定する。なお、アプリケーションデータ記憶部１０１に記憶された変数は、再開後も引き継いで使用することができる。以上の処理により、ユーザは携帯電話のＷＷＷブラウザを用いて、検索結果画面からアプリケーションの処理を再開することができる。
なお、中断後の異種クライアントでの再開は、アプリケーションの実行に必須ではない。すなわち、クライアントがＰＣ用ＷＷＷブラウザのみであっても本アプリケーションは最初から最後まで実行できるし、またクライアントが携帯電話用ＷＷＷブラウザのみでも本アプリケーションは最初から最後まで実行できる。
【００４０】
この実施の形態１のバリエーションについて以下に述べる。
上記例では、再開処理部１０８は再開時の開始状態を共通アクションの後の状態に設定するものとして扱ったが、開始状態は共通アクションより前の状態としてもよい。また、どちらで再開するかを選択可能にすることにより、状態遷移図作成者が状態遷移図定義時に、共通アクションの前後どちらで再開するかを指定したり、また、アプリケーションのユーザが処理再開時に、どちらから再開するかを動的に選択したりすることも可能になる。このようにすることでより柔軟な中断、再開を行うことができる。
【００４１】
また、上記例では、共通アクション検査部１０６が、アプリケーションの実行時に、アプリケーションの進行に伴って共通アクションかどうかを検出するとして扱ったが、アプリケーション実行前に、全状態遷移図の全アクションを予め検査し、共通アクションを検出しておくこともできる。具体的には、アクション記憶部１０２上の各アクションＩＤに対し、共通アクションであることを示す印を付ける領域を用意し、予め検出した共通アクションには、この領域に印を付けるようにする。そして、アプリケーション実行時には、共通アクション検査部１０６は、実行したアクションのアクションＩＤに対応する領域に印がついているかどうかで共通アクションかどうかを判断することができる。こうすることで、実行中のアクションの検査が不要になる。このため、アプリケーションの実行速度の高速化が図れる。
【００４２】
さらに、上記例では、中断時と再開時で同じ状態遷移図を使用する場合における、再開のための情報として、最後に実行したアクションのアクションＩＤを使用するとして（実行エンジン１０９の処理の流れにおけるステップＳＴ５０６、ステップＳＴ５０７、ステップＳＴ５０８、ステップＳＴ５０９の一連の処理）扱ったが、アクションＩＤの代りに現在状態の状態ＩＤを使用してもよい。すなわち、セッション情報記憶部１０３のデータ構造において、最後に実行したアクションＩＤを記憶する替りに、現在状態の状態ＩＤを記憶する。そして再開時に、中断時と同じ状態遷移図を使用する場合には、前記状態ＩＤに一致する状態を再開時開始状態とする。このようにすることで、上記例と同様の効果が得られる。
【００４３】
さらに、上記例では、再開処理部１０８は、セッション情報に含まれる共通アクションに該当するアクションが状態遷移図上に見つかれば、無条件で処理を再開するものとして扱った。しかし、再開前にユーザに再開するかどうかを問い合わせるプロンプトを出力するようにし、ユーザが再開すると入力すれば再開処理を行い、ユーザが再開しないと入力すれば状態遷移図の初期状態から処理を開始するようにしてもよい。このようにすることで、より柔軟な、再開処理を行うことができる。
【００４４】
さらに、上記例では、再開処理部１０８は、一ユーザに対し一つのセッションのみを扱っているが、一ユーザが複数のセッションを扱えるようにすることもできる。再開処理前に、セッション情報記憶部１０３に記憶されたユーザＩＤに対応するセッション情報を一覧として出力装置２０２に出力し、その上で、ユーザにどのセッションを再開するかを尋ねるプロンプトを出力する。そして、ユーザが選択したセッション情報を使用して再開処理を行うことで、一ユーザでも複数のセッションを扱うことができる。このようにすることで、さらに柔軟な、再開処理を行うことができる。
【００４５】
また、図２０に示すＰＣ用ＷＷＷブラウザ向け状態遷移図および図２１に示す携帯電話用ＷＷＷブラウザ向け状態遷移図を用いた例を説明する。これら２つの状態遷移図は、電話帳情報を登録するアプリケーションの振る舞いを定義している。図２０では、一画面で、名前、住所および電話番号を登録できる。一方、図２１では、名前入力画面、住所入力画面、番号入力画面の３画面から構成されており、それぞれの画面で名前、住所、電話番号を入れ、ボタンを押下することで登録ができる。
【００４６】
以上のように、この実施の形態１によれば、共通アクション検査部により、実行エンジンで動作させたアクションが共通アクションかどうかを検査し、検出された共通アクションを共通アクション記憶部に記憶し、状態遷移図選択部で、入力される端末の種類に応じて状態遷移図を選択し、再開処理部が、共通アクション記憶部の情報を基に、アプリケーション処理中断後の再開時状態遷移図上で開始状態を特定するようにしたものである。したがって、再開時の端末（クライアント）の種類が中断時と異なっていても、アプリケーション処理中断後の継続を可能にする効果が得られる。また、このため、異なるクライアント用の状態遷移図間における個々の状態間の関連付けが不要となる。
【００４７】
実施の形態１の別の効果を示す。まず、動作について説明するが、まず、ユーザが携帯電話を用いて本セッション管理装置３０２にアクセスすると、図２１の状態遷移図が使用される。次に、ユーザは、名前の欄に”田中太郎”を入力し、次へボタンを押下する。この時点で、セッション管理装置３０２におけるアプリケーションデータ記憶部１０１には、”名前＝田中太郎”（左辺が変数名、右辺が変数値。以降、アプリケーションデータをこの形式で記述する。）という情報が記憶される。次の住所入力画面では、ユーザは、住所の欄に”兵庫県尼崎市”を入力し、次へボタンを押下する。この時点で、セッション管理装置３０２におけるアプリケーションデータ記憶部１０１には、”住所＝兵庫県尼崎市”という情報が記憶される。そして、ユーザは、アプリケーションの処理を中断（携帯電話用ＷＷＷブラウザを終了）する。この時点では、共通アクション記憶部１０７には、共通アクション検査部１０６で検出した”ＬｏｇｉｎＡｕｔｈ”が記録されている。次に、同ユーザがＰＣ用ＷＷＷブラウザでセッション管理装置３０２にアクセスすると、図２０の状態遷移図が使用される。そして、再開処理部１０８は、共通アクション記憶部１０７に記憶されているアクションＩＤである”ＬｏｇｉｎＡｕｔｈ”に基づき、開始状態を電話帳登録画面と決定する。このとき、アプリケーションデータ記憶部１０１には”名前＝田中太郎”、”住所＝兵庫県尼崎市”が既に登録された状態なので、図２２に示すように、画面にこれらの値が反映される。したがって、この構成により、中断時のユーザの作業の途中経過の変数値を、再開時に画面に反映させることができる。
【００４８】
実施の形態２．
上記実施の形態１では、全ての状態遷移図上に共通に存在する共通アクションのみを使用している。このため、使用する状態遷移図によっては、共通アクションの実行の後に、共通でないアクションを多く実行する場合がある。このような状況で処理を中断した場合、再開時には中断時から離れた状態から再開されることになる。この実施の形態２はそのような点を改善する。
図２３はこの発明の実施の形態２によるセッション管理装置の機能構成を示すブロック図である。実施の形態２のハードウェア構成およびシステム構成は、図２および図３のように実施の形態１と同じである。図２３において、実施の形態１の図１と同じ構成部は同一の符号を付してある。実施の形態１と異なる点としては、履歴記憶部４０２および履歴保存処理部４０３が新規に追加されている。また、実施の形態１の共通アクション検査部１０６がここでは共通アクション検査部４０１に、再開処理部１０８が再開処理部４０４に、さらに、実行エンジン１０９が実行エンジン４０５に置き換えられている。ここで、履歴記憶部４０２は、実行エンジン４０５が動作させた共通アクションの履歴を記憶する手段で、図２のＰＣにおける記憶装置２０１上に置かれている。また、履歴保存処理部４０３は、実行エンジン４０５が動作させた共通アクションの履歴を履歴記憶部４０２に記憶させる処理を行う手段で、同ＰＣにおける記憶装置２０１上に置かれ、制御装置２０３で実行する機能である。
【００４９】
図２４は実施の形態２に係る共通アクション検査部４０１の処理の流れを示すフローチャートである。なお、ステップＳＴ２０１〜ＳＴ２０３の処理は実施の形態１の共通アクション検査処理と同様である。また、ステップＳＴ２０８の処理は実施の形態１の等価性評価処理と同様である。
まず、実行エンジン４０５から、検査対象となるアクションのアクションＩＤおよび状態遷移図記憶部１０４に記憶されている状態遷移図が与えられる。与えられたアクションＩＤは変数ａ１に格納される（ステップＳＴ２０１）。次に、変数ａ１がダミーアクションかどうかを検査する（ステップＳＴ２０２）。ダミーアクションの場合は、共通アクションではないとの結果をＦＡＬＳＥ値として実行エンジン４０５に返し（ステップＳＴ２０３）、本処理部を終了する。一方、ステップＳＴ２０２にて、変数ａ１がダミーアクションでなかった場合、与えられた状態遷移図の集合の中で、まだ調査していない状態遷移図（実行中の状態遷移図は除く）があるかどうかを検査する（ステップＳＴ７０１）。なお、テップＳＴ７０１は、状態遷移図ループ２（ステップＳＴ７０１〜ＳＴ７０７）の始端である。ここで、まだ検査していない状態遷移図があれば、ステップＳＴ７０２に進む。一方、状態遷移図の集合に実行中の状態遷移図以外の状態遷移図が含まれていなかったり、あるいは実行中の状態遷移図以外の全ての状態遷移図が調査済みであれば、ループを終了し、ステップＳＴ２０３へ進む。
【００５０】
ステップＳＴ７０２では、まだ調査済みでない状態遷移図を一つ抽出し、変数ｓ１に格納する。アクションループ２（ステップＳＴ７０３〜ＳＴ７０６）の始端であるステップＳＴ７０３では、状態遷移図ｓ１に登録済みのアクションの中から、まだ調査していないアクションがあるかどうかを検査する。まだ調査していないアクションがあれば、ステップＳＴ７０４に進む。そうでなければアクションループ２は終了し、ステップＳＴ７０７に進む。ステップＳＴ７０４では、まだ調査していないアクションのアクションＩＤを一つ抽出し変数ａ２に格納する。そして、変数ａ１とａ２が等しいかどうかを比較する等価性評価処理を起動する（ステップＳＴ２０８）。そして、等価性評価処理の結果がＴＲＵＥかどうかを検査する（ステップＳＴ７０５）。結果がＴＲＵＥであれば変数ａ１は共通アクションとみなし、実行エンジン４０５にＴＲＵＥを返し（ステップＳＴ７０８）、本処理を終了する。
【００５１】
一方、ステップＳＴ７０５で、結果がＦＡＬＳＥであれば、アクションループ２の終端であるステップＳＴ７０６において、変数ａ２に格納されたアクションは調査済みとし、ステップＳＴ７０３に戻る。ステップＳＴ７０７は前記状態遷移図ループ２の終端なので、変数ｓ１に格納された状態遷移図は調査済みとした上で、ステップＳＴ７０１に戻る。ステップＳＴ２０３では、変数ａ１は共通アクションではないと見なし、実行エンジン４０５にＦＡＬＳＥを返して本処理を終了する。
共通アクション検査部４０１が検出する共通アクションは、複数の異なる状態遷移図間で共通に使用されるアクションである。この共通アクションには、実施の形態１における共通アクション（全ての状態遷移図で共通に使用されるアクション）も含む。
【００５２】
図２５に履歴記憶部４０２のデータ構造例を示す。履歴記憶部４０２では、共通アクションの実行の履歴を、セッションＩＤに関連づけて記憶する。この履歴は、アクションのアクションＩＤを実行した順序に並べたものである。この順序を記憶するために、アクションＩＤの配列を使用する。この配列には、添え字が大きくなるほど、より新しく実行されたアクションのアクションＩＤが格納される。なお、前記配列に格納されたアクションＩＤは削除することもできる。なお、記憶装置２０１上に保存する際には、配列の順序を保持してプレーンテキスト形式で保存する。また、ＣＳＶ形式、あるいは、ＸＭＬ形式などの構造化された形式で保存してもよい。
【００５３】
図２６は履歴保存処理部４０３の処理の流れを示すフローチャートである。
実行エンジン４０５から、共通アクション検査部４０１の共通アクション検査処理における結果の真偽値および履歴記憶部４０２の情報が与えられる。まず、共通アクション検査処理がＴＲＵＥを返したかどうかを検査する（ステップＳＴ８０１）。もし、ＴＲＵＥを返さなかった場合は、履歴保存処理を終了する。一方、ＴＲＵＥを返した場合には、セッションＩＤを用いて履歴記憶部４０２を検索する（ステップＳＴ８０２）。次に、当該セッションＩＤに対応するアクションＩＤの履歴に、まだアクションＩＤを追加できるかどうか検査する（ステップＳＴ８０３）。追加できる場合はステップＳＴ８０５に進む。一方、追加できなければ、添え字の一番小さい要素（最も古いアクションＩＤ）を削除する。そして削除されて空になった部分を埋めるように、アクションＩＤを順次１つずつ詰める（ステップＳＴ８０４）。最後に、セッションＩＤに対応する履歴にアクションＩＤを追加し、処理を終了する（ステップＳＴ８０５）。
【００５４】
図２７は再開処理部４０４の処理の流れを示すフローチャートである。
まず、実行エンジン４０５から、実行中の状態遷移図および共通アクションのアクションＩＤの履歴が与えられる（ステップＳＴ９０１）。履歴ループ（ステップＳＴ９０２〜ＳＴ９０６）の始点であるステップＳＴ９０２において、履歴にまだ抽出されていないアクションＩＤがあるかどうかを検査する。履歴中のすべてのアクションＩＤが抽出済みの場合、履歴ループを終了し、ステップＳＴ９０８に進む。一方、まだ抽出されていないアクションＩＤが存在する場合、履歴の中から最も新しいアクションＩＤを取り出し、変数ａ３に格納する（ステップＳＴ９０３）。そして、実行中の状態遷移図を、変数ａ３を用いて検索し（ステップＳＴ９０４）、該当するアクションがあるかどうかを検査する（ステップＳＴ９０５）。もし、該当するアクションが存在しなかった場合は、ステップＳＴ９０６に進む。ステップＳＴ９０６は履歴ループの終端なので、変数ａ３は既に抽出済みのアクションＩＤとした上で、始端であるステップＳＴ９０２に戻る。一方、ステップＳＴ９０５において該当するアクションが見つかれば、履歴ループを脱出し、該当するアクションの直後の状態を再開時開始状態とし（ステップＳＴ９０７）、再開処理を終了する。ステップＳＴ９０８では、新規にセッションＩＤを生成する。そして、実行中の状態遷移図の初期状態を再開時開始状態とし（ステップＳＴ９０９）、再開処理を終了する。
【００５５】
実行エンジン４０５の処理の流れは、図１８に示した実施の形態１の実行エンジン１０９のものとほぼ同様である。ただし、ステップＳＴ５２３とステップＳＴ５２４の処理の間において、履歴記憶部４０２の情報および共通アクション検査部４０１における処理の結果の真偽値を用いて履歴保存処理部４０３を起動する処理が追加される。
【００５６】
図２８は３つの状態遷移図ＳＤ１０１、ＳＤ１０２およびＳＤ１０３を定義している。なお、便宜上、画面定義の画面表示は省略している。図２８を用いて、実施の形態２の動作を説明する。
まず、状態遷移図ＳＤ１０１を使用して、状態ＳＣ３０３まで遷移した後、アプリケーションを中断する。この場合、共通アクション検査部４０１は”ａｃｔｉｏｎＡ”および”ａｃｔｉｏｎＢ”を共通アクションとして検出する。したがって、この時、履歴保存処理部４０３は、アクションＩＤを実行した順に”ａｃｔｉｏｎＡ、ａｃｔｉｏｎＢ”と履歴記憶部４０２に記録する。次に、もし状態遷移図ＳＤ１０２を使用してアプリケーションを再開した場合、状態遷移図ＳＤ２０２には最も新しい履歴の共通アクションと同じアクションである”ａｃｔｉｏｎＢ”が存在する。したがって、再開処理部４０４は、”ａｃｔｉｏｎＢ”の実行直後の状態ＳＣ３０６を再開時開始状態と決定する。一方、状態遷移図ＳＤ１０３を使用してアプリケーションを再開した場合、状態遷移図ＳＤ１０３には”ａｃｔｉｏｎＢ”が存在しない。したがって、再開処理部４０４は、次に新しい履歴である共通アクションである”ａｃｔｉｏｎＡ”を用いて、”ａｃｔｉｏｎＡ”の実行直後の状態ＳＣ３０８を再開時開始状態と決定する。
【００５７】
次に、この実施の形態２のバリエーションについて述べる。
上記例では、履歴保存処理部４０３が履歴記憶部４０２に共通アクションの実行の履歴を保存するとして扱ったが、共通アクションかどうかに依らず、アクション全ての実行の履歴を保存するようにしてもよい。この場合、共通アクション検査部４０１は共通アクションを特に区別せず、その処理は常にＴＲＵＥを返し終了するステップのみの構成となる。これによれば、再開処理時において検査するアクションＩＤの件数が多くなるため実行速度が遅くなるものの、同様の効果が得られる。
また、上記例では、履歴記憶部４０２と共通アクション記憶部１０７を別の記憶部としているが、これらを一つにまとめてもよい。
【００５８】
以上のように、実施の形態２によれば、履歴保存処理部により、実行エンジンが共通アクションを動作させた履歴を履歴記憶部に記憶させ、この保存した共通アクションの情報を基に、再開処理部が、アプリケーション処理中断後の再開時状態遷移図上で開始状態を特定するようにしたものである。したがって、再開処理部は、含まれる全ての共通アクションから、最新に近い共通アクションを用いて再開時状態遷移図上の再開時開始状態を決定することができ、このため再開時開始状態をよりきめ細かく特定でき、より中断時に近い状態からの再開を可能にする効果が得られる。
【００５９】
実施の形態３．
上記実施の形態１および実施の形態２では、一方の状態遷移図上では複数の共通アクションが一つの遷移上で定義され、他方の状態遷移図上では、それらの共通アクションが別個の遷移上で定義されるという状態遷移図の組み合わせにおいて、まず後者の状態遷移図を使用し当該共通アクションを実行して中断後、前者の状態遷移図で再開する時は、再開後の状態遷移に伴って再び同じアクションを実行するため、アクションの実行が重複することがあった。この実施の形態３は、このような点を改善することにある。
図２９はこの発明の実施の形態３によるセッション管理装置の機能構成を示すブロック図である。実施の形態３のハードウェア構成およびシステム構成は、図２および図３のように実施の形態１と同じである。図２９において、実施の形態２の図２３と同じ構成部は同一の符号を付してある。異なる点としては、ロールバック処理部５０３を新規に追加している。また、実施の形態２のアクション記憶部１０２がここではロールバックコードを記憶するアクション記憶部５０１に、また再開処理部４０４が再開処理部５０２に、さらに、実行エンジン４０５が実行エンジン５０４に置き換えられている。ここで、ロールバック処理部５０３は、既に実行したアクションの処理を後戻り（ロールバック）する手段で、記憶装置２０１上に置かれ、制御装置２０３で実行される手段である。
【００６０】
図３０にアクション記憶部５０１のデータ構造例を示す。実施の形態１のアクション記憶部１０２に、アクションのプログラムコードを取り消すプログラムコードであるロールバックコードを記憶する領域を追加したものである。この実施の形態３で扱うアクションには、全てロールバックコードが存在する。ただし、ダミーアクションのロールバックコードは存在せず、空である。
【００６１】
再開処理部５０２の処理の流れは、実施の形態２で述べた図２７において、ステップＳＴ９０７およびステップＳＴ９０９の後に、共通アクションを用いて再開時開始状態を決定したかどうかの真偽値および再開時開始状態を決定するキーとなったアクションＩＤを実行エンジン５０４に返すというステップを追加して実現される。実行エンジン５０４に返す値の真偽値がＦＡＬＳＥの場合は、アクションＩＤは空である。なお、実施の形態１の再開処理部１０８を基にする場合は、上記処理を、図１７におけるステップＳＴ４０４およびステップＳＴ４０６の後に追加する。
【００６２】
図３１はロールバック処理部５０３の処理の流れを示すフローチャートである。
処理起動時に、実行エンジン５０４から、現在状態、再開処理部５０２が共通アクションＩＤを用いて再開時開始状態を決定したかどうかの真偽値、実行時の状態遷移図および再開処理部５０２が再開時開始状態を決定するキーとした共通アクションのアクションＩＤが与えられる。まず、再開処理部５０２が共通アクションのアクションＩＤを用いて再開時開始状態を決定したかどうかを検査する（ステップＳＴ１００１）。ＦＡＬＳＥであれば、本処理を終了する。一方、ＴＲＵＥであれば、実行中の状態遷移図を、現在状態および共通アクションのアクションＩＤを用いて検索し、現在状態以降で、かつ共通アクションが実行されるまでの遷移上に存在するアクションの系列を抽出する（ステップＳＴ１００２）。このアクションの系列がロールバックすべきアクションの系列である。なお、再開処理部５０２が再開時開始状態を共通アクションの後に決定した場合、アクションの系列は空である。
【００６３】
次に、アクションループ３（ステップＳＴ１００３〜ＳＴ１００８）の始端であるステップＳＴ１００３において、アクションの系列にまだ処理していないアクションがあるかどうかを検査する。もし、まだ処理していないアクションがあれば、ステップＳＴ１００４に進み、そうでなければ、アクションループ３を終了し、本ロールバック部の処理を終了する。ステップＳＴ１００４では、アクションの系列の内のまだ処理されていないアクションの中から、最も後に実行されるアクションのアクションＩＤを抽出し、変数ａ４に格納する。そして、変数ａ４に基づきアクション記憶部５０１を検索する（ステップＳＴ１００５）。すると、アクションＩＤに対応するロールバックコードがアクション記憶部５０１より得られる（ステップＳＴ１００６）。そしてロールバックコードを実行する（ステップＳＴ１００７）。最後に、アクションループ３の終端であるステップＳＴ１００８で、変数ａ４に格納されたアクションを処理済みとし、このループの始端であるステップＳＴ１００３に戻る。
【００６４】
実行エンジン５０４は、実施の形態１あるいは実施の形態２における実行エンジンの処理の流れ（図１８および図１９）とほぼ同様である。ただし、次の２点が異なる。その１つは、図１８のステップＳＴ５０９、ステップＳＴ５１１およびステップＳＴ５１５の直後に、ロールバック処理を起動するステップが追加されることである。もう一つは、ステップＳＴ５２０にて起動される遷移処理が、図３２に示す処理に置き換えられることである。
【００６５】
次に、図３２に示される遷移処理の流れについて説明する。
ステップＳＴ６０１、ステップＳＴ６０２およびステップＳＴ６０３は、実施の形態１および実施の形態２の遷移処理と同様である。まず、遷移先の状態を次状態に設定する（ステップＳＴ６０１）。次に、アクションループ４（ステップＳＴ１１０１〜ＳＴ１１０２）の始端であるステップＳＴ１１０１において、遷移上にまだ実行済みでないアクションがあるかどうかを検査する。実行済みでないアクションがなければ、アクションループ４を終了してステップＳＴ６０３に進む。一方、まだ実行済みでないアクションがあれば、遷移上からまだ実行済みでないアクションのＩＤを抽出し、そのアクションＩＤを用いてアクション実行処理を起動する（ステップＳＴ６０２）。アクションループ４の終端である次のステップＳＴ１１０２では、アクション実行処理で実行したアクションを実行済みとした上で、ループの始端であるステップＳＴ１１０１に戻る。最後に、次状態を現在状態に設定した上で、処理を終了する（ステップＳＴ６０３）。本遷移処理では、遷移上に複数のアクションが定義された場合に、それらを実行する機能を実現している。
【００６６】
次に、実施の形態３の動作を説明する。
図３３に、状態遷移図の例ＳＤ２０１およびＳＤ２０２を示す。ＳＤ２０２では、一つの遷移に複数のアクションが定義されている。まず、状態遷移図ＳＤ２０２を使用してＳＣ４０４まで状態遷移を行ったあと、中断する。このとき、共通アクション検査部４０１は、”ａｃｔｉｏｎＡ”を共通アクションとして検出する。そして、履歴保存処理部４０３は、履歴記憶部４０２における共通アクションの履歴の記憶領域に”ａｃｔｉｏｎＡ”を記憶する。次に、状態遷移図ＳＤ２０１を用いて処理を再開する。このとき再開処理部５０２は、セッション情報記憶部１０３のアクションの履歴の中で最も新しい”ａｃｔｉｏｎＡ”を用いてＳＣ４０１を再開時開始状態に決定する。このときロールバック処理部５０３は、アクション記憶部５０１から”ａｃｔｉｏｎＡ”に対応するロールバックコードを取得して実行し、”ａｃｔｉｏｎＡ”の実行をロールバックする。
【００６７】
以上のように、この実施の形態３によれば、ロールバック処理部により、アクション記憶部に記憶された実行したアクション情報に基づいて、既に実行したアクションの処理を取り消すようにしたものである。したがって、既に実行した重複するアクションをロールバックすることにより、一方の状態遷移図上で、複数の共通アクションが一つの遷移上で定義され、他方の状態遷移図上では、それらの共通アクションが別個の遷移上で定義されるような状態遷移図の組み合わせが状態遷移図記憶部に含まれていても、うまく扱うことができる効果が得られる。
【００６８】
実施の形態４.
図３４はこの発明の実施の形態４によるセッション管理装置の機能構成を示すブロック図である。実施の形態４のハードウェア構成およびシステム構成は、図２および図３のように実施の形態１と同じである。図３４において、実施の形態２の図２３と同じ構成部は同一の符号を付してある。異なる点としては、制約検査部６０１を新規に追加している。なお、実施の形態４は、便宜上、構成図は実施の形態２の構成を基にしているが、実施の形態１あるいは実施の形態３の構成に対して、制約検査部６０１を追加すれば同様に実現できるものである。この制約検査部６０１は、記憶装置２０１上に置かれ、制御装置２０３で実行される機能で、状態遷移図の制約を検査する手段である。
【００６９】
図３５は制約検査部６０１の処理の流れを示すフローチャートである。
制約検査部６０１における制約検査処理では、本セッション管理装置において、状態遷移図およびアクションが満たすべき制約を検査する。まず、アクション一意性検査処理（ステップＳＴ１２０１）を起動する。次に、共通アクション有無検査処理（ステップＳＴ１２０２）を起動し、終了する。
【００７０】
図３６はアクション一意性検査処理（ステップＳＴ１２０１）の詳細な流れを示すフローチャートである。
まず、状態遷移図ループ４（ステップＳＴ１３０１〜ＳＴ１３０４）の始端である最初のステップＳＴ１３０１では、状態遷移図記憶部１０４に検査済みでない状態遷移図があるかどうかを検査する。全てが検査済みであれば、状態遷移図ループ４を終了し、ステップＳＴ１３０５に進む。一方、検査済みでない状態遷移図があれば、状態遷移図記憶部１０４から、検査済みでない状態遷移図を一つ抽出し、変数ｓ４に格納する（ステップＳＴ１３０２）。次に、変数ｓ４に登録されているアクションのＩＤが全て一意であることを検査する（ステップＳＴ１３０３）。この検査は、一般的な整列アルゴリズム（バブルソート、マージソート、バイナリソート等）を用いて、変数ｓ４に登録されたアクションのＩＤを辞書式順序で整列させた後、隣同士のアクションＩＤが等しくないことを検査することで実現できる。
【００７１】
状態遷移図ループ４の終端である次のステップＳＴ１３０４では、変数ｓ４に格納されている状態遷移図を検査済みとした上で、ステップＳＴ１３０１に戻る。最後に、ステップＳＴ１３０５では、検査対象となった全ての状態遷移図についての検査結果を出力装置２０２上に出力する。具体的には、ステップＳＴ１３０３の検査において、アクションが一意と判定された状態遷移図については、その状態遷移図の識別子と”合格”の文字を表示する。そうでない状態遷移図については、その状態の識別子と、”アクションＩＤの一意性検査不合格”という警告を出力する。すなわち、状態遷移図上で一意に識別できないアクションがある場合、アプリケーション処理再開時に、再開処理部４０４で開始状態の決定が曖昧になることがある。本検査処理では、このような状態遷移図を検出し、出力装置２０２に警告を出力する。この警告を出力装置２０２で見るのは、このセション管理装置上で動作するアプリケーションの利用者である場合もあるし、状態遷移図の開発者である場合もある。セション管理装置の動作前にこの制約検査部６０１を実行する場合は、後者である。
本アクション一意性検査処理では、検査結果が不合格であれば警告を出力するものとしたが、検査結果が不合格の場合、自動的にその状態遷移図をセション管理装置で利用不能にするようにしてもよい。また、別の方法として、検査結果が不合格の場合には、一意に識別できないアクションについて、そのアクションＩＤに自動的に番号を追加するなどしてアクションＩＤを変更し、その状態遷移図上で各アクションが一意に識別できるように自動修正すようにしてもよい。
【００７２】
図３７は共通アクション有無検査処理（ステップＳＴ１２０２）の詳細な流れを示すフローチャートである。
状態遷移図ループ５（ステップＳＴ１４０１〜ＳＴ１４０８）の始端である最初のステップＳＴ１４０１では、まず、状態遷移図記憶部１０４に検査済みでない状態遷移図があるかどうかを検査する。全てが検査済みであれば、状態遷移図ループ５を終了し、ステップＳＴ１４０９に進む。一方、検査済みでない状態遷移図があれば、状態遷移図記憶部１０４から、検査済みでない状態遷移図を一つ抽出し、変数ｓ５に格納する（ステップＳＴ１４０２）。次に、アクションループ５（ステップＳＴ１４０３〜ステップＳＴ１４０７）の始端であるステップＳＴ１４０３では、まず、変数ｓ５に登録されているアクションが全て検査済みかどうかを検査する。全てが検査済みであれば、アクションループ５を終了し、ステップＳＴ１４０８に進む。もし、検査済みでないアクションがあれば、変数ｓ５から検査済みでないアクションＩＤを一つ抽出し、変数ａ５に格納する（ステップＳＴ１４０４）。そして、変数ｓ５および変数ａ５に基づき共通アクション検査処理（ステップＳＴ１４０５）を起動する。
【００７３】
この共通アクション検査処理（ステップＳＴ１４０５）は、実施の形態２を基にした実施の形態４の場合、共通アクション検査部４０１（実施の形態３の場合も同じ構成部）において実行される。また、実施の形態１を基にした場合には、共通アクション検査部１０６において同等の共通アクション検査処理がなされる。
次に、共通アクション検査処理の結果である真偽値を、変数ａ５に格納されたアクションＩＤと共に記憶装置２０１に記憶する（ステップＳＴ１４０６）。次のアクションループ５の終端であるステップＳＴ１４０７では、変数ａ５に格納されているアクションを検査済みとした上で、ステップＳＴ１４０３に戻る。状態遷移図ループ５の終端であるステップＳＴ１４０８では、変数ｓ５に格納されている状態遷移図を検査済みとした上で、ステップＳＴ１４０１に戻る。
【００７４】
最後に、ステップＳＴ１４０６にて記憶装置２０１上に記憶した結果を、表示装置上に一覧表の形式で出力する（ステップＳＴ１４０９）。また、記憶した結果から、共通アクションを含まない状態遷移図がある場合には、”不合格：共通アクションを含まない状態遷移図があります”との警告を出力し、本共通アクション有無検査処理を終了する。一方、状態遷移図上に共通アクションが無い場合、その状態遷移図を用いてアプリケーションの処理を再開する際には、常に初期状態が再開時開始状態となる。すなわち、異なる複数のクライアント間でアプリケーション処理中断後の再開ができなくなる場合がある。本検査処理では、このような状態遷移図を検出し、出力装置２０２に警告を出力する。この警告を出力装置２０２で見るのは、このセション管理装置上で動作するアプリケーションの利用者である場合もあるし、状態遷移図の開発者である場合もある。セション管理装置の動作前にこの制約検査部６０１を実行する場合は、後者である。
本共通アクション有無検査処理では、検査結果が不合格であれば警告を出力するものとしたが、検査結果が不合格の場合、自動的にその状態遷移図をセション管理装置で利用不能にするようにしてもよい。また、別の方法として、検査結果が不合格の場合には、その状態遷移図で作業を再開した場合、常に状態遷移図の初期状態から作業を再開するようにしてもよい。
上述のように、制約検査部６０１は、入力となる状態遷移図について２つの検査、すなわちアクション一意性検査処理および共通アクション有無検査処理を順次行い、それぞれの検査の後、検査結果を出力装置２０２に出力する。
【００７５】
この実施の形態４のバリエーションについて述べる。
上記例では、２つの検査を行っているが、これに加えて、共通アクションが逆順かどうかを検査する共通アクション順序検査処理を行ってもよい。共通アクションが逆順であるとは、例えば、一方の状態遷移図上で、共通アクションの実行順序がＡ−＞Ｂと定義されている場合に、他方の状態遷移図上での前記共通アクションの実行順序がＢ−＞Ａと定義されている場合である。この場合、前者状態遷移図上でＢを実行した後で中断し、後者状態遷移図で再開すると、再開処理部４０４はＢの実行後、かつＡの実行前の状態を再開時開始状態と決定する。ここで、Ａを実行した後で中断する。さらに、前者状態遷移図上で再開すると、再開処理部４０４は、Ａの実行後、かつＢの実行前を再開時開始状態と決定する。その後、Ｂを実行した後で中断するという動作を繰り返すと、アプリケーションの処理が無限ループになる。このような状態を検出する共通アクション順序検査処理を行い、検査結果が不合格の場合は、出力装置２０２上に不合格である旨の警告を出力することで、前記無限ループを予防することができる。
本共通アクション順序検査処理では、検査結果が不合格であれば警告を出力するものとしたが、検査結果が不合格の場合、自動的にその状態遷移図をセション管理装置で利用不能にするようにしてもよい。また、別の方法として、検査結果が不合格の場合には、不合格の原因となった当該アクションのアクションＩＤの一方（例えばＡ−＞Ｂと実行する場合Ｂ）を、他のアクションＩＤと重複しないアクションＩＤに自動的に変更し、アプリケーションの処理が無限ループになるのを自動的に予防するようにしてもよい。
【００７６】
また、上記例では、アクション一意性検査処理、共通アクション有無検査処理および共通アクション順序検査処理は全て実行するものとして扱っているが、任意の検査処理を組み合わせて任意の順序で実行するようにしてもよい。必要な検査処理だけを行うようにすることで、その分制約検査部６０１の実行速度を向上させることができる。
さらに、この例では、制約検査部６０１は、セッション管理装置が動作する前に実行するものとして扱っているが、セッション管理装置動作中に動作させてもよい。ただし、セッション管理装置の実行速度を遅くする可能性があるため、制約検査部６０１はセッション管理装置の動作開始前に実行する方がより好ましい。
このセッション管理装置の動作前に本制約検査部６０１を実行する場合は、状態遷移図記憶部１０４および制約検査部６０１のみが動作して直接状態遷移図の情報をやり取りできればよく、他の構成部は備えなくてもよい。
【００７７】
以上のように、この実施の形態４によれば、制約検査部が、状態遷移図記憶部から一意に識別できないアクションを含む状態遷移図を検出するアクション一意性検査処理手段、状態遷移図記憶部から共通アクションを一つも含まない状態遷移図を検出する共通アクション有無検査処理手段、および状態遷移図記憶部から共通アクションの実行順序が一致しない状態遷移図の組を検出する共通アクション順序検査処理手段として、一つまたは組み合わせの処理を行うようにしたものである。したがって、状態遷移図記憶部上の状態遷移図が、本セッション管理装置が適切に処理できる条件を満たしているかどうかを検出できる効果が得られる。また、制約検査部を本セッション管理装置の起動より前に動作させることで、事前に状態遷移図を検査することができる。
【００７８】
実施の形態５．
この実施の形態５の構成は、実施の形態１、実施の形態２あるいは実施の形態３において、共通アクション検査部（１０６または４０１）の等価性評価処理を置き換えて実現するもので、それ以外の構成は同じである。
この実施の形態５における共通アクション検査部（１０６または４０１）は、実行エンジン（１０９、４０５または５０４）が実行したアクションがＷｅｂサービス呼び出しを行うものであって、かつ状態遷移図から抽出されたＷｅｂサービス呼び出しの他のアクションと、サービス定義の内容およびＷｅｂサービスの接続先が等しい場合、双方のアクションＩＤが異なっていても共通アクションとして検出する。
【００７９】
図３８は実施の形態５の共通アクション検査部（１０６または４０１）における等価性評価処理の流れを示すフローチャートである。
まず、与えられたアクションａ１およびａ２がＷｅｂサービス呼び出しかどうかを検査する（ステップＳＴ１５０１）。アクションａ１およびａ２がＷｅｂサービス呼び出しで無かった場合、図１５で説明した実施の形態１、２、３における処理の流れと同じステップＳＴ３０１〜ＳＴ３０３の処理が実行される。一方、アクションａ１およびａ２がＷｅｂサービス呼び出しの場合、それぞれのアクションに関連付けられているサービス定義情報を取得し、その内容を比較し、内容が一致するかどうかを検査する（ステップＳＴ１５０２）。ここで、サービス定義情報とは、ＵＤＤＩ（Universal Description, Discovery and Integration）を用いて取得できる情報やＷＳＤＬ（Web Service Description Language）などにより定義された情報である。
【００８０】
ステップＳＴ１５０２の検査で、サービス定義情報の内容が一致しなかった場合には、ＦＡＬＳＥを返し（ステップＳＴ１５０３）、処理を終了する。一方、一致した場合には、Ｗｅｂサービスの接続先が等しいかどうかを検査する（ステップＳＴ１５０４）。このＷｅｂサービスの接続先は、サービス定義情報の記述やＷｅｂサービス呼び出しを実現するオブジェクトが保持している情報から取得することができる。接続先が等しい場合には、ＴＲＵＥを返して（ステップＳＴ１５０５）、処理を終了する。また、等しくない場合には、ＦＡＬＳＥを返して（ステップＳＴ１５０３）、処理を終了する。
【００８１】
以上のように、この実施の形態５によれば、実行エンジンで実行したアクションがＷｅｂサービス呼び出しを行うものであって、かつ状態遷移図から抽出されたＷｅｂサービス呼び出しの他のアクションと、サービス定義の内容およびＷｅｂサービスの接続先が等しい場合に、共通アクション検査部によって、共通アクションとして検出するようにしたものである。したがって、Ｗｅｂサービスを利用するアクションについて、その内容からも等価性を判断することができるようになるため、共通アクション検査部が検出する共通アクションが増える。このことにより、再開処理部が再開時開始状態を特定する手がかりが増えるため、本セッション管理装置が発揮する機能の範囲を広げることができる効果が得られる。
【００８２】
実施の形態６．
この実施の形態６の構成は、実施の形態１、実施の形態２あるいは実施の形態３において、共通アクション検査部（１０６または４０１）の等価性評価処理を置き換えて実現するもので、それ以外の構成は同じである。
この実施の形態６の共通アクション検査部（１０６または４０１）は、実行エンジン（１０９または５０４）が実行したアクションがデータベース問い合わせを行うものであり、かつ問い合わせのＳＱＬ（Structured Query Language）文および問い合わせの接続先のデータベースが一致していれば、双方のアクションＩＤが異なっていても共通アクションとして検出する手段である。
【００８３】
図３９は実施の形態６に係る共通アクション検査部（１０６または４０１）における等価性評価処理の処理の流れを示すフローチャートである。
まず、与えられたアクションａ１およびａ２がデータベース問い合わせかどうかを検査する（ステップＳＴ１６０１）。ここで、アクションがデータベース呼び出しかどうかは、そのアクションにデータベース問い合わせ文（ＳＱＬ文）が関連づけられているかどうかにより判断することができる。アクションａ１およびａ２がデータベース問い合わせでなかった場合、図１５で説明した実施の形態１、２、３における処理の流れと同じステップＳＴ３０１〜ＳＴ３０３の処理が実行される。一方、アクションａ１およびａ２がデータベース問い合わせの場合、それぞれのアクションに関連付けられているＳＱＬ文を比較し、その内容が一致するかどうかを検査する（ステップＳＴ１６０２）。一致しなかった場合には、ＦＡＬＳＥを返し（ステップＳＴ１６０３）、処理を終了する。一方、一致した場合には、接続先のデータベースが等しいかどうかを検査する（ステップＳＴ１６０４）。ここで、接続先のデータベースは、データベース問い合わせを実現するオブジェクトが保持している情報から取得することができる。接続先のデータベースが等しい場合には、ＴＲＵＥを返して（ステップＳＴ１６０５）、処理を終了する。一方、等しくない場合には、ＦＡＬＳＥを返して（ステップＳＴ１６０３）処理を終了する。
【００８４】
以上のように、この実施の形態６によれば、リレーショナルデータベースへの問い合わせ文および接続先情報を用いて共通アクションを検出するようにしている。したがって、共通アクション検査部が検出する共通アクションが増え、再開処理部が再開時開始状態を特定する手がかりが増えるため、本セッション管理装置が発揮する機能の範囲を広げることができる効果が得られる。
【図面の簡単な説明】
【００８５】
【図１】この発明の実施の形態１によるセッション管理装置の機能構成を示すブロック図である。
【図２】同実施の形態１の機能構成部を形成するハードウェア構成を示すブロック図である。
【図３】同実施の形態１のセッション管理装置が適用されるシステム構成例を示すブロック図である。
【図４】同実施の形態１に係るアプリケーションデータ記憶部のデータ構造例を示す説明図である。
【図５】同実施の形態１に係るアクション記憶部のデータ構造例を示す説明図である。
【図６】同実施の形態１に係るセッション情報記憶部のデータ構造例を示す説明図である。
【図７】同実施の形態１に係る状態遷移図記憶部のデータ構造例を示す説明図である。
【図８】同実施の形態１に係るＰＣ用ＷＷＷブラウザ向け状態遷移図を例示する説明図である。
【図９】同実施の形態１に係る携帯電話用ＷＷＷブラウザ向け状態遷移図を例示する説明図である。
【図１０】同実施の形態１に係るＪＳＰ形式による画面定義を例示する説明図である。
【図１１】図８に示した状態遷移図を画面定義も含めて視覚化した説明図である。
【図１２】図９に示した状態遷移図を画面定義も含めて視覚化した説明図である。
【図１３】この発明の実施の形態１に係る状態遷移図選択部の処理の流れを示すフローチャートである。
【図１４】同実施の形態１に係る状態遷移図選択部の処理の流れを示すフローチャートである。
【図１５】同実施の形態１に係る等価性評価処理を示すフローチャートである。
【図１６】同実施の形態１に係る共通アクション記憶部のデータ構造例を示す説明図である。
【図１７】同実施の形態１に係る再開処理部の処理の流れを示すフローチャートである。
【図１８（ａ）】同実施の形態１に係る実行エンジンの処理の流れを示すフローチャートである。
【図１８（ｂ）】同実施の形態１に係る実行エンジンの処理の流れを示すフローチャートである。
【図１９（ａ）】同実施の形態１に係る遷移処理およびセッション情報生成処理の流れを示すフローチャートである。
【図１９（ｂ）】同実施の形態１に係る遷移処理およびセッション情報生成処理の流れを示すフローチャートである。
【図１９（ｃ）】同実施の形態１に係る遷移処理およびセッション情報生成処理の流れを示すフローチャートである。
【図２０】同実施の形態１に係るＰＣ用ＷＷＷブラウザ向け状態遷移図の別例を示す説明図である。
【図２１】同実施の形態１に係る携帯電話用ＷＷＷブラウザ向け状態遷移図の別例を示す説明図である。
【図２２】同実施の形態１に係る登録された電話帳登録画面の例を示す説明図である。
【図２３】同実施の形態２によるセッション管理装置の機能構成を示すブロック図である。
【図２４】同実施の形態２に係る共通アクション検査部の処理の流れを示すフローチャートである。
【図２５】同実施の形態２に係る履歴記憶部のデータ構造例を示す説明図である。
【図２６】同実施の形態２に係る履歴保存処理部の処理の流れを示すフローチャートである。
【図２７】同実施の形態２に係る再開処理部の処理の流れを示すフローチャートである。
【図２８】同実施の形態２に係る定義された状態遷移図を例示する説明図である。
【図２９】同実施の形態３によるセッション管理装置の機能構成を示すブロック図である。
【図３０】同実施の形態３に係るアクション記憶部のデータ構造例を示す説明図である。
【図３１】同実施の形態３に係るロールバック処理部の処理の流れを示すフローチャートである。
【図３２】同実施の形態３に係る遷移処理の流れを示すフローチャートである。
【図３３】同実施の形態３に係る定義された状態遷移図を例示する説明図である。
【図３４】同実施の形態４によるセッション管理装置の機能構成を示すブロック図である。
【図３５】同実施の形態４に係る制約検査部の処理の流れを示すフローチャートである。
【図３６】同実施の形態４に係るアクション一意性検査処理の流れを示すフローチャートである。
【図３７】同実施の形態４に係る共通アクション有無検査処理の流れを示すフローチャートである。
【図３８】同実施の形態５に係る共通アクション検査部の等価性評価処理の流れを示すフローチャートである。
【図３９】同実施の形態６に係る共通アクション検査部の等価性評価処理の流れを示すフローチャートである。
【符号の説明】
【００８６】
１０１  アプリケーションデータ記憶部、１０２，５０１  アクション記憶部、１０３  セッション情報記憶部、１０４  状態遷移図記憶部、１０５  状態遷移図選択部、１０６，４０１  共通アクション検査部、１０７  共通アクション記憶部、１０８，４０４，５０２  再開処理部、１０９，４０５，５０４  実行エンジン、４０２  履歴記憶部、４０３  履歴保存処理部、５０３  ロールバック処理部、６０１  制約検査部。
【図１】
2005208759.tif 000003
【図２】
2005208759.tif 000004
【図３】
2005208759.tif 000005
【図４】
2005208759.tif 000006
【図５】
2005208759.tif 000007
【図６】
2005208759.tif 000008
【図７】
2005208759.tif 000009
【図８】
2005208759.tif 000010
【図９】
2005208759.tif 000011
【図１０】
2005208759.tif 000012
【図１１】
2005208759.tif 000013
【図１２】
2005208759.tif 000014
【図１３】
2005208759.tif 000015
【図１４】
2005208759.tif 000016
【図１５】
2005208759.tif 000017
【図１６】
2005208759.tif 000018
【図１７】
2005208759.tif 000019
【図１８（ａ）】
2005208759.tif 000020
【図１８（ｂ）】
2005208759.tif 000021
【図１９（ａ）】
2005208759.tif 000022
【図１９（ｂ）】
2005208759.tif 000023
【図１９（ｃ）】
2005208759.tif 000024
【図２０】
2005208759.tif 000025
【図２１】
2005208759.tif 000026
【図２２】
2005208759.tif 000027
【図２３】
2005208759.tif 000028
【図２４】
2005208759.tif 000029
【図２５】
2005208759.tif 000030
【図２６】
2005208759.tif 000031
【図２７】
2005208759.tif 000032
【図２８】
2005208759.tif 000033
【図２９】
2005208759.tif 000034
【図３０】
2005208759.tif 000035
【図３１】
2005208759.tif 000036
【図３２】
2005208759.tif 000037
【図３３】
2005208759.tif 000038
【図３４】
2005208759.tif 000039
【図３５】
2005208759.tif 000040
【図３６】
2005208759.tif 000041
【図３７】
2005208759.tif 000042
【図３８】
2005208759.tif 000043
【図３９】
2005208759.tif 000044