(57)【要約】【課題】アプリケーションの処理途中で処理が中断した場合でも、中断した時点から続けて処理を実行させる機能を共通化すること。【解決手段】アプリケーションを実行させるための入力データを受け付ける入力受付部１１０と、アプリケーションの一連の処理工程をシナリオとして定義したシナリオ定義情報を記憶するシナリオ記憶部１４０と、シナリオ定義情報に従ってアプリケーションの動作を決定するシナリオ管理部１７０と、各シナリオに含まれるアプリケーションの実行中の処理状態を、シナリオ定義情報と対応付けてセッション管理情報として記憶するセッション記憶部１５０と、を備え、シナリオ定義情報は、セッション管理情報に対応付けられる１以上の処理状態と、各処理状態において入力受付部が受け付ける入力データに対するアプリケーションの動作とを対応付けて定義する、アプリケーション状態管理装置１００が提供される。【選択図】図１
2008059223.tif 000002
【特許請求の範囲】
【請求項１】
実行中のアプリケーションの処理状態を管理するアプリケーション状態管理装置であって、
アプリケーションを実行させるための入力データを受け付ける入力受付部と、
前記アプリケーションの一連の処理工程をシナリオとして定義したシナリオ定義情報を記憶するシナリオ記憶部と、
前記シナリオ定義情報に従って前記アプリケーションの動作を決定するシナリオ管理部と、
前記各シナリオに含まれる前記アプリケーションの実行中の処理状態を、前記シナリオ定義情報と対応付けてセッション管理情報として記憶するセッション記憶部と、
を備え、
前記シナリオ定義情報は、前記セッション管理情報に対応付けられる１以上の処理状態と、前記各処理状態において前記入力受付部が受け付ける入力データに対するアプリケーションの動作とを対応付けて定義することを特徴とする、アプリケーション状態管理装置。
【請求項２】
前記シナリオ管理部の要求に応じて前記セッション記憶部から前記セッション管理情報を読み出し、前記セッション管理情報を設定するセッション管理部をさらに備え、
前記セッション管理部は、前記シナリオの処理を開始するための入力データに対応する前記セッション管理情報が既に前記セッション記憶部に存在する場合、前記セッション管理情報を読み出してシナリオ管理部に渡し、前記入力データに対応する前記セッション管理情報が前記セッション記憶部に存在しない場合、前記アプリケーションの処理状態に応じた前記セッション管理情報を生成し前記セッション記憶部に格納することを特徴とする、請求項１に記載のアプリケーション状態管理装置。
【請求項３】
前記アプリケーションの処理工程中に前記入力受付部によって受け付けられた入力データからイベント情報を生成するイベント情報生成部をさらに備え、
前記シナリオ管理部は、前記イベント情報と、前記セッション管理情報に含まれる前記アプリケーションの実行中の処理状態と、前記シナリオ定義情報とから、次に実行される処理を決定することを特徴とする、請求項１または２のいずれかに記載のアプリケーション状態管理装置。
【請求項４】
前記シナリオ管理部は、前記アプリケーションの所定の処理が実行された後、前記処理の実行結果に基づいて、前記シナリオ定義情報から前記アプリケーションが次に遷移する処理状態を取得し、前記セッション管理部に対し、前記セッション管理情報の更新を依頼することを特徴とする、請求項２または３のいずれかに記載のアプリケーション状態管理装置。
【請求項５】
前記セッション管理情報は、アプリケーションを利用する利用者または前記利用者が使用する端末のいずれかに対応付けられて生成されることを特徴とする、請求項１〜４のいずれかに記載のアプリケーション状態管理装置。
【請求項６】
前記シナリオ定義情報、前記セッション管理情報及び前記イベント情報は、ＸＭＬにより記述され、それぞれを構成する構成要素に対応して定義されたタグを用いて記述されることを特徴とする、請求項１〜５のいずれかに記載のアプリケーション状態管理装置。
【請求項７】
前記シナリオ管理部は、前記イベント情報のルートタグの名称を用いて、前記アプリケーションが次に実行する処理を決定することを特徴とする、請求項６に記載のアプリケーション状態管理装置。
【請求項８】
実行中のアプリケーションの処理状態を管理するアプリケーション状態管理方法であって、
アプリケーションの一連の処理工程を開始するための入力データに対応して、実行中の前記アプリケーションの処理状態を記憶するためのセッション管理情報を取得するセッション管理情報取得ステップと、
前記アプリケーションの処理工程中に入力される入力データから、ＸＭＬで記述されたイベント情報を生成するイベント情報生成ステップと、
前記イベント情報と、前記セッション管理情報に含まれるアプリケーションの処理状態と、前記アプリケーションの一連の処理工程をシナリオとして定義したシナリオ定義情報とを基に、次に実行される処理を決定する実行処理決定ステップと、
前記実行処理決定ステップにおいて決定された処理を実行後、前記処理の実行結果を取得する実行結果取得ステップと、
前記実行結果取得ステップにおいて取得された前記実行結果に基づいて、前記セッション管理情報に含まれる前記アプリケーションの処理状態を更新するセッション管理情報更新ステップと、
を含むことを特徴とする、アプリケーション状態管理方法。
【請求項９】
前記セッション管理情報取得ステップは、
前記入力に対応する前記セッション管理情報が既に存在するか否かを判断するステップと、
前記セッション管理情報が存在しない場合、前記セッション管理情報を生成するステップと、
前記セッション管理情報が既に存在する場合、前記セッション管理情報から前記アプリケーションの処理状態を取得するステップと、
をさらに含むことを特徴とする、請求項８に記載のアプリケーション状態管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アプリケーション状態管理装置に係り、特に、ＸＭＬデータを利用して、アプリケーションプロセスの状態管理を行うアプリケーション状態管理装置に関する。
【背景技術】
【０００２】
パーソナルコンピュータやインターネットの普及とともに、コンピュータや携帯電話、ＰＤＡ等の端末のブラウザ上で動作するＷｅｂアプリケーションの利用が拡大してきている。Ｗｅｂアプリケーションは、Ｗｅｂクライアントであるコンピュータや携帯電話端末等からネットワークを経由して送信される要求に応じ、アプリケーションが設置されたＷｅｂサーバが処理を行い、処理結果をＷｅｂクライアント側に返すアプリケーションである。ユーザは、Ｗｅｂクライアント上のブラウザを通してＷｅｂサーバ上のアプリケーションに対し要求を送り、処理結果を閲覧することにより、Ｗｅｂアプリケーションを利用することができる。具体的には、インターネットショッピングやインターネットオークション、インターネットバンキング等、様々な形態のＷｅｂアプリケーションが利用されている。
【０００３】
このようなＷｅｂアプリケーションの開発において、複数のアプリケーション、またはアプリケーションを構成する複数の機能に共通する部分を抽出し、基盤機能として共通化したものを用いることにより、ソフトウェアの改変や機能追加を容易にするための仕組みが提案されている。
【０００４】
例えば、特許文献１には、異なるアプリケーションに共通する汎用的な機能を備えた基本機能部と、アプリケーション毎に異なる動作を規定した電子文書とを組み合わせることにより、各アプリケーションを動作させる方法が提案されている。電子文書は、各アプリケーションの処理フローや、表示画面に表示する要素や配置位置等をＸＭＬ等で記述したもので、アプリケーションは、外部から入力された電子文書を読み込んで、基本機能部に備えられた機能を実行することにより動作する。この方法によると、各アプリケーション固有の機能を電子文書で提供し、アプリケーションの機能の変更や追加を行う場合でも、電子文書の記述内容を変更するだけでよいため、プログラムを改変する手間を省略することができる。
【０００５】
また、特許文献２には、個々に独立した企業アプリケーションやデータベース、ミドルウェア等を統合するためのコンポーネントについて記載されている。上記コンポーネントは、アプリケーション間の共通言語であるＸＭＬ等で記述したアプリケーションビューを提供することにより、あるアプリケーションが別のアプリケーションの機能にアクセスすることができるようにするものである。また、アプリケーションビューは、２つのアプリケーション間での双方向通信を可能にし、アプリケーション間でメッセージ交換することによってアプリケーションの統合を可能にする方法が開示されている。
【０００６】
【特許文献１】特開２００３−２１６４２７号公報
【特許文献２】国際公開第０３／０３４２８５号パンフレット
【発明の開示】
【発明が解決しようとする課題】
【０００７】
Ｗｅｂアプリケーションでは、アプリケーションで何らかの作業中にネットワークの接続が切断されてしまったり、ユーザ端末に不具合が発生して異常終了してしまったりすることによって、アプリケーションの処理が中断してしまう。このような場合、ユーザ端末を交換する等して再び同じアプリケーションを起動しても、多くの場合、作業途中のデータが失われてしまっており、再びアプリケーションの最初から処理を行わなければならないという問題がある。また、同一のユーザが複数の端末から同一のアプリケーションを利用する場合においても同様に、端末を変更した後で、変更前の処理を継続して行うことができない。例えば、コンピュータ端末からＷｅｂアプリケーションを利用して検索処理等を行った結果を、外出先でも携帯電話端末から引き続き利用したいというような場合、携帯電話端末側で、再度検索処理を最初から実行させなければならない。
【０００８】
また、アプリケーションの入出力手段として、例えば電子メールのような非同期的な通信手段を用いる場合、現状では、メールを最初のデータ入力とするか、あるいは、メールをレシートのような最終出力とするかのいずれかのパターンで利用されることが多い。電子メールのような非同期的な入出力を繰り返してアプリケーションを実行させる場合には、データ入出力の途中でアプリケーションプロセスが中断しても、データ入力があった時点で再び中断したプロセスを継続して実行させるための情報を保持しておく必要がある。
【０００９】
このような問題に対処するために、アプリケーション側で処理の状態や処理途中のデータを随時保存しておくことにより、処理が中断した場合であっても、中断前の状態をある程度回復することができるような仕組みが提供される場合もある。しかし、現状では、アプリケーション側でこのような仕組みを提供する場合、各アプリケーション毎に異なるデータベースの構成や処理内容に対応するため、各アプリケーション毎に個別に開発が行われている。しかし、このような仕組みは、多くのＷｅｂアプリケーションにおいて共通して要求されるものであり、アプリケーション毎に開発を行うのは非効率的という問題がある。
【００１０】
そこで、本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、アプリケーションの処理途中で処理が中断した場合でも、中断した時点から続けて処理を実行させる機能を共通化することが可能な、新規かつ改良されたアプリケーション状態管理装置を提供することにある。
【課題を解決するための手段】
【００１１】
上記課題を解決するために、本発明のある観点によれば、実行中のアプリケーションの処理状態を管理するアプリケーション状態管理装置であって、アプリケーションを実行させるための入力データを受け付ける入力受付部と、アプリケーションの一連の処理工程をシナリオとして定義したシナリオ定義情報を記憶するシナリオ記憶部と、シナリオ定義情報に従ってアプリケーションの動作を決定するシナリオ管理部と、各シナリオに含まれるアプリケーションの実行中の処理状態を、シナリオ定義情報と対応付けてセッション管理情報として記憶するセッション記憶部と、を備えるアプリケーション状態管理装置が提供される。また、シナリオ定義情報は、セッション管理情報に対応付けられる１以上の処理状態と、各処理状態において入力受付部が受け付ける入力データに対するアプリケーションの動作とを対応付けて定義する。
【００１２】
かかる構成により、アプリケーションの処理途中の状態をセッション管理情報として記憶させることができる。これにより、アプリケーション処理プロセスの中断後に、セッション管理情報を参照することによって、中断した時点からアプリケーションの処理を継続することが可能となる。さらに、通常は継続性を持たせることができない電子メールのような非同期的な通信手段を用いて、複数回の電子メール交換により処理が完了する会話型アプリケーションを実装することができるという効果が得られる。
【００１３】
また、シナリオ管理部の要求に応じてセッション記憶部からセッション管理情報を読み出し、セッション管理情報を設定するセッション管理部をさらに備えてもよい。さらに、セッション管理部は、シナリオの処理を開始するための入力データに対応するセッション管理情報が既にセッション記憶部に存在する場合、セッション管理情報を読み出してシナリオ管理部に渡し、入力データに対応するセッション管理情報がセッション記憶部に存在しない場合、アプリケーションの処理状態に応じたセッション管理情報を生成しセッション記憶部に格納するようにしてもよい。
【００１４】
また、アプリケーションの処理工程中に入力受付部によって受け付けられた入力データからイベント情報を生成するイベント情報生成部をさらに備えてもよい。さらに、シナリオ管理部は、イベント情報と、セッション管理情報に含まれるアプリケーションの実行中の処理状態と、シナリオ定義情報とから、次に実行される処理を決定するようにしてもよい。
【００１５】
また、シナリオ管理部は、アプリケーションの所定の処理が実行された後、処理の実行結果に基づいて、シナリオ定義情報からアプリケーションが次に遷移する処理状態を取得し、セッション管理部に対し、セッション管理情報の更新を依頼するようにしてもよい。このように、アプリケーションの処理の進行状況に従ってセッション管理情報を更新することにより、セッション管理情報から最新の処理状態を取得することができる。
【００１６】
また、セッション管理情報は、アプリケーションを利用する利用者に対応付けられて生成されてもよい。これにより、アプリケーションの処理を利用者毎に管理することができ、処理中断後にユーザＩＤ等を入力してアプリケーションにログオンすることによって、セッション管理情報を継承することができる。また、ユーザ端末を変更しても、同じユーザであれば継続して処理を実行することができるため、アプリケーションの端末依存性がなくなるという効果が得られる。
【００１７】
また、シナリオ定義情報、セッション管理情報及びイベント情報は、ＸＭＬにより記述され、それぞれを構成する構成要素に対応して定義されたタグを用いて記述されるようにしてもよい。これにより、アプリケーション毎に、それぞれの情報に保存されるデータの構造を簡単に変更したり、あるいは構成要素を追加することができる。したがって、複数の異なるアプリケーションで共通の仕組みを利用することができ、アプリケーション開発の効率化という効果が得られる。
【００１８】
また、シナリオ管理部は、イベント情報のルートタグの名称を用いて、アプリケーションが次に実行する処理を決定するようにしてもよい。
【００１９】
また、上記課題を解決するために、本発明の別の観点によれば、実行中のアプリケーションの処理状態を管理するアプリケーション状態管理方法であって、アプリケーションの一連の処理工程を開始するための入力データに対応して、実行中のアプリケーションの処理状態を記憶するためのセッション管理情報を取得するセッション管理情報取得ステップと、アプリケーションの処理工程中に入力される入力データから、ＸＭＬで記述されたイベント情報を生成するイベント情報生成ステップと、イベント情報と、セッション管理情報に含まれるアプリケーションの処理状態と、前記アプリケーションの一連の処理工程をシナリオとして定義したシナリオ定義情報とを基に、次に実行される処理を決定する実行処理決定ステップと、実行処理決定ステップにおいて決定された処理を実行後、処理の実行結果を取得する実行結果取得ステップと、実行結果取得ステップにおいて取得された実行結果に基づいて、セッション管理情報に含まれるアプリケーションの処理状態を更新するセッション管理情報更新ステップと、を含むアプリケーション状態管理方法が提供される。
【００２０】
かかる構成により、アプリケーションの処理途中の状態をセッション管理情報として記憶し、処理中断後にセッション管理情報を参照することによって、中断した時点からアプリケーションの処理を継続することが可能となる。これにより、シンクライアントにおけるステートフルなアプリケーションの実行が可能になるという効果が得られる。さらに、通常は継続性を持たせることができない電子メールのような非同期的な通信手段を用いて、複数回の電子メール交換により処理が完了する会話型アプリケーションを実装することができるという効果が得られる。
【００２１】
また、セッション管理情報取得ステップは、入力に対応するセッション管理情報が既に存在するか否かを判断するステップと、セッション管理情報が存在しない場合、セッション管理情報を生成するステップと、セッション管理情報が既に存在する場合、セッション管理情報からアプリケーションの処理状態を取得するステップと、をさらに含むようにしてもよい。
【発明の効果】
【００２２】
以上説明したように、本発明によれば、アプリケーションの処理途中で、処理が中断した場合でも、中断した時点から続けて処理を実行させる機能を共通化することが可能となる。
【発明を実施するための最良の形態】
【００２３】
以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
【００２４】
（第１の実施形態）
まず、本発明の第１の実施形態にかかるアプリケーション状態管理装置について説明する。図１は、本発明の第１の実施形態にかかるアプリケーション状態管理装置１００の概略構成を示すブロック図である。
【００２５】
本実施形態においては、アプリケーション状態管理装置１００を、電子メールによる非同期通信を用いて同期的に処理を行うアプリケーションの状態を管理する装置として適用した場合の例について説明する。このようなアプリケーションの例として、ここでは、電子メールを入出力データとしてユーザに路線情報を提供するアプリケーションの例を用いて説明する。上記アプリケーションでは、列車の経路検索、時刻表検索等の機能を備え、電子メールによる非同期通信を複数回実行することにより、時刻表検索等の機能の一連の処理が成立する。また、本実施形態にかかるアプリケーション状態管理装置１００は、同一ユーザが一機能を実行する処理の開始から終了までを１つのセッションとして管理する。即ち、電子メールの送信元及び送信先のメールアドレスに基づいて、セッションを割当て、管理するものとする。
【００２６】
本実施形態にかかるアプリケーション状態管理装置１００は、図１に示すように、入力受付部１１０と、セッションＩＤ生成部１２０と、イベント生成部１３０と、シナリオ記憶部１４０と、セッション記憶部１５０と、セッション管理部１６０と、シナリオ管理部１７０と、アクション実行部１８０とにより構成される。以下、アプリケーション状態管理装置１００の各部についてそれぞれ説明する。
【００２７】
入力受付部１１０は、アプリケーションに入力された入力データを受け付け、他の機能部に渡すための機能部である。本実施形態においては、入力データとしてメールサーバから送信された電子メールを受信し、受信した電子メールは、セッションＩＤ生成部及びイベント生成部に渡される。
【００２８】
セッションＩＤ生成部１２０は、各セッションを識別するためのセッションＩＤを生成する機能部である。セッションＩＤ生成部１２０は、例えば、送信元メールアドレスを基に、所定の方式にしたがってそれと対応するセッションＩＤを生成し、シナリオ管理部１７０に渡す。セッションＩＤの生成には、例えば、メールアドレスの一部、例えば「＠」記号より前の部分等を抽出して加工する等の方法を用いてもよい。あるいは、事前に登録されたユーザのメールアドレスから、各メールアドレスに対応するユーザＩＤを生成してデータベースに登録しておき、電子メールによる入力があった時点で、データベースを参照して該当するメールアドレスに対応するユーザＩＤを取得し、ユーザＩＤを加工したものをセッションＩＤとして用いてもよい。また、セッションＩＤの生成には、送信元メールアドレスの他に、送信先メールアドレスや電子メールのタイトル、あるいは、電子メールの本文を解析して抽出した情報を用いてもよいし、これらを複数組み合わせて用いてもよい。
【００２９】
イベント生成部１３０は、入力データである電子メールを解析し、イベント情報を生成するための機能部である。イベント情報は、例えば、ＸＭＬ等のマークアップ言語で記述された文書として生成される。図２は、イベント生成部１３０が電子メールから生成するイベント情報の例を示した説明図である。図２を参照して説明すると、例えば、時刻表検索のアプリケーションを用いて「東京」駅を出発する列車の時刻表を検索する場合、本文に「東京駅」あるいは「東京」と書かれた電子メール１３１が、入力受付部１１０を経由してイベント生成部１３０に入力される。イベント生成部１３０は、入力された電子メール１３１の本文１３２の内容を解析して、駅名に該当する部分１３２ａの「東京」を抽出し、イベント情報１３３を生成する。生成されるイベント情報１３３は、例えば、ＸＭＬで記述されたＸＭＬ文書であって、検索対象の駅名「東京」を、駅名を表すタグ「＜station＞＜/station＞」で囲んで記述したものである。これにより、イベント情報１３３は、駅名入力に対応する入力値が「東京」であることが識別できるように構成されている。なお、ここで示したイベント情報は一例であって、イベント情報に含まれる構成要素やその記述方法等については、各アプリケーションで任意に定めることができる。
【００３０】
シナリオ記憶部１４０は、アプリケーションに含まれるある一連の処理の開始から終了までのアプリケーションの動作を定義したシナリオ定義情報を記憶するための記憶部である。シナリオ定義情報に定義される、アプリケーションの一連の処理の開始から終了までをシナリオと呼ぶ。シナリオは、アプリケーションで行われる連続した処理を任意の単位で１つとしてまとめて定義するためのものであり、シナリオとして定義する処理の単位は、任意に定めることができる。例えば、上述した路線情報検索のアプリケーションのように、複数の機能から構成されるアプリケーションの場合、経路検索機能、時刻表検索機能等の各機能毎に１つのシナリオを割り当ててもよい。あるいは、アプリケーションの起動から終了までを１つのシナリオとしてもよいし、１人のユーザがアプリケーションに対しログイン処理を行ってからログアウトするまでの間を１つのシナリオとしてもよい。
【００３１】
図３は、シナリオ記憶部１４０に記憶されるシナリオ定義情報の例を示した説明図である。図３を参照して説明すると、シナリオ記憶部１４０は、１つ以上のシナリオ定義情報１４１を含む。シナリオ定義情報１４１は、ＸＭＬ等のマークアップ言語により記述されることができる。各シナリオ定義情報１４１は、例えば、シナリオＩＤ１４１ａ、シナリオ名１４１ｂ、状態リスト１４１ｃ等を含んで構成される。シナリオＩＤ１４１ａ及びシナリオ名１４１ｂは、シナリオを識別するための情報であり、状態リスト１４１ｃは、シナリオに含まれるアプリケーションの処理状態を定義した状態定義情報１４２のリストである。
【００３２】
さらに、各状態定義情報１４２は、例えば、状態ＩＤ１４２ａ、状態名１４２ｂ、イベントリスト１４２ｃ等を含んで構成される。状態ＩＤ１４２ａ及び状態名１４２ｂは、状態を識別するための情報であり、イベントリスト１４２ｃは、各状態において入力を受け付けるイベント情報に対するアプリケーションの動作（以下、アクションという）を定義したイベント定義情報１４３のリストである。
【００３３】
さらに、各イベント定義情報１４３は、例えば、イベント情報を識別するイベントＩＤ１４３ａ、イベント情報に対するアクションを示すアクション名１４３ｂ、及びアクション実行後にアプリケーションが遷移する処理状態を示す次状態リスト１４３ｃ等を含んで構成される。次状態リスト１４３ｃには、アクション実行の実行結果とそれに基づくアプリケーションの次の状態を対応付けて定義されている。
【００３４】
このようなシナリオ定義情報１４１により、例えば、時刻表検索機能のシナリオにおいて、アプリケーションが「駅名入力状態」であるとき、駅名を含むＸＭＬ形式のイベント情報が入力されると、そのイベント情報のルートタグの名称「station」から、次に実行すべきアクションの名称「駅名検索」を取得することができる。さらに、「駅名検索」実行後、検索処理が成功、即ち、入力された駅名に該当する駅が検索されたら、状態２に遷移し、検索処理が失敗、即ち、該当する駅名が検索されなかったら、状態１、即ち「駅名入力状態」のままであることが、シナリオ定義情報１４１において定義されている。
【００３５】
セッション記憶部１５０は、アプリケーションで実行中の処理状態を管理するためのセッション管理情報を記憶する記憶部である。本実施形態の例によると、同一ユーザの１つの機能の処理開始から終了までを１つのセッションとして管理し、セッション記憶部１５０は、セッション開始から終了までの間、アプリケーションの処理状態と処理中のデータとを記憶する。図４は、セッション記憶部１５０に記憶されるセッション管理情報の例を示した説明図である。図４を参照して説明すると、セッション記憶部１５０には、各セッションＩＤ１５２と１対１に対応するセッション管理情報１５１が記憶される。セッション管理情報１５１は、例えば、セッションＩＤ１５２、現在実行中の機能を示すシナリオ名（またはシナリオＩＤ）１５３、現在実行中のシナリオ中の状態を示す状態名（または状態ＩＤ）１５４、実行中のアプリケーションのデータ１５５等を含んで構成される。
【００３６】
セッション管理部１６０は、セッション記憶部１５０に記憶されたセッション管理情報の生成、読出し及び更新を行うための機能部である。シナリオ管理部１７０からセッションＩＤが入力されると、セッション管理部１６０は、そのセッションＩＤに該当するセッション管理情報１５１が存在しない場合は、セッション管理情報１５１を生成してセッション記憶部１５０に記憶させる。該当するセッション管理情報１５１が既に存在する場合、そのセッション管理情報１５１を読み出し、実行中のシナリオを示すシナリオ名または処理状態を示す状態名の少なくともいずれか１つをシナリオ管理部１７０に渡す。また、シナリオ管理部１７０からセッション管理情報１５１の更新要求があった場合は、シナリオ管理部１７０から入力されたセッションＩＤに該当するセッション管理情報１５１を読出し、入力された状態名またはアプリケーションのデータをセッション管理情報１５１に設定する。さらに、セッション終了時には、シナリオ管理部１７０からの要求に基づいて、セッション管理情報１５１をセッション記憶部１５０から消去するようにしてもよい。
【００３７】
シナリオ管理部１７０は、シナリオ定義情報を参照して、アプリケーションが次に実行すべきアクションを決定し、アクション実行部１８０に通知するための機能部である。より詳細にシナリオ管理部１７０の動作を説明すると、まず、シナリオ管理部１７０は、セッションＩＤ生成部１２０から入力されたセッションＩＤに対応するセッション管理情報１５１をセッション管理部１６０から取得する。次に、取得したセッション管理情報１５１から、現在実行中のシナリオと、シナリオ中の現在の処理状態を取得する。さらに、セッション管理情報１５１から取得した現在実行中のシナリオに該当するシナリオ定義情報１４１をシナリオ記憶部１４０から読み出し、セッション管理情報１５１から取得した現在の処理状態と、イベント情報１３３とから、対応するアクション名を取得する。このようにして取得したアクション名は、アクション実行部１８０に通知される。
【００３８】
また、アクション名に該当する処理の実行結果がアクション実行部１８０から入力されると、シナリオ管理部１７０は、入力された実行結果に対応する、アプリケーションの次の状態をシナリオ定義情報１４１からを取得する。取得した状態名は、セッション管理情報の更新要求とともに、セッション管理部１６０に通知される。
【００３９】
アクション実行部１８０は、シナリオ管理部１７０から通知されるアクション名に対応する処理を実行するための機能部である。シナリオ管理部１７０からは、アクション名とともにイベント生成部１３０で生成されたイベント情報が入力される。アクション実効部は、例えば、そのアクション名に対応付けられた処理プログラムを起動し、入力パラメータとしてイベント情報を解析して得られた値を入力する。処理が終了すると、実行結果のデータをシナリオ管理部に送る。また、実行結果をアプリケーションの出力データとして、電子メールでユーザに対し送信するようにしてもよいし、あるいは、ディスプレイ等の出力装置を通して出力するようにしてもよい。
【００４０】
以上、本実施形態にかかるアプリケーション状態管理装置１００の構成について説明した。なお、セッションＩＤ生成部１２０、イベント生成部１３０、セッション管理部１６０、シナリオ管理部１７０及びアクション実行部１８０は、サーバ等の情報処理装置にインストールされた、上述した各機能を実行可能なプログラムモジュールで構成されてもよい。また、シナリオ記憶部１４０及びセッション記憶部１５０は、例えば、半導体メモリ、光ディスク、磁気ディスク等の各種の記憶媒体等で構成されてもよい。
【００４１】
次に、図５及び図６に基づいて、上記のような構成のアプリケーション状態管理装置１００を用いたアプリケーションの状態管理方法について説明する。図５及び図６は、本実施形態にかかるアプリケーション状態管理装置１００を用いたアプリケーションの状態管理処理の流れを示すフローチャートである。なお、以下の説明においても、上述した路線情報を提供するアプリケーションの例を用いて、時刻表検索を行う処理の場合の例について説明する。
【００４２】
まず、ステップＳ２００において、ユーザ端末から送信された電子メールを受信する。ここで、受信する電子メールは、例えば、図２に示す電子メール１３１である。
【００４３】
次いで、ステップＳ２０１において、電子メールの送信元メールアドレスから、セッションＩＤを生成する。セッションＩＤの生成は、例えば、メールアドレスの一部、例えば「＠」記号より前の部分等を抽出して加工する等の方法を用いてもよいし、あるいは、メールアドレスとそれに対応するユーザＩＤを事前に登録したデータベースを参照して、該当するメールアドレスに対応するユーザＩＤを取得し、ユーザＩＤを加工したものをセッションＩＤとして用いてもよい。
【００４４】
さらに、ステップＳ２０２において、電子メールを解析して実行されるシナリオを決定する。シナリオの決定には、電子メールの送信元メールアドレス、送信先メールアドレスや電子メールのタイトル、あるいは、電子メールの本文を解析して抽出した情報を用いてもよいし、これらを複数組み合わせて用いてもよい。例えば、図２に示す電子メール１３１の場合、予め送信先メールアドレス「timetable@yyy.com」とシナリオとを対応付けたテーブルを作成しておき、該当するシナリオ「時刻表検索」が決定されるようにしてもよい。
【００４５】
次いで、ステップＳ２０３において、ステップＳ２０１で生成したセッションＩＤに対応するセッション管理情報がセッション記憶部１５０に記憶されているかどうかを検索する。ステップＳ２０４で、検索結果から該当するセッション管理情報が既に存在する場合は、ステップＳ２０７に移動する。
【００４６】
セッション管理情報が存在しない場合は、ステップＳ２０５で、対応するセッション管理情報を生成し、ステップＳ２０６で初期化する。具体的には、セッション管理情報に含まれるセッションＩＤ、シナリオ名、状態名等のデータを設定する。例えば、セッションＩＤには、ステップＳ２０１で生成されたセッションＩＤが設定され、シナリオ名には、ステップＳ２０２で決定されたシナリオのシナリオ名「時刻表検索」が設定される。初期化時の場合、状態名には通常シナリオ中の１番最初の初期状態が設定され、例えば、「時刻表検索」シナリオの初期状態である「駅名入力状態」が設定される。
【００４７】
次いで、ステップＳ２０７において、受信した電子メールを解析して、例えば図２に示すようなＸＭＬ形式のイベント情報１３３を生成する。
【００４８】
次いで、ステップＳ２０８において、生成したイベント情報に対する処理を実行する。具体的には、まず、ステップＳ２０９において、セッションＩＤに対応するセッション管理情報を取得する。さらに、取得したセッション情報から、ステップＳ２１０において、実行中のシナリオ名「時刻表検索」及び状態名「駅名入力状態」を取得する。
【００４９】
次いで、ステップＳ２１１で、ステップＳ２０７で生成されたイベント情報１３３と、ステップＳ２１０において取得したシナリオ名「時刻表検索」及び状態名「駅名入力状態」を基に、シナリオ定義情報に定義されているアクションを取得する。イベントを識別する識別子としては、例えば、ＸＭＬで記述されたイベント情報のルートタグの名称を用いて識別するようにしてもよい。図３の例では、シナリオ「時刻表検索」と、状態名「駅名入力状態」と、イベント情報１３３のルートタグの名称「station」とから、対応するアクション「駅名検索」を取得することができる。
【００５０】
ステップＳ２１２では、取得したアクション「駅名検索」に基づいて、駅名検索処理を実行する。入力パラメータは、ステップＳ２０７で生成されたイベント情報１３３を解析することにより取得されるものを用いる。ここでは、駅名に該当する「東京」が入力パラメータとして用いられ、「東京」に該当する駅とその路線が検索される。路線リストが検索された場合、セッション管理情報１５０のアプリケーションデータ１５５に路線リストが設定される。また、電子メールによりユーザ端末に検索結果である路線リストが送信されるようにしてもよい。あるいは、検索処理が失敗、即ち該当する駅名が存在しなかった場合、その旨を通知する電子メールが送信されるようにしてもよい。
【００５１】
ステップＳ２１３では、ステップＳ２１２の実行結果をキーとして、シナリオ定義情報から次の状態を取得する。例えば、検索処理が成功し、路線リストが取得された場合、次の状態「路線選択」が取得される。検索処理が失敗した場合は、状態は「駅名入力」のままとなる。
【００５２】
次いで、ステップＳ２１４において、ステップＳ２１３で取得した次の状態「路線選択状態」を、セッション管理情報に設定し、ステップＳ２００に戻る。
【００５３】
ステップＳ２１３の実行後、所定の時間間隔を経た後、ステップＳ２００において、再びユーザ端末から、選択した路線等を記載した電子メールが入力されると、再びステップＳ２００〜Ｓ２１４の処理を実行する。ここで、入力された電子メールの送信メールアドレスが前回ステップＳ２００で入力された電子メールの送信メールアドレスと同一の場合、続くステップＳ２０３において、セッションＩＤに対応するセッション管理情報が検索され、ステップＳ２０８〜Ｓ２１４のイベント処理において、検索されたセッション管理情報を用いることができる。したがって、ステップＳ２１０において取得される実行中のシナリオ名及び状態名は、「時刻表検索」及び「路線選択状態」となる。さらに、セッション管理情報に保存された前回処理の処理結果である路線リスト等を用いて、「路線選択状態」に応じた入力データに対する処理を、引き続き実行することが可能となる。
【００５４】
このように、１回目の入力による処理結果をセッション管理情報として記憶させることで、２回目の入力が行われた後でも、引き続きその情報を利用して処理を継続して実行させることが可能となる。したがって、通常は継続性を持たせることができない電子メールのような非同期的な通信手段を用いて、複数回の電子メール交換により処理が完了する会話型アプリケーションを実装することができるという効果が得られる。
【００５５】
以上、本実施形態にかかるアプリケーション状態管理装置１００を用いたアプリケーションの状態管理処理について説明した。
【００５６】
（第２の実施形態）
次に、本発明の第２の実施形態にかかるアプリケーション状態管理装置の処理について説明する。本実施形態においては、アプリケーション状態管理装置をＷｅｂアプリケーションの処理状態を管理する装置として適用した場合に、アプリケーションの処理途中でＷｅｂサーバとユーザ端末との接続が切断したときの処理の例について説明する。なお、本実施形態にかかるアプリケーション状態管理装置の構成及び各構成要素の機能は、第１の実施形態にかかるアプリケーション状態装置１００と実質的に同一であるので、重複説明を省略する。以下、図７及び図８に基づいてアプリケーション状態装置１００を用いたＷｅｂアプリケーションの状態管理処理の流れについて説明する。
【００５７】
まず、ステップＳ３００において、ユーザ端末からアプリケーションへのログイン処理が行われる。ログイン処理は、ユーザＩＤとパスワードをユーザ端末から入力して送信することにより行われてもよいし、あるいは、他の既存の認証方法を用いた方法によりおこなわれてもよい。
【００５８】
次いで、ステップＳ３０１において、入力されたユーザＩＤから、セッションＩＤを生成する。
【００５９】
次いで、ステップＳ３０２において、実行されるシナリオを決定し、シナリオの初期状態を取得する。
【００６０】
次いで、ステップＳ３０３において、ステップＳ３０１で生成したセッションＩＤに対応するセッション管理情報がセッション記憶部１５０に記憶されているかどうかを検索し、ステップＳ３０４で検索結果を判定する。
【００６１】
セッション管理情報が存在しない場合は、ステップＳ３０５で、対応するセッション管理情報を生成し、ステップＳ３０６でセッションＩＤ、シナリオ名、状態名等のデータをセッション管理情報に設定して初期化する。
【００６２】
ステップＳ３０７において、ユーザ端末からの処理要求を受け付け、次いでステップＳ３０８において、入力されたデータからＸＭＬ形式のイベント情報を生成する。
【００６３】
次いで、ステップＳ３０９において、生成したイベント情報に対する処理を実行する。
ステップＳ３０９におけるイベント情報処理は、上述した第１の実施形態におけるイベント情報処理ステップＳ２０８と実質的に同一であるため、重複説明を省略する。
【００６４】
ステップＳ３０９のイベント情報処理が正常に終了したら、ステップＳ３０７に戻り、ユーザ端末からの処理要求入力待ち状態となる。
【００６５】
ここで、ユーザ端末、またはユーザ端末とＷｅｂサーバを接続するネットワークに障害が発生し、アプリケーションが停止した場合を仮定する。あるいは、ユーザが、使用中のユーザ端末での処理を中止し、別の端末と交換した場合であってもよい。
【００６６】
ステップＳ３００において、再度同じまたは異なるユーザ端末から、アプリケーションへのログイン処理が行われる。
【００６７】
次いで、ステップＳ３０１において、ステップＳ３００で入力されたユーザＩＤからセッションＩＤを生成する。ここで、生成されるセッションＩＤは、１回目のログイン時に生成されたセッションＩＤと同一の値である。
【００６８】
次いで、ステップＳ３０２において、実行されるシナリオを決定し、シナリオの初期状態を取得する。さらに、ステップＳ３０３において、生成したセッションＩＤに対応するセッション管理情報がセッション記憶部１５０に記憶されているかどうかを検索する。
【００６９】
ここで、１回目のログイン時に生成されたセッション管理情報が検索されるため、ステップＳ３０４で、セッション管理情報が存在すると判定され、ステップＳ３１０に進む。
【００７０】
ステップＳ３１０で、検索されたセッション管理情報を基に、アプリケーションの状態を復元する。より詳細には、例えば、アプリケーションの処理状態を取得し、その状態に応じた表示画面のＨＴＭＬデータをユーザ端末に送信して表示されるようにしたり、あるいは、処理途中のデータを取得し、ユーザ端末に送信して画面に表示されるデータを更新する等の処理を行う。具体的には、例えば、列車の時刻表検索を行うＷｅｂアプリケーションにおいて、検索対象の駅名が入力され、駅名に対応する路線検索が終了した時点で処理が中断された場合、次に同じユーザがログインしたとき、セッション管理情報内に格納されている路線検索結果のデータを用いて、路線検索結果一覧の表示画面をユーザ端末に表示させる。
【００７１】
次いで、ステップＳ３０７で、ユーザ端末からの処理要求の入力を受け付ける。上述の列車の時刻表検索アプリケーションの場合、ユーザ端末に表示されている路線検索結果一覧から１つの路線が選択され、選択値が入力受付部１１０を通じて入力される。
【００７２】
次いで、ステップＳ３０８で、入力されたデータからＸＭＬ文書のイベント情報を生成する。
【００７３】
次いで、ステップＳ３０９において、生成したイベント情報に対する処理を実行する。即ち、セッション管理情報から実行中の処理状態を取得し、取得した処理状態とイベント情報を用いてシナリオ定義情報を検索し、実行すべきアクションを取得する。
【００７４】
上述したように、アプリケーション処理プロセスの中断後に、中断した時点からアプリケーションの処理を継続することが可能となる。これにより、シンクライアントにおけるステートフルなアプリケーションの実行が可能になるという効果が得られる。また、セッション管理情報、シナリオ定義情報、イベント情報等をＸＭＬを用いて管理することで、異なるアプリケーション間で共通の仕組みを利用することができ、アプリケーション開発の効率化という効果が得られる。
【００７５】
また、継続中のアプリケーション処理プロセスのセッション管理情報が、ユーザに対応させておくことによって、中断後にログオンシーケンスを実行することによって、セッション管理情報を継承することができる。また、中断前と中断後との間で、ユーザ端末を変更した場合であっても、同じユーザであれば継続して処理を実行することができる。即ち、アプリケーションの端末依存性がなくなるという効果が得られる。
【００７６】
さらに、ログオンシーケンスで処理を開始したユーザのＩＤを用いて、サービス提供者側でユーザのセッション管理情報を参照することも可能である。これにより、ユーザのアプリケーション処理状況を確認しながら、サービス提供者がアプリケーションに関するユーザ支援を行うことが可能になるという利点が得られる。
【００７７】
以上、添付図面を参照しながら本発明の好適な実施形態について説明したが、本発明は係る例に限定されないことは言うまでもない。当業者であれば、特許請求の範囲に記載された範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、それらについても当然に本発明の技術的範囲に属するものと了解される。
【図面の簡単な説明】
【００７８】
【図１】本発明の第１の実施形態にかかるアプリケーション状態管理装置の概略構成を示すブロック図である。
【図２】同実施形態にかかるイベント生成部が電子メールから生成するイベント情報の例を示した説明図である。
【図３】同実施形態にかかるシナリオ記憶部に記憶されるシナリオ定義情報の例を示した説明図である。
【図４】同実施形態にかかるセッション記憶部に記憶されるセッション管理情報の例を示した説明図である。
【図５】本実施形態にかかるアプリケーションの状態管理処理の流れを示すフローチャートである。
【図６】本実施形態にかかるアプリケーションの状態管理処理の流れを示すフローチャートである。
【図７】第２の実施形態にかかるアプリケーションの状態管理処理の流れを示すフローチャートである。
【符号の説明】
【００７９】
１００    アプリケーション状態管理装置
１１０    入力受付部
１２０    セッションＩＤ生成部
１３０    イベント生成部
１４０    シナリオ記憶部
１５０    セッション記憶部
１６０    セッション管理部
１７０    シナリオ管理部
１８０    アクション実行部
【図１】
2008059223.tif 000003
【図２】
2008059223.tif 000004
【図３】
2008059223.tif 000005
【図４】
2008059223.tif 000006
【図５】
2008059223.tif 000007
【図６】
2008059223.tif 000008
【図７】
2008059223.tif 000009