JPH076111A

JPH076111A - 修正可能な機能をサーバーで実行する方法

Info

Publication number: JPH076111A
Application number: JP5204346A
Authority: JP
Inventors: Reza Jalili; リザ・ジャリリ; Wayne L Wooten; ウェイン・エル・ウットン
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1992-10-23
Filing date: 1993-08-18
Publication date: 1995-01-10
Anticipated expiration: 2011-03-21
Also published as: US5423042A; JPH0827774B2

Abstract

(57)【要約】（修正有）【目的】サーバーが実行するように設計されていないク
ライアントのオブジェクト・コードを、サーバーがリコ
ンパイル又は再連係することなく実行する。【構成】クライアントは、実行可能なオブジェクト・コ
ードを、サーバー１００がそのオブジェクト・コードを
登録するのを許容する登録情報と共に、サーバーに供給
する。その登録情報は、オフジェクト・コードと共にサ
ーバー・メモリに記憶される。クライアントは、その登
録情報を操作することによって、サーバーにオブジェク
ト・コードを実行させる種々の要求をすることができ
る。サーバーの登録及び要求機能を使って、クライアン
トはオブジェクト・コードを実行させる時期及び頻度を
サーバーに指示する。サーバーは、クライアントの要求
に基づいてコード実行ステップにおけるそのアクション
を変更することによりこれを行う。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、サーバーと呼ばれるコ
ンピュータ・プログラムに関するものである。更に詳し
く言えば、サーバーが実行するように予め設計されてい
なかったオブジェクト・コードを、サーバー・プログラ
ムのリコンパイル又は再連係なしに、実行できるサーバ
ーに関するものである。

【０００２】

【従来の技術】サーバーは、他のプログラムに特定のサ
ービスを提供するコンピュータ・プログラムである。ク
ライアントは、サーバーのサービスを使うコンピュータ
・プログラムである。通常、サーバー・プログラムは、
クライアントからの要求を待ちながら１つの連続ループ
でアイドル稼働している。このプログラム・ループでは
いつも、サーバーは、特定の機能を遂行するためのクラ
イアントの要求により中断可能である。

【０００３】典型的には、クライアントは、そのクライ
アントが遂行し得ないタスクを遂行するようサーバーに
依頼する。例えば、プリント・サーバーは、プリンタ接
続機構を持った機械上にあり、プリンタでファイルを印
刷するためのクライアントからの要求を受付ける。クラ
イアントがファイルの印刷を望む時、それはファイルを
印刷する要求と共にそのファイルをサーバーに送る。ク
ライアントは、１つのコンピュータ上でサーバーと共に
走る別のプログラムであってもよく、何らかの形でサー
バー・コンピュータに接続された外部コンピュータ上で
走るプログラムであってもよい。

【０００４】一般に、サーバーは、プログラムされた機
能を遂行するための要求を受付けることができる。即
ち、サーバーは、言語を介してクライアントに利用可能
になる限定された機能セットを有する。その言語は、１
つのコマンドのような単純なものでもよく、プログラム
言語のような複雑なものでもよい。クライアントは、サ
ーバーの言語でサーバーとコミュニケートしなければな
らない。サーバーがクライアントの要求を理解した場
合、それは、それ自身のプログラムの適当な部分を実行
することによって、その要求を満足させる。「印刷」の
ような要求を受け取った場合、サーバーにおける所定の
予め連係した機能が実行される。サーバーのプログラム
のこの部分をオブジェクトと呼ぶことにする。

【０００５】オブジェクトは、オブジェクト言語と呼ば
れる、コンピュータが読み取り又は理解できる形で書か
れなければならない。このオブジェクト言語は、コンパ
イラと呼ばれる装置によって、人間が理解するプログラ
ム言語から作られる。従来技術では、サーバーが新しい
機能を遂行する前に、新しいオブジェクトがプログラム
言語から作られてコンパイルされ、それ自身がコンパイ
ルされているサーバー・プログラムと、連係と呼ばれる
プロセスを通して結合されなければならない。サーバー
のすべての部分がコンパイルされてしまった後、そのサ
ーバーは実行の準備ができたことになる。

【０００６】従来技術における別の方法は、サーバーに
おいてインタープリタを使ってクライアントの要求を解
釈するものである。このような場合のクライアントの要
求は、サーバーが理解する言語のプログラムである。サ
ーバーは、一組の所定機能を逐次に及びクライアントの
要求により指定されたように呼び出すことによって、そ
のクライアントの要求を解釈する。この方法を使って、
クライアントは、前述の方法を使う場合よりずっと複雑
な要求を行うことができる。しかし、この方法は、サー
バー内にプログラムされた一組の機能又は能力に、クラ
イアントの要求を制限するという欠点を持っている。ア
ドベ・ポストスクリプト・プリンタ・サーバーは、１つ
の例である（「ポストスクリプト」はアドベ・コンピュ
ータ社の商標）。そのサーバーには、ポストスクリプト
・ファイルと呼ばれるプログラムの形でクライアントの
要求が与えられる。ポストスクリプト・ファイルは、非
コマンド・テキストの他にコマンドも含んでいる。コマ
ンド・テキストは、非コマンド・テキストのフォーマッ
ティング及び印刷を制御するために、サーバーにより解
釈される。

【０００７】従来技術におけるサーバーは、特殊なアプ
リケーションのために書かれている。それらは、最初に
プログラムされた機能だけしか実行しない。それらは、
それらのオリジナル・プログラムとは異なるオブジェク
ト又はアプリケーションを容易に実行するほど十分に融
通性のあるものではない。サーバーの設計範囲外のオブ
ジェクトを実行するためには、従来技術のサーバーは書
き直され、コンパイルし直し（リコンパイル）されなけ
ればならない。本発明者が知っている従来技術は、その
サーバーに予定されてないオブジェクト・コード機能
を、そのサーバーの書き直し及びリコンパイルなしで実
行できるサーバーを開示するものではない。

【０００８】従来技術は、プログラムされてない機能を
実行する単一のサーバーについて教示するものではな
い。また、従来技術は、修正可能な一組のオブジェクト
を実行できる単一のサーバーについて教示するものでも
ない。

【０００９】サーバーがクライアントからのプログラム
を受付け、実行する場合、従来技術は、サーバーを減速
するインタプリタと関連したオーバヘッドを必要とす
る。また、インタプリタは、事前コンパイルされ且つサ
ーバーに事前連係されなければならない予め定義された
機能に制限される。

【００１０】

【発明が解決しようとする課題】本発明の目的は、当
初、サーバーが実行するように設計されなかったオブジ
ェクト・コードを、サーバー・プログラムのリコンパイ
ルなしに実行できるサーバー・プログラムのための設計
を提供することにある。

【００１１】本発明のもう１つの目的は、種々の機能を
遂行するように修正されたオブジェクト・コードを、サ
ーバー・プログラムのリコンパイルなしに実行できるサ
ーバー・プログラムのための設計を提供することにあ
る。

【００１２】本発明の更にもう１つの目的は、サーバー
により遂行されるべく設計された機能とは異なる機能及
び別のクライアントにより要求された機能実行を含む複
数の相異なるオブジェクトを、リコンパイルすることな
しに実行できるサーバー・プログラムを提供することに
ある。

【００１３】本発明の更にもう１つの目的は、各実行さ
れたオブジェクトが１つのグラフィック・ディスプレイ
の一部分を制御するように複数のクライアントからの複
数の且つ修正可能なオブジェクトを、リコンパイルする
ことなしに実行できるコンピュータ・グラフィック・サ
ーバー・プログラムを提供することにある。

【００１４】

【課題を解決するための手段】本発明は、機能と呼ばれ
る種々の相異なるオブジェクト・プログラムを、たとえ
これらオブジェクト・プログラムを実行するように特別
に設計されていなくても、実行する能力を持ったコンピ
ュータ・サーバー・プログラムを開示するものである。
そのサーバーは、これらプログラムがリコンパイルする
ことなしに修正されても、それらを再走させることがで
きる。更に、１つ又は複数のクライアントはオブジェク
ト又は機能を追加又は削除することができる。サーバー
は、これらオブジェクト及びそれらの機能を、再プログ
ラム又はリコンパイルする必要なく、実行する。その結
果、このサーバーは、多くの相異なる修正可能なオブジ
ェクトを、従来技術のサーバーよりも遥かに速く実行す
ることができる。

【００１５】本発明では、クライアントは、サーバーが
ループしている間に、実行可能なコードで書かれたオブ
ジェクト・プログラムをサーバーにロードする。その効
果は、新たにロードされたオブジェクト（実行可能なオ
ブジェクト・コード）を持ったサーバーがその新しいオ
ブジェクト・コードの機能をそれ自身のサーバー・プロ
グラムに加えることである。（機能は、オブジェクトに
より遂行されるタスクであり、オブジェクトは、１つ又
は複数の機能を含んでいる）。実際には、オブジェクト
・コードを加えられたサーバーは、その加えらえたオブ
ジェクト・コードの機能を遂行する方法を覚えており、
クライアントがそのオブジェクト・コードを再ロードす
る必要なく要求に応じてその新しいオブジェクトの機能
を遂行できる。従って、ますます多くのオブジェクトを
サーバーに加えることによって、サーバーは、オブジェ
クトによりそれに加えられる各機能を学習し、獲得す
る。一方、クライアントは、サーバーが以前に加えられ
た機能を忘却、即ち、ドロップすることを要求できる。

【００１６】クライアントは、サーバーが学習すべき機
能および他の情報を含むオブジェクトをサーバーに送
る。サーバーは、機能を登録することによってその機能
を学習する。即ち、サーバーは、オブジェクトの機能と
オブジェクト及び機能に関する情報とをサーバー・メモ
リに記憶する。特に、サーバーは、このオブジェクトに
より利用された機能を識別し、将来の参照のために、そ
れら機能及びそれら機能に関する情報をテーブルに記録
する。登録中、オブジェクト・コード及び他の情報がサ
ーバー・メモリにロードされる。クライアントは、サー
バーに種々な要求を行って登録情報を修正したり、サー
バーに或るオペレーションを遂行させたりできる。

【００１７】一旦オブジェクトがその機能と共にサーバ
ーに登録されてしまうと、クライアントはサーバーにそ
のオブジェクトの機能を走らせる（即ち、実行させる）
ことができる。これを行うために、クライアントは、そ
の機能をどのように走らせるかに関する情報をサーバー
に送り、その機能を呼び出す（即ち、実行する）ように
サーバーに要求する。この時点で、サーバーは、その機
能を走らせ且つその機能を走らせた結果をクライアント
に送るという実行手順を進めるであろう。

【００１８】

【実施例】種々なクライアントの要求で、サーバーがオ
ブジェクトを学習し、忘却するという能力は、サーバー
を非常に融通性に富むものにし、即ち、サーバーが遂行
し得る機能の数を拡大する。サーバーは、新しい各機能
を実行する前に再プログラムされたりリコンパイルされ
たりする必要がないため、オブジェクト・プログラム実
行の融通性を増大させる。更に、サーバーが既に学習し
たオブジェクト機能は、サーバーに再ロードされる必要
さえない。従って、本発明が開示するサーバーは、再プ
ログラム可能であり、そして、オン・ザ・フライで又は
正規のルーピングの過程で、リコンパイルのために停止
する必要なく新しいオブジェクト機能を実行できる。動
的連係とも呼ばれるこの能力は、この実行の融通性及び
速度を必要とする多くのアプリケーションでこのサーバ
ーを使用可能にする。今まで、これらサーバー・アプリ
ケーションは、ゆっくりしたペースで動作しなければな
らなかったか、或は、不可能であった。これらアプリケ
ーションのうちの或るものは、マルチメディア・クライ
アント・サーバー・アプリケーション、デバイス・ドラ
イバ、リソース・サーバー、マルチユーザＣＡＤ、及び
分散処理アプリケーションを含む。

【００１９】図１は、本発明のサーバーを示す。サーバ
ー１００は、連続ループにおいて走るコンピュータ・プ
ログラムであり、従来技術で典型的に実施された任意の
方法でループする。好ましい実施例では、そのサーバー
は、ＩＢＭＲＩＳＣシステム／６０００上で走る。
なお、このシステムは、ＩＢＭ「ＲｅｓｅａｒｃｈＲ
ｅｐｏｐｒｔＲＣ１６５５３１９９１，Ｔｈｅ
ＩＢＭＲＩＳＣＳｙｓｔｅｍ／６０００：Ａｒｃｈｔ
ｅｃｔｕｒｅａｎｄＰｅｒｆｏｒｍａｎｃｅ」に開
示されている。ＡＩＸ３．１が使用される。従来技術
におけるように、そのループでは少なくとも１回、この
サーバーは、何れかのクライアントがサーバーに要求を
行っているかどうかをボックス１０でチェックする。要
求が行われていない場合、サーバーは、線１２を介して
ルーピングを続ける。しかし、クライアントが要求を行
っている場合、サーバーは、２つの新規な動作の１つを
行う。その第１（ボックス２０）は、オブジェクトの登
録のようなクライアント要求を処理する。その第２（ボ
ックス３０）は、登録されたオブジェクト機能が活動化
される、即ち、後述の方法で実行のためにスケジュール
される場合、その機能の実行である。

【００２０】要求を処理する（ボックス２０）の例は、
次のような活動を含む。即ち、それらは、オブジェクト
を登録する（ＲＥＧＩＳＴＥＲ）、オブジェクトを登録
抹消する（ＵＮＲＥＧＩＳＴＥＲ）、機能を活動化する
（ＡＣＴＩＶＡＴＥ）、オブジェクトを非活動化する
（ＤＥＡＣＴＩＶＡＴＥ）、オブジェクトの機能を呼出
す（ＣＡＬＬ）、機能データを設定する（ＳＥＴＦＵ
ＮＣＴＩＯＮＤＡＴＡ）、機能データを獲得する（Ｇ
ＥＴＦＵＮＣＴＩＯＮＤＡＴＡ）、機能の優先順位
を設定する（ＳＥＴＰＲＩＯＲＩＴＹ）である。その
他の要求も当業者には明らかであろうし、本発明の技術
範囲に属するものである。これらの活動は、後述され
る。

【００２１】サーバー１００が要求を処理すること（ボ
ックス２０）を計画し且つ活動化した機能がない場合、
サーバーはループ２２へ続く。しかし、活動化した機能
がある場合、サーバーはそれらを実行し（ボックス３
０）、然る後、ループ３２へ続く。

【００２２】クライアントは、サーバーがそのクライア
ントのために或るコードを走らせることを必要とするコ
ンピュータ・プログラムである。クライアントは、サー
バーと同じコンピュータ上で走ることができるし、或
は、サーバーに対して外部にあるがサーバーとコミュニ
ケートするコンピュータ上で走ることもできる。このサ
ーバーを使うクライアントは、サーバーを走らせるため
の複数のオブジェクトをサーバーに与えることもでき
る。サーバーは、複数のクライアントをサービスするこ
とができる。

【００２３】クライアントを設計するユーザは、各オブ
ジェクトを実行可能な形で書かなければならない。即
ち、オブジェクトのすべての機能は、それらがロードさ
れた時にサーバー・コンピュータ上で走るよう、オブジ
ェクト・コードで書かれ、連係される。

【００２４】これらオブジェクトは、サーバーで走らせ
るためには、或る特性を持たなければならない。オブジ
ェクト機能の二重登録を防ぐために、ユーザは、オブジ
ェクトを走らせることをサーバーに要求する他のすべて
のクライアントがオブジェクト・タイプの名前、即ち、
タイプ名を知っていて，それを使用することを保証す
る。（同じタイプのオブジェクト、即ち、同じタイプ名
を持つオブジェクトは、同じ機能を持っている）。更
に、共通のオブジェクト・タイプの間で共用される機能
は内部状態を持ってはならない。（例えば、複数のクラ
イアントにより変更可能なカウンタは、コヒーレンスを
維持するように管理されなければならない。これを達成
するためには、クライアントは、タイプ名を知るための
ものをクライアント・メモリに組み込ませてもよいし、
既知のコミュニケーション技術を使ってこの情報がクラ
イアント間で交換されるようにしてもよい）。更に、ユ
ーザは、クライアントがサーバーの特性を無限ループで
走るオブジェクトの特性に変更することを望まない場
合、サーバーがその無限ループで走るオブジェクトを実
行することをクライアントが要求しないようにしなけれ
ばならない。

【００２５】オブジェクトは、実行可能なコード、即
ち、ロードされた時にサーバー上で走るように内部的に
連係したオブジェクト言語、に縮約したコンピュータ・
プログラムである。クライアントは、登録要求（ＲＥＧ
ＩＳＴＥＲ）使って１つのオブジェクト（即ち、そのオ
ブジェクトに含まれた機能）をサーバーに登録する。オ
ブジェクト及び機能の登録後、クライアントは、そのオ
ブジェクト機能を走らせるようサーバーに要求できる。
そのオブジェクトは走らせることのできる１つまたは複
数の機能のセットである。

【００２６】この新規な登録の概念は、ボックス２０に
おける要求の処理に含まれる活動の１つであり、以下で
詳述する。

【００２７】本発明におけるすべてのオブジェクトに存
在する１つの機能は、エントリ機能と呼ばれる。このエ
ントリ機能は、機能テーブル（後述する）に見られるフ
ィールドを含んだメモリ構造を持っている。それは、１
つの引数（即ち、エントリ機能が使用する情報、ここで
は、初期テーブル・ポインタ「ＩＴＰ」と呼ばれる）も
有する。

【００２８】図２ないし図６は、機能を登録し且つ走ら
せるためにサーバーにおいて使用される情報及びテーブ
ル機能のメモリ構造を示す。その示された構造は、図２
にサーバー・メモリ・スペース２００における可変数、
図３に初期テーブル２３０、図４に機能テーブル２５
０、図５にタイプ・テーブル２７０、及び図６に実行テ
ーブル２８０を含む。機能テーブル２５０、タイプ・テ
ーブル２７０、及び実行テーブル２８０は、サイズが拡
大及び縮小し得るテーブルである。好ましい実施例は、
これらテーブルのための連係リスト（矢印２６４、２７
８、２９８で示される）を使用する。

【００２９】サーバーは、そのサーバーに登録されたオ
ブジェクトに関連した値及び名前を記憶するためにメモ
リ・スペース２００の可変数を利用する。これらの可変
数は、オブジェクト・タイプ名の名前、即ち、タイプ名
２０２、初期テーブル・ポインタ（ＩＴＰ）２０４、機
能テーブルにおける機能の数（ＮＦＴＥ）、即ち、機能
テーブルの長さ２０６、所与のオブジェクトにおける機
能の数（機能数）２０８、タイプの数（タイプ数）、即
ち、タイプ・テーブルの長さ２１０、及び実行テーブル
・エントリの数（実行数）、即ち、実行テーブルの長さ
２１２を含む。また、オブジェクトの機能により使用さ
れる引数２１４及び実行可能なオブジェクト・コード自
体２１６のためのメモリ・スペースもある。オブジェク
ト上でエントリ機能を見つけて走らせるために使用され
るエントリ機能ポインタ（ＥＦＰ）２１８、そしてイン
スタンスＩＤ２２０、機能名２２２もサーバー・メモリ
・スペース２００に含まれる可変データである。

【００３０】図３の初期テーブル２３０は、オブジェク
トが最初にサーバーに送られた時、そのオブジェクトに
関する情報を記憶するために使用される。この情報は、
後に、他のテーブルに置かれる。テーブル２３０におけ
るエントリ２４６は、６個のフィールド、即ち、機能ポ
インタ・フィールド２３２、引数サイズ・フィールド２
３４、出力サイズ・フィールド２３６、優先順位フィー
ルド２３８、名前・フィールド２４０、タイプ名・フィ
ールド２４２を有する。

【００３１】引数フィールド２３４は、その機能に対す
る引数に対して十分なスペースを割当てるために使用さ
れる。出力サイズ・フィールド２３６は、その機能の結
果に対して十分なスペースを割当てるために使用され
る。その機能に関連した出力がない場合、出力サイズ・
フィールド２３６はゼロ値を有し、スペースを割当てら
れる必要がない。優先順位フィールド２３８は、機能の
リストにおける実行されるべき機能の優先順位を決定す
るために使用される。名前フィールド２４０は、その機
能を記号的に参照するために使用される。タイプ名フィ
ールド２４２は、その機能を特定のオブジェクト・タイ
プと関連付けるために使用される。

【００３２】図４の機能テーブル２５０も、それのエン
トリ２６６の各々に対する６個のフィールド、機能ポイ
ンタ・フィールド２５２、引数サイズ・フィールド２５
４、出力サイズ・フィールド２５６、優先順位フィール
ド２５８、名前フィールド２６０、タイプ名フィールド
２６２を有する。これらフィールドは、テーブル２３０
における対応フィールドが記憶する情報と同じ情報を記
憶し、機能及びフォーマットの両方ともテーブル２３０
におけるフィールドと同じである。

【００３３】図５のタイプ・テーブル２７０は、それの
エントリー２７５の各々において３個のフィールド、即
ち、タイプ名フィールド２７２（テーブル２３０におけ
るタイプ名フィールド２４２と同じ）、機能数フィール
ド２７４、エントリ機能ポインタ（ＥＦＰ）フィールド
２７６を有する。タイプ名フィールド２７２は、オブジ
ェクト・タイプの名前である。機能数フィールド２７４
は、このオブジェクトに対して登録される機能の数であ
る。ＥＦＰフィールド２７６は、そのオブジェクトに存
在するエントリ機能の開始位置に対するポインタであ
る。タイプ・テーブル２７０は、サーバーに登録される
オブジェクトの各タイプに対して１つのエントリを有す
る。

【００３４】図６の実行テーブル２８０は、サーバーが
実行し得る各機能に対して１つのエントリ２９６を有す
る。それは９個のフィールド、即ち、機能名フィールド
２８２、タイプ名フィールド２８４、インスタンス・フ
ィールド２８６、状態フィールド２８８、結果フィール
ド２８９、活動フィールド２９０、反復計数フィールド
２９２、優先順位フィールド２９４、機能ポインタ・フ
ィールド２９５を有する。

【００３５】機能名フィールド２８２は、所与のオブジ
ェクトにおける機能の名前である。オブジェクト、即
ち、オブジェクト・タイプは複数の機能を持つことがで
きる。その機能名は、機能テーブル２５０の名前フィー
ルド２６０にも現れる。

【００３６】インスタンス・フィールド２８６は、同じ
機能を持った同じオブジェクト・タイプを見つける手が
かりである。例えば、２つ以上のクライアントが同じオ
ブジェクト・タイプを持つ場合、インスタンス・フィー
ルド２８６は、同じオブジェクト・タイプをサーバーに
ロードしようとする各クライアントを追跡する。その機
能を登録するクライアントは、そのクライアントに名前
または番号を付けることによって、或は、この分野で実
施されている任意の知られた方法を使うことによって、
インスタンス・フィールド２８６に記録される。従っ
て、実行テーブル２８０は、すべてのクライアントによ
り登録された各機能に対して１つの機能エントリを有す
る。各機能を登録したクライアントの表示がインスタン
ス・フィールド２８６に記録される。

【００３７】状態フィールド２８８は、所与の機能の引
数を記憶するためのサーバーにより割当てられたメモリ
・スペースに対するポインタを含む。

【００３８】結果フィールド２８９は、そのオブジェク
トを走らせた結果を記憶する。このフィールドの大きさ
は、出力サイズ・フィールド２５６における結果に対し
て割当てられたスペースに依存する。

【００３９】活動フィールド２９０は、機能が活動化さ
れているかどうかを表わすフラッグを含む。

【００４０】反復計数フィールド２９２は、機能が走っ
ている時にいつもデクレメントされる計数値を含む。そ
れは、機能を走らせる回数を決定するために使用され
る。反復計数フィールド２９２における計数値が所与の
値、例えば、ゼロまでデクレメントされてしまわない
間、その機能は、サーバーがループする度に１回走らさ
れる。この分野で一般的な他の計数方法も考えられる。

【００４１】優先順位フィールド２９４は、機能テーブ
ル２５０の優先順位フィールド２５８における値と同じ
値である。機能ポインタ・フィールド２９５は、機能テ
ーブル２５０の機能ポインタ・フィールド２５２におけ
る値と同じ値である。

【００４２】図７は、クライアントがオブジェクトを登
録する時に関連したステップ３００のフローチャートを
示す。

【００４３】ボックス３０５において、クライアント
は、オブジェクト・タイプ名をサーバーに送る。クライ
アントは、実行可能なオブジェクト・コードもサーバー
に送る。別の好ましい実施例では、クライアントは、オ
ブジェクト・タイプ名２０２及びそのオブジェクトが存
在するファイル名を送る。そこで、サーバーは、このフ
ァイル位置をアクセスし、そこからオブジェクトをロー
ドする。

【００４４】ボックス３１０において、サーバーは、ク
ライアントが登録のためにシークするオブジェクト・タ
イプが任意の前に登録したクライアントのものと同じで
あるかどうかをチェックする。サーバーは、これを行う
ために、タイプ・テーブル２７０を走査しそしてタイプ
名フィールド２７２におけるエントリとその送られたオ
ブジェクトのタイプ名とを比較する。タイプ・テーブル
２７０に同じオブジェクト・タイプが存在しない場合、
サーバーは、独特のインスタンスＩＤを獲得し（ボック
ス３１５）、そのオブジェクトをロードする（ボックス
３２０）。しかし、ボックス３１０で一致が得られた場
合、サーバーは、独特のインスタンスＩＤを得て（ボッ
クス３５７）、実行テーブル２８０に進み、それを更新
する（ボックス３６０）。

【００４５】ボックス３２０において、サーバーは、オ
ブジェクト・コードをサーバー・メモリ２１６にロード
する。サーバーは、そのコードをロードする時、そのオ
ブジェクトからエントリ機能ポインタ値（ＥＦＰ）を得
て、それをメモリ・ロケーション２１８に記憶する。サ
ーバーは、オブジェクトからＥＦＰを取り出すことがで
きるオペーティング・システム機能を呼び出すことによ
ってこれを行う。これは、本発明を走らせる好ましいオ
ペレーティング・システムであるＡＩＸにおける標準的
なオペレーティング・システム機能である。ＡＩＸにお
ける正規のプログラム実行では、オペレーティング・シ
ステムがＥＦＰのロケーションを決定すると直ちにオブ
ジェクトが走らされる。しかし、本発明では、ＥＦＰが
アクセスされると、それは、その後の使用のために記憶
される。即ち、オブジェクトは直ちには実行されないか
もしれない。なお、オブジェクトからＥＦＰタイプの可
変データへのアクセスを得ることができる如何なるオペ
レーティング・システムも本発明の技術範囲に属するも
のである。

【００４６】ボックス３２０において、サーバーは、ク
ライアントからオブジェクト・タイプ名も得る。好まし
い実施例では、クライアントは、オブジェクト・コード
をサーバーに与える（ボックス３０５）と同時にこの情
報もサーバーに与える。

【００４７】ボックス３２５において、サーバーは、初
期テーブル２３０に対するスペースをサーバー・メモリ
において割当てる。サーバーは、初期テーブル・ポイン
タ（ＩＴＰ）２０４によって初期テーブル２３０の開始
ロケーションも定義する。好ましい実施例では、テーブ
ル２３０は、所与の機能数に対して割当てられる。この
数は、任意のオブジェクトが持つであろう機能数、即
ち、１００個のエントリ２４６、よりも大きい。一旦ス
ペースが割当てられると、サーバーは、ＩＴＰ（このス
ペースのロケーション）をエントリ機能に送る。ＩＴＰ
は、そこのエントリ機能引数に記憶される。ＥＦＰを使
って、サーバーはエントリ機能を走らせ、テーブル２３
０に記入する（ボックス３３０）。別の方法としては、
サーバーは、未定義のＩＴＰをエントリ機能に送り、然
る後、エントリ機能自体がテーブル２３０において必要
とする以上のスペースを割当てる。

【００４８】ボックス３３０は、エントリ機能を走らせ
る。サーバーは、ＥＦＰ２１８を使ってエントリ機能を
アクセスし、それを実行する。エントリ機能は、ＩＴＰ
を使って初期テーブル２３０の開始ロケーション２４４
を見つける。

【００４９】ボックス３３５において、エントリ機能
は、その関連のオブジェクトに関する情報を初期テーブ
ル２３０に記入し始める。エントリ機能は、登録される
べきオブジェクトにおける各機能に対して１つのエント
リを初期テーブル２３０に加える。従って、初期テーブ
ル２３０は、登録されている機能（オブジェクトにより
使用された機能）と同数のエントリ２４６を持つであろ
う。エントリ機能は、オブジェクトから情報を得て、各
エントリに対する初期テーブル２３０の各フィールドに
記入する。エントリ機能は、そのテーブルに入れられた
エントリの数を戻し、その結果は、機能数２０８の値、
即ち、そのオブジェクト・タイプにおける機能の数、に
割当てられる。

【００５０】そこで、サーバーは判断ブロック３４０に
進み、そのオブジェクトに対して幾つの機能が登録され
たかをチェックする。登録された機能がなかった場合、
エラー・メッセージがクライアントに送られる。しか
し、少なくとも１つの機能が登録された場合、サーバー
は、機能テーブル２５０、タイプ・テーブル２７０、及
び実行テーブル２８０を更新する（ボックス３４５、３
５５、３６０）。

【００５１】ボックス３４５で、サーバーは機能テーブ
ルを更新する。初期テーブル２３０における各エントリ
対して、同じエントリが機能テーブル２５０に作られ
る。ボックス３５０で、機能数２０８（このオブジェク
ト又はオブジェクト・タイプにおける機能の数）がＮＦ
ＴＥ２０６の現在値に加えられ、ＮＦＴＥ２０６を更新
する。ＮＦＴＥは、機能テーブルにおける機能の合計
数、即ち、機能テーブル２５０の長さである。

【００５２】ボックス３５５で、サーバーは、登録され
るオブジェクト・タイプ（又は、オブジェクト）に対応
する１つのエントリを加えることによってタイプ・テー
ブル２７０を更新する。サーバーは、新しいエントリに
対するタイプ・テーブル２７０のすべてのフィールドに
記入する。タイプ名フィールド２７２は、オブジェクト
・タイプ名２０２に等しく設定される。機能数フィール
ド２７４は、機能数２０８に等しく設定される。ＥＦＰ
フィールド２７６はＥＦＰ２１８に等しく設定される。
タイプ数２１０は、タイプ・テーブル２７０の長さを表
わすメモリ可変数であり、１ずつインクレメントされ
る。

【００５３】ボックス３１５及び３５７は同じ機能を遂
行する。即ち、それらは独特のインスタンスＩＤ値を与
える。好ましい実施例では、クライアントのオブジェク
トに対するインスタンス番号は、コミュニケーションが
行われるファイル記述子である。カウンタを使ったり、
一般に行われているような独特の名前発生器を使ったり
するような他の方法も可能である。（名前発生器は、既
知のストリングの連結、例えば、タイプ＝"Ｈａｎｄ"＝
＞インスタンス＝"Ｈａｎｄ１"、又は、既知の名前、例
えば、"ＸＦ＄１ｓ９．１８７"、を発生することによっ
て行うことができる)。

【００５４】サーバーは、実行テーブル２８０を更新す
る。サーバーは、その機能の各タイプ名２０２に対して
登録されるオブジェクト・タイプの各機能に対するエン
トリ２９６を作る。従って、すべてのクライアントが登
録するすべてのインスタンスの各機能に対するエントリ
が実行テーブル２８０に存在する。

【００５５】このような各機能に対して、サーバーは、
実行テーブル２８０における各フィールドに記入するこ
とによってその実行テーブルのエントリ２９６を作成す
る。機能名フィールド２８２が名前フィールド２６０に
設定される。タイプ名フィールド２８４は、オブジェク
ト・タイプ名２０２に等しく設定される。インスタンス
・フィールド２８６は、インスタンスＩＤ２２０に等し
く設定される。状態フィールド２８８は、サーバーによ
って割当てられた引数サイズ・フィールド２５４のメモ
リ・ブロックに等しく設定される。活動フィールド２９
０は、偽（ｆａｌｓｅ）に設定される。反復計数フィー
ルド２９２は、ゼロに設定される。優先順位フィールド
２９５は、機能テーブルの優先順位フィールド２５８に
等しく設定される。機能ポインタ・フィールド２９５
は、機能ポインタ・フィールド２５２に等しく設定され
る。

【００５６】サーバーは、より低い優先順位のエントリ
２９６（即ち、優先順位フィールド２９４の値がより高
い）の前で且つより高い優先順位のエントリ２９６の後
にあるようなエントリを実行テーブル２８０に挿入す
る。

【００５７】マッチング・タイプ・エントリの機能数フ
ィールド２７４は、実行エントリ数２１２に加えられ
る。即ち、実行エントリ数は、実行テーブルにおける現
在のエントリ数を反映するように更新される。

【００５８】図７及びオブジェクトを登録する方法を説
明したが、本発明の特徴は、他の種々の活動、即ち、オ
ブジェクトを登録抹消すること、機能を活動化および非
活動化すること、機能を呼び出すこと、機能データを設
定すること、機能データを獲得すること、優先順位を設
定すること、を含む活動を遂行するために使用可能であ
る。

【００５９】オブジェクト登録抹消の要求は、１つのオ
ブジェクトの所与のインスタンス（及びそれのすべての
機能）を除去する、即ち、サーバーにそのオブジェクト
を「忘却」させるものである。所与のインスタンスＩＤ
（及びその関連の機能）と共に登録抹消されたオブジェ
クトは、サーバーから除去される。これを行うために、
サーバーは、クライアントから送られたタイプ名２０２
及びインスタンスＩＤ２２０を使って実行テーブル２８
０を走査し、所与のタイプ名２０２及びインスタンスＩ
Ｄ２２０に一致するすべてのエントリを除去する。好ま
しい実施例では、然る後に、サーバーは、他の任意のイ
ンスタンスＩＤ２２０の同じ所与のタイプ名２０２を探
して実行テーブル２８０をもう１回走査する。少なくと
も１つのそのようなエントリが見つかる場合、それ以上
のアクションは取られない。そのようなエントリが見つ
からない場合、タイプ・テーブル２７０及び機能テーブ
ル２５０が更新される。この更新は、所与のタイプ名２
０２に一致するタイプ名フィールド２７２を持つタイプ
・テーブル２７０におけるエントリを見つけて除去する
こと、タイプ数２１８を１ずつデクレメントすること、
所与のタイプ名に一致したタイプ名フィールド２６２を
有する機能テーブル２５０の各エントリを見つけて除去
することを含む。この方法では、登録されたクライアン
トを持たないオブジェクト・タイプに対して割当てられ
たスペースは再割当て可能である。

【００６０】サーバーに登録された機能の活動化状態を
変更する又はその状態に入るためには、クライアントは
活動化要求を使用する。クライアントは、サーバーに機
能名、タイプ名、及びインスタンスを送ることによって
活動化されるべき機能を識別する。サーバーは、これら
の値を実行テーブル２８０における機能名フィールド２
８２、タイプ名フィールド２８４、及びインスタンス・
フィールド２８６に突合わせる。然る後、その突合せ機
能の反復計数２９２は、サーバーが与える値に設定され
る。その突合せ機能の活動フラッグ２９０（エントリ２
９６）も真（ｔｒｕｅ）に設定される。

【００６１】クライアントは、１つの機能を非活動化し
たい時、サーバーに非活動化要求を送る。クライアント
は、機能名、タイプ名、及びインスタンスによってその
非活動化されるべき機能を示す。サーバーは、機能名フ
ィールド２８２、タイプ名フィールド２８４、及びイン
スタンス・フィールド２８６を使って、これらの値を実
行テーブル２８０におけるエントリと突合せる比較す
る。一致が生じると、サーバーは、エントリ２９６の活
動フィールド２９０を偽（ｆａｌｓｅ）に設定する。

【００６２】１つの機能を走らせる（実行させる）ため
には、クライアントは呼び出し要求を使用する。クライ
アントは、名前、タイプ名、及びインスタンスＩＤ（サ
ーバー・メモリ・ロケーション２２２、２０２、及び２
２０に記憶される）によってサーバーに対し機能を示
す。サーバーは、機能名フィールド２８２、タイプ名フ
ィールド２８４、インスタンス・フィールド２８６を使
って、これら値を実行テーブル２８０におけるエントリ
２９６と突合わせる。一致が見つかると、サーバーは機
能ポインタ２９５を使ってその機能を実行する。その機
能は、その機能に対する引数が存在する予め割当てられ
たスペースを指す状態フィールド２８８の値を得る。機
能は或る値を戻し、サーバーはその値をチェックする。
それがゼロよりも大きい場合、結果フィールド２８９が
指すメモリ・スペースの内容がクライアントに送られ
る。

【００６３】１つの機能に対する引数をサーバーに供給
するためには、クライアントは機能データ設定要求を使
用する。クライアントは、その名前、タイプ名、及びイ
ンスタンスによってその機能を示す。これらの値は、サ
ーバー・メモリ２００におけるスペース・ロケーション
２２２、２０２、及び２２０に記憶される。サーバー
は、機能名フィールド２８２、タイプ名フィールド２８
４、及びインスタンス・フィールド２８６を使って、こ
れら値を実行テーブル２８０におけるエントリと突合わ
せる。サーバーは、一致を見つける場合、クライアント
により供給された引数を、その機能の引数のために取っ
ておいたメモリ・スペースに複写する。このメモリ・ス
ペースは、一致したエントリの状態フィールド２８８に
おける値を使って見つけられる。サーバーは、新しい引
数をこのサーバ・メモリ・スペースに複写する。

【００６４】サーバーから機能の結果を得るためには、
クライアントは機能データ獲得要求を使用する。クライ
アントは、機能名、タイプ名、及びインスタンスをサー
バーに送ることによってその機能を示す。これら値は、
実行テーブル２８０における機能名フィールド２８２、
タイプ名フィールド２８４、及びインスタンス・フィー
ルド２８６に突き合わされる。一致したエントリ２９６
の結果フィールド２８９は、その機能の結果のために取
っておいたメモリ・ブロックを指す。サーバーはそのメ
モリ・ブロックの内容を送る。

【００６５】機能の実行優先順位を変更又は入れるため
には、クライアントは優先順位設定要求を使用する。ク
ライアントは、機能名及びタイプ名をサーバーに送るこ
とによってその機能を示す。サーバーは、これらの値
を、実行テーブル２８０における機能名フィールド２８
２及びタイプ名フィールド２８４と突き合わせる。一致
したエントリの優先順位フィールド２９４は、クライア
ントが与える優先順位に設定される。

【００６６】図８は、本発明の実行モジュール、即ち、
図１のボックス３０で示された活動のフローチャートで
ある。

【００６７】ボックス４０５において、サーバーは、エ
ントリ２９６の機能が活動化されているかどうかを決定
するために実行テーブル２８０におけるそのエントリを
チェックする。サーバーは、実行テーブル２８０の活動
フィールド２９０をチェックすることによってこれを行
う。チェックされた機能がアクティブでない場合（線４
０８によりボックス４４０にブランチする）、サーバー
は次の機能をチェックする。しかし、チェックされた機
能がアクティブである場合、サーバーはその機能を走ら
せる（ボックス４１０）。

【００６８】サーバーは、図８に示されたステップを繰
り返しながら実行テーブルを最上部から最下部へ移行す
ることに注意すべきである。好ましい実施例では、実行
テーブル２８０は最上部から最下部へ優先順位で配列さ
れている。（優先順位フィールド２９４における低い番
号は、エントリ２９６に対して高い優先順位を意味す
る）。別の実施例では、実行テーブル２８０におけるす
べての機能の優先順位は等しいか、又は重要でない。こ
の場合、各機能の優先順位は、所与のデフォルト値に設
定可能であり、或は、優先順位フィールド２９４は完全
に除去されてもよい。

【００６９】実行テーブル２８０のエントリ２９６に対
する活動フィールド２９０が活動化されている（実施例
では、それが真である）場合、ボックス４１０で、その
機能が走らされる。別の実施例では、アクティブな機能
だけ、即ち、サーバーが実行するように計画されている
機能だけがリストされる。エントリ２９６における機能
を走らせるために、サーバーは機能ポインタ・フィール
ド２９５の値を使用する。実行テーブル２８０における
状態フィールド２８８及び結果フィールド２８９の値
は、その機能を実行する時に引数として使用される。状
態フィールド２８８の値は、その機能を走らせるのに必
要な引数を含んだサーバー・メモリ・スペースに対する
ポインタである。結果フィールド２８９の値は、その機
能を走らせた結果が記憶されるサーバー・メモリ・スペ
ースに対するポインタである。

【００７０】ボックス４１５において、走り終わった機
能はサーバーに或る値を戻す。好ましい実施例では、こ
の戻された値がゼロよりも大きい場合、結果フィールド
２８９により指定されたメモリ・スペースに記憶された
その機能の結果がクライアントに送り返される（ボック
ス４２０）。しかし、機能がゼロ値を戻す場合、結果フ
ィールド２８９により指定されたメモリ・スペースに記
憶された結果はクライアントに送られない。その結果は
サーバー・メモリに残り、サーバーはブランチ４１８に
よってボックス４２５に進む。

【００７１】ボックス４２５では、反復計数フィールド
２９２の値がチェックされる。好ましい実施例では、そ
の値がゼロより大きい場合、ボックス４３５においてそ
の値は１ずつデクレメントされる。しかし、反復計数フ
ィールド２９２の値がゼロである場合、サーバーはボッ
クス４４０に進む。

【００７２】ボックス４３７では、ボックス４３５にお
けるデクレメントの後、反復計数がチェックされる。反
復計数がまだゼロでない場合、ボックス４４０（次の機
能に対するチェック）が走らされる。反復計数がゼロで
あれば、ボックス４３８が走らされる。

【００７３】ボックス４３８では、活動フラッグ・フィ
ールド２９０が「偽」に設定される。（ゼロの初期反復
計数を持った活動化されたエントリは非活動化されない
であろうし、従って、クライアントによって明確に非活
動化されるまで、サーバーのメイン・ループの各サイク
ルを通して走らされるであろう）。活動フラッグ・フィ
ールド２９０を偽に設定した後、サーバーはボックス４
４０に進む。

【００７４】ボックス４４０では、サーバーは、実行テ
ーブル２８０に他の機能があるかどうかを決定する。そ
れがある場合、サーバーは、次の機能のために、ボック
ス４０５で始まるフローチャートの実行を再び開始す
る。実行テーブル２８０にそれ以上の機能がない場合、
サーバーはボックス４４５に進む。ボックス４４５で
は、サーバーは、実行テーブルにおける活動化された機
能の実行（図１におけるボックス３０）終了する。な
お、図４おけるボックス４４５は、図１における線３２
に相当する。

【００７５】以下では、実施例がグラフィックス・サー
バーである場合を説明する。その場合、本発明のサーバ
ーは、グラフィック・ディスプレイを制御するために使
用される。そのサーバーを使用する２つのクライアン
ト、即ち、クライアント１及びクライアント２がある。
各クライアントは、グラフィック・ディスプレイ上にイ
メージを描き、そのイメージをスクリーン内で移動させ
ることを望んでいる。各クライアントが描こうとしてい
るイメージは手である。その手は、右手でも左手でもよ
い。

【００７６】サーバーが手を描き且つ動かすために使用
するオブジェクトは、サーバー内にプリプログラムされ
ていない。それらは、実行可能な形でそれらクライアン
トにより与えられる。それらオブジェクト及び関連の機
能は、前述のように、サーバーにロードされる。それら
オブジェクトは次のとおりである。

【００７７】オブジェクト１：タイプ＝「Ｇｒａｐｈｉｃｓ」機能：０：名前＝「ＭａｋｅＷｉｎｄｏｗ」引数サイズ＝０タイプ名＝「Ｇｒａｐｈｉｃｓ」優先順位＝１出力サイズ＝０１：名前＝「ＣｌｅａｒＷｉｎｄｏｗ」引数サイズ＝０タイプ名＝「Ｇｒａｐｈｉｃｓ」優先順位＝２出力サイズ＝０２：名前＝「ＴｒａｎｓｆｅｒＴｏＳｃｒｅｅｎ」引数サイズ＝０タイプ名＝「Ｇｒａｐｈｉｃｓ」優先順位＝９９９出力サイズ＝０オブジェクト２：タイプ＝「Ｈａｎｄ」機能：０：名前＝「ＭａｋｅＨａｎｄ」引数サイズ＝０タイプ名＝「Ｈａｎｄ」優先順位＝３０出力サイズ＝０１：名前＝「ＤｒａｗＨａｎｄ」引数サイズ＝１３（バイト）タイプ名＝「Ｈａｎｄ」優先順位＝４０出力サイズ＝０オブジェクト１は、「Ｇｒａｐｈｉｃｓ」と呼ばれるタ
イプである。それは３個の機能、即ち、「ＭａｋｅＷｉ
ｎｄｏｗ」、「ＣｌｅａｒＷｉｎｄｏｗ」、及び「Ｔｒ
ａｎｓｆｅｒＴｏＳｃｒｅｅｎ」を有する。これら機能
の各々は、タイプ名フィールド２６２「Ｇｒａｐｈｉｃ
ｓ」（オブジェクト・タイプ）を持ち、引数を持たず
（引数サイズ＝０）、出力データを発生しない（機能テ
ーブル２５０における出力サイズ・フィールドはゼロで
ある）。それら機能は、グラフィックス・ウインドウを
作り、そのグラフィックス・ウインドウを消去し、そし
てグラフィックス・データをディスプレイに複写する。
それら機能の優先順位（実行テーブル２８０における優
先順位フィールド２９４）は、機能「ＭａｋｅＷｉｎｄ
ｏｗ」（優先順位１）が機能「ＣｌｅａｒＷｉｎｄｏ
ｗ」（優先順位２）よりも上であり、機能「Ｃｌｅａｒ
Ｗｉｎｄｏｗ」が機能「ＴｒａｎｓｆｅｒＴｏＳｃｒｅ
ｅｎ」（優先順位９９９）よりも上であるように割当て
られる。

【００７８】オブジェクト２は、「Ｈａｎｄ」と呼ばれ
るタイプである。それは、２つの機能、即ち、「Ｍａｋ
ｅＨａｎｄ」及び「ＤｒａｗＨａｎｄ」を有する。これ
ら機能は、両方とも、「Ｈａｎｄ」と呼ばれるタイプ名
を持ち、出力データを発生しない（出力サイズ・フィー
ルド２５６＝０）。機能「ＭａｋｅＨａｎｄ」は引数を
持たない（引数サイズ＝０）が、機能「ＤｒａｗＨａｎ
ｄ」は１３バイトの引数を有する。第１バイトは、手が
右か又は左かを指定し、次の４バイトは、スクリーン上
の手のＸ座標位置を与え、その次の４バイトは、そのＹ
座標位置を与え、最後の４バイトは、そのＺ座標位置を
与える。機能「ＭａｋｅＨａｎｄ」は、手のイメージを
記述するためのデータ・セットを作り、機能「Ｄｒａｗ
Ｈａｎｄ」はスクリーン上の適正な位置（ｘ，ｙ，ｚ）
にその手を表示する。機能「ＭａｋｅＨａｎｄ」は、３
０という優先順位を持ち、機能「ＤｒａｗＨａｎｄ」
は、４０という優先順位を持つ。

【００７９】クライアントは、前述のような方法で、こ
れらオブジェクトをサーバーに登録する。この例では、
クライアント１は、オブジェクト１をサーバーに登録す
る。そこで、サーバーは、オブジェクト１に対するコー
ドをロードし、そのテーブルを更新する。然る後、クラ
イアント１は、オブジェクト２をサーバーに登録する。
サーバーは、オブジェクト２に対するコードをロード
し、再びそのテーブルを更新する。然る後、クライアン
ト２は、オブジェクト２をサーバーに登録する。新しい
オブジェクト・タイプは導入されないので、サーバーは
オブジェクト２（及びその機能）に対するコードを再び
ロードする必要はない。しかし、サーバーは、オブジェ
クト２の第２インスタンスの付加を反映するように実行
テーブルを更新する。図５は、この例の実行テーブルを
示す。機能が上から下へ優先順位の順序でリストされて
いることに注意してほしい。

【００８０】一旦、クライアントがそれらのオブジェク
ト（及び関連の機能）を登録してしまうと、それらクラ
イアントは、前述のように、サーバーに要求を行う。ク
ライアント１は、「ＭａｋｅＷｉｎｄｏｗ」インスタン
ス１（クライアント１）及び「ＭａｋｅＨａｎｄ」イン
スタンス１を活動化し、機能データ設定要求を使ってそ
れらの反復計数を１に設定する（図５の５０２参照）。
同様に、「ＣｌｅａｒＷｉｎｄｏｗ」インスタンス１、
「ＴｒａｎｓｆｅｒＴｏＳｃｒｅｅｎ」インスタン１、
及び「ＤｒａｗＨａｎｄ」インスタンス１も活動化さ
れ、それぞれの反復計数フィールド２９２は０に設定さ
れる（５０４参照）。クライアント２は、「ＭａｋｅＨ
ａｎｄ」インスタンス２及び「ＤｒａｗＨａｎｄ」イン
スタンス２を活動化し、それぞれの反復計数フィールド
２９２を１及び０に設定する（５０６参照）。機能デー
タ設定要求を使って、クライアント１及び２は、「Ｄｒ
ａｗＨａｎｄ」インスタンス１及び２に対する機能デー
タを設定する。インスタンス１は、所与の［ｘ，ｙ，
ｚ］位置に左手に関するデータを有し、インスタンス２
は、所与の［ｘ，ｙ，ｚ］位置に右手に関するデータを
有する。反復計数を１に設定された機能はサーバー・ル
ープの第１パス上で走るだけであり、反復計数を０に設
定された機能は全サーバー・ループを走ることに注意し
てほしい（ボックス４３７参照）。サーバーがループす
る時、それは活動化された機能を実行する（図１のボッ
クス３０参照）。サーバーは、優先順位に従ってリスト
されている機能テーブルにおける活動化された機能に遭
遇する。

【００８１】まず、「ＭａｋｅＷｉｎｄｏｗ」機能が実
行され、ウインドウが作成される。然る後、「Ｍａｋｅ
Ｗｉｎｄｏｗ」機能は、その反復計数が１であったので
非活動化される。次に、「ＣｌｅａｒＷｉｎｄｏｗ」機
能が実行され、ウインドウは消去される。「ＭａｋｅＨ
ａｎｄ」インスタンス１機能が実行され、手に関するデ
ータ構造が作成される。然る後、「ＭａｋｅＨａｎｄ」
インスタンス１機能は、その反復計数が１であったので
非活動化される。「ＭａｋｅＨａｎｄ」インスタンス２
機能が実行され、第２の手に関するデータ構造が作成さ
れる。然る後、「ＭａｋｅＨａｎｄ」インスタンス２
は、その反復計数が１であったので非活動化される。
「ＤｒａｗＨａｎｄ」インスタンス１機能が実行され、
第１の手がグラフィックス・バッファに描かれる。「Ｄ
ｒａｗＨａｎｄ」インスタンス２が実行され、第２の手
がグラフィックス・バッファに描かれる。「Ｔｒａｎｓ
ｆｅｒＴｏＳｃｒｅｅｎ」が実行され、その図形が表示
される。

【００８２】図９の実行テーブルを見ると、活動化され
た機能のエントリ２９６だけがサーバー・ループで実行
される。これらの機能は、「ＣｌｅａｒＷｉｎｄｏ
ｗ」、「ＤｒａｗＨａｎｄ」インスタンス１（左手）、
「ＤｒａｗＨａｎｄ」インスタンス２（右手）、及び
「ＴｒａｎｓｆｅｒＴｏＳｃｒｅｅｎ」である。従っ
て、各サーバー・ループにより、ウインドウが消去さ
れ、各々の手が描かれ、そして、スクリーンに送られ
る。（非活動化された機能、即ち、「ＭａｋｅＷｉｎｄ
ｏｗ」、「ＭａｋｅＨａｎｄ」インスタンス１及び「Ｍ
ａｋｅＨａｎｄ」インスタンス２は、各サーバー・ルー
プがこれらイメージを作成するために反復される必要が
ない）。その結果は、グラフィックス・スクリーン上の
それぞれの［ｘ，ｙ，ｚ］位置における左手のイメージ
（クライアント１による制御）及び右手のイメージ（ク
ライアント２による制御）である。

【００８３】どちらの手のイメージ及び位置も、引数サ
イズ・フィールドにおける１３バイトの引数データを変
更するための機能データ設定要求を使ってクライアント
がその手を制御することにより変更可能である。この要
求の後のサーバー・ループにおいて、その影響を受けた
手は、スクリーン上の新しい位置へ移動する（又は、右
から左へ或はその反対に変わる）。引数を連続的に変更
することによって、それら手を、グラフィックス・スク
リーン上の種々な位置へ移動させることができる。

【００８４】この例は、前述のものと同じ技術を使うこ
とによって、３個以上のクライアントに対しても拡張可
能である。別の方法として、１つ（又は、複数の）クラ
イアントが複数のサーバー上にイメージを置くこともで
きる。クライアントは、同じ又は異なったオブジェクト
を各サーバーに登録し、然る後、そのオブジェクトを種
々のサーバー上で実行することもできる。

【００８５】次に、マルチユーザＣＡＤにおける実施例
について説明する。当業者は、本発明を使って、複数の
クライアントが、グラフィック・ディスプレイを制御す
るサーバー上に種々の図形設計オブジェクトを登録する
ことを想像できるであろう。前の例で説明したように、
各クライアントは、スクリーン上に幾つかのイメージの
制御を持つであろう。例えば、自動車の設計では、１つ
のクライアントはサスペンションを設計でき、もう１つ
のクライアントは車のボディを設計でき、更にもう１つ
のクライアントは内装等を設計できる。各設計者は、遠
隔地におけるサーバーによって駆動された図形出力を受
け取ることができる。各設計者は、他の設計者たちがそ
れぞれの担当部分を設計している間、自分自身の担当部
分を設計することができる。設計が変更され、サーバー
が各サーバー・ループ後にスクリーンを更新する時、最
終設計に関する各設計者の結果を図形出力上に見ること
ができる。新しいクライアントは、それらのオブジェク
トをサーバーに登録することによって設計過程に追加可
能である。古いクライアントは、それらのオブジェクト
を登録抹消することによって容易に除去可能である。

【００８６】他の図形設計の例では、複数のクライアン
トが複数のサーバーによってサービス可能である。ｋ個
のサイトがあり、各サイトｉは、クライアントＣｉ、サ
ーバーＳｉ、及びユーザＵｉを有する。各クライアント
Ｃｉは、そのグラフィック・オブジェクトをすべてのサ
ーバーＳｊ（ｊ＝０乃至ｋ）に登録する。各ユーザＵｉ
は、Ｓｉを含むすべてのサーバーにコミュニケートする
クライアントＣｉを使って、それ自身のディスプレイ上
の図形と対話する。その結果は、複数のユーザが，１つ
の共通のシーンに影響を与えるけれども、それら自身の
グラフィック・オブジェクトとだけ対話するということ
になる。

【００８７】本発明の開示があれば、当業者は、本発明
の範囲内であっても、多くの他の代替例を開発できるで
あろう。次のようないくつかの例がある。

【００８８】クライアントは、１つのオブジェクトを一
組のプロテクション又はパーミッションに登録するよう
選択可能である。プロテクション又はパーミッション
は、或るクライアントが或る要求を行うのを許す又は許
さないことである。例えば、クライアントは、１つのオ
ブジェクトを３つの機能に登録し、そして、そのクライ
アントだけがその実行を要求できるようなそれら機能の
うちの２つの機能の実行を制限するかもしれない。

【００８９】プロテクション・スキームは、２つの部
分、即ち、プロテクションを定義する手段及びプロテク
ションを強化する手段を必要とする。第１の部分は、機
能テーブル・エントリ（及び初期テーブル・エントリ）
におけるフィールドによって実施可能であり、そしてそ
のエントリのフィールドは、そのエントリと関連した特
定の機能をどのクライアントが実行できるかを指示する
ものである。その指示は、１つのクライアント名又はク
ライアント名のリストのような簡単なものでよい。第２
の部分は、クライアントがそのサーバーとのすべてのト
ランザクションに対して使用する暗号化された識別子を
各クライアントと関連付けることによって実施可能であ
る。そこで、サーバーは、クライアントの識別及び機能
を関連付けられたパーミッションに基づいて、クライア
ントの要求を認可し、又は否認する。

【００９０】クライアントがサーバーに機能を登録し、
然る後、適当と思われる任意の順序でそれら機能を呼び
出すよう要求することができることは、前述のとおりで
ある。クライアントは、呼び出された機能の結果を同じ
ように得ることができる。

【００９１】クライアントは、タスクを達成するための
一連の要求としてプログラムを構成することができる。
そのプログラムは、例えば、次のようになる。

【００９２】ＢｅｇｉｎＲｅｇｉｓｔｅｒＡ；オブジェクトＡを３つの機能ａ〜ｃに登録ＣａｌｌＡ／ａ；オブジェクトＡの機能ａを呼び出すＣａｌｌＡ／ｂ；オブジェクトＡの機能ｂを呼び出すｉ＝０；Ｗｈｉｌｅ（ｉ＜１０）Ｂｅｇｉｎｉ＝ｉ＋１；ＣａｌｌＡ／ｃ；オブジェクトＡの機能ｃを呼び出すＥｎｄＥｎｄ実行モジュール（図４）に加えて、又はそれに代わっ
て、解釈実行モジュールを考えることができよう。その
解釈実行モジュールでは、実行モジュールは、ファイル
からのプログラム・ステートメント又はクライアントか
ら送られたオブジェクトを読み取り、関連の要求を順次
に実行する。そのプログラムは、例えば、次のようにな
る。

【００９３】ＢｅｇｉｎＣａｌｌＡ／ａＣａｌｌＡ／ｂｉ＝０；Ｗｈｉｌｅ（ｉ＜１０）Ｂｅｇｉｎｉ＝ｉ＋１；ＣａｌｌＡ／ａ；オブジェクトＡの機能ｃを呼び出すＥｎｄＥｎｄこのプログラムは、サーバーが前に登録されたオブジェ
クトＡの機能ａを、然る後、機能ｂ及び機能ｃを順次実
行させることによって解釈可能である。

【００９４】サーバーは、ユーザ・インターフェースに
よって指定及びコード化可能である。ユーザ・インター
フェースは、Ｘ−ウインドウ又は他の一般的に実施され
ている方法を使うことによって構築可能である。ユーザ
・インターフェースは、図形的なものでよく、ボタン、
メニュー、リスト等を含むものでよい。ボタン及びメニ
ューは、サーバー制御監視能力を持ったオペレータを与
え得るものである。グラフィック・インターフェースを
使って、オペレータは、サーバーのテーブルの内容（例
えば、サーバーに現在ロードされている機能のリスト）
を見ること、クライアントによる使用のためのオブジェ
クトをサーバーにロードすること、オブジェクトをサー
バーからアンロードすること、及びサーバーの使用を監
視することができる。

【００９５】本質的には、ユーザ・インターフェース
は、外部クライアントからの要求をチェックしてそれを
処理することに加えて、サーバー・コードがユーザ・イ
ンターフェースを介してユーザからの要求をチェックし
て処理するように、図１を修正する。Ｘ−ウインドウの
ようなイベントに基づくユーザ・インターフェースが好
ましい。ユーザは、グラフィック・ユーザ・インターフ
ェース及びマウスを使って要求を発生する。ユーザは、
リストを介してサーバーの状態をフィードバックし、監
視する。グラフィック・マップは、種々のクライアント
からサーバーへの連結状況を示すことができる。

【００９６】

【発明の効果】当初、サーバーが実行するように設計さ
れていなかったオブジェクト・コードを、サーバー・プ
ログラムをリコンパイルすることなく、そのサーバーが
実行できる。

【図面の簡単な説明】

【図１】本発明のサーバーのフローチャートである。

【図２】サーバーがオブジェクトを登録し且つ実行する
ために使用するサーバー・メモリ・スペースの構成を示
す図である。

【図３】初期テーブルを示す図である。

【図４】機能テーブルを示す図である。

【図５】タイプ・テーブルを示す図である。

【図６】実行テーブルを示す図である。

【図７】オブジェクト及びその機能をサーバーに登録す
る時に遂行されるステップを示すフローチャートであ
る。

【図８】サーバーを使ってオブジェクト及びその機能を
実行する時に遂行されるステップを示すフローチャート
である。

【図９】２つの手のイメージをディスプレイ・スクリー
ン上に描くグラフィック・ディスプレイ・サーバーとし
て使用される本発明のデータ構成を示す図である。

【符号の説明】

２００・・・サーバー・メモリ・スペース２３０・・・初期テーブル２５０・・・機能テーブル２７０・・・タイプ・テーブル２８０・・・実行テーブル

───────────────────────────────────────────────────── フロントページの続き (72)発明者ウェイン・エル・ウットンアメリカ合衆国ジョージア州クラークストンペンドルトン・アベニュー 778

Claims

【特許請求の範囲】

【請求項１】修正可能な機能をサーバーにおいて実行す
る方法であって、サーバー・プログラムの実行中、実行可能なオブジェク
トをクライアント・プログラムによってサーバーにロー
ドするステップと、前記オブジェクトに含まれた機能をサーバー内に登録
し、該登録によって与えられた登録情報により決められ
た機能をサーバーが実行し得るようにするステップと、より成る方法。
【請求項２】前記登録情報はサーバー・メモリにおける
テーブルに記憶されることを特徴とする請求項１に記載
の方法。
【請求項３】前記登録情報は複数の機能の各々の活動状
態を指定し、サーバー・プログラムの所定ループにおい
てアクティブ機能だけを実行することを特徴とする請求
項２に記載の方法。
【請求項４】前記登録情報は複数の機能の各々の優先順
位を含むこと及び前記アクティブ機能は該優先順位に従
ってサーバー・プログラムの所定ループにおいて実行さ
れることを特徴とする請求項３に記載の方法。
【請求項５】前記登録情報は複数の機能の各々の反復計
数値を含むこと及び該機能は反復計数値により決定され
る数だけサーバー・プログラム・ループを実行させるこ
とを特徴とする請求項４に記載の方法。
【請求項６】クライアントは前記登録情報を変更するこ
とによってオブジェクトを登録抹消するようサーバーに
要求し、以て、登録抹消されたオブジェクトの機能がサ
ーバーにより実行されないようにすることを特徴とする
請求項１に記載の方法。
【請求項７】クライアントは前記登録情報を変更するこ
とによって１つの機能を活動化するようサーバーに要求
し、以て、該機能が少なくとも１つのサーバー・ループ
において実行されるようにすることを特徴とする請求項
１に記載の方法。
【請求項８】クライアントは前記登録情報を変更するこ
とによって１つの機能を非活動化するようサーバーに要
求し、以て、該機能がサーバー・ループにおいて実行さ
れないようにすることを特徴とする請求項１に記載の方
法。
【請求項９】クライアントは前記登録情報を変更するこ
とによって１つの機能を呼び出すようサーバーに要求
し、以て、該機能が実行されるようにすることを特徴と
する請求項１に記載の方法。
【請求項１０】クライアントは機能データを設定するよ
うサーバーに要求し、以て、該機能が引数として使用す
べき新しいを有するようにすることを特徴とする請求項
１に記載の方法。
【請求項１１】クライアントは機能データを獲得するよ
うサーバーに要求し、以て、サーバーが前に実行した機
能の結果をクライアントに戻すようにすることを特徴と
する請求項１に記載の方法。
【請求項１２】クライアントは優先順位を設定するよう
サーバーに要求し、以て、該機能がサーバー・ループに
おいて異なった順序で実行されるようにすることを特徴
とする請求項１に記載の方法。
【請求項１３】サーバー・プログラムの特性は、サーバ
ーに戻らない無限ループで走る機能によって変更される
ことを特徴とする請求項１に記載の方法。
【請求項１４】クライアントが１つ又は複数の機能をサ
ーバー上で実行する方法であって、実行可能なオブジェクト・コード及びオブジェクト・タ
イプ名をクライアントからサーバーに送るステップと、
前記オブジェクト・コード、オブジェクト・タイプ名及
びエントリ機能ポインタをサーバー・メモリの第１部分
にロードするステップと、エントリ機能を実行させることによって１つ又は複数の
機能に関する情報をサーバー・メモリの第２部分に記憶
するステップと、各機能に関連する情報を優先順位に従ってサーバー・メ
モリの第３部分に編成するステップと、前記関連する情報が編成された順序で前記機能を実行す
るステップと、より成る方法。