JP2004178466A

JP2004178466A - サービスサイト単位のセッションを確立させる方法

Info

Publication number: JP2004178466A
Application number: JP2002346754A
Authority: JP
Inventors: Tsuneo Ogawa; 恒生小川
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2002-11-29
Filing date: 2002-11-29
Publication date: 2004-06-24

Abstract

【課題】この発明は、ウエブサービスのユーザ・インタフェース・セッションの連携メカニズムを、複数のウエブサービスサイトでサービスの提供を可能にするためのセッションモデルとして提供する。
【解決手段】異なるウエブサイトにまたがるウェッブセッションにおいて、ウエブサービスを実行するためのセッション情報へのアクセスを制御する方法として、セッション情報をタスクセッション情報とスレッドセッション情報に分離し、アクセス制御のセッション識別子をタスクセッションに用いるタスクセッションＩＤとスレッドセッションに用いるスレッドセッションＩＤに分離することで、サービスサイト単位のセッションを確立させる方法を提供する。
【選択図】図１

Description

【０００１】
【発明の属する技術分野】
本発明は、ウエブサービスをベースにしたコンピュータ応用に関するもので、特に、ウエブサービスのユーザ・インタフェース・セッションの連携メカニズムを異なるウエブサービスサイトのウエブサービスサーバでサービス可能とするための、ウエブサービスのセッション情報管理に関するものである。
【０００２】
【従来の技術】
通常、セッションとは、指定されたアプリケーションに関連付けたページに、単一のクライアントからサーバに対して行われるすべての接続を示す。
【０００３】
ウエブブラウザの中の１つの項目からスタートした複数のウエブアプリケーションはそれぞれ独立に動作しており、このため互いに他のウエブアプリケーションについて知らないし、また、そのままでは如何なるプロパティも共用することはない。
【０００４】
このため、ウエブアプリケーションでは、ばらばらなウエブページを連携させて、一貫性のあるアプリケーションとして成立させるためにセッション識別子（セッションＩＤ）であるセッション変数とセッションオブジェクトを持っている。これはＨＴＴＰがステートレスなプロトコルであるために、ブラウザからの複数の要求の間で状態を保するためのメカニズムが用意されていないためである。この様に、ウエブアプリケーションでは、セッションＩＤによってばらばらなウエブページを連携させ、あわせてウエブページでのアクセス認証はセッションＩＤによって行われる。
【０００５】
従来のメカニズムの中で、セッションＩＤを含めたセッション情報管理は基本的には３つの方法があり、１つ目はｃｏｏｋｉｅに保持させる方法、２つ目はウエブサービスサーバまたはアプリケーションサーバのセッション情報管理に保持させる方法、３つ目は別のＤＢサーバに保持させる方法である。
【０００６】
１つ目のｃｏｏｋｉｅにセッション情報を保持させる方法では、Ｃｏｏｋｉｅデータの盗聴や改竄などが可能なため、商取引に使ったＣｏｏｋｉｅを横取りし本人になりすまして物品の購入を行なったり、Ｃｏｏｋｉｅを認証やセッション管理に使っているサイトに侵入できる可能性がある。
【０００７】
２つ目のウエブサービスサーバまたはアプリケーションサーバのセッション情報管理にセッション情報を保持させる方法は、異なる種類のウエブサービスサーバまたは異なる種類のアプリケーションサーバにおいて、セッション管理の方法がウエブサービスサーバやアプリケーションサーバで統一されていない。
【０００８】
３つ目のＤＢサーバに保持させる方法は、同一のサーバ内にＤＢを持つ方法と、別のＤＢサーバに保持させ共用させる方法とがあり、サイトをまたがるセッションの場合には、一般的にＤＢサーバ一は別の独立したサーバとして設置することとなる。
【０００９】
加えて、クライアントからの要求が一定期間明示的にされなかった場合において、これまでウエブサーバの設定はセッションがタイムアウトしたとして、セッションを切断するためにサーバのセッション情報を破棄していた。この設定される期間は、ウエブサービスサーバのリソースを節約するためと、セッション情報を不正なアクセスから保護するために、通常１０分〜２０分に設定されていた。
【００１０】
この要求が明示的であるというのは、クライアントからウエブサーバにＳｕｂｍｉｔの要求を出すということであり、従ってクライアント内のみで実行されるスクリプトなどのプログラムまたはセッション情報を保持していないサーバへのアクセスについては、タイムアウトの設定期間に影響を与えることは無かった。
【００１１】
また、ウエブサービス（インターネット上で提供されるアプリケーション・サービス）の概念としてのシステム・アーキテクチャは、クライアントのブラウザからの要求を、いったんウエブアプリケーション・サーバで受け、このウエブアプリケーション・サーバがウエブサービスサーバにウエブサービスを要求するクライアントとなる。そしてこのウエブアプリケーション・サーバがウエブサービスの結果から画面を生成し、クライアントのブラウザへ返す。このように、ウエブサービスをアプリケーションとして結合するのは、ウエブアプリケーション・サーバであり、このためウエブアプリケーション・サーバは、サービスを提供するポイントとして存在し、従ってこのサービスポイントは、ユーザから見ればウエブアプリケーションを提供する単一のウエブサイトとして認識される。
【００１２】
ところで、アプリケーション、もしくはアプリケーションの一部分がインターネットを通じて相互連動しタスクを遂行するという、ウエブサービスの基幹となるコンセプトに対し、たくさんの技術が存在している。そして、コンピュータ業界に立ちはだかる最大の壁は、常に、異なるシステムまたはアプリケーション同士の対話を実現することである。ウエブサービスとその関連技術はこの壁を克服しようという試みであり、セキュリティを含めた異なるサービスサイトをまたがるセッションモデルは、ウエブサービスに不可欠な土台であるが、現時点ではまだこの分野の標準は確定していない。
【００１３】
【発明が解決しようとする課題】
この発明の目的は、ウエブサービスのユーザ・インタフェース・セッションの連携メカニズムを異なるウエブサービスサイトからなるサービスを可能にするために、ユーザ認証後のサービスサイト単位の承認（何かを行う、またはある場所に存在することを、誰かに許可を与えること。）を与えるためのセッションモデルを提供することである。
【００１４】
たとえば、異なるウエブサイトをまたがるウエブセッションで同一のセッションＩＤを用いてセッションを行った場合に、セッションを行ったウエブサイトで補足したセッションＩＤを用いて、他のウエブサイトのセッション情報にアクセスできてしまうことに対する問題がある。例をあげると、決済サイトに保存されているユーザのクレジットカードの情報が、同一のセッションＩＤを用いてセッションを行う事によって補足されたセッションＩＤを、決済サイトのセッション情報への不正なアクセスに用いることによって、容易に漏洩する可能性がある。
【００１５】
加えて、複数のウエブサービスサイトが提供するウエブサービスのユーザインターフェイス・セッションにおいて、セキュリティを確保するためのプログラミングモデルが無いという問題がある。このためクライアントオブジェクトとサーバオブジェクトの関係において、双方でのオブジェクトが保持するセッション情報の保持内容とアクセスに関して、プログラミングモデルが必要である。
【００１６】
また、ウエブアプリケーションが発展し、クライアントスクリプトなどクライアントで高度なプログラムが動作するようになると、これまでのタイムアウト時間だけではユーザのアプリケーションへの滞在を一律的な期間で判断できなくなる。例えばウエブでのショッピングでユーザが購入する商品に対しこれまで以上に比較検討を要する場合、これまでのタイムアウト期間で設定されている期間以上に時間が必要となる。それに対し、決済を行うクレジットカードサイトでのタイムアウトのための設定期間は、セキュリティ対策のためにこれまで以上に期間を短くする方がセキュリティ対策上安全である。
【００１７】
加えて課題を実現する方法が、ＨＴＴＰのプロトコルでのセッション情報を共有する方法である要求がある。
【００１８】
また、特開２０００−１０５７４１；発明の名称を「セッション環境情報を共用する方法」でのセッション情報を集中して共用する形でウエブサービスに提供する方法は、異なるウエブサイトとセッション環境情報を共用する場合には、別のサイトにあるＤＢサーバを参照することとなるので、ネットワークを介してＤＢサーバを参照するための認証や権限のための仕掛けが必要となる。
【００１９】
また、これまでのウエブアプリケーション・サーバのプラットフォームは、ばらばらなＨＴＭＬページを連携させる課題を解決するための、独自のウエブセッション管理機能を提供する単一のサイト内、あるいはクライアントからの要求を受け付ける単一ポイントのアーキテクチャであり、複数のサービスサイトがそれぞれのサービスサイトでユーザを認識し、そのセッションにおいてＨＴＭＬページのページを連携し、それぞれのサービスサイトでのセッション情報管理を結合または相互補完する形でのセッションモデルはない。
【００２０】
【課題を解決するための手段】
上記目的を達成するため、本発明のウエブセッションの制御方法では、シングルサインオンでの認証エージェントを共有し信頼した認証プロセスの後において、サービスシナリオが示す異なるサービスサイトのウエブサービスを実行するためのユーザ・インタフェース・セッションを承認する手段として、アプリケーションの実行単位としてのタスクセッションとサービスサイト単位のセッションを実行単位とするスレッドセッションを有することを特徴とするウエブセッション制御方式を提供する。
【００２１】
スレッドセッションとは、サービスサイト同一の１つ以上の連続するウエブサービスを示し、タスクセッションとは、サービスシナリオの実行時における開始から終了までのセッションで１つ以上のスレッドセッションをまたがるセッションを示す、新たに導入した概念である。
【００２２】
そこで、本発明によるウエブアプリケーションのでのウエブセッションの制御方法では、ウエブサービスシナリオを実行する単位においてセッション識別子であるセッションＩＤを、タスクセッションＩＤとスレッドセッションＩＤに分け、タスクセッション側をタスクセッションＩＤにスレッドセッション側をスレッドセッションＩＤとすることにより、サービスサイト単位の独立したセッション識別子を保有することによってセッションを確立させる方法を提供する。
【００２３】
加えて、タスクセッションのためのセッションオブジェクトをクライアントとポータルサイトに持ち、スレッドセッションのためのオブジェクトを個々のウエブサービスサーバに持つことによってセッションを確立させる方法を提供する。
【００２４】
加えて、クライアントからウエブアプリケーション呼び出しを実行するための仕掛けとしてサービスシナリオを持ち、このサービスシナリオはウエブサービスを呼び出すための実行指示書である。さらにこのサービスシナリオには、スレッドセッションの開始と終了時の確認を行うウエブサービスの呼び出しを記載し、サービスシナリオの実行指示に従ってウエブサービスを実行する方法を提供する。
【００２５】
加えて、本発明によるウエブアプリケーションのでのウエブセッションの制御方法では、ポータルサイトにて、ウエブアプリケーションを選択するためのメニュー画面を提供し、あわせてこのポータルサイトでユーザの個人情報を保持しサービスサイトに提供する。
【００２６】
加えて、本発明によるウエブアプリケーションのでのウエブセッションの制御方法ではポータルサイトでタスクセッションの開始と終了とスレッドセッションの実行許可を管理するするための記憶手段に記憶する手段を提供する。
【００２７】
加えて、本発明によるウエブアプリケーションのでのウエブセッションの制御方法では、サービスを提供するサイトとポータルサイトとでスレッドセッションの開始と終了と実行許可を管理するための記憶手段に記憶する方法を提供する。
【００２８】
加えて、スレッドセッション毎にセッションのためのタイムアウト期間を設定する方法を提供する。
＜造語としての定義＞
タスクセッションＩＤは、タスクセッションのための識別子で、スレッドセッションＩＤはスレッドセッションのための識別子である。
【００２９】
タスクセッションとは、ウエブアプリケーションとしての実行指示書であるサービスシナリオの開始から終了までの期間をタスクセッションと定義し、このタスクセッションで用いるセッション識別子をタスクセッションＩＤとする。
【００３０】
スレッドセッションとは、タスクに対応するスレッドという語を用いて、同一のサービスサイト内の開始から終了までのセッションの期間をスレッドセッションと定義し、このスレッドセッションで用いるセッション識別子をスレッドセッションＩＤとする。
【００３１】
【発明の実施の形態】
本発明の形態について実施例を用いて説明する。
Ａ．概略
本発明は、異なるウエブサイトをまたがるウエッブ・ユーザ・インタフェース・セッションについての概念と、そのウェッブセッションにおいてウエブサービスを実行するためのセッション情報へのアクセスを制御する手段として、図３で示すように、これまでのセッション情報３３０をタスクセッション情報３４０とスレッドセッション情報３５０に分離するために、セッション識別子であるセッションＩＤ３００をタスクセッションＩＤ３１０とスレッドセッションＩＤ３２０の２つのＩＤによって構成することによって、サービスサイト単位のセッションを確立させる方法を提供するものである。
【００３２】
これは図１で示す様に、スレッドセッション情報２５０とスレッドセッション情報２７０は双方のサイト間で共有しないので、サイト固有の情報を持つことが出来る。スレッドセッション情報にアクセスするためには、スレッドセッションを識別するセッション識別子、つまりスレッドセッションＩＤが必要である。スレッドセッションＩＤはスレッドセッション毎に各サイトで生成され、サイト自身とクライアントでのみ共有されるため、他のサイトでこのセッションＩＤを補足することは出来ない。
【００３３】
従って本発明では実施例の図５で示すように、クライアントから入力される個人情報が、異なるサービスサイトをまたがるセッションの中で、クレジットカード番号とパスワードの様に他のサービスサイトと情報を共有されない方法を提供する。
Ｂ．詳細な説明
ウエブ上での複数のアプリケーションにログオンするための、一括で認証する方法としてシングルサインオンサービスが提供する認証方法があり、本発明の実施例の図２では、シングルサインオンサービスが提供するウエブサービスサイトの集合１３０に対し、（ａ）は、サインオンＩＤで利用可能なウエブサービスサイト１４０との関連の概念を示し、（ｂ）はサービスシナリオを導入することによってサインオンＩＤで利用可能なウエブサービスサイト１４０に対してアクセスが制限される、サインオン後のサービスシナリオ１００で利用可能なウエブサービスの集合１５０との関連の概念を示す。
【００３４】
サービスシナリオ１００は、シングルサインオン後にウエブアプリケーションを選択するとクライアントのに送られて実行する、ウエブアプリケーションのための実行指示書であり、図７に実施例を示す。
【００３５】
サービスシナリオはウエブアプリケーション導出のためのテンプレートであり、クライアントであるウエブブラウザからウエブサービスサーバにウエブサービスを要求する要求指示書である。
【００３６】
本発明の実施例においては、ウエブアプリケーションはクライアント側のサービスシナリオに記載されたＵＲＩをクライアント側から直接サービスを呼び出すことによって実行され、クライアント側のタスクセッション情報にスレッドセッションがアクセスすることによってウエブサービスが連携され、従ってクライアント側で個々のサービスが統合されるウエブサービスサービスの集合体である。
【００３７】
図４に示す本発明の実施例においては、これまでシングルサインオンサービスで行われてきた個人情報の管理をポータルサイト２２０に分離し、シングルサインオンサービス２９０はサービスを利用するユーザの認証のみを行い、ウエブサービスを利用するための個人情報の管理はポータルサイト側で行う。あわせてポータルサイト２２０ではウエブアプリケーションの選択のための図１６で示すメニュー画面９００を提供する。
【００３８】
メニュー画面９００を選択して開始したウエブアプリケーションは、クライアント２００とウエブサービスサイトＡ２４０とウエブサービスサイトＢ２６０のサイトの間でセッション識別子が遷移する。
【００３９】
こうして異なるウエブサイトをまたがるウエブアプリケーションのセッションモデルにおいて、クライアント２００のオブジェクト２１０でのタスクセッション情報とウエブサービスサイトＡ２４０のオブジェクト２４０でのスレッドセッション情報２５０とウエブサービスサイトＢ２６０でのスレッドセッション情報２７０によって一組のウエブアプリケーションが構成される。
【００４０】
上に示したように、シングルサインオンサービス２９０では個人情報は保持せず、ポータルサイト２２０で個人情報を保持する。これによってサインオンするＩＤと個人情報の保管を分離させる。
【００４１】
このポータルサイト２２０は、各ウエブサービスサイトが提供するウエブサービスの組合せからなるウエブアプリケーションの提供窓口でもある。この提供窓口で、シングルサインオンサービスで行われてきた個人情報の管理を行うことは、本発明の実施例でのサービスシナリオでサービスを実施する上での特長である。
【００４２】
次に図５は、本発明の実施例におけるインターネット上のウエブサービスサーバの構成図での各サイトに共有されるユーザ情報の関連図である。
【００４３】
ウエブアプリケーションの実行の順序は、ユーザがクライアント２００から、インターネット１８０を経由してシングルサインオンサービス２９０にサインオンＩＤでサインオンすると、シングルサインオンサービス２９０ではあらかじめ登録しておいたポータルサイトで有効なユーザＩＤをサインオンＩＤと置き換え、ポータルサイト以降のセッションに遷移する。次にポータルサイト２２０では、ウエブアプリケーションのメニューを提供し、あらかじめ登録し保存しているユーザ情報をユーザＩＤで検索して、ユーザ情報２３１を取り出す。次にユーザがウエブアプリケーションのメニューを選択すると店舗サイト２４１、その後クレジットカードサイト２６１へセッションが遷移する。この時、クライアント２００から各サイトへの通知情報２５１とサイトへの通知情報２７１では、通知される情報に差が有る。
【００４４】
これは、共有しない情報としてクレジットカード番号とパスワードを考えた場合、クライアント２００は、クレジットカード番号をクレジットカードサイト２６１に通知するが店舗サイト２４１には通知しない。クライアントで発生した情報２１１は、個々のサイトに対し必要な情報のみ各サイトに通知され、クレジットカード番号とパスワードは店舗サイト２４１には通知されない。
【００４５】
本発明の実施例でのウエブアプリケーション選択画面を図１６に示し、そのメニュー画面９００でウエブサービス・アプリケーションＡ１９０１を選択した場合、図１７に示すサービスシナリオの概念４８１が選択される。
【００４６】
このサービスシナリオの概念に対応するウエブサービスサイトのサービス構成を図６に示す。ウエブサービスサイトＡ２４０の中のウエブサービスａ１６１０、ウエブサービスａ２６１２、マネージャＵＲＩ６１６、サービス起動ＵＲＩ６１８、ログインＵＲＩ６２０とウエブサービスサイトＢ２６０の中のウエブサービスｂ１６３０、ウエブサービスｂ２６３２、マネージャＵＲＩ６３６、サービス起動ＵＲＩ６３８、ログインＵＲＩ６４０から構成される。
【００４７】
また（ａ）のウエブサービスサイトＡ２４０に対応するｈｏｓｔｎａｍｅは、ｓｉｔｅ＿Ａ．ｈｉｔａｃｈｉ．ｃｏ．ｊｐ２４５で、ウエブサービスａ１６１０に対応するｐａｔｈｎａｍｅは／ｓｅｒｖｉｃｅ＿ｍｅｔｈｏｄ／ａ１．ｈｔｍｌ６１１に対応し、ウエブサービスａ２６１２に対応するｐａｔｈｎａｍｅは／ｓｅｒｖｉｃｅ＿ｍｅｔｈｏｄ／ａ２．ｈｔｍｌ６１３に対応する。サービス起動ＵＲＩ６３８に対応するｐａｔｈｎａｍｅは／ｓｅｒｖｉｃｅ．ｈｔｍｌ６１９、ログインＵＲＩ６２０に対応するｐａｔｈｎａｍｅは／ｌｏｇｉｎ．ｈｔｍｌ６２１である。同様に（ｂ）にウエブサービスサイトＢ２６０のサービス構成を示す。
【００４８】
本発明の実施例でのサービスシナリオの概念の具体例としてのサービスシナリオを図７に示す。サービスシナリオ１２０はウエブサービスのＵＲＩとその対応するウエブサービスのメソッドの説明からなる。
【００４９】
ここで示すサービスシナリオのテーブルは、タスクセッションの開始から終了の手順で、スレッドセッション開始６５０、６７０とスレッドセッション終了６６０、６８０により、スレッドセッションの開始と終了がポータルサイトに通知されポータルサイト側で管理可能となる。
【００５０】
加えてサービスシナリオ１２０のメソッドの説明をクライアントで公開するために、サービスＵＲＩ１２１に対するウエブサービスのメソッドの説明１２２をテーブルに追加する。
【００５１】
図１は、タスクセッション情報２１０とスレッドセッション情報２５０、２７０がウエブアプリケーション実行時の参照とアクセスの範囲を示す。
【００５２】
タスクセッション情報２１０はサービスシナリオ１２０の開始から終了の間、実行されるウエブサービスからアクセスされる。スレッドセッション情報２５０は、スレッドセッション開始６５０からスレッドセッション終了６６０までの間でアクセスされる。同様に、スレッドセッション情報２７０は、スレッドセッション開始６７０からスレッドセッション終了６８０までの間でアクセスされる。
【００５３】
このスレッドセッション情報は他のウエブサービスと共用しない。
【００５４】
次にスレッドセッション開始時にスレッドセッションの識別子として、スレッドセッションＩＤを発行する。このＩＤはスレッドセッションの間のみ有効で、セッションが終了した時点でそのセッション識別子を破棄し、合わせてサーバ及びクライアント側のスレッドセッションのためのオブジェクトを破棄する。
【００５５】
この様に、ウエブサイト毎に個別のセッション識別子を持ちセッションを確立するため、他のウエブサイトが補足した自身のセッション識別子では他のセッション情報にアクセスまたは参照することができないことから、よって他のウエブサービスサイトからスレッドセッション情報が参照されない利点を持つ。
【００５６】
図１８に本発明の実施例におけるタスクセッションＩＤ管理テーブルを示す。
【００５７】
タスクセッションＩＤ管理テーブル９２０はユーザＩＤ９２１とタスクセッションＩＤ９２２とセッションオブジェクトＩＤ９２３の項目からなるテーブルである。
【００５８】
図１９に本発明の実施例におけるスレッドセッションＩＤ管理テーブルを示す。
【００５９】
スレッドセッションＩＤ管理テーブル９３０はタスクセッションＩＤ９３１とスレッドセッションＩＤ９３２とスレッドセッションオブジェクトＩＤ９３３からなるテーブルである。
【００６０】
図８と図９は、本発明の実施例におけるタスクセッションＩＤとスレッドセッションＩＤのメッセージフロー図である。
【００６１】
図８ではサービスシナリオに基づいてクライアント２００からポータルサイトのセッション管理７００にユーザＩＤとタスクセッション開始７３１のメッセージが送信される。
【００６２】
ポータルサイトのセッション管理７００はサーバ側で保持するタスクセッションオブジェクトとタスクセッションＩＤであるタスクセッションＩＤを生成し、クライアント２００にタスクセッションＩＤ７３２のメッセージを返信し、このときタスクセッションＩＤ管理テーブル７２０にユーザＩＤとタスクセッションＩＤ３１０とタスクセッションオブジェクトＩＤを登録する。
【００６３】
次に、スレッドセッションの開始として、クライアント２００からタスクセッションＩＤとスレッドセッション開始７４０のメッセージをサイトＡのセッション管理７１０に送信する。
【００６４】
サイトＡのセッション管理７１０は、タスクセッションＩＤとスレッドセッション開始７４１のメッセージをポータルサイトのセッション管理７００に送り、ポータルサイトのセッション管理７００は、タスクセッションＩＤ管理テーブル９２０のタスクセッションＩＤ９２２と受信したタスクセッションＩＤから要求が有効か無効かの判定を行い、スレッドセッションの開始−ｏｋ７４２のメッセージを返信し、サイトＡのセッション管理では、スレッドセッションオブジェクトを生成し、合わせてスレッドセッションのためのスレッドセッションＩＤを生成し、このときそれぞれをスレッドセッションＩＤ管理テーブル９３０のタスクセッションＩＤ９３１とスレッドセッションＩＤ９３２とスレッドセッションオブジェクトＩＤ９３３に登録し、スレッドセッションＩＤ７４３のメッセージをクライアント２００に返信する。
【００６５】
クライアント２００は受信したスレッドセッションＩＤを用いてスレッドセッションを開始する。次に、クライアント２００はウエブサービスａ１６１０にスレッドセッションＩＤ７４４のメッセージでサービスのリクエストを送信し、ウエブサービスａ１６１０は結果と併せてスレッドセッションＩＤ７４５のメッセージを返信する。同様にウエブサービスａ２６２０にスレッドセッションＩＤ７４６のメッセージでサービスのリクエストを送信し、ウエブサービスａ２６２０は結果と併せてスレッドセッションＩＤ７４７のメッセージを返信する。
【００６６】
スレッドセッションの終了としてクライアント２００からタスクセッションＩＤとセッション終了７４８のメッセージをサイトＡのセッション管理７１０に送る。
【００６７】
サイトＡのセッション管理は、スレッドセッションＩＤ管理テーブル９３０からスレッドセッションＩＤをキーとしてタスクセッションＩＤ３１０を取り出し、タスクセッションＩＤ３１０とスレッドセッション終了７４９のメッセージをポータルサイトのセッション管理７００に送る。ポータルサイトのセッション管理７００では、タスクセッションＩＤ管理テーブル９２０のタスクセッションＩＤ９２２と受信したタスクセッションＩＤから要求が有効か無効かの判定を行い、有効であればスレッドセッションの終了−ｏｋ７５０のメッセージをサイトＡのセッション管理に返信し、サイトＡのセッション管理は、スレッドセッションオブジェクトを破棄し、スレッドセッションＩＤ管理テーブル９３０からスレッドセッションＩＤをキーとしてレコードを削除し、スレッドセッションＩＤとスレッドセッションの終了−ｏｋ７５１のメッセージをクライアント２００に返信し、クライアント２００でスレッドセッションＩＤを破棄する。
【００６８】
次に図８に示す様に、同様にサイトＢにおいてもメッセージの送受信を行う。
【００６９】
スレッドセッションの開始として、クライアント２００からタスクセッションＩＤとスレッドセッション開始７６０のメッセージをサイトＢのセッション管理７２０に送信する。
【００７０】
サイトＢのセッション管理７２０は、タスクセッションＩＤとスレッドセッション開始７６１のメッセージをポータルサイトのセッション管理７００に送り、ポータルサイトのセッション管理７００は、タスクセッションＩＤ管理テーブル９２０のタスクセッションＩＤ９２２と受信したタスクセッションＩＤから要求が有効か無効かの判定を行い、スレッドセッションの開始−ｏｋ７６２のメッセージを返信し、サイトＡのセッション管理では、スレッドセッションオブジェクトを生成し、合わせてスレッドセッションのためのスレッドセッションＩＤを生成し、このときそれぞれをスレッドセッションＩＤ管理テーブル９３０のタスクセッションＩＤ９３１とスレッドセッションＩＤ９３２とスレッドセッションオブジェクトＩＤ９３３に登録し、スレッドセッションＩＤ７６３のメッセージをクライアント２００に返信する。
【００７１】
クライアント２００は受信したスレッドセッションＩＤを用いてスレッドセッションを開始する。次に、クライアント２００はウエブサービスｂ１６３０にスレッドセッションＩＤ７６４のメッセージでサービスのリクエストを送信し、ウエブサービスｂ１６３０は結果と併せてスレッドセッションＩＤ７６５のメッセージを返信する。同様にウエブサービスｂ２６４０にスレッドセッションＩＤ７６６のメッセージでサービスのリクエストを送信し、ウエブサービスｂ２６４０は結果と併せてスレッドセッションＩＤ７６７のメッセージを返信する。
【００７２】
スレッドセッションの終了としてクライアント２００からタスクセッションＩＤとセッション終了７６８のメッセージをサイトＡのセッション管理７２０に送る。
【００７３】
サイトＢのセッション管理は、スレッドセッションＩＤ管理テーブル９３０からスレッドセッションＩＤをキーとしてタスクセッションＩＤ３１０を取り出し、タスクセッションＩＤ３１０とスレッドセッション終了７６９のメッセージをポータルサイトのセッション管理７００に送る。ポータルサイトのセッション管理７００では、タスクセッションＩＤ管理テーブル９２０のタスクセッションＩＤ９２２と受信したタスクセッションＩＤから要求が有効か無効かの判定を行い、有効であればスレッドセッションの終了−ｏｋ７７０のメッセージをサイトＡのセッション管理に返信し、サイトＡのセッション管理は、スレッドセッションオブジェクトを破棄し、スレッドセッションＩＤ管理テーブル９３０からスレッドセッションＩＤをキーとしてレコードを削除し、スレッドセッションＩＤとスレッドセッションの終了−ｏｋ７７１のメッセージをクライアント２００に返信し、クライアント２００でスレッドセッションＩＤを破棄する。
【００７４】
最後にタスクセッションを終了するために、クライアント２００からタスクセッションＩＤとタスクセッション終了７８１のメッセージをポータルサイトのセッション管理７００に送る。ポータルサイトのセッション管理７００では、タスクセッションオブジェクトを破棄し、タスクセッションＩＤ管理テーブル９２０をタスクセッションＩＤ３１０で検索し、該当レコードを削除し、タスクセッション終了−ｏｋ７８２のメッセージを返信し、クライアント２００はウエブアプリケーションを終了する。
【００７５】
次に、本発明の実施例におけるポータルサイトのセッション管理の開始と終了のフローチャートを図１０で示す。
【００７６】
ステップ５００でクライアントから要求されたＨＴＴＰ要求から引数を取り出し、ステップ５１０で引数がセッション開始かどうかの判定を行い、結果がＹＥＳの場合開始処理となる。ステップ５１５でＨＴＴＰ要求からｃｏｏｋｉｅデータを取り出し、ステップ５２０でｃｏｏｋｉｅの中にユーザＩＤが有るかどうかの判定を行い、結果がＹＥＳの場合ステップ５２５でセッションオブジェクトを生成し、ステップ５３０でタスクセッションＩＤを生成し、ステップ５３５でユーザＩＤとタスクセッションＩＤとセッションオブジェクトＩＤからなるレコードを、タスクセッションＩＤ管理テーブル９２０に登録し、ステップ５４０でｃｏｏｋｉｅにタスクセッションＩＤを設定しＨＴＴＰ応答をクライアントに返す。
【００７７】
ステップ５１０の判定で結果がＮＯの場合終了処理となる。ステップ５５０でＨＴＴＰ要求からｃｏｏｋｉｅデータを取り出し、ステップ５５５でｃｏｏｋｉｅの中にタスクセッションＩＤが有るかどうかの判定を行い、ＹＥＳの場合ステップ５６０でタスクセッションＩＤ管理テーブル９２０をタスクセッションＩＤで検索し、ステップ５６５で該当レコードのセッションオブジェクトＩＤからセッションオブジェクトを破棄し、ステップ５７０でタスクセッションＩＤの示すレコードをタスクセッションＩＤ管理テーブル９２０から削除し、ステップ５７でセッション終了−ｏｋメッセージをＨＴＴＰ応答として返す。
【００７８】
図１１、図１２、図１３は本発明の実施例におけるウエブサービスサイトのセッション管理の手順のフローチャート図である。
【００７９】
図１１のステップ８０１でクライアントからのＨＴＴＰ要求から引数を取り出しステップ８０２、ステップ８０４ででスレッドセッションンの開始及び終了の判定をし、ステップ８０３はスレッドセッションの開始処理で、ステップ８０５はスレッドセッションの終了処理を示す。
【００８０】
図１２の、スレッドセッションの開始処理はステップ８１２でステッ８１１のＨＴＴＰ要求から取り出したｃｏｏｋｉｅにタスクセッションＩＤが有るかの判定を行い、ＮＯの場合はエラーとなる。
【００８１】
判定がＹＥＳの場合は、ステップ８１３でポータルサイトのセッションＩＤ管理にタスクセッションＩＤとスレッドセッション開始のメッセージで問い合わせる。ステップ８１４で応答メッセージはスレッドセッション開始−ｏｋか判定し、ＮＯの場合はエラーとなる。
【００８２】
ＹＥＳの場合ステップ８１５でスレッドセッションオブジェクトを生成し、ステップ８１６でスレッドセッションＩＤを生成し、ステップ８１７でタスクセッションＩＤとスレッドセッションＩＤとスレッドセッションオブジェクトＩＤをスレッドセッションＩＤ管理テーブル９３０に登録し、ステップ８１８でｃｏｏｋｉｅのタスクセッションＩＤを削除し、ステップ８１９でｃｏｏｋｉｅにスレッドセッションＩＤを登録し、ステップ８２０でスレッドセッションＩＤをクライアントに返信する。
【００８３】
図１３の、スレッドセッションの終了処理は８２１のＨＴＴＰ要求からｃｏｏｋｉｅを取り出し、ステップ８２２でスレッドセッションＩＤが有るかどうかの判定を行い、ＮＯの場合はエラーとなる。
【００８４】
結果がＹＥＳの場合は、ステップ８２３でスレッドセッションＩＤ管理テーブルからスレッドセッションＩＤでタスクセッションＩＤを検索し、ステップ８２４でポータルサイトのセッション管理にタスクセッションＩＤで問い合わせ、ステップ８２５でポータルサイトのセッション管理の応答メッセージはスレッドセッション終了−ｏｋかどうかの判定を行い、ＮＯの場合はエラーとなる。
【００８５】
結果がＹＥＳの場合、ステップ８２６でスレッドセッションＩＤ管理テーブルからスレッドセッションＩＤをキーとしてレコードを検索し、ステップ８２７でスレッドセッションＩＤの示すスレッドセッションオブジェクトを破棄し、ステップ８２８で検索したレコードを削除し、ステップ８２９でｃｏｏｋｉｅのタスクセッションＩＤを削除し、ステップ８３０でスレッドセッション終了−ｏｋのメッセージをクライアントに返信する。
【００８６】
図１４は、本発明の実施例におけるウエブサービスサイトのウエブサービスの実行の手順のフローチャート図である。
【００８７】
ウエブサービスの実行は、ステップ８３１でウエブサービスサーバは、ＨＴＴＰ要求を受信すると、ステップ８３２でｃｏｏｋｉｅからスレッドセッションＩＤを取り出し、ステップ８３３でスレッドセッションＩＤが有るかどうかの判定を行い、ＮＯの場合エラーとなる。
【００８８】
ＹＥＳの場合、ステップ８３４でＨＴＴＰの引数を取り出し、ステップ８３５で引数に応じたＨＴＴＰ要求のメソッドを実行し、ステップ８３６でメソッドの実行結果をｃｏｏｋｉｅのスレッドセッションＩＤと供に返信する。
【００８９】
図１５は本発明の実施例におけるクライアントでのサービスシナリオの実行の手順のフローチャート図である。
【００９０】
ステップ８４１でタスクセッションを開始し、ステップ８４２でサービスシナリオテーブル１２０から次のウエブサービスサイトとウエブサービスを取り出し、ステップ８４３でウエブサービスが有るかどうかの判定を行い、結果がＮＯの場合ステップ８４８でタスクセッションの終了となり、ステップ８４３の結果がＹＥＳの場合ステップ８４４でスレッドセッション開始または終了かの判定を行い、結果がＹＥＳの場合ステップ８４５でｃｏｏｋｉｅにスレッドセッションＩＤが有れば削除し、ステップ８４５でｃｏｏｋｉｅにタスクセッションＩＤを登録し、ステップ８４６でウエブサービスサーバにウエブサービスを要求してステップ８４２から繰り返す。
【００９１】
ステップ８４４の結果がＮＯの場合は、ステップ８４９でｃｏｏｋｉｅにスレッドセッションＩＤがあるかの判定を行い、結果がＹＥＳの場合ステップ８４６を実行する。
【００９２】
次に、クライアントとウエブサービスサイトとのネットワークでの接続形態及びサービスの内容を比較するために、これまでのウエブサービスの利用モデルを図２０に示し、本発明のウエブサービスの利用モデルを図２１に示す。
【００９３】
図２０のこれまでのウエブサービスの利用モデルが示すクライアントとウエブサービスサイトとの接続形態及びサービスの内容では、ポータルサイト２２０がアプリケーションサーバとなって、ウエブサービスサイト１９０からのサービスを仲介または統合してクライアント２００のユーザにアプリケーション（サービス）を提供している。
【００９４】
それに対し、図２１の本発明のウエブサービスの利用モデルが示すクライアントとウエブサービスサーバとの接続形態及びサービスの内容では、ポータルサイト２２０はアプリケーションのメニューとサービスの承認を提供し、クライアント２００のユーザは直接ウエブサービスサイト１９０からサービスを受け取る。つまりｌクライアントとウエブサービスはピア・ツウ・ピアの接続形態となる。
【００９５】
本発明の効果として、スレッドセッションをおこうサービスサイト毎にセッションのためのタイムアウト期間を設定が本発明によって可能となる。これはタイムアウト時間の設定が、サービスを提供するウエブサービスサーバにおいて設定出来るので、サービスサイト毎のタイムアウト期間が設定できる。これによって、例えばウエブでのショッピングおいてショッピングサイトでのタイムアウトまでの設定期間をこれまで設定されていた期間よりも長く、また決済のためのカードサイトにおいての設定期間をこれまで設定されていた期間より短く設定することによって、ショッピングサイトの利便性の改善とカードサイトのセキュリティに対する信頼性を向上することが出来る。
【００９６】
以上説明した様に、ウエブサービスのユーザ・インタフェース・セッションにおいて、これまでウエブアプリケーション間で用いられてきたセッションＩＤをタスクセッションＩＤとスレッドセッションＩＤからなる二つのＩＤによって構成することは、あたかもコンピュータがシングルプロセッサからマルチプロセッサへと進化した時に、それに応じて実行プログラムも複数のプロセッサに割り当てを可能とするために、プログラムの実行単位をプロセスからタスクとスレッドという概念に進化したことと類似している。
【００９７】
つまりタスクセッションＩＤとスレッドセッションＩＤの概念は、複数のウエブサービスサイトが提供するウエブサービスを実行させるために、ＣＰＵにプログラム実行単位のスレッドを割り当てるように、ウエブサイト毎のウエブサービスの実行単位ににスレッドの割り当てを行うようなものである。
【００９８】
このとき割り当てられるスレッドはスレッドセッションであり、サービスシナリオで示される実行パスである。そしてサービスシナリオはタスクと１：１の関係であって、タスクが起動している時だけこのスレッドセッションは実行される。
【００９９】
従って、新たなセッションモデルによって、ウエブサービスがシングルサインオンで認証された後のタスクからのアクセス時に、ウエブサービスサイトがアクセスのための単位ノードとなり、クライアントとピア・ツウ・ピアで接続することが可能となる。
【０１００】
それは、来る電子的情報通信ネットワークを新たな公共のコミュニティの骨格となる神経網とする社会において、社会のあらゆる単位ノード間が互いにピアとして結ばれる構造となった場合に、こうした通信系のトポロジにおいてウエブサービスサイトが単位ノードとなり、ウエブサービスが実行単位となることは、ネットワーク型コミュニケーションのための社会的インフラとして必要であると同時にネットワークノードの稼動を制御する基本的な方法として有効である。
【０１０１】
【発明の効果】
本発明によれば、ウエブサービスのユーザ・インタフェース・セッションにおけるウエブサービス間でサービスサイトの異なるサービスを連携し、かつサービスサイト単位のセッション情報を共用しない方法が開示される。
【図面の簡単な説明】
【図１】本発明の実施例におけるサービスシナリオ実行時のタスクセッション情報とスレッドセッション情報のスコープを示す図である。
【図２】本発明の実施例におけるサービスシナリオで利用可能なウエブサービスの集合の図である。
【図３】本発明の実施例におけるシングルサインオンサービスからサービスサイトへの通知される情報の例図である。
【図４】本発明の実施例におけるインターネット上のウエブサービスサーバの構成図でのタスクセッションＩＤとスレッドセッションＩＤの関連図である。
【図５】本発明の実施例におけるインターネット上のウエブサービスサーバの構成図での各サイトに共有されるユーザ情報の関連図である。
【図６】本発明の実施例におけるウエブサービスサイトのサービス構成図である。
【図７】本発明の実施例におけるサービスシナリオのテーブル図である。
【図８】本発明の実施例におけるタスクセッションＩＤとスレッドセッションＩＤの概念的なメッセージフロー図である。
【図９】本発明の実施例におけるタスクセッションＩＤとスレッドセッションＩＤの概念的なメッセージフロー図である。
【図１０】本発明の実施例におけるウエブサービスサイトでのタスクセッション管理の処理のフローチャート図である。
【図１１】本発明の実施例におけるウエブサービスサイトでのスレッドセッション管理の手順のフローチャート図である。
【図１２】本発明の実施例におけるウエブサービスサイトでのスレッドセッション管理の開始メソッドの手順のフローチャート図である。
【図１３】本発明の実施例におけるウエブサービスサイトでのスレッドセッション管理の終了メソッドの手順のフローチャート図である。
【図１４】本発明の実施例におけるウエブサービスサイト側でのウエブサービスを実行する手順のフローチャート図である。
【図１５】本発明の実施例におけるクライアントでサービスシナリオを基にウエブサービスを要求する手順のフローチャート図である。
【図１６】本発明の実施例におけるウエブアプリケーションを選択するメニュー画面の図である。
【図１７】本発明の実施例におけるサービスシナリオの概念図である。
【図１８】本発明の実施例におけるタスクセッションＩＤ管理テーブルの図である。
【図１９】本発明の実施例におけるスレッドセッションＩＤ管理テーブルの図である。
【図２０】これまでのウエブサービスの利用モデル図である。
【図２１】本発明の実施例におけるウエブサービスの利用モデル図である。
【符号の説明】
１００…サインオンＩＤ、１２０…サービスシナリオ、１８０…インターネット、２００…クライアント、２１０…タスクセッション情報、２２０…ポータルサイト、２３０…セッション管理、１９０、２４０、２６０…ウエブサービスサイト、２５０、２７０…スレッドセッション管理、２９０…シングルサインオンサービス、３００…セッションＩＤ、３１０…タスクセッションＩＤ、３２０…スレッドセッションＩＤ、７００…ポータルサイトのセッション情報、９００…メニュー画面。

Claims

シングルサインオンでの認証エージェントを共有し信頼した認証プロセスの後において、サービスシナリオが示す異なるサービスサイトのウエブサービスを実行するためのユーザ・インタフェース・セッションを承認する方法であって、
ａ）アプリケーションの実行単位としてのタスクセッションと、
ｂ）サービスサイト単位のセッションを実行単位とするスレッドセッションと、を含むことを特徴とするウエブセッション制御方式。
請求項１に記載のウエブセッション制御方式において、
ａ）スレッドセッションが、サービスサイト同一の１つ以上の連続するウエブサービスを示す段階と、
ｂ）タスクセッションとは、サービスシナリオの実行時における開始から終了までのセッションで１つ以上のスレッドセッションをまたがるセッションを示す段階と、
を含むウエブセッション制御方式。
請求項１に記載のウエブセッション制御方式において、
ａ）上記ウエブサービスシナリオを実行する単位を、セッション識別子であるセッションＩＤを、タスクセッションＩＤとスレッドセッションＩＤに分ける方法と、
ｂ）タスクセッション側をタスクセッションＩＤに定義する方法と、
ｃ）スレッドセッション側をスレッドセッションＩＤに定義する方法と、
を含む、サービスサイト単位の独立したセッション識別子を保有することによってセッションを確立させる方法。
請求１に記載のウエブセッション制御方式において、
ａ）上記タスクセッションのためのセッションオブジェクトをクライアントとポータルサイトに持つステップと、
ｂ）スレッドセッションのためのオブジェクトを個々のウエブサービスサーバに持つステップと、
を含むセッション情報を保持する方法。
請求項１に記載のウエブセッション制御方式において、
ａ）クライアントからウエブアプリケーションの呼び出しを実行するための仕掛けとして上記サービスシナリオを持つ方法と、
ｂ）上記サービスシナリオは、ウエブサービスを呼び出すためのステップと、
ｃ）上記サービスシナリオは、スレッドセッションの開始と終了時の確認を行うウエブサービスの呼び出しを記載する手段と、
を含むサービスシナリオの実行指示に従ってウエブサービスを実行する方法。
請求項４に記載のウエブセッション制御方式での上記ポータルサイトにおいて、
ａ）ウエブアプリケーションを選択するためのメニュー画面を提供する段階と、
ｂ）ユーザの個人情報を保持しサービスサイトに提供する段階と、
を含むプログラム。
請求項６に記載のウエブセッション制御方式での上記ポータルサイトにおいて、
上記ポータルサイトでタスクセッションの開始と終了とスレッドセッションの実行許可を管理するするための記憶手段に記憶するプログラム。
請求項２に記載のウエブセッション制御方式において、
サービスを提供するサイトとポータルサイトとで、スレッドセッションの開始と終了と実行許可を管理するするための記憶手段に記憶するプログラム。
請求項４に記載のセッション情報を保持する方法において、
タスクセッション開始時に、
ａ）タスクセッションオブジェクトを生成するステップと、
ｂ）識別子であるタスクセッションＩＤを生成するステップと、
タスクセッション終了時に
ｃ）タスクセッションオブジェクトを破棄するステップと、
ｄ）識別子であるタスクセッションＩＤを破棄するステップと、
を含むタスクセッション管理のプログラム。
請求項９に記載のタスクセッションのプログラムにおいて、
タスクセッションＩＤ管理テーブルに対し、
ａ）タスクセッション開始時に、ユーザＩＤとタスクセッションＩＤとタスクセッションオブジェクトのインスタンスからなるレコードを登録するステップと、
ｂ）タスクセッション終了時に、タスクセッションＩＤでレコードを削除するステップと、
を含むタスクセッション管理のプログラム。
請求項４に記載のセッション情報を保持する方法において、
スレッドセッション開始時に、
ａ）スレッドセッションオブジェクトを生成するステップと、
ｂ）識別子であるスレッドセッションＩＤを生成するステップと、
スレッドセッション終了時に、
ｃ）スレッドセッションオブジェクトを破棄するステップと、
ｄ）識別子であるスレッドセッションＩＤを破棄するステップと、
を含むスレッドセッション管理のプログラム。
請求項１１に記載のスレッドセッションのプログラムにおいて、
スレッドセッションＩＤ管理テーブルに対し、
ａ）スレッドセッション開始時に、タスクセッションＩＤとスレッドセッションＩＤとスレッドセッションオブジェクトのインスタンスからなるレコードを登録するステップと、
ｂ）スレッドセッション終了時に、スレッドセッションＩＤでレコードを削除するステップと、
を含むスレッドセッション管理のプログラム。
請求項１に記載のウエブセッション制御方式において、
ａ）ウエブサービスのユーザ・インタフェース・セッションの連携メカニズムを異なるウエブサービスサイトのウエブサービスサーバでサービス可能とするセッションモデルと、
ｂ）ウエブサービスサイト単位のセッションを確立させるセッションモデルと、を含むウエブセッション制御のプログラム。
請求項４に記載のセッション情報を保持する方法において、
クライアントで発生した情報を他のウエブサービスサイトと共用しないことを含む、ウエブサービスサイト単位のセッション情報を共用しない方法。
請求項１に記載のウエブセッション制御方式において、
ａ）サインオンＩＤで利用可能なウエブサービスサイトが示すウエブサービスの集合を集合Ａとする段階と、
ｂ）サービスシナリオで利用可能なウエブサービス集合を集合Ｂとする段階と、
ｃ）ＢはＡの部分集合である関係と、
ｄ）ＢをサービスシナリオによるＡの像である関係と、
ｅ）集合Ａから集合Ｂへの写像への関係が、アプリケーション実行時に選択したサービスシナリオによって成立する手段と、
によって利用可能なウエブサービスがダイナミックに制限されるプログラム。
上記ウエブサービスサイトにおいて、
ａ）サインオン時にログインするための工程と、
ｂ）上記ポータルサイトに対しウエブサービスの実行許可を確認するための工程と、
ｃ）クライアントからの要求でウエブサービスを起動するための工程と、
を含むウエブサービスの実行を制御するプログラム。
ウエブサービスサイト単位のセッション情報の中で他のサービスサイトと共有する必要の有る情報を、クライアント側のタスクセッションオブジェクトを用いて共有する方法およびプログラム。
上記ウエブセッション制御方式は、サービスサイトの単位セッションにおいてセッションのタイムアウト期間を設定することを可能とする請求項１の方法。