以下、本発明の実施の形態について、図を用いて説明する。
実施の形態1.
図1は、本実施の形態に係る情報配信システム100の構成を示すブロック図である。
図1において、情報配信システム100は、データベース102、データベース管理装置110、イベント制御装置120を備える。情報配信システム100は、クライアントシステム101から受け付けた依存関係のあるデータの操作要求に対し、データベース管理装置110によりデータベース102の操作を行った後に、イベント制御装置120により操作結果を各配信先システム103へと配信するシステムである。
図1には示していないが、情報配信システム100は、処理装置、記憶装置、入力装置、出力装置等のハードウェアを備える。ハードウェアは、データベース102や、後述するデータベース管理装置110及びイベント制御装置120の各部によって利用される。例えば、処理装置は、データや情報の演算、加工、読み取り、書き込み等を行うために利用される。記憶装置は、そのデータや情報を記憶するために利用される。また、入力装置は、そのデータや情報を入力するために、出力装置は、そのデータや情報を出力するために利用される。
クライアントシステム101は、データベース102の登録・更新等の操作を要求するシステムである。情報配信システム100に接続するクライアントシステム101の数が複数あってもよい。
データベース102は、マスタとなるデータベースである。データベース102の形式としては関係データベース、階層型データベース等、任意の形式を使用してよい。ここでは、便宜上、関係データベースを使用しているものとする。
配信先システム103は、データベース102で登録・更新等の操作がされた情報を受信するシステムである。配信先システム103の数は、必要に応じて任意の数をとる。図1では、複数の配信先システム103を配信先1、・・・、配信先nとして表している。配信先システム103の形態はデータベースや、受信した情報を基にメールを送信するメールサーバや、受信した情報を基にファイル構成を変更するようなシステム等である。
データベース管理装置110は、クライアントシステム101からの操作要求を受け付ける機能、データベース102へ登録、更新、削除、検索等の操作を行う機能を持つ。データベース管理装置110は、操作受付部111、イベント番号付加部112(イベント識別子割当部の一例)、データ操作部113、イベント通知部114、データセット検索部115を有する。
操作受付部111は、クライアントシステム101からのデータベース102の操作要求を受け付け、要求元のクライアントシステム101と操作内容によりイベント種別(例えば、依存関係のあるデータの一括登録、一括更新、一括削除)を判断する。
イベント番号付加部112は、操作受付部111より受信したデータに対しイベント番号(イベント識別子の一例)を付加する機能と、イベント番号とデータをデータ操作部113に送信する機能と、イベント通知部114へイベント番号とイベント種別とを含むイベント情報を送信する機能を持つ。
データ操作部113は、イベント番号付加部112より受信したイベント番号とデータを、データベース102へ投入する。
イベント通知部114は、イベント番号付加部112より送信されたイベント情報をイベント制御装置120へと送付する機能を持つ。
データセット検索部115は、イベント制御装置120からの要求を基にデータベース102の検索を行う。
イベント制御装置120は、データベース管理装置110からのイベント通知により、各配信先システム103への配信情報を取得し、配信状況を確認する機能を持つ。イベント制御装置120は、イベント受信部121、整合性検索要求部122(検索要求部の一例)、データ送信部123、配信管理部124を有する。
イベント受信部121は、イベント通知部114からのイベント情報を受け付ける機能を持つ。
整合性検索要求部122は、配信先情報管理表(イベント種別ごとに、データの配信先、配信項目、検索順序等を定めたテーブル)を基に、配信先システム103への情報配信内容に整合性が取れるようにデータベース102に対し検索要求を出す機能を有する。
データ送信部123は、検索されたデータを配信先情報管理表により指定された送信先へ送信する。
配信管理部124は、イベント受信部121で受け付けたイベント番号を登録する機能と、登録されたイベント番号の配信状況を監視する機能を持つ。
図2は、情報配信システム100のハードウェア構成の一例を示す図である。
図2において、情報配信システム100は、コンピュータであり、LCD901(Liquid・Crystal・Display)、キーボード902(K/B)、マウス903、FDD904(Flexible・Disk・Drive)、CDD905(Compact・Disc・Drive)、プリンタ906といったハードウェアデバイスを備えている。これらのハードウェアデバイスはケーブルや信号線で接続されている。LCD901の代わりに、CRT(Cathode・Ray・Tube)、あるいは、その他の表示装置が用いられてもよい。マウス903の代わりに、タッチパネル、タッチパッド、トラックボール、ペンタブレット、あるいは、その他のポインティングデバイスが用いられてもよい。
なお、情報配信システム100のうち、データベース管理装置110とイベント制御装置120とが別々のコンピュータとして実現されていても構わない。
情報配信システム100は、プログラムを実行するCPU911(Central・Processing・Unit)を備えている。CPU911は、処理装置の一例である。CPU911は、バス912を介してROM913(Read・Only・Memory)、RAM914(Random・Access・Memory)、通信ボード915、LCD901、キーボード902、マウス903、FDD904、CDD905、プリンタ906、HDD920(Hard・Disk・Drive)と接続され、これらのハードウェアデバイスを制御する。HDD920の代わりに、フラッシュメモリ、光ディスク装置、メモリカードリーダライタ、あるいは、その他の記録媒体が用いられてもよい。
RAM914は、揮発性メモリの一例である。ROM913、FDD904、CDD905、HDD920は、不揮発性メモリの一例である。これらは、記憶装置の一例である。通信ボード915、キーボード902、マウス903、FDD904、CDD905は、入力装置の一例である。また、通信ボード915、LCD901、プリンタ906は、出力装置の一例である。
通信ボード915は、LAN(Local・Area・Network)等に接続されている。通信ボード915は、LANに限らず、IP−VPN(Internet・Protocol・Virtual・Private・Network)、広域LAN、ATM(Asynchronous・Transfer・Mode)ネットワークといったWAN(Wide・Area・Network)、あるいは、インターネットに接続されていても構わない。LAN、WAN、インターネットは、ネットワークの一例である。
HDD920には、オペレーティングシステム921(OS)、ウィンドウシステム922、プログラム群923、ファイル群924が記憶されている。プログラム群923のプログラムは、CPU911、オペレーティングシステム921、ウィンドウシステム922により実行される。プログラム群923には、本実施の形態の説明において「〜部」として説明する機能を実行するプログラムが含まれている。プログラムは、CPU911により読み出され実行される。ファイル群924には、本実施の形態の説明において、「〜データ」、「〜情報」、「〜ID(識別子)」、「〜フラグ」、「〜結果」として説明するデータや情報や信号値や変数値やパラメータが、「〜ファイル」や「〜データベース」や「〜テーブル」の各項目として含まれている。「〜ファイル」や「〜データベース」や「〜テーブル」は、RAM914やHDD920等の記録媒体に記憶される。RAM914やHDD920等の記録媒体に記憶されたデータや情報や信号値や変数値やパラメータは、読み書き回路を介してCPU911によりメインメモリやキャッシュメモリに読み出され、抽出、検索、参照、比較、演算、計算、制御、出力、印刷、表示といったCPU911の処理(動作)に用いられる。抽出、検索、参照、比較、演算、計算、制御、出力、印刷、表示といったCPU911の処理中、データや情報や信号値や変数値やパラメータは、メインメモリやキャッシュメモリやバッファメモリに一時的に記憶される。
本実施の形態の説明において用いるブロック図やフローチャートの矢印の部分は主としてデータや信号の入出力を示す。データや信号は、RAM914等のメモリ、FDD904のフレキシブルディスク(FD)、CDD905のコンパクトディスク(CD)、HDD920の磁気ディスク、光ディスク、DVD(Digital・Versatile・Disc)、あるいは、その他の記録媒体に記録される。また、データや信号は、バス912、信号線、ケーブル、あるいは、その他の伝送媒体により伝送される。
本実施の形態の説明において「〜部」として説明するものは、「〜回路」、「〜装置」、「〜機器」であってもよく、また、「〜ステップ」、「〜工程」、「〜手順」、「〜処理」であってもよい。即ち、「〜部」として説明するものは、ROM913に記憶されたファームウェアで実現されていても構わない。あるいは、「〜部」として説明するものは、ソフトウェアのみ、あるいは、素子、デバイス、基板、配線といったハードウェアのみで実現されていても構わない。あるいは、「〜部」として説明するものは、ソフトウェアとハードウェアとの組み合わせ、あるいは、ソフトウェアとハードウェアとファームウェアとの組み合わせで実現されていても構わない。ファームウェアとソフトウェアは、プログラムとして、フレキシブルディスク、コンパクトディスク、磁気ディスク、光ディスク、DVD等の記録媒体に記憶される。プログラムはCPU911により読み出され、CPU911により実行される。即ち、プログラムは、本実施の形態の説明で述べる「〜部」としてコンピュータを機能させるものである。あるいは、プログラムは、本実施の形態の説明で述べる「〜部」の手順や方法をコンピュータに実行させるものである。
図3は、情報配信システム100の動作(本実施の形態に係る情報配信方法(データベース管理方法を含む))を示すフローチャートである。以下、情報配信システム100の動作について図3を用いて説明する。
ここで、データベース102は、個人情報、組織情報、配属情報といったデータ群を記憶する。一例として、データベース102は、個人情報として、企業の従業員等である個人1、個人2、・・・の名前、年齢、住所、電話番号等を、個人を一意に識別する個人ID(識別子)ごとに記憶する。また、データベース102は、組織情報として、企業の部署等である組織1、組織2、・・・の名称、所在地、電話番号等を、組織を一意に識別する組織IDごとに記憶する。また、データベース102は、配属情報として、個人1、個人2、・・・が組織1、組織2、・・・のいずれに配属されているかを示す配属1、配属2、・・・を記憶する。
また、データベース102は、データ群に含まれるデータごとに、データの内容が変更される度に割り当てられる世代番号と、内容が変更されたデータとを対応付けて記憶する。例えば、新たなデータがデータベース102に登録される際には、世代番号として世代1が割り当てられ、そのデータと対応付けてデータベース102に記憶される。それ以降、データが更新される度に、最後に割り当てられた世代番号を1つインクリメントした世代番号が割り当てられ、更新されたデータと対応付けてデータベース102に記憶される。例えば、登録後、データが初めて更新された場合、世代番号として世代2が割り当てられ、更新されたデータと対応付けてデータベース102に記憶される。つまり、このとき、登録時のデータと世代1との組み合わせ、及び、更新されたデータと世代2との組み合わせがデータベース102に記憶されることになる。なお、更新されたデータ全体ではなく、変更された内容のみと世代2との組み合わせがデータベース102に記憶されてもよい。この場合、ある世代のデータを取得したいときは、その世代以前のデータの変更履歴を辿ってデータを復元する必要があるが、データベース102に記憶するデータ量の増大を抑制することができる。
図4は、クライアントシステム101から要求される操作内容131、データ操作の種類(データ操作内容)やデータの種類とイベント種別の対応を示したイベント種別対応表132,132aの例を示す図である。図5は、操作受付部111からイベント番号付加部112へ流れるデータ133、イベント番号付加部112からデータ操作部113へ流れるデータ134の例を示す図である。
まず、ステップS101において、クライアントシステム101は、データベース102に記憶されたデータ群に含まれる複数のデータの内容を変更する操作を行う。具体的には、クライアントシステム101は、データベース102への整合性の取れた(依存関係のある)データの操作要求をデータベース管理装置110の操作受付部111へ出す。この際、操作内容131(図4参照)としては、データベース102へのレコードの追加(新規登録)、削除、更新、検索、参照等の操作が考えられるが、本実施の形態では、複数のレコードの追加、削除、更新といった操作が対象となる。
一例として、クライアントシステム101は、配属1のレコード(配属情報)(第1のデータの一例)と、データベース102において配属1のレコードから参照される個人1のレコード(個人情報)及び組織1のレコード(組織情報)(いずれも第2のデータの例)とを更新する操作(例えば、個人1の年齢、組織1の名称、個人1の配属先の変更)を行う。本実施の形態は、このような参照整合性(参照制約)が要求される(即ち、依存関係にある)データの内容を変更する場合に、特に効果を奏する。なお、例えばデータベース102が関係データベースではなく、階層型データベースであれば、本実施の形態は、存在整合性(存在制約)が要求されるデータの内容を変更する場合に、特に効果を奏する。
ステップS102において、操作受付部111は、クライアントシステム101による操作を入力装置によりイベントとして受け付ける。具体的には、操作受付部111は、クライアントシステム101からの要求を受け付け、イベント種別対応表132(図4参照)からイベント種別を決定し、イベント番号付加部112へイベント種別とデータ内容等を含むデータ133(図5参照)を通知する。このとき、操作受付部111は、依頼元(クライアントシステム101)ごとに設定されるイベント種別対応表132a(図4参照)を利用しても構わない。そして、操作受付部111は、補足情報として、どのクライアントシステム101から依頼を受けたのかという依頼元情報や、その他の情報を付加したデータ133を通知しても構わない。
一例として、操作受付部111は、記憶装置に予め記憶されたイベント種別対応表132を参照して、個人情報、組織情報、配属情報を更新する操作に対応するイベント種別が一括更新であると判断し、この操作を1つのイベントとして受け付ける。そして、操作受付部111は、イベント種別として一括更新を示し、データ内容として個人1のレコード、組織1のレコード、配属1のレコードの更新内容(例えば、個人1の年齢、組織1の名称、個人1の配属先)を含むデータ133をイベント番号付加部112に渡す。
ステップS103において、イベント番号付加部112は、操作受付部111で受け付けられたイベントに対して一意のイベント番号を処理装置により割り当てる。具体的には、まず、イベント番号付加部112では、操作受付部111より受信したデータ133のまとまりに対して、共通の番号(イベント番号)を付加する。このイベント番号は、全ての操作要求に対して連番をつけることが基本であるが、図4のイベント種別対応表132aの依頼元名のように、クライアントシステム101の種別や操作内容ごとに「クライアント1−1」、「データ削除−1」のような形式で割り当てることも可能である。イベント番号としては、番号以外にも記号や漢字等の文字も、イベント番号間で重複するものがなければ、割り当てることが可能である。共通のイベント番号を付加する対象は、データベース102にコミットする単位、即ちデータ間に整合性の取れている範囲とする。なお、データ1件で整合性が取れている場合(例えば、既存の個人の新たな配属先として既存の組織を指定する場合)は、1件の単位でイベント番号を付加することも可能である。次に、イベント番号付加部112は、イベント番号を付加したデータ134(図5参照)をデータ操作部113へ送付する。
一例として、イベント番号付加部112は、操作受付部111で受け付けられたイベントに対してイベント番号「1」を処理装置により割り当てる。そして、イベント番号付加部112は、イベント番号として「1」を示し、データ内容として個人1のレコード、組織1のレコード、配属1のレコードの更新内容(例えば、個人1の年齢、組織1の名称、個人1の配属先)を含むデータ134をデータ操作部113に渡す。
図6は、データベース102で保持される配属情報のテーブル135,135aの例を示す図である。図7は、イベント番号と対象レコード(データ識別子の一例)と世代番号の対応を示した世代管理テーブル136(世代管理部の一例)、イベント番号付加部112からイベント通知部114へ通知されるデータ137の例を示す図である。
データベース102で保持される配属情報のテーブル135(図6参照)では、個人1、個人2、・・・の1件1件のユーザに対し、更新があった際に、更新履歴を世代として記録しておく。なお、配属情報の全体において1件のユーザ(1人の個人)でも更新があった場合、世代が変わったとする管理方式でテーブル135a(図6参照)を構成しても構わない。
ステップS104において、データ操作部113は、操作受付部111で受け付けられたイベントに基づいてデータベース102に記憶された複数のデータの内容を変更する。そして、データ操作部113は、内容を変更したデータごとに、新たな世代番号を処理装置により割り当ててデータベース102に記憶させる。具体的には、データ操作部113は、イベント番号付加部112から受信したデータ134を基に、データベース102に対して操作を行う。データベース102の操作の際は、操作内容の結果のみをデータベース102として登録するのではなく、更新後の情報とともに、更新前の情報の履歴を世代としてデータベース102に保存する。世代の管理単位は、レコード単位(図6のテーブル135)、テーブル単位(図6のテーブル135a)等、システムの状況に合わせ設定することが可能である。なお、ここでは、「レコード」という語を、配属情報のテーブル135に含まれる個人ごとのデータという意味で用いている(個人情報、組織情報についても同様である)。例えば、個人1の配属先が組織1(世代1)から組織2(世代2)に変わり、再び組織1(世代3)に戻ったことを示すデータ全体が1つの「レコード」である。また、ここで「テーブル単位」というとき、「テーブル」という語を、配属情報のテーブル135aに含まれる更新時点ごとのデータという意味で用いている。例えば、個人1の配属先が組織1から組織2に変わった時点における個人1、個人2、・・・のデータ(世代2)全体が1つの「テーブル」であり、個人1の配属先が再び組織1に戻った時点における個人1、個人2、・・・のデータ(世代3)全体が1つの「テーブル」である。
一例として、データ操作部113は、データベース102に記憶された個人1のレコード、組織1のレコード、配属1のレコードを更新する(例えば、個人1の年齢、組織1の名称、個人1の配属先を更新する)。そして、データ操作部113は、更新後の個人1のレコード、更新後の組織1のレコード、更新後の配属1のレコードのそれぞれに対して、新たな世代番号を処理装置により割り当ててデータベース102に記憶させる(例えば、個人1の配属先が組織1になったことを示すデータを、世代3に対応付けて配属情報のテーブル135に記憶させる)。
次に、世代管理テーブル136(図7参照)は、イベント番号付加部112で割り当てられたイベント番号と、データ操作部113で内容が変更された複数のデータを各々識別する複数のデータ識別子と、データ操作部113で当該複数のデータに各々割り当てられた複数の世代番号とを対応付けて記憶装置により記憶する。具体的には、データ操作部113は、データそのものの登録だけでなく、世代管理テーブル136に、あるイベント番号の操作によって、どのレコードのどの世代を配信対象とすればよいのかを登録する。このように、世代管理テーブル136には、入手したイベント番号に対し、どの配信対象のどの世代のレコードを配信すべきかが記載される。
一例として、世代管理テーブル136は、イベント番号「1」と、個人1のレコードを識別するデータ識別子と、更新された個人1のレコードに割り当てられた世代2とを対応付けて記憶する。また、世代管理テーブル136は、イベント番号「1」と、組織1のレコードを識別するデータ識別子と、更新された組織1のレコードに割り当てられた世代2とを対応付けて記憶する。また、世代管理テーブル136は、イベント番号「1」と、配属1(個人1の配属先)のレコードを識別するデータ識別子と、更新された配属1のレコードに割り当てられた世代3とを対応付けて記憶する。
ステップS105において、イベント通知部114は、イベント番号付加部112で割り当てられたイベント番号を出力装置により出力する。具体的には、イベント番号付加部112は、データベース102へのデータのコミットが行われた後に、イベント通知部114へイベント通知を要求するデータ137(図7参照)を出す。その後、イベント通知部114は、イベント制御装置120のイベント受信部121へイベントを(例えば、図7のデータ137と同様の形式で)通知する。
一例として、イベント通知部114は、イベント番号として「1」を示し、イベント種別として一括更新を示すイベント情報(データ137と同様)をイベント受信部121に渡す。
図8は、イベント種別と、配信先、プロトコル(形式)、配信する内容(配信項目1,2,・・・)、検索順序との対応を示した配信先情報管理表141、イベント受信部121から配信管理部124へ流れるデータ142の例を示す図である。
ステップS106において、イベント受信部121は、イベント通知部114から出力されたイベント番号を受信する。具体的には、イベント受信部121は、イベント通知部114からイベント情報(データ137と同様)を受信した後、配信管理部124にイベント番号及びイベント種別を含むデータ142(図8参照)を送信し、配信が開始されることを通知する。このとき、イベント受信部121は、予めどの配信先へ配信が行われるかを配信先情報管理表141(図8参照)により抽出し、イベント番号、配信先、イベント種別の組み合わせを通知してもよい。また、イベント番号、配信先、イベント種別の組み合わせに対し番号を割り当ててもよい。イベント受信部121は、整合性検索要求部122、データ送信部123に対し、イベント種別を基に配信先情報管理表141で示された配信先へ配信する情報(配信項目等)を取得し、配信するように要求する。このとき、イベント受信部121は、イベント番号と配信先の情報及び配信先に適用される検索ルールを用いるように要求する。
図9は、イベント番号とそのイベント番号の配信の結果との対応を示した配信履歴テーブル143,143a、整合性検索要求部122からデータ送信部123へ流れるデータ144、配信先システム103へと配信される配信情報145の例を示す図である。
ステップS107において、配信管理部124は、イベント受信部121で受信されたイベント番号を記憶装置により記憶する。具体的には、配信管理部124は、配信履歴テーブル143(図9参照)に、イベント番号とイベント種別の情報を登録する。なお、配信管理部124は、配信先情報や配信番号等の情報を追加した配信履歴テーブル143a(図9参照)を管理してもよいし、確実にリカバリ配信を実現できるのであれば(配信先が1つのみの場合等)、イベント番号のみを配信履歴テーブル143に記録してもよい。
ステップS108において、整合性検索要求部122は、イベント受信部121で受信されたイベント番号をデータベース管理装置110のデータセット検索部115に入力する。具体的には、整合性検索要求部122は、イベントを受け付けた際に、配信先情報管理表141を基にして、該当する検索順序及び配信項目で検索するようデータセット検索部115に要求する。なお、データセット検索部115への要求は、検索順序の1番目から1つずつ順番に行ってもよいし(この場合、検索順序を通知しなくてよい)、一括で行ってもよい(この場合、検索順序を通知しなければならない)。なお、検索順序とは、各配信先システム103において、その順序でデータが登録、更新、削除等されなければ、データの整合性が取れなくなる等の問題が生じるものをいう。
ステップS109〜S111において、データセット検索部115は、イベント通知部114から出力されたイベント番号が入力されると、入力されたイベント番号に対応する複数のデータ識別子と複数の世代番号とを世代管理テーブル136から取得する。そして、データセット検索部115は、データベース102を検索して、世代管理テーブル136から取得した複数のデータ識別子の各々に対応するデータの内容のうち、世代管理テーブル136から取得した複数の世代番号の各々に対応する内容を取得する。具体的には、データセット検索部115は、ステップS109で要求を受け付け、ステップS110で要求に見合う形でデータベース102の検索を行う。この際に、世代管理テーブル136を参照し、取得したイベント番号の対象となる世代のレコードから情報を取得する。データセット検索部115は、ステップS111で検索結果を、イベント制御装置120の整合性検索要求部122に通知する。
一例として、データセット検索部115は、イベント番号「1」に対応するデータ識別子と世代番号との組み合わせとして、個人1のレコードを識別するデータ識別子と世代2との組み合わせ、組織1のレコードを識別するデータ識別子と世代2との組み合わせ、配属1(個人1の配属先)のレコードを識別するデータ識別子と世代3との組み合わせを、世代管理テーブル136から取得する。そして、データセット検索部115は、データベース102を検索して、世代2の個人1のレコード、世代2の組織1のレコード、世代3の配属1のレコードを取得する。このとき、データセット検索部115は、データベース102を、整合性検索要求部122から指定された検索順序で検索して、レコードを取得する度に、取得したレコードを即時に整合性検索要求部122へ返信する。例えば、データセット検索部115は、世代2の個人1のレコード、世代2の組織1のレコード、世代3の配属1のレコードを、順番に1つずつ取得するのと同時に整合性検索要求部122へ送信する。これにより、リアルタイム(即ち、高速な)配信を可能とする。
ステップS112において、整合性検索要求部122は、データベース102に記憶された複数のデータの内容のうち、データセット検索部115で取得された内容を受信する。具体的には、整合性検索要求部122は、検索結果を受信しデータ送信部123へ配信対象となるデータ内容とイベント番号を含むデータ144(図9参照)を通知する。このとき、整合性検索要求部122は、検索結果を受信する度に、そのデータ内容を含むデータ144を即時にデータ送信部123に渡す。これにより、リアルタイム(即ち、高速な)配信を可能とする。
ステップS113において、データ送信部123は、整合性検索要求部122で受信された内容を複数の配信先システム103へ配信する。具体的には、データ送信部123は、受け付けたデータを、配信先情報管理表141の配信先を基に、該当する配信先システム103へと整合性の取れた配信情報145(図9参照)に変換した上で配信する。この際に、データ送信部123は、配信先の通信プロトコルに合わせてデータを変換する。また、このとき、データ送信部123は、整合性検索要求部122で受信された内容を、整合性検索要求部122から受け取る度に、即時に配信する。即ち、データ送信部123は、整合性検索要求部122で受信された内容を、データベース102に記憶された複数のデータ間で予め定められた順序で配信する。これにより、リアルタイム(即ち、高速な)配信を可能とする。
ステップS114において、配信先システム103は、配信情報145を受信し、自身のシステムへ反映させる。前述したように、配信先の形態は、データベース、データ受信とともにメールを送信するようなメールサーバ、データ受信後に任意ファイルを操作するようなシステム等、どのようなものでもよい。
ステップS115において、データ送信部123は、配信先システム103への配信結果(「配信成功」/「配信失敗」/「配信一部失敗」/「通信不可」等)を、配信管理部124に通知し、配信管理部124は配信結果を配信履歴テーブル143へ記入する。
図10は、情報配信システム100による再配信の動作を示すフローチャートである。以下、配信に失敗したイベントに対する再配信の動作について図10を用いて説明する。
ステップS120〜S122において、配信管理部124は、記憶装置により記憶したイベント番号に対応する複数のデータの内容が正常に配信されたかどうかを処理装置により判定する。具体的には、ステップS120で、配信管理部124は、配信履歴テーブル143の中から、配信結果が「配信失敗」又は一定時間以上「配信中」となっている等、配信が成功になっていないイベント番号及び配信先の組み合わせの配信があるかどうかを検索する。なお、リカバリを実行するタイミングは、ステップS115で配信に失敗した直後でもよいし、決まった時間に自動起動してもよいし、外部からの要求を受け付けたタイミングでもよい。ステップS121で、配信管理部124は、上記検索の結果に基づき、再配信する必要のある配信情報145があるか判定する。配信対象が存在した場合、ステップS122において、配信管理部124は、整合性検索要求部122に対し、イベント番号を通知する。
この後の具体的な動作は、ステップS108〜S115と同様である。つまり、配信管理部124(配信履歴テーブル143)に記憶されたイベント番号に対応する複数のデータの内容が複数の配信先システム103のいずれかへ正常に配信されなかったと配信管理部124で判定された場合、整合性検索要求部122は、当該イベント番号をデータベース管理装置110のデータセット検索部115に再び入力する。そして、整合性検索要求部122は、データベース102に記憶された複数のデータの内容のうち、データセット検索部115で取得された内容を再び受信する。データ送信部123は、整合性検索要求部122で再び受信された内容を、当該内容が正常に配信されなかったと配信管理部124で判定された配信先システム103へ配信する。
以上のように、本実施の形態によれば、データベース102内で依存関係のあるデータが更新された場合、その更新後のデータをいつでも確実に整合性の取れたデータとして提供することが可能となる。また、複数のクライアントシステム101からのデータベース102の操作要求の受付と、各配信先システム103への情報配信をデータベース102にロックをかけずに並行して実行することができる。また、依存関係のあるデータ群を投入した場合でも、データベース102の世代管理を行うことにより、整合性を保ったまま各配信先システム103への配信を行える。つまり、本実施の形態では、データベース102を世代管理し、世代番号と配信のイベント番号を対応させることにより、クライアントシステム101から受け付けた整合性のあるデータ操作要求に対し、データベース102の操作の実行、及び、操作結果に対し整合性を保った状態での各配信先システム103への配信が可能である。
以上説明したように、本実施の形態に係る情報配信システム100は、データそのものだけでなくデータ変更の履歴情報を登録したデータベース102と、データベース102へのコミットのタイミングで番号をデータに割り振るイベント番号付加部112と、データベース102に登録内容と内容に対応した世代番号を登録するデータ操作部113と、イベント番号に対応した世代のデータを検索するデータセット検索部115と、配信するデータセットに配信すべき順序が存在する場合にその順序どおりに検索を実行するよう要求する整合性検索要求部122と、配信に失敗したイベント番号を基に再配信の要求を行う配信管理部124とを兼ね備える。
このように、本実施の形態では、データ更新要求がクライアントシステム101から来たタイミングで単純に番号を割り当てるのではなく、データベース102へコミットする単位で共通のイベント番号を付加する。なお、前述したように、番号付けも全受付を対象にして連番にさせる必要はなく、クライアントの種別や操作内容等によってイベント番号の割り付けを変更させることも可能である。
その後、実際に付加されたイベント番号に紐付けられたデータをデータベース102に投入する際に、データの履歴情報(世代)も同時に登録する。
単純にイベント番号を付加するだけでは、配信最中のデータに対して更新が行われた際に、配信先システム103で受け取るデータの整合性が保障されない。一方、本実施の形態の手法では、配信中にデータの更新が行われたとしても、配信途中のデータに関しては更新前の世代のデータを配信し、その後、改めて更新後のデータを配信することで、最終的に配信されるデータの整合性を保つことが可能である。
また、従来のように、配信すべき対象があるかどうかを、配信を行うシステムがデータベース102やデータベース102の更新情報が記載された場所に都度確認を取りにいくのでは、リアルタイム配信を実現できない。本実施の形態では、更新内容の配信先システム103への配信のトリガをイベント通知にすることで、リアルタイム性を保障する。
また、付加したイベント番号と配信先システム103について配信結果の管理を行うことで、無駄のないリカバリ配信が可能となる。
実施の形態2.
本実施の形態について、主に実施の形態1との差異を説明する。
図11は、本実施の形態に係る情報配信システム100の構成を示すブロック図である。
図11において、イベント制御装置120は、イベント受信部121、整合性検索要求部122、データ送信部123の組み合わせ、即ち、配信ルート221を複数有する。配信ルート221は、配信先システム103、配信するデータの種類等に応じて使い分けられる。図11では、複数の配信ルート221を配信ルート1、・・・、配信ルートnとして表している。また、必須ではないが、データベース管理装置110は、操作受付部111を複数有する。図11では、複数の操作受付部111を操作受付部1、・・・、操作受付部nとして表している。
このように、本実施の形態において、情報配信システム100は、実施の形態1と異なり、操作受付部111、配信ルート221が複数となる構成となる。
データベース管理装置110の操作受付部111は、クライアントシステム101からのデータベース102の操作要求を受け付け、要求元のクライアントシステム101と操作内容だけでなく、受付URL(Uniform・Resource・Locator)によりイベント種別(例えば、依存関係のあるデータの一括登録、一括更新、一括削除)を判断する。操作受付部111は、それぞれ予め設定された受付URLに対応する受信口を持っており、この受付URLはデータ操作内容及びデータの種類によって定まる個数だけ存在する。
データベース管理装置110のイベント通知部114は、イベント番号付加部112より送信されたイベント情報を基に、複数ある配信ルート221のうちどの配信ルート221に対しイベント番号を送付するのかを判定し、対象となる配信ルート221へ、イベント番号を送付する機能を持つ。
以下、情報配信システム100の動作について図3を用いて説明する。
図12は、依頼元のクライアントシステム101(依頼元名)と受付URLとの組み合わせごとに、データ操作の種類(データ操作内容)やデータの種類とイベント種別との対応を示したイベント種別対応表132b、配信ルート221ごとに、イベント種別と、配信先、プロトコル(形式)、配信する内容(配信項目1,2,・・・)、検索順序との対応を示した配信先情報管理表141aの例を示す図である。
ステップS101において、クライアントシステム101は、データベース102への整合性の取れた(依存関係のある)データの操作要求をデータベース管理装置110の操作受付部111のいずれかへ出す。この際、操作内容131(図4参照)としては、データベース102へのレコードの追加(新規登録)、削除、更新、検索、参照等の操作が考えられるが、本実施の形態でも、実施の形態1と同様に、複数のレコードの追加、削除、更新といった操作が対象となる。クライアントシステム101は、どの受付URLへ要求を送信するのかを、データベース102の操作内容や操作するデータの種類により決定する。なお、操作受付部111の数、及び、それぞれの操作受付部111が持つ受付URLの数は、データ操作内容、データの種類、クライアントシステム101の種別等により任意に決めることができる。
ステップS102において、操作受付部111は、クライアントシステム101からの要求を受け付け、イベント種別対応表132b(図12参照)からイベント種別を決定し、イベント番号付加部112へイベント種別とデータ内容等を含むデータ133(図5参照)を通知する。このとき、操作受付部111は、補足情報として、どのクライアントシステム101から依頼を受けたのかという依頼元情報や、その他の情報を付加したデータ133を通知しても構わない。
ステップS103において、まず、イベント番号付加部112では、操作受付部111より受信したデータ133のまとまりに対して、共通の番号(イベント番号)を付加する。このイベント番号は、全ての操作要求に対して連番をつけることが基本であるが、図12のイベント種別対応表132bの依頼元名のように、クライアントシステム101の種別や操作内容ごとに「クライアント1−1」、「データ削除−1」のような形式で割り当てることも可能である。イベント番号としては、番号以外にも記号や漢字等の文字も、イベント番号間で重複するものがなければ、割り当てることが可能である。共通のイベント番号を付加する対象は、データベース102にコミットする単位、即ちデータ間に整合性の取れている範囲とする。なお、データ1件で整合性が取れている場合(例えば、既存の個人の新たな配属先として既存の組織を指定する場合)は、1件の単位でイベント番号を付加することも可能である。次に、イベント番号付加部112は、イベント番号を付加したデータ134(図5参照)をデータ操作部113へ送付する。
ステップS104において、データ操作部113は、イベント番号付加部112から受信したデータ134を基に、データベース102に対して操作を行う。データベース102の操作の際は、操作内容の結果のみをデータベース102として登録するのではなく、更新後の情報とともに、更新前の情報の履歴を世代としてデータベース102に保存する。次に、データ操作部113は、データそのものの登録だけでなく、世代管理テーブル136(図7参照)に、あるイベント番号の操作によって、どのレコードのどの世代を配信対象とすればよいのかを登録する。
ステップS105において、イベント番号付加部112は、データベース102へのデータのコミットが行われた後に、イベント通知部114へイベント通知を要求するデータ137(図7参照)を出す。その後、イベント通知部114は、イベント種別の情報を基にして、配信先情報管理表141a(図12参照)より、イベント制御装置120のどの配信ルート221へイベントを通知するのかを決定し、通知すべき配信ルート221全てのイベント受信部121へイベントを(例えば、図7のデータ137と同様の形式で)通知する。
ステップS106において、イベント受信部121は、イベント通知部114からイベント情報(データ137と同様)を受信した後、配信管理部124にイベント番号及びイベント種別を含むデータ142(図8参照)を送信し、配信が開始されることを通知する。また、イベント受信部121は、整合性検索要求部122、データ送信部123に対し、イベント種別を基に配信先情報管理表141aで示された配信先へ配信する情報(配信項目等)を取得し、配信するように要求する。このとき、イベント受信部121は、イベント番号と配信先の情報及び配信先に適用される検索ルールを用いるように要求する。
ステップS107において、配信管理部124は、配信履歴テーブル143(図9参照)に、イベント番号とイベント種別の情報を登録する。このとき、配信管理部124は、配信履歴テーブル143に、さらに、どの配信ルート221でイベントを受け付けたか等の情報を登録することが望ましい。なお、配信管理部124は、確実にリカバリ配信を実現できるのであれば(配信先が1つのみの場合等)、イベント番号のみを配信履歴テーブル143に記録したり、イベント番号と配信ルート221に関する情報のみを配信履歴テーブル143に記録してもよい。
ステップS108において、整合性検索要求部122は、イベントを受け付けた際に、配信先情報管理表141aを基にして、自身の所属する配信ルート221に対応する検索順序及び配信項目で検索するようデータセット検索部115に要求する。なお、データセット検索部115への要求は、検索順序の1番目から1つずつ順番に行ってもよいし(この場合、検索順序を通知しなくてよい)、一括で行ってもよい(この場合、検索順序を通知しなければならない)。
データセット検索部115は、ステップS109で要求を受け付け、ステップS110で要求に見合う形でデータベース102の検索を行う。この際に、世代管理テーブル136を参照し、取得したイベント番号の対象となる世代のレコードから情報を取得する。データセット検索部115は、ステップS111で検索結果を、イベント制御装置120の整合性検索要求部122に通知する。
ステップS112において、整合性検索要求部122は、検索結果を受信しデータ送信部123へ配信対象となるデータ内容とイベント番号を含むデータ144(図9参照)を通知する。
ステップS113において、データ送信部123は、受け付けたデータを、配信先情報管理表141aの配信先を基に、該当する配信先システム103へと整合性の取れた配信情報145(図9参照)に変換した上で配信する。この際に、データ送信部123は、配信先の通信プロトコルに合わせてデータを変換する。
ステップS114において、配信先システム103は、配信情報145を受信し、自身のシステムへ反映させる。前述したように、配信先の形態は、データベース、データ受信とともにメールを送信するようなメールサーバ、データ受信後に任意ファイルを操作するようなシステム等、どのようなものでもよい。
ステップS115において、データ送信部123は、配信先システム103への配信結果(「配信成功」/「配信失敗」/「配信一部失敗」/「通信不可」等)を、配信管理部124に通知し、配信管理部124は配信結果を配信履歴テーブル143へ記入する。
以下、配信に失敗したイベントに対する再配信の動作について図10を用いて説明する。
ステップS120で、配信管理部124は、配信履歴テーブル143の中から、配信結果が「配信失敗」又は一定時間以上「配信中」となっている等、配信が成功になっていないイベント番号及び配信先の組み合わせの配信があるかどうかを検索する。なお、リカバリを実行するタイミングは、ステップS115で配信に失敗した直後でもよいし、決まった時間に自動起動してもよいし、外部からの要求を受け付けたタイミングでもよい。ステップS121で、配信管理部124は、上記検索の結果に基づき、再配信する必要のある配信情報145があるか判定する。配信対象が存在した場合、ステップS122において、配信管理部124は、整合性検索要求部122に対し、イベント番号を通知する。
この後の具体的な動作は、ステップS108〜S115と同様である。
以上のように、本実施の形態では、各配信先システム103への配信処理をパラレルに実行することが可能なので、配信の待ち時間が減少し、より即時性の高い配信が実現される。
配信用のルートが1本しか存在しないのでは、配信先システム103の数が多くなるにつれ、各配信先システム103間でのデータ受領のタイミングの差が大きくなってしまう。上記のように、本実施の形態では、配信ルート221を複数用意することによって、各配信先システム103への配信処理をパラレルに実行することが可能なので、配信の待ち時間が減少される。
実施の形態3.
本実施の形態について、主に実施の形態2との差異を説明する。
図13は、本実施の形態に係る情報配信システム100の構成を示すブロック図である。
本実施の形態では、実施の形態2と異なり、イベント制御装置120が配信先システム103へデータを配信するのではなく、イベント制御装置120は配信先システム103へイベント番号のみを通知し、配信先システム103がイベント番号を基にデータベース管理装置110に情報を要求する。
図14は、情報配信システム100の動作(本実施の形態に係る情報配信方法(データベース管理方法を含む))を示すフローチャートである。以下、情報配信システム100の動作について図14を用いて説明する。
ステップS301〜S310については、実施の形態2のステップS101〜S110と同様である。
ステップS311において、データセット検索部115は、ステップS310でデータベース102の検索を行った結果を、イベント制御装置120の整合性検索要求部122に通知する代わりに、記憶装置により保持しておく。データセット検索部115は、整合性検索要求部122には、検索が完了したことのみを通知する。
ステップS312において、整合性検索要求部122は、検索完了の通知を受け、データ送信部123へイベント番号を送信する。データ送信部123は、配信先システム103へイベント番号を送信する。
ステップS313において、配信先システム103は、イベント番号を取得する。ステップS314において、配信先システム103は、データベース管理装置110のデータセット検索部115にイベント番号を通知してデータを要求する。
ステップS315において、データセット検索部115は、要求を受け付ける。ステップS316において、データセット検索部115は、保持していた検索結果を配信先システム103へ配信する。
ステップS317において、配信先システム103は、データを取得する。ステップS318において、配信先システム103は、配信結果をイベント制御装置120のデータ送信部123へ返す。
ステップS319において、データ送信部123は、配信管理部124へ配信結果を通知する。
本実施の形態では、リカバリについても、実際のリカバリ対象のデータをイベント制御装置120に通すのではなく、配信先システム103が直接データベース管理装置110のデータセット検索部115とやり取りすることにより実現される。
以上により、データベース管理装置110、イベント制御装置120が複数のサーバで構成されている場合、必要以上のサーバ間データの受け渡し量を削減することが可能となり、サーバシステムの負荷を減らすことが可能となる。
配信すべきデータ量が多くなった場合、システムのサーバ内で配信情報の受け渡しをすると、システム中を流れるデータ量が多くなりサーバに負荷がかかる。そこで、本実施の形態では、配信先システム103には更新が行われたことのみを通知し、データの取得は配信先システム103がデータベース管理装置110に要求することで、サーバへの負荷を減らすことが可能となる。
実施の形態4.
本実施の形態について、主に実施の形態2との差異を説明する。
図15は、本実施の形態に係る情報配信システム100の構成を示すブロック図である。
本実施の形態では、リカバリ配信を行う際に、配信失敗となった配信ルート221に再配信要求を出すのではなく、情報配信システム100が別に持つ再配信用の配信ルートであるリカバリ配信ルート451に再配信要求を出す。
図15において、リカバリ要求元450は、リカバリ配信ルート451にリカバリ配信を要求する。リカバリ要求元450には、情報配信システム100の管理者、クライアントシステム101(のユーザ)、配信先システム103(のユーザ)等がなり得る。
リカバリ配信ルート451は、リカバリ受付部452のほか、他の配信ルート221と同様の整合性検索要求部122とデータ送信部123とを有する。なお、リカバリ配信ルート451は、リカバリ対象となるイベント種別や配信先システム103ごとに用意することも可能である。
リカバリ受付部452は、リカバリ要求元450からのリカバリ要求を受け付ける。
情報配信システム100の通常の配信動作については、図3に示した実施の形態2のものと同様である。
図16は、情報配信システム100による再配信の動作を示すフローチャートである。以下、配信に失敗したイベントに対する再配信の動作について図16を用いて説明する。
ステップS401において、リカバリ要求元450は、リカバリ配信ルート451のリカバリ受付部452に対しリカバリ配信を要求する。この際、リカバリ受付に対してどの配信ルート221のリカバリを要求するのかをリカバリ要求元450で指定してもよいし、全てのリカバリ対象のリカバリ配信を要求してもよい。
ステップS402において、リカバリ受付部452は、配信管理部124に対してリカバリ対象の検索を要求する。リカバリ受付部452は、外部からのリカバリ要求の受付以外にも、予め指定された時刻や、通常の配信に失敗した直後等も動作してよい。
ステップS403において、配信管理部124は、配信履歴テーブル143aの中で、今回のリカバリ対象となるイベントのうち、配信結果が「配信失敗」又は一定時間以上「配信中」となっている等、配信が成功になっていないイベント番号及び配信先の組み合わせの配信があるかどうかを検索する。ステップS404において、配信管理部124は、上記検索の結果に基づき、再配信する必要のある配信情報145があるか判定する。配信対象が存在した場合、配信管理部124は、整合性検索要求部122に対し、イベント番号を通知する。
この後の具体的な動作及びステップS405〜S411については、実施の形態2のステップS108〜S115と同様である。
上記のように、本実施の形態では、イベント制御装置120が、整合性検索要求部122とデータ送信部123との組み合わせを少なくとも2つ(配信ルート221及びリカバリ配信ルート451)有する。そして、配信管理部124(配信履歴テーブル143)に記憶されたイベント番号に対応する複数のデータの内容が複数の配信先システム103のいずれかへ正常に配信されなかったと配信管理部124で判定された場合と、それ以外の場合(正常に配信ができた場合)とで、使用する整合性検索要求部122とデータ送信部123との組み合わせを切り換える。このように、本実施の形態では、リカバリ配信ルート451を通常の配信ルート221と別に設けることで、通常の配信の邪魔をせずに並行して(通常の配信に影響を与えることなく)リカバリ配信を実現することが可能となる。
以上、本発明の実施の形態について説明したが、これらのうち、2つ以上の実施の形態を組み合わせて実施しても構わない。あるいは、これらのうち、1つの実施の形態を部分的に実施しても構わない。あるいは、これらのうち、2つ以上の実施の形態を部分的に組み合わせて実施しても構わない。