JPH0675888A - 分散不均一環境におけるアプリケーションの動的呼出しの方法及び装置 - Google Patents

Abstract

(57)【要約】 （修正有） 【目的】サーバー・アプリケーションが同じ又は他のプ
ラットフォーム上のアプリケーションを効率よく呼び出
す。 【構成】クライアント・アプリケーションは共通の特徴
を共有するようクラス編成された複数のインスタンス、
及び確認されたインスタンスに対応するオペレーション
の種類を指定する複数のメッセージを有する。プラット
フォームが第１インスタンスについての識別子、及び所
望のオペレーションについての識別子を含む第１メッセ
ージをクライアント・アプリケーション内に生成し、第
１メッセージ及び第１インスタンスのクラスから、所望
のオペレーションを許す手順への参照を包含するような
識別子を決定し、第１インスタンスの識別子及び手順へ
の参照をサーバー・アプリケーションを内蔵するプラッ
トフォームの中のサーバー・プラットフォームへ送る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、不均一データ処
理回路網にわたるコンピューターアプリケーションの相
互作用に関する。特に、この発明は、オブジェクト指向
モデルに従うデータ処理回路網の組織と、その様な不均
一回路網環境にわたる独立のアプリケーション同士の相
互作用とに関する。

【０００２】

【従来技術とその課題】コンピューターは、データ処理
回路網を介して相互に通信をする。コンピューター自体
は一般に「ノード」と呼ばれ、特定の形態のコンピュー
ター、即ち、特定の形態のオペレーティングシステムを
使う特定の形態のハードウェア、は「プラットフォー
ム」と呼ばれる。異なる種類のプラットフォームを包含
する回路網は「不均一回路網」と呼ばれる。プラットフ
ォームを接続して回路網にする一つの目的は、共用され
るデータに対してアプリケーションプログラム（簡単に
「アプリケーション」と呼ぶ）を実行する種々の環境を
提供することである。

【０００３】典型的データ処理回路網では、異なる種類
のプラットフォームと、異なる種類のプラットフォーム
上で走るアプリケーションとがそれ自身に特有の方法で
情報を記憶する。例えば、ＶＡＸ．ＶＭＳプラットフォ
ームではテキスト編集タスクはＴＰＵテキスト編集プロ
グラムを使って達成され、ＭＩＰＳ．ＵＬＴＲＩＸプラ
ットフォームでは、テキスト編集タスクはＥＭＡＣＳテ
キスト編集プログラムを使って達成されることが出来
る。両方のプラットフォームを持っている回路網のユー
ザーは、これらのプラットフォーム及びテキスト編集の
詳細を知る必要無しに、異なるテキスト編集プログラム
からのオペレーションを異なるプラットフォームに使用
しようと希望することが出来る。

【０００４】この互換性は、以前は不可能であった。む
しろ、普通の回路網は、各アプリケーションが特別のプ
ラットフォーム上でのオペレーションのために必要とす
る特別のインターフェースを不均一回路網のユーザーが
採用することを必要とする。普通の回路網は、標準的イ
ンターフェースを使ってアプリケーション間で通信を行
う能力をユーザーに提供することが出来ない。

【０００５】普通の不均一回路網環境でのアプリケーシ
ョン間通信の困難の例として、一プラットフォーム上の
テキスト編集アプリケーションのユーザーが、他のプラ
ットフォーム上の、科学論文のためのＤＩＡＬＯＧや裁
判官の意見のためのＬＥＸＩＳなどの、多ユーザー・デ
ータベース検索サービスにアクセスすることを希望した
とする。普通の回路網上でそうするためには、テキスト
編集アプリケーションの動作を一時停止させなければな
らず、且つ、該データベース検索サービスに特有のコマ
ンド及びメッセージを使って該データベース検索サービ
スを呼び出さなければならない。ユーザーは、希望する
各サービスの特有の名称を知らなければならないだけで
なくて、回路網中の該サービスの位置も知らなければな
らず、且つ、各サービスが採用する種々のコマンド及び
コマンドフォーマットに精通していなければならない。

【０００６】不均一な回路網において一プラットフォー
ム内のアプリケーションが異なるプラットフォーム上の
アプリケーションを効率的に且つ複雑でない方法で呼び
出せる様にするために、これまでは標準的インターフェ
ースは開発されていない。むしろ、普通のアプリケーシ
ョン間通信は、単に、アプリケーション同士の間でメッ
セージ及びデータを物理的に運ぶためのメカニズムを提
供するに過ぎない。

【０００７】一プラットフォーム上のアプリケーション
が別のプラットフォーム上のアプリケーションと通信出
来る様にするために現在使われているメカニズムの一例
は、遠隔手続きコール（Remote Procedure Call(RPC と
略記する））システムである。一プラットフォーム上の
ＲＰＣシステムは、最初にそのアプリケーションのメッ
セージを回路網データフォーマットに変換し、次にその
変換した問いあわせを該回路網を介して受け取り側プラ
ットフォームに送ることによって、「呼出しを行ってい
る」アプリケーションからの問い合わせに応答する。受
け取り側プラットフォームにおいて、ＲＰＣシステムの
他の構成要素が、変換されたメッセージを解読して、呼
び出されたアプリケーションに受入れられるデータフォ
ーマットの問い合わせにする。しかし、呼出し側プラッ
トフォームからの元のメッセージは、呼び出されたアプ
リケーションにより述べられる構文と矛盾してはならな
い。

【０００８】普通の回路網の他の難点は、遠くのノード
上のアプリケーションが現在ロードされ走っていないと
きに生じる。多くのＲＰＣシステムは、既にロードされ
走っているアプリケーションの遠隔呼出しだけを可能に
するに過ぎない。若しそうでなければ、クライアント・
アプリケーションのユーザーは、遠隔のプラットフォー
ム上のサーバーアプリケーションを呼び出す前に該アプ
リケーションをロードする何らかの方法を発見しなけれ
ばならない。これは極めて限定的である可能性がある。

【０００９】アプリケーション間通信を促進するための
汎回路網システムを実現するについての一つの障害は、
回路網内の種々のデータ、オペレーション、及びアプリ
ケーションの全てを扱うためにシステムに必要とされる
と考えられていたシステム資源の量の多さであった。回
路網が拡大するに従って、システム、資源、及び要件も
増大して、多くの提案された装置が全く扱いにくいもの
となる。

【００１０】従って、アプリケーションのための均一で
一貫性のあるインターフェースを通すなどして、異種の
プラットフォーム上のアプリケーションが相互に通信す
るための効率的で単純な方法が必要である。分散不均一
環境におけるアプリケーションのための動的呼出し環境
も必要である。これは、ロードされ走っているアプリケ
ーションと同様に未だロードされ走ってはいないアプリ
ケーションも呼び出す能力を提供することを含む。

【００１１】

【発明の概要】これらの必要を満たすために、本発明
は、データ自体を管理するのではなくてデータ・インス
タンス及びアプリケーションの「クラス」をシステムが
管理するオブジェクト指向的方法でプロセスの相互作用
に対処する。この様なクラスの管理は、該クラスにより
支援されるアプリケーション又はインスタンス（instan
ce) の或る共通の属性などの、該クラスについての情報
を包含するデータベースを必要とすることがある。

【００１２】クライアント・アプリケーションは、パラ
メーターと共に、大域的に（即ち、回路網にわたって）
認識されるメッセージを送ることによって他のアプリケ
ーションを遠くから呼び出すことが出来る。メッセージ
の名称と、或るパラメーター及び或る優先順位情報（コ
ンテキスト情報と称する）のクラスに関する情報とを使
って、特別の方法への参照が該データベースから選択さ
れる。この方法は、該メッセージで指定されているオペ
レーションを行う。該データベース中の他の情報は、そ
のとき、参照された方法を実施する実際のコードの位置
を確認して実行するのに使われる。

【００１３】詳しく言うと、複数のプラットフォームを
含むデータ処理回路網において、この発明に従ってクラ
イアント・アプリケーションによりサーバー・アプリケ
ーションを呼び出すプロセスは幾つかのステップを含む
が、該クライアント・アプリケーションは、該クライア
ント・アプリケーションにより操作又はアクセスされる
ことのあるアイテムである複数のインスタンスを包含
し、該インスタンスは、同じクラスの中のインスタンス
が共通の特徴を共有する様にクラスに編成され、更に該
クライアント・アプリケーションは、該クライアント・
アプリケーションについて確認されたインスタンスに対
して行われることの出来るオペレーションの種類を指定
する複数のメッセージを包含する。詳しく言うと、該プ
ロセスは、プラットフォームにより行われる次のステッ
プからなる、即ち、第１のインスタンスについての識別
子と、該第１インスタンスに対して行われるべき所望の
オペレーションについての識別子とを含む第１メッセー
ジを該クライアント・アプリケーション内に生成するス
テップと；該第１メッセージと、該第１インスタンスが
編入されているクラスとから第１の方法についての識別
子を決定するステップであって、該第１方法についての
識別子は、該サーバー・アプリケーションが該第１イン
スタンスに対して所望のオペレーションを行うのを許す
手順への参照を包含しているステップと；該第１インス
タンスについての該識別子と該手順への該参照とを、該
サーバー・アプリケーションを呼び出するための該サー
バー・アプリケーションを内蔵するプラットフォームの
サーバーの一つへ送るステップと、から成っている。

【００１４】クライアント・アプリケーションによりサ
ーバー・アプリケーションをオブジェクト指向的に遠く
から呼び出せる様にするこの発明のデータ処理回路網
は、一義的に識別可能な複数のクラスについての情報を
含む複数のクラス項目を含むデータベースを内蔵する回
路網内のメモリーを備えており、該クラスはインスタン
スの種類を特定し、該インスタンスは、共有される特徴
に従って該アプリケーションにより操作又はアクセスさ
れることのあるアイテムであり、該クラス項目の各々は
メッセージ項目の対応するグループの識別を包含してお
り、該メッセージ項目は、対応するクラス内のインスタ
ンスに対して行われることの出来るオペレーションの種
類を指定する情報を包含しており、該クラス項目の各々
は、該アプリケーションを呼び出す呼出しコマンドへの
参照を内蔵する方法項目の対応するグループの識別を内
蔵しており；該データ処理回路網は、更に、該クライア
ント・アプリケーションを実行するための複数の第１プ
ラットフォームと該サーバー・アプリケーションを実行
するための複数の第２プラットフォームとを備えてい
る。該第１プラットフォームは、第１インスタンスにつ
いての識別子と、該第１インスタンスに対して行われる
べき所望のオペレーションについての識別子とを含む第
１メッセージを生成する手段と、該メモリーに接続され
て該データベースを制御するデータベース制御手段とを
包含する。該データベース制御手段は、該第１メッセー
ジの結果として呼び出されるべきサーバー・アプリケー
ションを選択する手段と、該第１インスタンスに対して
所望のオペレーションを行う選択されたサーバー・アプ
リケーションへの参照を含む第１方法についての識別子
を該第１メッセージと該第１インスタンスが編入されて
いるクラスとから決定する手段と、該第１インスタンス
についての該識別子を介して該選択されたサーバー・ア
プリケーションへの該参照を該第２プラットフォームの
中の選択された一つに送る手段とを含む。該第２プラッ
トフォームは、該データベース制御手段内の該送り手段
から該サーバー・アプリケーションについての該参照を
受け取る手段を含む。

【００１５】この明細書に組み込まれてその一部を形成
する添付図面は、発明の具体例を示していて、説明と共
に発明の原理を説明する。

【００１６】

【実施例】添付図面に示されている発明の好適な実施例
を詳しく参照する。この発明は、普通の回路網アーキテ
クチャに組織されたデータプロセッサにより好適に実施
される。しかし、協働的にアプリケーションを実施する
ためのアーキテクチャ及び手順は、該回路網内のアプリ
ケーション間の相互作用へのオブジェクト指向的アプロ
ーチに対処するものであるので、従来からある普通のも
のではない。 Ａ．回路網の主要な構成要素 図１は、本発明を実施するのに使うことの出来る回路網
５０を示す。図１において、回路網５０は、回路網バス
５５によって接続された３個の独立のプラットフォーム
１００、２００、及び３００を包含する。プラットフォ
ーム１００、２００、及び３００は完全に不均一である
として示されているけれども（即ち、プラットフォーム
１００はＶＭＳオペレーティングシステムを使用するＶ
ＡＸプロセッサとして示されており、プラットフォーム
２００はＵＬＴＲＩＸオペレーティングシステムを使用
するＭＩＰＳプロセッサとして示されており、プラット
フォーム３００はＭＳ−ＤＯＳオペレーティングシステ
ムを使用する８０２８６プロセッサとして示されてい
る）、この発明は均一回路網でも作用するものである。
また、プラットフォームの数は重要ではない。

【００１７】回路網バス５５の構成及びプロトコール
は、それがプラットフォーム１００、２００、及び３０
０の間の情報の通信を考慮にいれる限りは、重要ではな
い。また、この特別の回路網アーキテクチャは、この発
明には充用でない。例えば、この発明に従って使用され
ることの出来る他の回路網アーキテクチャは、一つのプ
ラットフォームを、他のすべてのプラットフォームが接
続される回路網コントローラとして使用する。しかし、
図１に示されている回路網５０は、本発明の利点を強化
するものと考えられる。

【００１８】回路網５０の好適な実施例では、プラット
フォーム１００、２００、及び３００は、各々、中央処
理装置（ＣＰＵ）１１０、２１０、及び３１０をそれぞ
れ包含すると共に、メモリー１５０、２５０、及び３５
０をそれぞれ包含している。各中央処理装置１１０、２
１０、及び３１０には、アプリケーション１２０、２２
０、及び３２０、オペレーティングシステム（ＯＰ Ｓ
ＹＳ）１４０、２４０、及び３４０、及びアプリケーシ
ョン制御アーキテクチャ・サービス（ＡＣＡＳ）ソフト
ウェア構成要素１３０、２３０、及び３３０がそれぞれ
包含されている。

【００１９】アプリケーション１２０、２２０、及び３
２０は、本発明と協働するように前もって書かれて修正
され、又は本発明の与えるサービスを利用するように特
に書かれたプログラムであることが出来る。この解説の
目的のために、アプリケーションは、この発明に従って
行われるべきオペレーションを呼出し、或いは他のアプ
リケーションによる呼出しに応答する。

【００２０】ＡＣＡＳソフトウェア構成要素１３０、２
３０、及び３３０は、この発明のオブジェクト指向的ア
プローチを具体化するものである。好ましくは、ＡＣＡ
Ｓソフトウェア構成要素１３０、２３０、及び３３０
は、詳しく後述する数個のソフトウェア・モジュールか
ら成る。オペレーティングシステム１４０、２４０、及
び３４０は、それぞれ、プラットフォーム１００、２０
０、及び３００の対応するＣＰＵ１１０、２１０、及び
３１０に結び付けられている標準的オペレーティングシ
ステムである。

【００２１】メモリー１５０、２５０、及び３５０は、
幾つかの機能に貢献する。その機能の一つは、勿論、随
伴するプラットフォームのために汎用記憶装置を提供す
ることである。他の機能は、アプリケーション１２０、
２２０、及び３２０と、ＡＣＡＳソフトウェア構成要素
１３０、２３０、及び３３０と、オペレーティングシス
テム１４０、２４０、及び３４０とを、それぞれのＣＰ
Ｕ１１０、２１０、及び３１０によるそれらの実行に先
立って記憶することである。

【００２２】また、メモリー１５０、２５０、及び３５
０の一部分は、回路網５０内のプラットフォーム１０
０、２００、及び３００の全てにより共有され且つ直接
に又は間接的に利用されることの出来る、汎回路網、又
は「大域的な」、データベースについての情報を内蔵す
る。この大域データベースについて以下に詳細に説明す
る。 Ｂ．オブジェクト指向アーキテクチャの要素 （１） 要素の定義 オブジェクト指向的方法は、実際の実施からデータのイ
ンターフェースを分離するためにプログラミングにおい
て使用されてきているが、この様な方法は不均一回路網
には適用されていない。本発明では、オブジェクト指向
技術を使って実際のアプリケーション及びそのデータ
を、他のアプリケーションによるそのデータに対するオ
ペレーションの実施から分離する。

【００２３】この発明のオブジェクト指向アーキテクチ
ャは、好ましくは、或るキー要素を包含する。図２は、
これらの要素の或るものと、アプリケーションの或る普
通の特徴との関係を説明する。図２に示されている様
に、アプリケーション２６０は２通りの方法で記述され
ることが出来る。第１に、そのアプリケーションは或る
アプリケーション定義２６５を持っている。例えば、ア
プリケーション２６０がワード処理プログラムであるな
らば、そのアプリケーション定義は、そのワード処理プ
ログラムが行うことの出来るオペレーションと、そのワ
ード処理システムが操作することの出来るデータの種類
についての定義を含むことが出来る。

【００２４】また、アプリケーション２６０は、アプリ
ケーションデータ２６８を含む。アプリケーションデー
タ２６８は、アプリケーション２６０が操作するデータ
である。本発明に従って、該アプリケーションデータは
オブジェクト指向アーキテクチャによって「処理」され
ない。むしろ、本発明は、該アプリケーション定義及び
アプリケーションデータをオブジェクトの種類（この明
細書の残りの部分でオブジェクトと呼ばれている）に関
しての特徴付けを巡って組織される。オブジェクトは、
図２に示されてはいないが、図示の要素に浸透してい
る。

【００２５】以下の議論において、「オブジェクト」と
いう用語は、幾つかの異なる種類の要素を一般的に指す
が、その全ては二つの特徴を共通に持っている。第１
に、それは外部能力を指し、オブジェクトが、アプリケ
ーション定義又はアプリケーションデータの、他のアプ
リケーションと共に伝えられる必要のある部分を指し又
は記述することを意味する。第２に、それは包括的で、
オブジェクトは全てのアプリケーションに対して利用可
能なものであって、その様なものとして普遍的に認識さ
れた独特の名称を、そのオブジェクトへのインターフェ
ースを有する全てのアプリケーションについて有するこ
とを意味する。本発明は、特別のデータ又はアプリケー
ションの取扱ではなくてオブジェクトの取扱に関わるも
のである。

【００２６】図２に示されている様に、この発明のオブ
ジェクト指向アーキテクチャの二つの要素は、アプリケ
ーション定義２６５から開発される。一つはクラス２７
０で、他方は方法２８０である。クラスは、クラスの名
称とクラスの特徴との両方が外部的で且つ包括的である
という意味でオブジェクトである。更に、クラスは、ア
プリケーションだけでなくて、該アプリケーションによ
り使われるデータをも記述する手段として使われること
が出来る。

【００２７】また、そのアプリケーションによって行わ
れる或る種のオペレーションをアプリケーション定義２
６５から得ることが出来、それは方法２８０の特別の例
である。しかし、特別の方法２８０は、該システムによ
って管理されることはなくて、クラスに編成されること
が出来る。該アプリケーションにより実行される特別の
コマンドやオペレーションがそうではなくても、これら
の方法についてのクラス（方法オブジェクトと呼ばれ
る）は包括的で且つ外部的である。

【００２８】インスタンス２９０は、アプリケーション
データ２６８から得られたものであるが、アプリケーシ
ョンが操作し又はアクセスすることの出来る項目であ
る。インスタンスは、このアーキテクチャにより管理さ
れるオブジェクトではない。むしろ、インスタンスは、
同じクラス内のインスタンスが共通の特徴を共有するこ
ととなる様にクラスに編成される。例えば、特別のＤＥ
Ｃｗｒｉｔｅアプリケーションは、複合文書編集プログ
ラムであるが、ＭＹＦＩＬＥと呼ばれる特別のファイル
上で動作することが出来る。これは特別のファイルであ
って、ＡＣＡＳシステムによっては取り扱われない。む
しろ、ＭＹＦＩＬＥは、包括的で、従ってクラスオブジ
ェクトである例えばＡＳＣＩＩ ＦＩＬＥ等の両立ファ
イルのクラスに属することが出来る。

【００２９】また、特別のＤＥＣｗｒｉｔｅアプリケー
ションも該システム全体によって管理されるものではな
い。しかし、この特別のＤＥＣｗｒｉｔｅアプリケーシ
ョンは、包括的でクラスオブジェクトであるＤＥＣｗｒ
ｉｔｅと呼ばれるクラスに属することが出来る。図２か
ら分かる様に、アプリケーションが属するクラスによ
り、そのアプリケーションにおいて特別の方法を支援す
るクラス（方法オブジェクト）により、該方法オブジェ
クトが操作することの出来るクラスオブジェクトによっ
て、アプリケーションは特徴付けられることが出来る。

【００３０】クラスの特徴の一つは、それらが階層的に
編成され得ることである。このことは、以下に詳しく説
明するけれども、上位クラス及び下位クラスの概念を考
察することにより前もって理解することの出来るもので
ある。上位クラスは、その下位クラスの親であり、各下
位クラスは少なくとも一つの上位クラスの子である。上
位クラス／下位クラスの関係は、上位クラスの属性又は
共有される特徴が下位クラスに受け継がれることを意味
する。例えば、ＤＡＴＡ ＦＩＬＥＳのクラスは、属性
として、開かれ、読み出され、書き込まれることの出来
る能力を持つことが出来る。クラスＤＡＴＡ ＦＩＬＥ
Ｓの二つの下位クラスはＳＥＱＵＥＮＴＩＡＬ ＦＩＬ
ＥＳ及びＲＡＮＤＯＭ ＡＣＣＥＳＳ ＦＩＬＥＳの下
位クラスである。開かれ、読み出され、書き込まれるこ
とが出来るという属性に加えて、下位クラスＳＥＱＵＥ
ＮＴＩＡＬ ＦＩＬＥＳは、順次にアクセス可能である
という属性を持つことも出来、下位クラスＲＡＮＤＯＭ
ＡＣＣＥＳＳ ＦＩＬＥＳは、アドレスにより直接ア
クセス可能であるという属性を持つことが出来る。

【００３１】図２に反映されていない本発明のオブジェ
クト指向アーキテクチャの他の要素は、メッセージであ
る。メッセージは、アプリケーションプログラムと方法
との間のインターフェースであって、クライアント・ア
プリケーションで確認されるインスタンス上に行われる
ことの出来るオペレーションの種類を指定するために該
アプリケーションプログラムにおいて使用される。メッ
セージは、一般に、ＰＲＩＮＴなどのオペレーション
と、数個のパラメーター（これはインスタンス、ストリ
ング、番号、等々であることが出来る）とのセレクター
の形を取る。これらの要素間の関係を次の節で説明す
る。 （２） 要素の関係 図３は、前述した種々の要素の関係を示す図である。図
３が示す様に、各インスタンス３７０にクラス３８０が
随伴している。これを理解する他の道は、クラス３８０
を、そのクラスでの目的の創作（これはインスタンスで
あることが出来る）と、そのオブジェクトの操作とのた
めの「テンプレート」と見なすことである。「テンプレ
ート」という用語は、オブジェクト（それがデータ項
目、方法、又はアプリケーションであるとしても）が各
クラスにおいて、そのクラスにより決まる或る特徴又は
属性を共有することを意味する。

【００３２】インスタンス３７０は、メッセージ３６０
を送ることによって操作される。メッセージ３６０は、
ＥＤＩＴ、ＲＥＡＤ又はＰＲＩＮＴなどの動作である。
メッセージはクラスにより「支援される」と言われる
が、それは、メッセージの解釈が、そのメッセージ内の
インスタンスが属するところのクラスに依存するという
ことを意味する。例えば、若しインスタンスがクラスＣ
ＯＬＯＲ ＧＲＡＰＨＩＣＳ内のカラーグラフイックス
ファイルではなくてクラスＴＥＸＴ ＦＩＬＥ内のテキ
ストファイルであるならば、ＰＲＩＮＴメッセージは別
様に解釈されることがある。

【００３３】メッセージ３６０は、特定のオペレーショ
ンの実施を説明せず、単に特定のオペレーションの実施
へのインターフェースを表すに過ぎない。よって、特定
のメッセージ３６０が要求している特定のオペレーショ
ン（即ち、方法）を発見するためには、該メッセージだ
けではなくて、該インスタンスのクラスをも検査しなけ
ればならない。特別の動作を起こさせるためには、メッ
セージ３６０を実際の実行可能なプログラムコードにマ
ッピングしなければならない。このマッピングは、特定
のインスタンス３７０の特定のクラス３８０に対応する
特定のメッセージ３６０を発見し、次に該クラス３８０
により支援されるメッセージ３６０に対応する特定の方
法３９０を発見することによって行われる。該方法３９
０は、該インスタンス３７０上のメッセージ３６０の所
望のオペレーションを実施する実際の実行可能なプログ
ラムコードを表す。 （３） 編 成 図４は、種々のオブジェクト指向アーキテクチャ要素
を、メモリーにおけるその特別の表示に先立って編成す
る方法を示す。図４から明らかな様に、クラスと方法と
の間には複雑な関係がある。アプリケーション間に存在
しなければならない挙動に関する関係を反映するのに必
要なオブジェクト指向アプローチを実現するために、好
適な実施例では方法及びクラスの両方のために階層が使
用される。しかし、与えられた特別の例は単なる説明の
ためのものであって、これらのクラス及び方法について
の他の種類の表示は当業者には明らかであろう。

【００３４】図４に示されている図では、本質的に２分
岐の階層がある。一つは方法オブジェクト４００という
見出しが付され、他方にはクラス４５０という見出しが
付されている。該分岐、階層は、受け継がれるものによ
り異なる。クラス階層では、受け継がれるものは、メッ
セージを包含するので、挙動についてのものである。方
法階層では、受け継がれるのは属性についてのものだけ
である。クラス階層と方法階層との間の橋は、メッセー
ジ４９０及び４９５などのメッセージと、マップ４９３
及び３９８などの方法マップとを経由する。図４に示さ
れている方法階層では、方法階層４１０、４１５、及び
４２０は、それぞれＷＯＲＤ Ｃ ＣＵＴ ＭＳ−ＤＯ
Ｓ、ＷＯＲＤ Ｃ ＲＥＡＤ ＶＭＳ、及びＷＯＲＤ
Ｃ ＲＥＡＤ ＵＬＴＲＩＸとして表されているが、方
法オブジェクト４００から受け継ぐ。例えば、図４で
は、方法オブジェクト４００は、該方法を指示し、或る
相互作用タイプを使用し、或るサーバー始動タイプを有
する属性（図示せず）を持つことが出来る。

【００３５】方法オブジェクト４１０は、ＥＭＡＣＳア
プリケーションにおいてＣＵＴ機能を代表する。方法４
１０には、方法オブジェクト４００から受け継がれたも
のを包含する属性４３０の組が付随している。簡単に言
うと、ＰｌａｔｆｏｒｍＴｙｐｅ属性は、該方法オブジ
ェクトをその上で実行出来るところのプラットフォーム
を示す。ＩｎｔｅｒａｃｔｉｏｎＴｙｐｅ属性は、特定
の方法サーバーの中で実行される方法の実際の種類を記
述する。以下に説明するこの属性についての値の例は、
ＢＵＩＬＴ ＩＮ、ＳＣＲＩＰＴ ＳＥＲＶＥＲ、及び
ＤＹＮＡＭＩＣ ＬＯＡＤである。ＳｅｒｖｅｒＳｔａｒ
ｔｕｐＴｙｐｅ属性は、該方法サーバーのために使われ
るべき適切な呼出しメカニズムを示す。この属性につい
ての値の例は（これについても後述する）、ＳＨＥＬ
Ｌ、ＤＹＮＡＭＩＣ ＬＯＡＤ、及びＮＡＭＥＤ ＡＰ
ＰＬＩＣＡＴＩＯＮである。

【００３６】属性４３０の組は、ＭＳ ＤＯＳオペレー
ティングシステム付きの８０２８６プロセッサを有し、
ＢＵＩＬＴ ＩＮ、相互作用タイプ、及びＮＡＭＥＤ
ＡＰＰＬＩＣＡＴＩＯＮサーバー始動タイプを有するプ
ラットフォーム上で付随の方法が作動することを示す。
同様に、方法オブジェクト４１５は、ＥＭＡＣＳアプリ
ケーションにおいてＲＥＡＤ機能を代表する。方法４１
５には属性４３５の組が付随しているが、これらの属性
は、方法オブジェクト４００から受け継がれたものを含
んでいるけれども、これも、付随の方法がＶＭＳオペレ
ーティングシステムを走らせるＶＡＸプラットフォーム
上で動作し、ＢＵＩＬＴ ＩＮの相互作用タイプと、Ｎ
ＡＭＥＤ ＡＰＰＬＩＣＡＴＩＯＮサーバー始動タイプと
を有することを示す。

【００３７】方法オブジェクト４２０は、ＥＭＡＣＳア
プリケーションにおけるＲＥＡＤ機能を表す方法オブジ
ェクト４００の下位クラスである。方法クラス４２０に
ついて属性４４０は、ＢＵＩＬＴ ＩＮ相互作用タイ
プ、及びＮＡＭＥＤ ＡＰＰＬＩＣＡＴＩＯＮサーバー
始動タイプでＵＬＴＲＩＸオペレーティングシステムを
走らせるＭＩＰＳプロセッサ付きのプラットフォーム・
タイプを有する。

【００３８】一方、クラス４５０は、ＦＩＬＥＳと呼ば
れるクラス４６０と、ＡＰＰＬＩＣＡＴＩＯＮＳと呼ば
れるクラス４６５との上位クラスである。クラス４６０
はデータオブジェクトを参照する。図４に示されている
様に、クラス４６０は、属性（図示せず）を有し、クラ
ス４７０の上位クラスである。クラス４７０はＡＳＣＩ
Ｉ ＦＩＬＥと呼ばれる。例えば、クラス４７０は、Ａ
ＳＣＩＩファイルの共通の特徴を持っている回路網５０
（図１を見よ）内の全てのファイルを代表することが出
来る。この共通の特徴は、クラス４７０についての属性
において記述されることが出来るが、それは図４には示
されていない。

【００３９】クラス４７０は、数個のインスタンスにつ
いてのクラスであるが、該インスタンスは、該オブジェ
クト指向アーキテクチャによって管理されるものではな
いので、図４には示されていない。図４に示されている
のは、クラス４７０が支援するメッセージであり、簡単
のために図示されている唯一のものはＥＤＩＴメッセー
ジ４９０である。

【００４０】クラス支援メッセージは、該メッセージが
このオブジェクト指向アーキテクチャへのインターフェ
ースとして使われるときには、それを支援するクラスと
共に、従ってそのクラスの中のインスタンスと共に、使
用されることが出来ることを意味する。よって、図４に
示されている例では、ＡＳＣＩＩ ＦＩＬＥクラス内の
全てのインスタンスにＥＤＩＴメッセージを送ることが
出来る。

【００４１】ＡＰＰＬＩＣＡＴＩＯＮＳクラス４６５も
上位クラスであり、その下位クラスの一つ（ＥＤＩＴＯ
Ｒクラス４７５）が示されている。ＥＤＩＴＯＲクラス
４７５は、ＷＯＲＤ Ａ、ＷＯＲＤ Ｂ、又はＷＯＲＤ
Ｃに対応する、特別のアプリケーションクラス４８
０、４８３及び４８５に対して上位クラスである。ＷＯ
ＲＤ Ｃなどの、該クラスの各々は、ＥＭＡＣＳ又はＴ
ＰＵ特別のアプリケーションを代表する。よって、各ア
プリケーションは１クラスにより定義される。しかし、
アプリケーション・クラスは、２アプリケーション以上
の実施挙動に言及することが出来る。

【００４２】アプリケーション・クラスはメッセージも
支援するが、それは、メッセージＣＵＴ４９５がアプリ
ケーション・クラス４８５に支援されていることで示さ
れている。これは、クラス定義の時に、クラス４８５に
より代表される如何なるアプリケーションもメッセージ
ＣＵＴを支援しなければならないことが決定されたとい
う事実を反映している。

【００４３】簡単に上記した様に、好適な実施例では、
アプリケーションは、上位クラスと呼ばれる親クラス
と、下位クラスと呼ばれる子クラスとのあるクラスの階
層に編成される。図４において、クラス４６５は、ＥＤ
ＩＴＯＲと呼ばれる上位クラスである。この上位クラス
の全ての下位クラスは、該上位クラスの特定の独特の特
徴又は属性の同一の組を少なくとも持っている。図４に
おいて、上位クラス４７５ＥＤＩＴＯＲ下位クラスは、
ＷＯＲＤ Ａ４８０、ＷＯＲＤ Ｂ４８３、及びＷＯＲ
Ｄ Ｃ４８５である。ＷＯＲＤ ＡはＴＰＵアプリケー
ションを表し、ＷＯＲＤ Ｂ４８３は全てのＬＳＥアプ
リケーションを表し、ＷＯＲＤ Ｃ４８５は全てのＥＭ
ＡＣＳアプリケーションを表す。これらの上位クラスの
各々は、上位クラス４７５から受け継いだ特徴及び属性
に加えて、それ自身の独特の特徴及び属性の組を持って
おり、その特徴及び属性は、上位クラス４７５ＥＤＩＴ
ＯＲの中で下位クラスとして分離されることが可能とな
る様に異なっている。

【００４４】この発明の好適な実施例では、受け継ぎの
特別の規則は、クラス間での多重受け継ぎを許す様にな
っている。これは、如何なる下位クラスも２以上の上位
クラスを持つことが出来ることを意味する。この種類の
受け継ぎは、定義時に曖昧さを作り出すかもしれないの
で、上位クラスは、潜在的な受け継ぎ矛盾を解決するた
めに定義時に「順序づけ」られると考えられる。例え
ば、後述する下位クラスの定義の時に、メッセージ又は
属性が、記録されている上位クラスの中の二つ以上にお
いて重複して定義されているために矛盾が生じたなら
ば、最高の順位のクラスにおいて定義されているメッセ
ージ又は属性が該下位クラスに受け継がれるものである
と見なされる。

【００４５】前述した様に、方法オブジェクトとクラス
との間の関係は方法マップを経由するものである。図４
は、二つの方法マップ４９３及び４９８を示す。クラス
の各々はメッセージを有し、その各々は特別の方法マッ
プを指す。よって、方法マップ４９３にはＥＤＩＴメッ
セージ４９０が随伴し、方法マップ４９８にはＣＵＴメ
ッセージ４９５が随伴している。

【００４６】好ましくは、方法マップは、メッセージに
随伴する方法オブジェクトの名称を含んでいる。方法マ
ップは、他のクラス及びメッセージの名称を内蔵するこ
とも出来る。よって、方法マップ４９３は、二つの方法
オブジェクトの名称を含んでいる。方法マップ４９３
は、方法オブジェクトＷＯＲＤ Ｃ ＲＥＡＤ ＭＩＰ
Ｓ．ＵＬＴＲＩＸ４９４（これは方法オブジェクト４２
０の名称である）の名称と、方法オブジェクトＷＯＲＤ
Ｃ ＲＥＡＤ ＶＭＳ４９６（これは方法オブジェク
ト４１５の名称である）の名称とを包含している。

【００４７】同様に、メッセージＣＵＴ４９５について
の方法マップ４９８は、名称ＷＯＲＤ Ｃ ＣＵＴ ８
０２８６．ＭＳ−ＤＯＳ４９９を内蔵するが、これは方
法オブジェクト４１０の名称である。この様にして、方
法マップ４９３及び４９８を使って、方法オブジェクト
４１０、４１５、及び４２０にそれぞれ対応する属性の
組４３０、４３５、及び４４０の位置を示すことが出来
る。この種の順位を使って方法の位置を示すやり方を以
下に詳細に説明する。 Ｃ．クラス・データベース構造 該回路網アーキテクチャのクラス及び方法オブジェクト
は、図５に示されているクラス・データベース５００に
記憶される。クラス・データベース５００は、回路網５
０により共有され使用されることの出来る相互に関連し
たデータ項目の非冗長集合体を表す。

【００４８】図４において、クラス・データベース５０
０は、図４に示されているのと類似した２種類のオブジ
ェクトから成っている。該オブジェクトは、クラス５０
５又は方法５４９である。クラス５０５の各々は、対応
するクラスのインスタンスについての包括的外部表示に
対応する。例えば、図５において、クラスオブジェクト
ＡＳＣＩＩ ＦＩＬＥ５０６は、クラスＡＳＣＩＩ Ｆ
ＩＬＥ５０６の特徴を有するインスタンスの組の全ての
構成員についての包括的外部表示に対応する。該特徴
は、属性５１０の対応する組によって表される。

【００４９】好適な実施例では、クラス５０５に対応す
る属性５１０は、システム開発者又はユーザーが希望す
る随意の方法で使われる。例えば、ＡＳＣＩＩ ＦＩＬ
Ｅ５０６についての属性５１１は、クラス５０６をディ
スプレイ上に表示するアイコン（ｉｃｏｎ）の名称を含
むことが出来る。クラス５０５の各々は、メッセージ５
２０の組も支援する。メッセージは、「動詞」又はセレ
クターと呼ばれるＣＵＴ、ＲＥＡＤ又はＥＤＩＴなどの
メッセージ名と、パラメーターとから成る。該パラメー
ターの各々は、名称と、タイプと、方向とから成る。そ
の名称は「タイプ分けされている」が、それは、その名
称が、例えば整数、文字又はストリングなどの特定のタ
イプのものであることを意味する。各パラメーターにつ
いて可能な方向は「イン（ｉｎ）」、「アウト（ｏｕ
ｔ）」及び「イン／アウト（ｉｎ／ｏｕｔ）」である。
メッセージ内のパラメーターが「イン」方向を持ってい
るとき、これは、そのパラメーターが、呼び出されるべ
き方法への入力であることを意味する（後述する）。メ
ッセージ内のパラメーターが「アウト」方向を持ってい
るとき、それは、該パラメーターが方法からの出力であ
ることを意味する。メッセージ内のパラメーターが「イ
ン／アウト」方向を持っているとき、それは、該パラメ
ーターが方法への入力及び方法からの出力の両方である
ことを意味する。

【００５０】メッセージ５２０は、対応するクラス５０
０により表されるインスタンスの各々が支援することの
出来る妥当なオペレーションについての表示である。例
えば、図５において、クラスオブジェクトＡＳＣＩＩ
ＦＩＬＥ５０６は、メッセージ５２１及び５２５を含む
メッセージの組５２０を支援する。メッセージの組５２
０内の特別のメッセージは、ＯＰＥＮ（ＰＡＲＡ １、
ＰＡＲＡ ２．．．）５２１及びＥＤＩＴ（ＰＡＲＡ
１、ＰＡＲＡ ２．．．）５２５である。例えば、メッ
セージＥＤＩＴ（ＰＡＲＡ １）では、ＰＡＲＡ １は
「ＦｉｌｅＮａｍｅ：ストリング、イン／アウト」を表
すが、ここでＦｉｌｅＮａｍｅはパラメーターの名称で
あり、ストリングはパラメーターのタイプであり、イン
／アウトはパラメーターの方向である。

【００５１】メッセージ５２１及び５２５は、各々、そ
れぞれの方法マップ５３０及び５４０を指す。方法マッ
プ５３０及び５４０の各々は、クラス・データベース５
００内の対応する方法オブジェクトへの、又は他のクラ
ス及びメッセージの名称への、参照の組を内蔵する。例
えば、方法マップ５３０は、参照５３１及び５３３を内
蔵しており、その各々は、異なる方法オブジェクト（図
示せず）に対応する。方法マップ５４０も参照５４１及
び５４３を内蔵し、その各々は、クラス・データベース
５００内の方法オブジェクト５４９の中の異なる一つ一
つに対応する。参照５４１についての対応する方法オブ
ジェクトは図５に示されている。この例の目的のため
に、図５は、方法マップ５４０上の参照５４３が方法オ
ブジェクト５５０（これはＥＤ ３ ＲＥＡＤである）
を指すことを示す。

【００５２】上述した様に、クラス・データベース５０
０内の方法オブジェクト５４９も階層的に記憶される。
方法オブジェクト５４９の各々は、方法を行うことの出
来る実行可能なコードへの参照を表す。好適な実施例と
同様の回路網データ処理システムにおいては、方法オブ
ジェクト５４９の各々に随伴していて、各方法オブジェ
クトにより特定される機能を行うことの出来る実行可能
なコードの多くのインスタンスがあり得る。例えば、各
メモリー１５０、２５０及び３５０（図１）において、
方法オブジェクトＥＤ ３ ＲＥＡＤ５５０に実行可能な
コードの設備が随伴することが出来、その実行可能なコ
ードの各々は方法オブジェクトＥＤ ３ ＲＥＡＤ５５
０ＮＯ機能をプラットフォーム１００、２００、及び３
００のそれぞれの一つに行うことが出来る。好適な実施
例によるシステムは、３個の実行可能なコードの間で選
択を行うプロセスを包含する。

【００５３】クラスに随伴する属性５１０とは異なっ
て、方法オブジェクト５４９に随伴するクラス・データ
ベース５００の方法属性５６０は、回路網中の、方法オ
ブジェクト５５０などの特定の方法オブジェクトに随伴
するインスタンスの位置を示して実行するのに使われ
る。簡単のために、図５は、クラス・データベース５０
０内の方法属性５６１の唯一の組を示す。組５６１に
は、クラス・データベース５００内の方法オブジェクト
５４９の中の方法オブジェクト５５０が随伴している。
組５６０内の方法属性の幾つかは、該システムのユーザ
ーによって任意に指定されて実行中に該システムにより
使用されることが出来るけれども、或る属性は、オペレ
ーションにとっては重大である。

【００５４】図５に示されている様に、組５６１内の方
法属性は、ＰｌａｔｆｏｒｍＴｙｐｅ＝８０２８６．Ｍ
Ｓ−ＤＯＳ．ＩｎｔｅｒａｃｔｉｏｎＴｙｐｅ＝ＢＵＩ
ＬＴ ＩＮ．及びＳｅｒｖｅｒＳｔａｔｕｐＴｙｐｅ＝Ｓ
ＨＥＬＬを包含する。好適な実施例では、他に二つの方
法属性が方法属性の組５６１に含まれている。一つは、
指定された方法サーバーが始動されなければならない場
合に、それを始動させるために使われるべき呼出しスト
リングを定義するＩｎｖｏｃａｔｉｏｎＳｔｒｉｎｇ属
性である。この属性の値は、第１属性で指定される特定
のプラットフォームについて適切な値でなければならな
い。例えば、ＰｌａｔｆｏｒｍＴｙｐｅ属性の値がＭＩ
ＰＳ．ＵＬＴＲＩＸで、ＳｅｖｅｒＳｔａｒｔｕｐＴｙ
ｐｅ属性の値がＳＨＥＬＬであれば、この属性の値は適
切なＵＬＴＲＩＸシェル・コマンドであるべきである。 Ｄ．情報の流れ この発明の好適な実施例の詳細を説明する前に、システ
ム全体における情報の流れについて図６を参照して説明
する。

【００５５】図６は、図１に示されている回路網５０の
種々の構成要素と、これらの構成要素の間を流れる情報
とを示す図６００を包含している。図６のアプリケーシ
ョン６１０及び６７０は、各々、アプリケーション１２
０、２２０、又は３２０のいずれか一つにそれぞれ対応
しており、ＡＣＡＳソフトウェア構成要素６２０及び６
６０は、各々、ＡＣＡＳソフトウェア構成要素１３０、
２３０、又は３３０のいずれか一つに対応している。ク
ラス・データベース６４０及びコンテキストオブジェク
トデータベース６３０は、メモリー１５０、２５０、及
び３５０の中の１個以上に記憶される。

【００５６】以下に詳しく説明する様に、アプリケーシ
ョン６１０（これは、「クライアント・アプリケーショ
ン」と称する）は、メッセージを送る。該メッセージ
は、クライアント・アプリケーション（又はその他のア
プリケーション）のインスタンスを識別するのに使われ
るメカニズムであるインスタンス・ハンドルを包含する
ことがある。該メッセージは、クライアント・プラット
フォーム内のソフトウェア構成要素６２０に受け取られ
る。

【００５７】ＡＣＡＳソフトウェア構成要素６２０は、
メッセージと、該インスタンス・ハンドルが指している
インスタンスのクラスとの名称を使って、クラス・デー
タベース６４０内の方法マップを見つけだす。ＡＣＡＳ
ソフトウェア構成要素６２０は、コンテキストオブジェ
クトデータベース６３０からのコンテキスト情報を使っ
て、該方法マップから、実行されるべき方法を表す方法
識別子を選択することも出来る。該コンテキスト情報
は、選択された方法をその上で実行するべきプラットフ
ォーム（「サーバー・プラットフォーム」と称する）を
選択するためにも使われる。該コンテキスト情報につい
て以下に詳細に説明する。

【００５８】ＡＣＡＳソフトウェア構成要素６２０は、
クラス・データベース６４０から検索された方法識別子
とインスタンス・ハンドルとをサーバー・プラットフォ
ーム内のＡＣＡＳソフトウェア構成要素６６０に送る。
その後、ＡＣＡＳソフトウェア構成要素６６０は、「サ
ーバー・アプリケーション」６７０を使って、識別され
た方法を実行するために適切なステップを行うか、或い
は、ＡＣＡＳソフトウェア構成要素６６０を内蔵するサ
ーバー・プラットフォームが要求に答えることが出来な
いことをＡＣＡＳソフトウェア構成要素６２０に知らせ
る。この後者の場合、ＡＣＡＳソフトウェア構成要素６
２０は、該コンテキスト情報を検討して該回路網内の他
のプラットフォームをサーバー・プラットフォームとし
て選択するか、又は、その要求が成就しなかったことを
クライアントに知らせる。

【００５９】図６において確認された方法の、サーバー
・アプリケーション６７０による実行が、クライアント
・アプリケーション６１０に戻されるべきメッセージを
発生させたならば、そのメッセージは、追加の情報と共
に、サーバー・アプリケーション６７０からサーバー・
プラットフォーム内のＡＣＡＳソフトウェア構成要素６
６０に渡される。サーバー・プラットフォーム内のＡＣ
ＡＳソフトウェア構成要素６６０は、クライアント・プ
ラットフォーム内のＡＣＡＳソフトウェア構成要素６２
０に応答を送り、これは、その応答を該クライアント・
プラットフォーム内のクライアント・アプリケーション
６１０へ中継する。

【００６０】これらのトランザクションの全てについて
以下に詳細に説明する。 Ｅ．メモリー・システム （１） 大域クラス・データベース メモリー・システム７００の全体の図が図７に示されて
いる。メモリー・システム７００は、大域クラス・デー
タベース７０５と、局所クラス・データベース７１０、
７３０及び７５０とを包含している。後述する他の或る
情報を回路網のユーザーが利用できる様にするために、
汎回路網メモリー７０５も設けられている。

【００６１】大域クラス・データベース７０５は、プラ
ットフォームがアクセス出来る情報を内蔵する。好まし
くは、大域クラス・データベース７０５は、プラットフ
ォームのメモリー全体に分散されている。例えば、図７
において、大域クラス・データベース７０５は、メモリ
ー１５０、２５０、及び３５０の各々の中に部分的に内
在するものとして示されている。大域クラス・データベ
ース７０５の残りの部分は、図７に示されていない他の
メモリーに内在する。大域クラス・データベース７０５
の内容は、図４及び５に関して既に説明した。

【００６２】当業者は、図７に示されている分散メモリ
ー構成は本発明を実施するのに必要ではないことを理解
するであろう。例えば、本発明の原理に影響を与えず
に、大域クラス・データベース７０５の全体を単一ノー
ドのメモリーに又は専用のメモリーに記憶させることが
出来る。また、メモリー１５０、２５０、及び３５０の
各々は、局所クラス・データベース７１０、７３０、及
び７５０と共に、ノード・キャッシュ７２０、７４０、
及び７６０をそれぞれ有するものとして示されている。
局所クラス・データベースの情報は、対応するプラット
フォーム上のユーザーだけがアクセス可能である。ノー
ド・キャッシュ７２０、７４０、及び７６０は、大域ク
ラス・データベース７０５の、対応するプラットフォー
ムによって頻繁にアクセスされる部分のコピーを保持す
るのに使われる。

【００６３】該大域クラス・データベース構造を具体化
するのに使われるデータベース・システムは、単一のデ
ータベースの中の名称の大域的独自性、データベースを
横断する識別子の独自性、アクセス制御メカニズム、及
び適切な記憶及び検索メカニズムを支援するべきであ
る。大域的な名称の独自性は、包括的（ｇｅｎｅｒｉ
ｃ）であるので、オブジェクトにとって重要である。識
別子の独自性は、後述する様にデータベースを組み合わ
せることを可能にする。

【００６４】該データベース・システムのアクセス制御
メカニズムは、該回路網内の随意のプラットフォーム上
の正当と認められたユーザーがオブジェクト及び属性を
記憶し且つ検索することを可能にするものでなければな
らず、且つ、大域クラス・データベース７０５の完全性
を危険に曝すことを防止するために予防制御（ｓｅｃｕ
ｒｉｔｙ ｃｏｎｔｒｏｌ）及び構文チェックを提供し
なければならない。この制御の詳細の一部を以下に説明
する。残りは、周知のデータベース管理技術に関わるも
のである。

【００６５】本実施例は、（オブジェクト名称と同じ
く）オブジェクトを指すのに使うことの出来るオブジェ
クト識別子を大域クラス・データベース７０５内の各オ
ブジェクトに割り当てることが出来ることを必要とす
る。オブジェクト識別子は、２進コードであるので、好
都合なことに言語中立でもある。オブジェクト識別子
は、「大域的に」承認された方式に基づいて割り当てら
れ、そして、何個のクラス・データベースにわたっても
独特である。一方、オブジェクト名称は、単一のクラス
・データベースの中だけで独特であれば良い。クラス名
称と識別子との差異は、例によって良く理解することが
出来る。二つの会社が、各々それ自身のクラス・データ
ベースを持っていて、これらのデータベースを合併させ
たいと希望しているとする。これらのデータベースは、
合併されたデータベース内では異なっているべき同一の
名称のクラスを持っていることがあり、その差異は、大
域的に独特の識別子を通して維持されることが出来る。
該データベースは、合併されたデータベース内では同一
であるべき異なった名称の二つのクラスも持っているこ
とがある。これらのクラスは、同じクラス識別子を有す
ることとなる様にセットされることが出来る。よって、
オブジェクト識別子は、大域クラス・データベース内の
同じクラスが２以上のクラス名称によって識別されるこ
とを許す。例えば、回路網内の大域クラス・データベー
ス内のクラス名称ＥＤＩＴＯＲＳは、クラス名称ＷＰＲ
ＯＣＥＳＳＯＲＳによっても識別される。

【００６６】ＡＣＡＳソフトウェア構成要素１３０、２
３０、及び３３０の各々にも含まれている他のソフトウ
ェア構成要素は、クラス・データベース内で使用され記
憶されるための独特のオブジェクト識別子を作り出すメ
カニズムを提供する。好ましくは、オブジェクト名称の
永続的記憶を必要とするアプリケーションにより採用さ
れる記憶方式は、多数の大域クラス・データベース間の
命名の矛盾を避けるために、オブジェクト名ではなくオ
ブジェクト識別子を記憶するべきである。

【００６７】好都合なことにアプリケーションはそれ自
身のアプリケーション・インスタンス・データの組を完
全に管理するので、大域クラス・データベース７０５は
アプリケーション・インスタンス・データを記憶するよ
うにはなっていない。このために、既存のアプリケーシ
ョンは、その現在の記憶戦略を続けることが出来、新し
いアプリケーションのために利用可能な記憶オプション
は制限されない。

【００６８】しかし、好適な実施例は、二つのメカニズ
ム、即ち記憶クラス及びインスタンス命名を提供し、こ
れにより、アプリケーションは、その専用のインスタン
スを、好適な実施例によって維持される大域クラス・デ
ータベース７０５に接続することが可能となる。記憶ク
ラスは、アプリケーションが専用のインスタンスの解釈
の仕方を指定することを可能にする抽象である。記憶ク
ラスは、インスタンスがメッセージにおいて使われると
きに各インスタンスのクラスを識別することの代わりと
なるものである。好適な実施例では、記憶クラスは、イ
ンスタンスの名称を内蔵するレポジタリー（ｒｅｐｏｓ
ｉｔｏｒｉｅｓ）又はファイルなどの記憶システムを特
定する。例えば、記憶クラスは、ＲＭＳ ＦＩＬＥやＵ
ＮＩＸ ＦＩＬＥなどの既知の記憶メカニズムを記述す
ることが出来る。

【００６９】この発明のオブジェクト指向アーキテクチ
ャでは、記憶クラスはクラスであるとも見なされる。ク
ラス・データベースに記憶されている他のクラスと同じ
く、記憶クラスは、属性、メッセージ、及び方法から成
る実際のオブジェクト指向クラス定義と見ることの出来
るものである。各記憶クラスに随伴する方法は、そのイ
ンスタンスの記憶クラスにより識別される特定の記憶シ
ステムに随伴するインスタンスについてのクラス名を検
索するのに使われる。

【００７０】他方のメカニズム、即ちインスタンス命
名、は好適な実施例においてインスタンスの命名のため
に標準を使用する。該標準インスタンス・ハンドルは、
以下の論理構造により表されるストリングである： ＜ｃｌａｓｓ＞＜ｓｔｏｒａｇｅ ｃｌａｓｓ＞＜ｌｏ
ｃａｔｉｏｎ＞＜ｉｎｓｔａｎｃｅ ｒｅｆｅｒｅｎｃ
ｅ ｄａｔａ＞ 「クラス」（ｃｌａｓｓ）という用語は、随伴するＡＣ
ＡＳクラスの名称である。「記憶クラス」（ｓｔｏｒａ
ｇｅ ｃｌａｓｓ）という用語は、クラス名の代わりで
あって、記憶クラスの名称である。「位置」（ｌｏｃａ
ｔｉｏｎ）という用語は、インスタンスの、ノードなど
の論理的位置である。「位置」は随意的であって、イン
スタンスがある位置と同じ位置で方法が走ることをクラ
イアントが希望する場合に使用されるものである。「イ
ンスタンス基準データ」（ｉｎｓｔａｎｃｅ ｒｅｆｅ
ｒｅｎｃｅ ｄａｔａ）という用語は、インスタンス・
ハンドルは、アプリケーション専用部分である。

【００７１】インスタンス・ハンドルは、設備がインス
タンスを抽象的に指すことを可能にし、従ってインスタ
ンス自体を管理する必要が無い。インスタンス・ハンド
ルは、好都合なことには、クラス又は記憶クラス（必要
ならば）、インスタンスの位置、及び該インスタンスに
ついての識別子を含む。例えば、 ＥＤＩＴ（ＩＮＳＴＡＮＣＥ ＨＡＮＤＬＥ） というメッセージにおいて、ＥＤＩＴは所望のオペレー
ションを表す。ＩＮＳＴＡＮＣＥ ＨＡＮＤＬＥストリ
ングは、ＡＳＣＩＩ ＦＩＬＥ／ＮＯＤＥ １／ＭＹＦ
ＩＬＥ．ＴＸＴであることが出来る。このインスタンス
・ハンドルでは、ＡＳＣＩＩ ＦＩＬＥはクラスを表
し、ＮＯＤＥ １はインスタンスの位置であり、ＭＹＦ
ＩＬＥ．ＴＸＴは該インスタンスの識別子である。この
メッセージは、適切な方法マップを発見するのに充分な
クラス及びメッセージ情報を提供する。好適な実施例が
達成するのと同じ目的を達成するためにＩＮＳＴＡＮＣ
Ｅ ＨＡＮＤＬＥストリングについて他のフォーマット
を使用することも出来ることは当業者には明らかであろ
う。

【００７２】既に説明した様に、好適な実施例の大域ク
ラス・データベース内の全てのクラスは特定の大域クラ
ス・データベースと共に独特の名称を持っている。該ク
ラス名は、一般に、該クラスを最初に定義するユーザー
によって割り当てられる。 （２） 局所クラス・データベース 大域クラス・データベースに加えて、好適な実施例は、
クラス及び方法定義についての局所クラス・データベー
スも支援する。局所クラス・データベースは、局所クラ
ス・データベースの内容が大域的に利用可能ではないこ
とを除いて、大域クラス・データベースと同様に機能す
る。これらは、その局所ノードのために利用可能であれ
ばよい。よって、局所クラス・データベースを他の切に
分散させたり複写したりする必要はない。

【００７３】図７は、それぞれメモリー１５０、２５
０、及び３５０内における局所クラス・データベース７
１０、７３０、及び７５０の好適な設備を示す。大域ク
ラス・データベース７１０、７３０、及び７５０は、該
大域クラス・データベースに未だ加えられていない対応
するノードにより作られるクラス及び方法を保持する。
好適な実施例では、メモリー１５０、２５０及び３５０
は、それぞれ、ノード・キャッシュ７２０、７４０及び
７６０も含んでおり、それは、大域クラス・データベー
ス７０５からロードされる方法及びクラス情報を保持す
る。キャッシュは、最適化であり、厳密に要求されるわ
けではない。

【００７４】局所クラス・データベースを具体化するの
に使われるデータベース・システムは、単一のデータベ
ースの中で名称の独自性をもたらさなければならない。
局所クラス・データベースのためのアクセス制御は、デ
ータベース・レベルでのみ必要とされるに過ぎない。局
所クラス・データベースの好適な実施例は、該局所クラ
ス・データベースの内容へのアクセスを制御するために
該データベース・システムの中で下に位置する機密メカ
ニズム（ｓｅｃｕｒｉｔｙ ｍｅｃｈａｎｉｓｍ）に依
拠する。

【００７５】局所クラス・データベースの使用は、大域
クラス・データベースの使用に比べて幾つかの利点をも
たらす。例えば、局所クラス・データベースは、回路網
が利用できないときでもオブジェクト指向的に相互に通
信し続ける能力を各ノード上のアプリケーションに与え
る。その様な場合、該ノード上のアプリケーションは、
そのノードに特有の他のアプリケーションを呼出し続け
ることが出来る。

【００７６】また、多くの呼出しは、単一のプラットフ
ォームの範囲内で完全に操作されることが出来るので、
局所クラス・データベースを使えば、該局所クラス・デ
ータベースと同じノード内にあるアプリケーションのた
めに一層良好な動作が得られる。局所的に取り扱われる
ことの出来る呼出しを殆どのアプリケーションが使いそ
うなプラットフォームの上では、局所クラス・データベ
ースを使うと、呼出しを達成するために大域クラス・デ
ータベースにアクセスするなどの回路網の活動の必要が
無くなり、又は大いに減少する。

【００７７】大域データベースを探索する前に局所デー
タベースを探索することにより、クラス・データベース
はクラス及び方法の情報について好都合に探索される。
各ノードの局所データベースは、後述する所定の順序で
好都合に探索される。所望の情報の位置が突き止められ
ると、直にその探索は停止する。所望の情報の位置が局
所データベース内に突き止められない場合に限って、大
域データベースが探索される。よって、該探索順序は、
クラス・データベースの「優先順位」を定義する。

【００７８】図８は、局所クラス・データベース８００
の一部の一つの設計を示す。しかし、この設計は、ハン
ドルにとって重大ではない。好ましくは、局所クラス・
データベースは８００は、局所クラス・データベース８
００においてインデックス及び割り振りマップなどの、
組織に関する他の情報の位置を示すのに使われるデータ
ベース・ヘッダ−８１０を内蔵する。局所クラス・デー
タベース８００は、クラス及び方法に関する情報を保持
する数個のブロック８２０、８２２、及び８２４を内蔵
するブロック記憶スペース８１５も包含する。

【００７９】図９は、ブロック８２０、８２２、又は８
２４であることの出来るブロック９００の好都合な構成
を示す。ブロック９００は、ブロック９００の始めに位
置する、該ブロック内のオブジェクトの位置を特定する
登録簿９１０と、オブジェクト記憶部９２０とを包含す
る。登録簿９１０内の項目９５５及び９６５は、各々、
ブロック９００のオブジェクト記憶部９２０内に位置す
る異なるオブジェクト９５０及び９６０に対応する。各
登録薄項目は、ＩＤフィールド９１２についての値（こ
れは対応するオブジェクトを特定する）、ＯＦＦＳＥＴ
フィールド９１５についての値（これは、ブロック９０
０内の対応するオブジェクトの相対的位置を表す）、及
び、対応するオブジェクトに割り振られたブロック９０
０の量を示すＳＩＺＥフィールド９１７についての値を
包含する。

【００８０】オブジェクト９５０及び９６０は好都合な
ことには文字ストリングとして書式作成されるが、他の
技術を使うことも出来る。再び図８を参照すると、局所
クラス・データベース８００は、好都合なことには、そ
の名称をオブジェクト識別子に相関させることによっ
て、オブジェクトを検索することを可能にするＮＡＭＥ
−ＴＯ−ＩＤ−ＩＮＤＥＸ８３０を包含する。

【００８１】オブジェクト識別子は、ＩＤ ＴＯ ＢＬ
ＯＣＫ ＮＯ．ＭＡＰ８４０に含まれている。マップ８
４０は、局所クラス・データベース８００において識別
される各々の独自のオブジェクトについてのブロック番
号を提供する。局所クラス・データベース８００内の残
りのフィールドは、ＢＬＯＣＫ ＴＡＢＬＥ８５０であ
る。ＢＬＯＣＫ ＴＡＢＬＥ８５０は、好都合なことに
は、ブロック８２０、８２２、及び８２４の位置と、局
所クラス・データベース８００の中の利用可能なスペー
ス８２９の位置とを包含する。利用可能なスペース８２
９は、局所クラス・データベース８００により割り振ら
れたブロック記憶スペース８１５の未使用スペースであ
る。

【００８２】局所クラス・データベース８００からオブ
ジェクトを検索するために、そのオブジェクトについて
の名称がＮＡＭＥ−ＴＯ−ＩＤ−ＩＮＤＥＸ８３０にマ
ッピングされる。ＮＡＭＥ−ＴＯ−ＩＮＤＥＸ８３０か
らの識別子情報は、ＩＤ−ＴＯ−ＢＬＯＣＫ ＮＯ．Ｍ
ＡＰ８４０を使って適切なブロック番号へマッピングさ
れる。該マッピングは、所望のオブジェクトが現在ある
場所のブロック番号をもたらす。所望のオブジェクトを
伴うブロックの位置が示されると、オブジェクト登録簿
９１０を使ってそのオブジェクトが発見される（図
９）。 （３） ローダー／アンローダー 図１０に示されている様に、好都合なことには、局所ク
ラス・データベース１００、大域クラス・データベース
１０２０、及びノード・キャッシュ１０３０の間にＬＯ
ＡＤＥＲ／ＵＮＬＯＡＤＥＲソフトウェア構成要素１０
１０が接続されている。ＬＯＡＤＥＲ／ＵＮＬＯＡＤＥ
Ｒソフトウェア構成要素１０１０は、ＡＣＡＳソフトウ
ェア構成要素１３０、２３０、及び３３０（図１）の一
部であり、局所データベース１０２０、ノード・キャッ
シュ１０３０、及び局所クラス・データベース１０２０
への、及びこれらからの、ＡＣＡＳ情報の転送を制御す
るために使われる。好適な実施例では、ＬＯＡＤＥＲ／
ＵＮＬＯＡＤＥＲソフトウェア構成要素１０１０は、局
所クラス・データベース１０００が情報を大域クラス・
データベース１０２０にロードし、ノード・キャッシュ
１０３０がクラス・データベース情報を大域クラス・デ
ータベース１０２０から検索することを可能にする。ロ
ード及びアンロードの際に、ＬＯＡＤＥＲ／ＵＮＬＯＡ
ＤＥＲ構成要素１０１０は、好都合なことには記憶のた
めにメモリー１５０を使用する。

【００８３】ＬＯＡＤＥＲ／ＵＮＬＯＡＤＥＲソフトウ
ェア構成要素１０１０は、局所クラス・データベース１
０００内のクラス情報を大域クラス・データベース１０
２０へ転送することを希望するユーザーにより作動させ
られる。この転送により、以前は該プラットフォームだ
けに対してアクセス可能であった情報に、大域クラス・
データベース１０２０を通じて全ての回路網ユーザーが
アクセス出来る様になる。局所クラス・データベース１
０００からのクラス情報の、大域クラス・データベース
１０２０への転送は、好都合なことには、ＡＳＣＩＩフ
ォーマットのクラス及び方法オブジェクト定義をＬＯＡ
ＤＥＲ／ＵＮＬＯＡＤＥＲソフトウェア構成要素１０１
０に送って大域クラス・データベースにロードさせるこ
とにより達成される。ＬＯＡＤＥＲ／ＵＮＬＯＡＤＥＲ
ソフトウェア構成要素１０１０は、好都合なことには、
局所クラス・データベースにより記憶されている言語定
義を分解するプロセスを実行し、それらの定義を適切な
ＡＳＣＩＩ表示に変換する。ＬＯＡＤＥＲ／ＵＮＬＯＡ
ＤＥＲ１０１０は、大域クラス・データベースにより適
切なフォーマットで記憶されるべきこのＡＳＣＩＩ表示
のフォーマットを整える。

【００８４】ＬＯＡＤＥＲ／ＵＮＬＯＡＤＥＲソフトウ
ェア構成要素１０１０は、ノード・キャッシュ１０３０
へのロードのために大域クラス・データベース１０２０
から情報をアンロード又は検索するユーザーからの要求
にも応答しなければならない。検索された情報は、好都
合なことには、ＬＯＡＤＥＲ／ＮＬＯＡＤＥＲソフトウ
ェア構成要素１０１０により言語定義に変換され、この
定義はノード・キャッシュ１０３０に記憶される。 Ｆ．クラス及び方法の創出、定義／登録 （１） 創 出 好都合なことには、クラスは、例えばＬＯＡＤＥＲ／Ｕ
ＮＬＯＡＤＥＲにおいて使われる言語などの非手順言語
を使って定義され、次にコンパイルされてクラス・デー
タベースにロードされる。該言語、コンパイラ及びロー
ダー・ソフトウェアは好都合なことにはオブジェクト定
義設備の構成要素である。他の周知の技術も、当業者に
は自明であろう。

【００８５】該オブジェクト定義設備は、ＡＣＡＳソフ
トウェア構成要素１３０、２３０、及び３３０（図１）
の一部であって、クラス、メッセージ、クラス属性、方
法及び方法属性を定義する手段を提供する。この設備
は、クラス間の受け継ぎの指定にも対処するものであっ
て、上記のＬＯＡＤＥＲ／ＵＮＬＯＡＤＥＲソフトウェ
ア構成要素１０１０と共に、大域クラス・データベース
及び局所クラス・データベースの中の既存の定義を修正
するために使われることが出来る。また、該オブジェク
ト定義設備は、好都合なことには、大域クラス・データ
ベース内で新しいクラス及び方法定義を作るのに使われ
るクラス定義入力及び方法定義入力の所要の構文チェッ
クを行う。該オブジェクト定義設備のユーザーは、クラ
スを作るために或る情報を指定しなければならない。こ
の情報は、好都合なことには、大域クラス名称及び識別
子；このクラスの上位クラスの大域名称及び識別子（若
しあるならば）；このクラスにより支援されるメッセー
ジと、それに付随するアーギュメントのタイプ（若しあ
るならば）；定義される方法マップ及び各マップが関連
するメッセージ；並びに、このクラスについて定義され
た属性、を包含する。

【００８６】各メッセージは、好都合なことには、メッ
セージの名称、該メッセージにより支援されるパラメー
ター、及び対応する方法マップを含む構造を生成するこ
とにより指定される。各メッセージ構造は、好適な実施
例では２組の値に変換される。１組の値は、メッセージ
名と、該メッセージにより支援されるパラメーターのリ
ストとを包含する。他の組の値は、該メッセージの実施
を表す方法オブジェクトの組を特定する。

【００８７】方法オブジェクトは、クラスと同じ方法で
回路網環境内で定義される。しかし、好適な実施例のオ
ブジェクト定義設備は、方法オブジェクトの定義のため
の特別の備えを持っている。方法オブジェクトを定義す
るとき、次の情報、即ち、該方法オブジェクトの大域名
称と識別子；該方法オブジェクトの上位クラスの大域名
称と識別子；並びに、方法属性として記憶されるメタデ
ータ（即ち、データの記述）、が指定される。該方法定
義は、アーギュメント、及び、該メッセージ内のパラメ
ーターに対応するそのタイプ、並びに、該方法がパラメ
ーター・リストを含むか否か、を指定する。このパラメ
ーター・リストは、該方法により呼び出されることの出
来る実行可能なコード（後述する）により要求される入
力を表す。 （２） 方法／クラス定義 好適な実施例では、クラス及び方法定義のロードは、実
行時間前に行われ、或いは実行時間中に動的に行われ
る。クラス及び方法オブジェクトは、回路網内のノード
上で局所的にアクセス可能であるか（「局所定義」と称
する）、又は回路網内の全てのプラットフォームから大
域的にアクセス可能である（「大域定義」と称する）。
局所定義及び大域定義は、共に、ＬＯＡＤＥＲ／ＵＮＬ
ＯＡＤＥＲソフトウェア構成要素１０１０又は他の何ら
かの許容出来るメカニズムを使って達成されることが出
来る。 （３） サーバー登録 サーバー登録の目的は、メッセージからの要求に答える
ために利用出来る方法サーバーを発見することである。
方法サーバーは、方法を実現する活動中の（即ち、現在
走っている）プロセスである。方法サーバーは、単一の
アプリケーションのコード又は１個以上のアプリケーシ
ョンのコードの多くの部分の実行を必要とすることがあ
る。

【００８８】方法サーバーの登録は、クラス及び方法オ
ブジェクトの定義とは別である。クラス及び方法オブジ
ェクトの定義は、システムにおけるそれらの存在を識別
するために使われるのに対して、方法サーバーの登録
は、それらの状況（即ち、使用可能性）を追跡するため
に使われる。方法サーバーが登録されなければ、それは
システムにとっては未知である。 （４） アプリケーションの設置及び定義 好都合なことには、回路網においてアプリケーションを
登録し設置するために支援メカニズムが設けられる。好
適な実施例は、クラス・データベースに記憶されている
クラス、下位クラス、メッセージ及び方法のオブジェク
ト指向モデルにおいてアプリケーション及びアプリケー
ション断片を定義する能力をもたらす。この様なアプリ
ケーションの定義は、この発明の好適な実施例により行
われるアプリケーション間通信の実行のために重要であ
る。詳しく言うと、クラス・データベース内のクラス・
下位クラス、メッセージ及び方法の記憶は、アプリケー
ションが、実行時間中に該クラス・データベースを更新
すると共に、再コンパイルと再連係とを必要とすること
無くその更新したクラス・データベースを使って処理し
続けることを可能にする。

【００８９】アプリケーションは、他のクラスと同様に
して定義される。実際、上述した様に、アプリケーショ
ンは、それ自体が特別の種類のクラスであると定義され
る。アプリケーションは、そのプラットフォーム上の特
定のオペレーティングシステムに必要とされる方法でプ
ラットフォーム上に設置される。この発明の好適な実施
例では、アプリケーション設置は、幾つかの追加の機能
も必要とする。例えば、既に定義されているのでなけれ
ば、アプリケーションは、既存のＡＣＡＳ ＡＰＰＬＩＣ
ＡＴＩＯＮの下位クラスとして定義されるそれ自身のク
ラス定義を設けなければならない。

【００９０】アプリケーション設置は、既に設置されて
いるクラス定義を使ってもよく、或いは新しい定義を付
加してもよい。アプリケーション設置時には、設置手順
は、該アプリケーションにより支援されるクラス定義を
コンパイルして、上記したＬＯＡＤＥＲ／ＵＮＬＯＡＤ
ＥＲソフトウェア構成要素１０１０を使って局所クラス
・データベース又は大域クラス・データベースに登録す
ることが出来、その新しいアプリケーションによる影響
を受けるデータオブジェクトクラスの方法マップを更新
しなければならない。アプリケーション設置は、上記し
た方法オブジェクト定義手順も必要とする。 Ｇ．コンテキストオブジェクトデータベース この発明の好適な実施例では、コンテキストオブジェク
トデータベース６３０（図６を見よ）は方法を分解し、
方法を実行するべきプラットフォームを選択し、回路網
内にクラス・データベースを置くために使われるべき優
先順位を定義するメカニズムを提供する。数レベルのコ
ンテキストオブジェクトデータベースが図１の回路網５
０内に存在することが出来る。例えば、１レベルはユー
ザーコンテキストオブジェクトデータベースから成り、
もう一つのレベルはグループコンテキストオブジェクト
データベースから成る。システム（又はプラットフォー
ム）コンテキストオブジェクトデータベースも、該プラ
ットフォーム全体のユーザーのために優先順位を特定す
るために使われる。全てのコンテキストオブジェクトデ
ータベースは、方法分解時に優先順位を供給するけれど
も、グループコンテキストオブジェクトデータベース
は、２以上のユーザーの優先順位を認識するためにＡＣ
ＡＳソフトウェア構成要素１３０、２３０、及び３３０
により使われ、システムコンテキストオブジェクトデー
タベースは、２以上のグループの優先順位を認識するた
めに使われる。好都合なことには、方法分解において、
ユーザーコンテキストオブジェクトデータベース内の優
先順位がグループコンテキストオブジェクトデータベー
ス内のそれをオーバーライドし、それがシステムコンテ
キストオブジェクトデータベースをオーバーライドする
様に、コンテキストオブジェクトデータベース６３０内
のデータベースは使われる。

【００９１】コンテキストオブジェクトデータベース６
３０は、好都合なことには、特定の回路網セッション時
にユーザーに随伴するプラットフォーム上にある。ユー
ザーが回路網に入るときに実行される初期ログオン手順
において、そのユーザーに随伴するコンテキストオブジ
ェクトデータベースに記憶されている情報は、後にＡＣ
ＡＳソフトウェアの動作時に使用されるために呼び出さ
れる。

【００９２】図１１は、コンテキストオブジェクトデー
タベース１１００のための好適なメモリーシステムを示
す。コンテキストオブジェクトデータベース１１００
は、方法オーバーライド・テーブル１１１０、サーバー
・ノード・テーブル１１５０、及びクラス・データベー
ス・オーバーライド・テーブル１１７０、並びに他のユ
ーザー定義テーブル１１８０を含む。方法オーバーライ
ド・テーブルは、メッセージ名と、インスタンス・ハン
ドルにおいて特定されるクラスとに応じて好適な方法を
選ぶために、方法分解（詳しく後述する）の際に使われ
る。サーバー・ノード・テーブル１１５０は、プラット
フォームを選んで、サーバー・プラットフォームである
ことの出来る回路網内に置くために、呼出し動作（これ
についても詳しく後述する）の際に使われる。クラス・
データベース・オーバーライド・テーブル１１７０は、
方法及びクラス情報について局所クラス・データベース
を探索する順序を定義する。

【００９３】テーブル１１１０、１１５０、及び１１７
０は、システム供給テーブルである。ユーザーは、自身
の好みを実現するために自身のテーブル１１８０を供給
してもよい。方法オーバーライド・テーブル１１１０の
好適な実施例が図１１Ｂに示されている。方法オーバー
ライド・テーブル１１１０は、方法セレクター属性名称
１１１５と、随伴する値１１２０とのリストを含む。各
項目は、属性名称１１１５について、好適な値１１２０
を指定する。例えば、図１２において、好適なプラット
フォームはＶＡＸ．ＶＭＳと指定され、好適な相互作用
タイプはＢＵＩＬＴ ＩＮである。２以上の方法がメッセ
ージに応じて特定されると、テーブル１１１０内の優先
順位は、それらの方法の中から一つを選ぶのに使われ
る。属性について値が指定されていなければ、システム
は、優先順位は無いと見なす。

【００９４】コンテキストオブジェクトデータベース１
１００のサーバー・ノード・テーブル１１５０の好適な
実施例が図１３に示されている。サーバー・ノード・テ
ーブル１１５０は、図１の回路網５０内のノードの順序
づけられたリストである。テーブル１１５０内の各項目
は、プラットフォーム・タイプ１１５２と、選ばれた方
法を実施するのに使われることの出来る対応するプラッ
トフォーム・タイプを伴う回路網５０内のノード１１５
４の場所とに対応する。例えば、テーブル１１５０は、
ＴＹＰＥ Ａのプラットフォームタイプについて２個の
ノード、ノードａ及びノードｂ、を特定している。

【００９５】図１４は、クラス・データベース・オーバ
ーライド・テーブル１１７０の好適な実施例を包含す
る。テーブル１１７０は、局所クラス・データベース１
１７２の名称と、その場所１１７４とを含む数個の項目
を包含している。項目１１７５については、データベー
スＤＢ ＳＣＨ ＬＳＴは場所ｄｂｌ及びｄｂ２にあ
り、テーブル１１７０のもっと下側に列挙されている他
の局所クラスオブジェクトデータベースより前に探索さ
れる。

【００９６】本発明の好適な実施例は、コンテキストオ
ブジェクトデータベースを作成し、システムコンテキス
トオブジェクトデータベースの各々の中の項目を付加
し、修正し及び削除する能力をもたらす回路網の全ユー
ザーに利用可能なインターフェースを包含する。このイ
ンターフェースは、好都合なことには、これらの機能を
行うために標準的コンパイラを実行する。例えば、コン
テキストオブジェクトデータベースに項目を付加するた
めには、ユーザーは、設けられているインターフェース
を使ってコマンドを入力する。そのコマンドは、ＡＣＡ
Ｓソフトウェア構成要素１３０、２３０、及び３３０
（図１）により解釈されて、該インターフェースが受け
取ったデータを該標準的コンパイラにより適切なフォー
マットに変換せしめる。 Ｈ．ＡＣＡＳサービス （１） 一般的動作 この発明の好適な実施例の或る構成要素についての以上
の説明で、ＡＣＡＳ構成要素についての充分な理解が得
られるであろう。好都合なことには、本発明は、クライ
アントが要求を発生させ、サーバーが要求に答えるクラ
イアント／サーバー・モデルを使って実施される。以下
の記述においては、クライアント・プラットフォーム上
のクライアント・アプリケーションに随伴するサービス
又はオペレーションは「クライアント・サービス」と呼
ばれ、サーバー・プラットフォーム上で実行するサーバ
ー・アプリケーションに随伴するサービス又はオペレー
ションは「サーバー・サービス」と呼ばれる。好適な実
施例のクライアント・サービス及びサーバー・サービス
は、クライアント・プラットフォームからのメッセージ
をサーバー・プラットフォームへ、及びサーバー・プラ
ットフォームから、送ることの出来る輸送システムに依
拠する。好適な実施例では、ＲＰＣの様な通信システム
が該輸送システムとして使われる。

【００９７】図１に示されているＡＣＡＳソフトウェア
構成要素１３０、２３０、及び３３０は、好都合なこと
には、クライアント・サービス及びサーバー・サービス
をそれぞれ表すクライアント・サービス構成要素及びサ
ーバー・サービス構成要素を包含する。これは、例え
ば、２個のプラットフォーム１２００及び１３００と回
路網バス５５との図である図１５に示されている。プラ
ットフォーム１２００及び１３００は、図１のプラット
フォーム１００、２００、又は３００のいずれにも対応
することが出来る。

【００９８】プラットフォーム１２００及び１３００内
に、それぞれ、メモリー１２５０及び１３５０と、ＣＰ
Ｕ１２１０及び１３１０とがある。プラットフォーム１
２００及び１３００内の要素は、図１に関して上記した
類似の要素と同様に機能する。ＣＰＵ１２１０はクライ
アント・アプリケーション１２２０を実行し、ＣＰＵ１
３１０はサーバー・アプリケーション１３２０を実行す
る。ＣＰＵ１２１０及び１３１０は、ＯＰ ＳＹＳ １
１２４０及びＯＰ ＳＹＳ ２ １３４０もそれぞれ
実行し、且つ、ＡＣＡＳソフトウェア構成要素１２３０
及び１３３０もそれぞれ実行する。

【００９９】ＡＣＡＳソフトウェア構成要素１２３０及
び１３３０は、好都合なことには、指名ソフトウェア構
成要素１２３２及び１３３２をそれぞれ包含し、制御サ
ーバー・ソフトウェア構成要素１２３４及び１３３４を
それぞれ包含し、呼出しソフトウェア構成要素１２３６
及び１３３６をそれぞれ包含し、補助ソフトウェア構成
要素１２３７及び１３３７をそれぞれ包含している。

【０１００】大抵、呼出しソフトウェア構成要素１２３
６及び１３３６はクライアント・サービスを表し、指名
ソフトウェア構成要素１２３２及び１３３２はサーバー
・サービスを表す。補助ソフトウェア構成要素１２３７
及び１３３７は、好適な実施例の他の或るオペレーショ
ンを表す。回路網内のプラットフォーム１２００及び１
３００は、呼出しソフトウェア構成要素１２３６及び１
３３６をそれぞれ内蔵し、制御サーバー・ソフトウェア
構成要素１２３４及び１３３４をそれぞれ内蔵し、指名
ソフトウェア構成要素１２３２及び１３３２をそれぞれ
内蔵しているので、いずれのプラットフォームもクライ
アントとして又はサーバーとして活動することが出来
る。

【０１０１】好適な実施例では、呼出しソフトウェア構
成要素１２３６及び１３３６と指名ソフトウェア構成要
素１２３２及び１３３２とは、コンテキストオブジェク
トデータベース内のコンテキストデータと同様にクラス
・データベース内のクラス及び方法情報を解釈して、呼
び出すべき適切な方法を決定し、その方法をどの様にし
て呼び出すかを決定し、その方法を実施するコードを実
行するために必要なコマンドを指名する責任を有する。
呼出しソフトウェア構成要素１２３６及び１３３６及び
指名ソフトウェア構成要素１２３２及び１３３２は、ク
ライアント・アプリケーションを方法呼出し及び輸送レ
ベル・メカニズムの詳細から隔離させる。

【０１０２】制御サーバー・ソフトウェア構成要素１２
３４及び１３３４は、幾つかの機能を持っている。一つ
の機能は、現在作動中のサーバー・アプリケーションに
関する情報を回路網５０内のプラットフォーム１２００
及び１３００に記憶させることである。制御サーバー・
ソフトウェア構成要素１２３４及び１３３４は、方法サ
ーバーとなる新しいアプリケーションを始動させるプロ
セスも実行する。制御サーバー・ソフトウェア構成要素
１２３４及び１３３４が行う他の機能は、方法サーバー
登録である。例えば、制御サーバー・ソフトウェア構成
要素１３３４は、サーバー・プラットフォーム１３００
上で現在作動している、サーバー・アプリケーション１
３２０により特定される方法サーバーに関する情報を記
憶する。制御サーバー・ソフトウェア構成要素１３３４
は、汎回路網メモリー７０４（図７）におけるサーバー
登録設備とも通信して、サーバー・アプリケーション１
３２０に関する状況情報を記憶する。

【０１０３】補助ソフトウェア構成要素１２３７及び１
３３７は、クラス及び方法オブジェクト定義及び登録、
各プラットフォームの方法実行可能なカタログにおける
方法実行可能な登録（後述する）、ＬＯＡＤＥＲ／ＵＮ
ＬＯＡＤＥＲソフトウェア構成要素１０１０（図１０）
の機能などのＡＣＡＳソフトウェア構成要素１２３０及
び１３３０のオペレーションを表す。

【０１０４】以下の説明の目的のために、プラットフォ
ーム１２００はクライアント・プラットフォームと呼ば
れ、プラットフォーム１３００はサーバー・プラットフ
ォームと呼ばれる。この例では、クライアント・アプリ
ケーション１２２０は、サーバー・プラットフォーム１
３００内のサーバー・アプリケーション１３２０とオブ
ジェクト指向的に通信する。本発明に従って、好適な実
施例においては、１プラットフォーム上のクライアント
・アプリケーションは、同じプラットフォーム上のサー
バー・アプリケーションと通信することが出来る。

【０１０５】クライアント・アプリケーション１２２０
がサーバー・アプリケーション１３２０と通信すると
き、クライアント・プラットフォーム１２００の指名ソ
フトウェア構成要素１２３２及び制御サーバー・ソフト
ウェア構成要素１２３４は関与しないので、図１５では
陰が付けられている。同じく、サーバー・プラットフォ
ーム１３００の呼出しソフトウェア構成要素１３３６
は、活動していないので、陰が付けられている。

【０１０６】図１６は、好適な実施例に従う方法の呼出
しにおいて行われる主な機能の概略を示す流れ図１３６
０である。流れ図１３６０中のステップを開始する前
に、ＡＣＡＳソフトウェア構成要素１２３０及び１３３
０は最初に「待ち」状態にある。クライアント・アプリ
ケーション１２２０が方法呼出し要求を送るとき、図１
６に示されているＡＣＡＳソフトウェア構成要素１２３
０及び１３３０のプロセスが始まる。この方法呼出し要
求は、クライアント・アプリケーション１２２０の所望
のオペレーションを特定する入力メッセージを包含す
る。

【０１０７】第１に、該方法呼出し要求は呼出しソフト
ウェア構成要素１２３６に受け取られ（ステップ１３７
０）、この構成要素１２３６は該方法呼出し要求を処理
する（ステップ１３７５）。呼出しプロセスについて
は、以下に詳しく説明する。呼出しプロセスの普通の結
果は、処理済み方法呼出し要求である。次に、呼出しソ
フトウェア構成要素１２３６は、処理済みの方法呼出し
要求を、回路網バス５５を介して指名ソフトウェア構成
要素１３３２に送る（ステップ１３８０）。指名ソフト
ウェア構成要素１３３２及び制御サーバー１３３４は、
そのとき、それらの動作を開始する。

【０１０８】その処理済み方法呼出し要求を受け取った
後、指名ソフトウェア構成要素１３３２及び制御サーバ
ー・ソフトウェア構成要素１３３４は、該呼出し要求に
より特定される方法をサーバー・アプリケーション１３
２０により実行させる（ステップ１３９０）。サーバー
・アプリケーション１３２０は、該方法の実行を完了す
ると、その実行から生じたアーギュメントを出力し、指
名ソフトウェア構成要素１３３２は状況メッセージ（例
えば、「成功」）を生成する。その出力アーギュメント
及び状況メッセージは、処理済み方法呼出し要求（今
や、「応答」と呼ばれる）にマッピングされる。次に、
この応答は該指名ソフトウェア構成要素１３３２によっ
て呼出しソフトウェア構成要素１２３６に送られる。呼
出しソフトウェア構成要素１２３６は、元の方法呼出し
要求にマッピングされた指名ソフトウェア構成要素１３
３２から受け取られた応答をクライアント・アプリケー
ション１２２０に戻す（ステップ１３９５）ことによっ
て処理を完了する。

【０１０９】ＡＣＡＳソフトウェア構成要素１２３０及
び１３３０についての以上の説明により、この発明の好
適な実施例における情報の流れを良く理解出来る。図１
７は、呼出しソフトウェア構成要素１２３６から指名ソ
フトウェア構成要素１３３２への情報の流れによる影響
を受ける回路網５０の他の要素を示す。クライアント・
アプリケーション１２２０、サーバー・アプリケーショ
ン１３２０、呼出しソフトウェア構成要素１２３６、指
名ソフトウェア構成要素１３３２、及び制御サーバー・
ソフトウェア構成要素１３３４に加えて、図１７は、コ
ンテキストオブジェクトデータベース６３０（図６）、
クラス・データベース６４０（図６）、サーバー登録設
備１４２０、及び制御サーバー登録１４２５を包含する
が、これは、制御サーバー・ソフトウェア構成要素１３
３４によって維持されて、サーバー・プラットフォーム
内の実行可能なコードを追跡する。

【０１１０】図１４に示されている様に、コンテキスト
オブジェクトデータベース６３０は、ユーザーコンテキ
ストオブジェクトデータベース１４０２、グループコン
テキストオブジェクトデータベース１４０４、及びシス
テムコンテキストオブジェクトデータベース１４０６を
包含しており、この各々については、コンテキストオブ
ジェクトデータベースに関する説明において上述してあ
る。クラス・データベース６４０は、局所データベース
１０００（図１０）、ノード・キャッシュ１０３０、及
び大域クラス・データベース１０２０を包含する。クラ
ス・データベース６４０のこれらの要素の各々につい
て、クラス・データベースに関する説明において上述し
てある。

【０１１１】上述した様に、呼出しソフトウェア構成要
素１２３６に送られる方法呼出し要求をクライアント・
アプリケーション１２２０が生成するときに情報の流れ
が始まる。このインターフェースは、好都合なことに
は、好適な実施例のＩｎｖｏｋｅＭｅｔｈｏｄ手順コー
ルにより提供される。ＩｎｖｏｋｅＭｅｔｈｏｄ手順コ
ールにおいては、クライアント・アプリケーション１２
２０は、インスタンス・ハンドルと、メッセージ（メッ
セージ名、及びパラメーター・リストを含む）と、コン
テキストオブジェクトハンドルと、随意に出力インスタ
ンス・ハンドルとを、呼出しソフトウェア構成要素１２
３６に送る。

【０１１２】以上に詳しく説明した様に、インスタンス
・ハンドルは、方法呼出しに関与すべくクライアント・
アプリケーション１２２０が選んだ現在のインスタンス
を特定する構造である。メッセージ名は、該インスタン
スに対する所望のオペレーションを表す。メッセージ・
パラメーター・リストは、該メッセージが要求するパラ
メーターから成る。コンテキストオブジェクトハンドル
は、詳しく後述する呼出しプロセスにおいて使われるべ
きコンテキストオブジェクトデータベースを特定する参
照である。出力インスタンス・ハンドルは、呼び出され
る方法に随伴する作動中の方法サーバーのインスタンス
を表す。これにより、クライアント・アプリケーション
は、同じ方法サーバーとの対話を持ち続けることが出来
る。出力インスタンス・ハンドルの意味論は、インスタ
ンス・ハンドルについてのそれと同じである。

【０１１３】呼出しソフトウェア構成要素が方法呼出し
要求を受け取ったとき、呼出しソフトウェア構成要素１
２３６は、方法識別子を発見するためにコンテキストオ
ブジェクトデータベース６３０及びクラス・データベー
ス６４０に問い合わせる。この手順については上述し
た。該メッセージ名についての適切な方法識別子を決定
すると、呼出しソフトウェア構成要素１２３６は、次
に、該方法識別子に随伴する方法をその上で実行するべ
きサーバー・プラットフォームを発見するためにサーバ
ー登録設備１４２０とコンテキストオブジェクトデータ
ベース６３０とに問い合わせる。サーバー登録設備１４
２０は、該方法識別子に随伴する方法を行うことの出来
る作動中の方法サーバー（若しあるならば）の場所を確
認するために使われる。作動中の方法サーバーは、既に
始動したものとして自身を回路網５０に知らせた、例え
ばサーバー・アプリケーション１３２０などの、方法サ
ーバーである。

【０１１４】若し作動中の方法サーバーがあるならば、
呼出しソフトウェア構成要素１２３６により処理される
呼出し要求の方法を実行させることをクライアント・ア
プリケーション１２２０のユーザーが望む回路網５０
（図１）中の遠くのプラットフォームの場所を決定する
ために、呼出しソフトウェア構成要素は、コンテキスト
オブジェクトデータベース６３０のサーバー・プラット
フォーム・テーブルにも問い合わせる。しかし、サーバ
ー・アプリケーション１３２０が利用可能でなければ、
制御サーバー・ソフトウェア構成要素１３３４は、選ば
れた遠くのプラットフォーム上で該サーバー・アプリケ
ーションが利用可能でないことを呼出しソフトウェア構
成要素１２３６に知らせる。以上に略述した様に処理を
する呼出しソフトウェア構成要素１２３６は、特定され
た方法をその上で実行するべき回路網５０内の他のプラ
ットフォームを選ぶために、コンテキストオブジェクト
データベース６３０及びサーバー登録設備１４２０のサ
ーバー・プラットフォーム・テーブルに再び問いあわせ
を始める。

【０１１５】次に、呼出しソフトウェア構成要素１２３
６は選択されたサーバー・プラットフォームの制御サー
バー・ソフトウェア構成要素１３３４に問いあわせを送
り、これによって、制御サーバー・ソフトウェア構成要
素１３３４は、処理済み方法呼出し要求で特定される方
法を処理するために、選択されたサーバー・プラットフ
ォーム上の所望の方法サーバーを利用できるか否か決定
するために制御サーバー登録１４２５に問いあわせをす
る。方法サーバーの利用可能性は、好適な実施例では、
制御サーバー登録１４２５において、クライアント・ア
プリケーションにより呼び出された方法を該方法サーバ
ーが現在処理出来るか否か検査することによって決定さ
れる。

【０１１６】サーバー・アプリケーション１３２０の形
の方法サーバーが利用可能であることを制御サーバー・
ソフトウェア構成要素１３３４が呼出しソフトウェア構
成要素１２３６に示せば、呼出しソフトウェア構成要素
１２３６は、該処理済み方法呼出し要求を該サーバー・
プラットフォームの指名ソフトウェア構成要素１３３２
へ送る。呼出しソフトウェア構成要素１２３６は、コン
テキストオブジェクトデータベース６３０からの情報を
送ることも出来るが、それは所望の方法サーバーによっ
て使用されることが出来る。

【０１１７】指名ソフトウェア構成要素１３３２は、そ
のとき、その所望の方法を処理し始める。このプロセス
（「指名プロセス」と称する）は、一般に、該方法識別
子を指名してサーバー・アプリケーション１３２０によ
る該方法の実行を始めさせることを含む。しかし、回路
網内のプラットフォームで現在作動しているサーバー・
アプリケーション１３２０のコピーがあることをサーバ
ー登録設備１４２０が示さなければ、呼出しソフトウェ
ア構成要素１２３６は、コンテキストオブジェクトデー
タベース６３０及びクラス・データベース６４０から検
索された情報を使って、サーバー・アプリケーション１
３４０を始動させる要求を制御サーバー・ソフトウェア
構成要素１３３４に送ることが出来る。サーバー・アプ
リケーション１３２０が始動させられた後、制御サーバ
ー・ソフトウェア構成要素１３３４は、サーバー登録設
備１４２０に通知して、サーバー・アプリケーション１
３２０が作動していることを示す様に汎回路網メモリー
７０４（図７）を更新させる。制御サーバー・ソフトウ
ェア構成要素は、サーバー・アプリケーション１３２０
が使用可能であることを示すように制御サーバー登録１
４０５も更新する。呼出しソフトウェア構成要素１２３
６は、そのとき、該処理済み方法呼出し要求を指名ソフ
トウェア構成要素１３３２に送って、該処理済み方法呼
出し要求の方法識別子に対応する方法を実行させる。

【０１１８】サーバー・アプリケーション１３２０は、
その処理を終えた後、該処理済み方法呼出し要求により
要求された出力情報を指名ソフトウェア構成要素１３３
２に戻す。指名ソフトウェア構成要素１３３２は、その
とき、上述したように、指名ソフトウェア構成要素１３
３２により受け取られた該処理済み方法呼出し要求の出
力アーギュメントにマッピングされた出力情報と共に、
応答を呼出しソフトウェア構成要素１２３６に戻す。 （２） 呼出しオペレーション 呼出しソフトウェア構成要素１２３６が行う方法呼出し
のプロセスの部分を、今や詳細に説明することが出来
る。好都合なことには、その部分は、呼び出されるべき
適切な方法を決定すること（方法分解）、サーバー接続
又は始動、及び、該方法サーバー又はその他の実行可能
なコードにより実行されるべき適切な方法への識別子の
指名を可能にする輸送レベル通信、を含む数個の別々の
段階から成る。

【０１１９】図１８−２１及び２２は、図１５及び１７
の呼出しソフトウェア構成要素１２３６により行われ又
は呼ばれる手順の流れ図を含む。図１８−２１における
主な制御手順１５５０は、呼出しソフトウェア構成要素
１２３６により行われるステップ１３７０、１３７５、
及び１３８０（図１６）を表す。手順１３６０の場合と
同じく、主制御手順１５５０に入る前に、クライアント
・アプリケーション１２２０（図１５及び１７）は通常
は方法呼出し要求無しに作動しており、ＡＣＡＳソフト
ウェア構成要素１２３０は「待ち」状態にある。クライ
アント・アプリケーション１２２０がＩｎｖｏｋｅＭｅ
ｔｈｏｄ手順コールを使って方法呼出し要求を生成する
とき、主制御手順１５５０が始まり（図１８のステップ
１５５２）、呼出しソフトウェア構成要素１２３６は方
法呼出し要求を受け取る（ステップ１５５５）。

【０１２０】呼出しソフトウェア構成要素１２３６は最
初に該方法呼出し要求を確認する（ステップ１５５
７）。若しエラーがあったならば、呼出しソフトウェア
構成要素１２３６はエラー・メッセージを生成し（ステ
ップ１５５８）、これを呼出しソフトウェア構成要素１
２３６はクライアント・アプリケーション１２２０に戻
す（図２１のステップ１５９９）。

【０１２１】若し該方法呼出し要求が妥当であるならば
（図１８のステップ１５５７）、呼出しソフトウェア構
成要素１２３６は、次に、呼び出されるべき方法を、Ｉ
ｎｖｏｋｅＭｅｔｈｏｄコール内のメッセージ、クラス
・データベース、及びコンテキスト対象データベースか
ら分解する（ステップ１５６０）。方法分解は、適切な
方法を決定又は特定するプロセスである。

【０１２２】図２２は、方法を分解する好適な手順１６
００を示す。方法分解について既に言及したけれど、手
順１６００は、この様な分解について、叙上よりも遥か
に詳しく示す。好適な実施例では、呼び出されるべき適
切な方法の決定は、呼出しソフトウェア構成要素１２３
６により間接的に処理される。方法分解のための作業の
大半は、ＡＣＡＳソフトウェア構成要素１２３０及び１
３３０の補助ソフトウェア構成要素１２３７及び１３３
７によって処理される。好適な実施例では、補助ソフト
ウェア構成要素１２３７は、コンテキストオブジェクト
データベース及びクラス・データベースから情報を検索
する。勿論、呼出しソフトウェア構成要素１２３６も、
その様な情報を検索することが出来る。

【０１２３】方法分解手順１６００を開始した後（ステ
ップ１６０５）、呼出しソフトウェア構成要素１２３６
は、インスタンス・ハンドルが記憶クラス名称部分を含
んでいるか否か判定する（ステップ１６１０）。若し記
憶クラスが存在するならば、その位置が確認され（ステ
ップ１６２０）そのインスタンス・ハンドルに随伴する
クラスの名称を検索するために特別の方法が呼び出され
る（ステップ１６３０）。

【０１２４】クラス名を検索するために記憶クラスによ
り特定される方法を呼び出した後、又は、インスタンス
・ハンドルが記憶クラス名を包含していないと判定した
後、上記の探索順序を使ってクラス・データベース６４
０（図６及び１７）についてクラス情報の位置を確認す
るために呼出しソフトウェア構成要素１２３６によって
プロセスが実行される（ステップ１６４０）。例えば、
メッセージがＥＤＩＴ（ＩＮＳＴＡＮＣＥ ＨＡＮＤＬ
Ｅ）で、インスタンス・ハンドルがＡＳＣＩＩ ＦＩＬＥ
／ＮＯＤＥ １／ＭＹＦＩＬＥ．ＴＸＴであれば、クラ
ス名ＡＳＣＩＩ ＦＩＬＥを使ってクラス・データベー
ス６４０内のクラスＡＳＣＩＩ ＦＩＬＥ１６４５を発
見することが出来る。

【０１２５】次に、該メッセージのＥＤＩＴという名称
で、適切な方法マップ１６５５がクラス・データベース
６４０から検索される（ステップ１６５０）。説明して
いる特別の例では、好適な実施例の補助ソフトウェア構
成要素１２３７は、方法マップ１６５５を検索すると共
に、ステップ１６４０で位置が確認されたクラス情報が
メッセージ名ＥＤＩＴを包含することを検査して確かめ
る。これにより、対応するメッセージが該クラスにより
支援されることが保証される。

【０１２６】図２２に示されている様に、方法マップ１
６５５は、メッセージ名ＥＤＩＴ及びクラスＡＳＣＩＩ
ＦＩＬＥ１６４５について方法オブジェクトＭＥＴＨ
ＯＤ１及びＭＥＴＨＯＤ ２を包含する。方法オブジェ
クトＭＥＴＨＯＤ １には属性の組１６５７が随伴し、
方法オブジェクトＭＥＴＨＯＤ ２には属性の組１６５
９が随伴している。属性の組１６５７は、ＭＥＴＨＯＤ
１がＰＬＡＴＦＯＲＭ ＴＹＰＥ Ａ上で実行される
ことが出来ることを示し、属性の組１６５９は、Ｍｅｔ
ｈｏｄ ２がＰＬＡＴＦＯＲＭ ＴＹＰＥ Ｂ上で実行
されることが出来ることを示す。

【０１２７】方法マップには数個の方法オブジェクトが
あるかも知れないので、曖昧さを解明するためにコンテ
キストオブジェクトデータベース６４０に参照符が付さ
れる（ステップ１６６０）。コンテキストオブジェクト
データベース６４０に参照符を付するとき、維持されて
いる適切なサーバー・ノード・テーブルも、後に使用さ
れるために検索される。

【０１２８】コンテキストオブジェクトデータベース６
３０内の項目（若しあるならば）は、そのとき、方法オ
ブジェクト、従って、該メッセージにより表される所望
のオペレーションを実行する適切な方法とを選ぶために
（ステップ１６８０）、方法マップ上の方法コンテキス
トの組の中の属性と比較される（ステップ１６７０）。
図２２において、方法オーバーライド・テーブル１６６
５は、ユーザー優先順位がＰｌａｔｆｏｒｍＴｙｐｅ
Ａについて優位であることを示す項目１６６８を含む。
この項目１６６８を使って、呼出しソフトウェア構成要
素１２３６は、クラス・データベース６４０から、所望
のオペレーションＥＤＩＴを実行する適切な方法１６８
６を選ぶ。図２２に示されている例では、適切な方法
は、ＰＬＡＴＦＯＲＭ ＴＹＰＥ Ａ上で実行されるべ
きＭｅｔｈｏｄ １である。手順１６００は、今、図１
８乃至図２１の主制御手順１５５０に戻る（ステップ１
６８５）。

【０１２９】方法分解手順１６００の作動中の随意の点
において若しエラーがあれば（ステップ１６４０時など
に、インスタンス・ハンドルにおいて特定されたクラス
がクラス・データベースにおいて位置確認可能なクラス
でないならば）、方法分解手順１６００は、このエラー
を示すメッセージと共に戻る。方法分解手順１６００か
ら戻った後、方法分解プロセス時にエラーが発生したか
否か判定が行われる（図１８のステップ１５６２）。若
し答えが「ｙｅｓ」ならば、呼出しソフトウェア構成要
素１２３６は、適切なエラー・メッセージを生成し（ス
テップ１５６３）、該エラー・メッセージをクライアン
ト・アプリケーション１２２０に戻す（図２１のステッ
プ１５９９）。

【０１３０】そうでない場合、エラー無しに方法を分解
した後（図１８のステップ１５６２）、呼出しソフトウ
ェア構成要素１２３６は、回路網内の適切なプラットフ
ォーム上で適切な方法を実行するために、分解された方
法の識別子に対応する方法属性を検討する。該方法が既
にクライアント・アプリケーション１２２０内に連結さ
れている事をこれらの方法属性が、示すならば（例え
ば、ＩｎｔｅｒａｃｔｉｏｎＴｙｐｅ方法属性の値が
「ＢＵＩＬＴ ＩＮ」であるなど）、起動エラーについ
てチェックが行われる（ステップ１５６６）。若し一つ
あったならば、エラー・メッセージが生成され（ステッ
プ１５７６）、コントロールはクライアント・アプリケ
ーション１２２０に戻される（図２１のステップ１５９
９）。

【０１３１】若しエラーが無かったならば、成功フラグ
が生成され（ステップ１５６７）、クライアント・アプ
リケーション１２２０内に既に常駐しているコードによ
って、分解された方法が実行される（ステップ１５６
９）。該方法がクライアント・アプリケーション１２２
０に既に連結されていることを該方法属性が示さなけれ
ば（図１９のステップ１５６５）、呼出しソフトウェア
構成要素１２３６は、該方法が動的にロード可能である
ことを該方法属性が示しているか否か問い合わせる（ス
テップ１５７０）。動的にロード可能な方法は、実行時
にクライアント・アプリケーションの実行可能なコード
と合併させることの出来る実行可能な方法を代表する。
動的にロード可能な方法は、クライアント・アプリケー
ションの副手順又は機能により特定される実行可能な方
法であり得ることを当業者は認めるであろう。好都合な
ことには、動的にロード可能な方法サーバーについての
試験は、ＩｎｔｅｒａｃｔｉｏｎＴｙｐｅ方法属性の値
が「ＤＹＮＡＭＩＣ ＬＯＡＤ」であるか否か判定する
ことによって達成される。若しそうならば、呼出しソフ
トウェア構成要素１２３６は、分解された方法により特
定される実行可能なコードをクライアント・アプリケー
ション１２２０にロードしようと試みる（ステップ１５
７２）。

【０１３２】実行可能なコードのロード中にエラーが発
生したならば（ステップ１５７４）、呼出しソフトウェ
ア構成要素１２３６は、ロード・エラーが発生したこと
を示すメッセージを生成し（ステップ１５７６）、該ロ
ード・エラー・メッセージをクライアント・アプリケー
ション１２２０に戻す（図２１のステップ１５９９）。

【０１３３】そうでない場合、ロード・エラーが若し無
かったならば（ステップ１５７４）、呼出しソフトウェ
ア構成要素１２３６は、該方法呼出しが首尾よく完了し
たことを示すフラグを生成する（ステップ１５６７）。
次に、分解された方法に対応する、動的にロードされた
実行可能なコードが実行され（ステップ１５６９）、コ
ントロールは出力アーギュメントと共にクライアント・
アプリケーション１２２０に戻る（図２１のステップ１
５９９）。連結された又は動的にロード可能な方法サー
バーを実行している際のエラーは好都合なことにはパラ
メーター値として戻される。

【０１３４】方法属性が、前もって連結された、又は動
的にロード可能な方法を示さなければ（図１９のステッ
プ１５６５及び１５７０）、呼出しソフトウェア構成要
素１２３６は、図１７に関して上述した分解された方法
を処理することの出来る回路網内のプラットフォーム上
の実行中の方法サーバーの位置を確認しなければならな
い。

【０１３５】サーバー登録設備１４２０（ステップ１５
７８）から検索された情報が、分解された方法により特
定される方法を行うことの出来る作動中の方法サーバー
が少なくとも一つあることを示すならば（図２０のステ
ップ１５７９）、呼出しソフトウェア構成要素１２３６
は、サーバー登録設備１４２０から検索された情報を、
該方法分解手段１６００時にコンテキストオブジェクト
データベース６３０から検索されたサーバー・ノード・
テーブル上の項目と比較して回路網内のサーバー・プラ
ットフォームを選ぶ（ステップ１５８０）。

【０１３６】サーバー・プラットフォームを選んだ後、
呼出しソフトウェア構成要素１２３６は、ＱｕｅｒｙＳ
ｅｒｖｅｒコールを、その選択されたサーバー・プラッ
トフォームの制御サーバー・ソフトウェア構成要素１３
３４に送る。制御サーバー・ソフトウェア構成要素１３
３４の機能については、図２３及び２４に関して以下に
詳しく説明する。簡単には、制御サーバー・ソフトウェ
ア構成要素１３３４は、所望の方法サーバーが使用可能
であるか否かを判定する。

【０１３７】呼出しソフトウェア構成要素１２３６の主
制御手順１５５０は、そのとき、ステップ１５８２（図
２０）において継続して、所望の方法サーバーの使用可
能性について制御サーバー・ソフトウェア構成要素１３
３４により生成されたメッセージを受け取り、該メッセ
ージを、クライアント・アプリケーションが認識出来る
フォーマットに変換する。呼出しソフトウェア構成要素
１２３６は、制御サーバー・ソフトウェア構成要素１３
３４から、分解された方法に対応する方法サーバーが、
分解された方法により特定される方法を処理するために
使用出来るか否か判定する（ステップ１５８３）。若し
その対応する方法サーバーが使用出来るならば、該方法
サーバーが図２１において非同期方法サーバーであるか
否か問い合わせる（ステップ１５９３）ことにより呼出
しソフトウェア構成要素の処理が図２１において継続す
る。非同期方法サーバーは当該技術分野において公知で
ある。

【０１３８】該方法サーバーが非同期であれば（ステッ
プ１５９３）、該方法サーバーに知らせるためにＳｉｇ
ｎａｌＳｅｒｖｅｒコールを使って制御サーバー・ソフ
トウェア構成要素１３３４が呼び出される（ステップ１
５９４）。該方法サーバーが非同期でない場合、又は非
同期方法サーバーが信号された後（ステップ１５９
４）、該方法についての識別子と、方法分解時にコンテ
キストオブジェクトデータベースから検索された情報と
を含む、処理済み方法呼出し要求は回路網における通信
に使われるデータ構造にまとめられ（ステップ１５９
５）、呼出しソフトウェア構成要素１２３６は、そのま
とめられた処理済み方法呼出し要求を指名ソフトウェア
構成要素１３３２へ送る。指名ソフトウェア構成要素１
３３２のプロセスについて、図２５及び２６を参照して
以下に説明する。

【０１３９】指名ソフトウェア構成要素１３３２がその
処理を終えて、まとめられた応答を送った後、呼出しソ
フトウェア構成要素１２３６は、そのまとめられた応答
を受け取り（ステップ１５９７）、その応答をほぐし
（アンパックし）（ステップ１５９８）、その処理を完
了させるために該応答をクライアント・アプリケーショ
ン１２２０に戻す（ステップ１５９９）。

【０１４０】若し前の判定（図２０のステップ１５８
３）において、実行中の方法サーバーが使用可能でない
ことが分かったならば、呼出しソフトウェア構成要素１
２３６は、分解された方法により特定される方法を行う
ことの出来る他の実行中の方法サーバーをサーバー登録
設備１４２０が示したか否か判定する（ステップ１５８
４）。若しそうならば、検索された情報は、コンテキス
トオブジェクトデータベース６３０内のサーバー・ノー
ド・テーブルと照合され、ＱｕｅｒｙＳｅｒｖｅｒコー
ルが制御サーバー・ソフトウェア構成要素１３３４に対
して行われる（ステップ１５８１）。

【０１４１】そうでない場合、呼出しソフトウェア構成
要素は、最高の優先順位のサーバー・ノードをサーバー
・ノード・テーブルから選択する（ステップ１５８
６）。その選択されたサーバー・プラットフォームの制
御サーバー・ソフトウェア構成要素１３３４は、そのと
き、分解された方法により特定される方法に対応する適
切なアプリケーションを始動させようと試みるために制
御サーバー・ソフトウェア構成要素１３３４に指示する
ＳｔａｒｔＳｅｒｖｅｒコールを使って接触される（ス
テップ１５８７）。

【０１４２】制御サーバー・ソフトウェア構成要素１３
３４がその処理を終えてメッセージを送った後、呼出し
ソフトウェア構成要素１２３６は、その送られたメッセ
ージを受け取ってアンパックする（ステップ１５８
８）。アプリケーションが始動させられて方法サーバー
になったならば（ステップ１５８９）、呼出しソフトウ
ェア構成要素１２３６はその処理を終えるが、それにつ
いては既に説明した（図２１のステップ１５９３）。若
しアプリケーションが始動させられなければ（ステップ
１５８９）、呼出しソフトウェア構成要素１２３６は、
コンテキストオブジェクトデータベース６３０のサーバ
ー・ノード・テーブルにそれ以上のノードがあるか否か
問い合わせる（ステップ１５９０）。若しそうでなけれ
ば、サーバー・プラットフォームが位置確認出来なかっ
たので方法呼出しが不成功だったことを示すエラー・メ
ッセージが生成され（ステップ１５９２）、そのエラー
・メッセージはクライアント・アプリケーション１２２
０に戻される（図２１のステップ１５９９）。

【０１４３】しかし、他のノードがサーバー・ノード・
テーブル上にあれば（図２０のステップ１５９０）、次
に高い優先順位のプラットフォームが選択され（ステッ
プ１５９１）、呼出しソフトウェア構成要素１２３６の
処理は図２０のステップ１５８７に戻る。方法サーバー
が始動させられるまで（ステップ１５８９）又はサーバ
ー・プラットフォーム・リスト上にプラットフォームが
無くなるまで（ステップ１５９０）、ステップ１５８
７、１５８８、１５８９、１５９０、及び１５９１から
成るループが行われる。 （３） 制御サーバー・オペレーション 図２３及び２４は、制御サーバー・ソフトウェア構成要
素１３３４のオペレーションを表す制御サーバー手順１
７００を示す。当業者は、制御サーバー・ソフトウェア
構成要素１３３４の機能を具体化する他の多くの方法を
理解するであろう。

【０１４４】図２３のステップ１７０２において制御サ
ーバー手順１７００を開始した後、制御サーバー・ソフ
トウェア構成要素１３３４は制御サーバー・メッセージ
を受け取る（ステップ１７０５）。これに応じて、制御
サーバー・ソフトウェア構成要素１３３４は、制御サー
バー・ソフトウェア構成要素１３３４と共通のプラット
フォーム上で実行中のアプリケーションが方法呼出し要
求を処理するべく方法サーバーとして登録されるべきこ
とを要求していることを該制御サーバー・メッセージが
示しているか否か判定する（ステップ１７１０）。答え
が「ｙｅｓ」ならば、制御サーバー・ソフトウェア構成
要素１３３４は、該方法サーバーが使用可能であること
を示すために該サーバー・アプリケーションについての
所要の情報を制御サーバー登録１４２５に記録すること
によって該サーバー・アプリケーションを方法サーバー
として登録する。制御サーバー・ソフトウェア構成要素
１３３４は、該方法サーバーが実行中であることを示す
ためにサーバー登録設備１４２０にも知らせる（ステッ
プ１７１５）。実行中の使用可能な方法サーバーは、適
切な方法を実行することも出来る。制御サーバー・ソフ
トウェア構成要素１３３４は、今登録されたアプリケー
ションに戻される（図２４のステップ１７９９）べき成
功メッセージも生成する（ステップ１７２９）。

【０１４５】アプリケーションが登録されることを希望
していることを制御サーバー・メッセージが示さなけれ
ば（図２３のステップ１７１０）、制御サーバー・ソフ
トウェア構成要素は、現在登録されている方法サーバー
が制御サーバー・ソフトウェア構成要素１３３４及びサ
ーバー登録設備１４２５で登録解除されることを要求し
ていることを該制御サーバー・メッセージが示すか否か
判定する（ステップ１７２０）。若しそうならば、制御
サーバー・ソフトウェア構成要素１３３４は、該情報を
制御サーバー登録１４２５から除去することにより該方
法サーバーを登録解除する。これは、該方法サーバーに
より特定されるアプリケーションが最早使用可能でない
ことを示す。制御サーバー・ソフトウェア構成要素１３
３４は、汎回路網メモリー７０４に記憶されている情報
を除去するためにサーバー登録設備１４２０にも通知す
る（ステップ１７２５）。制御サーバー・ソフトウェア
構成要素１３３４は、そのとき、今登録解除されたアプ
リケーションに戻される（図２４のステップ１７９９）
べき成功メッセージを生成する（ステップ１７２９）。

【０１４６】アプリケーションがそれ自体を登録又は登
録解除することを要求したことを制御サーバー・メッセ
ージが示さなければ、制御サーバー・ソフトウェア構成
要素は、処理済み方法呼出し要求を実行する（ステップ
１７３０）ために呼び出されるべきことを期待すること
を非同期方法サーバーに信号することを呼出しソフトウ
ェア構成要素１２３６が希望することを制御サーバー・
メッセージが示すか否か判定する。若しそうならば、制
御サーバー・ソフトウェア構成要素１３３４は、非同期
方法サーバーに信号するプロセスを実行し（ステップ１
７３５）、処理を終える（図２４のステップ１７９
９）。

【０１４７】上記した様に、この発明の好適な実施例
は、この発明の特徴を利用するべく書かれたアプリケー
ションでも、或いは、好適な実施例で私達のために修正
された前もって書かれたアプリケーションでも動作する
ことが出来る。好適な実施例で動作する様に非同期アプ
リケーションを書き又は修正するとき、ユーザーは、部
分的にはこれらの非同期信号を認識すると共に、後述す
る様に、これらの信号と次の処理済み方法呼出し要求と
をキューに登録するプログラムコードを含める。これら
のオペレーションについて、指名ソフトウェア構成要素
１３３２により行われるプロセスを参照して以下に説明
する。

【０１４８】若し他の機能が要求されていなければ、制
御サーバー・ソフトウェア構成要素１３３４は、方法を
処理する方法サーバーとなるために新しいアプリケーシ
ョン（これは制御サーバー・ソフトウェア構成要素１３
３４と同じプラットフォーム上にある）が始動させられ
る（図２４の１７４０）べきであることを呼出しソフト
ウェア構成要素１２３６が要求していることを制御サー
バー・メッセージが示しているか否か判定する。若しそ
うならば、制御サーバー・ソフトウェア構成要素１３３
４は、制御サーバー登録１４２５をチェックして（ステ
ップ１７４５）、新しいアプリケーションの実行可能な
方法（分解された方法に対応する）が選択されたプラッ
トフォーム上にあるか否か判定する（ステップ１７５
０）。

【０１４９】制御サーバー登録１４２５は、局所的有効
範囲を持っているので、サーバー・プラットフォーム１
３００だけが、常駐している実行可能な方法を承知して
いる。実行可能な方法の登録１４２５における登録は、
例えば、方法を実施するシェル・スクリプト、及びこれ
らの実行可能な方法の状況など、実際の実行可能なコー
ドの実行可能なファイルにおける登録を含む。実行可能
なコードを大域的に管理する必要はないので、これらの
項目は好都合なことには局所的な登録有効範囲を有する
に過ぎない。

【０１５０】対応する実行可能な方法が制御サーバー登
録１４２５において特定されたならば、選択されたプラ
ットフォームはサーバー・プラットフォームである可能
性がある。制御サーバー・ソフトウェア構成要素１３３
４は、対応する実行可能な方法を始動させるプロセスを
実行すると共に、その結果としての方法サーバーをサー
バー登録設備１４２０と制御サーバー登録１４２５とに
登録して、新しく始動した方法サーバーが実行中であり
且つ使用可能であることを示す（ステップ１７５２）。
この始動プロセス時に、制御サーバー・ソフトウェア構
成要素１３３４は、その始動した方法サーバーにより使
われることの出来るコンテキストオブジェクトデータベ
ースも作る。次に、制御サーバー・ソフトウェア構成要
素１３３４は、分解された方法に対応するアプリケーシ
ョンが始動させられていて且つ今や方法サーバーである
ことを示すメッセージを生成する（ステップ１７５
４）。そのとき、このメッセージは、該方法サーバーが
始動させられることを要求した呼出しソフトウェア構成
要素１２３６に送られ（ステップ１７９０）、制御サー
バー・ソフトウェア構成要素１３３４はその処理を終え
ている（ステップ１７９９）。

【０１５１】分解された方法に対応する実行可能な方法
が制御サーバー登録１４２５において特定されなけれ
ば、制御サーバー・ソフトウェア構成要素１３３４は、
該実行可能な方法が始動させられなかったことを示す適
切なメッセージを生成する（ステップ１７５６）。この
メッセージは、該方法サーバーが始動させられるべきこ
とを要求した呼出しソフトウェア構成要素１２３６に送
られ（ステップ１７９０）、制御サーバー・ソフトウェ
ア構成要素１３３４はその処理を終えている（ステップ
１７９９）。

【０１５２】若し他の機能が要求されていなければ、制
御サーバー・ソフトウェア構成要素１３３４は、制御サ
ーバー・メッセージが、分解された方法により特定され
る方法を実行する実行中の方法サーバーの使用可能性に
関する情報についての呼出しソフトウェア構成要素１２
３６からの要求であるか否か判定する（ステップ１７６
０）。若しそうでなければ、制御サーバー・ソフトウェ
ア構成要素１３３４は、エラー・メッセージを生成し
（ステップ１７８０）、そのメッセージを呼出しソフト
ウェア構成要素１２３６に送り（ステップ１７９０）、
その処理を終える（ステップ１７９９）。

【０１５３】そうでない場合、制御サーバー・ソフトウ
ェア構成要素１３３４は、制御サーバー登録１４２５か
らの実行中の方法サーバーについての要求された情報を
再試行する（ステップ１７６５）。分解された方法によ
り特定される方法サーバーが使用可能であることを制御
サーバー登録１４２５からの情報が示しているならば
（ステップ１７７０）、制御サーバー・ソフトウェア構
成要素１３３４は、該方法サーバーの使用可能性を示す
メッセージを生成する（ステップ１７７５）。このメッ
セージは呼出しソフトウェア構成要素１２３６に送られ
（ステップ１７９０）、制御サーバー・ソフトウェア構
成要素の処理は完了する（ステップ１７９９）。

【０１５４】しかし、方法サーバーが使用可能でないこ
とを制御サーバー登録１４２５が示したならば、（ステ
ップ１７７０）、制御サーバー・ソフトウェア構成要素
１３３４は、方法サーバーが使用可能でないことを示す
メッセージを生成する（ステップ１７７７）。制御サー
バー・ソフトウェア構成要素１３３４は、そのとき、生
成されたメッセージを呼出しソフトウェア構成要素に送
り、（ステップ１７９０）、制御サーバー・ソフトウェ
ア構成要素１３３４の処理は完了する（ステップ１７９
９）。 （４） 指名オペレーション 方法サーバーを指名するプロセスは、方法サーバーによ
り処理されるべき方法を指名すること、及び輸送レベル
通信から成る。指名ソフトウェア構成要素１３３２は、
種々の方法呼出しも処理する。

【０１５５】非同期方法呼出しは、クライアント・アプ
リケーションが処理を完了するために特定された方法サ
ーバーを持つことを必要としない。例えば、呼出し要求
は、実行されるべくキュー上に置かれることが出来、Ｒ
ＰＣ輸送レベル・コールは、呼出しソフトウェア構成要
素１３３４に戻って、クライアント・アプリケーション
が「妨げられ」又は継続を阻止されることなくそれ自身
の処理を続けることを許すことが出来る。呼出しソフト
ウェア構成要素から受け取られた処理済み方法呼出し要
求のキューは、そのとき、図２５の指名手順１８００内
などの、指名ソフトウェア構成要素１３３２により試験
され、所定の順序に従って行われる。

【０１５６】非同期方法呼出しは、クライアント・アプ
リケーションが方法サーバーから応答を受け取ることを
予期しないならば、要求されることが出来る。唯一の応
答は、方法呼出しがサーバー・プラットフォーム上のＡ
ＣＡＳソフトウェア構成要素によって首尾よく受け取ら
れたか否かの表示である。該応答は、その実行が成功し
たか否か示さず、同期方法呼出しについては出来る様
に、実際の方法呼出しの出力を包含しない。

【０１５７】同期方法呼出しは、全ての方法呼出しにつ
いてデフォールト・モードである。同期方法呼出しで
は、該方法を呼び出したクライアント・アプリケーショ
ンは、それ自身の処理を続ける前に応答を待つ。図２５
及び２６は、図１５及び１７の指名ソフトウェア構成要
素１３３２により行われ又は呼び出される手順の流れ図
である。指名手順１８００は、指名ソフトウェア構成要
素１３８２により行われるステップ１３８５、１３９
０、及び１３９５（図１６）を表す。

【０１５８】指名手順１８００に入る前に、指名ソフト
ウェア構成要素１３３２は、回路網内の呼出しソフトウ
ェア構成要素から処理済み方法呼出し要求を待つ「待
ち」状態である。指名手順１８００を開始した後（ステ
ップ１８０２）、指名ソフトウェア構成要素１３３２
は、回路網輸送サービスを介して、輸送データ構造を受
け取る。この輸送データ構造は、回路網内の呼出しソフ
トウェア構成要素により送られた、まとめられた（パッ
クされた）処理済み方法呼出し要求を表す（ステップ１
８０５）。この輸送データ構造を受け取った後、呼出し
ソフトウェア構成要素１３３２は、該輸送データ構造を
アンパックして、サーバー・プラットフォームが認識出
来るデータ構造に変換する（ステップ１８１０）。呼出
しソフトウェア構成要素１３３２は、そのとき、実行中
の方法サーバーに随伴しているコンテキストデータベー
スを更新する（ステップ１８１５）。コンテキストオブ
ジェクトデータベースは、該方法サーバーを始動させる
ときに制御サーバー・ソフトウェア構成要素１３３４に
より作られることにより、又はサーバー・プラットフォ
ーム上にロギングして該方法サーバーを始動させるユー
ザーによって、実行中の方法サーバーに随伴させられる
ことが出来る。

【０１５９】呼出しソフトウェア構成要素１３３２は、
次に、受け取った処理済み方法呼出し要求が非同期方法
サーバーによって処理されるべき非同期呼出し要求であ
るか否か質問する（ステップ１８２０）。若しそうでな
ければ、呼出しソフトウェア構成要素１３３２は、該呼
出し要求が妥当な方法の識別（ｉｄｅｎｔｉｆｉｃａｔ
ｉｏｎ）を含んでいるか否か質問するが、それは、該方
法サーバーによって処理されることの出来る方法である
（ステップ１８２５）。若しそうでなければ、エラー・
メッセージが生成され（ステップ１８４０）、それは応
答としてパックされて（図２６のステップ１８９０）、
指名処理を完了する前に（ステップ１８９９）呼出しソ
フトウェア構成要素に送られる（ステップ１８９５）。

【０１６０】若し呼出し要求が妥当な方法の識別（ｉｄ
ｅｎｔｉｆｉｃａｔｉｏｎ）を含んでいたならば（図２
５のステップ１８２５）、指名ソフトウェア構成要素１
３３２は、受け取られた呼出し要求により特定される妥
当な方法を、該方法サーバーにより実行されるべく指名
する（ステップ１８３０）。該方法サーバーによる妥当
な方法の実行時にエラーが発生したならば（ステップ１
８３５）、指名ソフトウェア構成要素１３３２は適切な
エラー・メッセージを生成する（ステップ１８４０）。
指名ソフトウェア構成要素１３３２は、そのとき、該エ
ラー・メッセージを応答としてパックし（図２６のステ
ップ１８９０）、指名処理を完了する前に（ステップ１
８９９）そのパックしたエラー・メッセージを呼出しソ
フトウェア構成要素に送る（ステップ１８９５）。

【０１６１】若し実行エラーが発生しなければ、（図２
５のステップ１８３５）、指名ソフトウェア構成要素１
３３２は応答をパックするが（図２６のステップ１８９
０）、それは、この場合には、分解された方法により特
定される方法を処理した方法サーバーからの出力を含む
処理済み方法呼出し要求である（図１８のステップ１５
６０）。その応答は、パックされた後、元の処理済み方
法呼出し要求を初めに送った呼出しソフトウェア構成要
素に送られ（ステップ１８９５）、指名処理は完了する
（ステップ１８９９）。

【０１６２】指名ソフトウェア構成要素に受け取られた
処理済み方法呼出し要求が非同期呼出し要求であるなら
ば（図２５のステップ１８２０）、その非同期呼出し要
求は、好都合なことには、後に方法サーバーとして処理
されるべく指名ソフトウェア構成要素１３３２によって
指名されるべきキュー上に置かれる（ステップ１８５
０）。該非同期呼出し要求の成功を示すメッセージが生
成され（ステップ１８５５）、受け取られた処理済み方
法呼出し要求への応答としてパックされ（ステップ１８
６０）、次に、その処理済み方法呼出し要求を最初に送
った呼出しソフトウェア構成要素に送られる（ステップ
１８６５）。

【０１６３】好適な実施例では、非同期方法サーバー
は、非同期方法呼出し要求を、それらが最初にキュー上
に置かれた順に実行する。非同期要求を実行するとき、
指名ソフトウェア構成要素１３３２は、該非同期方法サ
ーバーにより処理されるべき方法呼出し要求がキュー上
にあるか否か質問する（図２６のステップ１８７０）。
若し方法呼出し要求が該キュー上に無ければ（ステップ
１８７０）、指名処理は完了する（ステップ１８９
９）。

【０１６４】若し非同期方法呼出し要求が該キュー上に
あったならば（ステップ１８７０）、指名ソフトウェア
構成要素１３３２は、次の非同期方法呼出し要求を該キ
ューから取り去る（ステップ１８７５）。該キューから
取り去られた要求が、例えば該方法サーバーにより処理
されることの出来ない要求などの無効な要求であるなら
ば（ステップ１８８０）、待ち合わせさせられた方法呼
出し要求が他にあるか否か発見するために該処理は戻る
（ステップ１８７０）。

【０１６５】該キューから取り去られた要求が妥当であ
るならば（ステップ１８８０）、指名ソフトウェア構成
要素１３３２は、該キューから取り去られた非同期方法
呼出し要求を該非同期方法サーバーにより処理されるべ
く指名する（ステップ１８８５）。 そのとき、該方法
サーバーの処理時にエラーが発生したか否かという質問
が行われる（ステップ１８８７）。エラーが若しあれ
ば、それは記録され（ステップ１８８８）、エラーが若
し発生しなかったならば、指名ソフトウェア構成要素１
３３２は該キューをチェックする（ステップ１８７
０）。この様にして、該方法呼出し要求を発したクライ
アント・アプリケーションを妨げずに該キュー上の全て
の非同期呼出し要求が処理される。 Ｉ． 要 約 この様にして、本発明は、１プラットフォーム上のアプ
リケーションが、他のプラットフォームについての詳細
や、他のアプリケーションについての詳細についても知
る必要無しに、同じ又は異なるプラットフォーム上のア
プリケーションを呼び出す効率的で単純な方法を提供す
る。その様な呼出しは、不均一回路網内の似ていないプ
ラットフォーム同士の間でも発生することが出来る。

【０１６６】この発明のコンテキスト指向技術による
と、データ（又はインスタンス）及びアプリケーション
は管理されないので、それらのデータ及びアプリケーシ
ョンを、アプリケーションの開発者が選んだ方法で管理
することが出来る。その代わりに、オブジェクトと、ア
プリケーションへの参照とだけを管理することにより、
システム資源についての要求は減少し、システムの柔軟
性が向上する。

【０１６７】この発明がもたらす他の利点は、現在実行
中ではないアプリケーションを自動的に呼び出す能力で
ある。これにより、この発明に従って構成されたシステ
ムの力と柔軟性とが更に向上する。一般的発明思想の範
囲から逸脱することなく本発明を修正、変形出来ること
を当業者は理解するであろう。従って、この発明は、広
い意味では、図示し説明した特別の詳細や代表的方法に
限定されるものではない。

【図面の簡単な説明】

【図１】図１は、本発明の好適な実施例に使用すること
の出来る回路網の図である。

【図２】図２は、アプリケーションとの関連でこの発明
のオブジェクト指向的モデルの主要構成要素を示す図で
ある。

【図３】図３は、本発明のこの実施例のオブジェクト指
向的モデルの構成要素間の関係の図である。

【図４】図４は、この発明のオブジェクト指向的モデル
の構成要素の例の間の関係の図である。

【図５】図５は、この好適な実施例による、図４に示さ
れている関係と一貫するクラスデータベースについての
構造の図である。

【図６】図６は、この好適な実施例の種々の構成要素
と、それらの構成要素間の情報の好適な流れとの図であ
る。

【図７】図７は、この好適な実施例における種々のメモ
リーシステムの関係を示す図である。

【図８】図８は、局所クラスデータベースの好適な構造
の図である。

【図９】図９は、図８に示されている局所クラスデータ
ベース内のブロックの好適な実施例の図である。

【図１０】図１０は、大域データベース、局所データベ
ース、及びノードキャッシュについてのローダー／アン
ローダーの機能の図である。

【図１１】図１１は、コンテキストオブジェクトデータ
ベースの好適な実施例を示す図である。

【図１２】図１２は、図１１に示されているコンテキス
トオブジェクトデータベースにおける方法オーバーライ
ド・テーブルの好適な実施例を示す図である。

【図１３】図１３は、図１１に示されているコンテキス
トオブジェクトデータベースにおけるサーバー・ノード
・テーブルのための好適な記憶構造を示す図である。

【図１４】図１４は、図１１に示されているコンテキス
トオブジェクトデータベースにおけるクラス・データベ
ース・オーバーライド・テーブルの好適な実施例を示す
図である。

【図１５】図１５は、該回路網のプラットフォームにお
ける個々のソフトウェア構成要素の図である。

【図１６】図１６は、アプリケーションの遠隔呼出しの
ために本発明の好適な実施例により行われる一般的オペ
レーションの流れ図である。

【図１７】図１７は、該回路網の構成要素と情報の流れ
との詳細な図である。

【図１８】図１８は、図１７の呼出しソフトウェア構成
要素が行う手順の流れ図である。

【図１９】図１９は、図１７の呼出しソフトウェア構成
要素が行う手順の流れ図である。

【図２０】図２０は、図１７の呼出しソフトウェア構成
要素が行う手順の流れ図である。

【図２１】図２１は、図１７の呼出しソフトウェア構成
要素が行う手順の流れ図である。

【図２２】図２２は、方法を分解するために図１７の呼
出しソフトウェア構成要素が行うステップの図である。

【図２３】図２３は、図１７の制御サーバーソフトウェ
ア構成要素が行うステップの流れ図である。

【図２４】図２４は、図１７の制御サーバーソフトウェ
ア構成要素が行うステップの流れ図である。

【図２５】図２５は、図１７のタスク指名ソフトウェア
構成要素が行うステップの流れ図である。

【図２６】図２６は、図１７のタスク指名ソフトウェア
構成要素が行うステップの流れ図である。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 アンドリュー ピー ウィルソン イギリス リーディング アールジー７ ３ディーピー バーグフィールド コモン バンセス レーン コモンズ ブリンク （番地なし) (72)発明者 ニール エフ ジェイコブソン アメリカ合衆国 ニューハンプシャー州 03062 ナシュア クランウェル コート ６ (72)発明者 マイケル ジェイ レンズロー アメリカ合衆国 マサチューセッツ州 01721アッシュランド バイロン ロード ７

Claims (16)

【特許請求の範囲】
1. 【請求項１】 複数のプラットフォームを含むデータ処
   理回路網において、クライアント・アプリケーションに
   よりサーバー・アプリケーションを呼び出すプロセスで
   あって、該クライアント・アプリケーションは、 該クライアント・アプリケーションにより操作され又は
   アクセスされることの出来るアイテムであって、同じク
   ラス内のインスタンスが共通の特徴を共有することとな
   る様にクラスに編成された複数のインスタンスと、 該クライアント・アプリケーションについて確認された
   インスタンスに対して行われることの出来るオペレーシ
   ョンの種類を指定する複数のメッセージとを包含し、 該プロセスは、該プラットフォームが行う下記のステッ
   プ、即ち、 １のインスタンスについての識別子と、該第１インスタ
   ンスに対して行われるべき所望のオペレーションについ
   ての識別子とを含む第１メッセージを該クライアント・
   アプリケーション内に生成するステップと、 該第１メッセージと、該第１インスタンスが編入されて
   いるクラスとから第１の方法についての識別子を決定す
   るステップであって、該第１方法についての該識別子
   は、該サーバー・アプリケーションが該第１インスタン
   スに対して所望のオペレーションを行うのを許す手順へ
   の参照を包含しているステップと、 該第１インスタンスについての該識別子と該手順への該
   参照とを、該サーバー・アプリケーションを呼び出すた
   めの該サーバー・アプリケーションを内蔵するプラット
   フォームの中のサーバー・プラットフォームへ送るステ
   ップと、から成ることを特徴とするプロセス。
2. 【請求項２】 送るステップは、 該プラットフォームの中のサーバー・プラットフォーム
   をして該サーバー・アプリケーションを実行せしめるサ
   ブステップを含むことを特徴とする請求項１に記載のプ
   ロセス。
3. 【請求項３】 該サーバー・アプリケーションを始動さ
   せるステップを更に含むことを特徴とする請求項２に記
   載のプロセス。
4. 【請求項４】 該データ処理回路網は、該クライアント
   ・アプリケーションのユーザーに対応するユーザーコン
   テキスト情報を包含しており、 該第１方法についての該識別子を決定するステップは、 該ユーザーコンテキスト情報への参照によって該第１方
   法についての該識別子を決定するサブステップを含むこ
   とを特徴とする請求項１に記載のプロセス。
5. 【請求項５】 該データ処理回路網は、該回路網のユー
   ザーのグループに対応するグループコンテキスト情報を
   包含しており、 該第方法についての該識別子を決定するステップは、 該グループコンテキスト情報への参照によって該第１方
   法についての該識別子を決定するサブステップを含むこ
   とを特徴とする請求項１に記載のプロセス。
6. 【請求項６】 該データ処理回路網は、該回路網内のプ
   ラットフォームの各々にとってアクセス可能で、該クラ
   スについての情報を含む大域データベースを包含してお
   り、 該第１方法についての該識別子を決定するステップは、 該第１インスタンスのクラスを決定し、 該第１インスタンスのクラス及び該第１メッセージで該
   大域データペースにアクセスして該第１方法について該
   識別子の位置を確認し、 該第１方法の該識別子を検索するサブステップを含むこ
   とを特徴とする請求項１に記載のプロセス。
7. 【請求項７】 該データ処理回路網は、該クライアント
   ・アプリケーションのユーザーに対応するコンテキスト
   情報を包含しており、 随伴するクラス内のインスタンスの共通の特徴を定義す
   る属性の組が該方法の各々に随伴しており、 該第１方法についての該識別子を決定するステップは、 該コンテキスト情報を各方法の属性の組と比較して該方
   法の中の一つを選択するサブステップを含むことを特徴
   とする請求項６に記載のプロセス。
8. 【請求項８】 該サーバー・アプリケーションをして実
   行せしめるステップは、 該サーバー・アプリケーションにより使用されるべきコ
   ンテキストオブジェクトデータベースを生成するサブス
   テップを含み、該コンテキストオブジェクトデータベー
   スはコンテキスト情報を含むことを特徴とする請求項２
   に記載のプロセス。
9. 【請求項９】 送るステップは、 該サーバー・アプリケーションにより使用されるべきコ
   ンテキスト情報を該プラットフォームの中のサーバー・
   プラットフォームに送るサブステップを含むことを特徴
   とする請求項１に記載のプロセス。
10. 【請求項１０】 随伴するクラス内のインスタンスを定
    義する属性の組が該クラスの各々に随伴しており、 対応する上位クラスの下位クラスとなっているクラス
    が、対応する上位クラスから属性を受け継ぐ様に、該ク
    ラスは上位クラスと下位クラスとに階層的に整理されて
    おり、 該方法は、更に、 該１インスタンスの属性を、該第１インスタンスについ
    てのクラスの属性と、該第１インスタンスについてのク
    ラスの全ての上位クラスの属性とから決定するステップ
    を含むことを特徴とする請求項１に記載のプロセス。
11. 【請求項１１】 該クライアント・アプリケーション
    は、該プラットフォームの中のクライアント・プラット
    フォームにおいて実行し、 該第１方法についての該識別子を決定するステップは、 該プラットフォームの中の該クライアント・プラットフ
    ォームにおいて、該第１インスタンスが編入されている
    クラスを決定するサブステップを含むことを特徴とする
    請求項１に記載のプロセス。
12. 【請求項１２】 クライアント・アプリケーションによ
    りサーバー・アプリケーションをオブジェクト指向的に
    遠くから呼び出せる様にするデータ処理回路網であっ
    て、 データベースを内蔵する回路網内のメモリーを備えてお
    り、該データベースは、 一義的に識別可能な複数のクラスについての情報を含む
    複数のクラス項目を含んでおり、該クラスは、インスタ
    ンスの種類を特定し、該インスタンスは、共有される特
    徴に従って該アプリケーションにより操作又はアクセス
    されることのあるアイテムであり、 該クラス項目の各々はメッセージ項目の対応するグルー
    プの識別を包含しており、該メッセージ項目は、対応す
    るクラス内のインスタンスに対して行われることの出来
    るオペレーションの種類を指定する情報を包含してお
    り、 該クラス項目の各々は、該アプリケーションを呼び出す
    呼出しコマンドへの参照を内蔵する方法項目の対応する
    グループの識別を内蔵しており、 該データ処理回路網は、更に、該クライアント・アプリ
    ケーションを実行するための複数の第１プラットフォー
    ムと該サーバー・アプリケーションを実行するための複
    数の第２プラットフォームとを備えており、該第１プラ
    ットフォームは、 第１インスタンスについての識別子と、該第１インスタ
    ンスに対して行われるべき所望のオペレーションについ
    ての識別子とを含む第１メッセージを生成する手段と、 該メモリーに接続されて該データベースを制御するデー
    タベース制御手段とを包含しており、該データベース制
    御手段は、 該第１メッセージの結果として呼び出されるべきサーバ
    ー・アプリケーションを選択する手段と、 該第１インスタンスに対して所望のオペレーションを行
    う選択されたサーバー・アプリケーションへの参照を含
    む第１方法についての識別子を該第１メッセージと該第
    １インスタンスが編入されているクラスとから決定する
    手段と、 該第１インスタンスについての該識別子を介して該選択
    されたサーバー・アプリケーションへの該参照を該第２
    プラットフォームの中の選択された一つに送る手段とを
    含んでおり、該第２プラットフォームは、 該データベース制御手段内の該送り手段から該サーバー
    ・アプリケーションについての該参照を受け取る手段を
    含むことを特徴とするデータ処理回路網。
13. 【請求項１３】 該第１プラットフォームの中の選択さ
    れたプラットフォームは、該第２プラットフォームの中
    のプラットフォームであることが出来ることを特徴とす
    る請求項１２に記載のデータ処理回路網。
14. 【請求項１４】 該メモリーの一部分は該第１プラット
    フォーム内にあることを特徴とする請求項１２に記載の
    データ処理回路網。
15. 【請求項１５】 該メモリーの一部分は該第２プラット
    フォーム内にあることを特徴とする請求項１２に記載の
    データ処理回路網。
16. 【請求項１６】 該第１プラットフォームは、 該クライアント・アプリケーションのユーザーに対応す
    るコンテキスト情報を保持する記憶手段と、 該コンテキスト情報への参照によって該第１方法につい
    ての該識別子を決定する手段とを含むことを特徴とする
    請求項１２に記載のデータ処理回路網。