JPH1027121A

JPH1027121A - データベース・ネットワークの接続性に関する生産物

Info

Publication number: JPH1027121A
Application number: JP9007167A
Authority: JP
Inventors: Rafael Bracho; ラファエル・ブラッチョ; Tilman Sporkert; ティルマン・スポーカート
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1996-01-18
Filing date: 1997-01-20
Publication date: 1998-01-27
Also published as: EP0806731B1; EP0806731A2; DE69723612T2; US5974417A; DE69723612D1; EP0806731A3; US5873084A

Abstract

(57)【要約】（修正有）【課題】サポートが困難なレガシ・データベース・ソ
フトウェアを、修正を加えずにネットワーク・システム
に統合できるようにする。【解決手段】「公表と予約」モデルを採用し、レガシ
・データベースのデータベース接続部を含むパブリシャ
１０２〜１１６やサブスクライバ１０４〜１１８がシス
テム内の通信の基礎となる「イベント」を公表あるいは
予約できるようにする。パブリシャとサブスクライバは
互いについての直接の知識をもたず、「広告」を行うこ
とにより公表と予約を非同期的に行う。サブスクライバ
は公表されたイベントであって指定した予約基準と一致
するものを受信できる。データベース接続部はレガシ・
データベースのトランザクション・モニタに対してはノ
ードとして振る舞い、ネットワークのハブ１０６〜１１
４に対してはクライアントとして公表や予約を行う。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】

関連出願 "Middleware For Enterprise Information Distributio
n"と題する、BrachoおよびJankowskiの米国特許出願番
号第号が本願と同時に出願された。

【０００２】追加資料追加資料Ａは、本明細書の一部であり、この言及により
本願にも含まれているものとする。この追加資料Ａに
は、本発明の好適実施例において、ハブ間で渡すことが
できるシステム・イベントの一例について、その概要が
収容されている。

【０００３】本発明は、情報公表システムに関し、更
に特定すれば、レガシ・データ・ベース(legacy data b
ase)を情報公表システムに接続する方法および装置に関
するものである。

【０００４】

【従来の技術】従来のシステムの中には、データ処理シ
ステムのノード間で情報を交換するために「トランザク
ション」モデル(transactional model)を使用するもの
がある。

【０００５】従来のトランザクション・モデルでは、２
つのアプリケーションが同期した「トランザクション」
を起動し、このトランザクションは、ノード間で情報を
交換している限り保持される。トランザクション・モデ
ルは、各業務アクティビティ(business activity)にト
ランザクションを定義することを必要とする。ネットワ
ークの広範囲にわたる異なる部分にあるノードがトラン
ザクション・モデルを通じて通信しようとする場合、当
該システムの全ての部分で良好に動作するトランザクシ
ョンを定義することが困難なことが多い。更に、トラン
ザクションは、当該トランザクションを開始したノード
のみを伴うことができる。他のノードは途中からトラン
ザクションに予約することはできない。この方式は、ノ
ードがシステム内の他の全ノードについて知らないよう
なシステムには、不向きである。

【０００６】多くの商業的企業は未だに、昔開発されも
はやその製造者によるサポートを受けられないソフトウ
エアを使用している。このようなソフトウエアのことを
「レガシ・ソフトウエア」と呼ぶ。加えて、多くの商業
的企業は、商用ソフトウエア製品を使用する。既存の商
用ソフトウエアやレガシ・ソフトウエアを修正し、新た
にネットワーク組織としたシステムで動作させること
は、必ずしも可能ではなく、また望ましいことでもな
い。商用ソフトウエアおよびレガシ・ソフトウエアは非
常に複雑な場合があり、それを修正するのは困難で、し
かも費用がかかる。会社は、常に稼働している安定なシ
ステムに修正を加えることには、慎重である。更に、会
社内には、修正を加えることができる程にレガシ・シス
テムについて詳しく理解しているコンピュータ・プログ
ラマが全くいない場合もある。最後に、会社は、レガシ
・アプリケーションを商業的販売人から購入した場合、
当該レガシ・アプリケーションのソース・コードを所有
していないという場合もある。また、会社は、データ・
ベース・ソフトウエアを修正する法的な権利を有してい
ない場合もある。

【０００７】

【発明が解決しようとする課題】必要とされているの
は、商用およびレガシ・データ・ベース・ソフトウエア
をネットワーク・システムに統合し、しかもデータ・ベ
ース・ソフトウエア自体には修正を加えなくて済む方法
である。

【０００８】

【課題を解決するための手段】本発明は、従来技術の問
題点および欠点を克服するにあたり、ネットワーク内で
パブリッシャあるいはサブスクライバのいずれとしても
動作可能な「データ・ベース接続部」を提供する。

【０００９】本発明は、「ミドルウエア」(middleware)
の一種として実施される。ミドルウエアとは、アプリケ
ーション・プログラムと制御レベルのプログラムとの間
に位置するソフトウエアのことである。ミドルウエアは
「ネットワーク中心」(network centric)であり、特定
のユーザ・インターフェースや特定のデータベースの組
織に集中しない。以下に記載する実施例は、情報を公表
する複数の「パブリッシャ」(publisher)エンティティ
と、情報を要求し使用する複数の「サブスクライバ」(s
ubscriber)エンティティとを含む。パブリッシャとサブ
スクライバは、互いにネットワークで接続されている。
ネットワークは、「格納および転送」(store and forwa
rd)ネットワークであり、そのルーティング(routing)は
「内容を基本とする」(content-based)ものである。内
容を基本とするルーティング・システムでは、情報は、
当該情報の内容に基づいて流通するのであり、システム
内のパブリッシャやサブスクライバのアドレスに基づく
のではない。以下に記載する実施例では、情報は多くの
サブスクライバに並行して分配される。

【００１０】以下に記載する実施例では、情報の基本的
単位(basic quanta)を「イベント」(event)と呼ぶ。パ
ブリッシャはイベントを公表し、サブスクライバは、サ
ブスクライバ自身が定義した基準と一致するイベントに
予約を行う。以下に記載する実施例では、イベントを表
わす際に、Ｃプログラム言語におけるデータ構造を使用
するが、適切な表現であればあらゆるものが使用可能で
ある。

【００１１】公表と予約は非同期的に実行される。パブ
リッシャとサブスクライバは互いの直接的な知識を有し
ていない。システムは、パブリッシャから公表されたイ
ベントを受信し、全ての適切なサブスクライバにそのイ
ベントを送出する。各サブスクライバは、イベントがサ
ブスクライバ自身の指定した予約基準に一致する場合の
み、システム上で公表された全てのイベントを受信する
ことを保証されている。

【００１２】以下に記載する実施例は、パブリッシャお
よびサブスクライバ用のアプリケーション・プログラミ
ング・インターフェース（ＡＰＩ:Application Program
mingInterface)を含む。ＡＰＩは、各パブリッシャおよ
びサブスクライバにシステムへのインターフェースを可
能にする、複数の手順を定義する。したがって、様々な
タイプのパブリッシャおよびサブスクライバは、ＡＰＩ
にしたがって定義されたインターフェース手順を使用し
ている限り、システムに接続することができる。また、
以下に記載する実施例は、共通のデータベース、インス
トールおよび管理ツール、およびロギング機能(logging
facilities)のような、複数のソフトウエア・エレメン
トに対するサポートを含む。したがって、以下に記載す
る実施例は、商業用企業の全域にわたって使用可能なの
で、「企業システム」と命名する。

【００１３】以下に記載する本発明の実施例は、レガシ
・システム、レガシ・アプリケーション、およびレガシ
・ハードウエアをシステムに容易に統合し、ユーザがシ
ステムを使用するために修得しなければならない情報量
を最少に抑えようとするものである。システム内の通信
は非同期の「イベント」に基づいて行われるので、本発
明は、様々なオペレーティング・システムの下で実行
し、多種多様なアプリケーションを走らせる、ＰＣおよ
びメインフレームの双方を含む異種ネットワーク上での
実施が可能である。以下に記載する実施例は、分散オブ
ジェクト環境(distributed-object environment)を利用
し、本発明の好適実施例は、共通オブジェクト要求ブロ
ーカ(CORBA:Common Object Request Broker)を実施す
る。

【００１４】本発明の目的によると、本明細書において
具体化され広く記載されるように、本発明は、データ・
ベースをパブリッシャ／サブスクライバ・ネットワーク
に接続し、データ・ベースがネットワークにイベントを
公表できるようにする方法に関する。この方法は、デー
タ処理システムによって実行される次のステップから成
る。即ち、リンクを用意し、トランザクション監視コン
ピュータ・プログラムによって、データ・ベースがデー
タ・ベース接続コンピュータ・プログラムと通信できる
ようにするステップと、ネットワークにおいてデータ・
ベース接続部をパブリッシャ・ハブとして設定するステ
ップと、データ・ベースによって、当該データ・ベース
内のデータを変更するユーザからの入力を受信するステ
ップと、データが変更されたことをトランザクション・
モニタに通知するステップと、変更データを受け入れる
ことを示すユーザからの入力を受信するステップと、変
更データが受け入れられたことをトランザクション・モ
ニタに通知するステップと、データ・ベース接続部によ
って、データが受け入れられたというトランザクション
・モニタからのメッセージにしたがって、公表されたイ
ベントを、変更されたデータにしたがってネットワーク
に送るステップから成る。

【００１５】本発明の目的および利点は、部分的に以下
の説明に記載されており、部分的に以下の記載から明白
であり、あるいは本発明の実施を通じて学習することが
できる。本発明の目的および利点は、特許請求の範囲に
おいて特定的に指摘してある要素および組み合わせ、な
らびにその均等物によって、実現および達成されよう。

【００１６】添付図面は、本明細書に含まれその一部を
構成するが、本発明の種々の実施例を例示し、以下の記
載と共に、本発明の原理を説明するために供するもので
ある。

【００１７】

【発明の実施の形態】これより、本発明の好適実施例に
ついて詳細に説明する。本発明の例は添付図面に示され
ており、可能な場合は、同一参照番号を図面全てにおい
て使用して、同一部分または同様部分に言及することと
する。

【００１８】１．概要図１は、本発明の好適実施例によるネットワーク型コン
ピュータ・システム１００のブロック図である。ネット
ワーク型コンピュータ・システム１００は、複数のパブ
リッシャ１０２，１１０，１１６および複数のサブスク
ライバ１０４，１１２，１１８を含む。パブリッシャ１
０２とサブスクライバ１０４は、ハブ１０６を通じてネ
ットワーク１２０に接続されている。パブリッシャ１１
０およびサブスクライバ１１２はハブ１０８を通じてネ
ットワーク１２０に接続されている。パブリッシャ１１
６とサブスクライバ１１８は、ハブ１１４を通じてネッ
トワーク１２０に接続されている。ハブ１０６およびそ
れに接続されているパブリッシャおよびサブスクライバ
は第１テリトリ(territory)１３０にある。ハブ１０
８，１１４およびこれらに接続されているパブリッシャ
およびサブスクライバは第２テリトリ１４０にある。そ
の他のテリトリ（図示せず）もネットワーク１２０には
存在する。「ハブ」、「パブリッシャ」、「サブスクラ
イバ」、および「テリトリ」については、以下で順番に
論じることにする。

【００１９】図１において点線で示すように、各パブリ
ッシャ、サブスクライバ、およびハブは、別個のコンピ
ュータ（１０２，１０４，１０６）、同一コンピュータ
（１０８，１１０，１１２）、または別個のコンピュー
タおよび同一コンピュータ（１１４，１１６，１１８）
のいずれかの組み合わせの中に配置することができる。
ハブは、０カ所以上のパブリッシャおよび０カ所以上の
サブスクライバを有することができる。また、ハブは直
接その他のハブと接続することも可能である。

【００２０】各コンピュータ（図１において点線で表わ
す）は、ＣＰＵと、メモリと、入出力線とを含むこと
は、当業者には理解されよう。これらの要素は、例の明
確化のために、図には示していない。各コンピュータ
は、ディスク駆動装置、キーボード、表示装置、ネット
ワーク接続部、追加メモリ、追加ＣＰＵ等のようなその
他の多数の要素を含むことも可能である。パブリッシ
ャ、サブスクライバ、およびハブは、メモリ内に格納さ
れたソフトウエア命令として実施され、コンピュータ・
システムのプロセッサによって実行されることが好まし
い。通常、パブリッシャ、サブスクライバ、およびハブ
・ソフトウエアは、当該ソフトウエアが格納されている
コンピュータのプロセッサによって実行されるが、他の
コンピュータ・システムのプロセッサがかかるソフトウ
エアを実行することも可能である。

【００２１】本発明の好適実施例は、ソラリス(Solari
s)オペレーティング・システム、バージョン２．４の下
で実行する。ソラリスは、米国およびその他の国におい
てサン・マイクロシステムズ・インコーポレーテッド(S
un Microsystems, Inc.)の登録商標であり、ユニックス
(Uｎｉｘ)オペレーティング・システムを基本とするも
のである。ユニックスは、米国およびその他の国におけ
る登録商標であり、Ｘ／ＯＰＥＮ，Ｌｔｄ．を通じて独
占的に実施許諾されている。ネットワーク型コンピュー
タ・システム１００は、ＴＣＰ／ＩＰのようなネットワ
ーク通信プロトコルを使用するが、本発明を実施するに
は、あらゆる適切なプロトコルを使用することができ
る。

【００２２】ここに記載する実施例では、「パブリッシ
ャ」はネットワーク１２０上である種のイベントを公表
し、「サブスクライバ」はある種のイベントに予約を行
う。パブリッシャおよびサブスクライバは非同期的に動
作し、互いの存在について知らない。「公表および予
約」モデルを使用することにより、ネットワークからに
アプリケーションを、および互い分離することができ
る。公表は、イベントの同報通信として考えることがで
きる。イベント・タイプは無線局と類似している。特定
の局に関心があるアプリケーションは、特定のイベント
・タイプに予約（即ち、渡す）する。関連する当事者が
予め１組の可能な周波数で同意していなければならな
い、無線の同報通信と丁度同じように、ここに記載する
実施例におけるアプリケーションも、所定の組のイベン
ト・タイプに予め同意していなければならない。

【００２３】ここに記載する本発明の実施例は、「内容
による予約」を使用する。サブスクライバは、イベント
・タイプおよび時報の内容に基づいて、彼らがほしいも
のを指定する。ここに記載する実施例は、イベントに対
して、「格納および転送」技法を利用する。この用語
は、パブリッシャがオフ・ラインであても、サブスクラ
イバがイベントを取り込むことができるように、システ
ムがイベントをバッファに入れておくことを意味する。
同様に、パブリッシャも、サブスクライバがオフ・ライ
ンであっても、イベントを公表することができる。

【００２４】ここに記載する実施例は、ハブ単位で管理
される。ハブ１０６のようなハブは、パブリッシャおよ
び／またはサブスクライバの局在接続点である。パブリ
ッシャおよびサブスクライバ双方を、ハブの「クライア
ント」と呼ぶ。パブリッシャは「広告」(advertisemen
t)を用いて、それが公表しようとしているイベントのタ
イプ、どのようにそれらを公表しようとしているか（例
えば、毎日、各イベント・トリガが発生する度、等）に
ついて、システムに伝える。広告は、パブリッシャのイ
ンストールの間に、このパブリッシャが接続されている
ハブに登録される。広告は固有の名称を有する必要があ
る。公表すべきイベント・タイプの名称を含むことに加
えて、広告はパブリッシャについての他の情報も含む。
この情報は、公表されるイベントの優先度レベル、イベ
ントの有効期間等を含むことができる。ハブは広告を全
ての潜在的サブスクライバに送信する。ハブは、公表さ
れたイベントを、サブスクライバの予約と内容が一致す
るタイプのイベントに予約してある、全てのサブスクラ
イバに送信する。

【００２５】ＩＩ．パブリッシャおよびサブスクライバ以下の章では、アプリケーション（パブリッシャまたは
サブスクライバのいずれか）を作成し、それをハブ上に
インストールするために必要なステップについて説明す
る。また、以下の章では、パブリッシャの一例がイベン
トを公表する際に実行するステップ、およびサブスクラ
イバの一例がイベントに予約する際に実行するステップ
についても説明する。ここに記載する実施例は、プログ
ラマが高水準言語でアプリケーション（パブリッシャお
よびサブスクライバ）用ソフトウエアを書き、ＡＰＩに
定義されているルーチンを使用し、更に各ユーザ定義イ
ベントのタイプに対して発生したイベント操作ルーチン
を使用して、ハブとインターフェースを行うことができ
るようにするものである。

【００２６】図２は、例えば、パブリッシャのようなア
プリケーションをハブ上にインストールする際に実行す
るステップを示すフロー・チャートである。図３は、イ
ンストールしたパブリッシャがあるイベントを公表する
際に実行するステップを示すフロー・チャートである。
図４は、図１のサブスクライバが、あるタイプおよび内
容のイベントに予約する際に実行するステップを示すフ
ロー・チャートである。先に論じたように、パブリッシ
ャおよびサブスクライバは双方とも、プロセッサによっ
て実行されるソフトウエア・プログラムとして実施する
ことが好ましい。

【００２７】ここに記載する実施例は、イベントの送信
（公表）および受信（予約）を中心とする。パブリッシ
ャがイベントを公表できるようにするには、パブリッシ
ャはそれが公表しようとするイベントを定義し、その広
告を行わなければならない。イベントを意味のあるもの
にするために、パブリッシャおよびサブスクライバは互
いに理解し合う必要がある。このために、ここに記載す
る実施例は、イベントを定義するために、標準的な使用
言語を使用する。図２のステップ２０２において、パブ
リッシャは、当該パブリッシャが公表可能な１つ以上の
イベントを定義する。ここに記載する実施例は、業界標
準のインターフェース定義言語（ＩＤＬ:Interface Def
inition Language）を用いて、イベントの定義が可能で
ある。ＩＤＬは、オブジェクト管理グループ（ＯＭＧ:O
bject Management Group）によって普及された標準的イ
ンターフェースであるが、イベントの構造を記述するた
めに適用可能ないずれのシンタックスも、ここに記載す
る実施例と組み合わせて使用可能である。ステップ２０
４において、イベントのＯＭＧＩＤＬ定義をＣプログ
ラミング言語のデータ構造に変換する。

【００２８】例えば、アプリケーションが"SalesOrder"
イベントを公表すると仮定する。このアプリケーション
をシステムに追加可能にするには、そして他にSalesOrd
erイベントを扱うアプリケーションが未だ存在しないと
仮定すると、プログラマはＯＭＧＩＤＦを用いて、以
下のように、"SalesOrder"を定義する。

【００２９】 //filename: order:ddl interface SalesOrder{ struct Address{ string street; string city; string state; unsigned long zip; }; attribute string customer_name; attribute Address customer_address; };

【００３０】上記のシンタックスは、１つのイベントを
「インターフェース」として定義し、当該イベント内の
データ・メンバを「属性」として定義する。

【００３１】１つ以上のイベントを定義した後、これら
のイベントをＣプログラミング言語の構造体定義に変換
する。好ましくは、この変換は、ＯＭＧＩＤＬコンパ
イラによって実行し、ヘッダ・ファイルとコード・ファ
イルを各イベントについて発生する。発生したヘッダ・
ファイルは、コード・ファイル内に定義した型宣言され
た関数(typed function)に対するイベントの宣言を表わ
す、単純なＣ言語構造体を含む。タイプSalesOrderの上
記の例示イベントのために発生したＣ構造体の定義は、
以下の通りである。

【００３２】 typedef struct SalesOrder_Address { nxsString street; nxsString city; nxsString state; nxsULong zip; } SalesOrder_Address; typedef struct SalesOrder { nxsStrig customer_name; SalesOrder_address customer_address; } SalesOrder;

【００３３】この例のＩＤＬがどのようにして上に示す
Ｃプログラミング言語構造の定義に変換するかについて
は、当業者は容易に理解しよう。

【００３４】イベント定義から発生したコード・ファイ
ルは、定義されたタイプ（ここでは、SalesOrderイベン
ト）のイベントを操作するための手順を含む。この手順
は少なくとも以下の処理を行う。

【００３５】パブリッシャによる使用のためタイプSalesOrderのイベント作成。タイプSalesOrderの
イベント公表。タイプSalesOrderのイベント廃棄。サブスクライバによる使用のためタイプSalesOrderのイベント内容の印刷。タイプSalesO
rderのイベントに対する予約登録。

【００３６】上記の複数の手順は各定義されたイベント
について発生するが、これら手順の処理は、イベントの
構造における相違によって異なるものとなることは、当
業者は理解しよう。また、これらの手順は、ここに記載
する実施例がプログラミング・エラーを防止するために
タイプされた関数を用いるという事実によっても、異な
るものとなる。

【００３７】ハブにプロセス・アプリケーションをイン
ストールするプロセスは、ステップ２０６に示すよう
に、１つ以上の広告をハブに格納することを含む。これ
らの広告は、ハブが知っているイベントのタイプを定義
する。１つの広告は、当該広告の名称、パブリッシャが
公表するイベント（例えば、SalesOrderのイベント）の
記述、どのようにパブリッシャがそのイベントを公表す
るか（例えば、毎日、イベント・トリガが発生したとき
等）、イベント・タイプの名称、イベントの優先度レベ
ル、および当該イベントの消滅時間（「存続時間」とも
呼ぶ）を含む。図示していないが、ここに記載する実施
例は、種々のイベント・タイプについてアクセス制御許
可を設定することも可能である。

【００３８】また、ここに記載する実施例は、ＡＰＩに
おいて予め定義されたルーチンを含み、これらはパブリ
ッシャおよびサブスクライバ・ソフトウエアには使用可
能であり、少なくとも以下の機能を実行するルーチンを
含む。

【００３９】クライアントの登録。既存のセッションを
用いてのクライアントの再確立。クライアントの抹消。
公表する意向の登録。公表の抹消。イベントの登録。イ
ベントへの予約。イベントへのアクティブな予約の再活
性化。予約の取り消し。

【００４０】本発明による他のＡＰＩは、多少異なるＡ
ＰＩ機能を含むこともあり得る。加えて、ＡＰＩは、呼
び出し元のアプリケーションがあるタイプのイベントの
予約または公表が可能であるか否かを示すブール値を返
す、"can_subscribe"ルーチン（予約可能ルーチン）お
よび"can_publish"ルーチン（公表可能ルーチン）を含
むことが好ましい。また、ＡＰＩは、あるイベントのパ
ブリッシャについての情報、およびどのようにしてその
イベントを公表したかについての情報を返す、"get_cur
rent_envelope"ルーチン（現エンベロープ取得ルーチ
ン）も含む。（このルーチンは、コールバック手順から
のみコールされる）。例えば、サブスクライバがあるイ
ベントを受信した場合、コールバック手順をコールす
る。図９は、あるイベントに対する、エンベロープ・デ
ータ構造のフォーマットを示す。

【００４１】あるパブリッシャまたはサブスクライバに
ついてのイベント記述を最初に、例えば、Ｃに変換する
とき、先に発生について論じたイベント・ヘッダ・ファ
イルを、アプリケーション・ソフトウエア・ソース・コ
ードに含ませる。したがって、この例では、パブリッシ
ャは、SalesOrderイベントの定義へのアクセスを有す
る。また、変換はイベント操作ルーチンおよびＡＰＩル
ーチンを、この時点でアプリケーションにリンクする。
対応するハブは、その他のハブと共に、広告の存在を示
す通知を、潜在的なサブスクライバに送信する。これに
ついては、以下で論ずる。

【００４２】一旦パブリッシャをハブにインストールし
たなら、広告およびイベントを自由に公表することがで
きる。図３は、パブリッシャの処理の間に、図１のパブ
リッシャが実行するステップを示すフロー・チャートで
ある。ＩＤＬをコンパイルすることによって作成された
イベント操作ルーチンへのコールを伴うステップは、図
においてアステリスクによって示されている。

【００４３】図３のステップ３０２に示すように、パブ
リッシャは、まず、それが接続されているハブに、それ
自体をクライアントとして登録する。次に、パブリッシ
ャは、公表するときにそれがどの「広告」を使用するの
かについて、ハブに通知する。広告は、「公表する意
向」を表わし、パブリッシャがどのタイプのイベントを
公表しようとしているかをハブに伝える。ステップ３０
２においてハブに通知するために、パブリッシャは、既
にハブにインストールしてある（図２参照）広告の名称
を伝える。

【００４４】ステップ３０４において、パブリッシャは
イベントを公表する時刻がくるまで待機する。上述の例
におけるように、パブリッシャによっては、発生する毎
に各イベントを公表するものもある。他のパブリッシャ
は、１日１回のように、指定した時刻まで待ち、その時
刻に未公表のイベントを全て公表する。例えば、第１の
パブリッシャは、人間のオペレータが売買注文をシステ
ムに入力したときはいつでも、イベントを公表するよう
にしてもよい。第２のパブリッシャは時間毎に同一タイ
プのイベントを公表するようにしてもよい。一旦パブリ
ッシャがイベントを作成することを決定したなら、その
公表すべきイベントに相応しいフォーマットを有するＣ
構造体を作成する、イベント操作ルーチンの１つをコー
ルする（ステップ３０６において）。

【００４５】ステップ３０８において、パブリッシャ
は、イベント操作ルーチンの１つをコールし、未公表の
イベントを公表する。これについては、以下で更に詳し
く論ずることにする。ステップ３１０において、パブリ
ッシャは、イベント操作ルーチンの１つをコールし、公
表済みのイベントを廃棄する。（通常、ここに記載する
実施例では、イベントの割り当てを担うあらゆるエンテ
ィティがイベントの破棄も担当する。）

【００４６】ステップ３１２において、パブリッシャは
実行を中止べきか否かを判断する。中止すべきでない場
合、制御はステップ３０４に戻る。中止すべき場合、ス
テップ３１４において、パブリッシャはハブからそれ自
体を抹消し、実行を中止する。広告はハブ内に保持さ
れ、パブリッシャがそれらのイベントを実行し送出可能
であることを示す。この情報は、サブスクライバへの経
路を構築する際に必要となる。これについては、以下で
説明する。図示していないが、同一ハブに接続されてい
る他のパブリッシャも、図３のステップとは非同期に動
作することも可能である。

【００４７】サブスクライバは、特定のイベント・タイ
プのイベントに予約を行う。図４は、図１のサブスクラ
イバが、サブスクライバの処理の間に実行するステップ
を示すフロー・チャートである。サブスクライバは、ま
ず最初に、それ自体をハブのクライアントとして登録す
る。次に、各予約について、「コールバック」手順を登
録する。

【００４８】ステップ４０２に示すように、サブスクラ
イバは次に、それが接続されているハブに、それ自体を
クライアントとして登録する。次に、サブスクライバ
は、ハブを通じて受信を希望するイベント・タイプに対
して「予約」を登録する。（サブスクライバは、どのタ
イプのイベントが広告されているかを調べるために、ハ
ブを閲覧することができる。）予約は、イベントのタイ
プを指定し、更に、サブスクライバがあるタイプのイベ
ントのみを受信することを希望していることを示す「フ
ィルタ」も指定することができる。この場合、イベント
はあるフィールドにある値を有する。

【００４９】ステップ４０４において、各予約に対し
て、パブリッシャは、所定の「コールバック」手順を定
義する。コールバック手順は、サブスクライバがあるタ
イプのイベントを受信したと判断したときはいつでも、
ハブによって起動される。コールバックのフォーマット
は、本発明を実施する各オペレーティング・システムに
よって異なる場合があり、コールバック手順は、実際に
は、イベントを受信するときに実行されているいずれか
の手順とすることができる。例えば、図４のステップ４
０６において、コールバック手順は、イベントの内容を
印刷することができる（そのタイプのイベントを印刷す
るように設計されたイベント操作手順の１つを用い
て）。コールバック手順は各予約毎に定義されるので、
コールバック手順は、サブスクライバが予約しようとし
ている各タイプのイベントに対して定義しなければなら
ない。ここに記載する実施例では、コールバック手順に
渡されたイベントは、コールバック手順が終了すると廃
棄される。したがって、サブスクライバがそのイベント
のいずれかの情報を保持することを望む場合、その情報
をコールバック手順の中でイベント外部にコピーする必
要がある。

【００５０】サブスクライバは、実行を中止する時刻が
くるまで繰り返す（ステップ４０８を参照）。指定され
たタイプのイベントおよび値がハブによって受信される
と、このループの間、０回、１回または多数回、コール
バック手順を活性化することができる。サブスクライバ
が予約したイベントが受信された場合、ステップ４０６
においてコールバック手順を実行する。ステップ４０８
において、サブスクライバが切断する時であると判断し
た場合、サブスクライバは任意に、その予約を抹消し、
それ自体をハブから抹消し、実行を中止する。予約をハ
ブ内に保持することによって、切断中に、以降のイベン
トを受信することも可能である。図示さないが、同一ハ
ブに接続されている他のサブスクライバも、図４のステ
ップとは非同期に、ステップを実行することも可能であ
る。

【００５１】以下の例は、Ｃプログラミング言語で書か
れており、パブリッシャおよびサブスクライバのソフト
ウエア例を示すものである。

【００５２】 /* *publish.c */ #include <nexus.h> #include "nxs_output/order_nxs.h" int main() { SalesOrder *event; nxsClientID id; nxsPublicationID pub_id; /* Register the Client and the publication */ nxsCreateClient ("order publisher", NULL,NULL , 0, &id); nxsRegisterPublication (id, "order_advertisement", &pub_id); /* Create the event */ event = nxsCreate_SalesOrder(); event->customer_name = "Jim Nexus"; event->customer_address.street = "l2345 Anistreet"; event->customer_address.city = "Mountain View"; event- > customer_address.state = "CA"; event- > customer_address.zip = "95000"; /* Publish Event */ nxsPublish_SalesOrder (id,pub_id,event,0,0); /* Clean up */ nxsDestroy_SalesOrder(event); /* Unregister the publication and client */ nxsUnregisterPublication (id,pub_id); nxsDestroyClient (id); return (0); } /* * subscribe.c */ #include < nexus.h > #include "nxs_output/order_nxs.h" /* Callback function to be called when each event is received */ void event_callback ( nxsClientID id, nxsSubscription sub_id, nsxULong seq_num_high, nsxULong seq_num_low, SalesOrder *the_event, void *client_data) { char *st; printf("Event received!＼n"); st = nxsStringify_SalesOrder(the_event); printf(st); free(st); } int main(int argc, char **argv) { Sales Order *event; nxsClient ID id; nxsSubscriptionID sub_id; /* Register Client and subscription */ /* (Only subscribe to specific ZIP codes) */ nxsCreateClient ("order subscriber",NULL, NULL, 0,&id); nxsRegisterSubscription SalesOrder(id, "customer_address.zip ==95000", event_callback, NULL&sub_id); /* Main loop */ nxsMainLoop(id); /* Unregister subscription and client */ nxsUnregister Subscription(id,sub_id); nxsDestroyClient(id); return(0); }

【００５３】ＩＩＩ．ハブ図５は、図１のハブ１０６の詳細を示すブロック図であ
る。図１のハブ１０８，１１４、そして実際ここに記載
する実施例における他のハブも全て同様の構造を有す
る。ハブ１０６は、ネットワーク１２０を通じて（また
は直接）遠隔ハブ１０８，１１４に、そして０箇所以上
のパブリッシャ１０２および０箇所以上のサブスクライ
バ１０４に接続されている。また、ハブ１０６は、ハブ
の管理に関する情報５３０、そのクライアント（パブリ
ッシャおよびサブスクライバ）の管理に関する情報５３
２、およびシステム・イベント管理に関する情報５３６
を受信する。

【００５４】ハブ１０６への全ての入力およびハブ１０
６からの全ての出力は整列されている。例えば、遠隔ハ
ブ１０８およびサブスクライバ１０２からハブ１０６に
よって受信されたイベントは、ハブ１０６がそれらを処
理する時間を有するまで、各イベント・キュー５０２，
５０４の中に、イベントの優先度順に格納される。更に
他の例として、ハブ１０６が遠隔ハブ１１４およびサブ
スクライバ１０４に送るイベントは、ハブ１０６がそれ
らを送出する時間を有するまで、メモリ内の各イベント
・キュー５０６，５０８の中にイベントの優先度順に格
納される。ハブは、先入れ先出し方式を用いて、イベン
トの分配を行う。これが意味するのは、同一優先度レベ
ルを有する全てのイベントは、それらがパブリッシャか
ら受け入れられた順に、ハブ１０６によって送出される
ということである。優先度レベルが高い全てのイベント
は、それより優先度が低い待機中イベントよりも早く送
出される。ここに記載する実施例は、イベントがシステ
ム中を移動する際、単一のパブリッシャからの同様のイ
ベントの順序付けを維持することを保証する。これは、
例えば、更新の順序を保持しなければならないトランザ
クションの処理では、重要である。パブリッシャ間の順
序付けは、経路や可用性によって異なるので、保証され
ていない。

【００５５】また、図５はハブ１０６内部の、以下にあ
げる機能ブロックも示す。即ち、クライアント管理ブロ
ック５１０、イベント管理ブロック５１２、プリプロセ
ッサ・ブロック５１４、格納ブロック５１６、マッチ・
ブロック５１８、および遠隔管理ブロック５２０であ
る。クライアント管理ブロック５１０は、クライアント
の登録および抹消を扱う。イベント管理ブロック５１２
は、新たな接続、タイプ、経路、広告、および予約のよ
うなシステム・イベントの管理を扱う。プリプロセス・
ブロック５１４は、エンベロープ情報のイベントへの追
加のようなタスクを実行する。格納ブロック５１６は、
ハブのメモリである。マッチ・ブロック５１８は、経路
情報をイベントに追加し、イベントのルーティング(rou
ting)に関して以下に述べるような方法でイベント・フ
ィルタ処理を行い、他に接続されている適切なハブにイ
ベントを送出する。遠隔管理ブロック５２０は、システ
ム管理タスクを実行する。

【００５６】図８は、図１のハブ１０６のメモリ６９０
に格納されるデータ構造の図であり、図５の機能ブロッ
ク全てによってアクセス可能である。データ構造は、イ
ンストールされた広告のテーブル７００、登録済みクラ
イアントのテーブル７３０、登録済み公表のテーブル７
６０、および登録済み予約のテーブル７７０を含む。デ
ータは、パブリッシャおよびサブスクライバが図２、図
３、および図４の種々のステップを実行する際に、以下
のように図８のデータ構造の中に配置される。

【００５７】図２のステップ２０２は、インストール済
み広告テーブル７００のエントリを満たす。

【００５８】図３および図４のステップ３０２，４０２
は、登録済みクライアント・テーブル７３０のエントリ
を満たす。ユーザ名フィールド７３４およびユーザ・パ
スワード・フィールド７３６はＮＵＬＬ値を有すると、
現ユーザＩＤを使用すべきことを指示することができ
る。ハブ名７３７およびテリトリ名７４０は、ＮＵＬＬ
にセットすると、デフォルトのハブおよびテリトリの使
用を指示することができる。フラグ７４２は、例え
ば、"call-back-on-any-thread"（いずれかのスレッド
にコール・バックする）を含み、イベント・コール・バ
ックが新たなスレッドに到来することを示す。

【００５９】図３のステップ３０２も、登録済み公表テ
ーブル７６０のエントリを満たす。

【００６０】広告名７６４は、ハブにインストールされ
た広告の名称である。図４のステップ４０４も、登録済
み予約テーブル７７０のエントリを満たす。内容フィル
タ７７４については以下で論じる。コールバック手順の
名称は、サブスクライバ内に（ＣＡＰＩによって）局
所的に保持される。ＡＰＩは、予約ＩＤからのコールバ
ックを発見する。クライアント・データ・フィールド
は、これもＡＰＩによって保持され、予約に関連する情
報を、各イベントのコールバックによって返すことがで
きるようにする。戻される情報は、予約アプリケーショ
ン(subscribing application)にとって意味がある。

【００６１】以下の節では、サブスクライバが予約を登
録するときに指定可能な様々なタイプの内容フィルタに
ついて説明する。上述の例に示したように、サブスクラ
イバは、ハブが入来するイベントの流れにフィルタをか
け、ある基準と一致したイベントのみをサブスクライバ
に通すことを要求できる。フィルタは、好ましくは、予
約を登録するためのルーチンにパラメータとしてサブス
クライバが送った式の文字列(expression string)とし
て指定される。ここに記載する実施例における内容フィ
ルタに対する式の文字列のシンタックスは、以下の通り
である。（勿論、いずれの適切なシンタックスも使用可
能である）

【００６２】記号意味許されるタイプ＝等しい全ての基本タイプ！＝等しくない全ての基本タイプ＞より大きい数値および文字列タイプ＞＝、＜＝以上数値および文字列タイプ and 論理積式またはブーリアン or 論理和式またはブーリアン not 論理否定式またはブーリアン

【００６３】イベント属性名は、イベント内のどのフィ
ールドを比較すべきかを指定するために用いられる。サ
ブ・フィールド（構造内部のサブフィールド）は、ドッ
ト表記(dot notation)を用いて指定する。名称は、Ｃプ
ログラミング言語に精通している人には既知であるが、
列挙タイプ(enumerated type)とすることも可能であ
る。一旦内容フィルタを指定したなら、イベント・ルー
ティング(event routing)の間使用される。これについ
ては、以下で図９ないし図１３に関連付けて説明する。
予約に対して各内容フィルタを記述する情報は、図８の
フィールド７７４に格納される。

【００６４】図６は、図５のハブ１０６のメモリに格納
されるデータ構造を示す図である。全てのハブは同様の
データ構造を収容する。ここに記載するインプリメンテ
ーションは、分散型オブジェクト・モデルを使用する
が、あらゆる適切な組織的構造が使用可能である。図６
のデータ構造の詳細を図７に纏めておく。理想的なの
は、図６のデータ構造がシステム内の全広告を記述し、
近隣のハブに、クライアント・ハブがあるタイプのイベ
ントをどこに送出すべきかを示すことである。図１１お
よび図１３は、それぞれ、図６のデータ構造を移植する
ステップ、および図７のデータ構造を用いてハブ間でイ
ベントをやりとりするステップを記述するものである。
図１２は、データを移植されたデータ構造の一例を示
す。

【００６５】ハブ１０６（「クライアント・ハブ」）
は、サブスクライバである現ハブの各クライアント
（「クライアント」６８４および「S」６９５によって
示す）と、現ハブに接続されている各近隣のハブ（「近
隣ハブＡ」６９６および「近隣ハブＢ」６９７）を表わ
す、データ・オブジェクトを含む。現ハブは、その近隣
ハブの予約オブジェクトを追跡し続ける。予約オブジェ
クト「Ｓ」６５０は、各近隣ハブを通じて到達可能な全
てのサブスクライバを表わす。各近隣オブジェクト
は、"mycost"および"theircost"という２つの関連する
コスト値を有する。"mycost"は現ハブから近隣ハブに情
報を送るコストを表わす。"theircost"は、近隣ハブか
ら現ハブに情報を送るコストを表わす。"their cost"
は、以下で説明するように、経路を定義するために用い
られる。予約側ハブは、「公表側」ハブに、最も低い"t
heircost"でイベントの転送(deliver)を依頼する。"myc
ost"は、当該リンクを通じて情報を送るためには、現ハ
ブにどの位のコストが必要かを、近隣ハブに通知するた
めのみに使用することが好ましい。例えば、コストは、
財政的コスト、単位時間のコスト、便利さの尺度として
のコスト、またはその他のあらゆる適切なコストを表わ
すことができる。

【００６６】ハブ１０６は、システムに登録されている
各広告について（"RemoteAd"）オブジェクトを含む（即
ち、公表する意向毎。図２のステップ２０２参照）。各
RemoteAdオブジェクトは、１つ以上の"AdSource"オブジ
ェクトを指し示す。各AdSourceオブジェクトは、現ハブ
と、広告のパブリッシャが常駐するハブとの間のパス(p
ath)を表わす。各Adsourceオブジェクトは、その広告の
最初のパブリッシャへのパスに伴うコストを格納する。
したがって、各AdSourceに対する「コスト」値は、イベ
ントをそのソースから現ハブの近隣ハブまで、またはそ
の反対に現ハブまで送るための全コストを含む。

【００６７】各AdSourceオブジェクトは、関連する「シ
ンク・オブジェクト」(sink object)のリストを有す
る。（SinkCaおよびSinkNbは、単一のリストに位置付け
ることが好ましいが、図ではそのように示されていな
い。）各シンク・オブジェクトは、関連する予約のリス
トを有する。例えば、SinkCaは、RemoteAd５１０の広告
に一致する、クライアント６９４の全予約のリスト５０
５を有する。同様に、SinkNbは、RemoteAd５１０の広告
と一致した、近隣ハブＢの全予約（および近隣ハブＢを
通じて到達可能な全予約）のリスト５１５を有する。

【００６８】各近隣オブジェクトは、パブリッシャと当
該近隣オブジェクトとの間の全パスについてAdSources
を指し示すAdSourceRefリストを有する。これらの経路
は、以下で説明するように、ハブ間でシステム・イベン
トの経路を決定する際に用いる。

【００６９】ＩＶ．ハブ間におけるイベントのルーティ
ング図１１は、図１のハブ１０６，１０８，１１４が図６の
データ構造に移植する際に実行するステップの詳細を示
すフロー・チャートである。これらのステップは、ネッ
トワークを最初に初期化するときに実行する。続いて、
種々のハブが「システム・イベント」を発行し、ハブ接
続、イベント・タイプ、広告、ルーティング、予約等に
おいて変更があったことを、他のハブに伝える。追加資
料Ａは、本明細書の一部であり、この言及により本願に
も含まれるものとするが、ここに記載する実施例におい
てハブ間で渡すことができるシステム・イベント例の概
要を含む。

【００７０】図１１において、フロー・チャート内のス
テップに影響を与える、追加資料Ａのシステム・イベン
トの名称を、ステップの次に示す。ステップ１００２で
は、ハブが互いにシステム・イベントを送出し合い、ネ
ットワーク内のハブ間における物理的接続を定義する。
各ハブは、その近隣ハブへの物理的接続を表わす近隣オ
ブジェクトを作成する（図６参照）。ステップ１００４
において、ハブは互いにシステム・イベントを送出し、
広告を公表可能なイベントのタイプを定義する。各ハブ
は、全てのイベントを知っていることを確認する。この
ステップは、ハブをテリトリに追加するときに実行され
る。ステップ１００６において、パブリッシャに接続さ
れているハブが互いにシステム・イベントを送出する。
これらはハブ間で転送され、当該ハブ間で広告を分散す
る。例えば、追加資料Ａのシステム・イベント"NSX_SYS
_EVENT_CREATE_NEW_ADVERTISEMENTは、ハブにおいて、R
emoteAdオブジェクトを作成させる（図６参照）。

【００７１】ステップ１００８において、パブリッシャ
に接続されているハブは、他のハブにシステム・イベン
トを送出する。このシステム・イベントはハブ間で転送
され、パブリッシャのハブから他のハブへの経路を決定
する。（システム・イベント"NXS_SYS_EVENT_NEW_ROUTE
S"により、ハブ内にAdSourceオブジェクトを作成する
（図６参照））。経路の存在を登録するために、最初の
ハブが、広告名／ＩＤ、その（パブリッシャハブの）名
称およびテリトリ、ならびにイベントをパブリッシャハ
ブから現ハブまで送出する際にかかる費用を含む、シス
テム・イベントをその近隣ハブに送出する。ここに記載
するインプリメンテーションでは、コストは初期状態で
は０に設定される。各近隣ハブはこのプロセスを繰り返
し、当該ハブがイベントを受信した際の接続のコストを
加算する。各ハブでは、これがそのハブへの最初の経路
である場合、ローカル・クライアントをチェックし、予
約との一致を調べる（この動作の結果、"NEW_SUBSCRIPT
ION"システム・イベントが、"NEW_ROUTES"の送出元に得
られる。転送のために、各経路を別個に検討する。経路
は、それが受信されたハブ、発信ハブ(oroginating hu
b)、またはイベントを既に知っているハブには転送され
ない（以下で説明するように、ルーティング・リストか
ら判断する）。経路は、RemoteAdに対する最初の経路で
ある場合、またはそれが２番目の経路であり、目的地の
ハブが現行の経路提供元である場合にのみ、他のハブに
転送される。

【００７２】ステップ１０１０において、あるサブスク
ライバに接続されているハブが他のハブにシステム・イ
ベントを送出し、これら他のハブが知っている広告に対
する予約を登録する。（システム・イベント"NXS_SYS_E
VENT_NEW_SUBSCRIPTIONS"は、他のハブに予約を送出す
る。図６参照）。このシステム・イベントを受信したハ
ブは、予約オブジェクト（図６参照）を作成し、それに
ついてのRemoteAdを伝える。最少コストのパスを有する
AdSourceのことを、現AdSourceと呼ぶ。RemoteAdは、現
AdSourceに伝え、Neighborオブジェクトのシンク・オブ
ジェクトおよび予約オブジェクトを作成する（シンク・
オブジェクトおよび予約オブジェクトが存在しない場
合）。次に、シンクが、予約オブジェクトに対するSubs
criptionRef エントリ（例えば、５０５，５１２）を追
加する。他のハブから広告が受信された場合、現ハブ
は、新たな予約に対するシステム・イベントを、現最少
コスト経路の一部である近隣ハブに転送する。

【００７３】この予約の他のハブへの転送は、本発明の
重要な態様である。これは、本質的に、サブスクライバ
のハブからパブリッシャのハブに戻る予約の連鎖を作成
する。この連鎖は、パブリッシャとサブスクライバとの
間の最少コスト経路に従う。

【００７４】図１２は、サブスクライバのハブからパブ
リッシャのハブへの予約連鎖の作成例を示す。図１２は
５つのハブＡ，Ｂ，Ｃ，Ｄ，Ｅを示す。ハブＡにはパブ
リッシャＰが接続されている。ハブＣにはサブスクライ
バＳが接続されている。この例では、各接続は、「１」
のコストを有する。したがって、例えば、ハブＡおよび
Ｃ間には、全コスト＝２の経路があり、ハブＡおよびＣ
間には全コスト＝３の経路がある。

【００７５】図１２は、図１１のステップ１０１０の後
のハブのステータスを示す。接続、イベント・タイプ、
および経路がハブ間に分散され、RemoteAd, AdSource,
Neighbor, およびAdsourceRefオブジェクトが各ハブ
内で作成されている。

【００７６】この例では、サブスクライバＳがハブＣ上
で予約を登録する（Ｓがそれ自体をクライアントとして
登録したときに、ハブＣは既に予約オブジェクト１１０
２を作成しており、サブスクライバＳがハブＣのクライ
アントであることを示している）。次に、ハブＣは、
「新たな予約システム・イベント」（「予約」）を、当
該イベントに対する広告のパブリッシャへの最少コスト
上にある、近隣ハブに送信する。この例では、ハブＢか
らパブリッシャ・ハブＡまでのコストが「１」なので、
ハブＣは予約をハブＢに送信する。ハブＢが予約を受け
取ると、ハブＣに対する近隣オブジェクトに接続されて
いる予約オブジェクト１１０４を追加し、サブスクライ
バがハブＣまで到達可能であることを示す。

【００７７】次に、ハブＢは、イベントに対する広告の
パブリッシャへの最少コスト経路上にある、近隣ハブに
予約を送信する。本例では、ハブＡからハブＢへのコス
トが「０」であるので、ハブＢは予約をハブＡに送信す
る。ハブＡが予約を受信すると、ハブＢに対する隣接オ
ブジェクトに接続された予約オブジェクト１１０６を作
成し、予約がハブＢまで到達可能であることを示す。ハ
ブＡは、それ自体が予約されつつある広告の作成元ハブ
であるので、これ以上予約を送信しない。

【００７８】一旦図１２のデータ構造が確立されると、
パブリッシャＰが公表したイベントは、予約オブジェク
ト１１０６，１１０４，１１０２によって定義されたパ
スに沿って、サブスクライバＳに到達するまで、ハブ間
で送出される。

【００７９】図１３は、図１のハブが、公表したイベン
トをシステムのハブを通じて送信することによって、サ
ブスクライバにそのイベントを送出する際に実行するス
テップの詳細を示すフロー・チャートである。図１３の
ステップは、１）それ自体に接続されているパブリッシ
ャからのイベントを受信したハブ（ステップ１２０
２）、または２）近隣のハブからのイベントを受信した
ハブ（ステップ１２０３）によって実行される。図１３
のステップは、各イベントがシステム全体にわたって送
信される際に、種々のハブによって実行される。以下の
節では、図１３のステップを実行するハブのことを、
「現ハブ」と命名する。

【００８０】現ハブがそれに接続されているパブリッシ
ャの１つからのイベントを受信すると（ステップ１２０
２）、現ハブのプリプロセッサ５１４は、最初に「エン
ベロープ」をそのイベントに加える（ステップ１２０
４）。イベント・エンベロープのフォーマットについて
は、図９に関連付けて以下で説明する。プリプロセッサ
５１４は、次にステップ１２０４において、このイベン
トのイベント・タイプがハブに登録されているか否か判
断する。登録されていなければ、パブリッシャはこのイ
ベントを公表することができない。登録されていれば、
ステップ１２０６において、ハブはそのイベントを、ハ
ブの入来イベント・キューに入れて、更に処理を行う。
ここに記載する実施例では、イベント・キューは重複す
るイベントを破棄する（イベント・エンベロープの連番
またはタイム・スタンプによって判断する）。

【００８１】現ハブが近隣ハブからイベントを受信した
場合（ステップ１２０３）、近隣ハブはそのイベント
を、現ハブの入来イベント・キューに入れる。

【００８２】ステップ１２０８において、現ハブのフィ
ルタ５１８が、現ハブの入来イベント・キューからその
イベントを取り出す。次に、フィルタ５１８は、キュー
内で費やした時間量を示す、エンベロープの経過時間フ
ィールドを増分する。ステップ１２１０において、フィ
ルタ５１８は、ルーティング・ブロックをイベントに加
える。イベントを送信する各ハブは、他のルーチング・
ブロックを当該ブロックに加える。２つのルーティング
・ブロックのフォーマットを図１０に示す。

【００８３】ステップ１２１２において、現ハブは、特
定のAdSourceから来るイベントに関心がある全てのサブ
スクライバを表わす、「現」AdSourceオブジェクトの位
置を突き止める。これは、通常、現ハブとサブスクライ
バ間の最少コスト・パスを表わす（ここに記載する実施
例は、一旦AdSourceデータ構造が確立されたなら、再送
信は行わないことに注意されたい）。AdSourceオブジェ
クトの位置を突き止めるには、現ハブに対する全Remote
Adを探索するか（イベントが、現ハブに関係するパブリ
ッシャから来た場合）、あるいは近隣ハブに対するAdSo
urceRefリストを探索する（イベントが近隣ハブから来
た場合）。ステップ１２１６〜１２２２は、１つ以上の
サブスクライバにイベントを送出する。ステップ１２１
６〜１２２２は、AdSourceに関係する各シンク・オブジ
ェクト毎に実行される。したがって、ステップ１２１６
〜１２２２は、送信されたタイプのイベントを受信する
ことを要求した各サブスクライバのために実行される。

【００８４】ステップ１２１６において、イベントの存
続時間がエンベロープの経過時間よりも小さい場合、こ
のイベントは消滅し、これ以上現ハブによって送信され
ない（ステップ１２１８）。その他の場合、ステップ１
２２０において、フィルタ５１８は、イベントが、サブ
スクライバが指定したパラメータに該当する内容を有す
るか否かを判断する。サブスクライバは、イベント・タ
イプに予約した時点で、内容フィルタを指定している
（図８のフィールド７７４を参照）。例えば、あるサブ
スクライバは、ロサンゼルスに住んでいるカストマのた
めのSalesEventのみを受信することを要求した可能性が
ある。サブスクライバが指定した範囲の値をイベントが
有する場合、ステップ１２２２においてイベントはサブ
スクライバに送出される（以下で説明するように、直接
またはそのハブを通して）。各サブスクライバは異なる
内容フィルタを指定した可能性がある（あるいは、内容
フィルタを指定しない可能性もある）。例えば、第１の
サブスクライバが、カストマが住んでいるロサンゼルス
のSalesEventの受信希望を指定し、第２のサブスクライ
バが、カストマが住んでいるサンフランシスコのSalesE
ventの受信希望を指定した可能性がある。この例では、
イベントは第１のサブスクライバとは一致するが、第２
のサブスクライバとは一致しない。

【００８５】ステップ１２２２において、フィルタ５１
８は、一致したサブスクライバにイベントを送出する。
サブスクライバは、現ハブのクライアントであることも
あり、その場合イベントは直接サブスクライバに送出さ
れる。あるいは、サブスクライバは近隣のハブに、直接
的にまたは間接的に接続されている場合もある。一致し
たサブスクライバが近隣のハブに接続されている場合、
現ハブはイベントをその近隣ハブに送信する（エンベロ
ープのフィールド８０２から判断して、その近隣ハブが
イベントを発生したハブでない場合。図９参照）。ま
た、現ハブは、そのイベントを既に見たハブにも、当該
イベントを送信しない（イベントに添付されているルー
ティング・ブロックから判断する。図１０参照）。

【００８６】ここに記載する実施例では、現ハブは、近
隣ハブが１つ以上の一致する予約を有していても、この
近隣ハブにイベントを送信するのは１回のみである。し
たがって、図６の予約オブジェクト６５１がイベントと
一致した場合、そのイベントを近隣ハブＢに転送する。
予約オブジェクト６５２もそのイベントと一致する場
合、近隣ハブＢに２回目のイベント送出を行う必要はな
い。近隣ハブＢがこのイベントを受信すると、これも図
１３のステップを実行し、そのクライアントのサブスク
ライバのいずれかがイベントと一致するか否かを判断す
る。

【００８７】図９は、イベントのエンベロープ・データ
構造のフォーマットを示す。図５のプリプロセッサは、
イベントが公表される前に、そのサブスクライバから受
信したイベントにエンベロープを加える。エンベロープ
は、各イベントに付随し、起点ハブ８０２、広告名８０
４、パブリッシャ名８０６、テリトリ名８０８、初期タ
イム・スタンプ８１０、存続時間８１２、優先度８１
４、フラグ８１６、および経過時間フィールド８２２を
含む。フラグは、ここに記載する実施例では、使用しな
い。別の実施例では、フラグは、例えば、イベントが
「永続的」か、あるいは「一時的」かを示す場合もあ
る。

【００８８】図１０は、イベントの２つのルーティング
・ブロックのフォーマット例を示す。各ハブは、それが
それ自体を通じて送信するイベントに、ルーティング・
ブロックを追加する。ＡＰＩは、イベントがあるサブス
クライバに到達するために取った実際の経路についての
情報を返す、get_current_route_infoルーチンも含む。
ルーティング情報は、各訪問ハブ毎に１つのエントリ
で、リンクされたリストとして、システムによって格納
される。各エントリは、現ハブに対する出立タイム・ス
タンプ、現ハブのハブ名、および現ハブのテリトリ名を
含む。また、任意にルーティング情報は、パブリッシャ
によってイベントに最初に割り当てられる、６４ビット
の連番を含む。

【００８９】Ｖ．テリトリ図１の各テリトリ１３０，１４０は、共通のイベント辞
書を有するハブの集合である。テリトリは組織を反映
し、地理や直接物理的接続性(direct physical connect
ivity)に結びつける必要はない。ここに記載する実施例
では、１テリトリ内のハブは全て完全に接続されていな
ければならない。なぜなら、広告情報はテリトリ間を跨
いで転送されないからである。したがって、あるテリト
リ内の２つのハブ間には、このテリトリを離れる必要な
く、間接的な場合もあるが、常にいくつかの経路があ
る。好適実施例では、テリトリの階層が存在し、レベル
が低い方のテリトリはそれらの親テリトリのイベント辞
書を継承する。例えば、ある会社が、各支店に１つのテ
リトリを有するように選択を行うことがあり、これら全
てがある「社内イベント」を理解している。

【００９０】１つのハブは、１つのテリトリのみに属す
ることが望ましい。クライアント（パブリッシャまたは
サブスクライバ）がハブに接続するとき、どのテリトリ
またはテリトリにそれが属するかを指定する。異なるテ
リトリでは、イベント、例えば、SalseOrderの意味が異
なる場合があるので、クライアントは１つのテリトリに
属さなければならない。ここに記載する実施例では、各
ハブは所定のデフォルトテリトリを有し、アプリケーシ
ョン開発者がテリトリを指定しない場合、これが用いら
れる。

【００９１】別の実施例では、多重テリトリハブが会社
間通信には特に有用である。２つの会社が、ここに記載
する本発明の実施例を使用して通信を行うことを決定し
た場合、共有すべきいくつかのイベント・タイプおよび
フォーマットについて合意し、共同テリトリ(joint ter
ritory)を設定することができる。テリトリ情報は広告
の一部として保持されるので、２つの会社を接続するハ
ブは、この共同テリトリのイベントのみを転送する。こ
れについては、イベントのルーティングに関連付けて以
下で説明する。

【００９２】ＶＩ．データベース接続性 (database con
nectivity) 図１４は、図１のネットワーク１２０に組み込まれたデ
ータ・ベース・アプリケーション１３０２のブロック図
である。データベース・アプリケーション１３０２は、
インターフェース・ルーチン１３０４を有するデータベ
ース・ライブラリを含み、ユーザがデータ・ベース１３
０８内の情報にアクセスできるようにする。データ・ベ
ース１３０８は、例えば、オラクル(Oracle)、サイベー
ス(Sybase)、またはインフォミックス(Informix)で作成
されたデータ・ベースとすることができる。本発明は、
トランザクション・モニタと共に動作可能な適切なデー
タ・ベースであれば、どれを用いても実施可能である。

【００９３】図１４は、トランザクション・モニタ１３
０６も含む。トランザクション・モニタ１３０６は、ト
ランザーク・コーポレーション(Transarc Corporation)
が製造するエンシーナ・トランザクション・モニタ(Enc
ina transaction monitor)であることが好ましい。ま
た、例えば、ノベル(Novell)が製造するツクセド・トラ
ンザクション・モニタ(Tuxedo transaction monitor)と
することもできる。あるいは、適切なトランザクション
・モニタのいずれかを用いて、本発明を実施することが
できる。データ・ベース・ライブラリ１３０４を有する
データ・ベース接続部１３１０は、ネットワーク１２０
に接続し、ネットワーク１２０とのデータ送受信を行
う。データ・ベース接続部１３１０は、ハブ機能を実行
するソフトウエアを含んでもよく、あるいは別個のハブ
に接続してもよい。図１４において、データ・ベース・
アプリケーション１３０２はデータ・ベース１３０８に
情報を送出する。データ・ベース・アプリケーション１
３０２も、データ・ベース１３０８からの情報を要求
し、その情報を人が読むことのできる形態で表示する。

【００９４】データ・ベース接続部１３１０は、パブリ
ッシャ、サブスクライバ、または双方とすることができ
る。データ・ベース接続部１３１０がパブリッシャであ
る場合、例えば、データ・ベース１３０２において値の
変更がある毎に、イベントを公表する。また、例えば、
規則的な時間間隔でイベントを公表し、最後の公表以降
データ・ベースにおいて更新されたデータを反映するこ
とも可能である。データ・ベース１３０２がサブスクラ
イバである場合、受信したイベントの情報をデータ・ベ
ース１３０２内に格納する。ここに記載する実施例は、
データ・ベース接続部１３１０用のコンフィギュレーシ
ョン・ファイル（図示せず）を含む。コンフィギュレー
ション・ファイルは、例えば、データベース接続がパブ
リッシャか、サブスクライバか、あるいは双方かを指定
する。また、コンフィギュレーション・ファイルは、例
えば、公表すべきおよび／または予約すべきイベントの
記述も含む。また、コンフィギュレーション・ファイル
は、データ・ベース１３０８のレイアウトに関する情報
も指定する。

【００９５】図１５は、データ・ベースがサブスクライ
バであるときに実行されるステップを示すフロー・チャ
ート１４００である。例えば、ネットワーク１２０から
イベントを受信すると、これらイベントからのデータが
データ・ベース１３０２に追加される。フロー・チャー
ト１４００は、データ・ベース接続部１３１０が既にそ
れ自体およびその予約（群）を、上述のように、登録済
みであると仮定する。ステップ１４０２においてデータ
・ベース接続部１３１０がイベントを受信すると、デー
タ・ベース接続部は、そのイベント内のデータを、デー
タ・ベース１３０６内にマップし格納する。データがデ
ータ・ベース内に完全に格納されるまでは、このデータ
はデータ・ベースには「受け入れられて」いない。「受
け入れ」(commitment)とは、データが実際にデータ・ベ
ースに入力されることを意味する。データへの変更が受
け入れられるまで、これらは一時的格納場所に保持され
る。したがって、「受け入れ」処理が実行されるまで
は、受け入れられていないデータは、いつでも「ロール
バック」(rolled back)するこができ、データ・トラン
ザクションを取り消すことができる。「ロールバック」
の間、一時的格納部におけるデータの変更は廃棄され、
データ・ベースは、変更が行われた前のその状態に保持
される。状況によっては、データ・ベース接続部１３１
０は、あるイベントを受信するまでは、「受け入れ」コ
マンドを発行しない。

【００９６】図１６は、データ・ベースがパブリッシャ
である場合に実行されるステップを示すフロー・チャー
ト１５００である。例えば、人間のユーザがデータの追
加、削除、および修正をデータ・ベース１３０２におい
て行うと、データ接続部１３１０はネットワーク１２０
に周期的なイベントを送出する。ステップ１５０２にお
いて、トランザクション・モニタ１３０６は、データ・
ベース接続部１３１０が「ノード」であることの通知を
受ける。このステップを実行する正確な方法は、トラン
ザクション・モニタ１３０６の製造者によって異なる
が、一般的にこのステップは当業者にはよく知られてい
る。ステップ１５０４において、前述のように、データ
・ベース接続部１３１０は、それ自体およびその広告
（群）を登録する。

【００９７】ステップ１５０６〜１５１２は、例えば、
ユーザがデータ・ベース１３０８に変更を加える場合に
実行されるステップを示す。ステップ１５０６において
データ・ベース・トランザクションが開始すると、デー
タ・ベース１３０８は、トランザクション・モニタに、
例えば、Ｘ／ＯｐｅｎのＸＡプロトコルを用いて、トラ
ンザクションが開始したことを通知する。トランザクシ
ョン・モニタ１３０６は、データ・ベース接続部１３１
０に、トランザクションが発生していることを通知し、
データ・ベース接続部１３１０はトランザクションに注
目する。ステップ１５０８において、ユーザがデータ・
ベースに変更を加えるが、ユーザは変更を受け入れてい
ない）。

【００９８】ステップ１５０７において、ユーザ（また
は、変更を加えるソフトウエア）が、トランザクション
を受け入れるべきことを指示すると、ステップ１５１０
において、この事実はトランザクション・モニタ１３０
６に伝達される。トランザクション・モニタ１３０６は
データ・ベース接続部１３１０に通知し、受け入れられ
たデータをデータ・ベース１３０８から引き出し、この
受け入れられたデータを含むイベントを公表する。イベ
ントは図１３に示すように公表される。ステップ１５１
２においてユーザ（または、変更を加えるソフトウエ
ア）が、トランザクションをロールバックすることを指
示すると、この事実はトランザクション・モニタ１３０
６に伝達される。トランザクション・モニタ１３０６が
データ・ベース接続部１３１０に報告すると、データ・
ベース接続部１３１０はステップ１５０６の変更につい
て「忘れ」、イベントを公表しない。このように、ここ
に記載する実施例は、商用データ・ベース処理には一般
的な受け入れおよびロールバック処理を考慮に入れてい
る。

【００９９】別の実施例において、使用するデータ・ベ
ース生産物１３０２がトランザクション・モニタを含ま
ない場合、データ・ベース１３０８と接続するときは、
データ・ベース接続部１３１０がトランザクション・モ
ニタとして機能する。更に、データ・ベース接続部１３
１０は、このコンフィギュレーションでは、パブリッシ
ャおよび／またはサブスクライバとしても機能する。デ
ータ・ベース１３０８は、それが実際にはデータ・ベー
ス接続部１３１０に接続されていても、トランザクショ
ン・モニタに接続されていると考える。

【０１００】ＶＩＩ．要約要約すると、本発明の好適実施例は、情報を公表する複
数の「パブリッシャ」エンティティと、情報を要求し使
用する複数の「サブスクライバ」エンティティとを含
む。パブリッシャおよびサブスクライバは、ネットワー
クを通じて互いに接続されている。ネットワークは、そ
のルーティングが「内容を基本とした」、「格納および
転送」ネットワークである。

【０１０１】本発明の上述の実施例では、情報の基本単
位を「イベント」と呼ぶ。パブリッシャはイベントを公
表し、サブスクライバは、当該サブスクライバが定義し
た基準と一致するイベントに予約する。公表および予約
は非同期に行われる。パブリッシャおよびサブスクライ
バは、直接互いについての知識を有していない。システ
ムは、パブリッシャから公表されたイベントを受信し、
そのイベントを全ての適切なサブスクライバに送信す
る。各サブスクライバは、当該サブスクライバが指定し
た予約基準と一致する場合のみ、システム上で公表され
た全てのイベントを受信することが保証されている。

【０１０２】上述の本発明の実施例は、レガシ・システ
ム、レガシ・アプリケーション、およびレガシ・ハード
ウエアをシステムに容易に統合し、ユーザがそのシステ
ムを使用するために修得しなければならない情報量を最
少に抑えようとするものである。レガシ・データ・ベー
スは、データ・ベース接続部によって、ネットワークに
予約することができる。この場合、データ・ベース接続
部は、パブリッシャ、サブスクライバ、または双方とす
ることができる。

【０１０３】ここに開示した本発明の明細書および実施
を検討することから、他の実施例も当業者には明白であ
ろう。明細書および例は例示としてのみ解釈し、本発明
の真の範囲は特許請求の範囲によって示されるものであ
ることを意図するものである。

【０１０４】追加資料Ａ（４４頁）６．０システム・イベントハブ間で通信を行うために２３個のシステム・イベント
が用いられる。これらは、通常のイベントのヘッダ構造
のいくつかを共有するが、その他の場合、通常のイベン
ト・コード・パスとは完全に異なり、その外側で処理さ
れる。システム・イベント構造は、include/nxs_syspac
kP.hhの中で定義される。 typedef struct nxsSystemEventHeader{ nxsULong length; Byte length of the event nxsLong magic_number; Used to det ect bogus evnets nxsUlong nexus_version; Nexus version number nxsULong routing_offset; Nexus version number nxsULong routing_offset; nxsEventRoutingEntry nxsULong sys_event_type; NXS_SYS_EVENT_* nxsULong data_offset: String data } nxsSystemEventHeader; sys_event_typeの値は、transport/hub/sysevent.hhの
中で見つけることができる。全てのシステム・イベント
処理コードは、nexushub.hhにおいて宣言され（NexusHu
bの方法として）、sysevent.ccにおいて定義される。シ
ステム・イベント・データは、離間された別個のトーク
ンで構成されたストリングである。可能なトークンは以
下の通りである。string <space>および<nul>以外の
あらゆる文字のストリング /string/ ^_(／037)によって囲まれた^_(／037)を除
くあらゆる文字のストリング long 符号付き３２ビット値 ulong 符号なし３２ビット値（４５頁）オブジェクト参照はストリング形式で転送す
る。システム・イベントは、いくつかの通信スタイルに
用いられる。接続の確立の間、システム・イベントは、
ピア間メッセージ(peer-to-peer message)として用いら
れる。これらのイベントは、他のハブには見えない。他
のイベントの殆どは、テリトリの状態に影響を与え、テ
リトリグラフ(territory graph)全体に転送される。１
つのハブからそれ自体に数個のイベントを送ることがで
きる。 NXS_SYS_EVENT_CONNECT_HUB /string/ Sending hub name /string/ Sending hub territory string Sending hub imcoming EventQueue:: PushConsu mer ulong Receiving hub's cost ulong Sending hub's cost このイベントは、NexusAdmin::HubAdmin::connectHubへ
のコールの結果として送出される。送出側のハブは既に
接続のために、NeighborおよびEventQueueを作成してあ
る。受信側のハブもシステム・イベントを受信したとき
に、同様のことを行う。尚、送出側ハブは既に、NexusA
dmin::HubAdmin::connectHubへのアーギュメントを通じ
て、受信側の入来EventQueue::PushConsumerを有するこ
とに注意されたい。これが受信側ハブにとって最初の接
続である場合（テリトリを連結している）、テリトリの
共有データ（イベント・タイプ等）を獲得する必要があ
る。システム・イベントは、送出側ハブからこの情報を
要求するために用いられる（NXS_SYS_EVENT_REQUEST_EV
ENTTYPESおよびNXS_SYS_EVENT_REQUEST_ADVERTISEMENT
S）。ハブが既にテリトリのメンバである場合、その経
路をNXS_SYS_EVENT_NEW_ROUTESと共に送出元に送出す
る。受信側ハブは常に、NXS_SYS_EVENT_REQUEST_ROUTES
で、送出側からの経路を要求する。例えば、テリトリ名
が間違っていて、接続を行うことができない場合、受信
側はNXS_SYS_EVENT_CONNECT_FAILEDを送る。 NXS_SYS_EVENT_CONNECT_FAILED /string/ Sending hub name /string/ Sending hub territory /string/ Reason for connection failure 接続の確立ができなかったときに送る。データ構造を消
去する。 NXS_SYS_EVENT_DISCONNECT_HUB /string/ Sending hub name (or neighbor name) /string/ Sending hub territory このシステム・イベントは、それ自体または他のハブに
送ることができる。NexusAdmin::HubAdmin::disconnect
Hubへのコールの結果として、それ自体に送る。この場
合、最初のアーギュメントは近隣ハブの名称である。ハ
ブは同様のイベントを近隣（送出側ハブの名称を含む）
に送出し、接続遮断を行う。これによって、次のシステ
ム・イベントが送出される。NXS_SYS_EVENT_FAIL_SUBSC
RIPTIONS, NXS_SYS_EVENT_DELETE_ROUTES, および NXS
_SYS_EVENT_DELETE_ADVERTISEMENTS。一旦接続消去イベ
ントが送出されると、NXS_SYS_EVENT_END_OF_STREAMが
伝えられる。（４６頁）イベント・シーケンスは、NXS_SYS_EVENT_DI
SCONNECT_HUBを受信した近隣ハブ上で同一である。接続上で見られる最後のイベントを示す。データ構造を
消去する。 NXS_SYS_EVENT_NEW_EVENTTYPE_FILESを用いて、送出側
にイベント・タイプを送出する。 NXS_SYS_EVENT_NEW_EVENTTYPE_FILES long Number of files F long Number of types T Repeated F times: /string/ .nexus file contents /string/ .ifr file contents Repeated T times: string Event type name IFRおよびNexusをIFRにロードし、与えられたイベント
・タイプを作成する。イベントは、送信元および既にそ
のイベントを見た近隣(neighbors)を除いて、全ての接
続されている近隣に送る。 NXS_SYS_EVENT_FORWARD_EVENTTYPE_FILE ulong Address of EventTypeFile state long Number of event types T Repeated T times: string Event type name イベント・タイプ・ファイルおよびイベント・タイプを
全ての接続されている近隣に送出する。イベント・タイ
プが作成されたときまたは更新されたときは、それ自体
にのみ送出する。 NXS_SYS_EVENT_NEW_ADVERTISEMENTSを用いて、送出側ハ
ブに全ての広告を送り出す。 NXS_SYS_EVENT_NEW_ADVERTISEMENTS long Number of Advertisements A （４７頁） Repeated A times: /string/ Advertisement name /string/ Event type name long Priority string Storage mode; "p" or "t" for persistent or transient ulong Time to live (seconds) /string/ Originating hub name /string/ Originating hub territory リストにある広告に対するRemoteAdを作成する。発信ハ
ブは、当該広告を作成したところである。システム・イ
ベントは、送出元および当該イベントを既に見た近隣を
除いて、全ての接続されている近隣に送られる。送出側ハブは接続を使用する用意ができている。受信側
も用意ができている場合、NXS_SYS_EVENT_CONNECTION_R
EADYを用いて応答する。接続が既に確立している場合、
このシステム・イベントは無視される。指名された広告を全ての接続されている近隣に送出す
る。広告を作成したときは、それ自体にのみ送出する。 NXS_SYS_EVENT_CHANGE_ADVERTISEMENT /string/ Advertisement name /string/ Originating hub name /string/ Originating hub territory long Priority string Storage mode; "p" or "t" for persistent or transient ulong Time to live 一致するRemoteAdを所与の値で更新する。このシステム
・イベントは、送出元およびこのイベントを既に見たハ
ブを除いて、全ての近隣に送られる。 NXS_SYS_EVENT_DELETE_ADVERTISEMENT long Number of Advertisements A Repeated A times: /string/ Advertisement name /string/ Originating hub name /string/ Originating hub territory （４８頁）付随するRemoteAdsおよび関連するデータ構
造を削除する。広告が削除されるときに、発信ハブによ
って送出される。このシステム・イベントは、送出元お
よびこのイベントを既に見たハブを除いて、全ての近隣
に転送される。 NXS_SYS_EVENT_NEW_ROUTESを用いて、全てのルーティン
グ情報を送出元に送り出す。 NXS_SYS_EVENT_NEW_ROUTES long Number of routes R Repeated R times: /string/ Advertisement name /string/ Originating hub name /string/ Originating hub territory long Cost 送出元から所与の広告までの所与のコストでの経路の存
在を記録する。AdSourceオブジェクトが作成され、これ
が当該広告への最初の経路である場合、ローカル・クラ
イアントをチェックし、予約との一致を調べる。この結
果、NXS_SYS_EVENT_NEW_ROUTESの送出側へのNXS_SYS_EV
ENT_NEW_SUBSCRIPTIONSが得られる。各経路は、転送に
ついて、別個に検討される。経路は、送出元、発信ハ
ブ、または当該イベントを既に見たハブには転送されな
い。また、ルートがRemoteAdに対する最初の経路である
場合、または２番目の経路であり目的地のハブが現経路
の供給元である場合にのみ、そのルートが転送される。
転送されるイベントのコスト・フィールドは、イベント
を受信した接続のコストだけ増分される。このシステム
・イベントは、接続設定の終了を印すこともできる。イ
ベントが未だ完全に接続されていない近隣から来た場
合、NXS_SYS_EVENT_CONNECTION_READYがこの近隣に送出
される。 NXS_SYS_EVENT_CHANGE_ROUTES long Number of route changes R /string/ Originating hub name /string/ Originating hub territory Repeated R times: /string/ Advertisement name long Cost 経路のコストを変更する。一致するRemoteAdおよびAdso
urceを発見し、そのコスト値を更新する。このシステム
・イベントは、送出元およびこのイベントを既に見た近
隣を除いて、全ての近隣ハブに送られる。 NXS_SYS_EVENT_DELETE_ROUTES long Number of routes R Repeated R times: （４９頁） /string/ Advertisement name /string/ Originating hub name /string/ Originating hub territory 所与の広告(RemoteAd)に対する経路(Adsource)を削除す
る。この経路によって供給されたあらゆる予約は失われ
る。この結果、NXS_SYS_EVENT_FAIL_SUBSCRITIONSが、
広告に対して予約を登録してある近隣に送られる。削除
された各経路の転送は別個に検討されるが、広告への最
後の経路が除去されたとき場合のみである。このシステ
ム・イベントは、送出元および発信ハブには送り出され
ない。 NXS_SYS_EVENT_CHANGE_CONNECTION /string/ Sending hub name /string/ Sending hub territory long Delta to sending hub's connection cost それらの接続に対するコストを更新する。 NXS_SYS_EVENT_NEW_SUBSCRIPTIONS long Number of subscriptions S Repeated S times: /string/ Advertisement name /string/ Advertisement hub name /string/ Advertisement hub territory /string/ Filter expression luong Owner id in sender ulong Subscription id in sender 所与の広告に対して、送出元からの予約を登録する。送
信側近隣上に予約を作成し、それについてRemoteAdに伝
える。RemoteAdは、Neighborに対してSinkを作成する現
Adsourceに伝える（未だ存在しない場合）。Sinkは、そ
の予約に対するSubscriptionRefを追加する。広告が他
のハブからである場合、新しい予約に対するシステム・
イベントを、現経路を供給する近隣に送り出す。所有者
ｉｄおよび予約ｉｄを用いて、予約が取り消されるとき
にその位置を突き止め、それが失われるときその識別を
行う。予約の登録中に不履行があった場合、NXS_SYS_EV
ENT_FAIL_SUBSCRIPTIONSが送出元に返される。 NXS_SYS_EVENT_CANCEL_SUBSCRIPTIONS long Number of subscriptions S Repeated S times: ulong Owner id in sender ulong Subscription id in sender （５０頁）リスト上の予約を取り消す。このイベント
は、それ自体または近隣から見ることができる。全ての
現AdSourceからの予約への全ての参照を除去する。これ
によって、Sinkを所有するSubscriptionRefによる予約
への参照を全て削除する。取り消しは、予約を供給した
可能性がある全ての近隣に送り出される。 NXS_SYS_EVENT_FAIL_SUBSCRIPTIONS long Number of failures S Repeated S times: ulong Owner id in receiver ulong Subscription id in receiver /string/ Hub name where failure occurred /string/ Territory where failure occurred /string/ Failure reason AdSourceからの予約への参照を除去する。予約自体は、
不履行による影響を受けない。予約が近隣からである場
合、不履行は発信ハブに戻される。新たな予約を、それを供給可能な近隣に送り出す。全て
の一致するRemoteAdにこの予約について伝える。各Remo
teAdは、クライアントに対してSinkを作成した、その現
AdSourceに伝える（まだ存在していない場合）。Sinkは
この予約に対するSubscriptionRefを追加する。ローカ
ルでない各RemoteAdに対して、現ソースにNXS_SYS_EVEN
T_NEW_SUBSCRIPTIONSを送出する。イベント・タイプを破壊する。このシステム・イベント
は、送出元およびこのイベントを既に見たハブを除い
て、全ての接続されている近隣に転送される。

【図面の簡単な説明】

【図１】本発明の好適実施例によるネットワーク型コン
ピュータ・システムのブロック図。

【図２】図１のハブ上の、パブリッシャのようなアプリ
ケーションをインストールするために実行するステップ
を示すフロー・チャート。

【図３】図１のパブリッシャがイベントを公表する際に
実行するステップを示すフロー・チャート。

【図４】図１のサブスクライバがイベントに予約する際
に実行するステップを示すフロー・チャート。

【図５】図１のハブの詳細を示すブロック図。

【図６】図５のハブのメモリに格納されるデータ構造を
示す図。

【図７】図６のデータ構造の詳細を纏めた図。

【図８】ハブのクライアントについての情報を記憶する
目的のために、図５のハブのメモリに格納される追加の
データ構造を示す図。

【図９】イベントのエンベロープ・データ構造のフォー
マットを示す図。

【図１０】イベントのルーティング・ブロックのフォー
マットを示す図。

【図１１】図１のハブが図６のデータ構造に移植する際
に実行するステップの詳細を示すフロー・チャート。

【図１２】データを移植された図６のデータ構造の例を
示す図。

【図１３】図１のハブが、公表されたイベントをサブス
クライバに送出する際に実行するステップの詳細を示す
フロー・チャート。

【図１４】図１のネットワークに組み込まれた、データ
・ベース・アプリケーションのブロック図。

【図１５】データ・ベースがサブスクライバであるとき
に実行されるステップを示すフロー・チャート。

【図１６】データ・ベースがパブリッシャであるときに
実行されるステップを示すフロー・チャート。

【符号の説明】

１００ネットワーク型コンピュータ・システム１０２，１１０，１１６パブリッシャ１０４，１１２，１１８サブスクライバ１０６，１０８，１１４ハブ１２０ネットワーク１３０，１４０テリトリ５０６，５０８イベント・キュー５１０クライアント管理ブロック５１２イベント管理ブロック５１４プリプロセッサ・ブロック５１６格納ブロック５１８マッチ・ブロック５２０遠隔管理ブロック

───────────────────────────────────────────────────── フロントページの続き (71)出願人 597004720 2550 ＧａｒｃｉａＡｖｅｎｕｅ，ＭＳＰＡＬ１−521，ＭｏｕｎｔａｉｎＶｉｅｗ，Ｃａｌｉｆｏｒｎｉａ 94043− 1100，ＵｎｉｔｅｄＳｔａｔｅｓｏｆＡｍｅｒｉｃａ (72)発明者ラファエル・ブラッチョアメリカ合衆国カリフォルニア州95014, カッパーティーノ，シーニック・サークル 10461 (72)発明者ティルマン・スポーカートアメリカ合衆国カリフォルニア州95131, サン・ホセ，オヤマ・プレイス 1510

Claims

【特許請求の範囲】

【請求項１】データ・ベースをパブリッシャ／サブスク
ライバ・ネットワークに接続することにより、前記デー
タ・ベースがイベントをネットワークに公表可能とする
方法であって、トランザクション・モニタ・コンピュータ・システムを
通じて、前記データ・ベースがデータ・ベース接続コン
ピュータ・プログラムと通信可能とするリンクを用意す
るステップと、データ・ベース接続部を、前記ネットワーク内のパブリ
ッシャ・ハブとして設定するステップと、前記データ・ベースにより、入力を前記データ・ベース
内のデータを変更するユーザから受け取るステップと、前記トランザクション・モニタに、前記データが変更さ
れたことを通知するステップと、前記変更データを受け入れるべきことを示す入力をユー
ザから受信するステップと、前記トランザクション・モニタに前記変更データを受け
入れることを通知するステップと、前記データ・ベース接続部によって、前記データを受け
入れたという前記トランザクション・モニタからのメッ
セージにしたがって、前記変更データにしたがって、前
記ネットワークに、公表されたイベントを送出するステ
ップと、から成り、前記ステップはデータ処理システム
によって実行されることを特徴とする方法。
【請求項２】請求項１記載の方法であって、更に、前記変更データをロール・バックすべきことを指示す
る、ユーザからの入力を受け取るステップと、前記トランザクション・モニタに、前記変更データをロ
ール・バックすることを通知するステップと、前記データ・ベース接続部によって、前記ロールバック
にしたがって、前記変更データを前記ネットワークに送
ることを自制するステップと、を含むことを特徴とする
方法。
【請求項３】データ・ベースをパブリッシャ／サブスク
ライバ・ネットワークに接続することにより、前記デー
タ・ベースがネットワーク上のイベントに予約できるよ
うにする方法であって、データ・ベース接続コンピュータ・プログラムが前記デ
ータ・ベースと通信可能とするリンクを用意するステッ
プと、前記データ・ベース接続部を、前記ネットワークにおけ
るサブスクライバ・ハブとして設定するステップと、前記データ・ベース接続部によって、前記ネットワーク
からイベントを受信するステップと、前記データ・ベース接続部によって、前記受信したイベ
ントに応じたデータを前記データ・ベースに送出するス
テップと、前記データ・ベース接続部によって、前記データ・ベー
ス内に前記データを受け入れるステップと、から成り、
前記ステップはデータ処理システムによって実行される
ことを特徴とする方法。
【請求項４】請求項１記載の方法であって、更に、前記データ・ベース接続部によって、前記イベントをそ
の近隣ハブの１つに送出するステップを含み、前記デー
タ・ベース接続部内のデータ構造は、前記近隣ハブが、
前記イベントに対するサブスクライバへの最少コスト上
にあることを示すことを特徴とする方法。
【請求項５】請求項１記載の方法であって、更に、前記データ・ベース接続部によってイベントを受信する
ステップと、前記データ・ベース接続部によって、前記データ・ベー
ス接続部のデータ構造にしたがって、前記データ・ベー
スが前記イベントに予約されていることを判定するステ
ップと、前記データ・ベース接続部によって、前記イベントを前
記データ・ベースに送出するステップと、を含むことを
特徴とする方法。
【請求項６】請求項１記載の方法であって、更に、前記データ・ベース接続部によってイベントを受信する
ステップと、前記データ・ベース接続部によって、前記データ・ベー
ス接続部のデータ構造にしたがって、近隣ハブが、前記
イベントに対するサブスクライバへの最少コスト経路上
に直接的または間接的に接続されていることを判定する
ステップと、前記データ・ベース接続部によって、前記イベントをそ
の近隣ハブに送出し、前記イベントを前記サブスクライ
バに転送可能とするステップと、を含むことを特徴とす
る方法。
【請求項７】請求項１記載の方法において、前記送出ス
テップは、前記データ・ベース接続部内のデータ構造が、前記デー
タベースがイベントのタイプを有するイベントに予約す
ることを示すとき、前記データ・ベース接続部によっ
て、前記近隣ハブの１つに前記イベントを送出するステ
ップを含むことを特徴とする方法。
【請求項８】請求項１記載の方法において、前記送出ス
テップは、前記データ・ベース接続部のデータ構造内の内容フィル
タが、前記データ・ベースがイベントの中で発見した値
を有するイベントに予約することを示すとき、前記デー
タ・ベース接続部によって、その近隣ハブの１つに前記
イベントを送出するステップを含むことを特徴とする方
法。