JP2003316738A - ウエブサービスに対応したユーザ認証とサービス利用制限を備えたオブジェクトのライフサイクル管理方法 - Google Patents

Abstract

(57)【要約】 【課題】ウエブサービスに対応したユーザ認証とサービ
ス利用制限方法を提供する 【解決手段】ウエブサービスからなるウエブアプリケー
ションの利用許可をライフサイクルマネジャが発行する
ライフサイクルＩＤによって管理し、ウエブサービスの
実行の指示書としてサービスシナリオを設ける。また複
数のウエブサービスが提供するウエブブラウザ上の異な
る種類のオブジェクトのライフサイクルを管理可能にす
ることを目的として、クライアントにタスクオブジェク
トを設ける。ウエブサービスサーバ側ではライフサイク
ルマネージャからライフサイクルの状態を取得するため
にウエブサービスマネージャを設ける。

Description

【発明の詳細な説明】 【０００１】 【発明の属する技術分野】本発明はインターネット環境
におけるウエブサービスの提供に関する方法、特にクラ
イアントでのウエブサービスの組み合わせへの指示とオ
ブジェクトのライフサイクルの管理とサービスの利用を
管理する方法に関する。 【０００２】 【従来の技術】これまでのウエブアプリケーションでは
サーバ側のアプリケーションの状態管理や、cookieを用
いた状態の管理が行われてきた。このcookie管理ソリュ
ーションはウエブの開発で直面するＨＴＴＰがステート
レスなプロトコルであるという問題に対応するため、ば
らばらなＨＴＭＬページを組み合わせて一貫性のあるア
プリケーションを構成するための方法である。 【０００３】セッション管理を利用したウエブアプリケ
ーションでの利用者の情報は、cookieに保持させる方法
とサーバのセッション管理機能を利用する方法がある。
従来のサーバのセッション管理機能を利用する方法が提
供するウエブセッション管理機構の中の組み込みオブジ
ェクトの１つであるセッションオブジェクトは、ウエブ
アプリケーションでの利用者情報をウエブアプリケーシ
ョンの実行の間保持する、ウエブセッション管理ソリュ
ーションとして利用できる。 【０００４】セッション管理機能の方式の双方にセキュ
リティ面での稀弱性がそれぞれある。利用者情報をcook
ieに保持させる方法では、cookieが盗聴された場合に利
用者情報そのものが盗まれてしまう。また利用者情報を
サーバのセッションオブジェクトに保持させる方法で
は、クラッカーがアクティブなセッションＩＤを推測ま
たはでたらめに想定し、サーバにセッション要求を行う
ことでセッションＩＤの推測に成功した場合、利用者情
報は盗まれてしまう。 【０００５】またサーバ側のセッション管理機能では、
一般的にサーバ側のセッションオブジェクトはメモリ空
間に制限または制約があるので、メモリ使用量の制約を
超えてセッションオブジェクトをメモリ空間に保持し続
けることは不可能である。またウエブコンテナを用いた
場合、コンテナをまたいだセッションオブジェクトの共
有が出来ない。そこで、セッションオブジェクトを永続
化オブジェクトし、共有する方法としてしてファイル、
あるいはＤＢに書き出す方法を用いる。しかしこの方法
は性能の低下を招く。さらに、長期間セッションオブジ
ェクトを保持する方法は、クラッカーがセッションＩＤ
の推測する期間を延長するので、成りすましによるクラ
ッキングを容易にしてしまう。 【０００６】このためサーバ側のセッションオブジェク
トの管理では、セッションオブジェクトに生存のための
時間的制約を設けて管理している。具体的には、一定時
間クライアントからセッション要求の無いセッションオ
ブジェクトに対し、消滅させる操作を行う。このため一
般的なウエブアプリケーションではクライアントの状態
はタイムアウト時間（クライアントからの最終要求時刻
からの経過時間の監視）による緩やかな管理を行ってい
る。これは、セッション要求についてクライアントのア
プリケーションの実行環境である一般的なウエブブラウ
ザは、クライアントのオブジェクトの状態をサーバに伝
える専用の機能を持たないので、サーバはクライアント
オブジェクトのことについてクライアントからの要求に
よってのみ状態を知ることとなっているからである。 【０００７】ところでクライアントからの要求が途絶え
た場合、サーバアプリケーション側からは、クライアン
ト側でアプリケーションが強制終了されたのか、ただ単
に放置されているのか、それともネットワークに問題が
生じているのかは区別がつかなかった。このためクライ
アントで強制終了されたアプリケーションは、サーバ側
のセッションオブジェクトの状態はタイムアウト時間に
達するまでゾンビセッション（アプリケーションの破棄
からセッションオブジェクトの消滅までの時間）となっ
ていた。 【０００８】これはまさにウエブアプリケーションを実
行するプラットフォームのリソースが、それ以前のアプ
リケーション様にアプリケーションの管理下にあったの
とは異なるためである。このリソースであるオブジェク
トは常時生存する必要性がなく、ほとんどクライアント
から要求された場合に実行されるパーツとなっている。 【０００９】その上、ウエブアプリケーションは単一の
プロセスではなく、サーバがクライアントにサービスを
提供するために互いに通信するプロセスやオブジェクト
の要求時のみ結合する緩やかな集合体である。このた
め、個別毎のオブジェクトの管理は困難であった。 【００１０】またウエブアプリケーションを単一のプラ
ットフォームで全て実装することは、特定用途向け（例
えば携帯端末専用の専用アプリケーションなど）で用い
る方法であり、通常はアプリケーションの開発効率や、
既存資源の活用、特定の機能のアプリケーションを実行
するプラグインなどを組み合わせるのが一般的であるた
め、これまではクライアントのオブジェクトを管理でき
ていなかった。 【００１１】またcookieを用いたセッション管理ソリュ
ーションでは、クライアントの要求がクライアントから
のセッションＩＤを保持するサーバに要求が連続して行
わなければならない。これは性能対策のためにロードバ
ランシングを導入した場合、セッション管理を意識した
ロードバランスをインプリメントする必要があった。加
えて、クライアントの要求がクライアントからのセッシ
ョンＩＤを保持するサーバに要求が行わなければならな
いため、クライアントから直接異なるサーバに対して要
求を出せなかった。 【００１２】またこれまで、ユーザがアプリケーション
を実行するウエブサーバまたはサイトにアクセスする際
に行うユーザ認証のインフラを提供するサービスが有
る。このサービスはログイン時のユーザ認証を代行して
いるものと、複数のウエブサーバを一括で認証（シング
ルサインオン）するものがある。ユーザ認証を代行する
ものはログイン後のユーザ認証はここのウエブサーバ側
において行うものとなっている。またシングルサインオ
ンではサインオンすると複数サイトに対するアクセスが
可能になるので、セキュリティに対する安全性は低くな
る。 【００１３】 【発明が解決しようとする課題】現実の企業活動を見て
みると、企業活動がサービス業としての活動範囲を急速
に拡大している。またこの企業活動とは１社の中でクロ
ーズして行っていた業務をサービスとして請負い、アウ
トソーシングとして成立させている。このことは企業活
動をコンピュータの世界で行っている企業では同じ事が
起きる。 【００１４】このことは、ユーザとコンピュータとの関
係を規定する概念に影響を与え、これまでのアプリケー
ション中心のパラダイムから、ウエブが発展するに従い
サービス中心のパラダイムに変わりつつある。つまりユ
ーザとコンピュータとの関係は、ローカルなプログラム
とのインタラクションからネットワークに分散するサー
ビスとのインタラクションにとって変わることとなる。 【００１５】従ってこのアプリケーションの技術的な流
れは、ネイティブコードバイナリのアプリケーションが
サーバあるいはクライアントにあるというコンセプト
（バイナリーファイルによるパッケージの配布）からサ
ーバ側またはクライアント側でサービスを呼び出すコン
セプト（ネットワークを介したサービスの提供）の方向
となる。 【００１６】ここでのサービスとはウエブサービスであ
り、サービスを提供するサービスサーバはウエブサービ
スサーバのことである。 【００１７】このサービスサーバは単一または複数のサ
ービスのみを提供するために存在し、これまでのような
セッションＩＤによるセッション管理に対し責任を持て
ない。それは、これまでのセッション管理ソリューショ
ンが基本的には個別のプラットフォームでの単一のサー
バに対して提供されてきたもののためである。またセッ
ション管理ソリューションは複数のページの組み合わせ
に一貫性を持たせる役割について、サーバ側が主体とな
っているがために利用されてきた。 【００１８】これからのサービス主体のアプリケーショ
ンは、サービスの組み合わせで成立し、クライアントは
異なる複数のサーバからのサービスを受るようになる。
従って、おのずからサービスの制御がクライアント側中
心で行われるようになる。つまりサービスの組み合わせ
を行う主体は、サーバ側からクライアント側に移行する
ことになる。ところで、サービスの組み合わせを行う主
体がクライアントであるフレームワークはまだ無い。 【００１９】このようにアプリケーションがサービス主
体となった場合には、クライアントから直接サービスサ
ーバと通信するようになる。するとこれまでのセッショ
ン管理ソリューションではセッションの管理はできな
い。そこで、セッションＩＤに変わるサービスを通じて
一貫性を保つ仕掛けが必要となる。加えて、cookieを用
いたセッション管理ソリューションには盗聴や成りすま
しによるセキュリティ上の稀弱性があり、ミッションク
リティカルなアプリケーションでは、これまでとは違っ
た方式のセキュリティ対策が必要である。合わせて、セ
ッションＩＤより推測されにくいＩＤの組み合わせが必
要である。 【００２０】さらにウエブアプリケーションにおいて、
多様なクライアント側のオブジェクトをどのような方法
で管理するのかという課題がある。合わせて、クライア
ントオブジェクトの状態をサーバに知らせるためには、
クライアントアプリケーション側にアプリケーション毎
にクライアントの状態をサーバに通知するための仕掛け
を組み込む必要がある。加えてサーバ側のオブジェクト
の管理では、オブジェクトに生存のため時間的制約をオ
ブジェトの状態に合わせたものにしたいという要求があ
る。加えてロードバランシングを導入したときに追加の
インプリメントを不用にしたいという要求がある。加え
てシングルサインオンしたときのセキュリティレベルの
低下を招かないようにしたいという要求がある。 【００２１】ところで、ウエブアプリケーションの作成
者はこれまで個々のクライアントのオブジェクトを管理
対象として意識していないし、また上記のような課題が
あるので管理対象として認識していなかった。また、全
てを純粋なオブジェクト指向の言語やＣＯＲＢＡのイン
ターフェイスでアプリケーションを構築するのとは違
い、はばらばらな形式のオブジェクトからなるアプリケ
ーションを、純粋なオブジェクト指向のメソッドレベル
で管理する方法は、ウエブアプリケーションの作成者に
混乱を招くものになりかねない。 【００２２】この様に、これまでクライアントの多様な
オブジェクトをサービスサーバのサービスと組み合わせ
たアプリケーションを一貫して管理するモデルはまだな
い。異なるあらゆる種類のオブジェクトを管理するため
の統一した方法は見当たらない。 【００２３】従って、ウエブサービスのクライアント側
のオブジェクトモデルは管理する対象としてのオブジェ
クトを何にするか、そしてその管理方法はどのようにす
るか、加えてサービスの組み合わせの主体がクライアン
トなった場合の、サービスの組み合わせでアプリケーシ
ョンを構成するウエブアプリケーションのフレームワー
クとしてのモデルをどうするかという課題がある。 【００２４】 【課題を解決するための手段】ウエブサービス・アプリ
ケーションに新たなフレームワークを導入する。まずウ
エブブラウザのフレームをコンテンツフレームとタスク
フレームとセッションフレームに分け、クライアントと
しての管理対象をブラウザの中でウエブサービスの実行
領域の境界を示すコンテンツフレームをその単位とす
る。その上で、フレームワークとしてウエブサービスの
組み合わせを指示するウエブサービスシナリオを導入す
る。これに合わせて、今までのセッションＩＤに変わり
クライアントオブジェクトの状態を管理する事と同時に
サービスサーバに対してユーザ認証とサービス利用毎に
認証するサービス利用認証に使用するライフサイクルＩ
Ｄを導入する。 【００２５】このライフサイクルＩＤの概念は、ライフ
サイクルマネジャでアプリケーションの実行単位、すな
わちウエブサービスシナリオの単位をアプリケーション
のライフサイクルとする。 【００２６】このためライフサイクルＩＤは、ライフサ
イクルマネージャＩＤとユーザ認証済ＩＤとタスクＩＤ
から構成し、ユーザ認証済ＩＤはユーザ認証を行った証
としてランダムな値を指定し、タスク番号はユーザ認証
後サービスシナリオを実行する毎に前の値に１を加算し
た値を暗号化して発行する。 【００２７】次にライフサイクルＩＤを発行、管理する
ために、ライフサイクルマネージメントサーバを新設し
ライフサイクルマネージャを設け、ウエブサービス・ア
プリケーションの管理方法としてクライアントにタスク
オブジェクトを設け、サービスシナリオの実行とクライ
アントオブジェクトの生存メッセージを通知する役目を
担わせる。 【００２８】加えてウエブサービスサーバにウエブサー
ビスマネージャを設け、これがライフサイクルマネージ
ャと通信しライフサイクルの状態をウエブサービスに通
知する事によって、異なるウエブサービスサーバが提供
する複数のサービスが組み合わされたウエブサービス・
アプリケーションのクライアントオブジェクトのライフ
サイクルを管理可能とすることを特徴とする。 【００２９】本発明によれば、ウエブサービスの組み合
わせからなるアプリケーションにおいて、サービスを提
供するサービスサーバに直接要求が可能となるためサー
ビスを提供するサーバが異なる場合と、サービスのクラ
イアントオブジェクトの形式が異なる場合に最も有効で
ある。 【００３０】セッションフレームを設けてセッションデ
ータをクライアントに保持する方法については、依頼番
号OGK010722 ダイナミックなドキュメントの生成表示方
法及びその装置ですでに述べている。 【００３１】 【発明の実施の形態】（１）概要 図１は、本発明のウエブアプリケーションのフレームワ
ークのコンポーネントを示す。タスクオブジェクト１０
０は、クライアントでのウエブアプリケーションの実行
を管理し、サービスシナリオ２００はウエブアプリケー
ションの実行手順であり、セッションオブジェクト３０
０は、ウエブサービス間でのセッション中の利用者デー
タを保存するエリアを持ち、ウエブサービス４００は、
本発明のフレームワークに対応したサービスであり、ウ
エブサービスマネージャ５００はウエブサービスとライ
フサイクルマネージャとコミュニケーションを仲介し、
ライフサイクルマネージャ６００はサービス利用認証の
ための専用サービスであり、ログインマネージャ８００
はユーザ認証のための専用サービスである。 【００３２】図２は、本発明の新たなフレームワークで
の認証の要求と応答の関係を示し、（ａ）は、クライア
ント７００は（１）ログインすると、ログインサーバ８
００はユーザ認証済ＩＤと（２）アプリケーション選択
画面をクライアントに返すことを示す図である。 【００３３】（ｂ）は、利用者がクライアントでアプリ
ケーションを選択して（３）タスク開始をライフサイク
ルマネージメントサーバ６１０に送信し、（４）ライフ
サイクルＩＤを発行しクライアントに返信する。クライ
アントは（５）ライフサイクルＩＤでサービスを要求す
る。ウエブサービスサーバ４１０ではクライアントから
要求のあったサービスが提供が許可されているかどうか
ライフサイクルマネージメントサーバにサービスの利用
可否の確認を行い、ウエブサービスサーバ６１０では
（７）確認応答を元にサービスを行うかを判断し、クラ
イアントに（８）サービスを提供することを示す図であ
る。 【００３４】（ｃ）は、クライアントタスクが生存して
いることを（９）アクティブ通知によって行うことを示
す図である。 【００３５】（ｄ）は、クライアントタスクが終了する
ことを（１１）タスク終了によって行うことを示す図で
ある。 【００３６】（ｅ）は、ログアウトの通知を（１３）ロ
グアウト通知によって行うことを示す図である。 【００３７】図１５でサービスの実行単位を識別するラ
イフサイクルＩＤ１２０の実装時の概念を図で示す。ラ
イフサイクルＩＤはライフサイクルマネージメントサー
バＩＤとユーザ認証済ＩＤとタスク番号で構成する。 【００３８】図３は、本発明のクライアント７００とウ
エブサービス４００とライフサイクルマネージャ６００
の間での認証のためのデータの流れを示す。 【００３９】ライフサイクルマネジャからクライアント
のウエブブラウザ７１０のタスクオブジェクト１００に
ライフサイクルＩＤ１３０とウエブサービスＵＲＩが送
られる。タスクオブジェクトはウエブサービスＵＲＩで
ライフサイクルＩＤをパラメータとしてウエブサービス
にサービスを要求する。 【００４０】このときhttpのget メソッドのパラメータ
またはcookieまたはhttpのputメソッドのフォームデー
タとして、利用者情報がウエブサービスに送信される。
ウエブサービスはメソッド内部に、サービスを識別する
ためのユニークなサービスＩＤ４７０をサービス単位に
持つ。 【００４１】このサービスＩＤとパラメタとして与えら
れたライフサイクルＩＤでウエブサービスマネージャ５
００を介してライフサイクルマネージャにサービス利用
確認１７０の問い合わせを行い、確認応答１８０の結果
を元にページコンテンツ１６０を応答する。 （２）詳細な説明 図４は、本発明のフレームワークでの各コンポーネント
の詳細な構成を示す。クライアント７００内のウエブブ
ラウザ７１０の中はコンテンツフレーム７２０、セッシ
ョンフレーム７３０、タスクフレーム７４０の３つのフ
レームで構成される。セッションフレームとタスクフレ
ームをひとつにすることは可能である。フレームを生成
する実装例を図１２のベースページコンテンツの実装例
６３０の図で示す。 【００４２】コンテンツフレームの中にはサービスの実
体であるコンテンツオブジェクト７６０が要求毎に生成
される。セッションフレームの中にはセッションオブジ
ェクト３００があり、サービスシナリオの開始後生成さ
れた後、終了まで継続して存在し、タスクフレームのタ
スクオブジェクトも同様にサービスシナリオの開始後生
成された後、終了まで継続して存在する。 【００４３】ウエブアプリケーションでのクライアント
としての管理対象として設けられたタスクフレームはウ
エブサービスへのログイン後ロードされにアプリケーシ
ョンが終了する間再ロードされない。このため、タスク
オブジェクトはタスクフレームのコンテンツとして一度
だけロードされ生成、実行し、アプリケーションが終了
するまで一貫して存在するオブジェクトである。また、
タスクオブジェクトは、サービスシナリオをもとにウエ
ブサービスを実行し、平行してコンテンツオブジェクト
のステータスをライフサイクルサーバに通知する。 【００４４】次にログインサーバ８１０はログインマネ
ージャ８００、パスワードファイル８２０、ユーザ認証
済ＩＤテーブル８３０から成る。 【００４５】次にライフサイクルマネージメントサーバ
６１０はライフサイクルマネージャ６００、ライフサイ
クル管理テーブル６２０、ベースページコンテンツ６３
０、サービスシナリオＤＢ６４０、ライフサイクルステ
ータスログファイル６５０、タスクオブジェクトライブ
ラリファイル６６０、ライフサイクルＩＤテーブル６７
０、タイムスタンプ６８０、メニュー画面コンテンツ６
９０から成る。 【００４６】次にウエブサービスサーバ４１０は、ウエ
ブサービス４００、サービスの内容であるページコンテ
ンツ４２０、ウエブサービスマネージャ５００、ライフ
サイクルマネージャを探すためのライフサイクルマネー
ジャＵＲＩファイル５１０から成る。 【００４７】図５は、本発明のクライアントとウエブア
プリケーションとサービスサーバの関係を具体的な例で
示す。クライアントの部分集合であるネットワークＡ７
０１のクライアントからライフサイクルマネージメント
サーバＡ６１０のウエブアプリケーションを利用する時
のウエブアプリケーションのメニュー構成は４６１、４
６２、４６３から成り、関係するウエブサービスサーバ
はウエブサービスサーバＡ４１１、ウエブサービスサー
バＢ４１２、ウエブサービスサーバＣ４１３である。ウ
エブサービスサーバＡにはウエブサービスａ１ ４３
１、ウエブサービスａ２ ４３２、ウエブサービスａ３
４３３のサービスがあり、同様にウエブサービスサー
バＢにはウエブサービスｂ１ ４４１、ウエブサービス
ｂ２ ４４２のサービスがある。 【００４８】図６は、本発明のサービスシナリオの実行
例を図６（ａ）４８１、図（ｂ）４８２、図（ｃ）４８
３で示す。図（ａ）は図５の４６１に、図（ｂ）は図５
の４６２に、図（ｃ）は図５の４６３にそれぞれ対応す
る。ちなみに図（ａ）のシナリオの流れは、スタート、
ウエブサービスａ１ ４３１、ウエブサービスａ２４３
２、ウエブサービスｂ１ ４４１、ウエブサービスｂ２
４４２、エンド、である。 【００４９】図７は、本発明のウエブアプリケーション
のメニュー画面７７０の実行例である。メニュー画面
は、サービスシナリオを実行を指示するウエブサービス
・アプリケーションの起動を選択するウエブサービス名
を表示するボタン７７１、７７２、７７３と、ログアウ
トのためのログアウトボタン７７４とからなる。メニュ
ー画面はタスクマネージャで生成され、ウエブサービス
名とウエブサービス・アプリケーションＩＤの関連付け
の定義は、図１８のサービスシナリオＤＢ１０７０で行
う。メニュー画面を生成する際に、図４のメニュー画面
コンテンツ６９０をベースとして図１８のサービスシナ
リオＤＢ６４０のウエブサービス名１０７１とウエブサ
ービス・アプリケーションＩＤ１０７２を関連付けた画
面を生成する。 【００５０】この様にして、アプリケーション名を示す
ボタンとウエブサービスアプリケーションＩＤは関係づ
けによって、ボタンをクリックすると該当ウエブサービ
スアプリケーションＩＤとユーザ認証済ＩＤはライフサ
イクルマネージメントサーバに送信され、サービスは開
始する。つまり、ウエブサービス・アプリケーションＡ
１ ７７１は図５の４６１に対応する。 【００５１】図８、図９は、本発明のログイン１１００
からログアウト１２４０までのユーザ認証と利用者認証
の概略の流れとその手順の一部のメッセージフロー図を
示す。メッセージフロー図で説明すると、ユーザが図９
のログイン画面要求９０１をログインマネージャ８００
に送信し、ログイン画面９０２を返信する。ログイン画
面でログインＩＤ、パスワードを入力し、ログインＩ
Ｄ、パスワード９０３でログインマネージャに送信する
と、ライフサイクルマネージャはライフサイクルマネー
ジメントサーバＵＲＩ、ユーザ認証済ＩＤ９０４をクラ
イアントに返信し、クライアントのウエブブラウザのwi
ndowオブジェクトのlocationをライフサイクルマネージ
メントサーバＵＲＩにすることでwindowオブジェクトの
Baseページを変更して、ユーザ認証済ＩＤ９０５をライ
フサイクルマネージャに送信する。 【００５２】このときのログインマネージャでのユーザ
認証に用いるファイルの実装時の概念を、図２０のパス
ワードファイル８２０の図で示す。 【００５３】またログインマネージャでユーザ認証を保
持するテーブルの実装時の概念を、図２１のユーザ認証
済ＩＤテーブル８３０の図で示す。 【００５４】続いて、図７のメニュー画面でのボタンの
クリックで、図８の流れ図では１１４０でウエブサービ
ス・アプリケーションＩＤの選択後、１１５０でログア
ウトボタンがクリックされたかの判定が行われる。 【００５５】図８の１１５０の判定がYES の場合、図９
のログアウト要求９０５がログインマネージャになされ
ログアウト画面応答９０６を返す。１１５０の判定がNO
の場合１１６０でブラウザウインドウを生成し、１１７
０でライフサイクルマネージャが発行するタスク番号を
加たライフサイクルＩＤを１１８０でライフサイクル管
理テーブルに登録し、１１９０でシナリオを実行する。 【００５６】その後、シナリオの実行が終了すると１２
００でライフサイクル管理テーブルから該当タスク番号
のレコードは削除され、１２１０でライフサイクルＩＤ
は無効となり、１２２０でブラウザウインドウを破棄す
る。 （３）シナリオの実行の説明 クライアントでのタスクオブジェクトでのシナリオの実
行の流れを、図２２の（ａ）で示す。タスクフレームで
１３００でライフサイクルＩＤとサービスシナリオを受
信しタスクオブジェクトとサービスシナリオテーブルを
生成する。図１７のサービスシナリオテーブル１１０に
実装時の概念を図に示す。１３１０で処理番号＝０、最
大処理番号をサービスシナリオテーブルより求め設定す
る。１３２０で処理番号の値が最大処理番号未満なら処
理番号を１加算し、１３３０で処理番号をキーとしてサ
ービスシナリオテーブルの処理番号を検索し、ウエブサ
ービスＵＲＩを取出す。 【００５７】１３４０でコンテンツフレームからライフ
サイクルＩＤをパラメータとしてウエブサービスＵＲＩ
にサービスを要求する。１３５０でコンテンツフレーム
からのメッセージが終了メッセージなら１３８０でタイ
マー設定を解除して１３９０ライフサイクルＩＤとタス
クステータス(end) をパラメータとしてライフサイクル
マネージャにステータスを通知する。 【００５８】メッセージが終了メッセージでなく、１３
６０のメッセージが”戻る”の判定がNOなら１３２０か
ら繰り返す。YES なら処理番号を２減算し１３２０から
繰り返す。 【００５９】図２２の（ｂ）はクライアントオブジェク
トの生存メッセージをライフサイクルマネージャに通知
知るための実装時の概念である。 【００６０】１４４０、１４１０は一定期間、例えば３
０秒間隔でライフサイクルマネージャにステータス(act
ive)を通知する。 【００６１】ライフサイクルマネージャが、パラメタと
して受取ったライフサイクルＩＤ１０８１とステータス
１０８２と要求元１０８３に、タイムススタンプ１０８
４を付加して記録するファイルの実装の概念を、図１９
のライフサイクルステータスログファイル６５０の図に
示す。 【００６２】ウエブサービスはクライアントからの要求
があると、ウエブサービスマネージャのメソッドを呼び
出す。ウエブサービスの処理の流れを図２３で示すと１
５００でライフサイクルＩＤを受信し、１５１０でライ
フサイクルＩＤと自身のサービスＩＤを引数としてウエ
ブサービスマネージャのメソッドを呼び出す。１５２０
で戻り値としてクライアントオブジェクトのステータス
を受取り、１５３０でステータス＝"active"の判定を行
う。判定結果がYESなら１５４０でサービス処理を実行
しコンテンツを返し、NOであれば１５６０でエラーコン
テンツを返す。 【００６３】呼び出されるウエブサービスマネージャの
処理の流れを図２４で示す。ウエブサービスマネージャ
は１６００で呼び出されると、１６１０でライフサイク
ルＵＲＩを取出す。このときライフサイクルＩＤの構成
を示す図１５でのサーバＩＤ部１０４１を取出し、この
サーバＩＤから図１３で示すライフサイクルマネージャ
ＵＲＩファイル５１０でのライフサイクルマネージメン
トサーバＩＤ１０２１とライフサイクルマネージャＵＲ
Ｉ１０２２の対応表からライフサイクルマネージャを特
定し、１６２０でライフサイクルＩＤをパラメタとして
特定したライフサイクルマネージャＵＲＩでウエブサー
ビス利用確認の問い合わせを行い、１６３０でクライア
ントオブジェクトのタスクステータスを受信し、１６４
０でタスクステータスを戻り値として返す。 【００６４】サービス利用確認の問い合わせがされる、
ライフサイクルマネージャでの処理の流れを図２５で示
す。１７００でライフサイクルＩＤとサービスＩＤを受
信したライフサイクルマネージャは、１７１０でサーバ
ＩＤ部取出し、１７２０でライフサイクルサーバのライ
フサイクルサーバＩＤと比較し、１７３０でユーザ認証
済ＩＤ取出し、１７４０でライフサイクル管理テーブル
のユーザ認証済ＩＤ部とタスク部をキーとしてテーブル
を検索する。図１６でライフサイクル管理テーブル６２
０の実装時の概念を図で示す。ライフサイクル管理テー
ブルのデータを格納しておくＤＢの実装時の概念を図１
８のサービスシナリオＤＢ６４０で示す。 【００６５】検索結果が有りなら１７５０で該当レコー
ドのサービスシナリオをサービスＩＤで検索し、結果が
有りなら１７６０でタスクステータスを"active"とし、
それ以外は１７８０ で全てタスクステータスを"nonact
ive" とし、ウエブサービスマネージャにタスクステー
タスを返信１７７０し、最後に１７９０でライフサイク
ルステータスログファイルにアクセスログを記録する。 【００６６】図１０、は本発明のコンテンツフレームと
セッションフレームとウエブサービスサーバでのシナリ
オの実行例による利用者情報の流れの実施例を示す。４
３１ウエブサービスａ１のページコンテンツで発生した
利用者情報は、７３０のセッションフレームで保持され
る。同様に４３２ウエブサービスａ２のページコンテン
ツで発生した利用者情報はセッションフレームで先ほど
の利用者情報に加えられて保持される。 【００６７】次に４４１ウエブサービスｂ１のページコ
ンテンツはセッションフレームの利用者情報を取出し、
４４２ウエブサービスｂ２に送り、ウエブサービスｂ２
では７８０データ更新メソッドが起動され５３０ＤＢを
利用者情報で更新する。 【００６８】図１１は、図１０で示したシナリオの実行
例による利用者情報の流れを手順のメッセージフローで
示す。アプリケーションのメニュー画面では、クライア
ントのウエブブラウザはユーザ認証済ＩＤを持ってい
る。アプリケーションを選択することで７２０から９１
０のメッセージをＵＲＩのパラメタに組み込んで６００
ライフサイクルマネージャに対してタスクを開始するた
めのタスクステータス(start)を送る。 【００６９】ライフサイクルマネージャは９１１の応答
メッセージでベースページコンテンツ、ライフサイクル
ＩＤ、サービスシナリオを返す。図１２でベースページ
コンテンツの実装例を示し、このベースページコンテン
ツから９１２、９１３、９１４の手順でタスクフレーム
のオブジェクト７４０、セッションフレーム７３０のオ
ブジェクト、７２０コンテンツフレームのオブジェクト
を生成し、各オブジェクトは９６０でブラウザウインド
ウの破棄まで継続して存在する。９１５以降は処理実行
の一連の流れである。 【００７０】最後に、終了メッセージ９３７を受取ると
ライフサイクルマネージャにタスク９３８を終了させる
ためのタスクステータス（end)を送る。 【００７１】この様に、ライフサイクルＩＤによるライ
フサイクル管理での概念は、ライフサイクルＩＤはタス
クオブジェクトの生成から消滅までをライフサイクルを
単位として、ユーザ認証済み利用者の選択するウエブア
プリケーションに割り当てるユニークなＩＤである。こ
のＩＤを用いてサービスの利用許可の確認を行うことに
よって、サービスの利用者がユーザ認証済みの状態であ
っても、利用しているサービス以外は利用できないこと
が、シングルサインオンでの応用時にセキュリティ面で
有効である。従って、ログイン時にウエブサービスの利
用範囲が限定されていることは、クラッカーによる不正
なアクセスを未然防止し、このことがセキュリティ対策
に有効である。 【００７２】また、本発明の実施例においては、これま
でのセッションＩＤソリューショント比較して、ロード
バランシングを導入した場合に伴うインプリメントの追
加が不用となり、システムの拡張が容易となる。 【００７３】この他に、サービスを提供する業者にとっ
てこれまでアプリケーションの部品レベルの流通から、
ウエブサービスの流通を変革するための必要な技術とな
る。ウエブサービスの流通単位をアプリケーションの部
品単位と置き換え、かつ課金を行う単位を構成すること
にも応用できる。この課金の単位はサービスを選択した
地点でまたはサービスにアクセスした地点でも良い。こ
の小さな課金単位はウエブサービスを時間、または期間
以外の従量制の課金に変更するのに有効である。 【００７４】 【発明の効果】以上述べたように本発明によれば、ウエ
ブサービスに応じたオブジェクトの監視方法のための新
たなフレームワークが示され、これによってサービスに
対するログイン認証サービスとクライアントのオブジェ
クトの管理ができるようになる。

【図面の簡単な説明】 【図１】本発明のフレームワークを示す図である。 【図２】本発明の実施例における認証の遷移を示す概念
図である。 【図３】本発明の実施例におけるライフサイクルＩＤの
流れを説明する概念図である。 【図４】本発明の実施例における構成を示す概念図であ
る。 【図５】本発明の実施例におけるクライアントとライフ
サイクルサーバとウエブサービスサーバのウエブサービ
ス・アプリケーションと個々のウエブサービスとの関係
を表した概念図である。 【図６】本発明の実施例におけるサービスシナリオの実
行の手順を示す流れ図である。 【図７】本発明の実施例におけるメニュ画面の実施例で
ある。 【図８】本発明の実施例におけるログインからログアウ
トまでの実行の手順を示す流れ図である。 【図９】本発明の実施例におけるログイン時とログアウ
ト時の手順を示すメッセージフロー図である。 【図１０】本発明の実施例におけるシナリオ実行の利用
者データの流れを示す概念図である。 【図１１】本発明の実施例におけるシナリオ実行の手順
を示すメッセージフロー図である。 【図１２】本発明の実施例におけるベースページコンテ
ンツの実装例である。 【図１３】本発明の実施例におけるライフサイクルマネ
ージャＵＲＩファイルの概念図である。 【図１４】本発明の実施例におけるライフサイクルＩＤ
テーブルの概念図である。 【図１５】本発明の実施例におけるライフサイクルＩＤ
の構成要素を示す図である。 【図１６】本発明の実施例におけるライフサイクル管理
テーブルの概念図である。 【図１７】本発明の実施例におけるサービスシナリオテ
ーブルの概念図である。 【図１８】本発明の実施例におけるサービスシナリオＤ
Ｂの概念図である。 【図１９】本発明の実施例におけるライフサイクルステ
ータスログファイルの概念図である。 【図２０】本発明の実施例におけるパスワードファイル
の概念図である。 【図２１】本発明の実施例におけるユーザ認証済ＩＤテ
ーブルの概念図である。 【図２２】本発明の実施例におけるタスクオブジェクト
の実行の手順を示す流れ図である。 【図２３】本発明の実施例におけるウエブサービスの実
行の手順を示す流れ図である。 【図２４】本発明の実施例におけるウエブサービスマネ
ージャの実行の手順を示す流れ図である。 【図２５】本発明の実施例におけるライフサイクルマネ
ージャの実行の手順を示す流れ図である。 【符号の説明】 １００…タスクオブジェクト、１１０…シナリオテーブ
ル、１２０…ライフサイクルＩＤ、２００…サービスシ
ナリオ、３００…セッションオブジェクト、４００…ウ
エブサービス、４１０…ウエブサービスサーバ、４２０
…ページコンテンツ、５００…ウエブサービスマネージ
ャ、５１０…ライフサイクルマネージャＵＲＩファイ
ル、６００…ライフサイクルマネージャ、６１０…ライ
フサイクル・マネージメントサーバ、６２０…ライフサ
イクル管理テーブル、６３０…ベースページコンテン
ツ、６４０…サービスシナリオＤＢ、６７０…ライフサ
イクルＩＤテーブル、６９０…メニュー画面コンテン
ツ、８００…ログインマネージャ、８１０…ログインサ
ーバ、８２０…パスワードファイル。

Claims (1)

1. 【特許請求の範囲】 【請求項１】インターネット上でクライアントのウエブ
   ブラウザでウエブサービスの組み合わせから成るウエブ
   アプリケーションを実行させる方法であって、セッショ
   ン管理ソリューションに代わって、（ａ）前記セッショ
   ン管理ソリューションで用いるセッション識別子に代わ
   りライフサイクルＩＤを利用する段階と、（ｂ）前記セ
   ッション管理ソリューションで用いるセッションオブジ
   ェクトをサーバでなくクライアントで持つ段階と、
   （ｃ）サービスを実行する仕様書となるサービスシナリ
   オでサービス実行手順を定義する段階と、（ｄ）前記サ
   ービスシナリオは、クライアント側で実行する段階と、
   （ｅ）ウエブアプリケーションの実行単位を前記サービ
   スシナリオが示すタスク単位とする段階と、（ｆ）ライ
   フサイクルＩＤが前記タスク単位で実行が管理される段
   階と、を含むライフサイクル管理方法。