(57)【要約】【課題】提供可能な時間帯やユーザの権限等が異なる複数のサービスを提供するサーバシステムにおいて、提供不可であるサービスに対してアクセスがあった場合でも、アプリケーションサーバに余計なアクセスが発生しないように制御するサーバシステムを提供する。【解決手段】複数のサービスをＰＬサーバ１００を介してクライアント端末６００に提供するサーバシステムであって、ＰＬサーバ１００は、セッション管理ＴＢＬ１５７と、サービス時間管理ＴＢＬ１５６と、クライアント端末６００から利用要求を受けた前記サービスについて、サービス時間管理ＴＢＬ１５６が保持する情報と現在時刻との比較に基づいて前記サービスの提供可否を判定するサービス制御部１５３とを有し、サービス制御部１５３にて前記サービスが提供不可であると判定した場合は、前記サービスが提供不可である旨の応答をクライアント端末６００に対して送信する。【選択図】図１
2010039763.tif 000002
【特許請求の範囲】
【請求項１】
Ｗｅｂサーバ、アプリケーションサーバ、ＤＢサーバを有し、前記アプリケーションサーバおよび前記ＤＢサーバによって処理される複数のサービスを前記Ｗｅｂサーバを介してクライアント端末に提供するサーバシステムであって、
前記Ｗｅｂサーバは、前記クライアント端末との間のセッションに関する情報を保持するセッション管理テーブルと、
前記サービスを前記クライアント端末に提供可能な時間帯を前記サービス毎に保持するサービス時間管理テーブルと、
前記クライアント端末から利用要求を受けた前記サービスについて、前記サービス時間管理テーブルが保持する前記サービスを提供可能な時間帯の情報と、現在時刻との比較に基づいて、前記サービスの提供可否を判定するサービス制御部とを有し、
前記クライアント端末からの前記サービスの利用要求を受けた際に、前記サービス制御部にて、前記サービスが提供不可であると判定した場合は、前記サービスが提供不可である旨の応答を前記クライアント端末に対して送信することを特徴とするサーバシステム。
【請求項２】
請求項１に記載のサーバシステムにおいて、
前記セッション管理テーブルは、さらに、前記セッションを確立したユーザの属性情報および前記クライアント端末が前記Ｗｅｂサーバへのアクセスに利用したチャネルの情報に基づいて決定される前記セッションの属性情報を保持し、
前記サービス時間管理テーブルは、さらに、前記サービス毎に利用可能なユーザの属性情報を保持し、
前記サービス制御部は、前記クライアント端末から利用要求を受けた前記サービスについて、前記サービス時間管理テーブルが保持する前記サービスを提供可能な時間帯の情報と、現在時刻との比較、および前記サービス時間管理テーブルが保持する前記サービスを利用可能なユーザの属性情報と、前記セッション管理テーブルが保持する前記セッションの属性情報との比較に基づいて、前記サービスの提供可否を判定することを特徴とするサーバシステム。
【請求項３】
請求項１または２に記載のサーバシステムにおいて、
前記サービス時間管理テーブルが保持する前記サービスを提供可能な時間帯の情報を随時変更することが可能であることを特徴とするサーバシステム。
【請求項４】
請求項１〜３のいずれか１項に記載のサーバシステムにおいて、
前記Ｗｅｂサーバは、前記クライアント端末が前記Ｗｅｂサーバへのアクセスに利用可能なチャネル毎に、前記チャネルの利用可否の情報を保持するチャネル管理テーブルと、
前記クライアント端末が前記Ｗｅｂサーバへのアクセスに利用した前記チャネルについて、前記チャネル管理テーブルが保持する前記チャネル毎の利用可否の情報に基づいて、前記チャネルの利用可否を判定するチャネル制御部とを有し、
前記クライアント端末からの前記サービスの利用要求を受けた際に、前記チャネル制御部にて、前記クライアント端末が前記Ｗｅｂサーバへのアクセスに利用した前記チャネルが利用不可であると判定した場合は、前記サービスが提供不可である旨の応答を前記クライアント端末に対して送信することを特徴とするサーバシステム。
【請求項５】
請求項４に記載のサーバシステムにおいて、
前記チャネル管理テーブルが保持する前記チャネルの利用可否の情報を随時変更することが可能であることを特徴とするサーバシステム。
【請求項６】
請求項１〜５のいずれか１項に記載のサーバシステムにおいて、
前記サービス制御部は、前記Ｗｅｂサーバから前記クライアント端末への応答時に、前記サービス時間管理テーブルが保持する前記サービス毎の提供可能な時間帯の情報と、現在時刻との比較、および前記サービス時間管理テーブルが保持する前記サービス毎の利用可能なユーザの属性情報と、前記セッション管理テーブルが保持する前記セッションの属性情報との比較に基づいて、当該時点において提供可能な前記サービスおよび提供可能な時間帯の情報の一覧を生成し、
前記一覧を前記クライアント端末の画面に表示させることを特徴とするサーバシステム。
【請求項７】
請求項１〜５のいずれか１項に記載のサーバシステムにおいて、
前記サービス制御部は、前記Ｗｅｂサーバから前記クライアント端末への応答時に、前記サービス時間管理テーブルが保持する前記サービス毎の提供可能な時間帯の情報と、現在時刻との比較、および前記サービス時間管理テーブルが保持する前記サービス毎の利用可能なユーザの属性情報と、前記セッション管理テーブルが保持する前記セッションの属性情報との比較に基づいて、当該時点において提供可能な前記サービスを特定し、
特定された前記サービスのメニューのみを前記クライアント端末の画面に表示させることを特徴とするサーバシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Ｗｅｂによってサービスを提供するサーバシステムにおいて、ユーザによるサービスの利用の制御を行う技術に関し、特に、提供可能な時間帯やユーザの権限等が異なる複数のサービスを提供するサーバシステムに適用して有効な技術に関するものである。
【背景技術】
【０００２】
Ｗｅｂを利用してユーザにサービスを提供するサーバシステムは、一般的に、ユーザの利用するクライアント端末とやり取りして、セッション管理や画面生成等に関する処理を行うＷｅｂサーバと、提供するサービス（業務）に固有の業務処理を行うアプリケーションサーバと、業務処理に必要となる各種データをデータベースとして保持するＤＢサーバとに機能的に分けて構成される、いわゆる三層構造を備えている。
【０００３】
提供するサービスの規模にもよるが、あるサービス（例えば株式の注文等）を処理するためには、通常は、アプリケーションサーバにて、細分化された単位業務を提供する複数のアプリケーションサーバや、その上で動作する複数の業務モジュールを順次もしくは並列的に呼び出して連携させて一連の処理を行うことにより、規模の大きなサービスについての処理を実現している。
【０００４】
このような単位業務を処理するアプリケーションサーバや業務モジュールでは、アプリケーションサーバや業務モジュール毎にメンテナンスやバッチ処理等の時間を定期的に確保するためのサービス停止時間が予め設けられており、サービス停止時間中に業務処理のリクエストを受けると、その都度サービス時間外のエラーを応答する必要があるため、余計な負荷がアプリケーションサーバや業務モジュールにかかってしまうという課題があった。
【０００５】
このような課題に対して、特開２００７−２４１５１０号公報（特許文献１）には、Ｗｅｂサーバとアプリケーションサーバの間に介装される業務制御システムであって、業務処理の処理プロセスと処理順序を規定する処理シーケンスを格納する処理シーケンスＴＢＬと、サービス提供時間帯および対応する処理シーケンスを格納するサービス時刻ＴＢＬと、要求されたサービスについて現在時刻に基づいて現時点でのサービス提供の可否を判定する手段等を備え、サービス停止時間中に処理要求がアプリケーションサーバに送信されないように制御するサーバシステムが開示されている。
【特許文献１】特開２００７−２４１５１０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
企業のポータルサイトなどでは、ユーザに対して複数のサービスが利用可能なように提供されている。その中で、サービス内容の向上・拡充のため、サービス提供の２４時間化なども進められてきている。その際には、情報の閲覧や照会など２４時間提供可能なサービスもあれば、例えば株式の売買等、実際のサービスが２４時間行われるわけではないものや、システムのメンテナンスやバッチ処理等のため定期的にサービスを停止するものもあり、全てのサービスが２４時間提供可能となるわけではない。また、システム障害や過負荷等により、特定のサービスのみ一時的に提供不可となる場合もある。
【０００７】
このような状況で、ユーザがその時点で提供可能ではないサービスにアクセスした場合に、従来技術によるサーバシステムでは、業務制御システムにおいて、各アプリケーションサーバや業務モジュールのサービス時刻に基づいてサービス提供の可否を判定することで、アプリケーションサーバに対してリクエストが送られ余計な負荷がかかるということは回避することができる。
【０００８】
しかし、Ｗｅｂサーバから業務制御システムに対しては余計なアクセスが発生してしまう。また、例えば、ユーザ毎の権限や属性などによって提供可能なサービスが異なる場合や、さらに、ユーザが所望のサービスにアクセスする経路（チャネル）が、例えば、自宅のパソコンや携帯電話、企業の営業店や店舗等に設置されている端末や、販売員等が有する携帯端末など複数存在し、それぞれのチャネルに対して個別のアプリケーションサーバや業務モジュールが存在するような場合は、従来技術の業務制御システムでは当該サービスの提供可否が判定できず、アプリケーションサーバや業務モジュールにて個別に判定手段を作りこむ必要がある。また、ユーザから見た場合、所望のサービスに実際にアクセスしてみるまで当該サービスが利用可能な状態か否かが不明であり利便性も高くない。
【０００９】
そこで本発明の目的は、提供可能な時間帯やユーザの権限等が異なる複数のサービスを提供するサーバシステムにおいて、ユーザの権限等や時間帯、アクセスのチャネルに応じて各サービスの提供可否を判断して提供可能なサービスのメニューをユーザに提示するように制御し、また、提供不可であるサービスに対してユーザからのアクセスがあった場合でも、アプリケーションサーバに余計なアクセスが発生しないように制御するサーバシステムを提供することにある。
【００１０】
本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。
【課題を解決するための手段】
【００１１】
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。
【００１２】
本発明の代表的な実施の形態によるサーバシステムは、Ｗｅｂサーバ、アプリケーションサーバ、ＤＢサーバを有し、前記アプリケーションサーバおよび前記ＤＢサーバによって処理される複数のサービスを前記Ｗｅｂサーバを介してクライアント端末に提供するサーバシステムであって、前記Ｗｅｂサーバは、前記クライアント端末との間のセッションに関する情報を保持するセッション管理テーブルと、前記サービスを前記クライアント端末に提供可能な時間帯を前記サービス毎に保持するサービス時間管理テーブルと、前記クライアント端末から利用要求を受けた前記サービスについて、前記サービス時間管理テーブルが保持する前記サービスを提供可能な時間帯の情報と、現在時刻との比較に基づいて、前記サービスの提供可否を判定するサービス制御部とを有し、前記クライアント端末からの前記サービスの利用要求を受けた際に、前記サービス制御部にて、前記サービスが提供不可であると判定した場合は、前記サービスが提供不可である旨の応答を前記クライアント端末に対して送信することを特徴とするものである。
【発明の効果】
【００１３】
本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。
【００１４】
本発明の代表的な実施の形態によれば、提供可能な時間帯やユーザの権限等が異なる複数のサービスを提供するサーバシステムにおいて、ユーザの権限等や時間帯、アクセスのチャネルに応じて各サービスの提供可否を判断して提供可能なサービスのメニューをユーザに提示することができるため、サービスを利用する際のユーザの利便性を高めることが可能となる。
【００１５】
また、本発明の代表的な実施の形態によれば、提供不可であるサービスに対してユーザからの利用要求があった場合でも、アプリケーションサーバに余計なアクセスが発生しないように制御することができるため、アプリケーションサーバにかかる負荷を低減することが可能となる。
【発明を実施するための最良の形態】
【００１６】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。
【００１７】
＜実施の形態＞
本発明の一実施の形態であるサーバシステムは、Ｗｅｂサーバ、アプリケーションサーバ、ＤＢサーバの三層構造を有し、アプリケーションサーバおよびＤＢサーバによって処理される複数のサービスをＷｅｂサーバを介してクライアント端末に提供するサーバシステムである。
【００１８】
本実施の形態のサーバシステムは、提供可能な時間帯やユーザの権限等が異なる複数のサービスを提供する際に、ユーザの権限等や時間帯、アクセスのチャネルに応じて各サービスの提供可否を判断して提供可能なサービスのメニューをユーザに提示するように制御し、また、提供不可なサービスに対してユーザからの利用要求があった場合でも、アプリケーションサーバに余計なアクセスが発生しないように制御する。
【００１９】
なお、本実施の形態のサーバシステムの説明において、「サービス」とは、ユーザ（クライアント）からの要求と、当該要求に対する応答からなる一連の処理によって実現される単位業務を指すものとし、例えば、株式のトレーディングシステムにおける注文処理やポートフォリオ分析、シミュレーション等の業務、インターネットバンキングシステムにおける残高照会や振込処理、口座情報の照会などが該当する。
【００２０】
また、「チャネル」とは、ユーザが所望のサービスを利用しようとする際に通った経路であり、例えば、自宅のパソコンや携帯電話、企業の営業店や店舗等に設置されている端末や、販売員等が有する携帯端末などの利用環境によって異なり、また、当該サービスを提供するＷｅｂサイトにどのＷｅｂサイトからリンクしてきたかによっても異なり得る。なお、チャネルはユーザが本実施の形態のサーバシステムにアクセスした際のＵＲＬ（Uniform Resource Locator）によって識別することができる。
【００２１】
＜システムの構成＞
以下、本実施の形態のサーバシステムのシステム構成について説明する。
【００２２】
図１は、本実施の形態のサーバシステムの構成例の概要を示した図である。サーバシステムは、三層構造におけるＷｅｂサーバに相当するプレゼンテーションロジック（ＰＬ）サーバ１００、アプリケーションサーバに相当するビジネスロジック（ＢＬ）サーバ２００、ＤＢサーバ３００を有する構成となっている。各サーバは、物理的にそれぞれ別の機器に構築されていてもよいし、一部または全部が同一の機器に論理的に分かれて構築されていてもよい。物理的に別の機器で構築されている場合は、各サーバはＬＡＮ等によって接続される。
【００２３】
クライアント端末６００は、インターネットやイントラネット等のネットワーク５００を介してＰＬサーバ１００経由で本実施の形態のサーバシステムに接続する。クライアント端末６００は、自宅のパソコンや携帯電話、企業の営業店や店舗等に設置されている端末や、販売員等が有する携帯端末など、Ｗｅｂブラウザや他のアプリケーションによってＷｅｂを利用したサービスの提供を受けることが可能な種々の機器が該当する。
【００２４】
ＰＬサーバ１００は、チャネル制御機能１１０、認証機能１２０、サービス制御機能１３０、外部連動機能１４０、ＰＬサーバ基盤部１５０、および画面制御部１６０を有する構成となっている。さらに、ＰＬサーバ基盤部１５０は、チャネル制御部１５１、認証部１５２、サービス制御部１５３、業務基盤部１５４、チャネル管理ＴＢＬ１５５、サービス時間管理ＴＢＬ１５６、セッション管理ＴＢＬ１５７を有する構成となっている。
【００２５】
チャネル制御機能１１０は、ＰＬサーバ１００のＷｅｂサーバの機能によってクライアント端末６００から受け付けたアクセスのチャネル（ＵＲＬ）を識別し、ＰＬサーバ基盤部１５０のチャネル制御部１５１によって、チャネル管理ＴＢＬ１５５の内容に従って、チャネル単位でサービスの提供可否の制御を行う。チャネル制御機能１１０には、利用可能なチャネル（ＵＲＬ）の情報が定義されている。
【００２６】
認証機能１２０は、クライアント端末６００からのアクセスに際して種々の認証の要否を識別し、ＰＬサーバ基盤部１５０の認証部１５２によって認証を行う。ここでの認証には、例えば、デジタル証明書による認証や、ワンタイムパスワードによる認証、Ｃｏｏｋｉｅによる認証、その他チャネル固有の認証などがある。
【００２７】
サービス制御機能１３０は、クライアント端末６００からの利用対象のサービスを識別し、ＰＬサーバ基盤部１５０のサービス制御部１５３によって、サービス時間管理ＴＢＬ１５６、セッション管理ＴＢＬ１５７の内容に従って、サービス毎に時間帯やユーザの権限等に基づいてサービスの提供可否の制御を行う。サービス制御機能１３０には、システムとして提供可能なサービスの情報が定義されている。また、サービス制御部１５３では、クライアント端末６００とのセッションに関する情報をセッション管理ＴＢＬ１５７に保持し、セッション情報の引継ぎやサービス毎のセッション数の管理などのセッション管理を行う。
【００２８】
サービス制御機能１３０は、クライアント端末６００からの利用対象のサービスの提供が可能である場合には、当該サービスを処理するＢＬサーバ２００を呼び出して業務処理を依頼する。クライアント端末６００からの利用対象のサービスが、本実施の形態のサーバシステムの外部のシステムによって提供される外部サービス４００である場合には、ＢＬサーバ２００ではなく、外部連動機能１４０を呼び出す。外部連動機能１４０は、ＰＬサーバ基盤部１５０の業務基盤部１５４によって該当の外部サービス４００に対して処理を依頼して連携することによってサービスを提供する。
【００２９】
このとき、セッション管理ＴＢＬ１５７のセッション情報を利用して業務基盤部１５４により対象の外部サービス４００にサインオンすることによってシングルサインオンを実現することも可能である。このような外部サービス４００としては、例えば、金融サービス会社によって提供される株価情報や、各種シミュレーションサービスなどがある。
【００３０】
画面制御部１６０は、クライアント端末６００からのサービスの利用要求に従ってＢＬサーバ２００もしくは外部サービス４００での業務処理が行われた結果に基づいて、保持している画面用ファイルから応答用の画面データ（ＨＴＭＬ（HyperText Markup Language）データ）を生成する。生成された画面データは、ＰＬサーバ１００のＷｅｂサーバの機能によって要求元のクライアント端末６００に送信され、クライアント端末６００のＷｅｂブラウザや他のアプリケーションによって表示される。
【００３１】
ＢＬサーバ２００は、業務制御部２１０と、業務モジュール２１０を有する構成となっている。さらに、業務制御部２１０は、時間制御部２１１と業務サービス制御部２１２を有する構成となっている。ＢＬサーバ２００では、従来技術に記載されているように、クライアント端末６００から要求されたサービスを実行するために必要となる複数の業務モジュール２２０が、業務制御部２１０での制御に従って順次または並列で実行される。また、複数のＢＬサーバ２００における業務モジュール２２０の連携によりサービスが実行される場合もある。
【００３２】
業務制御部２１０の時間制御部２１１は、各業務モジュール２２０の使用可能時間を保持し、この情報に基づいて、要求されたサービスが現時点で実行可能か否かを判定する。業務制御部２１０の業務サービス制御部２１２は、要求されたサービスが実行可能な場合に、必要となる業務モジュール２２０を処理シーケンスに従って実行する。各業務モジュール２２０は、業務処理を実行するために必要となるデータについて、ＤＢサーバ３００によって管理される業務ＤＢ３１０にアクセスして読み書きを行い、業務処理を実行する。
【００３３】
なお、本実施の形態のサーバシステムの特徴的な構成は、上記ＰＬサーバ１００における、チャネル制御機能１１０、およびチャネル制御部１５１、チャネル管理ＴＢＬ１５５と、サービス制御機能１３０、およびサービス制御部１５３、サービス時間管理ＴＢＬ１５６、セッション管理ＴＢＬ１５７の各部である。これら各部によってチャネル単位でのサービスの提供可否の制御や、時間帯、ユーザの権限、セッション情報などに基づくサービス単位でのサービス提供可否の制御を行うことによって、ＰＬサーバ１００においてサービスの提供可否を判定し、提供不可であるサービスについての処理要求がＢＬサーバ２００に送信されないように制御する。この制御の詳細については後述する。
【００３４】
＜データの構成＞
以下、ＰＬサーバ１００のＰＬサーバ基盤部１５０にて保持され、本実施の形態のサーバシステムがサービス制御を行う際に使用するデータを保持する各テーブルの構成について説明する。
【００３５】
図２は、チャネル管理ＴＢＬ１５５のデータの構成例を示した図である。チャネル管理ＴＢＬ１５５は、ＵＲＬと利用可否のデータ項目を有する。ＵＲＬは、ユーザがクライアント端末６００から本実施の形態のサーバシステムにアクセスしてくる際に使用するＵＲＬであり、アクセスのチャネル毎に異なる値となる。利用可否は、対応するＵＲＬで特定されるチャネルが現在利用可能であるか否かを表すデータである。例えば、システム障害等により、優先度の低いチャネルをチャネル単位で利用不可とするような場合に、利用可否の値を不可とする。
【００３６】
図３は、サービス時間管理ＴＢＬ１５６のデータの構成例を示した図である。サービス時間管理ＴＢＬ１５６は、サービス名、属性、およびサービス時間のデータ項目を有する。サービス名は、本実施の形態のサーバシステムによって提供される各サービスの名称を表すデータである。属性は、当該サービスを利用可能なユーザの権限などによって決定される属性情報を表すデータである。
【００３７】
サービス時間は、当該サービスを提供可能な時間帯を表すデータである。例えば、ＢＬサーバ２００における不定期のメンテナンス等によりサービスの提供時間を変更する場合や、障害等により該当のサービスを一時的に利用不可とするような場合は、サービス時間の値を変更してサービス提供時間外となるようにすることで当該サービスを提供不可とすることができる。
【００３８】
図４は、セッション管理ＴＢＬ１５７のデータの構成例を示した図である。セッション管理ＴＢＬ１５７は、セッションＩＤ、ＵＲＬ、ＩＤ、セッション属性、および更新日時のデータ項目を有する。セッションＩＤは、ユーザによるクライアント端末６００から本実施の形態のサーバシステムへのログインの成功により確立されたセッションを特定するために割り振られたセッションＩＤである。
【００３９】
ＵＲＬは、当該セッションが確立された際に経由してきたチャネルを表すＵＲＬである。ＩＤは、本実施の形態のサーバシステムにログインして当該セッションを確立したユーザのユーザＩＤである。セッション属性は、当該セッションのユーザの属性やチャネルなどによって決定されるセッションの属性（権限）を表すデータである。更新日時は、セッション管理ＴＢＬ１５７における当該セッションのエントリが更新されたタイムスタンプであり、セッションの活性状態を把握するために使用されるデータである。
【００４０】
図２〜図４に示す上記各テーブルのデータ項目は、図示されているものに限らず、他のデータ項目を有していてもよい。また、上記各テーブルの実装方法は、データベースやファイル、メモリテーブルなど種々のものが可能である。
【００４１】
＜ログイン処理＞
以下、ユーザがクライアント端末６００から本実施の形態のサーバシステムにログインする際の、サービス制御の例について図５を用いて説明する。なお、以下の説明では、本実施の形態のサーバシステムでの特徴的な処理を説明するため、例えば認証機能１２０および認証部１５２での処理や、業務制御部２１０内の処理などは省略して記載する。
【００４２】
ログイン前には、例えば、ポータルサイトなどに、サービス時間管理ＴＢＬ１５６から取得したサービス時間の情報に基づいて、サービスの提供可能時間帯毎に区分けされた形でサービス名およびサービス提供時間の一覧が表示されるようにしてもよい。
【００４３】
ＰＬサーバ１００がクライアント端末６００から本実施の形態のサーバシステムへのログイン要求を受信した際、ログイン要求にはＵＲＬ（チャネル）、ユーザのＩＤおよびパスワード（ＰＷＤ）が含まれる。ログイン要求は、ＰＬサーバ１００を経由してログイン処理を行うＢＬサーバ２００に送信され、ログイン処理を行う業務モジュール２２０に渡される。
【００４４】
業務モジュール２２０では、例えば、ＩＤをキーとしてユーザの属性情報を保持する業務ＤＢ３１０（例えば口座情報ＤＢなど）からパスワードと属性（権限）情報などを取得し、パスワードを照合することによってログイン処理を行う（Ｓ５０１）。ログイン処理が成功すると、ＵＲＬ、ＩＤおよび業務ＤＢ３１０から取得した属性情報等の情報を含むログイン応答が、ＢＬサーバ２００を経由してＰＬサーバ１００に送信される。
【００４５】
ログイン応答を受信したＰＬサーバ１００では、サービス制御部１５３によってセッションＩＤを付与し、セッションＩＤ、ＵＲＬ、ＩＤ、セッション属性などのデータをセッション管理ＴＢＬ１５７に書き込む（Ｓ５０２）。
【００４６】
また、サービス制御部１５３によってサービス時間管理ＴＢＬ１５６から、属性、現在時刻などに基づいて、当該ユーザの属性に対して現時点で提供可能なサービスのサービス名、サービス時間のリストを取得する（Ｓ５０３）。このリストに基づいて、例えば、ログインしたユーザが現在利用可能なサービスおよびその利用可能時間帯の一覧をログイン後の画面に表示させたり、ログインしたユーザが現在利用可能なサービスのメニューのみ選択可能なように表示させたりすることができる。なお、このような処理はログイン時に限らず、他のサービス処理の結果をＰＬサーバ１００からクライアント端末６００に応答する際や、メインとなる画面を表示する際などに随時行うことができる。
【００４７】
これにより、ユーザは、実際にサービスの利用要求を行わずとも、当該サービスが利用可能か否かを知ることが可能となる。ただしこの場合でも、例えば、ログイン結果の画面表示時点とユーザが実際にサービスの利用要求を行う時点との時間差により、利用不可であるサービスに対して利用要求が行われる場合などもあり得る。このような場合は、サービスの利用要求が行われた際に、後述する処理によりＰＬサーバ１００にてサービス提供可否の制御が行われる。
【００４８】
ログイン処理の成功により、ＰＬサーバ１００からクライアント端末６００には、画面データに加えてセッションＩＤが送信される。これ以降、サービス制御部１５３およびセッション管理ＴＢＬ１５７によって、当該セッションＩＤを用いて当該ユーザによるサービス利用のためのセッションを特定するセッション管理が行われる。
【００４９】
＜サービス処理＞
以下、ユーザがクライアント端末６００から本実施の形態のサーバシステムにアクセスして所望のサービスを利用する際の、サービス制御の例について図６を用いて説明する。
【００５０】
ＰＬサーバ１００がクライアント端末６００から本実施の形態のサーバシステムへのサービス処理要求を受信した際、サービス処理要求にはＵＲＬ（チャネル）、サービス名、セッションＩＤが含まれる。サービス処理要求を受信したＰＬサーバ１００では、チャネル制御機能１１０によってＵＲＬからチャネルを識別し、チャネル制御部１５１によってチャネル管理ＴＢＬ１５５からＵＲＬをキーとしてその利用可否を取得して、チャネルの利用可否を判定する（Ｓ６０１）。チャネルが利用不可の場合の処理については後述する。
【００５１】
チャネルが利用可能な場合は、サービス制御機能１３０によってサービス名からサービスを識別し、サービス制御部１５３によって、セッション管理ＴＢＬ１５７からセッションＩＤをキーとしてセッション属性などを取得する（Ｓ６０２）。さらに、サービス時間管理ＴＢＬ１５６から、サービス名をキーとして属性、サービス時間を取得し、セッション属性および現在時刻とそれぞれ比較することにより、当該サービスの提供可否を判定する（Ｓ６０３）。サービスが提供不可の場合の処理については後述する。
【００５２】
サービスが提供可能な場合は、サービス処理要求は、当該サービスを処理するＢＬサーバ２００に送信され、当該サービスの処理を行う業務モジュール２２０に渡される。業務モジュール２２０では、必要な場合には業務ＤＢ３１０にアクセスしてデータの読み書きを行い、サービスの処理を実行する（Ｓ６０４）。サービスの処理が完了すると、処理結果を含むサービス処理応答がＰＬサーバ１００に送信される。なお、図６ではＢＬサーバ２００にてサービスの処理を行う場合を例としているが、外部サービス４００にて処理を行う場合であっても同様である。
【００５３】
サービス処理応答を受信したＰＬサーバ１００では、サービス制御部１５３によって、セッション管理ＴＢＬ１５７の該当のレコードの更新日時のタイムスタンプを現在時刻で更新する（Ｓ６０５）。その後、ＰＬサーバ１００は画面制御部１６０によって処理結果の画面データを生成し、クライアント端末６００に送信する。
【００５４】
＜サービス提供不可の場合＞
以下、ユーザがクライアント端末６００から本実施の形態のサーバシステムにアクセスして所望のサービスを利用する際に、該当のサービスが提供不可である場合の制御の例について図７を用いて説明する
前述のサービス処理の場合と同様に、ＰＬサーバ１００がクライアント端末６００から本実施の形態のサーバシステムへのサービス処理要求を受信した際、チャネル制御機能１１０およびチャネル制御部１５１によりチャネルの利用可否を判定し（Ｓ６０１）、チャネルが利用可能な場合は、サービス制御機能１３０およびサービス制御部１５３により当該サービスの提供可否を判定する（Ｓ６０２、Ｓ６０３）。
【００５５】
ここで、当該サービスが提供不可であると判定した場合は、ＰＬサーバ１００は画面制御部１６０によって、サービスが提供不可である旨を表示する画面データを生成し、クライアント端末６００に送信する。これにより、サービス処理要求がＢＬサーバ２００もしくは外部サービス４００には送信されず、ＢＬサーバ２００や外部サービス４００に余計なアクセスを発生させずに、サービスの提供可否の制御を行うことが可能となる。
【００５６】
なお、例えば、ＢＬサーバ２００における不定期のメンテナンス等や、障害、トラフィック溢れ時など、一時的に該当のサービスを提供不可にするような場合は、サービス時間管理ＴＢＬ１５６の該当サービスのエントリにおけるサービス時間を変更してサービス提供時間外となるようにすることで実現することができる。サービス時間の変更は、例えば、ＢＬサーバ２００等における障害の検知をトリガとして自動で行ったり、操作員が手動で行ったりすることが可能である。
【００５７】
＜チャネル利用不可の場合＞
以下、ユーザがクライアント端末６００から本実施の形態のサーバシステムにアクセスして所望のサービスを利用する際に、ユーザがアクセスに利用したチャネルが利用不可である場合の制御の例について図８を用いて説明する。
【００５８】
前述のサービス処理の場合と同様に、ＰＬサーバ１００がクライアント端末６００から本実施の形態のサーバシステムへのサービス処理要求を受信した際、チャネル制御機能１１０およびチャネル制御部１５１によりチャネルの利用可否を判定する（Ｓ６０１）。
【００５９】
ここで、ユーザがアクセスに利用したチャネルが利用不可であると判定した場合は、ＰＬサーバ１００は画面制御部１６０によって、サービスが提供不可である旨を表示する画面データを生成し、クライアント端末６００に送信する。これにより、サービス処理要求がＢＬサーバ２００もしくは外部サービス４００には送信されず、ＢＬサーバ２００や外部サービス４００に余計なアクセスを発生させずに、サービスの提供可否の制御を行うことが可能となる。
【００６０】
なお、例えば、システム障害等により、優先度の低いチャネルをチャネル単位で一時的に利用不可とするような場合は、チャネル管理ＴＢＬ１５５の該当チャネルの利用可否の値を不可に変更することで実現することができる。利用可否の値の変更は、例えば、システム障害等の検知をトリガとして自動で行ったり、操作員が手動で行ったりすることが可能である。
【００６１】
以上に説明したように、本発明の実施の形態のサーバシステムによれば、提供可能な時間帯やユーザの権限等が異なる複数のサービスを提供する場合に、ＷｅｂサーバであるＰＬサーバ１００において、ユーザの属性（権限）や時間帯、アクセスのチャネルに応じて各サービスの提供可否を判断して提供可能なサービスのメニューをユーザに提示することができるため、サービスを利用する際のユーザの利便性を高めることが可能となる。
【００６２】
また、提供不可なサービスに対してユーザからの利用要求があった場合でも、ＢＬサーバ２００や外部サービス４００に余計なアクセスが発生しないように制御することができるため、これらにかかる負荷を低減することが可能となる。また、このようなチャネルやユーザの属性等に応じたサービスへのアクセスの制御をＰＬサーバ１００において行うことから、例えば、ＢＬサーバ２００に、サービスへのアクセスを制御する機能をチャネル毎やユーザの属性毎に個別に実装するというような必要がなく、ＢＬサーバ２００の実装を共通化することも可能となる。
【００６３】
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
【産業上の利用可能性】
【００６４】
本発明は、Ｗｅｂによってサービスを提供するサーバシステムに利用可能である。
【図面の簡単な説明】
【００６５】
【図１】本発明の一実施の形態であるサーバシステムの構成例の概要を示した図である。
【図２】本発明の一実施の形態におけるチャネル管理ＴＢＬのデータの構成例を示した図である。
【図３】本発明の一実施の形態におけるサービス時間管理ＴＢＬのデータの構成例を示した図である。
【図４】本発明の一実施の形態におけるセッション管理ＴＢＬのデータの構成例を示した図である。
【図５】本発明の一実施の形態におけるサービス制御の例について説明する図である。
【図６】本発明の一実施の形態におけるサービス制御の例について説明する図である。
【図７】本発明の一実施の形態におけるサービスが提供不可である場合の制御の例について説明する図である。
【図８】本発明の一実施の形態におけるチャネルが利用不可である場合の制御の例について説明する図である。
【符号の説明】
【００６６】
１００…ＰＬサーバ、１１０…チャネル制御機能、１２０…認証機能、１３０…サービス制御機能、１４０…外部連動機能、１５０…ＰＬサーバ基盤部、１５１…チャネル制御部、１５２…認証部、１５３…サービス制御部、１５４…業務基盤部、１５５…チャネル管理ＴＢＬ、１５６…サービス時間管理ＴＢＬ、１５７…セッション管理ＴＢＬ、１６０…画面制御部、２００…ＢＬサーバ、２１０…業務制御部、２１１…時間制御部、２１２…業務サービス制御部、２２０…業務モジュール、３００…ＤＢサーバ、３１０…業務ＤＢ、４００…外部サービス、５００…ネットワーク、６００…クライアント端末。
【図１】
2010039763.tif 000003
【図２】
2010039763.tif 000004
【図３】
2010039763.tif 000005
【図４】
2010039763.tif 000006
【図５】
2010039763.tif 000007
【図６】
2010039763.tif 000008
【図７】
2010039763.tif 000009
【図８】
2010039763.tif 000010