図面 (/)

技術 イベント通知機能提供システム

出願人 ヤフー株式会社
発明者 川崎庸市高橋啓介豊田将志
出願日 2009年9月15日 (9年3ヶ月経過) 出願番号 2009-213277
公開日 2011年3月31日 (7年9ヶ月経過) 公開番号 2011-065244
状態 特許登録済
技術分野 オンライン・システム
主要キーワード 数値化情報 設定用ページ 参照リクエスト 消去メッセージ 共有リスト スケールアウト サマリー情報 友だち
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2011年3月31日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (17)

課題

アプリケーションで大量に発生するイベントを処理する。

解決手段

アプリケーションを管理するサービス提供サーバから送信されたイベントの発生を受信する第1サーバと、第1サーバからの依頼に応じ、イベントの発生を記憶手段に登録する登録処理を行う第2サーバと、を備え、第1サーバは、サービス提供サーバから受信したイベントの発生の登録処理を第2サーバに依頼するとともに、第2サーバからの完了通知を受け取ることなく、イベントの発生の登録処理を行った旨のレスポンスをサービス提供サーバに対して送信する。

概要

背景

近年、インターネットにおいては、例えばソーシャルネットワーキングサービス(以下、SNS)などのように、ユーザ個人記事写真動画といったコンテンツ投稿し、他ユーザ公開することができる場を構築するアプリケーションウェブ上で提供するサービスが普及している。

これらのサービスは、一般にCGM(Consumer Generated Media)とも呼ばれ、コンテンツを作成したユーザから他ユーザへの情報発信のツールとしてだけでなく、ユーザ間のコミュニケーションのツールとしても利用されている。たとえば、或るユーザが投稿した日記に対して、その日記を閲覧した他ユーザが個々にコメントを付記することで、その日記を媒介としてユーザ間で意見交換が行われる、というものである。

そして、最近、上記のようなサービスでは、或るコンテンツに対してユーザによりコメントが付記された場合に、そのコンテンツを投稿したユーザに対して、新着のコメントがあった旨を通知するようにしたものが提案されている(例えば、特許文献1を参照。)。このような通知は、そのときサービスの利用中であればクライアントブラウザにより表示されているウェブページに差し込むことで行われる。

概要

各アプリケーションで大量に発生するイベントを処理する。アプリケーションを管理するサービス提供サーバから送信されたイベントの発生を受信する第1サーバと、第1サーバからの依頼に応じ、イベントの発生を記憶手段に登録する登録処理を行う第2サーバと、を備え、第1サーバは、サービス提供サーバから受信したイベントの発生の登録処理を第2サーバに依頼するとともに、第2サーバからの完了通知を受け取ることなく、イベントの発生の登録処理を行った旨のレスポンスをサービス提供サーバに対して送信する。

目的

近年、インターネットにおいては、例えばソーシャル・ネットワーキング・サービス(以下、SNS)などのように、ユーザ個人が記事や写真や動画といったコンテンツを投稿し、他ユーザに公開することができる場を構築するアプリケーションをウェブ上で提供する

効果

実績

技術文献被引用数
1件
牽制数
1件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

ウェブ上のアプリケーションで任意に定義されたイベントの発生を大量に処理するためのサーバ構成を有し、各アプリケーション間でイベントの発生を通知するイベント通知機能提供システムであって、アプリケーションを管理するサービス提供サーバから送信されたイベントの発生を受信する第1サーバと、前記第1サーバからの依頼に応じ、前記イベントの発生を記憶手段に登録する登録処理を行う第2サーバと、を備え、前記第1サーバは、前記サービス提供サーバから受信したイベントの発生の登録処理を前記第2サーバに依頼するとともに、前記第2サーバからの完了通知を受け取らずに前記イベントの発生を受信した後に、イベントの発生の登録処理を行った旨のレスポンスを前記サービス提供サーバに対して送信することを特徴とするイベント通知機能提供システム。

請求項2

前記第1サーバは、前記サービス提供サーバから送信されるイベント発生メッセージを、イベントの発生として受信し、前記第2サーバは、前記イベント発生メッセージから抽出した、ユーザ識別子、イベントが発生したアプリケーションの識別子、イベントが発生したコンテンツの識別子、発生したイベントの識別子及びイベントの内容を含むイベント情報を、ユーザ識別子に関連づけてデータベースに登録し、かつ、前記データベースに登録されているイベント情報から作成したサマリー情報キャッシュに登録し、前記第1サーバは、前記サービス提供サーバからのリクエストに応じて、前記キャッシュに登録されているサマリー情報をサービス提供サーバに送信することを特徴とする請求項1に記載のイベント通知機能提供システム。

請求項3

ウェブ上のアプリケーションで任意に定義されたイベントの発生を大量に処理し、各アプリケーション間でイベントの発生を通知するイベント通知機能提供システムの動作方法であって、第1サーバが、アプリケーションを管理するサービス提供サーバから送信されたイベントの発生を受信する工程と、第2サーバが、前記第1サーバからの依頼に応じ、前記イベントの発生を記憶手段に登録する登録処理を行う工程と、第1サーバが、前記サービス提供サーバから受信したイベントの発生の登録処理を前記第2サーバに依頼するとともに、前記第2サーバからの完了通知を受け取らずに前記イベントの発生を受信した後に、イベントの発生の登録処理を行った旨のレスポンスを前記サービス提供サーバに対して送信する工程と、を含むことを特徴とするイベント通知機能提供システムの動作方法。

技術分野

0001

本発明は、ウェブ上のアプリケーション間イベントの発生を通知する技術に関する。

背景技術

0002

近年、インターネットにおいては、例えばソーシャルネットワーキングサービス(以下、SNS)などのように、ユーザ個人記事写真動画といったコンテンツ投稿し、他ユーザ公開することができる場を構築するアプリケーションをウェブ上で提供するサービスが普及している。

0003

これらのサービスは、一般にCGM(Consumer Generated Media)とも呼ばれ、コンテンツを作成したユーザから他ユーザへの情報発信のツールとしてだけでなく、ユーザ間のコミュニケーションのツールとしても利用されている。たとえば、或るユーザが投稿した日記に対して、その日記を閲覧した他ユーザが個々にコメントを付記することで、その日記を媒介としてユーザ間で意見交換が行われる、というものである。

0004

そして、最近、上記のようなサービスでは、或るコンテンツに対してユーザによりコメントが付記された場合に、そのコンテンツを投稿したユーザに対して、新着のコメントがあった旨を通知するようにしたものが提案されている(例えば、特許文献1を参照。)。このような通知は、そのときサービスの利用中であればクライアントブラウザにより表示されているウェブページに差し込むことで行われる。

先行技術

0005

特開2007−328537号公報

発明が解決しようとする課題

0006

しかし、上記のような従来のサービスでは、扱われるコンテンツの数は膨大であり、それに伴い、発生するイベントは大量となる。そのため、上記のようなサービスを提供するサーバは、大量に発生するイベントを処理するべく、そのような負荷に耐えうる仕組みを構築することが求められている。

0007

そこで、本発明は、大量に発生するイベントを処理することが可能なサーバ構成を有するイベント通知機能提供システムを提供することを目的とする。

課題を解決するための手段

0008

上記の課題を解決するため、本発明は以下のような態様を要旨とする。

0009

(1)ウェブ上のアプリケーションで任意に定義されたイベントの発生を大量に処理するためのサーバ構成を有し、各アプリケーション間でイベントの発生を通知するイベント通知機能提供システムであって、
アプリケーションを管理するサービス提供サーバから送信されたイベントの発生を受信する第1サーバと、
前記第1サーバからの依頼に応じ、前記イベントの発生を記憶手段に登録する登録処理を行う第2サーバと、を備え、
前記第1サーバは、
前記サービス提供サーバから受信したイベントの発生の登録処理を前記第2サーバに依頼するとともに、前記第2サーバからの完了通知を受け取らずに前記イベントの発生を受信した後に、イベントの発生の登録処理を行った旨のレスポンスを前記サービス提供サーバに対して送信することを特徴とするイベント通知機能提供システム。

0010

(1)によれば、第1サーバがサービスサーバから送信されるイベントの発生を受信すると、イベントの発生を受信した直後に、登録処理を行った旨のレスポンスをサービスサーバに返送し、その一方で、イベントの登録処理を第2サーバに依頼するようにした。したがって、サービスサーバとの間で、各アプリケーションで発生する大量のイベントを滞りなく処理することができる。

0011

(2) 前記第1サーバは、
前記サービス提供サーバから送信されるイベント発生メッセージを、イベントの発生として受信し、
前記第2サーバは、
前記イベント発生メッセージから抽出した、ユーザ識別子、イベントが発生したアプリケーションの識別子、イベントが発生したコンテンツの識別子、発生したイベントの識別子及びイベントの内容を含むイベント情報を、ユーザ識別子に関連づけてデータベースに登録し、かつ、前記データベースに登録されているイベント情報から作成したサマリー情報キャッシュに登録し、
前記第1サーバは、
前記サービス提供サーバからのリクエストに応じて、前記キャッシュに登録されているサマリー情報をサービス提供サーバに送信することを特徴とする(1)のイベント通知機能提供システム。

0012

(2)によれば、イベントの登録処理については第2サーバがバックグラウンドで行う一方で、イベントの参照処理については第1サーバがキャッシュにアクセスすることで行う。これにより、第1サーバが、データベースに直接アクセスすることによる処理パフォーマンスの低下を防ぐことができ、大量に発生するイベントを処理するのに好適である。

0013

(3)ウェブ上のアプリケーションで任意に定義されたイベントの発生を大量に処理し、各アプリケーション間でイベントの発生を通知するイベント通知機能提供システムの動作方法であって、
第1サーバが、アプリケーションを管理するサービス提供サーバから送信されたイベントの発生を受信する工程と、
第2サーバが、前記第1サーバからの依頼に応じ、前記イベントの発生を記憶手段に登録する登録処理を行う工程と、
第1サーバが、前記サービス提供サーバから受信したイベントの発生の登録処理を前記第2サーバに依頼するとともに、前記第2サーバからの完了通知を受け取らずに前記イベントの発生を受信した後に、イベントの発生の登録処理を行った旨のレスポンスを前記サービス提供サーバに対して送信する工程と、を含むことを特徴とするイベント通知機能提供システムの動作方法。

0014

(3)によれば、(1)と同様の効果を奏する。

発明の効果

0015

本発明によれば、各アプリケーションで大量に発生するイベントを処理することが可能となる。

図面の簡単な説明

0016

実施形態にかかるシステム全体の構成例を示す図である。
実施形態にかかるイベント通知機能提供システムの構成例を示す図である。
イベントテーブルデータ構造例を示す図である。
コンテンツテーブルのデータ構造例を示す図である。
キャッシュテーブルのデータ構造例を示す図である。
イベント定義データ共有リストのデータ構造例を示す図である。
実施形態の処理例を示すシーケンス図(イベント登録)である。
実施形態の処理例を示すシーケンス図(イベント参照サマリー)である。
イベントの通知に関する画面例(サマリー)を示す図である。
実施形態の処理例を示すシーケンス図(イベント参照:イベント一覧)である。
イベントの通知に関する画面例(イベント一覧)を示す図である。
実施形態の処理例を示すシーケンス図(イベント消去)である。
イベント通知機能提供システムの第2サーバの詳細な構成例を示す図である。
farmID対応付けテーブルのデータ構造例を示す図である。
実施形態の処理例を示すシーケンス図(イベント登録)である。
実施形態の処理例を示すフローチャート図(依頼先サーバ決定処理)である。

実施例

0017

以下、図面を参照して、本発明を実施するための形態(以下、実施形態)について説明する。

0018

<構成>
図1を参照して、本実施形態に係るイベント通知機能提供システム(ノーティスプラットフォーム)3を含むシステム全体の構成について説明する。

0019

イベント通知機能提供システム3は、複数のサービス提供サーバ5(5a、…、5x)とネットワークNを介して接続されている。また、サービス提供サーバ5は、複数のユーザ端末7(7a、…、7x)とネットワークを介して接続されている。

0020

イベント通知機能提供システム3、サービス提供サーバ5及びユーザ端末7は、CPU等の制御装置メモリやHDD等の記憶装置通信I/F等の通信装置といったハードウェア資源を有するコンピュータ(単一或いは複数)により構成される。ユーザ端末7は、ユーザが利用するPC(Personal Computer)や携帯電話端末等であり、上記のようなハードウェア資源に加え、キーボタンタッチパネル等の入力装置液晶ディスプレイ等の出力装置を備える。

0021

(ユーザ端末7)
ユーザ端末7は、一般的なブラウザを備えている。ブラウザは、インターネットの標準プロトコルであるHTTP(Hyper Text Transfer Protocol)等に従い、HTML(Hyper Text Markup Language)等の言語で記述されたページデータの要求、取得及び表示、フォームデータの送信等を行う機能を有している。ユーザは、ユーザ端末7のブラウザを通じて、サービス提供サーバ5により提供されるアプリケーションを利用する。

0022

(サービス提供サーバ5)
複数のサービス提供サーバ5は、それぞれ個別のアプリケーション(以下、AP)をユーザ端末7に対して提供し、ウェブ上のサービスを実現する。ウェブ上のサービスの例は、ユーザが記事や写真や動画等といったコンテンツを閲覧したり、ユーザ白身がコンテンツを投稿して他のユーザに公開したり、商取引を行う場を提供するサービスであり、ニュースサービス、SNS(ソーシャルネットワーキングサービス)、オークションサービス地図情報サービス等が該当する。APは、ユーザ端末7に対して、コンテンツの投稿やコンテンツに対する何らかのアクションの入力や、コンテンツの検索、閲覧等をユーザが行うための各種機能を提供する。

0023

本実施形態では、各APにおいて任意に定義されるものであって、ユーザに関わりのあるコンテンツをターゲットとした何らかのアクションを示す情報を「イベント」という。

0024

例えば、オークションサービスであれば、一のユーザ(ユーザAとする)が出品したアイテムに対して他のユーザ(ユーザBやユーザCとする)により入札が行われた場合、ユーザAから見たユーザBやユーザCの入札行為を「イベント」と定義することができる。

0025

また、別の例では、オークションサービスにおいて、一のユーザ(ユーザBとする)が或るアイテムに対して入札を行い、その入札を行ったアイテムに対してさらに他のユーザ(ユーザCとする)により入札が行われた場合、ユーザBから見たユーザCの入札行為を「イベント」と定義することができる。

0026

また、別の例では、SNSにおいて、一のユーザ(ユーザXとする)を他のユーザ(ユーザYとする)が友だちに登録した場合、ユーザXから見たユーザYの登録行為を「イベント」と定義することができる。

0027

さらに、別の例では、オークションサービスにおいて、一のユーザ(ユーザZとする)の出品物が誰にも落札されないで終了した場合、ユーザZから見た、その終了したという結果を「イベント」と定義することができる。この例でいうアクションは、ユーザが直接的に生じさせたものではないが、このようにAPの動作上で自動的に発生した出来事もアクションに含めることができる。

0028

なお、本実施形態では、一のサービス提供サーバ5が一のAPを管理する構成について説明するが、本発明はこれに限らず、一のサービス提供サーバ5が複数のAPを管理する構成や、一のAPを複数のサービス提供サーバ5が管理する構成を採用することができる。

0029

サービス提供サーバ5は、一のAPにつき、入力受付手段51と、入力情報処理手段52と、イベント送信手段53と、イベント参照手段54と、イベント受信手段55と、ページデータ提供手段56と、を備えている。

0030

入力受付手段51は、ユーザ端末7のブラウザから、マウスクリックキーボード入力に基づいたユーザの各種リクエスト及び入力情報を受信する機能を有する。

0031

入力情報処理手段52は、入力受付手段51が受信したユーザのリクエスト及び入力情報の内容に応じて、投稿されたコンテンツやコンテンツに対するアクションのデータベースヘの登録、検索、参照等の各種処理を行う機能を有する。また、入力情報処理手段52は、コンテンツに対するアクションを登録する際に、イベントの定義付けをする。例えば、オークションサービスにおいて、ユーザの入力情報の内容が「出品物1への1つ目の入札」であった場合、出品物1の識別子(item_0001)に、1つ目の入札を示す識別子(event_0001)を割り当てる。

0032

イベント送信手段53は、入力情報処理手段52がコンテンツに対するアクションをイベントとして定義した場合に、イベントの発生メッセージをイベント通知機能提供システム3に対して送信する機能を有する。

0033

イベント参照手段54は、入力受付手段51が受信したユーザのリクエストに応じて、イベント通知機能提供システム3に対してイベントの参照リクエストを送信する機能を有する。

0034

イベント受信手段55は、イベント通知機能提供システム3から送信された、各APにおけるイベントの発生状況を受信する機能を有する。

0035

ページデータ提供手段56は、ページデータを作成し、ユーザ端末7のブラウザに対して送信する機能を有する。例えば、イベント受信手段55が受信した、各APにおけるイベントの発生状況に基づいてページデータを作成し、ユーザ端末7のブラウザに対して送信し、ユーザに対してイベントの発生を通知する。

0036

イベント送信手段53、イベント参照手段54及びイベント受信手段55は、イベント通知機能提供システム3の管理者側から提供されたAPI(Application Program Interface)をAPに組み込むことで実現される機能である。各サービス提供サーバ5が管理するAPとイベント通知機能提供システム3との間の通信は任意の形式とすることができる。

0037

(イベント通知機能提供システム3)
一方、イベント通知機能提供システム3は、複数のAPのそれぞれにおいて任意に定義されているイベントの発生を収集し、一括管理し、各APに対して通知する機能を有する。イベント通知機能提供システム3は、イベント受信手段31と、イベント登録手段32と、イベント読出手段33と、イベント通知手段34と、イベント消去手段35と、イベント記憶手段36と、を備えている。

0038

イベント受信手段31は、各AP(より詳しくはイベント送信手段53)からそれぞれ送信されたイベントの発生メッセージを受信する。イベント登録手段32は、イベント受信手段31が受信した各APにおけるイベントの発生メッセージに基づいて、イベント記憶手段36に対するイベントの登録処理を行う。

0039

イベント記憶手段36は、各ユーザに関するイベントの発生状況を記憶している。ユーザに関するイベントの発生状況とは、各APで発生したイベントをユーザ単位分類し、時系列に従って蓄積したデータである。詳しいデータ構成は後述するが、イベント記憶手段36は、イベントが発生したコンテンツ及びAPと、イベントの発生の通知対象となるユーザとを特定可能なデータを少なくとも記憶している。

0040

イベント読出手段33は、各AP(より詳しくはイベント参照手段54)から送信されたイベントの参照リクエストに応じて、イベント記憶手段36からイベントの発生状況を読み出す。なお、本実施形態でのイベントの読み出しは、いわゆるプル型の通知を行う場合のものであるが、プッシュ型の通知を行う場合など任意のタイミングを採用することができる。

0041

イベント通知手段34は、イベント読出手段33が読み出したイベントの発生状況を、各AP(より詳しくはイベント受信手段55)に対して送信する。イベント消去手段35は、イベント通知手段34が各APに対して送信したイベントの発生状況のうち、ユーザにより通知の確認が行われたイベントに関するレコードを、イベント記憶手段36から消去する。

0042

(イベント通知機能提供システム3のサーバ構成)
図1ではイベント通知機能提供システム3の機能的な構成について説明したが、以下では、図2を参照してハードウェア的な構成について説明する。図2は、本実施形態にかかるイベント通知機能提供システム3のサーバ構成を示す図である。

0043

イベント通知機能提供システム3は、第1サーバ11と、第2サーバ12と、データベースサーバ(以下、DBサーバ)13と、キャッシュサーバ14と、を備え、これらの各サーバ11〜14が相互に通信可能に接続されて構成されている。各サーバ11〜14間の通信は、任意の形式とすることができる。各サーバ11〜14は、CPU等の制御装置、メモリやHDD等の記憶装置、通信I/F等の通信装置といったハードウェア資源を有するコンピュータにより構成される。

0044

第1サーバ11は、複数のサービス提供サーバ5のそれぞれにより管理されているAPとの窓口となる。つまり、第1サーバ11は、各サービス提供サーバ5からのリクエストを受け付け、処理結果をレスポンスとして返送するフロントエンド部としての機能を有する。第2サーバ12は、第1サーバ11の依頼を受けてイベントの登録処理を行う機能を有する。DBサーバ13及びキャッシュサーバ14は、各APにおいて発生したイベントを管理する。

0045

ここで、図1との関係において、第1サーバ11は、前述したイベント受信手段31、イベント読出手段33及びイベント通知手段34として機能する。また、第2サーバ12は、イベント登録手段32及びイベント消去手段35として機能する。さらに、DBサーバ13及びキャッシュサーバ14は、イベント登録手段32、イベント消去手段35及びイベント記憶手段36として機能する。

0046

(イベントの登録処理)
ここで、本実施形態のイベント通知機能提供システム3は、各APにおいて発生する大量のイベントを処理するため、イベントの登録処理に関して以下のような処理を行うようにしている。

0047

第1サーバ11は、まず、サービス提供サーバ5からイベントの発生メッセージを受信すると、受信したイベントの登録処理を第2サーバ12に対して依頼する。このとき、第1サーバ11は、第2サーバ12からの処理完了の通知を受け取ることなく、イベントの発生メッセージを受信した直後、イベントの登録処理を行った旨のレスポンスを受信元のサービス提供サーバ5に対して送信する。

0048

一方で、第1サーバ11から依頼を受けた第2サーバ12は、イベントの登録処理をDBサーバ13及びキャッシュサーバ14に対して行う。

0049

このようにして、イベントの登録処理を、各サービス提供サーバ5からのリクエストを直接受け付ける第1サーバ11ではなく、第2サーバ12がバックグラウンドで行うようにしたので、第1サーバ11はイベントの発生メッセージを受信するとそのままサービス提供サーバ5に対してレスポンスを送信できるようになり、各APにおいて発生する大量のイベントを滞りなく処理することができるようになる。また、第1サーバ11は、イベントの登録処理及び読出処理の両方を行うことによる処理負担から解放されるので、イベントの登録処理及び読出処理の双方に関するパフォーマンスを向上させることができる。

0050

(DBサーバ13のデータ構成)
次に、図3及び図4を参照して、DBサーバ13が備えるデータ構造例について説明する。DBサーバ13は、イベントテーブル(図3)とコンテンツテーブル(図4)と、を備えている。

0051

(イベントを個々に管理するイベントテーブル)
イベントテーブル(図3)は、各APにおいて発生したイベントに関する情報(以下、イベント情報)を記憶している。イベント情報は、「ユーザ識別子」、「サービス識別子」、「コンテンツ識別子」、「イベント識別子」、「イベント内容」及び「日時」の各データ項目を含んでいる。これらの各データ項目は、サービス提供サーバ5のAPにより任意に定義され、イベントの発生メッセージに含まれて送信されてくるものである。

0052

「ユーザ識別子」は、イベントの発生を通知する対象ユーザを特定するためのデータである。例えば、オークションサービスであれば、入札がつけられた出品物の出品者が有するユーザIDである。

0053

「サービス識別子」は、イベントが発生したAPを特定するデータである。例えば、識別子「auc」であればオークションサービス、識別子「board」であれば掲示板サービス、という具合に特定される。

0054

「コンテンツ識別子」は、イベントが発生したコンテンツを特定するデータである。例えば、オークションサービスを例にすると、識別子「item」であれば「出品物」であり、識別子「item_0001」であれば「出品物A」という具合に特定される。

0055

「イベント識別子」は、発生したイベントを特定するデータである。例えば、オークションサービスの出品物を例にすると、識別子「event」であれば「入札」であり、識別子「event_0001」であれば1つ目の「入札1」、という具合に特定される。

0056

「イベント内容」は、発生したイベントについての付加情報を示すテキストデータである。例えば、イベントを発生させたユーザにより入力された情報の内容であり、オークションサービスであれば、「入札額」や「入札者のユーザID」などが記述されている。

0057

「日時」は、イベントが発生した日時を特定するデータである。例えば、オークションサービスを例にすると、「入札が行われた日時」となる。

0058

(イベントをコンテンツ単位で管理するコンテンツテーブル)
コンテンツテーブル(図4)は、発生したイベントをコンテンツ単位で集約した情報(以下、コンテンツ情報)を記憶している。コンテンツ情報は、「ユーザ識別子」、「サービス識別子」、「コンテンツ識別子」、「イベント数」、「イベント識別子」、「URL」及び「日時」の各データ項目を含んでいる。

0059

「イベント数」は、コンテンツに対して発生したイベントの数を特定するデータである。前述のイベントテーブルに記憶されている各イベント情報を、「ユーザ識別子」、「サービス識別子」及び「コンテンツ識別子」の組をキーとして取りまとめ、その数をカウントしたものが記憶されている。「URL」は、各APで管理されているコンテンツのアドレスを特定するデータである。例えば、オークションサービスを例にすると、1個の出品物に対して新たに入札がついた件数となる。

0060

本実施形態では、DBサーバ13は、イベント情報とコンテンツ情報をそれぞれ分けて管理していることから、それぞれを別のサーバファームとして構築するような場合に、それぞれのデータ量に応じて拡張が可能になり、スケーラビリティを確保することができる。

0061

(イベントをAP単位で管理するキャッシュテーブル)
次に、図5を参照して、キャッシュサーバ14が備えるデータ構造例について説明する。キャッシュサーバ14は、キャッシュテーブル(図5)を備えている。

0062

キャッシュテーブル(図5)は、イベントが発生したコンテンツをAP単位で集約した情報(以下、サマリー情報)を記憶している。サマリー情報は、「ユーザ識別子」、「サービス識別子」、「コンテンツ数」、「コンテンツ識別子」、「イベント識別子」、「URL」及び「日時」の各データ項目を含んでいる。

0063

「コンテンツ数」は、イベントが発生したコンテンツの数を特定するデータである。前述のDBサーバ13のコンテンツテーブルに記憶されているコンテンツ情報を、「ユーザ識別子」及び「サービス識別子」の組をキーとして取りまとめ、その数をカウントしたものが記憶されている。例えば、オークションサービスを例にすると、10個の出品物を出品しているような場合に、そのうち新たに入札がついた出品物の個数となる。

0064

また、サマリー情報には、コンテンツ数に含まれる個々のコンテンツに関するコンテンツ情報が関連付けて記憶されている。これにより、個々のコンテンツのURLや発生したイベントの数なども特定可能となる。

0065

(各APにおける発生イベントの表示の共有
次に、図6を参照して、イベント定義データ共有リストについて説明する。

0066

イベント定義データ共有リストは、各APにおいて、他のAPで定義されているイベントを把握するために用いられるデータであり、各APに共通して提供される。また、ユーザ端末7のブラウザにより、他のAPにおけるサービス名、コンテンツ名及びイベント名を表示させる際に用いられる。

0067

イベント定義データ共有リストは、各APにおいて任意に定義されている「サービス識別子」、「コンテンツ識別子」及び「イベント識別子」の一覧に応じて、それぞれを表示する名称が関連付けられている。例えば、サービス識別子「auc」に対して「オークション」サービス、コンテンツ識別子「item」に対して「出品物」が関連付けられている。

0068

イベント通知機能提供システム3は、各APに対して、他のAPに関するイベントの発生を通知するとき、前述のサマリー情報等とともに、イベント定義データ共有リストを提供する。これにより、各APでは、他のAPにおいて定義されているコンテンツやイベントを共有することができ、また、イベントの通知を行う際に各APで共通の表示を行うことができる。

0069

ここで、「サービス識別子」、「コンテンツ識別子」及び「イベント識別子」は、サービス提供サーバ5の運営者により各APで任意に定義された識別子が設定される。

0070

識別子の設定を行うに際して、イベント通知機能提供システム3は、サービス提供サーバ5に接続された運営者端末(図示せず)のブラウザに設定用ページデータを送信する。サービス提供サーバ5の運営者は、ブラウザに表示された設定用ページを介して、AP内で任意に定義する識別子を登録し、イベント通知機能提供システム3に対して送信する。

0071

例えば、APにより提供されるウェブ上のサービスがオークションサービスである場合、運営者は、サービス識別子として「auc」を、表示名のテキストとして「オークション」を登録する。また、コンテンツ識別子として「item」を、表示名のテキストとして「出品物」を登録する。さらに、イベント識別子として「event」を、表示名のテキストとして「入札」を登録する。

0072

なお、上記設定用ページでは、各APで任意に定義する識別子の登録のほか、イベントの発生通知を行うページのレイアウト(後述の図9及び図11を参照)のカスタマイズや、イベントの発生の通知のパターン(後述のAP単位、コンテンツ単位、イベント一覧など)、通知の確認が終了したイベントの消去のタイミングなどを任意に設定できるようにしてもよい。この場合、イベント通知機能提供システム3は、イベントの発生の通知のパターンや消去のタイミングなどの設定情報を、サービス識別子に関連付けて管理し、各APに応じた処理を行う。

0073

<動作>
次に、本実施形態のイベント通知機能提供システム3の動作について説明する。

0074

(イベントの登録)
図7は、本実施形態の処理例を示すシーケンス図であり、サービス提供サーバ5のAPから送信されたイベントの発生を、DBサーバ13及びキャッシュサーバ14に格納するまでの処理例である。

0075

ユーザ端末7のユーザが、ブラウザからサービス提供サーバ5のAPにより提供されるサービスのページを閲覧したい場合、ブラウザからサービス提供サーバ5のAPに対してページリクエストを送信する(ステップS11)。例えば、オークションサービスを例にすると、出品物を閲覧するためのページのリクエストである。このリクエストは、ブラウザにおいて、対象コンテンツのURLを入力するか、他のページに張られたリンクを指定すること等により行われる。

0076

なお、ログイン済みであるかどうかの確認は、例えばセッションID等を示すクッキーを読み込むことで行う。未だログインされていないものとすると、サービス提供サーバ5は、ユーザ端末7のブラウザにログインページを送信し、ユーザIDとパスワードの入力を受け付け、ユーザデータベースに登録されているか否かの照合を行い、ログイン処理を行う。

0077

サービス提供サーバ5は、予め保持されたページデータを取得するか、動的にページデータを作成するかにより、ブラウザに提供するページデータを作成する(ステップS12)。この際、APが提供するコンテンツと、コンテンツに対して何らかのアクションを入力するための画面領域をページデータに含める。

0078

続いて、サービス提供サーバ5は、作成したページデータをユーザ端末7に対して送信する(ステップS13)。ページデータはHTTPのレスポンス等に従ってブラウザに送信される。ユーザ端末7は、受信したページデータに基づいてブラウザにページ画面を表示する(ステップS14)。例えば、オークションサービスを例にすると、出品物とともに「入札」及び「入札額」を指定する画面領域が表示されており、その領域に対して入力を行うことで入札を行うことができるようになる。

0079

続いて、ユーザ端末7のユーザが、ページ画面のコンテンツに対するアクションとして所望の内容を入力すると、ブラウザからサービス提供サーバ5のAPに対して、入力されたアクションの内容が送信される(ステップS101)。

0080

サービス提供サーバ5は、受信したアクションの内容をデータベースに登録し、その際、イベントの定義付けを行う(ステップS102)。すなわち、新たに発行した「イベント識別子(例えば、入札1)」やユーザによる入力情報の内容を示す「イベント内容(例えば入札額)」を、「コンテンツ識別子(例えば出品物A)」、イベントの通知対象となる「ユーザ識別子(例えば、入札がついた出品物Aの出品者)」、「URL」等とともにデータベースに登録する。

0081

続いて、サービス提供サーバ5は、イベントの発生メッセージをイベント通知機能提供システム3の第1サーバ11に対して送信する(ステップS103)。イベントの発生メッセージには、イベントの通知対象となる「ユーザ識別子」、「サービス識別子」、「コンテンツ識別子」、「イベント識別子」、コンテンツの「URL」、「イベント内容」及び「日時」が含まれている。

0082

第1サーバ11は、サービス提供サーバ5からイベントの発生メッセージを受信すると、その登録処理を第2サーバ12に依頼するリクエストと共に、第2サーバ12に送信する(ステップS104)。続いて、第1サーバ11は、受信したイベントの発生メッセージについて処理完了のレスポンスを受信元のサービス提供サーバ5に対して送信する(ステップS105)。なお、第1サーバ11は、第2サーバ12への依頼を行う前にサービス提供サーバ5に対するレスポンスを行うようにしても良い。

0083

つまり、第1サーバ11は、第2サーバ12による登録処理の完了を待たず、イベントの発生メッセージを受信した後、直ちに、処理完了のレスポンスを返送することになる。

0084

一方、第1サーバ11から登録処理を依頼された第2サーバ12は、まず、DBサーバ13に対してイベント登録リクエストを送信する(ステップS106)。これを受けたDBサーバ13は、まず、発生メッセージからイベント情報を抽出し、イベントテーブル(図3)に登録する。続いて、DBサーバ13は、イベントテーブルからコンテンツ情報を生成し、コンテンツテーブル(図4)に登録する(ステップS107)。各テーブルの参照や更新には、SQL(Structured Query Language)等のコマンドが用いられる。

0085

より具体的には、DBサーバ13は、第1サーバ11が受信したイベントの発生メッセージから、イベントの通知対象となる「ユーザ識別子」、「サービス識別子」、「コンテンツ識別子」、「イベント識別子」、「イベント内容」及び「日時」の組を抽出し、イベント情報として、イベントテーブルの新たなレコードに設定する。

0086

また、DBサーバ13は、イベント情報の登録が完了すると、イベントテーブルに記憶されている各イベント情報を、「ユーザ識別子」、「サービス識別子」及び「コンテンツ識別子」の組をキーとして取りまとめ、そのレコード数を「イベント数」としてカウントする。そして、「ユーザ識別子」、「サービス識別子」、「コンテンツ識別子」、「イベント数」、「イベント識別子」、「URL」及び「日時」の組を抽出し、コンテンツ情報として、コンテンツテーブルの新たなレコードに設定する。

0087

DBサーバ13は、イベントテーブル(図3)及びコンテンツテーブル(図4)への登録を完了すると、その旨の通知を第2サーバ12に対して送信する(ステップS108)。

0088

次に、第2サーバ12は、DBサーバ13に対してサマリー作成リクエストを送信する(ステップS109)。これを受けたDBサーバ13は、サマリー情報を作成し(ステップS110)、第2サーバ12に対して送信する(ステップS111)。

0089

より具体的には、DBサーバ13は、コンテンツテーブル(図4)において新たなレコードとして登録されたコンテンツ情報を、「ユーザ識別子」及び「サービス識別子」の組をキーとして取りまとめ、そのレコード数を「コンテンツ数」としてカウントする。そして、「ユーザ識別子」、「サービス識別子」、「コンテンツ数」、「コンテンツ識別子」、「イベント識別子」、取りまとめたコンテンツのうち最新のイベントが発生したコンテンツの「URL」、最新のイベントの「イベント内容」及び「日時」からなる項目組合せをサマリー情報とし、これに個々のコンテンツ情報をづける。

0090

第2サーバ12は、DBサーバ13からサマリー情報を受信すると、キャッシュサーバ14に対して、サマリー登録リクエストを送信する(ステップS112)。これを受けたキャッシュサーバ14は、サマリー情報をキャッシュテーブル(図5)の新たなレコードに設定し、登録を行う(ステップS113)。なお、サマリー登録リクエストは、DBサーバ13からキャッシュサーバ14に対して行われるようにしても良い。

0091

キャッシュサーバ14は、サマリー情報の登録を完了すると、その旨の通知を第2サーバ12に対して送信する(ステップS114)。第2サーバ12は、イベントの登録完了の通知を第1サーバ11に対して送信する(ステップS115)。

0092

これを受けた第1サーバ11は、更新通知を要求するAPが予め設定されている場合には、その対象となるAPに対して更新通知を送信する(ステップS116)。

0093

(イベントの参照)
図8及び図10は、本実施形態の処理例を示すシーケンス図であり、サービス提供サーバ5のAPがイベントの参照リクエストを送信してから、そのAPに対してイベントが通知されるまでの処理例である。

0094

(イベントの参照:サマリー一覧)
まず、図8を参照して、サマリー一覧を指定したイベントの参照リクエストを行った場合の処理例について説明する。

0095

図8において、ユーザ端末7のユーザがブラウザからサービス提供サーバ5のAPにより提供されるサービスのページを閲覧したい場合、ブラウザからサービス提供サーバ5のAPに対してページリクエストを送信する(ステップS201)。例えば、ショッピングサービスを例にすると、商品を検索・閲覧するためのページのリクエストである。このリクエストは、ブラウザにおいて、対象コンテンツのURLを入力するか、他のページに張られたリンクを指定すること等により行われる。

0096

サービス提供サーバ5は、ユーザ端末7のブラウザからAPに対するページリクエストを受信すると、第1サーバ11に対して、イベント参照リクエスト「サマリー一覧」を送信する(ステップS202)。イベント参照リクエストには、当該リクエストを行ったユーザのユーザ識別子が含まれている。

0097

イベント参照リクエストを受信した第1サーバ11は、イベント参照リクエスト「サマリー一覧」をキャッシュサーバ14に対して送信する(ステップS203)。

0098

イベント参照リクエストを受信したキャッシュサーバ14は、リクエストを行った「ユーザ識別子」をキーとしてキャッシュテーブル(図5)を参照し、対象となるサマリー情報を検索する(ステップS204)。

0099

キャッシュヒットありの場合)
ステップS204での検索の結果、サマリー情報がヒットした場合、キャッシュサーバ14は、サマリー情報を取得し、第1サーバ11に対して送信する(ステップS205)。

0100

サマリー情報を受信した第1サーバ11は、サマリー情報をサービス提供サーバ5に対して送信する(ステップS206)。

0101

サマリー情報を受信したサービス提供サーバ5は、サマリー情報に基づいてページデータを作成し(ステップS207)、ページリクエストのあったユーザ端末7のブラウザに送信する(ステップS208)。

0102

ページデータを受信したユーザ端末7のブラウザはページ画面を表示する(ステップS209)。図9は、ブラウザのページ画面70の例を示している。ページ画面70には、イベント通知領域71が表示されており、その領域内において、サマリー情報に基づいて作成されたAP単位通知領域72及びコンテンツ単位通知領域73が表示されている。

0103

AP単位通知領域72には、ユーザに閲するイベントの発生をAP単位で通知するメッセージが表示される。例えば、「オークションにおいて2つの出品物に入札があります」、「掲示板において1件のトピックに対して新着コメントがあります」といったメッセージが表示され、イベントが発生したAP名とそのAPにおいてイベントが発生したコンテンツの数がユーザに通知される。

0104

一方、コンテンツ単位通知領域73には、ユーザに関するイベントの発生をコンテンツ単位で通知するメッセージが表示される。例えば、「オークションの出品物Aに2件の入札があります」、「オークションの出品物Bに1件の入札があります」というように、イベントが発生したAP名及びコンテンツ名とそのコンテンツに対して発生したイベントの数をユーザに通知するメッセージが表示される。

0105

また、AP単位通知領域72には、AP毎に、最新のイベントが発生したコンテンツへのリンク先URLが埋め込まれる。一方、コンテンツ単位通知領域73には、コンテンツ毎に、そのコンテンツへのリンク先URLが埋め込まれる。

0106

リンク先URLは、URLの文字列を表示するか、或いは、通知メッセージの表示に紐付けるなどし、それらの表示をクリッカブルとすることにより、リンク先URLが示すウェブページへの遷移をユーザに指定させる。

0107

これにより、イベントの発生通知を受けたユーザは、上記リンク先URLを介して、イベントが発生したコンテンツのウェブページをブラウザに表示させ、発生したイベントを実際に確認することができる。

0108

(キャッシュヒットなしの場合) ところで、本実施形態では、イベントの登録処理とイベントの読出処理との間は非同期で行われるため、イベント参照時にサマリー情報が末作成である場合も起こりうる。以下の処理は、この場合における処理例である。

0109

ステップS204での検索の結果、サマリー情報がヒットしなかった場合、キャッシュサーバ14は、サマリー情報の取得に失敗した旨の通知を、第1サーバ11に対して送信する(ステップS210)。

0110

通知を受信した第1サーバ11は、イベント参照リクエスト「サマリー一覧」をDBサーバ13に対して送信する(ステップS211)。

0111

イベント参照リクエストを受信したDBサーバ13は、リクエストを行った「ユーザ識別子」をキーとしてコンテンツテーブル(図4)を参照し、サマリー情報を作成して(ステップS212)、第1サーバ11に対して送信する(ステップS213)。

0112

より具体的には、DBサーバ13は、コンテンツテーブル(図4)において新たなレコードとして登録されたコンテンツ情報を、リクエストを行った「ユーザ識別子」をキーに抽出する。そして、これらを「サービス識別子」をキーとして「サービス識別子」単位で取りまとめ、そのレコード数を「コンテンツ数」としてカウントする。そして、「ユーザ識別子」、「サービス識別子」、「コンテンツ数」、「コンテンツ識別子」、「イベント識別子」、取りまとめたコンテンツのうち最新のイベントが発生したコンテンツの「URL」、最新のイベントの「テキスト」及び「日時」からなる組をサマリー情報とし、これに個々のコンテンツ情報を紐づける。

0113

サマリー情報を受信した第1サーバ11は、サマリー情報をサービス提供サーバ5に対して送信する(ステップS214)。

0114

サマリー情報を受信したサービス提供サーバ5は、サマリー情報に基づいてページデータを作成し(ステップS215)、ページリクエストのあったユーザ端末7のブラウザに送信する(ステップS216)。ベージデータを受信したユーザ端末7のブラウザはページ画面(図9参照)を表示する(ステップS217)。

0115

また、第1サーバ11は、キャッシュサーバ14に対して、サマリー登録リクエストを送信する(ステップS218)。これを受けたキャッシュサーバ14は、サマリー情報をキャッシュテーブル(図5)の新たなレコードに設定し、登録を行う(ステップS219)。これにより次回以降の参照時にはキャッシュサーバ14にアクセスすればよい。

0116

(イベントの参照:イベント一覧)
次に、図10を参照して、イベント一覧を指定したイベントの参照リクエストを行った場合の処理例について説明する。

0117

図10において、ユーザ端末7のユーザがブラウザからサービス提供サーバ5のAPにより提供されるサービスのページを閲覧したい場合、ブラウザからサービス提供サーバ5のAPに対してページリクエストを送信する(ステップS301)。例えば、ニュースサービスを例にすると、ニュース記事を閲覧するためのページのリクエストである。

0118

サービス提供サーバ5は、ユーザ端末7のブラウザからAPに対するページリクエストを受信すると、第1サーバ11に対して、イベントの参照リクエスト「イベント一覧」を送信する(ステップS302)。イベントの参照リクエストには、送信元のサービス識別子や、当該リクエストを行ったユーザのユーザ識別子(例えばユーザID)が含まれている。

0119

イベントの参照リクエストを受信した第1サーバ11は、イベントの参照リクエストをDBサーバ13に対して送信する(ステップS303)。イベントの参照リクエストを受信したDBサーバ13は、リクエストを行った「ユーザ識別子」をキーとしてイベントテーブル(図3)を参照し、対象となるイベント情報をサービス識別子ごとに取りまとめ、一覧として取得する(ステップS304)。DBサーバ13は、取得したイベント情報の一覧を第1サーバ11に対して送信する(ステップS305)。

0120

イベント情報の一覧を受信した第1サーバ11は、イベント情報の一覧をサービス提供サーバ5に対して送信する(ステップS306)。イベント情報の一覧を受信したサービス提供サーバ5は、イベント情報の一覧に基づいてページデータを作成し(ステップS307)、ページリクエストのあったユーザ端末7のブラウザに送信する(ステッブS308)。

0121

ページデータを受信したユーザ端末7のブラウザはページ画面を表示する(ステップS309)。図11は、ブラウザのページ画面70の例を示している。ページ画面70には、イベント通知領域71が表示されており、その領域内において、イベント情報の一覧に基づいて作成されたイベント一覧通知領域74が表示されている。

0122

イベント一覧通知領域74には、リクエストを行ったユーザに対するイベントの発生をイベント単位で(つまり、個々のイベントを詳細に)通知するメッセージが表示される。例えば、「オークションの出品物Aに対する入札は以下です」とし、「入札1:詳細(時間/入札者/入札額)」、「入札2:詳細(時間/入札者/入札額)」といったメッセージが表示され、発生したイベントが個別に通知される。

0123

(イベントの消去)
図12は、本実施形態の処理例を示すシーケンス図であり、サービス提供サーバ5のAPがイベントの消去リクエストを送信してから、DBサーバ13及びキャッシュサーバ14により対象のイベントが消去されるまでの処理例である。

0124

図12において、サービス提供サーバ5は、前述したように、ユーザ端末7に対してページデータを送信し(ステップS21)、ブラウザに表示させる(ステップS22)ことで、イベントの通知を行う(図8及び図10)。その後、ユーザ端末7において、イベントが発生したコンテンツのリンク先URLがユーザにより指定(クリック)されると(ステップS23)、リンク先URLが示すウェブページのページリクエストがサービス提供サーバ5に対して送信される(ステップS24)。

0125

これを受けたサービス提供サーバ5は、そのページリクエストを処理する(ステップS25)。例えば、他のサービス提供サーバ5で管理されるAP内のコンテンツであれば、そのページリクエストを他のサービス提供サーバ5に受け渡す。

0126

続いて、サービス提供サーバ5は、発生したイベントをユーザが確認したものとし、イベント通知機能提供システム3の第1サーバ11に対して、イベントの消去メッセージを送信する(ステップS401)。イベントの消去メッセージには、消去を行う対象の「ユーザ識別子」、「サービス識別子」及び「コンテンツ識別子」が含まれている。

0127

第1サーバ11は、サービス提供サーバ5からイベントの消去メッセージを受信すると、その消去処理を第2サーバ12に依頼するリクエストと共に、第2サーバ12に送信する(ステップS402)。続いて、第1サーバ11は、消去メッセージについて処理完了のレスポンスを受信元のサービス提供サーバ5に対して送信する(ステップS403)。

0128

一方、第1サーバ11から消去処理を依頼された第2サーバ12は、まず、DBサーバ13に対してイベント消去リクエストを送信する(ステップS404)。これを受けたDBサーバ13は、まず、イベントテーブル(図3)から、消去対象の「ユーザ識別子」、「サービス識別子」及び「コンテンツ識別子」をキーとしてイベント情報を消去する(ステップS405)。

0129

また、DBサーバ13は、該当するイベント情報を消去した後のイベントテーブルからコンテンツ情報を抽出し、コンテンツテーブル(図4)に登録する。これは、消去後のイベント情報をコンテンツ情報に反映するためである。

0130

DBサーバ13は、消去を完了すると、その旨の通知を第2サーバ12に対して送信する(ステップS406)。次に、第2サーバ12は、DBサーバ13に対してサマリー作成リクエストを送信する(ステップS407)。これは、消去後のイベント情報をサマリー情報に反映するためである。これを受けたDBサーバ13は、サマリー情報を作成し(ステップS408)、第2サーバ12に対して送信する(ステップS409)。

0131

第2サーバ12は、DBサーバ13からサマリー情報を受信すると、キャッシュサーバ14に対して、サマリー登録リクエストを送信する(ステップS410)。これを受けたキャッシュサーバ14は、サマリー情報をキャッシュテーブル(図5)の新たなレコードに設定し、登録を行う(ステップS411)。

0132

キャッシュサーバ14は、サマリー情報の登録を完了すると、その旨の通知を第2サーバ12に対して送信する(ステップS412)。第2サーバ12は、完了の通知を第1サーバ11に対して送信する(ステップS413)。

0133

これを受けた第1サーバ11は、更新通知を要求するAPが予め設定されている場合には、そのAPに対して更新通知を送信する(ステップS414)。

0134

なお、前述の処理例では、ユーザによりリンク先URLが指定されたことをトリガーとして、イベントの消去を行うようにしたが、これに限られるものではなく、例えば、サマリー情報やイベント情報に基づいて作成したページデータをユーザ端末7に対して送信したことをトリガーとして、イベントの消去を行うようにすることもできる。

0135

(第2サーバ12の詳細な構成)
以下では、図13図16を参照し、前述した第2サーバ12の詳細な構成及び動作について説明する。

0136

図13は、第2サーバ12の詳細構成を示す。第2サーバ12は、複数のサーバ12(12a、…、12x)を組み合わせたサーバファームとして構築されている。すなわち、第2サーバ12は、第1サーバ11からの依頼に応じたイベントの更新系処理(登録処理及び消去処理)を、負荷分散により行うべく集積された複数のサーバ群である。

0137

第2サーバ12は、2台のサーバを組み合わせたグループ(以下、小ファーム)を複数設けることで構成される。サーバファーム全体を構成する個々のサーバには、それぞれを特定するための識別子(以下、farmID)が割り当てられる。例えば、サーバファーム全体で2N台のサーバが設けられる場合、farmIDとして、「0」から「(N−1)+N」までの数値を識別子として各サーバに割り当てることができる(図13参照)。

0138

第1サーバ11は、イベントの登録依頼を、上記farmIDを指定することにより行う。第1サーバ11により指定されたサーバは、DBサーバ13及びキャッシュサーバ14に対してイベントの登録処理を行う。

0139

図14は、farmID対応付けテーブルを示す。farmID対応付けテーブルは、複数のサーバ間で互いに対となって小ファームを構成する2台のサーバの組合せが予め定められているテーブルである。小ファームを構成する2台のサーバは、サーバの障害発生時に相互に補い合う関係にある。

0140

つまり、一方のサーバがダウンすると、そのサーバに対して割り振られていたイベント登録依頼が、同じ小ファーム内の(正常に稼働中の)他方のサーバに対して割り振られる。

0141

farmID対応付けテーブルは、第1サーバ11の記憶部(メモリなど)に記憶されている。つまり、第1サーバ11は、farmIDを指定してイベント登録依頼を行う予定のサーバがダウンしているとき、farmID対応付けテーブルを参照する。そして、そのfarmID(例えば、図示の「farm_0」)に対応づけられた他方のfarmID(例えば、図示の「farm_(N−1)+1」)を読み出し、読み出したfarmIDを指定して他方のサーバに対してイベント登録依頼を行う。

0142

図15は、本実施形態の処理例を示すシーケンス図であり、サービス提供サーバ5のAPから送信されたイベントの発生を、DBサーバ13及びキャッシュサーバ14に格納するまでの処理例である。基本的には、図7に示すシーケンス図と同様であるため、同様の内容(図7と同一の符号で示された処理など)については説明を省略する。

0143

図15において、第1サーバ11は、ステップS103においてサービス提供サーバ5から送信されたイベントの発生メッセージを受信すると、依頼先サーバ決定処理を行う(ステップS501)。依頼先サーバ決定処理では、前述の第2サーバ12のサーバファームのうち、イベントの登録処理を依頼するサーバ(以下、依頼先サーバ)を決定する処理を行う。本処理については、後で図16を参照して説明する。

0144

第1サーバ11は、依頼先サーバ決定処理により決定した依頼先サーバに対して、イベントの登録処理を依頼するリクエストと共に、サービス提供サーバ5から受信したイベントの発生メッセージを送信する(ステップS104)。これを受けた依頼先サーバは、DBサーバ13に対してイベント登録リクエストを送信する(ステップS106)。

0145

図16は、前述の依頼先サーバ決定処理の処理例を示すフローチャート図である。

0146

まず、第1サーバ11は、イベントの発生メッセージに含まれる「ユーザ識別子」を取得し、その取得した「ユーザ識別子」を数値化情報(=k)に変換する(ステップS511)。

0147

「ユーザ識別子」が、英数字の組合せで構成されるユーザIDである場合、第1サーバ11は、ユーザIDに含まれる文字(英字記号)部分を数値に変換することで、ユーザID全体を数値化することができる。文字の数値化には、英字(A〜Z)や記号(−、/)などの文字に一意数字が予め対応づけられたデータ(例えば、ASCII文字コード)を用いて行うことができる。例えば、ASCIIコードでは、英字「A〜Z」が数値「65〜90」に対応付けられており、ユーザIDが「AZ1111」だとすると、数値化情報として「65901111」を得ることができる。また、得られた数字列をいくつかに分け、それらを加えたものを数値化情報とすることもできる(例えば、65+90+11+11=177)。

0148

次に、第1サーバ11は、第2サーバ12のサーバファームを構成する全てのサーバ数(=n)を取得する(ステップS512)。続いて、第1サーバ11は、演算式「Result=k mod n」を実行する(ステップS513)。つまり、第1サーバ11は、「ユーザ識別子」の数値化情報(=k)を、サーバファームの全サーバ数(=n)で除算し、その余り演算結果として出力する。たとえば、「ユーザ識別子」の数値化情報(=k)が「177」であり、全サーバ数(=n)が「6」とすると、「177」が「6」で除算されて剰余値「3」が算出される。

0149

次に、第1サーバ11は、演算結果をfarmIDとして取得する(ステップS514)。続いて、第1サーバ11は、取得したfarmIDに該当するサーバが正常に稼働しているかどうかを判別する(ステップS515)。

0150

第1サーバ11は、取得したfarmIDに該当するサーバが正常に稼働していると判別した場合、取得したfarmIDに該当するサーバを依頼先サーバとして決定する(ステップS517)。

0151

一方、第1サーバ11は、取得したfarmIDに該当するサーバが正常に稼働していない(サーバダウンである)と判別した場合、farmID対応付けテーブル(図14)を参照し、そのfarmIDに対応づけられた他方のfarmIDを取得する(ステップS516)。そして、取得したfarmIDに該当するサーバを依頼先サーバとして決定する(ステップS517)。

0152

このように、1人のユーザに関するイベントの発生の処理は1つの固有のサーバにより行われ、かつ、その固有のサーバには障害時に切り替えられるサーバが割り当てられているので、1人のユーザに関するイベントの発生の処理が複数のサーバに跨って振り分けられることはなく、個々のユーザに関するイベントの発生順序を確保することができる。

0153

また、個々のユーザに関するイベントの発生を処理するサーバを、ユーザ識別子から一意に、かつ動的に決定することができるようにしたので、スケールアウトの際にも容易に対処できるようになり、スケーラビリティの確保につながる。

0154

なお、前述の依頼先サーバの決定処理は一例であるから、その具体的な内容は、「各ユーザに固有の識別子を用いてそのユーザに関するイベントの登録処理を担当するサーバを一意に決定する」という目的を逸脱しない範囲で任意に変更可能である。例えば、端末IDなど、ユーザIDとは異なるユーザ識別子を用いる場合や、所定の関数を用いるなど、前述の数値化手法とは異なる手法を採用することができる。

0155

また、farmID対応付けテーブル(図14)を参照して、小ファーム内の他方のサーバを決定するようにしたが、これに限らず、テーブルを設けずとも、小ファーム内の他方のサーバを、以下のようにして動的に決定することも可能である。

0156

サーバファーム全体で2N台のサーバが設けられる場合に、「0」から「(N−1)+N」までの数値を識別子として各サーバに割り当てたとき、一方のサーバの識別子を「x」であるとすると、他方のサーバの識別子を演算式「y=x+N」により決定することができる。例えば、サーバファーム全体で「2N=10」台のサーバが設けられている場合に、一方のサーバが「x=3」であるとき、他方のサーバを「y=8」と決定することができる。このようにすると、2台の組合せを予め定めたテーブルを用意する必要がなくなり、拡張性を持たせるのに好適となる。

0157

なお、本実施形態のDBサーバ13及びキャッシュサーバ14についても、複数のサーバを組み合わせたサーバファームとして構築するようにしても良い。そして、この場合は、各ユーザに固有の識別子(ユーザ識別子)とサーバ固有の識別子とを予め紐づけたテーブルなどを用意しておき、そのユーザに関するイベントの管理を担当するサーバを一意に決定するようにすることができる。これにより、あるユーザに関するイベントの発生状況固有のサーバにより管理することができ、データが分散管理されることがない。

0158

総括
以上説明したように、本実施形態のイベント通知機能提供システム3では、それぞれで異なるAPにおいて任意に定義されたイベントの発生を横断的に管理することができ、一のAPにおいて任意に定義されたイベントの発生を他のAPに通知する仕組みを提供することができる。これにより、ユーザからすれば、利用しているAP間の隔たりを意識することなく、各APでのイベントの発生を知ることができるようになる。

0159

また、発生したイベントの登録処理を、各サービス提供サーバ5からのリクエストを直に受ける第1サーバ11ではなく、第2サーバ12がバックグラウンドで行うようにしたので、第1サーバ11はイベントの発生メッセージを受信するとそのままサービス提供サーバ5に対してレスポンスを送信できるようになり、各APにおいて発生する大量のイベントを滞りなく処理することができるようになる。また、第1サーバ11は、イベントの登録処理及び読出処理の両方を行うことによる処理負担から解放されるので、イベントの登録処理及び読出処理の双方に関するパフォーマンスを向上させることができる。

0160

また、イベントの登録処理については第2サーバがバックグラウンドで行う一方で、イベントの参照処理については第1サーバがキャッシュサーバにアクセスすることで行う。これにより、第1サーバが、DBサーバに直接アクセスすることによる処理パフォーマンスの低下を防ぐことができ、大量に発生するイベントを処理するのに好適である。

0161

また、各APでのイベントの発生状況を、通知を行う対象となるユーザ識別子をキーとして管理するので、ユーザ識別子ごとにデータベースを分割管理することができ、これによってユーザごとにデータアクセス高速化も期待できる。また、イベントの参照時には、通知を行う対象となるユーザ識別子を超えてイベント情報が読み出されることもなく、システムの堅牢性も確保することができる。

0162

また、発生したイベントを、AP単位の識別子及びコンテンツ単位での識別子を紐付けて管理するので、イベントの発生状況の通知に、AP単位での通知、コンテンツ単位での通知、個々のイベント単位での通知という具合に、バリエーションを持たせることができる。

0163

以上、本発明の好適な実施形態により本発明を説明した。ここでは特定の具体例を示して本発明を説明したが、特許請求の範囲に定義された本発明の広範な趣旨および範囲から逸脱することなく、これら具体例に様々な修正および変更を加えることができることは明らかである。すなわち、具体例の詳細および添付の図面により本発明が限定されるものと解釈してはならない。

0164

本実施形態のイベント通知機能提供システム3は、複数のサービスを統合してユーザに提供する一のサービス提供企業利用可能なことはもちろんであるが、異なるサービス提供企業間でも利用可能である。さらに、ウェブ上のサービスをユーザに提供するサービス提供企業に限らず、社員業務アプリケーションを使用させて情報の共有を行っているような一般企業においても利用可能である。

0165

なお、本発明は、一のAPでのイベントの発生を他のAPに対して通知することを要旨とするものであり、そこから先のAP側での処理は、各APにゆだねることができる。本実施形態では、各APは、イベントの発生をユーザに対して通知することにより、他のAPでのイベントの発生をユーザが知ることができるようにしているが、例えばユーザの行動分析するためのAPであれば、イベントの発生そのものを通知するというよりは、イベントの発生状況を分析した結果を提供することも考えられる。あるAPにおけるコンテンツに対してコメントが付きやすい時間帯集計する、という具合である。また、イベントの発生状況の分析をイベント通知機能提供システム3側で行い、その結果を各APに対して提供するようにしても良い。

0166

1 システム
3イベント通知機能提供システム
5サービス提供サーバ
7ユーザ端末
11 第1サーバ
12 第2サーバ
13DBサーバ
14キャッシュサーバ
15イベント消去手段
16 イベント記憶手段
31イベント受信手段
32イベント登録手段
33 イベント読出手段
34イベント通知手段
35 イベント消去手段
36 イベント記憶手段
51入力受付手段
52入力情報処理手段
53イベント送信手段
54イベント参照手段
55 イベント受信手段
56イベントデータ提供手段
70ページ画面
71 イベント通知領域
72AP単位通知領域
73コンテンツ単位通知領域
74イベント一覧通知領域

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

ページトップへ

新着 最近 公開された関連が強い 技術

  • キヤノン株式会社の「 中継装置、制御方法、およびプログラム」が 公開されました。( 2018/11/15)

    【課題】複数のユーザで造形装置を効率よく利用することを可能とする中継装置を提供する。【解決手段】3次元オブジェクトを造形する造形装置100と接続され、クライアント端末104から造形装置100に対する造... 詳細

  • 株式会社日立製作所の「 業務連携システムおよび業務連携方法」が 公開されました。( 2018/11/15)

    【課題】クラウド化した営業店端末機能にて業務連携処理を実装するに際し、連携対象業務に応じたホストでの各事象に由来する情報の出力先制御を的確、かつ、効率的なものとする。【解決手段】業務連携システム10に... 詳細

  • 富士通株式会社の「 制御プログラム、制御方法及び制御装置」が 公開されました。( 2018/11/15)

    【課題】受け付けた特定操作に応じた画面遷移が行われない事態の発生を抑制する。【解決手段】第1のイベントを検出すると、ソフトウェアに関する第1プロセス及び第2プロセスの生成指示を出力し、いずれかの情報を... 詳細

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する挑戦したい社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ