JP2000181861A - アプリケーションサーバ連携装置 - Google Patents

Abstract

(57)【要約】 【課題】アプリケーション間で信頼性のあるデータの共
有を行なうこと、及び、いくつかのアプリケーションが
順番に動くような場合に、次に動くべきアプリケーショ
ンを自動的に起動でき、データのそれぞれのバージョン
において追跡することでその元データの鮮度を知ること
ができるアプリケーションサーバ連携装置を提供するこ
とを目的とする。 【解決手段】ＤＢ１０３内のテーブルにデータ変更が施
されると、通知機構１０６がＤＢ１０３の変化を管理サ
ーバ１０１に通知する。管理サーバ１０１は、管理ファ
イルにより、アプリケーションサーバとそのアプリケー
ションサーバへの入力となるテーブルとの関係を示す情
報を保持している。管理サーバ１０１は、前記通知を受
けて、データ変更されたテーブルを入力としているアプ
リケーションサーバが搭載されたサーバの判断機構１０
９，１１２にそれを通知し、その通知を受けた判断機構
がアプリケーションサーバ１０８，１１１に処理をさせ
る否かを決定し、処理させるときには、処理命令を送
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、複数のアプリケー
ションプログラムを連携して動作させる技術分野に属
し、例えば、ワークフロー用のデータベースあるいはデ
ータウェアハウスの利用技術に関する。

【０００２】

【従来の技術】複数のアプリケーションプログラムの連
携、及びデータベースの利用に関しては、以下の公知例
がある。

【０００３】石井裕著、”グループウェアのデザイ
ン”、共立出版株式会社(1994)の３６頁から４２頁に
は、オフィス手続きモデルとワークフローに関する記述
がある。この技術では、電子メールを用いて、予め決ま
った経路あるいは電子メールの内容で決まる分岐を伴っ
た経路を経て文書が送られる。そこでは必要事項が付加
されて次の担当者に送られる。これを繰り返し、文書を
予め定められた経路で順次送っていきながら所定の業務
を進めていく。これを公知例１と呼ぶ。

【０００４】成田雅彦他著、”ＣＯＲＢＡとＪａｖａ分
散オブジェクト技術”、ソフト・リサーチ・センター(1
997)の８５頁から８６頁には、ＣＯＲＢＡのイベントサ
ービスの記述がある。これは、ＣＯＲＢＡのオブジェク
ト間で非同期に通信を行なう機能を提供するサービスで
ある。オブジェクトが処理中に発生したエラーメッセー
ジの通知や、システム間でのメッセージ伝送などの信頼
性の高い片方向通信を必要とする業務処理などに使用さ
れている。これを公知例２と呼ぶ。

【０００５】Ｊ．セルコ著、”プログラマのためのＳＱ
Ｌ”、トッパン(1996)の９２頁には、データベースにお
けるトリガーという機能の記述がある。このトリガー機
能は、データベースのテーブルに何か起きたときに、デ
ータベースに対して実行される一連の手続きコードのこ
とである。これを公知例３と呼ぶ。

【０００６】

【発明が解決しようとする課題】上記従来の技術には以
下のような課題がある。

【０００７】公知例１では、電子メールを用いているの
で大量データの扱いには向かない。また、一般に電子メ
ールの送受については信頼性が保証されていない。ま
た、電子メールはデータのコピーの送信であるので、シ
ステム全体としてはデータ量が膨張する一方である。各
所に様々なバージョンのデータが散在することになり、
整合がとりづらくなるという問題も内包している。

【０００８】公知例２では、通信の基盤を提供している
だけであり、具体的なアプリケーションプログラムの連
携手法については述べていない。また、公知例３では、
データベースの変化を検出して何かのアクションにつな
げる基盤技術を提供はしているが、その後それを何に使
うかについては規定していない。

【０００９】したがって、本発明の第１の目的は、アプ
リケーション間で信頼性のあるデータの共有を行なうこ
とにある。さらに、データのバージョン管理を行なうア
プリケーションサーバ連携装置を提供することにある。
また、本発明の第２の目的は、アプリケーション間の連
携を管理する手法を確立したアプリケーションサーバ連
携装置を提供することにある。また、本発明の第３の目
的は、データベースの変化の情報をそれぞれのアプリケ
ーションが利用できるアプリケーションサーバ連携装置
を提供することにある。

【００１０】

【課題を解決するための手段】上記課題を解消するた
め、本発明は、データベースを各アプリケーションサー
バが共用し、入出力をそのデータベースに対して行なう
ようにしたものである。また、本発明は、どのアプリケ
ーションサーバがデータベースのどのテーブルを参照す
るかを管理するものである。また、本発明は、データベ
ースのあるテーブルに変化が起こった際に、それを参照
するアプリケーションサーバにその変化を通知するもの
である。また、本発明は、データベースのそれぞれのデ
ータがいつのデータを元データとして作られたものかを
管理するものである。

【００１１】すなわち、本発明は、二つ以上のアプリケ
ーションサーバを連携して動作させるアプリケーション
サーバ連携装置であって、複数のテーブルを含むデータ
ベースと、前記データベースと接続され、これを管理す
るデータベースサーバと、前記データベース内のテーブ
ルに対してアクションが施されたとき、その旨を管理サ
ーバに通知する通知機構と、前記アプリケーションサー
バとそのアプリケーションサーバへの入力となる前記デ
ータベース内のテーブルとの関係を示す情報を保持する
管理ファイルと、前記データベース内のテーブルに対し
てアクションが施された旨を示す通知を前記通知機構か
ら受理し、該アクションがデータの変更であった場合
に、前記管理ファイルに保持されている前記アプリケー
ションサーバと前記テーブルとの関係を示す情報を参照
して、該データ変更があったテーブルを入力とする前記
アプリケーションサーバにそのテーブル変更を通知する
管理サーバとを備えたことを特徴とする。

【００１２】前記管理サーバからのテーブル変更の通知
を受けて、前記アプリケーションサーバに処理を行なわ
せるか否かを判断する判断機構を、さらに備えるように
してもよい。

【００１３】前記判断機構の判断ロジックとしては、
前記管理サーバから前記テーブル変更の通知を受けたと
き、前記アプリケーションサーバに必ず処理を行なわせ
る、あるいは、前記管理サーバから送られてきた前記
テーブル変更の通知の回数と、前記テーブル変更の通知
の日時との二つの情報のうち少なくとも一つを用いて、
前記アプリケーションサーバに処理を行なわせる手法を
採るとよい。

【００１４】前記判断機構をどこに配置するかは任意で
あるが、例えば、各アプリケーションサーバを搭載した
サーバ内にアプリケーションサーバに対応して設けても
よいし、それらの各アプリケーションサーバに対応する
判断機構を１つの判断サーバに設けてもよい。また、各
アプリケーションサーバに対応する判断機構を１つにま
とめてもよい。

【００１５】前記管理ファイルに、前記データベース内
のテーブルに対して施されたアクションの履歴情報を保
持するようにしてもよい。前記通知機構から前記管理サ
ーバに通知する、前記データベース内のテーブルにアク
ションが施された旨の通知内容に、該アクションを行な
ったアプリケーションサーバの名称を含ませるようにし
てもよい。その場合、前記管理サーバは、指定された時
刻における前記データベースの指定されたテーブルに対
して、前記管理ファイルに保持されているアクションの
履歴情報、及び前記アプリケーションサーバと前記デー
タベース内のテーブルとの関係を示す情報を参照して、
該指定されたテーブルを生成するために使われたテーブ
ルの生成日時を抽出する手段をさらに備えてもよい。

【００１６】

【発明の実施の形態】以下、図面を用いて本発明の実施
の形態の一例を詳細に説明する。

【００１７】図１は、本発明の実施の形態の一例を示
す。本実施の形態において、通信機構１００には、管理
サーバ１０１、データサーバ１０４、サーバＡ１０７、
及びサーバＢ１１０が接続されている。管理サーバ１０
１には、管理ファイル１０２が接続されている。データ
サーバ１０４には、ＤＢ（データベース）１０３が接続
されている。データサーバ１０４には、ＤＢサーバ１０
５と通知機構１０６が組み込まれている。サーバＡ１０
７には、アプリケーションサーバＡ１０８と判断機構Ａ
１０９が組み込まれており、サーバＢ１１０には、アプ
リケーションサーバＢ１１１と判断機構Ｂ１１２が組み
込まれている。

【００１８】ここで、サーバＡ１０７とサーバＢ１１０
は同様の構成をとるサーバであり、通信機構１０６に２
つ以上いくつでも同様に接続することができる。図１で
は、一例としてサーバＡ１０７とサーバＢ１１０の２つ
だけ記しているが、これに限定されるものではない。

【００１９】それぞれの各要素の機能を簡単に説明す
る。

【００２０】通信機構１００は、この通信機構１００に
接続されている複数のサーバ間の通信路を提供し、この
通信路はネットワーク、または、バスで実現される。Ｄ
Ｂサーバ１０５は、通常のＤＢ１０３のマネージメント
の他に、ＤＢ１０３のテーブルに何か（データの変更や
読み取りなど）が起きた際に、それを通知機構１０６に
通知する機能を有する。通知機構１０６は、その通知の
内容を通信機構１００を通して管理サーバ１０１に通知
する。管理サーバ１０１は、管理下にある各アプリケー
ションサーバ（Ａ１０８，Ｂ１１１など）がどのテーブ
ル（ＤＢ１０３内のテーブル）を入力としているかとい
う情報を管理ファイル１０２に記憶して管理している。
また、通知機構１０６から前記通知が来た場合に、その
通知をログに残す。また、管理サーバ１０１は、通知機
構１０６から前記通知が来た場合、それが、ＤＢ１０３
内のテーブルが変更されたという通知であった場合に
は、そのテーブルを入力としているアプリケーションサ
ーバの存在するサーバの判断機構（Ａ１０９，Ｂ１１２
など）に、そのテーブルの変更を通知する。

【００２１】その通知を受けた判断機構は、そのテーブ
ルの変更に応じて、同じサーバ内にあるアプリケーショ
ンサーバに処理をさせるか否かを判断する。判断機構
は、処理をさせる場合には、処理命令を当該アプリケー
ションサーバに送る。アプリケーションサーバは、自分
のスケジュールや外部からの命令で任意にアプリケーシ
ョンサーバの処理を行なう場合と、上述したように同じ
サーバ内の判断機構からの処理命令により処理を行なう
場合の２通りがある。アプリケーションサーバが処理を
行なった場合、その結果の出力先はＤＢ１０３となる。
処理結果は、通信機構１００を通り、ＤＢサーバ１０５
を経由してＤＢ１０３に格納される。

【００２２】以降、それぞれのサーバごとに詳細に説明
する。

【００２３】まずデータサーバ１０４について説明す
る。データサーバ１０４には、ＤＢサーバ１０５と通知
機構１０６が組み込まれている。ＤＢサーバ１０５に
は、通常のＤＢＭＳの機能に加えて、公知例３で示した
トリガーの機能が組み込まれている。これにより、ＤＢ
１０３内のテーブルに何かが起きた場合に、それを検知
することができる。テーブルに何かが起きたときは、そ
の旨を通知機構１０６に通知する。

【００２４】図２は、その通知するデータ形式を示して
いる。図２において、１レコード（１行のデータ）は１
つのイベントに対応しており、「日時」と「テーブル
名」と「アクション内容」という項目を持つ。１レコー
ドデータは、「日時」で示される時間に、「テーブル
名」で示されるＤＢ１０３内のテーブルに、「アクショ
ン内容」で示されるアクションが行なわれた、というこ
とを示す。通知機構１０６は、図２のようなデータを通
信機構１００を介して管理サーバ１０１に送信する。

【００２５】管理サーバ１０１について説明する。管理
サーバ１０１は、第１の機能として、管理ファイル１０
２に、管理下にある各アプリケーションサーバＡ１０
８，Ｂ１１１，…が入力データとしてどのテーブルを使
用しているかの情報を持つ。

【００２６】図３は、その情報の形式を示す。図３
（ａ）は、アプリケーションサーバと入出力テーブル名
との関係の一例を示す。テーブル１，２，３はＤＢ１０
３内のテーブルを示す。アプリケーションサーバＡは、
処理結果をテーブル１に出力する。アプリケーションサ
ーバＢは、テーブル１を入力とし、処理結果をテーブル
２，３に出力する。アプリケーションサーバＣは、テー
ブル１を入力とし、処理結果をテーブル３に出力する。
アプリケーションサーバＤは、テーブル３を入力とす
る。図３（ｂ）は、管理ファイル１０２に保有される、
各アプリケーションサーバが入力データとしてどのテー
ブルを使用しているかの情報の例であり、図３（ａ）の
関係に対応する情報の例である。以降、このファイルを
入力テーブル情報ファイルと呼ぶ。このファイルの１レ
コード（１行のデータ）は、１つのアプリケーションサ
ーバに対応しており、「アプリケーションサーバ名」と
そのアプリケーションサーバの「入力テーブル名」の項
目を持つ。「アプリケーションサーバ名」に示された名
称のアプリケーションサーバは、「入力テーブル名」に
示された名称のテーブルを入力とする。Φは入力テーブ
ルがないことを示す。

【００２７】また、管理サーバ１０１は、第２の機能と
して、通知機構１０６より通知されたテーブルに関する
イベントのデータ（図２）をログとして管理ファイル１
０２に蓄積する機能を有する。ログの形式は任意だが、
受け取った図２の通知データの形式でよい。

【００２８】さらに、管理サーバ１０１の第３の機能と
しては、通知機構１０６からテーブルの変化の情報（図
２）が来た場合に一連の手続きを行なう。図４は、この
一連の手続きのフローチャートを示す。ステップ４０１
では、通知機構１０６からの通知があるかないかを判定
する。通知があった場合には、ステップ４０２に移り、
なかった場合にはステップ４０１に戻る。ステップ４０
２では、通知機構１０６からの通知がテーブルの内容の
変更であったか否かの判定を行なう。これは、図２の
「アクション内容」の欄が「変更」であるかないかを調
べることにより判定できる。テーブルの内容の変更であ
った場合には、ステップ４０３に移り、そうでない場合
には、ステップ４０１に移る。ステップ４０３では、変
更があったテーブルを入力とするアプリケーションサー
バが搭載されたサーバの判断機構に対し、当該テーブル
の変更を通知する。通知するデータは、図５のようなデ
ータ形式である。該データは、「日時」で変更があった
日時を示し、「テーブル名」で該変更があったテーブル
の名称を示す。ステップ４０３の後、ステップ４０１に
戻る。なお、図２のように通知データが複数レコード
（複数行）あった場合は、各レコード単位で４０１〜４
０３の処理を行なうものとする。

【００２９】次に、アプリケーションサーバを搭載した
サーバについて説明する。ここでは、図１のサーバＡ１
０７について説明するが、サーバＢ１１０あるいは通信
機構１００に接続される不図示の他のサーバについても
同様である。サーバＡ１０７は、その中にアプリケーシ
ョンサーバＡ１０８と判断機構Ａ１０９を搭載してい
る。アプリケーションサーバＡ１０８は、そのサーバへ
の独自の入力やスケジュールに基づいて処理を行なうこ
とができる。処理を行なった際には、処理結果をＤＢ１
０３に出力する。さらに、判断機構Ａ１０９からの処理
命令に応じてアプリケーションサーバＡ１０７の処理を
行なうこともできる。すなわち、まずＤＢ１０３内のア
プリケーションサーバＡ１０８の入力となるテーブル
（以下、単に入力テーブルという）に変更が生じた場
合、管理サーバ１０１は、その変更があった旨を示す情
報を通知機構１０６経由で受け取る。管理サーバは、そ
の入力テーブルに変更があった事実を、アプリケーショ
ンサーバＡ１０８を搭載するサーバＡ１０７の判断機構
Ａ１０９に通知する。判断機構Ａ１０９は、その通知を
元にして、アプリケーションサーバＡ１０８の処理を行
なうか否かを決定して、処理を行なうことに決まったと
きには処理を行なわせる。この判断機構Ａ１０９の方式
で最も単純なものは、「通知があれば常に処理を行な
う」という判断ロジックである。

【００３０】上述した実施の形態によれば、電子メール
を用いたりせずに、すべてデータベースをアプリケーシ
ョンの入出力先としているため、信頼性のあるデータ共
有を実現できる。さらに、データが変更されたときに、
順々に関連するアプリケーションの処理が実行されてい
くので、最新のデータを得るための最小限のアプリケー
ションの実行が実現される。また、すべてのテーブルと
すべてのアプリケーションの間の関係をつながった形式
でデータとしてもたなくてもよいので、アプリケーショ
ンの仕様変更の際の管理ファイルの変更も最小限で済
む。また、アプリケーションの起動を決定するのはその
アプリケーションを搭載しているサーバである、という
ことで、実行権限をサーバ内に保持しておける。

【００３１】また、上述した実施の形態は、例えば以下
のように種々の変更をして実施することも勿論可能であ
る。

【００３２】上記実施の形態の第１の変形例を説明す
る。図６は、上記実施の形態の図１の構成を変形したも
のである。図６の構成では、図１における判断機構Ａ１
０９、判断機構Ｂ１１２をサーバＡ１０７、サーバＢ１
１０から分離して、独立したサーバとして判断サーバ６
０９を新たに設け、判断機構Ａ６１０及び判断機構Ｂ６
１１をその判断サーバ６０９に組み込むように構成して
いる。通信機構６００には、管理サーバ６０１、データ
サーバ６０４、アプリケーションサーバＡ６０７、アプ
リケーションサーバＢ６０８、及び判断サーバ６０９が
接続されている。管理サーバ６０１には、管理ファイル
６０２が接続されている。データサーバ６０４には、Ｄ
Ｂ６０３が接続されている。データサーバ６０４には、
ＤＢサーバ６０５と通知機構６０６が組み込まれてお
り、判断サーバ６０９には、判断機構Ａ６１０と判断機
構Ｂ６１１が組み込まれている。

【００３３】ここで、アプリケーションサーバＡ６０７
とアプリケーションサーバＢ６０８は同様の構成をとる
サーバであり、通信機構６００に２つ以上いくつでも同
様に接続される。また、判断機構Ａ６１０はアプリケー
ションサーバＡ６０７に対応しており、判断機構Ｂ６１
１はアプリケーションサーバＢ６０８に対応している。
これも、アプリケーションサーバに対応して、その数だ
け判断サーバに組み込まれる。図６では、アプリケーシ
ョンサーバＡ６０７とアプリケーションサーバＢ６０
８、及び判断機構Ａ６１０と判断機構Ｂ６１１というよ
うに、アプリケーションサーバと判断機構の組を一例と
して２組だけ記している。

【００３４】次にそれぞれの要素の機能を簡単に説明す
る。

【００３５】通信機構６００は、この通信機構６００に
接続されているサーバ間の通信路を提供する。ＤＢサー
バ６０５は、通常のＤＢ６０３のマネージメントの他
に、ＤＢ６０３のテーブルに何かが起きた際に、それを
通知機構６０６に通知する。通知機構６０６は、その内
容を通信機構６００を通して管理サーバ６０１に通知す
る。管理サーバ６０１は、それぞれのアプリケーション
サーバがどのテーブルを入力としているかという情報を
管理ファイル６０２に記憶して管理する。また、通知機
構６０６から前記通知が来た場合、それをログに残す。
また、管理サーバ６０１は、通知機構６０６から前記通
知が来た場合、それが、ＤＢ６０３内のテーブルが変更
されたという通知であった場合には、そのテーブルを入
力としているアプリケーションサーバに対応する判断機
構に、該テーブルの変更を通知する。この場合、判断機
構は、例えばＡ６１０やＢ６１１のように判断サーバ６
０９に存在する。

【００３６】その通知を受けた判断機構は、そのテーブ
ルの変更に応じてアプリケーションサーバの処理を行な
わせるか否かを判断する。判断機構は、処理を行なわせ
る場合には、処理命令を、対応するアプリケーションサ
ーバに送る。

【００３７】アプリケーションサーバは、自分のスケジ
ュールや外部からの命令で任意に処理を行なう場合と、
対応する判断機構からの上記処理命令で処理を行なう場
合の２通りがある。処理を行なった場合には、その処理
結果の出力先はＤＢ６０３となる。処理結果は、通信機
構６００を通り、ＤＢサーバ６０５を経由してＤＢ６０
３に格納される。

【００３８】上記第１の変形例は、判断機構がアプリケ
ーションサーバから分離したことを除けば、図１の実施
の形態と同様である。本変形例によれば、アプリケーシ
ョンサーバを追加する際に、アプリケーションサーバ自
体に変更を加えなくても容易に通信機構６００に接続が
できるようになる。なお、上記第１の変形例において、
判断機構は判断サーバ内に各アプリケーションサーバ対
応に設けてあるが、管理サーバから判断機構に送る通知
の中に、変更されたテーブルを入力としているアプリケ
ーションサーバを特定できる情報を含めておけば、判断
機構を１つにまとめることができる。すなわち、判断機
構は、管理サーバから受け取った通知の中の情報から特
定されるアプリケーションサーバに対して処理命令を発
行すればよい。

【００３９】次に、上記実施の形態の第２の変形例を説
明する。上記実施の形態において、判断機構は「通知が
あれば常に処理命令を送る」という判断ロジックを用い
たが、本変形例では、その代わりに次のような判断ロジ
ックを持つ。すなわち、テーブルの変更があった回数
を計数しておき、予め定めた一定の回数に達したときに
処理命令を送る方法、予め定めた日時を経過し、か
つ、テーブル変更の通知があった場合に処理命令を送る
方法、上記及びを組み合わせて、日時の条件と回
数の条件を両方満たしたときに処理命令を送る方法、ま
たは、上記もしくはのどちらかを満たしていると
きに処理命令を送る方法のうち、何れかの判断ロジック
を用いる。本変形例によれば、テーブル変更の通知が頻
繁に発生する場合に、それに対応して多数回の処理をさ
せなくても済む。

【００４０】次に、上記実施の形態の第３の変形例を説
明する。第３の変形例では、一つのアプリケーションサ
ーバが二つ以上の入力テーブルを持つとき、判断機構
は、そのうちの任意の一つの入力テーブルが変更され
たときに処理命令を送るように判断ロジックを設定す
る、あるいは、予め決めておいたある入力テーブルが
変更されたときのみ処理命令を送るように判断ロジック
を設定する、の何れかの判断ロジックで判断する。本変
形例によれば、一つのアプリケーションサーバが二つ以
上の入力テーブルを持つときにも対応が可能である。

【００４１】次に、上記実施の形態の第４の変形例を説
明する。第４の変形例では、ＤＢサーバが通知機構に通
知し管理サーバに送信する通知データのデータ形式、及
び管理サーバがログとして管理ファイルに蓄積するデー
タのデータ形式を、図２に示すデータ形式から図７に示
すデータ形式のように変更する。すなわち、データサー
バは、テーブルにアクションをした「アプリケーション
サーバ名」を同時に通知するようにする。図７のような
通知データを受けた管理サーバは、その「アプリケーシ
ョンサーバ名」も含めてログに残す。

【００４２】さらに第４の変形例では、管理サーバは、
あるテーブルが、いつの元データを使って作られたもの
かを追跡調査する機能も持つ。図８に、その追跡調査の
方法のフローチャートを示す。以下、図８の手順を、図
７の内容の管理ファイルを例として説明する。

【００４３】ステップ８０１では、どの時点のどのテー
ブルについてその元データを追跡したいかを入力する。
例えば、ユーザが、１９９８年７月２８日４時００分０
０秒における、テーブル３という情報を入力したとす
る。ステップ８０２では、与えられた時刻からさかのぼ
ってそのテーブルの最新の変更を示すレコードを管理フ
ァイルのログから抽出する。この例では、管理ファイル
のログの内容は図７のようになっているから、図７のレ
コード７０１がテーブル３への変更としては最新である
ことが検索される。ステップ８０３では、上記ステップ
８０２で検索したレコードで、変更をしたアプリケーシ
ョンサーバ名を抽出する。この場合はアプリケーション
サーバ名はＣである。

【００４４】ステップ８０４では、上記ステップ８０３
で抽出されたアプリケーションサーバが、ステップ８０
２で抽出された変更を行なう処理を行なったときに、元
データを読んだイベントを示すレコードを検索する。こ
の検索は、ステップ８０２で検索されたレコードから時
刻をさかのぼりながら行なう。ここでは、図３（ｂ）に
示した入力テーブル情報ファイルを用いるものとして説
明する。これにより、該当アプリケーションサーバの元
データとなる入力テーブルを抽出し、それらのテーブル
が該当アプリケーションサーバによって最近に読まれた
ことを示すレコードを抽出する。この例では、図３
（ｂ）からアプリケーションサーバＣはテーブル１を入
力としていることが分かるから、そのテーブル１を読み
込んだイベントを検索し、結果として図７のレコード７
０２が検索される。レコード７０２の「日時」の欄に
は、アプリケーションサーバＣがテーブル１を読み込ん
だ日時が記載されている。

【００４５】ステップ８０５では、上記ステップ８０４
で検索されたレコードから時刻をさかのぼって、その元
データの最新の変更を示すレコードを検索する。この例
では、レコード７０３が元データの入力テーブルである
テーブル１を最近に変更したという記録を示している。
ステップ８０６では、ステップ８０５で抽出されたレコ
ードの日時とテーブル名を出力する。この例では、１９
９８年７月２８日２時００分００秒にテーブル１が変更
されているという情報を出力することになる。これによ
り、ユーザが入力した時刻とテーブル名から、そのテー
ブルが、いつの時点の元データから作られたものかを知
ることができる。

【００４６】以上、本変形例によれば、それぞれのテー
ブルを作るためにアプリケーションサーバが参照した元
データの鮮度が追跡調査できる。さらに、図７のような
通知データによりどのアプリケーションサーバでどのテ
ーブルが変更されたかが分かり、図３（ｂ）のような入
力テーブル情報ファイルにより各アプリケーションサー
バの入力テーブルが分かるから、元データのさらに元デ
ータを追跡調査するというように、何段でもさかのぼっ
て追跡調査が可能となる。

【００４７】

【発明の効果】以上述べたように、本発明によれば、デ
ータベースを各アプリケーションサーバで共用し、入出
力をそのデータベースに対して行なうようにしているの
で、アプリケーション間で信頼性のあるデータの共有を
行なうことができる。また、どのアプリケーションサー
バがデータベースのどのテーブルを入力とするかを管理
し、データベースのあるテーブルに変化が起こった際
に、そのテーブルを入力とするアプリケーションサーバ
にその変化を通知するようにしているので、データベー
スの変化の情報を各アプリケーションで利用することが
でき、アプリケーション間の連携を管理することができ
る。例えば、いくつかのアプリケーションが順番に動く
ような場合に、次に動くべきアプリケーションを自動的
に起動することができる。さらに、管理ファイルにアプ
リケーションとテーブルとの関係を示す情報とともに、
アクションの履歴情報を記憶するようにすれば、指定さ
れた時刻の指定されたテーブルに対して、該テーブルを
作成する元になったテーブルの生成日時を求めることが
でき、元データの鮮度を知ることができ、データのバー
ジョン管理を行なうことができる。

【図面の簡単な説明】

【図１】本発明の実施の形態の一例の構成図。

【図２】通知データの形式の一例を示す図。

【図３】アプリケーションサーバの入力テーブルの情報
を示す図。

【図４】管理サーバの通知に関するフローチャート図。

【図５】サーバの判断機構に通知されるデータ形式を示
す図。

【図６】本発明の実施の形態の変更例の構成図。

【図７】変更例におけるデータ形式を示す図。

【図８】追跡調査のフローチャート図。

【符号の説明】

１００…通信機構、１０１…管理サーバ、１０２…管理
ファイル、１０３…ＤＢ（データベース）、１０４…デ
ータサーバ、１０５…ＤＢサーバ、１０６…通知機構、
１０７…サーバＡ、１０８…アプリケーションサーバ
Ａ、１０９…判断機構Ａ、１１０…サーバＢ、１１１…
アプリケーションサーバＢ、１１２…判断機構Ｂ、６０
０…通信機構、６０１…管理サーバ、６０２…管理ファ
イル、６０３…ＤＢ（データベース）、６０４…データ
サーバ、６０５…ＤＢサーバ、６０６…通知機構、６０
７…アプリケーションサーバＡ、６０８…アプリケーシ
ョンサーバＢ、６０９…判断サーバ、６１０…判断機構
Ａ、６１１…判断機構Ｂ。

フロントページの続き (72)発明者 伊藤 幸康 神奈川県横浜市戸塚区戸塚町5030番地 株 式会社日立製作所ソフトウェア事業部内 Ｆターム(参考） 5B082 FA11 FA16 HA03 5B085 AC03 BG07

Claims (8)

【特許請求の範囲】
1. 【請求項１】二つ以上のアプリケーションサーバを連携
   して動作させるアプリケーションサーバ連携装置であっ
   て、 複数のテーブルを含むデータベースと、 前記データベースと接続され、これを管理するデータベ
   ースサーバと、 前記データベース内のテーブルに対してアクションが施
   されたとき、その旨を管理サーバに通知する通知機構
   と、 前記アプリケーションサーバとそのアプリケーションサ
   ーバへの入力となる前記データベース内のテーブルとの
   関係を示す情報を保持する管理ファイルと、 前記データベース内のテーブルに対してアクションが施
   された旨を示す通知を前記通知機構から受理し、該アク
   ションがデータの変更であった場合に、前記管理ファイ
   ルに保持されている前記アプリケーションサーバと前記
   テーブルとの関係を示す情報を参照して、該データ変更
   があったテーブルを入力とする前記アプリケーションサ
   ーバにそのテーブル変更を通知する管理サーバとを備え
   たことを特徴とするアプリケーションサーバ連携装置。
2. 【請求項２】前記管理サーバからのテーブル変更の通知
   を受けて、前記アプリケーションサーバに処理を行なわ
   せるか否かを判断する判断機構を、さらに備えたことを
   特徴とする請求項１に記載のアプリケーションサーバ連
   携装置。
3. 【請求項３】前記判断機構は、前記管理サーバから前記
   テーブル変更の通知を受けたとき、前記アプリケーショ
   ンサーバに必ず処理を行なわせることを特徴とする請求
   項２に記載のアプリケーションサーバ連携装置。
4. 【請求項４】前記判断機構は、前記管理サーバから送ら
   れてきた前記テーブル変更の通知の回数と、前記テーブ
   ル変更の通知の日時との二つの情報のうち少なくとも一
   つを用いて、前記アプリケーションサーバに処理を行な
   わせるか否かを判断することを特徴とする請求項２に記
   載のアプリケーションサーバ連携装置。
5. 【請求項５】前記判断機構を搭載した判断サーバを構成
   要素として含むことを特徴とする請求項２に記載のアプ
   リケーションサーバ連携装置。
6. 【請求項６】前記管理ファイルが、前記データベース内
   のテーブルに対して施されたアクションの履歴情報を保
   持することを特徴とする請求項１に記載のアプリケーシ
   ョンサーバ連携装置。
7. 【請求項７】前記通知機構から前記管理サーバに通知す
   る、前記テーブルにアクションが施された旨の通知内容
   に、該アクションを行なったアプリケーションサーバの
   名称を含ませることを特徴とする請求項６に記載のアプ
   リケーションサーバ連携装置。
8. 【請求項８】前記管理サーバは、指定された時刻におけ
   る前記データベースの指定されたテーブルに対して、前
   記管理ファイルに保持されているアクションの履歴情
   報、及び前記アプリケーションサーバと前記データベー
   ス内のテーブルとの関係を示す情報を参照して、該指定
   されたテーブルを生成するために使われたテーブルの生
   成日時を抽出する手段を、さらに備えたことを特徴とす
   る請求項７に記載のアプリケーションサーバ連携装置。