JP2009294736A - イベント制御プログラム、イベント制御方法およびイベント制御装置 - Google Patents

イベント制御プログラム、イベント制御方法およびイベント制御装置 Download PDF

Info

Publication number
JP2009294736A
JP2009294736A JP2008145360A JP2008145360A JP2009294736A JP 2009294736 A JP2009294736 A JP 2009294736A JP 2008145360 A JP2008145360 A JP 2008145360A JP 2008145360 A JP2008145360 A JP 2008145360A JP 2009294736 A JP2009294736 A JP 2009294736A
Authority
JP
Japan
Prior art keywords
server
event
request
notify
client
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2008145360A
Other languages
English (en)
Other versions
JP5029495B2 (ja
Inventor
Hitoshi Ueno
仁 上野
Koichiro Amamiya
宏一郎 雨宮
Masaaki Takase
正明 高瀬
Kenichi Abiru
健一 阿比留
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2008145360A priority Critical patent/JP5029495B2/ja
Priority to US12/415,527 priority patent/US20090300182A1/en
Priority to GB0906600A priority patent/GB2460509B8/en
Publication of JP2009294736A publication Critical patent/JP2009294736A/ja
Application granted granted Critical
Publication of JP5029495B2 publication Critical patent/JP5029495B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/54Presence management, e.g. monitoring or registration for receipt of user log-on information, or the connection status of the users

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)
  • Information Transfer Between Computers (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

【課題】サーバの負荷を軽減させること。
【解決手段】イベント制御装置1を、受信手段1a、要求手段1b、転送手段1cとして機能させる。
受信手段1aは、クライアント4a、4bを指定する指定情報を含むイベントの通知要求を受信する。要求手段1bは、受信した指定情報に基づいて、サーバ3a〜3cの中から指定情報によって特定されるクライアントに対してサービスを提供している振り分け先のサーバの通知を要求する。転送手段1cは、要求手段1bによる要求に応じて通知された振り分け先のサーバに、イベントの通知要求を転送する。
【選択図】図1

Description

本発明はイベント制御プログラム、イベント制御方法およびイベント制御装置に関し、特に、複数のプロトコルを利用するサービスに用いるイベント制御プログラム、イベント制御方法およびイベント制御装置に関する。
近年、Web上のサービスにおいて、HTTP(HyperText Transfer Protocol)やSIP(Session Initiation Protocol)等複数のプロトコル(Protocol)を用いたサービスを組み合わせることで、特徴あるアプリケーションを容易に提供したい、という要求が高まっている。
一例として、プレゼンスサーバ(Presence Server)からのSIP Notify情報をもとに、WebブラウザからのHTTPリクエストの応答コンテンツを変更する、といったサービスが知られている。
このようなサービスでは、サービス利用者の増加に伴うサーバ(Server)の処理速度の低下やサービスの停止を防ぐため、一般的に、複数のサーバを利用した負荷分散が行われる。
図23は、負荷分散を行うシステムの構成を示す図である。
図23に示すシステムは、サーバロードバランサ(SLB:Server Load Balancer)91と、プレゼンスサーバ92と、クライアント93a、93bと、Webサーバ94a、94bとを有している。
サーバロードバランサ91は、クライアント93a、93bに対するWebアプリケーションの負荷分散のため、クライアント93a、93bからのHTTPリクエストを順番にWebサーバ94a、94bに振り分ける機能を有している。
一旦、クライアントとWebサーバ間でセッションが確立されると、サーバロードバランサ91は、一定時間は、そのクライアントからのHTTPリクエストを、セッションが確立したWebサーバに振り分ける。
プレゼンスサーバ92は、プレゼンス情報を必要とするWebサーバ94a、94bからの、通知を要求する状態変化(イベント)の通知要求を、予めSubscribe(登録)する。
その後、プレゼンスサーバ92は、通知を要求する状態変化を検知すると、(Subscribeしていた)Webサーバ94a、94bにそれぞれNotify(状態変化の通知)を転送する。
これにより、例えば、クライアント93aとWebサーバ94a間でセッションが確立されると、サーバロードバランサ91によりクライアント93aからのHTTPリクエストは、Webサーバ94aに振り分けられる。
一方、プレゼンスサーバ92によるNotifyは、Subscribeしている全てのWebサーバ94a、94bに通知される。
このため、クライアント93によりHTTPアクセスされてないWebサーバ94bにもNotifyが通知されることになる。
通常、Notifyを受信したWebサーバは、そのNotifyに格納されたタグの情報に基づく処理(例えば、データベース検索や画面データの準備等)を実施するため、HTTPアクセス対象ではないWebサーバ(図23ではWebサーバ94b)にとっては無駄な処理を行っていることになる。
ここで、Subscribe時において対象物の状態が変化していない場合は、空のNotifyを送信することで、ネットワーク負荷の軽減を図る技術が知られている。
しかしながら、このような場合においてもWebサーバに対してNotifyが通知されてしまうため、サーバの負荷を軽減させることはできないという問題がある。
特開2007−26006号公報
本発明はこのような点に鑑みてなされたものであり、サーバの処理負荷を軽減させることができるイベント制御プログラム、イベント制御方法およびイベント制御装置を提供することを目的とする。
上記目的を達成するために、イベントの中継制御をイベント制御装置に実行させるイベント制御プログラムが提供される。このプログラムは、イベント制御装置を、受信手段、要求手段、転送手段として機能させる。
受信手段は、クライアントを指定する指定情報を含むイベントの通知要求を受信する。
要求手段は、受信した指定情報に基づいて、複数のサーバのうち、指定情報によって特定されるクライアントに対してサービスを提供しているサーバを振り分け先のサーバとして通知するよう要求する。
転送手段は、要求手段による要求に応じて通知された振り分け先のサーバに、イベントの通知要求を転送する。
このようなイベント制御プログラムを実行するコンピュータによれば、受信手段により、指定情報を含むイベントの通知要求が受信される。要求手段により、受信手段によって受信された識別情報に基づいて、振り分け先のサーバの通知が要求される。
転送手段により、要求手段による要求に応じて通知された振り分け先のサーバに、イベントの通知要求が転送される。
開示のイベント制御プログラムによれば、通知された振り分け先のサーバ以外には通知要求は転送されなくなるため、他のサーバの処理負荷を軽減させることができる。
以下、実施の形態を、図面を参照して詳細に説明する。
まず、実施の形態のコンピュータシステムの概要について説明し、その後、実施の形態をより具体的に説明する。
図1は、実施の形態のコンピュータシステムの概要を示す図である。
イベント制御装置1は、ネットワークを介して負荷分散装置2およびサーバ3a〜3cに接続されている。
負荷分散装置2は、サーバ3a〜3cと所定のプロトコル(例えばHTTP等)でデータ通信を行うクライアント4a、4bからのデータ処理の要求をサーバ3a〜3cに動的に振り分ける。その際、振り分け先として決定したサーバとクライアントとの関係が分かるように保管しておき、セッションが確立している時間は、クライアントからのデータ処理の要求は、上記の関係に基づいてサーバに振り分ける。
図1では、一例として、負荷分散装置2は、クライアント4aからのデータ処理の要求をサーバ3cに振り分けることを決定し、この関係を保管している。また、クライアント4bからのデータ処理の要求をサーバ3aに振り分けることを決定し、この関係を保管している。
サーバ3a〜3cは、それぞれクライアント4a、4bの要求に応じて所定のサービスを提供する。
イベント制御装置1は、受信手段1aと、要求手段1bと、転送手段1cとを有している。
受信手段1aは、クライアントを指定する指定情報を含むイベントの通知要求を受信する。この通知要求は、サーバ−クライアント間のプロトコルとは異なるプロトコル(例えば、SIP等)で送信される。
なお、指定情報としては、例えば、クライアントを直接指定するクライアントのIPアドレスや、クライアントを間接的に指定する、クライアントがログインしているユーザのIDや、クライアントに対応して設けられているタグのID等が挙げられる。
また、イベントの通知要求とは、イベントの通知要求を予めSubscribeしているサーバに対してイベントを通知する要求である。
要求手段1bは、受信手段1aが受信したイベントの通知要求に含まれる指定情報に基づいて、サーバ3a〜3cのうち、指定情報によって特定されるクライアントに対してサービスを提供しているサーバを、振り分け先のサーバとして通知するよう負荷分散装置2に要求する。
負荷分散装置2は、予め保管しておいた情報に基づいて振り分け先のサーバを決定し、イベント制御装置1に返す。
転送手段1cは、要求手段1bによる要求に応じて通知された振り分け先のサーバに対し、イベントの通知要求をサーバ−クライアント間のプロトコルとは異なるプロトコルで転送する。
例えば、負荷分散装置2からサーバ3cが振り分け先として通知された場合、転送手段1cは、サーバ3cにのみ通知要求を転送し、サーバ3a、3bには通知要求は転送しない。
このイベントの通知要求により、(クライアント4aと通信を行っている)サーバ3cは、イベントの処理を実行し、クライアント4aに応答する。
このように、イベント制御装置1が、振り分け先として決定されたサーバ3a〜3cのいずれかに通知要求を転送し、その他のサーバには通知要求を転送しないようにすることで、その他のサーバは無駄な処理を行わなくてよいため、その他のサーバの処理負荷を軽減させることができる。
以下、実施の形態をより具体的に説明する。
<第1の実施の形態>
図2は、ネットワークシステムの構成を示す図である。
ネットワークシステム100は、クライアント10a、10bと、タグリーダー20a、20bと、HTTPロードバランサ(サーバロードバランサ)30と、プレゼンスサーバ40と、Notify制御装置50と、サーバ60a、60bとを有している。
クライアント10a、10bとHTTPロードバランサ30間、タグリーダー20a、20bとプレゼンスサーバ40間、プレゼンスサーバ40とNotify制御装置50間、およびNotify制御装置50とHTTPロードバランサ30とサーバ60a、60b間はそれぞれネットワークで接続されている。これらのネットワークは、個別のネットワークであってもよいし、または、部分的にもしくは全体が重複していてもよい。
ここで、クライアント10a、10b、HTTPロードバランサ30およびサーバ60a、60b間は、HTTPによる通信制御が行われる。また、HTTPロードバランサ30とNotify制御装置50間、並びにプレゼンスサーバ40、Notify制御装置50およびサーバ60a、60b間は、SIPによる通信制御が行われる。なお、タグリーダー20a、20bとプレゼンスサーバ40間のプロトコルは特に限定されず、任意のプロトコルによる通信制御が行われる。
クライアント10a、10bは、それぞれサーバ60a、60bが提供するサービスをユーザが利用(享受)する装置である。
これらのクライアント10a、10bには、マウスやキーボード等(図示せず)が接続されており、それぞれユーザのマウスやキーボード等の操作(以下、単に「ユーザの操作」と言う)により送られてくる信号に応じてWebブラウザ11a、11bをクライアント10a、10bに接続されたモニタ(図示せず)に起動する。
そして、クライアント10a、10bは、それぞれユーザの操作により、Webブラウザ11a、11b上に所定の画面を表示させる要求を受けつけると、HTTPリクエストをHTTPロードバランサ30に出力する。
タグリーダー20a、20bは、それぞれクライアント10a、10bに対応して設けられている。図2では、タグリーダー20aは、クライアント10aの近傍に設けられており、タグリーダー20bは、クライアント10bの近傍に設けられている。
タグリーダー20a、20bは、それぞれ所定のエリア内に存在するタグ(例えば、携帯端末装置やカードに内蔵されたタグ)を読み込む機能を有しており、読み込んだ内容に所定の情報を付加したタグ情報を、プレゼンスサーバ40に送信する。
なお、読み込んだ内容には、例えば、クライアント10a、10bにログインしたユーザを識別するユーザID等が含まれる。また、付加する所定の情報には、例えばタグリーダー20a、20bの識別情報等が含まれる。
このようなネットワークシステム100の使われ方の一例を簡単に説明する。
クライアント10aを操作するユーザは、Webブラウザ11aの閲覧中にWebアプリケーション61aによる特別なサービスを享受したい場合、タグリーダー20aにタグを読み込ませる。これにより、プレゼンスサーバ40およびNotify制御装置50により後述する処理が行われ、サーバ60aにNotifyが転送される。サーバ60aのWebアプリケーション61aは、Notifyに対する処理を実行し、Webブラウザ11aにその応答コンテンツを返す。これによって、ユーザは、特別なサービスを享受することができる。
HTTPロードバランサ30は、クライアント10a、10bとサーバ60a、60b間を中継している。
HTTPロードバランサ30は、クライアント10aまたはクライアント10bからのHTTPリクエストを受信すると、そのHTTPリクエストを処理させる(振り分け先の)サーバ60aまたはサーバ60bを決定し、決定したサーバ60aまたはサーバ60bにそのHTTPリクエストを動的に振り分ける。
HTTPロードバランサ30は、HTTPリクエストを送信したクライアントと、そのクライアントからのHTTPリクエストを振り分けるサーバとを関連づけて振り分け先管理テーブル(後述)に格納する。
以後、HTTPリクエストを受信すると、振り分け先管理テーブルを参照し、そのHTTPリクエストを要求したクライアントに関連づけられたサーバに対し、そのHTTPリクエストを振り分ける。
なお、図2では、クライアント10aの要求したHTTPリクエストをサーバ60aに振り分けた場合を示している。
また、HTTPロードバランサ30は、振り分け先のサーバ60aまたはサーバ60bからHTTPリクエストに対する応答を受信すると、HTTPリクエストを送信したクライアント10aまたはクライアント10bに対し、その応答を返す。なお、図2では、サーバ60aからリクエストに対する応答があり、HTTPリクエストを送信したクライアント10aに対し、その応答を返す場合を示している。
また、HTTPロードバランサ30は、Notify制御装置50から、Notifyの振り分け先のサーバに関する問い合わせを受けると、後述する処理によって振り分け先のサーバを特定し、応答する。
プレゼンスサーバ40には、受信したタグ情報の最初の転送先としてNotify制御装置50のIPアドレスが予め設定されている。これにより、プレゼンスサーバ40が受信した全てのタグ情報は、タグ情報の宛先に記載されたサーバに直接送信されることなく、Notify制御装置50に送信される。
プレゼンスサーバ40は、タグリーダー20aまたはタグリーダー20bからのタグ情報を受信すると、Subscribe管理テーブル(後述)を参照してSubscribe元(イベントの通知要請元)となるサーバを特定し、このサーバに対するNotifyをNotify制御装置50に送信する。このNotifyには、タグ情報が含まれる。
なお、Subscribe元となるサーバが複数存在する場合、これらのサーバのそれぞれに対応するNotifyを送信する。
Notify制御装置50は、プレゼンスサーバ40からのNotifyを受信すると、HTTPロードバランサ30に振り分け先を問い合わせる。具体的には、Notify制御装置50は、HTTPロードバランサ30に振り分け先を問い合わせる際、予め用意されたグループ管理テーブル(後述)を参照することで応答コンテンツを必要とするクライアントを特定し、特定したクライアントのIPアドレスに基づいて振り分け先を問い合わせる。
振り分け先を問い合わせることで、受信したNotifyに対するNotifyの転送先のサーバ60aまたはサーバ60bを決定する。
図2では、クライアント10aが特定された場合を図示している。前述したように、HTTPロードバランサ30は、クライアント10aが送信するHTTPリクエストを、サーバ60aに振り分けているため、HTTPロードバランサ30からは、サーバ60aが振り分け先として通知され、Notify制御装置50は、サーバ60aを振り分け先として決定する。
その後、Notify制御装置50は、振り分け先として決定したサーバにNotifyを転送してよいか否かの判定を行い、転送してよいと判定した場合、そのサーバにNotifyを転送する。
サーバ60a、60bは、それぞれWebブラウザ11a、11bの要求に応じたWebアプリケーション61a、61bを実行する機能を有しており、HTTPロードバランサ30からHTTPリクエストを受信すると、そのリクエストに応じたWebアプリケーションを実行し、処理結果のファイル(HTMLファイル等)をHTTPロードバランサ30に送信する。
また、サーバ60a、60bは、Notify制御装置50からのNotifyを受信すると、そのNotifyに含まれる情報に応じた処理を行い、その応答コンテンツを、HTTPリクエストに対する応答に含ませて、特定したクライアントに送信する。
次に、HTTPロードバランサ30が備える振り分け先管理テーブルについて説明する。
図3は、振り分け先管理テーブルを示す図である。
振り分け先管理テーブル30aには、クライアントおよび振り分け先の欄が設けられており、各欄の横方向に並べられた情報同士が互いに関連づけられている。
クライアントの欄には、HTTPロードバランサ30が受信したHTTPリクエストの送信元のクライアントのIPアドレス(識別情報)が格納される。
図3では、クライアント10aのIPアドレス「192.16.0.5」が格納されている。
振り分け先アドレスの欄には、クライアントの欄に格納されたIPアドレスを備えるクライアントとセッションが確立されているサーバを識別するIPアドレスが記載される。
図3では、サーバ60aのIPアドレス「10.16.0.2」が格納されている。
次に、プレゼンスサーバ40が備えるSubscribe管理テーブルについて説明する。
図4は、Subscribe管理テーブルを示す図である。
Subscribe管理テーブル40aには、Subscribe元および購読対象の欄が設けられており、各欄の横方向に並べられた情報同士が互いに関連づけられている。
Subscribe元の欄には、Subscribe送信元のサーバのIPアドレスが格納される。
図4では、サーバ60aのIPアドレス「10.16.0.2」およびサーバ60bのIPアドレス「10.16.0.5」が格納されている。
購読対象の欄には、Subscribe元の欄に格納されたサーバがSubscribeを受けつける(Subscribe対象となる)タグリーダーのURI(Uniform Resource Identifier)が格納される。
図4では、タグリーダー20aのURI「reader05@10.25.10.3」が格納されている。
このSubscribe管理テーブル40aを参照することにより、プレゼンスサーバ40は、どのサーバが、どのタグリーダーの変化を通知して欲しいことを予めSubscribeしているかを認識することができる。
次に、Notify制御装置50が備えるグループ管理テーブルについて説明する。
図5は、グループ管理テーブルを示す図である。
グループ管理テーブル50aには、クライアントおよびFrom URIの欄が設けられており、各欄の横方向に並べられた情報同士が互いに関連づけられている。
クライアントの欄には、クライアントのIPアドレスが格納されている。
From URIの欄には、タグリーダーのURIが格納されている。
このグループ管理テーブル50aを参照することにより、Notify制御装置50は、受け取ったNotifyに含まれるタグ情報が、どのクライアントに対応しているのかを認識することができる。
次に、ネットワークシステム100の処理を簡単に説明する。
図6は、ネットワークシステムの処理を示すシーケンス図である。
サーバ60a、60bは、それぞれSubscribe元および購読対象を含むSIP Subscribeをプレゼンスサーバ40に送信する。プレゼンスサーバ40は、受信したSIP Subscribeに含まれるSubscribe元および購読対象をSubscribe管理テーブル40aに格納する。ここまでが前処理として行われている。
その後、クライアント10aのWebブラウザ11aが起動され、HTTPロードバランサ30に対してHTTPリクエストが送信される(ステップS1)。
HTTPロードバランサ30は、HTTPリクエストに応じて振り分け先のサーバを決定し、送信元のクライアントのIPアドレスと、決定した振り分け先のサーバのIPアドレスとを関連づけて振り分け先管理テーブル30aに格納する(ステップS2)。
その後、HTTPロードバランサ30は、そのHTTPリクエストを振り分け先のサーバ(図6では、サーバ60a)に振り分ける(ステップS3)。
HTTPリクエストが振り分けられたサーバ60aは、そのHTTPリクエストに応じたHTMLファイルをクライアント10aに返す(ステップS4)。
その後、タグリーダー20aにタグがかざされると、タグリーダー20aは、プレゼンスサーバ40にタグ情報を送信する(ステップS5)。
プレゼンスサーバ40は、Subscribe管理テーブル40aを参照して得られるSubscribe元に対するNotify通知をNotify制御装置50に送信する(ステップS6)。
Notify制御装置50は、Notify通知を受信すると、HTTPロードバランサ30に対し、振り分け先を問い合わせる(振り分け先の通知を要求する)(ステップS7)。
HTTPロードバランサ30は、Notify制御装置50の要求に応じて振り分け先管理テーブル30aを参照し、振り分け先を応答する(ステップS8)。
Notify制御装置50は、その応答に含まれる振り分け先として決定したサーバにNotifyを転送するか否かの判定を行い、転送する場合、そのサーバ(図6では、サーバ60a)にNotifyを転送する(ステップS9)。なお、転送するか否かの判定基準については後に詳述する。
これにより、サーバ60aのWebアプリケーション61は、アプリケーションを実行し、得られた応答コンテンツをクライアント10aに送信する(ステップS10)。これにより、クライアント10aが備えるモニタに応答コンテンツが表示される。
以上でネットワークシステム100の処理の説明を終了する。
以下、Notify制御装置50の構成について詳しく説明する。
図7は、Notify制御装置のハードウェア構成例を示す図である。
Notify制御装置50は、CPU(Central Processing Unit)101によって装置全体が制御されている。CPU101には、バス106を介してRAM(Random Access Memory)102、ハードディスクドライブ(HDD:Hard Disk Drive)103、および通信インタフェース104、105が接続されている。
RAM102には、CPU101に実行させるOS(Operating System)のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、RAM102には、CPU101による処理に必要な各種データが格納される。HDD103には、OSやアプリケーションプログラムが格納される。また、HDD103内には、プログラムファイルが格納される。
通信インタフェース104は、HTTPロードバランサ30との間でデータの送受信を行う。通信インタフェース105は、プレゼンスサーバ40およびサーバ60a、60bとの間でデータの送受信を行う。
以上のようなハードウェア構成によって、本実施の形態の処理機能を実現することができる。このようなハードウェア構成のシステムにおいて前述した処理を行うために、Notify制御装置50内には、以下のような機能が設けられる。
図8は、Notify制御装置の機能を示すブロック図である。
Notify制御装置50は、Notify受信部51と、管理テーブル格納部52と、検索部53と、アドレス要求部54と、転送判定部55とを有している。
Notify受信部51は、プレゼンスサーバ40からのNotifyを受信する。
管理テーブル格納部52には、グループ管理テーブル50aが格納されている。なお、管理テーブル格納部52は、例えば、図7のHDD103またはRAM102の記憶領域として実現される。
検索部53は、グループ管理テーブル50aを参照し、Notify受信部51が受信したNotifyに含まれるFrom URIに対応するクライアントのIPアドレスを検索し、取得する。
アドレス要求部54は、検索部53が取得したIPアドレスに基づいて、HTTPロードバランサ30に対し、振り分け先を問い合わせる。
そして、問い合わせに対するHTTPロードバランサ30からの応答を転送判定部55に送る。
転送判定部55は、振り分け先として決定したサーバにNotifyを転送してよいか否かを判定し、転送してよいと判定した場合、その振り分け先に対してNotifyを転送する。転送してはいけないと判定した場合、Notifyを廃棄する。
次に、Notify制御装置50の処理を説明する。
図9は、Notify制御装置の処理を示すフローチャートである。
まず、Notify受信部51が、Notifyを受信する(ステップS11)。
次に、検索部53が、グループ管理テーブル50aを参照し、Notify受信部51が受信したNotifyに含まれるFrom URIに対応するクライアントのIPアドレスを検索し、取得する(ステップS12)。
次に、アドレス要求部54が、検索部53が取得したクライアントのIPアドレスに基づいて、HTTPロードバランサ30に対し、振り分け先のサーバ(図9では単に「振り分け先」と表記している。以下同じ)を問い合わせる(ステップS13)。
次に、転送判定部55が、HTTPロードバランサ30から振り分け先のサーバが得られたか否かを判定する(ステップS14)。
振り分け先のサーバが得られない場合、すなわち、振り分け先管理テーブル30aに、クライアントに対応する振り分け先のサーバが存在しない場合(ステップS14のNo)、転送判定部55は、Notifyに含まれる宛先を、このクライアントに対するNotifyの振り分け先としてHTTPロードバランサ30に登録を要求する(ステップS15)。その後、宛先のサーバを振り分け先のサーバとして、宛先のサーバに対しNotifyを転送し(ステップS18)、処理を終了する。
一方、振り分け先のサーバが得られた場合(ステップS14のYes)、転送判定部55は、振り分け先のサーバのIPアドレスとNotifyに含まれる宛先のIPアドレスとが一致するか否かを判定する(ステップS16)。
一致しない場合(ステップS16のNo)、受信したNotifyを廃棄し(ステップS17)、処理を終了する。
一方、一致する場合(ステップS16のYes)、一致した振り分け先のサーバに対しNotifyを転送し(ステップS18)、処理を終了する。
以上でNotify制御装置50の処理の説明を終了する。
次に、ネットワークシステム100の処理の具体例を説明する。
以下、具体例では、HTTPロードバランサ30の処理に際しては、図3に示す振り分け先管理テーブル30aの値を使用する。プレゼンスサーバ40の処理に際しては、図4に示すSubscribe管理テーブル40aに格納された値を使用する。Notify制御装置50の処理に際しては、図5に示すグループ管理テーブル50aに格納された値を使用する。
図10は、処理の具体例を示すシーケンス図である。
ステップS21〜ステップS25:それぞれ図6のステップS1〜ステップS5と同様の処理を行う。
タグリーダー20aからのタグ情報を受信したプレゼンスサーバ40は、Subscribe管理テーブル40aを参照する。そして、タグ情報に含まれるタグリーダー20aのID「reader05@.10.25.10.3」に対応するIPアドレス「10.16.0.2」のサーバ、すなわちサーバ60aをSubscribe元として特定する。また、タグリーダー20aのID「reader05@.10.25.10.3」に対応するIPアドレス「10.16.0.5」のサーバ、すなわちサーバ60bをSubscribe元として特定する。
そして、From URIを「reader05@10.25.10.3」とし、To URIを「server01@10.16.0.2」としたNotifyを、サーバ60aに対するNotifyとする。
また、From URIを「reader05@10.25.10.3」とし、To URIを「server01@10.16.0.5」としたNotifyを、サーバ60bに対するNotifyとする。
そして、これらNotifyをそれぞれNotify制御装置50に送信する(ステップS26、S27)。
以下、説明を分かりやすくするために、まず、ステップS26のNotifyがNotify制御装置50に通知された場合の処理を説明し、次に、ステップS27のNotifyがNotify制御装置50に通知された場合を説明する。なお、このような処理の順序は特に限定されるものではない。
Notify受信部51が、ステップS26のNotifyを受信すると、検索部53が、グループ管理テーブル50aを参照する。そして、Notifyに含まれるFrom URI「reader05@10.25.10.3」に対応するIPアドレス「192.16.0.5」のクライアント、すなわちクライアント10aを特定する。
そして、アドレス要求部54が、クライアント10aに対する振り分け先をHTTPロードバランサ30に問い合わせる(ステップS28)。
要求を受信したHTTPロードバランサ30は、振り分け先管理テーブル30aを参照する。
ここで、振り分け先管理テーブル30aには、IPアドレス「192.16.0.5」のクライアント10aに対する振り分け先のIPアドレス「10.16.0.2」が存在するため、振り分け先のIPアドレス「10.16.0.2」をNotify制御装置50に応答する(ステップS29)。
振り分け先のサーバのIPアドレスが得られたため、転送判定部55が、振り分け先のサーバのIPアドレスとNotifyの宛先の一致を判定する。
ここで、振り分け先のサーバのIPアドレスとNotifyのTo URIは、共に「10.16.0.2」で一致するため、転送判定部55は、IPアドレス「10.16.0.2」のサーバ、すなわちサーバ60aにNotifyを出力する(ステップS30)。
これにより、サーバ60aは、Notifyに含まれる情報(SIPリクエストのボディ)に対応するアプリケーションを実行し、その結果をクライアント10aに送信する(ステップS31)。
一方、Notify受信部51が、ステップS27のNotifyを受信すると、検索部53およびアドレス要求部54は、ステップS28およびステップS29と同様の処理を行う(ステップS32、S33)。
そして、転送判定部55が、振り分け先のサーバのIPアドレスとNotifyの宛先の一致を判定する。
ここで、振り分け先のサーバのIPアドレス「10.16.0.2」とNotifyのTo URI「10.16.0.5」は、一致しないため、転送判定部55は、Notifyを廃棄する。
以上述べたように、ネットワークシステム100によれば、Notify制御装置50が、振り分け先と宛先が一致した宛先にのみ、Notifyを転送し、一致しないNotifyを廃棄するようにしたので、Subscribe管理テーブル40aに格納されているが、今回の処理対象ではないサーバにはNotifyは転送されない。これにより、サーバの無駄な処理を回避させることができる。
また、HTTPロードバランサ30と連携してNotifyの無駄な転送を減らすようにしたので、複数のプロトコルを用いたシステムにも適用することができる。
また、振り分け先のサーバが得られなかった場合、HTTPロードバランサ30に登録を要求するようにして、今回のNotifyは、宛先のサーバに転送するようにしたので、例えば、クライアント10aとサーバ60a間にセッションが確立していない場合において、ユーザがタグリーダー20aにタグ情報を読み込ませてしまった場合においても、その情報が振り分け先のサーバのWebアプリケーション61aに確実に転送される。そして、クライアント10aとサーバ60a間のセッション確立後に、応答コンテンツがWebブラウザ11aに送信される。
これにより、例えばWebブラウザ11a、11bと、タグリーダー20a、20bのどちらが先に動作した場合においても振り分け先のサーバの無駄な処理を回避させることができる。
なお、本実施の形態では、要求元のクライアントがHTTPロードバランサ30に登録されていなかった場合にNotify制御装置50のアドレス要求部54がNotifyの振り分け先の登録をHTTPロードバランサ30に要求するようにしたが、これに限らず、HTTPロードバランサ30が振り分け先を決定し、アドレス要求部54に通知するようにしてもよい。以下、詳しく説明する。
図11は、HTTPロードバランサの処理を示すフローチャートである。
まず、アドレス要求部54から振り分け先の問い合わせを受信する(ステップS41)。
次に、振り分け先管理テーブル30aを参照し、問い合わせに含まれるクライアントのIPアドレスに基づいて、振り分け先のサーバを検索する(ステップS42)。
次に、振り分け先のサーバが得られたか否かを判断する(ステップS43)。
振り分け先のサーバが得られた場合(ステップS43のYes)、得られた振り分け先のサーバのIPアドレスをアドレス要求部54に送信する(ステップS44)。
一方、振り分け先のサーバが得られなかった場合(ステップS43のNo)、任意のサーバのIPアドレスを振り分け先として1つ選択する(ステップS45)。選択の方法は特に限定されないが、例えば、振り分け可能なサーバのIPアドレスが格納されているリストを予め用意しておいて、そのリストの上から順番に選択する方法や、リストからランダムに選択する方法等が挙げられる。
次に、選択したサーバのIPアドレスを、問い合わせに含まれるクライアントのIPアドレスに関連づけて振り分け先管理テーブル30aに反映(格納)する(ステップS46)。
その後、ステップS44に移行し、選択した振り分け先のサーバのIPアドレスをアドレス要求部54に送信する。
以上で処理の説明を終了する。
このような処理を行うことによって、振り分け先管理テーブル30aの管理(設定)がHTTPロードバランサ30の中で閉じて行われるため、管理の容易化を図ることができる。
また、本実施の形態では、Notify制御装置50が有する各機能を独立した装置(Notify制御装置50)に持たせて説明したが、このような構成に限定されず、例えば、ネットワークシステム100の他の装置にNotify制御装置50が有する機能を備えさせるようにしてもよい。
図12および図13は、Notify制御装置が有する機能を他の装置に実装した例を示す図である。
図12に示すネットワークシステム100aでは、プレゼンスサーバ401は、プレゼンスサーバ40と同じ機能を備えるNotify配信部41と、Notify制御装置50と同じ機能を備えるNotify制御部42とを有している。
図13に示すネットワークシステム100bでは、HTTPロードバランサ301は、HTTPロードバランサ30と同じ機能を備えるHTTP振り分け部31と、Notify制御部42とを有している。
図12および図13に示すネットワークシステム100a、100bによっても、ネットワークシステム100と同様の効果が得られる。また、このようなシステム構成によれば、ネットワークシステムの小型化を図ることができる。
また、本実施の形態では、HTTPとSIPを利用するネットワークシステムについて説明したが、本発明は、複数のプロトコルを利用するシステムであれば、利用するプロトコルの種別は特に限定されず、例えばSOAP(Simple Object Access Protocol)、SMTP(Simple Mail Transfer Protocol)、RTP(Real-time Transport Protocol)/RTCP(RTP Control Protocol)等を用いたシステムにも適用することができる。
<第2の実施の形態>
次に、第2の実施の形態のネットワークシステムについて説明する。
以下、第2の実施の形態のネットワークシステムについて、前述した第1の実施の形態との相違点を中心に説明し、同様の事項については、その説明を省略する。
第2の実施の形態のネットワークシステムは、Notifyを必要とするサーバと必要としないサーバとの混在を可能とするシステムであり、Notify制御装置50の代わりにNotify制御装置501を備えている。
図14は、第2の実施の形態のNotify制御装置の機能を示すブロック図である。
Notify制御装置501は、管理テーブル格納部52aおよび検索部53aを備えている点がNotify制御装置50と異なっている。
管理テーブル格納部52aは、グループ管理テーブル50aに加え、処理対象サーバリストを備えている。
図15は、処理対象サーバリストを示す図である。
処理対象サーバリスト50bには、アドレス要求部54および転送判定部55の処理対象となるサーバ(処理対象サーバ)のIPアドレスがリスト化されて格納されている。
再び図14に戻って説明する。
検索部53aは、処理対象サーバリスト50bを参照し、Notifyに含まれる宛先が、処理対象サーバリスト50bに存在しない場合、Notifyをアドレス要求部54に送ることなく宛先のサーバに転送する。
図16は、第2の実施の形態のNotify制御装置の処理を示すフローチャートである。
まず、Notify受信部51が、Notifyを受信する(ステップS51)。
次に、検索部53aが、宛先が処理対象のサーバか否かを判断する(ステップS52)。具体的には、処理対象サーバリスト50bを参照し、Notifyの宛先が処理対象サーバリスト50bに含まれているか否かを判断する。
宛先が処理対象のサーバである場合、すなわち、宛先が処理対象サーバリスト50bに含まれている場合(ステップS52のYes)、ステップS53に移行する。
ステップS53〜ステップS59:転送判定部55が、それぞれ図9のステップS12〜ステップS18と同様の処理を行う。
一方、宛先が処理対象のサーバではない場合、すなわち、宛先が処理対象サーバリスト50bに含まれていない場合(ステップS52のNo)、検索部53aは、Notifyをアドレス要求部54に送ることなく宛先のサーバに転送する(ステップS60)。
以上で処理の説明を終了する。
この第2の実施の形態のNotify制御装置501によれば、第1の実施の形態のNotify制御装置50と同様の効果が得られる。
そして、第2の実施の形態のNotify制御装置501によれば、処理対象サーバリスト50bに含まれていないサーバ(例えば、HTTPロードバランサ30の分散対象でないサーバ)の宛先がNotifyに含まれている場合、そのサーバに対しては必ずNotifyが通知されるようにすることができるため、Notify制御装置501の処理の負荷を軽減することができる。また、Notifyが誤って廃棄されることを防止することができる。
なお、本実施の形態では、処理対象のサーバを処理対象サーバリスト50bに格納したが、本発明はこれに限らず、例えば、処理対象外のサーバをリスト化し、このリストに含まれているサーバの宛先がNotifyに含まれている場合、そのサーバに対しては必ずNotifyが通知されるようにしてもよい。
<第3の実施の形態>
次に、第3の実施の形態のネットワークシステムについて説明する。
以下、第3の実施の形態のネットワークシステムについて、前述した第1の実施の形態との相違点を中心に説明し、同様の事項については、その説明を省略する。
第3の実施の形態のネットワークシステムは、ユーザIDを使って振り分け先を管理するシステムであり、HTTPロードバランサ30が備える振り分け先管理テーブルの内容およびNotify制御装置の機能構成が異なっている。
図17は、第3の実施の形態の振り分け先管理テーブルを示す図である。
振り分け先管理テーブル30bには、ユーザIDおよび振り分けアドレスの欄が設けられており、各欄の横方向に並べられた情報同士が互いに関連づけられている。
ユーザIDの欄には、クライアントに現在ログインしているユーザを識別する情報(ユーザID)が格納されている。
図18は、第3の実施の形態のNotify制御装置の機能を示すブロック図である。
Notify制御装置502は、管理テーブル格納部52および検索部53を有さず、アドレス要求部54が、Notify受信部51が受信したNotifyを直接取得する。すなわち、本実施の形態のNotify制御装置502では、タグリーダーのURIに応じてクライアントを特定する処理は行わない。
アドレス要求部54は、クライアントのIPアドレスの代わりにタグ情報に含まれているユーザIDに基づいてHTTPロードバランサ30に対し、振り分け先を問い合わせる。
図19は、第3の実施の形態のNotify制御装置の処理を示すフローチャートである。
まず、Notify受信部51が、Notifyを受信する(ステップS61)。
次に、アドレス要求部54が、Notifyのタグ情報に含まれているユーザIDに基づいて、HTTPロードバランサ30に対し、振り分け先を問い合わせる(ステップS62)。
ステップS63〜ステップS67:転送判定部55が、それぞれ図9のステップS14〜ステップS18と同様の処理を行う。なお、本実施の形態のHTTPロードバランサ30は、アドレス要求部54から振り分け先の問い合わせを受信すると、振り分け先管理テーブル30bを参照し、問い合わせに含まれるユーザIDに基づいて、振り分け先のサーバを特定する。
この第3の実施の形態のNotify制御装置502によれば、第1の実施の形態のNotify制御装置50と同様の効果が得られる。
なお、本実施の形態では、HTTPロードバランサ30およびプレゼンスサーバ40からの通知パラメータとしてユーザIDを利用したが、これに限定されず、その他の通知パラメータ、例えば、HTTPブラウザに与えたセッションID等を利用するようにしてもよい。
<第4の実施の形態>
次に、第4の実施の形態のネットワークシステムについて説明する。
以下、第4の実施の形態のネットワークシステムについて、前述した第1の実施の形態との相違点を中心に説明し、同様の事項については、その説明を省略する。
第4の実施の形態のネットワークシステムは、ユーザを認証する認証サーバを備えている点、およびNotify制御装置の機能構成が異なっている。
図20は、第4の実施の形態のNotify制御装置を示すブロック図である。
第4の実施の形態のNotify制御装置503は、管理テーブル格納部52および検索部53の代わりに、認証要求部56を備えている。
認証要求部56は、Notifyのタグ情報に含まれるユーザIDに基づいて、認証サーバ70に対してNotify受信部51が受信したNotifyの認証を要求する。
図21は、認証サーバが備えるユーザ利用状況管理テーブルを示す図である。
ユーザ利用状況管理テーブル70aには、クライアントおよびユーザIDの欄が設けられており、各欄の横方向に並べられた情報同士が互いに関連づけられている。
ユーザIDの欄には、クライアントへのログインを許可するユーザIDが格納されている。
認証サーバ70は、認証要求部56からの要求を受信すると、対応するクライアントのIPアドレスが存在すればそのIPアドレスを返し、存在しなければ対応なしを返す。
図22は、第4の実施の形態のNotify制御装置の処理を示すフローチャートである。
まず、Notify受信部51が、Notifyを受信する(ステップS71)。
次に、認証要求部56が、Notifyのタグ情報に含まれているユーザIDに基づいて、認証サーバ70に対して認証を要求する(ステップS72)。
次に、認証要求部56が、クライアントのアドレスが得られたか否かを判断する(ステップS73)。
得られない場合(ステップS73のNo)、処理を終了する。
得られた場合(ステップS73のYes)、ステップS74に移行する。
ステップS74〜ステップS79:転送判定部55が、それぞれ図9のステップS13〜ステップS18と同様の処理を行う。
この第4の実施の形態のNotify制御装置503によれば、第1の実施の形態のNotify制御装置50と同様の効果が得られる。
なお、本実施の形態では、認証にユーザIDを用いたが、これに限定されず、例えば、認証サーバ70から得られる証明IDをタグに格納し、このタグをタグリーダー20a、20bに読み込ませてNotifyに格納するようにしてもよい。
以上、本発明のイベント制御プログラム、イベント制御方法およびイベント制御装置を、図示の実施の形態に基づいて説明したが、本発明はこれに限定されるものではなく、各部の構成は、同様の機能を有する任意の構成のものに置換することができる。また、本発明に、他の任意の構成物や工程が付加されていてもよい。
また、本発明は、前述した各実施の形態のうちの、任意の2以上の構成(特徴)を組み合わせたものであってもよい。
なお、上記の処理機能は、コンピュータによって実現することができる。その場合、Notify制御装置50、501、502、503が有する機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、例えば、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリ等が挙げられる。磁気記録装置としては、例えば、ハードディスク装置(HDD)、フレキシブルディスク(FD)、磁気テープ等が挙げられる。光ディスクとしては、例えば、DVD(Digital Versatile Disc)、DVD−RAM(Random Access Memory)、CD−ROM(Compact Disc Read Only Memory)、CD−R(Recordable)/RW(ReWritable)等が挙げられる。光磁気記録媒体としては、例えば、MO(Magneto-Optical disk)等が挙げられる。
プログラムを流通させる場合には、例えば、そのプログラムが記録されたDVD、CD−ROM等の可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
イベント制御プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送される毎に、逐次、受け取ったプログラムに従った処理を実行することもできる。
以上の実施形態に関し、更に以下の付記を開示する。
(付記1) イベントの中継制御をイベント制御装置に実行させるイベント制御プログラムにおいて、
前記イベント制御装置を、
クライアントを指定する指定情報を含むイベントの通知要求を受信する受信手段、
前記指定情報に基づいて、複数のサーバのうち、前記指定情報によって特定されるクライアントに対してサービスを提供しているサーバを振り分け先のサーバとして通知するよう要求する要求手段、
前記要求手段による要求に応じて通知された前記振り分け先のサーバに、前記イベントの通知要求を転送する転送手段、
として機能させることを特徴とするイベント制御プログラム。
(付記2) 前記受信手段は、前記通知要求をプレゼンスサーバから受信し、
前記要求手段は、前記通知要求を分散処理装置に要求し、
前記サーバは、アプリケーションサーバである、
ことを特徴とする付記1記載のイベント制御プログラム。
(付記3) 前記イベントの通知要求には、前記イベントの通知を要求するサーバの宛先が含まれており、
前記転送手段は、通知された前記振り分け先と、前記宛先とが一致した場合のみ前記振り分け先のサーバに対し、前記イベントの通知要求を転送することを特徴とする付記1または2記載のイベント制御プログラム。
(付記4) 前記指定情報は、前記クライアントの識別情報以外の情報であり、
前記イベント制御装置を、前記指定情報と前記クライアントの識別情報とを関連づけて格納する格納手段、
前記受信手段により前記イベントの通知要求が受信されると、受信した前記イベントの通知要求に含まれる前記指定情報に応じた前記クライアントの識別情報を前記格納手段から検索する検索手段、として機能させ、
前記要求手段は、前記検索手段により検索された前記クライアントの識別情報に基づいて、前記振り分け先のサーバの通知を要求することを特徴とする付記1から3の何れかに記載のイベント制御プログラム。
(付記5) 前記要求手段は、前記サーバの負荷を分散する機能を備え前記クライアントとセッションが確立しているサーバの情報を格納する負荷分散装置に対して前記振り分け先のサーバの通知を要求することを特徴とする付記1記載のイベント制御プログラム。
(付記6) 前記負荷分散装置は、前記指定情報に基づいた前記振り分け先のサーバが存在しない場合、任意のリストから前記振り分け先のサーバを選択し、前記要求手段に応答することを特徴とする付記4記載のイベント制御プログラム。
(付記7) 前記イベントの通知要求には、前記イベントの通知を要求するサーバの宛先が含まれており、
前記要求手段は、前記振り分け先のサーバの通知を要求した要求先から前記振り分け先のサーバが通知されなかった場合、前記要求先に対し、前記指定情報に応じた前記宛先の登録を要求することを特徴とする付記1記載のイベント制御プログラム。
(付記8) 前記イベントの通知要求には、前記イベントの通知を要求するサーバの宛先が含まれており、
前記格納手段は、処理対象のサーバの識別情報を格納するリストを格納しており、
前記検索手段は、前記宛先が、前記リストに含まれている場合、振り分け先のサーバの通知を要求することなく前記リストに含まれているサーバに対し、前記イベントの通知要求を前記第1のプロトコルで転送することを特徴とする付記1記載のイベント制御プログラム。
(付記9) 前記受信手段は、第1のプロトコルで送信された前記イベントの通知要求を受信し、
前記要求手段は、前記指定情報によって指定されるクライアントに対して第2のプロトコルでサービスを提供しているサーバを振り分け先のサーバとして通知するよう要求し、
前記転送手段は、前記イベントの通知要求を前記第1のプロトコルで転送することを特徴とする付記1記載のイベント制御プログラム。
(付記10) イベントの中継制御を、受信手段と要求手段と転送手段を有するイベント制御装置に実行させるイベント制御方法において、
前記受信手段が、クライアントを指定する指定情報を含むイベントの通知要求を受信し、
前記要求手段が、前記指定情報に基づいて、複数のサーバのうち、前記指定情報によって特定されるクライアントに対してサービスを提供しているサーバを振り分け先のサーバとして通知するよう要求し、
前記転送手段が、前記要求手段による要求に応じて通知された前記振り分け先のサーバに、前記イベントの通知要求を転送する、
ことを特徴とするイベント制御方法。
(付記11) イベントの中継制御を行うイベント制御装置において、
クライアントを指定する指定情報を含むイベントの通知要求を受信する受信部と、
前記指定情報に基づいて、複数のサーバのうち、前記指定情報によって特定されるクライアントに対してサービスを提供しているサーバを振り分け先のサーバとして通知するよう要求する要求部と、
前記要求部による要求に応じて通知された前記振り分け先のサーバに、前記イベントの通知要求を転送する転送部と、
を有することを特徴とするイベント制御装置。
実施の形態のコンピュータシステムの概要を示す図である。 ネットワークシステムの構成を示す図である。 振り分け先管理テーブルを示す図である。 Subscribe管理テーブルを示す図である。 グループ管理テーブルを示す図である。 ネットワークシステムの処理を示すシーケンス図である。 Notify制御装置のハードウェア構成例を示す図である。 Notify制御装置の機能を示すブロック図である。 Notify制御装置の処理を示すフローチャートである。 処理の具体例を示すシーケンス図である。 HTTPロードバランサの処理を示すフローチャートである。 Notify制御装置が有する機能を他の装置に実装した例を示す図である。 Notify制御装置が有する機能を他の装置に実装した例を示す図である。 第2の実施の形態のNotify制御装置の機能を示すブロック図である。 処理対象サーバリストを示す図である。 第2の実施の形態のNotify制御装置の処理を示すフローチャートである。 第3の実施の形態の振り分け先管理テーブルを示す図である。 第3の実施の形態のNotify制御装置の機能を示すブロック図である。 第3の実施の形態のNotify制御装置の処理を示すフローチャートである。 第4の実施の形態のNotify制御装置を示すブロック図である。 認証サーバが備えるユーザ利用状況管理テーブルを示す図である。 第4の実施の形態のNotify制御装置の処理を示すフローチャートである。 負荷分散を行うシステムの構成を示す図である。
符号の説明
1 イベント制御装置
1a 受信手段
1b 要求手段
1c 転送手段
2 負荷分散装置
3a〜3c、60a、60b サーバ
4a、4b、10a、10b クライアント
11a、11b Webブラウザ
20a、20b タグリーダー
30、301 HTTPロードバランサ
30a、30b 振り分け先管理テーブル
40、401 プレゼンスサーバ
40a Subscribe管理テーブル
41 Notify配信部
42 Notify制御部
50、501、502、503 Notify制御装置
50a グループ管理テーブル
50b 処理対象サーバリスト
51 Notify受信部
52、52a 管理テーブル格納部
53、53a 検索部
54 アドレス要求部
55 転送判定部
56 認証要求部
61a、61b Webアプリケーション
70 認証サーバ
70a ユーザ利用状況管理テーブル
100、100a、100b ネットワークシステム

Claims (6)

  1. イベントの中継制御をイベント制御装置に実行させるイベント制御プログラムにおいて、
    前記イベント制御装置を、
    クライアントを指定する指定情報を含むイベントの通知要求を受信する受信手段、
    前記指定情報に基づいて、複数のサーバのうち、前記指定情報によって特定されるクライアントに対してサービスを提供しているサーバを振り分け先のサーバとして通知するよう要求する要求手段、
    前記要求手段による要求に応じて通知された前記振り分け先のサーバに、前記イベントの通知要求を転送する転送手段、
    として機能させることを特徴とするイベント制御プログラム。
  2. 前記受信手段は、前記通知要求をプレゼンスサーバから受信し、
    前記要求手段は、前記通知要求を分散処理装置に要求し、
    前記サーバは、アプリケーションサーバである、
    ことを特徴とする請求項1記載のイベント制御プログラム。
  3. 前記イベントの通知要求には、前記イベントの通知を要求するサーバの宛先が含まれており、
    前記転送手段は、通知された前記振り分け先と、前記宛先とが一致した場合のみ前記振り分け先のサーバに対し、前記イベントの通知要求を転送することを特徴とする請求項1または2記載のイベント制御プログラム。
  4. 前記指定情報は、前記クライアントの識別情報以外の情報であり、
    前記イベント制御装置を、前記指定情報と前記クライアントの識別情報とを関連づけて格納する格納手段、
    前記受信手段により前記イベントの通知要求が受信されると、受信した前記イベントの通知要求に含まれる前記指定情報に応じた前記クライアントの識別情報を前記格納手段から検索する検索手段、として機能させ、
    前記要求手段は、前記検索手段により検索された前記クライアントの識別情報に基づいて、前記振り分け先のサーバの通知を要求することを特徴とする請求項1から3の何れかに記載のイベント制御プログラム。
  5. イベントの中継制御を、受信手段と要求手段と転送手段を有するイベント制御装置に実行させるイベント制御方法において、
    前記受信手段が、クライアントを指定する指定情報を含むイベントの通知要求を受信し、
    前記要求手段が、前記指定情報に基づいて、複数のサーバのうち、前記指定情報によって特定されるクライアントに対してサービスを提供しているサーバを振り分け先のサーバとして通知するよう要求し、
    前記転送手段が、前記要求手段による要求に応じて通知された前記振り分け先のサーバに、前記イベントの通知要求を転送する、
    ことを特徴とするイベント制御方法。
  6. イベントの中継制御を行うイベント制御装置において、
    クライアントを指定する指定情報を含むイベントの通知要求を受信する受信部と、
    前記指定情報に基づいて、複数のサーバのうち、前記指定情報によって特定されるクライアントに対してサービスを提供しているサーバを振り分け先のサーバとして通知するよう要求する要求部と、
    前記要求部による要求に応じて通知された前記振り分け先のサーバに、前記イベントの通知要求を転送する転送部と、
    を有することを特徴とするイベント制御装置。
JP2008145360A 2008-06-03 2008-06-03 イベント制御プログラム、イベント制御方法およびイベント制御装置 Expired - Fee Related JP5029495B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2008145360A JP5029495B2 (ja) 2008-06-03 2008-06-03 イベント制御プログラム、イベント制御方法およびイベント制御装置
US12/415,527 US20090300182A1 (en) 2008-06-03 2009-03-31 Computer-readable storage medium storing event control program, event control method, and event controller
GB0906600A GB2460509B8 (en) 2008-06-03 2009-04-16 Event control method and event controller

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2008145360A JP5029495B2 (ja) 2008-06-03 2008-06-03 イベント制御プログラム、イベント制御方法およびイベント制御装置

Publications (2)

Publication Number Publication Date
JP2009294736A true JP2009294736A (ja) 2009-12-17
JP5029495B2 JP5029495B2 (ja) 2012-09-19

Family

ID=40750743

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008145360A Expired - Fee Related JP5029495B2 (ja) 2008-06-03 2008-06-03 イベント制御プログラム、イベント制御方法およびイベント制御装置

Country Status (3)

Country Link
US (1) US20090300182A1 (ja)
JP (1) JP5029495B2 (ja)
GB (1) GB2460509B8 (ja)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8886787B2 (en) * 2009-02-26 2014-11-11 Microsoft Corporation Notification for a set of sessions using a single call issued from a connection pool
US8676977B2 (en) * 2009-12-14 2014-03-18 Sonus Networks, Inc. Method and apparatus for controlling traffic entry in a managed packet network
JP6039352B2 (ja) * 2012-10-12 2016-12-07 キヤノン株式会社 デバイス管理システム、デバイス管理システムの制御方法、及びプログラム
US9609068B2 (en) * 2013-12-16 2017-03-28 Fuji Xerox Co., Ltd. Session management system, session management apparatus, and non-transitory computer readable medium
JP6298711B2 (ja) * 2014-05-19 2018-03-20 株式会社日立製作所 分散処理システム

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040003099A1 (en) * 2002-06-28 2004-01-01 Microsoft Corporation Bi-directional affinity within a load-balancing multi-node network interface
JP2005094323A (ja) * 2003-09-17 2005-04-07 Nippon Telegraph & Telephone West Corp イベント通知システム、及びイベント通知方法
JP2007026006A (ja) * 2005-07-15 2007-02-01 Nec Corp 情報交換システム、管理サーバ及びそれらに用いるネットワーク負荷軽減方法並びにそのプログラム
US20080065652A1 (en) * 2006-08-25 2008-03-13 Microsoft Corporation Maintaining and establishing subscriptions with load-balanced servers

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6424992B2 (en) * 1996-12-23 2002-07-23 International Business Machines Corporation Affinity-based router and routing method
US6470389B1 (en) * 1997-03-14 2002-10-22 Lucent Technologies Inc. Hosting a network service on a cluster of servers using a single-address image
US6324580B1 (en) * 1998-09-03 2001-11-27 Sun Microsystems, Inc. Load balancing for replicated services
US6725281B1 (en) * 1999-06-11 2004-04-20 Microsoft Corporation Synchronization of controlled device state using state table and eventing in data-driven remote device control model
US6907455B1 (en) * 2000-06-29 2005-06-14 Cisco Technology, Inc. Apparatus and methods for providing an event driven notification over a network to a telephony device
US6999992B1 (en) * 2000-10-04 2006-02-14 Microsoft Corporation Efficiently sending event notifications over a computer network
US7069309B1 (en) * 2000-10-19 2006-06-27 Cisco Technology, Inc. Apparatus and methods for requesting an event notification over a network
US7406524B2 (en) * 2001-07-26 2008-07-29 Avaya Communication Isael Ltd. Secret session supporting load balancer
EP1315349B1 (en) * 2001-11-21 2008-03-19 Sun Microsystems, Inc. A method for integrating with load balancers in a client and server system
US7469302B2 (en) * 2003-08-29 2008-12-23 Yahoo! Inc. System and method for ensuring consistent web display by multiple independent client programs with a server that is not persistently connected to client computer systems
US7170982B2 (en) * 2004-08-26 2007-01-30 Lucent Technologies Inc. Call authorization and billing message routing capability
KR100690787B1 (ko) * 2005-02-25 2007-03-09 엘지전자 주식회사 무선통신 시스템에서 이벤트 통지방법
US8203964B2 (en) * 2005-05-06 2012-06-19 Broadcom Corporation Asynchronous event notification
US20070150492A1 (en) * 2005-12-27 2007-06-28 Hitachi, Ltd. Method and system for allocating file in clustered file system
US7831600B2 (en) * 2005-12-28 2010-11-09 Sap Ag Cluster communication manager
US8423670B2 (en) * 2006-01-25 2013-04-16 Corporation For National Research Initiatives Accessing distributed services in a network

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040003099A1 (en) * 2002-06-28 2004-01-01 Microsoft Corporation Bi-directional affinity within a load-balancing multi-node network interface
JP2005094323A (ja) * 2003-09-17 2005-04-07 Nippon Telegraph & Telephone West Corp イベント通知システム、及びイベント通知方法
JP2007026006A (ja) * 2005-07-15 2007-02-01 Nec Corp 情報交換システム、管理サーバ及びそれらに用いるネットワーク負荷軽減方法並びにそのプログラム
US20080065652A1 (en) * 2006-08-25 2008-03-13 Microsoft Corporation Maintaining and establishing subscriptions with load-balanced servers

Also Published As

Publication number Publication date
GB2460509A8 (en) 2013-06-19
GB2460509A (en) 2009-12-09
US20090300182A1 (en) 2009-12-03
JP5029495B2 (ja) 2012-09-19
GB2460509B (en) 2012-04-04
GB0906600D0 (en) 2009-05-27
GB2460509B8 (en) 2013-06-19

Similar Documents

Publication Publication Date Title
US20180213031A1 (en) System and method to balance servers based on server load status
US7861174B2 (en) Method and system for assembling concurrently-generated content
US8527635B2 (en) Contents delivery system and method, web server and contents provider DNS server thereof
KR100472952B1 (ko) 세션 초기화 프로토콜(sip)기반의 부하 분산장치 및방법
JP4758362B2 (ja) 中継装置、プログラム及び中継方法
CN101326493B (zh) 用于多处理器服务器中的负载分配的方法和装置
US20070150602A1 (en) Distributed and Replicated Sessions on Computing Grids
CN103597471A (zh) 用于对计算机网络上的数据通信进行缓存的方法和系统
JP2008181427A (ja) シングルサインオンシステム、情報端末装置、シングルサインオンサーバ、プログラム
JP5029495B2 (ja) イベント制御プログラム、イベント制御方法およびイベント制御装置
US20030051042A1 (en) Load balancing method and system for allocation of service requests on a network
US11640368B2 (en) Acceleration system for facilitating processing of API calls
JP2018506772A (ja) ネットワークアドレスの解決
JP2007219637A (ja) 負荷分散システムおよびそのプログラム
CN110708309A (zh) 反爬虫系统及方法
JP2006268671A (ja) ログイン制御システムおよびログイン制御方法
CA2452134A1 (en) System and method for constructing phrases for a media server
JP2009017347A (ja) 通信を制御する装置、方法、プログラム、および端末装置
KR20060066385A (ko) 홈네트워크에서의 미디어 포맷 및 전송 프로토콜 변환장치 및 그 방법
JP2005078193A (ja) プロトコル自動選択装置および方法ならびにプログラム
KR100947114B1 (ko) 더미 메시지를 이용하여 웹 서비스의 품질 데이터를추출하는 방법
Cisco Location Confirmation Enhancements for Alternate Endpoints
JP4653618B2 (ja) アクセス管理装置、方法及びプログラム
KR100835528B1 (ko) 구간정보를 이용한 멀티미디어 콘텐츠의 스트리밍 방법 및그 스트리밍 단말기
JP2016149652A (ja) 呼制御サーバ、端末登録方法、端末登録プログラム、及び通信システム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20110217

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20120524

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20120529

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20120611

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20150706

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees