JP3817823B2 - データ通信方法 - Google Patents
データ通信方法 Download PDFInfo
- Publication number
- JP3817823B2 JP3817823B2 JP09244697A JP9244697A JP3817823B2 JP 3817823 B2 JP3817823 B2 JP 3817823B2 JP 09244697 A JP09244697 A JP 09244697A JP 9244697 A JP9244697 A JP 9244697A JP 3817823 B2 JP3817823 B2 JP 3817823B2
- Authority
- JP
- Japan
- Prior art keywords
- tag
- message
- metaspace
- meta
- continuation
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F7/00—Methods or arrangements for processing data by operating upon the order or content of the data handled
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/465—Distributed object oriented systems
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
- Computer And Data Communications (AREA)
- Information Transfer Between Computers (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、オブジェクト指向オペレーティング・システム（ＯＳ）又はその他のオブジェクト指向プログラミングシステムにおいてオブジェクト間のデータ通信方法に関する。
【０００２】
【従来の技術】
最近のソフトウェア技術には、いわゆるオブジェクト指向技術がある。オブジェクト指向技術を適用したソフトウェアでは、ソフトウエア内部の各機能はオブジェクトとしてモジュール化されている。ソフトウエア全体の機能を実現するために、各オブジェクトはオブジェクト間通信を行なう。オブジェクト間通信では送信内容をメッセージに詰めて配送する。
【０００３】
オブジェクト間通信には同期方法やメッセージの管理方法について、いろいろな方式が考えられる。これらの方式はアプリケーションからの要求に応じて決定される必要がある。そのため、いろいろな要求に応えるためには、アプリケーションに応じた性質（意味構造、セマンティクス）やそれに応じたインターフェース（Application Programming Interface：ＡＰＩs）を持ったオブジェクト間通信機構が必要になる。なお、以下で扱うＡＰＩとは、ＯＳの機能を用いるインターフェース或いはプログラミングシステムの機能としてのインターフェースを示す。
【０００４】
ある性質やインターフェースを持ったオブジェクト間通信機構が存在することを「環境」があると呼ぶことにする。一つの機器やホストにはただ一つの環境が実現されることもあるし、異なる複数の環境が同時に実現されることもある。特に異なる環境に存在するオブジェクト間の通信は相互の環境の協調動作を行わしめるという点から重要である。
【０００５】
ここで、異なる環境に存在するオブジェクトにメッセージを送る機能を提供する考え方として、本質的に以下の二つがある。すなわち、
１．異なる環境に存在するオブジェクトにメッセージを送るために、同じ環境に存在するオブジェクトにメッセージを送るときとは異なるインターフェースや手続きを提供するという考え方と、
２．異なる環境に存在するオブジェクトにメッセージを送るために、同じ環境に存在するオブジェクトにメッセージを送るときと同じインターフェースや手続きを使うことができるという考え方とがある。
【０００６】
前者の方法は、比較的容易に実現できる。なぜなら、全ての環境をプログラマが意識しなくてもよい考え方なので、インターフェースや手続きの違いが環境の違いによって各々異なる機能を提供することで吸収させればよいからである。
【０００７】
【発明が解決しようとする課題】
しかし、プログラマのためには異なる環境に対してプログラムコードが左右されない、いわゆる透明性を提供した方がよい。
【０００８】
そこで本発明は、上述した課題に鑑みてなされたものであり、プログラマのために異なる環境に対して透明性を提供することを可能にするデータ通信方法を提供することを目的とするものである。
【０００９】
【課題を解決するための手段】
本発明は、ソフトウェア機能を実現するため複数のオブジェクト間で通信を行うデータ通信方法において、異なるオブジェクト間通信機構をそれぞれ固有に持つ環境間でそれぞれ異なる実体を用いて通信を行う際、上記異なるオブジェクト間通信機構のデータ構造を共通のデータ構造で関連付けるタグを生成し、上記タグを生成する際、上記タグを識別するためのタグＩＤと上記環境を特定するタグの型を示す属性とを、少なくとも生成し、上記タグを通信メッセージと共に通信し、上記タグの型を示す属性に基づいて上記実体を特定することを特徴としている。
本発明は、同一又は相違ＯＳを問わずオブジェクト間通信が必要なソフトウェアであって、ソフトウェア間が透明性をもって通信することを実現するタグと、それを適用したソフトウェアシステムを実現することにより、上述した課題を解決する。
【００１０】
すなわち、本発明は、上記「タグ」を導入することによって、異なる環境間で透明性のある通信機構を実現したソフトウェア、またはその実現方式を提供する。本発明によって、ある通信機構が固有に持つオブジェクト間通信の同期や並行性の制御に必要な実体が環境によって異なっている場合でも、異なる環境に存在しているオブジェクトが互いにその違いを意識することなく、通信可能になる。
【００１１】
【発明の実施の形態】
本発明の一実施の形態について、図面を参照しながら説明する。
【００１２】
本発明実施の形態のデータ通信方法は、異なる複数の環境を実現できるソフトウェア・システムに適用することを基本的な特徴の一つとしている。本発明の実施の形態では「環境」のことを特にメタスペースと呼んでいる。また、本発明の実施の形態におけるメタスペースでは、オブジェクト間通信機構以外の機能についても異なる「環境」を提供できる。なお、上記異なる複数の環境を実現できるソフトウェア・システムとしては、例えば本件出願人が先に提案している特願平８−６７８８１号の明細書及び図面に記載したデータ処理方法及び装置を挙げることができる。このデータ処理方法は、複数のオブジェクトで構成されるアプリケーションプログラムと、複数のオブジェクトで構成される前記アプリケーションプログラムの動作を規定する実行環境と、前記アプリケーションプログラムと前記実行環境の間のインターフェースを規定するアプリケーションプログラムインターフェースとを備えるサーバと、前記サーバより前記アプリケーションプログラムをダウンロードするクライアントとを備えるデータ処理システムにおけるデータ処理方法であって、前記サーバは前記クライアントに前記アプリケーションプログラムをダウンロードするとき、前記クライアントがダウンロードする前記アプリケーションプログラムの実行環境を有するか否かを検査し、その検査結果に対応して前記アプリケーションプログラムを前記クライアントにダウンロードすることを特徴とするものである。
【００１３】
図１には、本発明実施の形態のデータ通信方法が適用される装置構成の一例を示す。
【００１４】
この図１の装置は、カセット内にビデオテープを収納したビデオカセットを用いて信号の記録再生を行うビデオカセットレコーダ（以下、ＶＣＲ装置と呼ぶ）である。勿論ＶＣＲ装置以外のオーディオ・ビジュアル機器（いわゆるＡＶ機器）や事務機器等のその他の装置、一般のコンピュータ装置にも本発明は適用可能である。
【００１５】
図１のＶＣＲ装置において、ＶＣＲ機能部１４はビデオカセットを用いてデータの記録再生を行うビデオカセットレコーダとしての主要機能を備え、当該ＶＣＲ機能部１４にてビデオカセットに記録／再生されるデータは、バス／ＩＯブリッジ１５を介して装置の他の構成に送られ、また端子２３を介して外部との入出力が行われる。ＣＰＵ（中央処置ユニット）１２は、バス／メモリブリッジ１３を介して各部を制御する制御部である。ＲＡＭ（ランダム・アクセス・メモリ）１０は、比較的小容量で構成され、ワークエリアを有する。ＲＯＭ（リード・オンリ・メモリ）１１は、基本的な機能に関するプログラムを記憶していると共に、本発明で言うＯＳに係るプログラムも記憶されている。すなわち、上記ＣＰＵ１２は、上記ＲＯＭ１１が記憶するプログラムに基づいて各部を制御し、上記ＲＡＭ１０をワークエリアとして使用する。
【００１６】
ＩＣカードドライブ１６は、カード状の筐体内にＩＣ（集積回路）を備えた記憶媒体であるＩＣカードが挿入されるスロットと、当該ＩＣカードに対するデータの書き込み／読み出しを行うＩＣカード駆動部とを有する。フロッピィディスクドライブ１７は、フロッピィディスが挿入されるスロットと、当該フロッピィディスクを回転駆動する回転駆動部と、フロッピィディスクに対してデータの記録／再生を行うヘッド部とを有し、各種データの記録やアプリケーションソフトのインストールなどが行われる。ハードディスクドライブ１８は、当該ハードディスクを回転駆動する回転駆動部と、ハードディスクに対してデータの記録／再生を行うヘッド部とを有する。バススロット１９は、拡張ボードを追加する際の拡張端子である。シリアルポート２０は、モデム（ＭＯＤＥＭ）を介して外部との間でデータ通信を行うための入出力部である。
【００１７】
このＶＣＲ装置は、一般のＶＣＲの機能に追加して、付加的なアプリケーションソフトを与えることができるようになっている。例えばユーザがバージョンアップを図りたい（新しい機能をこのＶＣＲ装置に付加したい）場合等は、ＩＣカードやフロッピディスク或いはインターネット等のネットワーク回線を介して付加的な機能ソフトをインストールできる。したがってユーザは、ＶＣＲ装置本体を買い換えることなく装置の機能アップが行える。アプリケーションプログラムはプログラマによって作成されてユーザに供給されるものである。ここでこれらソフトウェアをいわゆるオブジェクト指向型プログラミングソフトで構築する場合を考える。
【００１８】
上記の例の場合、異なる複数の環境（メタスペース）間で通信が必要となる場合がある。
【００１９】
例えば図２に示すように外部からＭＯＤＥＭ（モデム）、シリアルポートを介して通信されてきたアプリケーションソフトと予めＶＣＲ装置内に存在するアプリケーションソフトは異なる環境（メタスペース）下にあり、それぞれは通信用ＯＳ（後述するメタスペース（mLocal）、メタスペース（mDrive）等）、ＡＶ用ＯＳとＡＰＩ（後述するセンド（Send）、リプライ（Reply）等）により通信が行われるようになっている。
【００２０】
先ず初めに、上記「異なる通信機構について具体的な二つの例」を本発明のデータ通信方法にて実現した例を使って述べる。この例では後述するフューチャ（Future）と呼ぶ実体を使った通信セマンティクス（性質、意味構造）を実現したメタスペース（mLocal）と、コンティネーション（Continuation）と呼ぶ実体を使った通信セマンティクスを実現したメタスペース（mDrive）の例で示す。
【００２１】
本実施の形態では、上記「異なる通信機構の具体的な例」として、
［メタスペース（mLocal）通信機構］
［メタスペース（mDrive）通信機構］
［メタスペース（mLocal）通信機構とメタスペース（mDrive）通信機構の比較］
［本発明方法における通信機構の実現方式］
［フューチャ（Future）とメタスペース（mLocal)通信機構の実現方式］
［コンティネーション（Continuation）とメタスペース（mDrive）通信機構の実現方式］
の順に説明する。
【００２２】
次に、「タグを使った通信機構の基本的な説明」を述べる。ここでもメタスペース（mLocal）とメタスペース（mDrive）を例に述べる。なお、メタスペース（mLocal）、メタスペース（mDrive）は、１つのＯＳ又はプログラミングシステムとして捉えることができる。本実施の形態では、上記「タグを使った通信機構の基本的な説明」として、
［オブジェクトＡ（メソッドＡ１（A::A1））がオブジェクトＢ（メソッドＢ１（B::B1））にセンド及びウェイトフォー（Send+WaitFor）する場合］
［オブジェクトＢ（メソッドＢ１（B::B1））がオブジェクトＡ（メソッドＡ１（A::A1））にセンド（Send）し、継続メソッドとしてオブジェクトＢ（メソッドＢ２（B::B2））を指定した場合］
の順に説明する。
【００２３】
その後、「タグを使った通信機構の本発明方法での実現事例」についての詳細を述べる。本実施の形態では、上記「タグを使った通信機構の本発明方法での実現事例」として、
［フューチャ（Future）、コンティネーション（Continuation）、タグ（Tag）］
［タグＩＤの管理方式と当該タグＩＤを配送するオブジェクト（Deliverer）］
［異なるメタスペース間通信の実際］
の順に説明する。
【００２４】
最後に「他に考えられる些細な点で他に異なる方式」について述べる。本実施の形態では、上記「その他に考えられる実現方式」として、
［タグＩＤでタグの型を認識する方式］
［タグの管理方式］
の順に説明する。
【００２５】
先ず、上記本発明方法における「異なる通信機構の具体的な例」の場合の説明を行う。
【００２６】
本章では、「異なる通信機構の具体的な例」として、本発明のデータ通信方法におけるオブジェクト間通信の具体的な仕様と実現方式について述べる。本章に続く本発明の具体的な事例では、本章で述べる二つの異なる（通信機構を提供している）環境間でのオブジェクト間通信の実現方式を説明する。
【００２７】
［メタスペース（mLocal）通信機構］
上記メタスペース（mLocal）は上記フューチャ（Future）を基本にした通信機構をサポートした環境（オブジェクト間通信機構）である。このメタスペース（mLocal）はアプリケーションを記述するためのものである。メタスペース（mLocal）通信機構の仕様のうち、インターフェースについては後述する。
【００２８】
ここでは、メタスペース（mLocal）通信機構を使ったオブジェクト間通信の基本的を動作について述べる。この通信機構の実現方式、説明で使用されるフューチャ（Future）が持つ属性については後に述べる。
【００２９】
図３と図４はメタスペース（mLocal）通信機構を使ったオブジェクト間通信の基本的な動作を示している。図３にはメタスペース（mLocal）通信機構において、ウェイトフォー（WaitFor）がリプライ（Reply）よりも先に実行された場合を示し、図４にはメタスペース（mLocal）通信機構においてリプライ（Reply）がウェイトフォー（WaitFor）よりも先に実行された場合を示している。これら図３、図４ともにＡ、Ｂはオブジェクト、A::A1、B::B1はそれぞれオブジェクトＡのメソッドＡ１、オブジェクトＢのメソッドＢ１、縦の実線矢印はメソッドの実行、縦の破線矢印はメソッドの待ち状態、斜めの実線矢印はメッセージの配送を示している。なお、上記ウェイトフォー（WaitFor）は、メタスペース（mLocal）におけるＡＰＩ（Application Programming Interface）の一つであり、本実施の形態ではオブジェクトＡがオブジェクトＢの結果を待つ場合に用いられる。当該ウェイトフォー（WaitFor）には、その引数として後述するフューチャＩＤ（futureID）、上記リプライ（Reply）から送られた返答メッセージ（&msg）及びそのサイズ（sizeof(msg)）を備える。なお、上記リプライ（Reply）は、メタスペース（mLocal）におけるＡＰＩの一つであり、本実施の形態ではオブジェクトＢがオブジェクトＡの返答する場合に用いられる。当該リプライ（Reply）には、その引数としてメソッドＢ１の実行結果として得られる返答メッセージ（msg）及びそのサイズ（sizeof(msg)）を備える。
【００３０】
また図３、図４ともに、オブジェクトＡがオブジェクトＢにメッセージを送信し、その返答を受け取る例である。はじめにオブジェクトＡはオブジェクトＢにセンド（ Send）を使ってメッセージを送信する。メソッドＢ１（B::B1）はこれによって起動するメソッドであり、図中msgは配送されるメッセージ（のポインタ）である。これによって、メソッドＢ１（B::B1）が起動される。メソッドＡ１（A::A1）、メソッドＢ１（B::B1）は並行に動作する。このとき、メソッドＡ１（A::A1）のウェイトフォー（Waitfor）とメソッドＢ１（B::B1）のリプライ（Reply）のどちらが先に実行されるかという保証はない。なお、センド（Send）とは、メタスペース（mLocal）におけるＡＰＩの一つであり、本実施の形態ではメイルの送信を行う場合に用いられる。当該センド（Send）には、その引数として宛先（Ｂ）と選択メソッド（Ｂ１）、メッセージ（msg）及びそのサイズ（sizeof(msg)）とフューチャＩＤ（&futureID）とを備える。
【００３１】
オブジェクトＡがオブジェクトＢにメッセージ送信したとき、オブジェクトＡはフューチャＩＤ(futureID）を受け取る。このフューチャＩＤはＯＳ（オペレーティング・システム）がメッセージを配送する際にＯＳが内部的に生成する上記フューチャ（Future）と呼ばれる実体に対応するＩＤである。ここで、生成とはオブジェクトを構成する属性に必要なメモリの領域を確保すること及び当該属性を初期化することを示す。図５に示すように、アプリケーションソフトはＡＰＩを介してメイラ（例えば後述するメタオブジエクト（MLocalMailer））のオブジェクトや後述するスケジューラ（Scheduler）のオブジェクトに通信を行う。メイラの実行がオブジェクト内の実行コードに基づいてＣＰＵによって行われ、ＣＰＵはフューチャ（Future）に必要なメモリ領域をＯＳ領域内に確保する。フューチャＩＤ(futureID）はオブジェクトＡが後にこのメッセージの配送に対する返答を受け取るとき、どのメッセージ送信に対する返答メッセージの受信なのかを識別するために使われる。
【００３２】
図６はフューチャ（Future）の属性を示している。この属性としては、フューチャ（Future）を生成したオブジェクトを特定するためのＩＤ（ThreadID creator）、返答が済んでいるかどうかを調べるためのフラグ（bool isReplyDone）、返答メッセージがある場合にはこれを保存しておくための領域（ void* replyMessage ）が定義されている。例えば図３、図４の例ならば、ＩＤ（ThreadID creator）はオブジェクトＡが、返答メッセージ（void* replyMessage）にはメッセージ（msg）が保存される。
【００３３】
図３はウェイトフォー（Waitfor）がリプライ（Reply）よりも先に実行された場合を示しており、この場合、ウェイトフォー（Waitfor）の引数として上記フューチャＩＤ(futureID）を与える。このとき、指定されたフューチャＩＤ(futureID）に対する返答のための処理が行われていないので、メソッドＡ１（A::A1）の実行は待ち状態になる。その間、メソッドＢ１（B::B1）は処理を続け、返答のための手続きをするときリプライ（Reply）を実行する。リプライ（Reply）が実行されると、ＯＳがメソッドＢ１（B::B1）を起動するときに生成したフューチャ（Future）の状態を観察する。この場合、ＯＳはそのフューチャ（Future）に対して待ち状態のメソッドがあることを知ることができるので、ここでメソッドＡ１（A::A1）を再び実行状態に戻す。その後、メソッドＡ１（A::A1）、メソッドＢ１（B::B1）は再び並行に動作する。
【００３４】
一方、図４はリプライ（Reply）がウェイトフォー（Waitfor）よりも先に実行された場合を示している。リプライ（Reply）が実行されたとき、ＯＳがメソッドＢ１（B::B1）を起動するときに生成したフューチャ（Future）の状態を観察する。この場合、ＯＳはそのフューチャ（Future）に対応したメッセージの送信者（この場合はオブジェクトＡ）はまだ待ち状態にないことを知ることができるので、フューチャ（Future）に返答済みである印を付ける。メソッドＢ１（B::B1）はそのまま残り部分の実行を続ける。メソッドＡ１（A::A1）がメソッドＢ１（B::B1）からの返答を必要としたとき、メソッドＡ１（A::A1）はウェイトフォー（Waitfor）の引数としてフューチャＩＤ(futureID）を与える。この場合、指定されたフューチャＩＤ(futureID）に対する返答のための処理がすでに行われているので、メソッドＡ１（A::A1）は実行を継続することができる。
【００３５】
このように、フューチャ（Future）は並行動作している二つのオブジェクトの同期を取るための仲介的な役割を果たしている。メタスペース（mLocal）通信機構の仕様では、メッセージの送信側はどのメッセージに対する返答待ちかを明示的に示す必要があるので、フューチャＩＤ(futureID）によってフューチャ（Future）を特定する。メッセージの受信側はどの送信者に対する返信なのかを意識する必要がないように定めているので、フューチャＩＤ(futureID）は明示的に現れていない。
【００３６】
［メタスペース（mDrive）通信機構］
メタスペース（mDrive）はコンティネーション（Continuation）を基本にした通信機構をサポートした環境である。このメタスペース（mDrive）はデバイスドライバを記述するためのものである。
【００３７】
ここでは、メタスペース（mDrive）通信機構を使ったオブジェクト間通信の基本的な動作について述べる。この通信機構の実現方式、説明で使用されるコンティネーション（Continuation）が持つ属性や状態遷移などの詳細は後述する。
【００３８】
図７はメタスペース（mDrive）通信機構を使ったオブジェクト間通信の基本的な動作を示している。図３、図４と同様にＡ、Ｂはともにオブジェクト、A::A1、A::A2及びB::B1はそれぞれのオブジェクトＡ、ＢのメソッドＡ１、Ａ２、Ｂ１、縦の実線矢印はメソッドの実行、斜めの実線矢印はメッセージの配送を示している。
【００３９】
オブジェクトＡはセンド（Send）を使ってオブジェクトＢにメッセージを送信する。図７の例ではオブジェクトＢのメソッドＢ１（B::B1）にメッセージ（msg）を配送する。このとき、オブジェクトＡはセンド（Send）に対して５番目の引数として継続メソッド（Ａ２）を、さらに６番目の引数として継続メッセージ（contMsg）を与える。このときのメソッドＡ２（A::A2）は、メソッドＡ１（A::A1）の処理が終了した後、メソッドＢ１（B::B1）からの返答を受け取って処理を継続するメソッドである。また、このときのメッセージ（contMsg）は、継続メソッド（Ａ２）の処理を補助するためのメッセージで、メソッドＡ１（A::A1）が継続メソッドＡ２（A::A2）に渡す内容を含んだメッセージである。
【００４０】
ＯＳは継続メソッド、継続メッセージを含む上記コンティネーション（Continuation）と呼ばれる実体を内部に生成する。ここでのコンティネーション（Continuation）の生成は前記図５での説明で述べたフューチャ（Future）の例と同様、後述するメタオブジエクト（MDriveMailre）等のメイラオブジェクトの実行によりメモリ内にコンティネーション（Continuation）に必要な領域を確保する。
【００４１】
図８はコンティネーション（Continuation）の属性を示している。ここにはコンティネーション（Continuation）を生成したオブジェクトを特定するためのＩＤ（Thread IDcreator）、継続メソッド（Selector method）、継続メッセージ（void*message）を格納する領域が定義されている。このコンティネーション（Continuation）の属性は、図８に示されており、コンティネーション（Continuation）を生成したオブジェクトを特定するためのＩＤ（ThreadID creator）、選択される継続メソッド（Selector method）及び継続メッセージ（void* Message）を保存する領域が定義されている。図７の例ではセンド（Send）により、オブジェクトＡ、メソッドＡ２、メッセージ（contMsg）が送られると、ＯＳがコンティネーション（Continuation）を生成し、ＩＤ（ThreadID creator）にはオブジェクトＡ、継続メソッド（Selector Method）にはメソッドＡ２、及び継続メッセージ（void* Message）にはメッセージ（contMsg）が保存される。
【００４２】
メソッドＢ１（B::B1）はメソッドＡ１（A::A1）から配送されたメッセージの内容の他、そのコンティネーション（Continuation）を特定するためのＩＤとしてＯＳにより生成されたコンティネーションＩＤ（ContID）を受け取る。図７の例では、contIDとして受け取っている。このコンティネーションＩＤ（ContID）はキック（Kick）の引数として使われる。なお、キック（Kick）とはメタスペース（mDrive）におけるＡＰＩの一つであり、本実施の形態ではコンティネーションＩＤ（ContID）をオブジェクトＡに与えることでコンティネーション（Continuation）の中味の情報を得る際に用いられる。このキック（Kick）には、その引数として上記コンティネーションＩＤ（ContID）を備える。メタスペース（mDrive）のオブジェクトはコンティネーション（Continuation）をキック（Kick）することで、コンティネーション（Continuation）に含まれる情報を意識せずに継続メソッドを起動することができる。図７の例では、メソッドＢ１（B::B1）は受け取ったコンティネーションＩＤ（contID）をそれ自身がキック（Kick）し、これによりメソッドＡ１（A::A1）が指定した継続メソッドＡ２（A::A2）が起動され、メソッドＢ１の結果と継続メッセージ（contMsg）が渡される。
【００４３】
このように、コンティネーション（Continuation）は、メッセージを受信したオブジェクトが、誰がメッセージを送信したのか、あるいはどこに返答を送信すればよいのかを意識することなく、継続メソッドを起動できる（そのときに、返答を送信することができる）。メタスペース（mDrive）通信機構の仕様では、コンティネーションＩＤ（ContID）はＯＳがメッセージの受信側にメッセージと共に配送するので、送信側にはコンティネーションＩＤ（ContID）は現れない。
【００４４】
［メタスペース（mLocal）通信機構とメタスペース（mDrive）通信機構の比較］
メタスペース（mLocal）通信機構の仕様において、メソッドの実行の並行性は、あるメソッドの開始から終了までの間にのみ存在する。このセマンティクスは並行性は高くないが（メタスペース（mDrive）通信機構の仕様に比べて）、プログラマが直感的に理解しやすい、記述しなければならないコードの量を少なくし易いなどの利点がある。しかし、この仕様では、割込みを使ったデバイスドライバのような非同期な事象を効率的に記述することができない。
【００４５】
メタスペース（mDrive）通信機構の仕様では、メソッドを一度終了した後の継続メソッドを指定することができる。割込みのような非同期な事象に対応して返答を送信するとき、コンティネーション（Continuation）をキック（Kick）することによってあらかじめ指定された継続メソッドを起動できる。そのため、デバイスドライバのような非同期な事象を処理するプログラムを効率的に記述することができる。これは並行性の高いプログラムを記述できるが（メタスペース（mLocal）通信機構の仕様に比べて）、プログラマが直感的に理解し難い、記述しなければならないコードの量が多くなり易いなどの欠点がある。
【００４６】
[本発明方法における通信機構の実現方式］
本発明方法では、メタスペースが提供する機能は、メタスペースを構成するオブジェクトによって実現する。このようなオブジェクトを、メタスペースが提供する機能を使うオブジェクトに対して特にメタレベルオブジェクト、またはメタオブジエクトと呼ぶ。一方、メタスペースが提供する機能を使うオブジェクトをベースレベルオブジェクト、またはベースオブジェクトと呼ぶ。
【００４７】
各メタスペースに共通な機能を提供するオブジェクトとして（これから説明を進める各通信機構を実現するための構成要素として）、例えばスケジューラ（Scheduler）と呼ぶものを用いることができる。スケジューラ（Scheduler）はオブジェクトの状態を管理するメタオブジェクトである。本実施の形態で必要になるスケジューラ（Scheduler）の仕様は後述する。
【００４８】
一方、メタスペース（mLocal）とメタスペース（mDrive）の通信機構はそれぞれのメタスペースで異なる機構なので、それを実現するための機能を提供するメタオブジエクトは、それぞれに定義することができる。ここでは、メタスペース（mLocal）通信機構にてメッセージの配送を実現するメタオブジエクトをメタオブジエクト（MLocalMailer）、メタスペース（mDrive）通信機構にてメッセージの配送を実現するメタオブジエクトをメタオブジエクト（MDriveMailer）と呼ぶ。
【００４９】
メタスペース（mLocal）通信機構はメタオブジエクト（MLocalMailer）、スケジューラ（Scheduler）、そしてそれらの実行を支援する他のモジュールによって実現される。また、メタスペース（mDrive）通信機構はメタオブジエクト（MDriveMailer）、スケジューラ（Scheduler）、そしてそれらの実行を支援する他のモジュールによって実現される。ここではメタオブジエクト（MLocalMailer）とスケジューラ（Scheduler）、メタオブジエクト（MDriveMailer）とスケジューラ（Scheduler）の関係にシナリオを与え、各通信機構の実現方式を示す。また、それぞれフューチャ（Future）とコンティネーション（Continuation）の属性を与え、シナリオによってそれらの状態遷移を示す。
【００５０】
［フューチャ（Future）とメタスペース（mLocal）通信機構の実現方式］
図９から図１２はメタオブジエクト（MLocalMailer）とスケジューラ（Scheduler）の関係をシナリオ（フローチャート）によって与える。
【００５１】
図９はメタスペース（mLocal）のセンド（Send）の手続きを示している。
【００５２】
この図９において、先ずメタスペース（mLocal）上のベースオブジェクトがセンド（Send）を実行すると、メタスペース（mLocal）を構成する通信機構のためのメタオブジェクト（MLocalMailer）に処理が移ると共にベースオブジェクトはステップＳＴ７のようにウェイト（Wait）の状態となる。ここで、ベースオブジェクトからメタオブジエクトへ処理の状態が移ることを、以下にＭ（Meta Computation）と表現する。
【００５３】
このように処理が移ると、メタオブジエクト（MLocalMailer）は、ステップＳＴ１として、フューチャ（Future）を生成する。
【００５４】
次に、ステップＳＴ２として、メッセージ（ActiveMessage）を配送する宛て先のオブジェクトのメッセージキュー（メッセージの並び）の状態を調べる。このとき、メッセージキューにメッセージがない場合（ＦＡＬＳＥ、偽）には、そのオブジェクトは休眠状態（スケジューラ（Scheduler）が管理している状態では休止（Dormant））なので、ステップＳＴ５として、スケジューラ（Scheduler）にメイクレディ（MakeReady）を発行（issue）してオブジェクトを実行可能状態（スケジューラ（Scheduler）が管理している状態ではレディ（Ready））にする。ここで簡単にメッセージキューについて解説する。図１３に示すように、ＣＰＵはオブジェクト内の１つのスレッドを実行する際、配送されたメッセージを利用する。メッセージキューはメッセージの並びを示し、メッセージキュー内のメッセージを順次利用するように構成される。なお、メイクレディ（MakeReady）はスケジューラ（Scheduler）にそのオブジェクトが実行可能とするために用いられるＡＰＩであり、上記レディ（Ready）は実行可能状態を、上記ドーマント（Dormant）はオブジェクトが休止状態であることを表す。上記ドーマント（Dormant）時は、オブジェクトが何も実行せずメッセージを受信できる状態を表す。メイクレディ（MakeReady）には、引数としてベースオブジェクトを特定する（Thread of base）（この実施の形態ではオブジェクトＢ）、宛先のメソッド（method）、メッセージ(msg）を持つ。よって、この実施の形態ではベースオブジェクトＢを指定してメソッドＢにメッセージ（msg）を送るように管理する命令をスケジューラ（Scheduler）に送ることになる。
【００５５】
一方、ステップＳＴ２において、メッセージキューにメッセージがある場合（ＴＲＵＥ、真）には、すでにそのメッセージが宛て先のオブジェクトに配送されて、そのオブジェクトが実行可能状態（レディ（Ready））、オブジェクトが実行状態（ランニング（RUNNING））なので、ステップＳＴ４として、メッセージキューの最後にそのメッセージを入れて終了する。このとき、メッセージ送信に対応したフューチャ（Future）を特定できるフューチャＩＤ(futureID）もあわせてメッセージキューで管理する。なお、これらの状態については後述する図２８にて説明する。
【００５６】
その後は、ステップＳＴ６で配送完了であることを示す返り値サクセス（sSuccess）をメタメッセージ（MetaMessage）に入れ、ベースオブジェクトに状態遷移を戻す。その後ベースオブジェクトはステップＳＴ８のように実行或いは実行可能状態となる。ここで、これ以降、メタオブジェクトからベースオブジェクトへ状態遷移が戻ることをＲ（Resume）と表す。上記メタメッセージ（MetaMessage）とは、メタスペース(mLocal）上のベースオブジェクトがセンド（Send）をするとき、当該センド（Send）に必要なパラメータ（引数）を持ったメッセージである。
【００５７】
なお、上述したＭ（Meta Computation），Ｒ（Resume）については、先に示した特願平８−６７８８１号の明細書及び図面に詳しく示されている。
【００５８】
図１０はメタオブジエクト（MLocalMailer）によるリプライ（Reply）に関する手続きを示している。
【００５９】
この図１０において、初めにステップＳＴ１１として、メタオブジエクト（MLocalMailer）はどのベースオブジェクトがリプライ（Reply）してきたのかを確認する。図３、図４の例で言えば、ベースオブジェクトＢがリプライ（Reply）を発行（issue）することが確認される。なお、この確認として、本実施の形態ではＡＰＩの例えば関数GetLast()を使うようにしているが、ここではどのような方法でもよい。またこのときのベースオブジェクトはステップＳＴ２４のようにウェイト（Wait）の状態となる。
【００６０】
次に、ステップＳＴ１２からステップＳＴ１４として、このベースオブジェクトを起動したときに一緒に配送されたフューチャＩＤ(futureID）が特定するフューチャ（Future）が本当にメタスペース（mLocal）のフューチャ（Future）かどうか確認する。ステップＳＴ１２，ＳＴ１４で偽と判断されたらエラーとし、ステップＳＴ２２へ進む。ステップＳＴ１３が偽のときは、本実施の形態の主題であるタグを使った通信機構で他のメタスペースと通信する場合に相当し、後述するメタオブジェクト（Deliverer）に処理を依頼する。
【００６１】
ステップＳＴ１２からステップＳＴ１４において、そうであることが確認されたら、ステップＳＴ１５として、そのフューチャ（Future）の属性（creator）の状態を調べる。このとき、属性（creator）はリプライ（Reply）をしたベースオブジェクトにメッセージを送ったオブジェクトを含み、図３、図４の例で言えばリプライ（Reply）をしたベースオブジェクトＢにメッセージを送ったオブジェクトはＡであり、領域（ThreadID Creator）に保存されている。
【００６２】
次に、ステップＳＴ１６として、そのオブジェクトが待ち状態（ウェイト（Wait））になっているかどうかを調べ、そのオブジェクトが待ち状態（ウェイト（Wait））になっている場合は、ステップＳＴ１７のようにそのオブジェクトがウェイトフォー（WaitFor）を実行している場合である。ウェイトフォー（WaitFor）の実行は前に図３、図４の説明で述べているように、引数としてフューチャＩＤ（futureID）、返答メッセージ（&msg）、サイズ（sizeof(msg)）を有し、いま扱っているフューチャＩＤ（futureID）とウェイトフォー（WaitFor）に与えられたフューチャＩＤ（futureID）は等しく、リプライ（Reply）により送られたメッセージ(msg）が引数（&msg）に与えられる。待ち状態のオブジェクトは前記メイクレディ（MakeReady）によって再び実行可能状態になる。つまり、図３、図４の例では、オブジェクトＡが実行可能状態に復帰する。
【００６３】
なお、この場合の宛先のメソッドはウェイト（wait）状態なので、指定は不要だからUNDEF（undefine）、メッセージ（msg）も不要なのでＮＵＬＬとされている。
【００６４】
一方、ステップＳＴ１６において、属性（creator）が待ち状態でない場合は、まだウェイトフォー（Waitfor）を実行していない。したがってこのとき、メタオブジエクト（MLocalMailer）は、ステップＳＴ１９としてフューチャ（Future）の属性（isReplyDone）をセットし、リプライ完了のマークを入れる。さらに必要に応じてステップＳＴ１８のようにメッセージ（message）に返答メッセージを一時的に保存する。
【００６５】
その後は、ステップＳＴ２０にてフューチャ（Future）を削除し、さらにステップＳＴ２１では配送完了の返り値サクセス（sSuccess）をメタメッセージ（MetaMessage）に入れ、ステップＳＴ２２ではエラーを示す返り値をメタメッセージ（MetaMessage）に入れ、ステップＳＴ２３では配送完了の返り値サクセス（sSuccess）をメタメッセージ（MetaMessage）に入れる。その後ベースオブジェクトはステップＳＴ２５のように実行或いは実行可能状態となる。
【００６６】
図１１と図１２はウェイトフォー（WaitFor）の手順であり、図１１はリプライ（Reply）がウェイトフォー（WaitFor）よりも先に実行された場合（図４の場合）、図１２はその逆（図３の場合）を示している。これらは図１０の説明に対応している。なお、これ以降、ベースオブジェクトの流れは図示を省略する。
【００６７】
図１１において、初めにステップＳＴ３１ではフューチャ（Future）の確認を行い、ステップＳＴ３２ではフューチャ（Future）の属性（isReplyDone）がセットされている（リプライ（Reply）が既に行われている）かどうかの確認を行う。これらステップＳＴ３１、ＳＴ３２にて共に真（ＴＲＵＥ）とされた時には、ステップＳＴ３３にてフューチャ（Future）内にセットされた結果、メッセージをウェイトフォー（WaitFor）のメッセージ（&msg）に入力し、その後は、ステップＳＴ３４にてフューチャ（Future）を削除し、さらにステップＳＴ３５では配送完了のサクセス（sSuccess）をメタメッセージ（MetaMessage）に入れる。ステップＳＴ３１で偽と判断されたら、ステップＳＴ３６ではエラーコードをメタメッセージ（MetaMessage）に入れ、Ｒ（Resume）を行う。なお、ステップＳＴ３２で偽と判断されたら、図１２に示すステップＳＴ４３へ移行する。
【００６８】
一方、図１２において、初めにステップＳＴ４１ではフューチャ（Future）の確認を行い、ステップＳＴ４２ではフューチャ（Future）の属性（isReplyDone）がセットされていないかどうかの確認を行う。これらステップＳＴ４１、ＳＴ４２にて共に真（ＴＲＵＥ）とされた時には、ステップＳＴ４３にて待ち状態となされ、その後、ステップＳＴ４４ではサクセス（sSuccess）をメタメッセージ（MetaMessage）に入れ、ステップＳＴ４５ではメタコール（MetaCall）を終了する。ステップＳＴ４１にて偽と判断されたらステップＳＴ４６にてエラーコードをメタメッセージ（MetaMessage）に入れ、Ｒ（Resume）を行う。ステップＳＴ４２にて偽と判断されたら図１１のステップＳＴ３３へ移行する。なお、図１１、図１２の例は共にベースオブジェクトがメタオブジエクト（MLocalMailer）にウェイトフォー（WaitFor）を依頼し、Ｒ（Resume）されるまでウェイト（Wait）の状態となる（図示せず）。
【００６９】
［コンティネーション（Continuation）とメタスペース（mDrive）通信機構の実現方式］
図１４から図１８にはメタオブジエクト（MDriveMailer）とスケジューラ（Scheduler）の関係をシナリオによって与える。メタオブジエクト（MDriveMailer）はデバイスドライバのためのメタスペースなので、その手続きは前記メタオブジエクト（MLocalMailer）に比べてやや複雑である。その一つに遅延実行テーブル（DelayedExecutionTable）がある。メタオブジエクト（MDriveMailer）においてセンド（Send）やキック（Kick）の手続きは、メタスペース(mDrive）上のオブジェクトがセンド（Send）やキック（Kick）を依頼したときに、遅延実行テーブル（DelayedExecutionTable）への登録だけが行われ、実際のメッセージの配送は、メソッドの終了時（Exitするとき）にまとめて行われる。
【００７０】
図１４はメタオブジエクト（MDriveMailer）におけるセンド（Send）の手続きを示す。
【００７１】
この図１４において、ステップＳＴ５１では、すでに述べたようにセンド（Send）の処理を遅延実行テーブル（DelayedExecutionTable）に登録する。すなわち、当該テーブルにメタメッセージ内の遅延実行用引数を登録する。ここでは、メタスペース(mDrive）上のベースオブジェクトがセンド（Send）をするとき、センド（Send）に必要なパラメータが入った実体としてのメタメッセージ（MetaMessage）が遅延実行テーブル（DelayedExecutionTable）に登録される。その後、ステップＳＴ５２ではサクセス（sSuccess）をメタメッセージ（MetaMessage）に入れ、Ｒ（Resume）を行う。
【００７２】
ここで、上述のメタメッセージ（MetaMessage）の構成について簡単に説明する。
【００７３】
メタメッセージ（MetaMessage）は図１９に示すように、２つの領域に分かれ、メタコール（metacall）のＡＰＩを実行するために必要な情報（例えば引数）のための領域Ａとエラー用コードを納める領域Ｂとを有する。なお、遅延実行テーブル（DelayedExecutionTable）は前記図５で示したフューチャ（Future）の生成と同じく、メイラ(mailer）のオブジェクトがメモリ内に当該テーブル用の領域を確保することで生成される。
【００７４】
図１５は、メタオブジエクト（MDriveMailer）におけるキック（Kick）の手続きである。
【００７５】
この図１５において、ステップＳＴ６１では、図１４と同様にキック（Kick）の処理を遅延実行テーブル（DelayedExecutionTable）に登録する。その後は、ステップＳＴ６２にてサクセス（sSuccess）をメタメッセージ（MetaMessage）に入れ、Ｒ（Resume）を行う。
【００７６】
図１６はメタオブジエクト（MDriveMailer）の終了時（Exit）で、メタスペース(mDrive）上のベースオブジェクトが処理を終了するときに呼び出される手続きである。ここでは、遅延実行テーブル（DelayedExecutionTable）に登録された手続きを、処理の依頼された順序で実行し、最後にオブジェクトのメソッドの終了手続きをする。
【００７７】
この図１６のおいて、初めにステップＳＴ７１として、終了（Exit）の手続きを依頼したベースオブジェクトを特定する（例えば関数GetLast()を使って特定する）。
【００７８】
次に、ステップＳＴ７２にて当該ベースオブジェクトが割込みによって起動されたかどうかを調べる。すなわち、終了（Exit）メソッドが起動された原因がベースオブジェクトの割り込みによるものか判断する。割り込みで起動された場合、その割り込みの前に更に別の割り込みが生じていた可能性が考えられる。図２０に示すように、ベースオブジェクトＩの実行中にベースオブジェクトＩＩが割り込んだ場合、ステップＳＴ７３では今回の終了（Exit）が当該ベースオブジェクトＩＩの割り込みの終了（Exit）か否かを判断する。ステップＳＴ７２、ステップＳＴ７３にて共に真（ＴＲＵＥ）であると判断された場合は、ステップＳＴ７４にて上記別の割り込みに戻る（Resume Interrupt）。また、ベースオブジェクトＩが割り込みによって起動されたものではないとき（ステップＳＴ７２：偽）、ステップＳＴ７３は偽である。このように、ステップＳＴ７２およびステップＳＴ７３で偽と判断されたら、ステップＳＴ７５のように、遅延実行テーブル（DelayedExecutionTable）に登録された手続きを処理する。この処理について、センド（Send）については後述する図１７、キック（Kick）については後述する図１８が示している。
【００７９】
上記ステップＳＴ７５の遅延実行テーブル（DelayedExecutionTable）のための処理を終えると、ステップＳＴ７６にて再びそのベースオブジェクトが割込みで起動されたかどうか調べる。このステップＳＴ７６は、ステップＳＴ７２と実質的に同じである。ここで、もし割込みで起動されている場合は、ステップＳＴ７７にて、そこから復帰するための手続き（ExitFromInterrupt（））を実行して最初の割り込みを終了する。一方、割り込みで起動されていない場合は通常のオブジェクト間通信で起動された場合である。この場合、それまで実行していたオブジェクトを休眠状態にするために、ステップＳＴ７８にて遅延実行テーブル（DelayedExecutionTable）を初期化し、スケジューラ（Scheduler）に休止（MakeDormant）するようにメッセージを送る。引数（BaseThread）はステップＳＴ７１で特定されたベースオブジェクトである。さらに、ステップＳＴ７９にて、そのベースオブジェクトのメッセージキューからそれまで実行していたメッセージを取り除く。
【００８０】
ここでメッセージキューが空になった場合はそれで終了である。もしもメッセージキューが空ではなかった場合には、次に配送されるべきメッセージを引数にして、スケジューラ（Scheduler）に（再び、そのオブジェクトが引数で与えられるメッセージによって起動されるように）メイクレディ（MakeReady）を発行（issue）し、次のメッセージのためにそのオブジェクトを実行可能状態（Ready）にする。
【００８１】
次に、図１７と図１８には、遅延実行テーブル（DelayedExecutionTable）に登録された手続きの一つを処理するシナリオを示す。当該テーブルに例えば１０個が発行されれば１０回実行が行われる。メッセージの有無によるスケジューラ（Scheduler）への依頼事項はメタオブジエクト（MLocalMailer）の場合と同じである。
【００８２】
図１７におけるメタオブジエクト（MDriveMailer）のセンド（Send）の場合は、先ず、ステップＳＴ８１にてコンティネーション（Continuation）を生成する。
【００８３】
次のステップＳＴ８２にてメッセージの宛先がメタスペース(mDrive）オブジェクトか判断する。もし偽であれば、後述するメタオブジエクト（Deliverer）に処理の依頼を行わない、タグ通信が行われる。ステップＳＴ８３ではメッセージ（ActiveMessage）を配送する宛て先のオブジェクトのメッセージキューの状態を調べる。このとき、メッセージキューにメッセージがない場合には、そのオブジェクトは休眠状態（スケジューラ（Scheduler）が管理している状態では休止（Dormant））なので、ステップＳＴ８５として、スケジューラ（Scheduler）にメイクレディ（MakeReady）を発行（issue）してオブジェクトを実行可能状態（スケジューラ（Scheduler）が管理している状態ではレディ（Ready））にする。メッセージキューにメッセージが存在しない状態になると、ステップＳＴ８４として、配送メッセージとコンティニュエーションをメッセージキューに格納する。
【００８４】
一方、ステップＳＴ８２及びステップＳＴ８３において、真の場合には、すでにそのメッセージが宛て先のオブジェクトに配送されて、そのオブジェクトが実行可能状態、実行状態（RUNNING）、または実行中断状態（Suspend）なので、ステップＳＴ８４として、メッセージキューの最後にそのメッセージを入れて終了する。このとき、メッセージ送信に対応したコンティネーション（Continuation）或いはそれを指し示すＴＩＤ（後述する）もあわせてメッセージキューで管理する。
【００８５】
図１８におけるメタオブジエクト（MDriveMailer）のキック（Kick）の場合は、ステップＳＴ９１において、与えられたコンティネーション（Continuation）がメタオブジエクト（MDriveMailer）のコンティネーション（Continuation）なのかどうかを確認する。ステップＳＴ９１が真の場合はステップＳＴ９２にてコンティネーション（Continuation）の存在を確認する。このコンティネーションが確認されたら、ステップＳＴ９３で当該コンティネーション（Continuation）を開き、コンティネーション内の属性（宛先、メソッド、メッセージ（msg））をチェックし、それに基づいてセンド（Send）を行う。次のステップＳＴ９４にてメッセージの確認を行い、ステップＳＴ９５では、メッセージキューの最後にそのメッセージを入れて終了する。このとき、メッセージ送信に対応した後述するタグＩＤ(TID）もあわせてメッセージキューで管理する。
【００８６】
一方、ステップＳＴ９２、ＳＴ９４にて、偽である場合は、ステップＳＴ９６にてスケジューラ（Scheduler）にメイクレディ（MakeReady）を発行してオブジェクトを実行可能状態にする。そして、ステップＳＴ９５として、メッセージキューにメッセージとメッセージ送信に対応したタグＩＤ（ＴＩＤ）とを格納する。なお、ステップＳＴ９４、ＳＴ９５、ＳＴ９６は、図１７のステップＳＴ８３、ＳＴ８４、ＳＴ８５と同様の機能である。ステップＳＴ９１で偽と判断されたら、後述するタグを使った通信機構で他のメタスペースと通信する場合に相当し、メタオブジェクト（Deliverer）に処理の依頼を行う。
【００８７】
「タグを使った通信機構の基本的な説明」
オブジェクト間通信をするには、単純なメッセージ送信の他に、返答を受け取ったり他のメソッドの実行と同期をとることが必要になる。このとき、フューチャ（Future）やコンティネーション（Continuatin）のようなものが必要になる。このような複数のオブジェクト間通信（本実施の形態ではフューチャやコンティネーション等）で必要とされる同期や並行性を制御するデータ構造を本実施の形態ではタグと呼ぶ。ここでいうデータ構造とは例えばＣ言語やＰＡＳＣＡＬでいうところのStructureやＣ＋＋でいうClassのような構造を示す。このタグとは異なるデータ構造をある共通のデータ構造で関連付けるものであり、この共通のデータ構造はこれらの異なるデータ構造を区別するための識別子（属性：例えばExecSpaceID mailer）を含むように構成される。さらに、同種類のデータ構造間の区別を与えるための識別子（属性：例えばlongword timeStamp）を有することでより多くのデータ構造が管理できる。詳細は図２１の説明時に行う。また、タグを識別するために必要なＩＤをタグＩＤ（TID）と呼ぶ。
【００８８】
ここで、タグの属性としてタグの型が必要になる。タグの型はそのタグがどの環境で使われるどのようをものかを特定できる必要がある。ただし、タグの型はグローバルに認識ができるものである必要はない。ある環境でそのタグの型を特定できなかった場合には、そのタグの型を特定できる他の独立したオブジェクトに問い合わせなどを行なうことでそれを解決することができればよい。
【００８９】
ここでは、メタスペース（mLocal）とメタスペース（mDrive）におけるフューチャ（Future）、コンティネーション（Continuation）の例を使って、タグを使った異なるメタスペース間の通信について述べる。本実施の形態の例では、メタスペース（mLocal）にオブジェクトＡ、メタスペース(mDrive）にオブジェクトＢが存在し、それぞれ前述同様に、以下のようなメソッドが定義されているとする。
【００９０】
オブジェクトＡ
メソッドＡ１（A::A1）
オブジェクトＢ
メソッドＢ１（B::B1）
メソッドＢ２（B::B2）
このとき、以下の二通りについて、タグを使った異なるメタスペース間通信の基本的な動作について述べる。
【００９１】
１．オブジェクトＡ（メソッドＡ１（A::A1））がメソッドＢ１（B::B1）にセンド及びウェイトフォー（Send＋WaitFor）する場合
２．オブジェクトＢ（メソッドＢ１（B::B1））がメソッドＡ１（A::A1）にセンド（Send）し、継続メソッドとしてメソッドＢ２（B::B2）を指定した場合
［オブジェクトＡ（メソッドＡ１（A::A1））がメソッドＢ１（B::B1）にセンド及びウェイトフォー（Send＋WaitFor）する場合］
メソッドＡ１（A::A1）はセンド（Send）（オブジェクトＢ，メソッドＢ1，メッセージ（mag）,関数sizeof(msg)，フューチャＩＤ(&futureID））を実行する。このとき、実際にこの手続きを処理するメタオブジエクト（MLocalMailer）はフューチャ（Future）を生成する。フューチャ（Future）は次の要件を満たしていればよい。すなわち、
フューチャ（Future）がタグＩＤで特定できるユニークな実体であること、
タグの型がメタスペース（mLocal）のフューチャ（Future）であることを示すこと、及び
図６で示したフューチャ（Future）の属性を持っていること。
【００９２】
メタオブジエクト（MLocalMailer）は、なんらかの方法でメタオブジエクト（MDriveMailer）にメッセージ（msg）をオブジェクトＢまで配送するように依頼すると共に、メソッドＢ１（B::B1）を起動するように依頼をする。このとき、フューチャ（Future）を特定することができるタグＩＤをあわせて配送する。また、このときオブジェクトＡはそのフューチャ（Future）を後に特定することができるようにフューチャＩＤ(futureID）を受け取る。ここではその型の変数をフューチャＩＤ(futureID）としている。このＩＤは、タグＩＤをメタスペース（mLocal）の仕様にあわせてマップしたものであると考えられる。
【００９３】
オブジェクトＢは、そのメッセージ（msg）によってメソッドＢ１（B::B1）が起動されたとき、そのメッセージがどこから配送されたかを知ることはできない（或いは知るべきではない）。これが透明性のあるオブジェクト間通信の実現で要求される。メソッドＢ１（B::B1）は起動されるときに、コンティネーション（Continuation）がメッセージ（msg）といっしょに配送される。コンティネーション（Continuation）は型（コンティネーションＩＤ（contID））として扱い、ここではその変数を（contID）とする。この変数（contID）は先のフューチャＩＤ(futureID）と同じタグを特定していることになる。
【００９４】
メソッドＢ１（B::B1）の実行が進むとキック（Kick（contID））を実行する。このとき、メタオブジエクト（MDriveMailer）はコンティネーションＩＤ（変数contID）で特定できるタグの型をチェックする。このとき、タグＩＤの管理方式の観点から、次の二つの可能性がある。
【００９５】
１．メタオブジエクト（MDriveMailer）がコンティネーションＩＤ（contID）で特定できるタグの型をメタスペース（mLocal）のフューチャ（Future）であるとわかる場合（タグＩＤの管理方式（1））
２．メタオブジエクト（MDriveMailer）がコンティネーションＩＤ（contID）で特定できるタグの型を知ることができない場合（タグＩＤの管理方式（2））
前者の場合、メタオブジエクト（MDriveMailer）はなんらかの方法でメタオブジエクト（MLocalMailer）に直接タグＩＤを配送することができる。メタオブジエクト（MLocalMailer）はタグＩＤが配送されると、それはメタスペース（mLocal）上でリプライ（Reply()）が行われるのとまったく同じように処理を進めることができる。すなわち、タグＩＤ（＝フューチャＩＤ(futureID））に対応したフューチャ（Future）に対して、図１０で示したシナリオと同様にメソッドＡ１（A::A1）の実行を再開させたり、返答メッセージをフューチャ（Future）に一時的に保存しておくことができる。
【００９６】
後者の場合、タグＩＤをメタオブジエクト（MLocalMailer）に配送する方法として、次の方法が考えられる。
【００９７】
１．タグの型を管理している別のオブジェクトがあり、そのオブジェクトはタグＩＤを与えるとそのタグＩＤの型を調べ、そのタグを処理できるＡＰＩとしてのメイラ（Mailer）を教えてくれるメソッドを用意する。メタオブジエクト（MDriveMailer）はこのメソッドを利用して、そのタグＩＤをメタオブジエクト（MLocalMailer）に配送すればよいことを知ることができ、直接メタオブジエクト（MLocalMailer）にタグＩＤを配送する方法（タグＩＤの管理方式（2A））
２．タグの型を管理している別のオブジェクトがあり、そのオブジェクトは与えられたタグＩＤを直接それに対応したタグを処理できるメイラ（Mailer）に配送してくれる方法（タグＩＤの管理方式（2B））
これらの場合も、最終的にはメタオブジエクト（MLocalMailer）にタグＩＤが配送され、図１０で示したシナリオと同様にメソッドＡ１（A::A1）の実行を再開させたり、返答メッセージをフューチャ（Future）に一時的に保存しておくことができる。
【００９８】
[オブジェクトＢ（メソッドＢ１（B::B1））がメソッドＡ１（A::A1）にセンド（Send）し、継続メソッドとしてメソッドＢ２（B::B2）を指定した場合］
メソッドＢ１（B::B1）はセンド（オブジェクトＡ，メソッドＡ１，メッセージ（msg），関数（sizeof(msg)），メソッドＢ２、メッセージ（contMsg））を実行する。このとき、実際にこの手続きを処理するメタオブジエクト（MDriveMailer）はコンティネーション（Continuation）を生成する。コンティネーション（Continuation）は次の用件を満たすことになる。
【００９９】
コンティネーション（Continuation）がタグＩＤで特定できるユニークな実体であること、
タグの型がメタスペース（mDrive）のコンティネーション（Continuation）であることを示すこと、及び
図８で示したコンティネーション（Continuation）の属性を持っていること。
【０１００】
メタオブジエクト（MDriveMailer）を含むＯＳは、なんらかの方法でメタオブジエクト（MLocalMailer）にメッセージ（msg）をオブジェクトＡに配送し、メソッドＡ１を起動するように依頼する。このとき、コンティネーション（Continuation）を特定することができるタグＩＤをあわせて配送する。
【０１０１】
メタスペース(mDrive）の通常のオブジェクト間通信では、このタグＩＤはコンティネーションＩＤ（ContID）として扱われるものになる。しかし、この場合はメタオブジエクト（MLocalMailer）ではそれをコンティネーションＩＤ（ContID）として扱う必要はなく、タグＩＤとして扱う。そして、メタスペース（mLocal）の通常のオブジェクト間通信ではメッセージを配送してあるメソッドを起動すると、それにフューチャ（Future）（またはフューチャＩＤ(futureID））が関係付けられるのと同様に、メタオブジエクト（MDriveMailer）から配送されたタグＩＤが関係付けられる。
【０１０２】
メソッドＡ１（A::A1）の実行が進むとリプライ（Reply()またはReply（ReplyMsg））を実行する。このとき、メタオブジエクト（MLocalMailer）はメソッドＡ１（A::A1）を起動したときに関係付けられたタグＩＤを調べ、タグＩＤが特定するタグの型をチェックする。このとき、メタスペース（mLocal）上のオブジェクトＡからメタスペース(mDrive）上のオブジェクトＢに通信した場合と同様に、タグＩＤの管理方式の観点から、次の二つの可能性がある。
【０１０３】
１．メタオブジエクト（MLocalMailer）がタグＩＤで特定できるタグの型をメタスペース(mDrive）のコンティネーション（Continuation）であるとわかる場合（タグＩＤの管理方式（１））
２．メタオブジエクト（MLocalMailer）がタグＩＤで特定できるタグの型を知ることができない場合（タグＩＤの管理方式（２））
いずれの場合においても、メタスペース（mLocal）上のオブジェクトＡからメタスペース(mDrive）上のオブジェクトＢに通信した場合と同様、なんらかの方法でメタオブジエクト（MDriveMailer）にタグＩＤを配送できる。メタオブジエクト（MDriveMailer）はタグＩＤを受け取ると、図１８で示したシナリオと同様の手続きを行なう。すなわち、はじめにタグＩＤに対応したコンティネーション（Continuation）を開き（Open）し、継続メソッドと継続メッセージを得る。そして、継続メソッドを配送するべきオブジェクト（コンティネーション（Continuation）のクリエータ（creator））のメッセージキューの状態に応じて、スケジューラ（Scheduler）をアクセスし、最終的にメソッドＢ２（B::B2）を起動する。
【０１０４】
「タグを使った通信機構の本実施の形態での実現事例」
本章では、本実施の形態において、タグを使ってそれぞれメタスペース（mLocal）、メタスペース(mDrive）に存在するオブジェクトが透明性を持って通信することを可能にした実現方式について述べる。ここでは異なる通信機構としてメタスペース（mLocal）通信機構とメタスペース(mDrive）通信機構の二つのみが存在することを仮定する。
【０１０５】
［フューチャ（Future），コンティネーション（Continuation）とタグ（Tag）］
メタスペース（mLocal）におけるフューチャ（Future）、メタスペース(mDrive）におけるコンティネーション（Continuation）を、ＯＳではタグ（Tag）として扱うことが可能である。このとき、ＯＳはタグ（Tag）がフューチャ（Future）であるかコンティネーション（Continuation）であるかを識別する必要がある。それを識別するための型としてＡＰＩのメイラ（Mailer）のＩＤを使う。タグの型として使われるメイラＩＤ（MailerID）がメタオブジエクト（MLocalMailer）の場合にはフューチャ（Future）、メタオブジエクト（MDriveMailer）の場合にはコンティネーション（Continuation）であると認識することができる。
【０１０６】
図２１はタグ（Tag）とフューチャ（Future）、コンティネーション（Continuation）の関係、タグ（Tag）とタグＩＤ（TID）の関係をいわゆるＯＭＴ（object modeling technique）法のオブジェクトモデル図で示している。クラスフューチャＣ１と、クラスコンティネーションＣ２はクラスタグＣ３から派生したサブクラスとして定義できる。タグ（Tag）はメイラ（Mailer）を識別するＩＤとして実行場所ＩＤ（ExecSpaceID）を使っている。この場合、実行場所ＩＤ（ExecSpaceID）は、そのオブジェクトを示すＩＤと等価な意味で使われている。タグ（Tag）はタグＩＤ（TID）というＩＤによって特定できる。タグ（Tag）に含まれるタイムスタンプ（timeStamp）はタグ（Tag）をタグＩＤ（TID）を使って特定するとき時間軸に対してユニークであることを保証するために使用される。フューチャ（Future）およびコンティネーション（Continuation）を特定することができれば、タイムスタンプ（timeStamp）は必ずしも使われる必要はない。
【０１０７】
メタスペース（mLocal）通信機構、メタスペース(mDrive）通信機構ではそれぞれフューチャ（Future）、コンティネーション（Continuation）を特定するためにフューチャＩＤ(futureID）、コンティネーションＩＤ（ContID）が使われる。タグ（Tag）を導入した場合、ＯＳ内ではこれらはすべて共通に表記されることのできるタグＩＤ（TID）として特定することができる。
【０１０８】
本実施の形態では、プログラマがメタスペース（mLocal）やメタスペース(mDrive）を提供しているインターフェースをそのまま使用することができるように、インターフェースを定義しているへッダフアイル（MLocal.h、MDrive.h）では型の再定義が行われている。すなわち、メタスペース（mLocal）のへッダフアイル（MLocal.h）ではフューチャＩＤ(futureID）をタグＩＤに再定義する。これを例えばＣ言語やＣ＋＋の定義方法で示すと、typedef TID futureID；となる。なお、typedefは新しい型を定義（define）すると言う意味である。メタスペース(mDrive）のヘッダファイル（MDrive.h）のコンティネーションヘッダファイル（Cont.h）ではコンティネーションＩＤ（ContID）をタグＩＤに再定義している。これも同様に示すと、typedef TID ContID；となる。
【０１０９】
［タグＩＤの管理方式と当該タグＩＤを配送するオブジェクト（Deliverer）］
本実施の形態では、前記タグＩＤの管理方式（2B）を適用している。異なるメタスペース間の通信機構をサポートするメタオブジェクトとして、Delivererを導入する。オブジェクト（Deliverer）は主に二つのインターフェース（メソッド或いはＡＰＩ）を持つ。
【０１１０】
すなわち、その一つであるインターフェース（sError DeliverObject）は、メッセージ（msg）を指定されたオブジェクト（destination）（引数オブジェクトＩＤ（ＯＩＤ）及び宛先メソッド（sel）で示される。）に配送し、最終的にオブジェクト（destination）のメソッド（method）が起動されるよう、オブジェクト（destination）が存在するメタスペースのメイラ（Mailer）に依頼をする。このインターフェース（sError DeliverObject）は更に、引数の一つとして配送されるタグＩＤ（TID）を、オブジェクト（destination）が返答する場合に使用する。
【０１１１】
もう一方のインターフェース（sError DelivereTag）は、タグＩＤ（TID）を配送する。オブジェクト（deliverer）はタグＩＤ（TID）に対応したタグ（Tag）の型を調べ、どのメイラ（Mailer）にタグＩＤ（TID）を配送すればよいかを知る。必要に応じて、返答メッセージ（replyMsg）も配送する。
【０１１２】
相手先オブジェクト（destination）が存在するメタスペースのメイラ（Mailer）を知る方法としては、
１．オブジェクトの生成時にあらかじめオブジェクト（deliverer）に登録をして、オブジェクト（deliverer）がその内容を（テーブルなどを使って）管理する方法
２．オブジェクトから直接たどることができるデータ構造に、そのオブジェクトが所属しているメタスペースまたはメタスペースを識別できるなにかのＩＤを含めておく方法
が考えられる。本実施の形態では、後者の方法を使っている。
【０１１３】
［異なるメタスペース間通信の実際］
この異なるメタスペース間通信では、以下の二つの異なるメタスペース間通信（異なるメタスペースに存在するオブジェクト間通信）が考えられる。
【０１１４】
Ａ．メタスペース（mLocal）オブジェクトがメタスペース(mDrive）オブジェクトと通信する（或いは通信して返答を受け取る）場合
Ｂ．メタスペース(mDrive）オブジェクトがメタスペース（mLocal）オブジェクトに通信する（或いは通信して返答を受け取る）場合
図２２と図２３は、オブジェクト（deliverer）を介して異なるメタスペース（メタスペース（mLocal）とメタスペース(mDrive））間通信を行なう場合の前者Ａを、図２４と図２５は後者Ｂのシナリオを示している。
【０１１５】
図２２において、メタオブジエクト（MLocalMailer）がベースオブジェクトのセンド（Send）の手続きの依頼を受け付けてからフューチャ（Future）を生成する処理（ステップＳＴ１０１）までは、図９と同様である。但し、このフューチャ（Future）はタグのサブクラスとして生成される。
【０１１６】
ここで、ステップＳＴ１０２では、メッセージの配送先の確認を行い、メッセージの配送先がメタスペース（mLocal）オブジェクトではない場合、オブジェクト（Deliverer）のメソッド（DeliverObject）にメッセージを送る。
【０１１７】
オブジェクト（Deliverer）はメソッド（DeliverObject）の引数にてその配送先を知ることができるので、ステップＳＴ１０３のように、そのメイラ（MDriveMailer）にさらに配送する。ステップＳＴ１０６以降に示す、メタオブジエクト（MDriveMailer）がインターフェース（DeliverObject）を通じて配送依頼された後の手続き（ステップＳＴ１０６、ＳＴ１０７、ＳＴ１０８）は、前述した図１７のメタオブジエクト（MDriveMailer）が終了時（Exit）にセンド（Send）のために行なう手続き（ステップＳＴ８３、ＳＴ８４、ＳＴ８５）と同様である。但し、この場合はステップＳＴ１０７にてメッセージキューにタグＩＤ(TID）を加えるようになっている。
【０１１８】
図２３はメタスペース(mDrive）に配送されたタグＩＤ（TID）がメタスペース(mDrive）ではコンティネーションＩＤ（ContID）として扱われて、これをキック（Kick）した場合の手続きを示している。
【０１１９】
この図２３において、メタオブジエクト（MDriveMailer）は、ステップＳＴ１１１にて終了時（Exit）のキック（Kick）のための処理時に指定されたコンティネーションＩＤ（ContID）がメタスペース(mDrive）のコンティネーション（Continuation）のものではないとわかる。そこでオブジェクト（Deliverer）のタグ（DeliverTag）を使ってタグＩＤ（TID）を配送する。
【０１２０】
オブジェクト（Deliverer）はステップＳＴ１１２にてタグＩＤ（TID）からタグ（Tag）を特定し、その属性（ExecSpaceID mailer）から、そのタグ（Tag）がメタオブジエクト（MLocalMailer）のもの（メタスペース（mLocal）のフューチャ（Future））とわかる。そこでメタオブジエクト（MLocalMailer）にそのタグＩＤ（TID）を配送する。
【０１２１】
メタオブジエクト（MLocalMailer）がタグＩＤ（TID）を受け取った後の手続きは、前述した図１０のメタオブジエクト（MLocalMailer）のリプライ（Reply）と同様である（ステップＳＴ１３が真であった場合以降ステップＳＴ１４、ＳＴ１５、ＳＴ１６、ＳＴ１７、ＳＴ２０まで）。
【０１２２】
一方、図２４、図２５はメタスペース(mDrive）からメタスペース（mLocal）にメッセージを送信し、返答を受け取る場合のシナリオである。オブジェクト（Deliverer）の動作は図２２、図２３と同様である。
【０１２３】
すなわち、図２４の例では、メタオブジエクト（MDriveMailer）がベースオブジェクトのセンド（Send）の手続きの依頼を受け付けてからコンティネーション（Continuation）を生成する処理（ステップＳＴ１２１）は、図１７と同様である。
【０１２４】
ここで、ステップＳＴ１２２では、メッセージの配送先の確認を行い、メッセージの配送先がメタスペース（mDrive）オブジェクトではない場合、オブジェクト（mMLocal）のメソッド（DeliverObject）にメッセージを送る。
【０１２５】
オブジェクト（Deliver）はその配送先を知ることができるので、ステップＳＴ１２３のように、そのメイラ（MLocaMailer）にさらに配送する。ステップＳＴ１２６、ＳＴ１２７、ＳＴ１２８に示す、メタオブジエクト（MLocalMailer）がインターフェース（DeliverObject）を通じて配送依頼された後の手続きは、前述した図１８のメタオブジエクト（MDriveMailer）が終了時（Exit）にセンド（Send）のために行なう手続き（ステップＳＴ９４、ＳＴ９５、ＳＴ９６）と同様である。
【０１２６】
また、図２５において、メタオブジエクト（MLocalMailer）は、ステップＳＴ１３１からステップＳＴ１３４にてReply処理時に指定されたフューチャＩＤ（futureID）がメタスペース(mLocal）のフューチャ（Future）のものではないとわかる（図１０のステップＳＴ１１、ＳＴ１２、ＳＴ１３と同様）。そこでオブジェクト（Deliverer）のタグ（DeliverTag）を使ってタグＩＤ（TID）を配送する（図１０のステップＳＴ１３の偽の場合と同じ）。
【０１２７】
オブジェクト（Deliver）はステップＳＴ１３５にてタグＩＤ（TID）からタグ（Tag）を特定し、その属性（ExecSpaceID meiler）から、そのタグ（Tag）がメタオブジェクト（MDriveMailer）のもの（メタスペース（mDrive）のコンティネーション（Continuation））とわかる。そこでメタオブジエクト（MDriveMailer）にそのタグＩＤ（TID）を配送する。
【０１２８】
メタオブジエクト（MDriveMailer）がタグＩＤ（TID）を受け取った後の手続き（ステップＳＴ１３８以降）は、前述した図１８のメタオブジエクト（MDriveMailer）の処理（ステップＳＴ９３、ＳＴ９４、ＳＴ９５、ＳＴ９６）と同様である。
【０１２９】
「その他に考えられる実現方式」
本章ではこれまでに説明した実施の形態での実現方式以外に考えられる「タグを使った通信機構」の実現方式について述べる。
【０１３０】
［タグＩＤでタグの型を認識する方式］
本実施の形態では、タグ（Tag）の属性としてメイラ（Mailer）のＩＤを持っている。これによってタグ（Tag）の型を識別した。つまり、タグＩＤ（TID）からタグ（Tag）を特定し、その属性からタグの型を認識した。別の方法ではタグＩＤにタグの型を認識するための情報を付加する方式である。いまタグＩＤが３２ビットで表わされる整数値だとした場合、例えば下位２ビットをタグ（Tag）の型のために使うという方式が考えられる。図２６には、タグＩＤでタグの型を認証する方式の一例を表す。すなわちこの図２６では、下位２ビットの組み合わせが００のときにはメタスペース（mLocal）のフューチャ（Future）を表すものとし、下位２ビットの組み合わせが０１のときにはメタスペース（mDrive）のコンティネーション（Continuation）を表すものとする。このようにタグの実体を用いずにタグＩＤ（TID）にみを発生させて、このタグＩＤ（TID）にタグの属性を含めたＯＭＴを図２１に対して図２７として示す。なお、図２７中の指示符号Ｃ１，Ｃ２は図２１と同じものである。このようにすれば、タグを介することなくフューチャやコンティネーションを対応付けることができる。この場合は、タグの領域をメモリ内に確保する必要がないので、メモリ領域を削減できる利益がある。なお、本実施の形態ではタグの下位２ビットを利用する例を述べたが、１ビット或いは上位、中位の任意のビットを用いても良いことは勿論である。
【０１３１】
［タグの管理方式］
本実施の形態では、前述したようにタグの管理方式（１）、（２Ａ）、（２Ｂ）の可能性を示したが、いずれの方式もタグにはその属性として型があり、メイラ（Mailer）はその型を調べることで少なくともそのメイラ（Mailer）自身が処理できるタグかどうかを判断する方式について述べた。これらとは別に、タグの属性には型を持たせずに、ただそのメイラ（Mailer）が処理できるタグをメイラ（Mailer）内部に情報として管理するという方式が考えられる。
【０１３２】
この方式では、メイラ（Mailer）がフューチャ（Future）やコンティネーション（Continuation）を生成したら、その情報をメイラ（Mailer）自身が持つテーブルなどに保存する。リプライ（Reply）やキック（Kick）でタグを配送するとき、メイラ（Mailer）はそのテーブルを走査し、そのタグがそのメイラ（Mailer）で処理できる場合は通常のリプライ（Reply）、キック（Kick）の処理を行なう。そうでない場合は、タグの管理方式（２Ａ）のように、どのメイラ（Mailer）にタグを配送すればよいか問い合わせたり、（２Ｂ）のように他のオブジェクトに処理の続きを依頼することができる。
【０１３３】
この場合、メイラ（Mailer）以外に（オブジェクト（Deliverer）のような）タグＩＤとそれに対応したタグを処理できるメイラ（Mailer）を知ることができるオブジェクトも、タグの属性としての型がない場合には、テーブルなどでその対応を管理する必要がある。
【０１３４】
図２８には、スケジューラ（Scheduler）におけるスレッド（Thread）の状態遷移図を示し、以下にスケジューラ（Scheduler）の仕様の例を示す。
【０１３５】
各スレッド（Thread）は実行制御のために各状態を呈する。スケジューラ（Scheduler）はこれらスレッド（Thread）の状態変化を司り、優先順位のような属性（attribute）に基づいて次にどのスレッドを実行すべきかを決定する。
【０１３６】
休止状態（Dormant）はそのスレッド（Thread）に関して実行されるべきものが無いことを示す、このときのメッセージ（message）は受信可能の状態にある。
【０１３７】
実行可能状態（Ready）は、そのスレッド（Thread）は実行可能状態にあることを示し、スケジューラ（Scheduler）内の実行可能状態のスレッド（Thread）のためのキュー（レディキュー（Ready Queues））に入れられる（enqueue）。スレッド（Thread）が実行可能状態（Ready）のときそのスレッド（Thread）に対応付けられたオブジェクトはRで呼び起こされる。
【０１３８】
実行状態（Running）はそのスレッド（Thread）は実行中であることを示す。
【０１３９】
待機状態（Wait）は、オブジェクトの実行中断状態を示し、例えば前述のメタスペース（mLocal）通信機能によってウェイトフォー（WaitFor）がリプライ（Reply）よりも先に発行された場合に生ずる。
【０１４０】
ここでインターフェース（ＡＰＩ）の例をいくつか示す。
【０１４１】
sError MakeReady(thread,sel,msg)
このインターフェース（ＡＰＩ）はスレッド（Thread）によりリンクされた宛先オブジェクトのセレクタ（sel）で指定されるメソッドにメッセージ(msg）を送るためにメーラメタオブジェクト（例えば前述のメタオブジェクト（MLocalMailer））により使用される。
【０１４２】
スケジューラ（Scheduler）はスレッド（Thread）の状態を休止状態（Dormant）から実行可能状態（Ready）に遷移させ、上記レディキュー（Ready Queues）内の列にそれを入れる（enqueue）。
【０１４３】
宛先オブジェクトはスレッド（Thread）がスケジュールされた時、すなわち上記スケジューラ（Scheduler）により実行可能状態（Ready）のスレッド（Thread）が実行されるときに呼び起こされる。
【０１４４】
なお、sErrorはインターフェースの実行結果の状態を示し、メイクレディ（MakeReady）が正しく動作した場合、それを示す返り値（sSuccess）を返す。そうでない場合は各種のエラーを示す値を返す。
【０１４５】
sError MakeReady(thread)
このインターフェース（ＡＰＩ）はスレッド（Thread）の実行を再開するためにメーラによって使用される。スケジューラ（Scheduler）はスレッド（Thread）の状態を待機状態（Wait）から実行可能状態（Ready）に変化させ、レディキュー（Ready Queues）内の列にそれを入れる（enqueue）。このインターフェースは例えば前述のメタスペース（mLocal）通信機能によってウェイトフォー（WaitFor）を発行して待機状態（Wait）にあるオブジェクトが、別のオブジェクトの発行したリプライ（Reply）によって結果メッセージを受け取り、実行可能状態にする必要があるときに使われる。
【０１４６】
sError MakeWait(thread)
このインターフェース（ＡＰＩ）はスレッド（Thread）の実行を停止するために利用される。スケジューラ（Scheduler）はスレッド（Thread）を実行可能状態（Ready）から待機状態（Wait）に遷移させ、レディキュー（Ready Queues）内の列からそれを除く（dequeue）。なお、上記各メーラはベースオブジェクトの実行停止のため、このインターフェースを呼び出す必要はない。なぜならば、ベースオブジェクトが上述のＭ（Meta Computation）を使ってメーラを呼び起こす時にその状態は待機状態（Wait）に変化しているからである。
【０１４７】
sError MakeDormant(thread)
このインターフェース（ＡＰＩ）はスレッド（Thread）の実行を終了するために上記メーラによって利用される。スケジューラ（Scheduler）はスレッド（Thread）の状態を実行可能状態（Ready）から休止状態（Dormant）に変化させ、レディキュー（Rdady Queus）内の列からそれを除く（dequeue）。
【０１４８】
なお、上記メーラ（mailer）からみたオブジェクト（又はそれに関連付けられたスレッド）の状態は、休止状態（Dormant）、実行可能状態（Ready）、待機状態（Wait）の３つである。これは複数の実行可能状態にあるオブジェクトのうち、どのオブジェクトをＣＰＵが処理している（Running）かどうか、メイラは知る必要がないからである。
【０１４９】
【発明の効果】
本発明によれば、異なるオブジェクト間通信機構がそれぞれ固有に持つオブジェクト間通信の同期及び並行性の制御を行うためのタグを導入することによって、異なる環境間のオブジェクト間通信を透明性をもって容易に実現することができる。
【図面の簡単な説明】
【図１】本発明実施の形態のデータ通信方法が適用されるＶＣＲ装置の概略構成を示すブロック回路図である。
【図２】本実施の形態のＶＣＲ装置と通信用ＯＳ、ＡＶ用ＯＳとＡＰＩにより通信が行われる様子の説明に用いる図である。
【図３】メタスペース（mLocal）通信機構（ウェイトフォー（WaitFor）がリプライ（Replay）よりも先に実行された場合）の説明に用いる図である。
【図４】メタスペース（mLocal）通信機構（リプライ（Reply）がウェイトフォー（WaitFor）よりも先に実行された場合）の説明に用いる図である。
【図５】アプリケーションソフトがＡＰＩによってメイラのオブジェクトやスケジューラのオブジェクトに通信を行う様子の説明に用いる図である。
【図６】フューチャ（Future）の属性の説明に用いる図である。
【図７】メタスペース（mDrive）通信機構の説明に用いる図である。
【図８】コンティネーション（Continuation）の属性の説明に用いる図である。
【図９】メタオブジエクト（MLocalMailer）とスケジューラ（Scheduler）の関係（メタスペース（mLocal）におけるセンド（Send）の実現）の手続きの流れを示す図である。
【図１０】メタオブジエクト（MLocalMailer）とスケジューラ（Scheduler）の関係（メタスペース（mLocal）におけるリプライ（Reply）の実現）の手続きの流れを示す図である。
【図１１】メタオブジエクト（MLocalMailer）とスケジューラ（Scheduler）の関係（メタスペース（mLocal）におけるウェイトフォー（WaitFor）でリプライ（Reply）がウェイトフォー（WaitFor）よりも先に実行された場合）の手続きの流れを示す図である。
【図１２】メタオブジエクト（MLocalMailer）とスケジューラ（Scheduler）の関係（メタスペース（mLocal）におけるウェイトフォー（WaitFor）でウェイトフォー（WaitFor）がリプライ（Reply）よりも先に実行された場合）の手続きの流れを示す図である。
【図１３】メッセージキューの説明に用いる図である。
【図１４】メタオブジエクト（MDriveMailer）におけるセンド（Send）の手続きの流れを示す図である。
【図１５】メタオブジエクト（MDriveMailer）におけるキック（Kick）の手続きの流れを示す図である。
【図１６】メタオブジエクト（MDriveMailer）の終了時（Exit）で、メタスペース(mDrive）上のベースオブジェクトが処理を終了するときに呼び出される手続きの流れを示す図である。
【図１７】遅延実行テーブル（DelayeExecutionTable）に登録（メタオブジエクト（MDriveMailer）のセンド（Send）の場合）された手続きを処理する流れを示す図である。
【図１８】遅延実行テーブル（DelayeExecutionTable）に登録（メタオブジエクト（MDriveMailer）のキック（Kick）の場合）された手続きを処理する流れを示す図である。
【図１９】メタメッセージ（MetaMessage）の構成の説明に用いる図である。
【図２０】ベースオブジェクトＩの実行中にベースオブジェクトＩＩが割り込んだ場合の動作説明に用いる図である。
【図２１】タグ（Tag）とフューチャ（Future）、コンティネーション（Continuation）の関係、タグ（Tag）とタグＩＤ（TID）の関係をＯＭＴ法のオブジェクトモデルで示す図である。
【図２２】オブジェクト（deliverer）を介して異なるメタスペース間通信を行なう場合（メタスペース（mLocal）がメタスペース(mDrive）に通信する場合）の往路の流れを示す図である。
【図２３】オブジェクト（deliverer）を介して異なるメタスペース間通信を行なう場合（メタスペース（mLocal）がメタスペース(mDrive）に通信する場合）の復路の流れを示す図である。
【図２４】オブジェクト（deliverer）を介して異なるメタスペース間通信を行なう場合（メタスペース(mDrive）がメタスペース（mLocal）に通信する場合）の往路の流れを示す図である。
【図２５】オブジェクト（deliverer）を介して異なるメタスペース間通信を行なう場合（メタスペース(mDrive）がメタスペース（mLocal）に通信する場合）の復路の流れを示す図である。
【図２６】タグｌＤでタグの型を認証する方式の一例を表す図である。
【図２７】このタグＩＤ（TID）にタグの属性を含めたＯＭＴを示す図である。
【図２８】スレッド（Thread）の状態遷移図を示す。
【符号の説明】
mLocal，mDrive メタスペース、 MLocalMailer，MDriveMailer メタオブジエクト
【発明の属する技術分野】
本発明は、オブジェクト指向オペレーティング・システム（ＯＳ）又はその他のオブジェクト指向プログラミングシステムにおいてオブジェクト間のデータ通信方法に関する。
【０００２】
【従来の技術】
最近のソフトウェア技術には、いわゆるオブジェクト指向技術がある。オブジェクト指向技術を適用したソフトウェアでは、ソフトウエア内部の各機能はオブジェクトとしてモジュール化されている。ソフトウエア全体の機能を実現するために、各オブジェクトはオブジェクト間通信を行なう。オブジェクト間通信では送信内容をメッセージに詰めて配送する。
【０００３】
オブジェクト間通信には同期方法やメッセージの管理方法について、いろいろな方式が考えられる。これらの方式はアプリケーションからの要求に応じて決定される必要がある。そのため、いろいろな要求に応えるためには、アプリケーションに応じた性質（意味構造、セマンティクス）やそれに応じたインターフェース（Application Programming Interface：ＡＰＩs）を持ったオブジェクト間通信機構が必要になる。なお、以下で扱うＡＰＩとは、ＯＳの機能を用いるインターフェース或いはプログラミングシステムの機能としてのインターフェースを示す。
【０００４】
ある性質やインターフェースを持ったオブジェクト間通信機構が存在することを「環境」があると呼ぶことにする。一つの機器やホストにはただ一つの環境が実現されることもあるし、異なる複数の環境が同時に実現されることもある。特に異なる環境に存在するオブジェクト間の通信は相互の環境の協調動作を行わしめるという点から重要である。
【０００５】
ここで、異なる環境に存在するオブジェクトにメッセージを送る機能を提供する考え方として、本質的に以下の二つがある。すなわち、
１．異なる環境に存在するオブジェクトにメッセージを送るために、同じ環境に存在するオブジェクトにメッセージを送るときとは異なるインターフェースや手続きを提供するという考え方と、
２．異なる環境に存在するオブジェクトにメッセージを送るために、同じ環境に存在するオブジェクトにメッセージを送るときと同じインターフェースや手続きを使うことができるという考え方とがある。
【０００６】
前者の方法は、比較的容易に実現できる。なぜなら、全ての環境をプログラマが意識しなくてもよい考え方なので、インターフェースや手続きの違いが環境の違いによって各々異なる機能を提供することで吸収させればよいからである。
【０００７】
【発明が解決しようとする課題】
しかし、プログラマのためには異なる環境に対してプログラムコードが左右されない、いわゆる透明性を提供した方がよい。
【０００８】
そこで本発明は、上述した課題に鑑みてなされたものであり、プログラマのために異なる環境に対して透明性を提供することを可能にするデータ通信方法を提供することを目的とするものである。
【０００９】
【課題を解決するための手段】
本発明は、ソフトウェア機能を実現するため複数のオブジェクト間で通信を行うデータ通信方法において、異なるオブジェクト間通信機構をそれぞれ固有に持つ環境間でそれぞれ異なる実体を用いて通信を行う際、上記異なるオブジェクト間通信機構のデータ構造を共通のデータ構造で関連付けるタグを生成し、上記タグを生成する際、上記タグを識別するためのタグＩＤと上記環境を特定するタグの型を示す属性とを、少なくとも生成し、上記タグを通信メッセージと共に通信し、上記タグの型を示す属性に基づいて上記実体を特定することを特徴としている。
本発明は、同一又は相違ＯＳを問わずオブジェクト間通信が必要なソフトウェアであって、ソフトウェア間が透明性をもって通信することを実現するタグと、それを適用したソフトウェアシステムを実現することにより、上述した課題を解決する。
【００１０】
すなわち、本発明は、上記「タグ」を導入することによって、異なる環境間で透明性のある通信機構を実現したソフトウェア、またはその実現方式を提供する。本発明によって、ある通信機構が固有に持つオブジェクト間通信の同期や並行性の制御に必要な実体が環境によって異なっている場合でも、異なる環境に存在しているオブジェクトが互いにその違いを意識することなく、通信可能になる。
【００１１】
【発明の実施の形態】
本発明の一実施の形態について、図面を参照しながら説明する。
【００１２】
本発明実施の形態のデータ通信方法は、異なる複数の環境を実現できるソフトウェア・システムに適用することを基本的な特徴の一つとしている。本発明の実施の形態では「環境」のことを特にメタスペースと呼んでいる。また、本発明の実施の形態におけるメタスペースでは、オブジェクト間通信機構以外の機能についても異なる「環境」を提供できる。なお、上記異なる複数の環境を実現できるソフトウェア・システムとしては、例えば本件出願人が先に提案している特願平８−６７８８１号の明細書及び図面に記載したデータ処理方法及び装置を挙げることができる。このデータ処理方法は、複数のオブジェクトで構成されるアプリケーションプログラムと、複数のオブジェクトで構成される前記アプリケーションプログラムの動作を規定する実行環境と、前記アプリケーションプログラムと前記実行環境の間のインターフェースを規定するアプリケーションプログラムインターフェースとを備えるサーバと、前記サーバより前記アプリケーションプログラムをダウンロードするクライアントとを備えるデータ処理システムにおけるデータ処理方法であって、前記サーバは前記クライアントに前記アプリケーションプログラムをダウンロードするとき、前記クライアントがダウンロードする前記アプリケーションプログラムの実行環境を有するか否かを検査し、その検査結果に対応して前記アプリケーションプログラムを前記クライアントにダウンロードすることを特徴とするものである。
【００１３】
図１には、本発明実施の形態のデータ通信方法が適用される装置構成の一例を示す。
【００１４】
この図１の装置は、カセット内にビデオテープを収納したビデオカセットを用いて信号の記録再生を行うビデオカセットレコーダ（以下、ＶＣＲ装置と呼ぶ）である。勿論ＶＣＲ装置以外のオーディオ・ビジュアル機器（いわゆるＡＶ機器）や事務機器等のその他の装置、一般のコンピュータ装置にも本発明は適用可能である。
【００１５】
図１のＶＣＲ装置において、ＶＣＲ機能部１４はビデオカセットを用いてデータの記録再生を行うビデオカセットレコーダとしての主要機能を備え、当該ＶＣＲ機能部１４にてビデオカセットに記録／再生されるデータは、バス／ＩＯブリッジ１５を介して装置の他の構成に送られ、また端子２３を介して外部との入出力が行われる。ＣＰＵ（中央処置ユニット）１２は、バス／メモリブリッジ１３を介して各部を制御する制御部である。ＲＡＭ（ランダム・アクセス・メモリ）１０は、比較的小容量で構成され、ワークエリアを有する。ＲＯＭ（リード・オンリ・メモリ）１１は、基本的な機能に関するプログラムを記憶していると共に、本発明で言うＯＳに係るプログラムも記憶されている。すなわち、上記ＣＰＵ１２は、上記ＲＯＭ１１が記憶するプログラムに基づいて各部を制御し、上記ＲＡＭ１０をワークエリアとして使用する。
【００１６】
ＩＣカードドライブ１６は、カード状の筐体内にＩＣ（集積回路）を備えた記憶媒体であるＩＣカードが挿入されるスロットと、当該ＩＣカードに対するデータの書き込み／読み出しを行うＩＣカード駆動部とを有する。フロッピィディスクドライブ１７は、フロッピィディスが挿入されるスロットと、当該フロッピィディスクを回転駆動する回転駆動部と、フロッピィディスクに対してデータの記録／再生を行うヘッド部とを有し、各種データの記録やアプリケーションソフトのインストールなどが行われる。ハードディスクドライブ１８は、当該ハードディスクを回転駆動する回転駆動部と、ハードディスクに対してデータの記録／再生を行うヘッド部とを有する。バススロット１９は、拡張ボードを追加する際の拡張端子である。シリアルポート２０は、モデム（ＭＯＤＥＭ）を介して外部との間でデータ通信を行うための入出力部である。
【００１７】
このＶＣＲ装置は、一般のＶＣＲの機能に追加して、付加的なアプリケーションソフトを与えることができるようになっている。例えばユーザがバージョンアップを図りたい（新しい機能をこのＶＣＲ装置に付加したい）場合等は、ＩＣカードやフロッピディスク或いはインターネット等のネットワーク回線を介して付加的な機能ソフトをインストールできる。したがってユーザは、ＶＣＲ装置本体を買い換えることなく装置の機能アップが行える。アプリケーションプログラムはプログラマによって作成されてユーザに供給されるものである。ここでこれらソフトウェアをいわゆるオブジェクト指向型プログラミングソフトで構築する場合を考える。
【００１８】
上記の例の場合、異なる複数の環境（メタスペース）間で通信が必要となる場合がある。
【００１９】
例えば図２に示すように外部からＭＯＤＥＭ（モデム）、シリアルポートを介して通信されてきたアプリケーションソフトと予めＶＣＲ装置内に存在するアプリケーションソフトは異なる環境（メタスペース）下にあり、それぞれは通信用ＯＳ（後述するメタスペース（mLocal）、メタスペース（mDrive）等）、ＡＶ用ＯＳとＡＰＩ（後述するセンド（Send）、リプライ（Reply）等）により通信が行われるようになっている。
【００２０】
先ず初めに、上記「異なる通信機構について具体的な二つの例」を本発明のデータ通信方法にて実現した例を使って述べる。この例では後述するフューチャ（Future）と呼ぶ実体を使った通信セマンティクス（性質、意味構造）を実現したメタスペース（mLocal）と、コンティネーション（Continuation）と呼ぶ実体を使った通信セマンティクスを実現したメタスペース（mDrive）の例で示す。
【００２１】
本実施の形態では、上記「異なる通信機構の具体的な例」として、
［メタスペース（mLocal）通信機構］
［メタスペース（mDrive）通信機構］
［メタスペース（mLocal）通信機構とメタスペース（mDrive）通信機構の比較］
［本発明方法における通信機構の実現方式］
［フューチャ（Future）とメタスペース（mLocal)通信機構の実現方式］
［コンティネーション（Continuation）とメタスペース（mDrive）通信機構の実現方式］
の順に説明する。
【００２２】
次に、「タグを使った通信機構の基本的な説明」を述べる。ここでもメタスペース（mLocal）とメタスペース（mDrive）を例に述べる。なお、メタスペース（mLocal）、メタスペース（mDrive）は、１つのＯＳ又はプログラミングシステムとして捉えることができる。本実施の形態では、上記「タグを使った通信機構の基本的な説明」として、
［オブジェクトＡ（メソッドＡ１（A::A1））がオブジェクトＢ（メソッドＢ１（B::B1））にセンド及びウェイトフォー（Send+WaitFor）する場合］
［オブジェクトＢ（メソッドＢ１（B::B1））がオブジェクトＡ（メソッドＡ１（A::A1））にセンド（Send）し、継続メソッドとしてオブジェクトＢ（メソッドＢ２（B::B2））を指定した場合］
の順に説明する。
【００２３】
その後、「タグを使った通信機構の本発明方法での実現事例」についての詳細を述べる。本実施の形態では、上記「タグを使った通信機構の本発明方法での実現事例」として、
［フューチャ（Future）、コンティネーション（Continuation）、タグ（Tag）］
［タグＩＤの管理方式と当該タグＩＤを配送するオブジェクト（Deliverer）］
［異なるメタスペース間通信の実際］
の順に説明する。
【００２４】
最後に「他に考えられる些細な点で他に異なる方式」について述べる。本実施の形態では、上記「その他に考えられる実現方式」として、
［タグＩＤでタグの型を認識する方式］
［タグの管理方式］
の順に説明する。
【００２５】
先ず、上記本発明方法における「異なる通信機構の具体的な例」の場合の説明を行う。
【００２６】
本章では、「異なる通信機構の具体的な例」として、本発明のデータ通信方法におけるオブジェクト間通信の具体的な仕様と実現方式について述べる。本章に続く本発明の具体的な事例では、本章で述べる二つの異なる（通信機構を提供している）環境間でのオブジェクト間通信の実現方式を説明する。
【００２７】
［メタスペース（mLocal）通信機構］
上記メタスペース（mLocal）は上記フューチャ（Future）を基本にした通信機構をサポートした環境（オブジェクト間通信機構）である。このメタスペース（mLocal）はアプリケーションを記述するためのものである。メタスペース（mLocal）通信機構の仕様のうち、インターフェースについては後述する。
【００２８】
ここでは、メタスペース（mLocal）通信機構を使ったオブジェクト間通信の基本的を動作について述べる。この通信機構の実現方式、説明で使用されるフューチャ（Future）が持つ属性については後に述べる。
【００２９】
図３と図４はメタスペース（mLocal）通信機構を使ったオブジェクト間通信の基本的な動作を示している。図３にはメタスペース（mLocal）通信機構において、ウェイトフォー（WaitFor）がリプライ（Reply）よりも先に実行された場合を示し、図４にはメタスペース（mLocal）通信機構においてリプライ（Reply）がウェイトフォー（WaitFor）よりも先に実行された場合を示している。これら図３、図４ともにＡ、Ｂはオブジェクト、A::A1、B::B1はそれぞれオブジェクトＡのメソッドＡ１、オブジェクトＢのメソッドＢ１、縦の実線矢印はメソッドの実行、縦の破線矢印はメソッドの待ち状態、斜めの実線矢印はメッセージの配送を示している。なお、上記ウェイトフォー（WaitFor）は、メタスペース（mLocal）におけるＡＰＩ（Application Programming Interface）の一つであり、本実施の形態ではオブジェクトＡがオブジェクトＢの結果を待つ場合に用いられる。当該ウェイトフォー（WaitFor）には、その引数として後述するフューチャＩＤ（futureID）、上記リプライ（Reply）から送られた返答メッセージ（&msg）及びそのサイズ（sizeof(msg)）を備える。なお、上記リプライ（Reply）は、メタスペース（mLocal）におけるＡＰＩの一つであり、本実施の形態ではオブジェクトＢがオブジェクトＡの返答する場合に用いられる。当該リプライ（Reply）には、その引数としてメソッドＢ１の実行結果として得られる返答メッセージ（msg）及びそのサイズ（sizeof(msg)）を備える。
【００３０】
また図３、図４ともに、オブジェクトＡがオブジェクトＢにメッセージを送信し、その返答を受け取る例である。はじめにオブジェクトＡはオブジェクトＢにセンド（ Send）を使ってメッセージを送信する。メソッドＢ１（B::B1）はこれによって起動するメソッドであり、図中msgは配送されるメッセージ（のポインタ）である。これによって、メソッドＢ１（B::B1）が起動される。メソッドＡ１（A::A1）、メソッドＢ１（B::B1）は並行に動作する。このとき、メソッドＡ１（A::A1）のウェイトフォー（Waitfor）とメソッドＢ１（B::B1）のリプライ（Reply）のどちらが先に実行されるかという保証はない。なお、センド（Send）とは、メタスペース（mLocal）におけるＡＰＩの一つであり、本実施の形態ではメイルの送信を行う場合に用いられる。当該センド（Send）には、その引数として宛先（Ｂ）と選択メソッド（Ｂ１）、メッセージ（msg）及びそのサイズ（sizeof(msg)）とフューチャＩＤ（&futureID）とを備える。
【００３１】
オブジェクトＡがオブジェクトＢにメッセージ送信したとき、オブジェクトＡはフューチャＩＤ(futureID）を受け取る。このフューチャＩＤはＯＳ（オペレーティング・システム）がメッセージを配送する際にＯＳが内部的に生成する上記フューチャ（Future）と呼ばれる実体に対応するＩＤである。ここで、生成とはオブジェクトを構成する属性に必要なメモリの領域を確保すること及び当該属性を初期化することを示す。図５に示すように、アプリケーションソフトはＡＰＩを介してメイラ（例えば後述するメタオブジエクト（MLocalMailer））のオブジェクトや後述するスケジューラ（Scheduler）のオブジェクトに通信を行う。メイラの実行がオブジェクト内の実行コードに基づいてＣＰＵによって行われ、ＣＰＵはフューチャ（Future）に必要なメモリ領域をＯＳ領域内に確保する。フューチャＩＤ(futureID）はオブジェクトＡが後にこのメッセージの配送に対する返答を受け取るとき、どのメッセージ送信に対する返答メッセージの受信なのかを識別するために使われる。
【００３２】
図６はフューチャ（Future）の属性を示している。この属性としては、フューチャ（Future）を生成したオブジェクトを特定するためのＩＤ（ThreadID creator）、返答が済んでいるかどうかを調べるためのフラグ（bool isReplyDone）、返答メッセージがある場合にはこれを保存しておくための領域（ void* replyMessage ）が定義されている。例えば図３、図４の例ならば、ＩＤ（ThreadID creator）はオブジェクトＡが、返答メッセージ（void* replyMessage）にはメッセージ（msg）が保存される。
【００３３】
図３はウェイトフォー（Waitfor）がリプライ（Reply）よりも先に実行された場合を示しており、この場合、ウェイトフォー（Waitfor）の引数として上記フューチャＩＤ(futureID）を与える。このとき、指定されたフューチャＩＤ(futureID）に対する返答のための処理が行われていないので、メソッドＡ１（A::A1）の実行は待ち状態になる。その間、メソッドＢ１（B::B1）は処理を続け、返答のための手続きをするときリプライ（Reply）を実行する。リプライ（Reply）が実行されると、ＯＳがメソッドＢ１（B::B1）を起動するときに生成したフューチャ（Future）の状態を観察する。この場合、ＯＳはそのフューチャ（Future）に対して待ち状態のメソッドがあることを知ることができるので、ここでメソッドＡ１（A::A1）を再び実行状態に戻す。その後、メソッドＡ１（A::A1）、メソッドＢ１（B::B1）は再び並行に動作する。
【００３４】
一方、図４はリプライ（Reply）がウェイトフォー（Waitfor）よりも先に実行された場合を示している。リプライ（Reply）が実行されたとき、ＯＳがメソッドＢ１（B::B1）を起動するときに生成したフューチャ（Future）の状態を観察する。この場合、ＯＳはそのフューチャ（Future）に対応したメッセージの送信者（この場合はオブジェクトＡ）はまだ待ち状態にないことを知ることができるので、フューチャ（Future）に返答済みである印を付ける。メソッドＢ１（B::B1）はそのまま残り部分の実行を続ける。メソッドＡ１（A::A1）がメソッドＢ１（B::B1）からの返答を必要としたとき、メソッドＡ１（A::A1）はウェイトフォー（Waitfor）の引数としてフューチャＩＤ(futureID）を与える。この場合、指定されたフューチャＩＤ(futureID）に対する返答のための処理がすでに行われているので、メソッドＡ１（A::A1）は実行を継続することができる。
【００３５】
このように、フューチャ（Future）は並行動作している二つのオブジェクトの同期を取るための仲介的な役割を果たしている。メタスペース（mLocal）通信機構の仕様では、メッセージの送信側はどのメッセージに対する返答待ちかを明示的に示す必要があるので、フューチャＩＤ(futureID）によってフューチャ（Future）を特定する。メッセージの受信側はどの送信者に対する返信なのかを意識する必要がないように定めているので、フューチャＩＤ(futureID）は明示的に現れていない。
【００３６】
［メタスペース（mDrive）通信機構］
メタスペース（mDrive）はコンティネーション（Continuation）を基本にした通信機構をサポートした環境である。このメタスペース（mDrive）はデバイスドライバを記述するためのものである。
【００３７】
ここでは、メタスペース（mDrive）通信機構を使ったオブジェクト間通信の基本的な動作について述べる。この通信機構の実現方式、説明で使用されるコンティネーション（Continuation）が持つ属性や状態遷移などの詳細は後述する。
【００３８】
図７はメタスペース（mDrive）通信機構を使ったオブジェクト間通信の基本的な動作を示している。図３、図４と同様にＡ、Ｂはともにオブジェクト、A::A1、A::A2及びB::B1はそれぞれのオブジェクトＡ、ＢのメソッドＡ１、Ａ２、Ｂ１、縦の実線矢印はメソッドの実行、斜めの実線矢印はメッセージの配送を示している。
【００３９】
オブジェクトＡはセンド（Send）を使ってオブジェクトＢにメッセージを送信する。図７の例ではオブジェクトＢのメソッドＢ１（B::B1）にメッセージ（msg）を配送する。このとき、オブジェクトＡはセンド（Send）に対して５番目の引数として継続メソッド（Ａ２）を、さらに６番目の引数として継続メッセージ（contMsg）を与える。このときのメソッドＡ２（A::A2）は、メソッドＡ１（A::A1）の処理が終了した後、メソッドＢ１（B::B1）からの返答を受け取って処理を継続するメソッドである。また、このときのメッセージ（contMsg）は、継続メソッド（Ａ２）の処理を補助するためのメッセージで、メソッドＡ１（A::A1）が継続メソッドＡ２（A::A2）に渡す内容を含んだメッセージである。
【００４０】
ＯＳは継続メソッド、継続メッセージを含む上記コンティネーション（Continuation）と呼ばれる実体を内部に生成する。ここでのコンティネーション（Continuation）の生成は前記図５での説明で述べたフューチャ（Future）の例と同様、後述するメタオブジエクト（MDriveMailre）等のメイラオブジェクトの実行によりメモリ内にコンティネーション（Continuation）に必要な領域を確保する。
【００４１】
図８はコンティネーション（Continuation）の属性を示している。ここにはコンティネーション（Continuation）を生成したオブジェクトを特定するためのＩＤ（Thread IDcreator）、継続メソッド（Selector method）、継続メッセージ（void*message）を格納する領域が定義されている。このコンティネーション（Continuation）の属性は、図８に示されており、コンティネーション（Continuation）を生成したオブジェクトを特定するためのＩＤ（ThreadID creator）、選択される継続メソッド（Selector method）及び継続メッセージ（void* Message）を保存する領域が定義されている。図７の例ではセンド（Send）により、オブジェクトＡ、メソッドＡ２、メッセージ（contMsg）が送られると、ＯＳがコンティネーション（Continuation）を生成し、ＩＤ（ThreadID creator）にはオブジェクトＡ、継続メソッド（Selector Method）にはメソッドＡ２、及び継続メッセージ（void* Message）にはメッセージ（contMsg）が保存される。
【００４２】
メソッドＢ１（B::B1）はメソッドＡ１（A::A1）から配送されたメッセージの内容の他、そのコンティネーション（Continuation）を特定するためのＩＤとしてＯＳにより生成されたコンティネーションＩＤ（ContID）を受け取る。図７の例では、contIDとして受け取っている。このコンティネーションＩＤ（ContID）はキック（Kick）の引数として使われる。なお、キック（Kick）とはメタスペース（mDrive）におけるＡＰＩの一つであり、本実施の形態ではコンティネーションＩＤ（ContID）をオブジェクトＡに与えることでコンティネーション（Continuation）の中味の情報を得る際に用いられる。このキック（Kick）には、その引数として上記コンティネーションＩＤ（ContID）を備える。メタスペース（mDrive）のオブジェクトはコンティネーション（Continuation）をキック（Kick）することで、コンティネーション（Continuation）に含まれる情報を意識せずに継続メソッドを起動することができる。図７の例では、メソッドＢ１（B::B1）は受け取ったコンティネーションＩＤ（contID）をそれ自身がキック（Kick）し、これによりメソッドＡ１（A::A1）が指定した継続メソッドＡ２（A::A2）が起動され、メソッドＢ１の結果と継続メッセージ（contMsg）が渡される。
【００４３】
このように、コンティネーション（Continuation）は、メッセージを受信したオブジェクトが、誰がメッセージを送信したのか、あるいはどこに返答を送信すればよいのかを意識することなく、継続メソッドを起動できる（そのときに、返答を送信することができる）。メタスペース（mDrive）通信機構の仕様では、コンティネーションＩＤ（ContID）はＯＳがメッセージの受信側にメッセージと共に配送するので、送信側にはコンティネーションＩＤ（ContID）は現れない。
【００４４】
［メタスペース（mLocal）通信機構とメタスペース（mDrive）通信機構の比較］
メタスペース（mLocal）通信機構の仕様において、メソッドの実行の並行性は、あるメソッドの開始から終了までの間にのみ存在する。このセマンティクスは並行性は高くないが（メタスペース（mDrive）通信機構の仕様に比べて）、プログラマが直感的に理解しやすい、記述しなければならないコードの量を少なくし易いなどの利点がある。しかし、この仕様では、割込みを使ったデバイスドライバのような非同期な事象を効率的に記述することができない。
【００４５】
メタスペース（mDrive）通信機構の仕様では、メソッドを一度終了した後の継続メソッドを指定することができる。割込みのような非同期な事象に対応して返答を送信するとき、コンティネーション（Continuation）をキック（Kick）することによってあらかじめ指定された継続メソッドを起動できる。そのため、デバイスドライバのような非同期な事象を処理するプログラムを効率的に記述することができる。これは並行性の高いプログラムを記述できるが（メタスペース（mLocal）通信機構の仕様に比べて）、プログラマが直感的に理解し難い、記述しなければならないコードの量が多くなり易いなどの欠点がある。
【００４６】
[本発明方法における通信機構の実現方式］
本発明方法では、メタスペースが提供する機能は、メタスペースを構成するオブジェクトによって実現する。このようなオブジェクトを、メタスペースが提供する機能を使うオブジェクトに対して特にメタレベルオブジェクト、またはメタオブジエクトと呼ぶ。一方、メタスペースが提供する機能を使うオブジェクトをベースレベルオブジェクト、またはベースオブジェクトと呼ぶ。
【００４７】
各メタスペースに共通な機能を提供するオブジェクトとして（これから説明を進める各通信機構を実現するための構成要素として）、例えばスケジューラ（Scheduler）と呼ぶものを用いることができる。スケジューラ（Scheduler）はオブジェクトの状態を管理するメタオブジェクトである。本実施の形態で必要になるスケジューラ（Scheduler）の仕様は後述する。
【００４８】
一方、メタスペース（mLocal）とメタスペース（mDrive）の通信機構はそれぞれのメタスペースで異なる機構なので、それを実現するための機能を提供するメタオブジエクトは、それぞれに定義することができる。ここでは、メタスペース（mLocal）通信機構にてメッセージの配送を実現するメタオブジエクトをメタオブジエクト（MLocalMailer）、メタスペース（mDrive）通信機構にてメッセージの配送を実現するメタオブジエクトをメタオブジエクト（MDriveMailer）と呼ぶ。
【００４９】
メタスペース（mLocal）通信機構はメタオブジエクト（MLocalMailer）、スケジューラ（Scheduler）、そしてそれらの実行を支援する他のモジュールによって実現される。また、メタスペース（mDrive）通信機構はメタオブジエクト（MDriveMailer）、スケジューラ（Scheduler）、そしてそれらの実行を支援する他のモジュールによって実現される。ここではメタオブジエクト（MLocalMailer）とスケジューラ（Scheduler）、メタオブジエクト（MDriveMailer）とスケジューラ（Scheduler）の関係にシナリオを与え、各通信機構の実現方式を示す。また、それぞれフューチャ（Future）とコンティネーション（Continuation）の属性を与え、シナリオによってそれらの状態遷移を示す。
【００５０】
［フューチャ（Future）とメタスペース（mLocal）通信機構の実現方式］
図９から図１２はメタオブジエクト（MLocalMailer）とスケジューラ（Scheduler）の関係をシナリオ（フローチャート）によって与える。
【００５１】
図９はメタスペース（mLocal）のセンド（Send）の手続きを示している。
【００５２】
この図９において、先ずメタスペース（mLocal）上のベースオブジェクトがセンド（Send）を実行すると、メタスペース（mLocal）を構成する通信機構のためのメタオブジェクト（MLocalMailer）に処理が移ると共にベースオブジェクトはステップＳＴ７のようにウェイト（Wait）の状態となる。ここで、ベースオブジェクトからメタオブジエクトへ処理の状態が移ることを、以下にＭ（Meta Computation）と表現する。
【００５３】
このように処理が移ると、メタオブジエクト（MLocalMailer）は、ステップＳＴ１として、フューチャ（Future）を生成する。
【００５４】
次に、ステップＳＴ２として、メッセージ（ActiveMessage）を配送する宛て先のオブジェクトのメッセージキュー（メッセージの並び）の状態を調べる。このとき、メッセージキューにメッセージがない場合（ＦＡＬＳＥ、偽）には、そのオブジェクトは休眠状態（スケジューラ（Scheduler）が管理している状態では休止（Dormant））なので、ステップＳＴ５として、スケジューラ（Scheduler）にメイクレディ（MakeReady）を発行（issue）してオブジェクトを実行可能状態（スケジューラ（Scheduler）が管理している状態ではレディ（Ready））にする。ここで簡単にメッセージキューについて解説する。図１３に示すように、ＣＰＵはオブジェクト内の１つのスレッドを実行する際、配送されたメッセージを利用する。メッセージキューはメッセージの並びを示し、メッセージキュー内のメッセージを順次利用するように構成される。なお、メイクレディ（MakeReady）はスケジューラ（Scheduler）にそのオブジェクトが実行可能とするために用いられるＡＰＩであり、上記レディ（Ready）は実行可能状態を、上記ドーマント（Dormant）はオブジェクトが休止状態であることを表す。上記ドーマント（Dormant）時は、オブジェクトが何も実行せずメッセージを受信できる状態を表す。メイクレディ（MakeReady）には、引数としてベースオブジェクトを特定する（Thread of base）（この実施の形態ではオブジェクトＢ）、宛先のメソッド（method）、メッセージ(msg）を持つ。よって、この実施の形態ではベースオブジェクトＢを指定してメソッドＢにメッセージ（msg）を送るように管理する命令をスケジューラ（Scheduler）に送ることになる。
【００５５】
一方、ステップＳＴ２において、メッセージキューにメッセージがある場合（ＴＲＵＥ、真）には、すでにそのメッセージが宛て先のオブジェクトに配送されて、そのオブジェクトが実行可能状態（レディ（Ready））、オブジェクトが実行状態（ランニング（RUNNING））なので、ステップＳＴ４として、メッセージキューの最後にそのメッセージを入れて終了する。このとき、メッセージ送信に対応したフューチャ（Future）を特定できるフューチャＩＤ(futureID）もあわせてメッセージキューで管理する。なお、これらの状態については後述する図２８にて説明する。
【００５６】
その後は、ステップＳＴ６で配送完了であることを示す返り値サクセス（sSuccess）をメタメッセージ（MetaMessage）に入れ、ベースオブジェクトに状態遷移を戻す。その後ベースオブジェクトはステップＳＴ８のように実行或いは実行可能状態となる。ここで、これ以降、メタオブジェクトからベースオブジェクトへ状態遷移が戻ることをＲ（Resume）と表す。上記メタメッセージ（MetaMessage）とは、メタスペース(mLocal）上のベースオブジェクトがセンド（Send）をするとき、当該センド（Send）に必要なパラメータ（引数）を持ったメッセージである。
【００５７】
なお、上述したＭ（Meta Computation），Ｒ（Resume）については、先に示した特願平８−６７８８１号の明細書及び図面に詳しく示されている。
【００５８】
図１０はメタオブジエクト（MLocalMailer）によるリプライ（Reply）に関する手続きを示している。
【００５９】
この図１０において、初めにステップＳＴ１１として、メタオブジエクト（MLocalMailer）はどのベースオブジェクトがリプライ（Reply）してきたのかを確認する。図３、図４の例で言えば、ベースオブジェクトＢがリプライ（Reply）を発行（issue）することが確認される。なお、この確認として、本実施の形態ではＡＰＩの例えば関数GetLast()を使うようにしているが、ここではどのような方法でもよい。またこのときのベースオブジェクトはステップＳＴ２４のようにウェイト（Wait）の状態となる。
【００６０】
次に、ステップＳＴ１２からステップＳＴ１４として、このベースオブジェクトを起動したときに一緒に配送されたフューチャＩＤ(futureID）が特定するフューチャ（Future）が本当にメタスペース（mLocal）のフューチャ（Future）かどうか確認する。ステップＳＴ１２，ＳＴ１４で偽と判断されたらエラーとし、ステップＳＴ２２へ進む。ステップＳＴ１３が偽のときは、本実施の形態の主題であるタグを使った通信機構で他のメタスペースと通信する場合に相当し、後述するメタオブジェクト（Deliverer）に処理を依頼する。
【００６１】
ステップＳＴ１２からステップＳＴ１４において、そうであることが確認されたら、ステップＳＴ１５として、そのフューチャ（Future）の属性（creator）の状態を調べる。このとき、属性（creator）はリプライ（Reply）をしたベースオブジェクトにメッセージを送ったオブジェクトを含み、図３、図４の例で言えばリプライ（Reply）をしたベースオブジェクトＢにメッセージを送ったオブジェクトはＡであり、領域（ThreadID Creator）に保存されている。
【００６２】
次に、ステップＳＴ１６として、そのオブジェクトが待ち状態（ウェイト（Wait））になっているかどうかを調べ、そのオブジェクトが待ち状態（ウェイト（Wait））になっている場合は、ステップＳＴ１７のようにそのオブジェクトがウェイトフォー（WaitFor）を実行している場合である。ウェイトフォー（WaitFor）の実行は前に図３、図４の説明で述べているように、引数としてフューチャＩＤ（futureID）、返答メッセージ（&msg）、サイズ（sizeof(msg)）を有し、いま扱っているフューチャＩＤ（futureID）とウェイトフォー（WaitFor）に与えられたフューチャＩＤ（futureID）は等しく、リプライ（Reply）により送られたメッセージ(msg）が引数（&msg）に与えられる。待ち状態のオブジェクトは前記メイクレディ（MakeReady）によって再び実行可能状態になる。つまり、図３、図４の例では、オブジェクトＡが実行可能状態に復帰する。
【００６３】
なお、この場合の宛先のメソッドはウェイト（wait）状態なので、指定は不要だからUNDEF（undefine）、メッセージ（msg）も不要なのでＮＵＬＬとされている。
【００６４】
一方、ステップＳＴ１６において、属性（creator）が待ち状態でない場合は、まだウェイトフォー（Waitfor）を実行していない。したがってこのとき、メタオブジエクト（MLocalMailer）は、ステップＳＴ１９としてフューチャ（Future）の属性（isReplyDone）をセットし、リプライ完了のマークを入れる。さらに必要に応じてステップＳＴ１８のようにメッセージ（message）に返答メッセージを一時的に保存する。
【００６５】
その後は、ステップＳＴ２０にてフューチャ（Future）を削除し、さらにステップＳＴ２１では配送完了の返り値サクセス（sSuccess）をメタメッセージ（MetaMessage）に入れ、ステップＳＴ２２ではエラーを示す返り値をメタメッセージ（MetaMessage）に入れ、ステップＳＴ２３では配送完了の返り値サクセス（sSuccess）をメタメッセージ（MetaMessage）に入れる。その後ベースオブジェクトはステップＳＴ２５のように実行或いは実行可能状態となる。
【００６６】
図１１と図１２はウェイトフォー（WaitFor）の手順であり、図１１はリプライ（Reply）がウェイトフォー（WaitFor）よりも先に実行された場合（図４の場合）、図１２はその逆（図３の場合）を示している。これらは図１０の説明に対応している。なお、これ以降、ベースオブジェクトの流れは図示を省略する。
【００６７】
図１１において、初めにステップＳＴ３１ではフューチャ（Future）の確認を行い、ステップＳＴ３２ではフューチャ（Future）の属性（isReplyDone）がセットされている（リプライ（Reply）が既に行われている）かどうかの確認を行う。これらステップＳＴ３１、ＳＴ３２にて共に真（ＴＲＵＥ）とされた時には、ステップＳＴ３３にてフューチャ（Future）内にセットされた結果、メッセージをウェイトフォー（WaitFor）のメッセージ（&msg）に入力し、その後は、ステップＳＴ３４にてフューチャ（Future）を削除し、さらにステップＳＴ３５では配送完了のサクセス（sSuccess）をメタメッセージ（MetaMessage）に入れる。ステップＳＴ３１で偽と判断されたら、ステップＳＴ３６ではエラーコードをメタメッセージ（MetaMessage）に入れ、Ｒ（Resume）を行う。なお、ステップＳＴ３２で偽と判断されたら、図１２に示すステップＳＴ４３へ移行する。
【００６８】
一方、図１２において、初めにステップＳＴ４１ではフューチャ（Future）の確認を行い、ステップＳＴ４２ではフューチャ（Future）の属性（isReplyDone）がセットされていないかどうかの確認を行う。これらステップＳＴ４１、ＳＴ４２にて共に真（ＴＲＵＥ）とされた時には、ステップＳＴ４３にて待ち状態となされ、その後、ステップＳＴ４４ではサクセス（sSuccess）をメタメッセージ（MetaMessage）に入れ、ステップＳＴ４５ではメタコール（MetaCall）を終了する。ステップＳＴ４１にて偽と判断されたらステップＳＴ４６にてエラーコードをメタメッセージ（MetaMessage）に入れ、Ｒ（Resume）を行う。ステップＳＴ４２にて偽と判断されたら図１１のステップＳＴ３３へ移行する。なお、図１１、図１２の例は共にベースオブジェクトがメタオブジエクト（MLocalMailer）にウェイトフォー（WaitFor）を依頼し、Ｒ（Resume）されるまでウェイト（Wait）の状態となる（図示せず）。
【００６９】
［コンティネーション（Continuation）とメタスペース（mDrive）通信機構の実現方式］
図１４から図１８にはメタオブジエクト（MDriveMailer）とスケジューラ（Scheduler）の関係をシナリオによって与える。メタオブジエクト（MDriveMailer）はデバイスドライバのためのメタスペースなので、その手続きは前記メタオブジエクト（MLocalMailer）に比べてやや複雑である。その一つに遅延実行テーブル（DelayedExecutionTable）がある。メタオブジエクト（MDriveMailer）においてセンド（Send）やキック（Kick）の手続きは、メタスペース(mDrive）上のオブジェクトがセンド（Send）やキック（Kick）を依頼したときに、遅延実行テーブル（DelayedExecutionTable）への登録だけが行われ、実際のメッセージの配送は、メソッドの終了時（Exitするとき）にまとめて行われる。
【００７０】
図１４はメタオブジエクト（MDriveMailer）におけるセンド（Send）の手続きを示す。
【００７１】
この図１４において、ステップＳＴ５１では、すでに述べたようにセンド（Send）の処理を遅延実行テーブル（DelayedExecutionTable）に登録する。すなわち、当該テーブルにメタメッセージ内の遅延実行用引数を登録する。ここでは、メタスペース(mDrive）上のベースオブジェクトがセンド（Send）をするとき、センド（Send）に必要なパラメータが入った実体としてのメタメッセージ（MetaMessage）が遅延実行テーブル（DelayedExecutionTable）に登録される。その後、ステップＳＴ５２ではサクセス（sSuccess）をメタメッセージ（MetaMessage）に入れ、Ｒ（Resume）を行う。
【００７２】
ここで、上述のメタメッセージ（MetaMessage）の構成について簡単に説明する。
【００７３】
メタメッセージ（MetaMessage）は図１９に示すように、２つの領域に分かれ、メタコール（metacall）のＡＰＩを実行するために必要な情報（例えば引数）のための領域Ａとエラー用コードを納める領域Ｂとを有する。なお、遅延実行テーブル（DelayedExecutionTable）は前記図５で示したフューチャ（Future）の生成と同じく、メイラ(mailer）のオブジェクトがメモリ内に当該テーブル用の領域を確保することで生成される。
【００７４】
図１５は、メタオブジエクト（MDriveMailer）におけるキック（Kick）の手続きである。
【００７５】
この図１５において、ステップＳＴ６１では、図１４と同様にキック（Kick）の処理を遅延実行テーブル（DelayedExecutionTable）に登録する。その後は、ステップＳＴ６２にてサクセス（sSuccess）をメタメッセージ（MetaMessage）に入れ、Ｒ（Resume）を行う。
【００７６】
図１６はメタオブジエクト（MDriveMailer）の終了時（Exit）で、メタスペース(mDrive）上のベースオブジェクトが処理を終了するときに呼び出される手続きである。ここでは、遅延実行テーブル（DelayedExecutionTable）に登録された手続きを、処理の依頼された順序で実行し、最後にオブジェクトのメソッドの終了手続きをする。
【００７７】
この図１６のおいて、初めにステップＳＴ７１として、終了（Exit）の手続きを依頼したベースオブジェクトを特定する（例えば関数GetLast()を使って特定する）。
【００７８】
次に、ステップＳＴ７２にて当該ベースオブジェクトが割込みによって起動されたかどうかを調べる。すなわち、終了（Exit）メソッドが起動された原因がベースオブジェクトの割り込みによるものか判断する。割り込みで起動された場合、その割り込みの前に更に別の割り込みが生じていた可能性が考えられる。図２０に示すように、ベースオブジェクトＩの実行中にベースオブジェクトＩＩが割り込んだ場合、ステップＳＴ７３では今回の終了（Exit）が当該ベースオブジェクトＩＩの割り込みの終了（Exit）か否かを判断する。ステップＳＴ７２、ステップＳＴ７３にて共に真（ＴＲＵＥ）であると判断された場合は、ステップＳＴ７４にて上記別の割り込みに戻る（Resume Interrupt）。また、ベースオブジェクトＩが割り込みによって起動されたものではないとき（ステップＳＴ７２：偽）、ステップＳＴ７３は偽である。このように、ステップＳＴ７２およびステップＳＴ７３で偽と判断されたら、ステップＳＴ７５のように、遅延実行テーブル（DelayedExecutionTable）に登録された手続きを処理する。この処理について、センド（Send）については後述する図１７、キック（Kick）については後述する図１８が示している。
【００７９】
上記ステップＳＴ７５の遅延実行テーブル（DelayedExecutionTable）のための処理を終えると、ステップＳＴ７６にて再びそのベースオブジェクトが割込みで起動されたかどうか調べる。このステップＳＴ７６は、ステップＳＴ７２と実質的に同じである。ここで、もし割込みで起動されている場合は、ステップＳＴ７７にて、そこから復帰するための手続き（ExitFromInterrupt（））を実行して最初の割り込みを終了する。一方、割り込みで起動されていない場合は通常のオブジェクト間通信で起動された場合である。この場合、それまで実行していたオブジェクトを休眠状態にするために、ステップＳＴ７８にて遅延実行テーブル（DelayedExecutionTable）を初期化し、スケジューラ（Scheduler）に休止（MakeDormant）するようにメッセージを送る。引数（BaseThread）はステップＳＴ７１で特定されたベースオブジェクトである。さらに、ステップＳＴ７９にて、そのベースオブジェクトのメッセージキューからそれまで実行していたメッセージを取り除く。
【００８０】
ここでメッセージキューが空になった場合はそれで終了である。もしもメッセージキューが空ではなかった場合には、次に配送されるべきメッセージを引数にして、スケジューラ（Scheduler）に（再び、そのオブジェクトが引数で与えられるメッセージによって起動されるように）メイクレディ（MakeReady）を発行（issue）し、次のメッセージのためにそのオブジェクトを実行可能状態（Ready）にする。
【００８１】
次に、図１７と図１８には、遅延実行テーブル（DelayedExecutionTable）に登録された手続きの一つを処理するシナリオを示す。当該テーブルに例えば１０個が発行されれば１０回実行が行われる。メッセージの有無によるスケジューラ（Scheduler）への依頼事項はメタオブジエクト（MLocalMailer）の場合と同じである。
【００８２】
図１７におけるメタオブジエクト（MDriveMailer）のセンド（Send）の場合は、先ず、ステップＳＴ８１にてコンティネーション（Continuation）を生成する。
【００８３】
次のステップＳＴ８２にてメッセージの宛先がメタスペース(mDrive）オブジェクトか判断する。もし偽であれば、後述するメタオブジエクト（Deliverer）に処理の依頼を行わない、タグ通信が行われる。ステップＳＴ８３ではメッセージ（ActiveMessage）を配送する宛て先のオブジェクトのメッセージキューの状態を調べる。このとき、メッセージキューにメッセージがない場合には、そのオブジェクトは休眠状態（スケジューラ（Scheduler）が管理している状態では休止（Dormant））なので、ステップＳＴ８５として、スケジューラ（Scheduler）にメイクレディ（MakeReady）を発行（issue）してオブジェクトを実行可能状態（スケジューラ（Scheduler）が管理している状態ではレディ（Ready））にする。メッセージキューにメッセージが存在しない状態になると、ステップＳＴ８４として、配送メッセージとコンティニュエーションをメッセージキューに格納する。
【００８４】
一方、ステップＳＴ８２及びステップＳＴ８３において、真の場合には、すでにそのメッセージが宛て先のオブジェクトに配送されて、そのオブジェクトが実行可能状態、実行状態（RUNNING）、または実行中断状態（Suspend）なので、ステップＳＴ８４として、メッセージキューの最後にそのメッセージを入れて終了する。このとき、メッセージ送信に対応したコンティネーション（Continuation）或いはそれを指し示すＴＩＤ（後述する）もあわせてメッセージキューで管理する。
【００８５】
図１８におけるメタオブジエクト（MDriveMailer）のキック（Kick）の場合は、ステップＳＴ９１において、与えられたコンティネーション（Continuation）がメタオブジエクト（MDriveMailer）のコンティネーション（Continuation）なのかどうかを確認する。ステップＳＴ９１が真の場合はステップＳＴ９２にてコンティネーション（Continuation）の存在を確認する。このコンティネーションが確認されたら、ステップＳＴ９３で当該コンティネーション（Continuation）を開き、コンティネーション内の属性（宛先、メソッド、メッセージ（msg））をチェックし、それに基づいてセンド（Send）を行う。次のステップＳＴ９４にてメッセージの確認を行い、ステップＳＴ９５では、メッセージキューの最後にそのメッセージを入れて終了する。このとき、メッセージ送信に対応した後述するタグＩＤ(TID）もあわせてメッセージキューで管理する。
【００８６】
一方、ステップＳＴ９２、ＳＴ９４にて、偽である場合は、ステップＳＴ９６にてスケジューラ（Scheduler）にメイクレディ（MakeReady）を発行してオブジェクトを実行可能状態にする。そして、ステップＳＴ９５として、メッセージキューにメッセージとメッセージ送信に対応したタグＩＤ（ＴＩＤ）とを格納する。なお、ステップＳＴ９４、ＳＴ９５、ＳＴ９６は、図１７のステップＳＴ８３、ＳＴ８４、ＳＴ８５と同様の機能である。ステップＳＴ９１で偽と判断されたら、後述するタグを使った通信機構で他のメタスペースと通信する場合に相当し、メタオブジェクト（Deliverer）に処理の依頼を行う。
【００８７】
「タグを使った通信機構の基本的な説明」
オブジェクト間通信をするには、単純なメッセージ送信の他に、返答を受け取ったり他のメソッドの実行と同期をとることが必要になる。このとき、フューチャ（Future）やコンティネーション（Continuatin）のようなものが必要になる。このような複数のオブジェクト間通信（本実施の形態ではフューチャやコンティネーション等）で必要とされる同期や並行性を制御するデータ構造を本実施の形態ではタグと呼ぶ。ここでいうデータ構造とは例えばＣ言語やＰＡＳＣＡＬでいうところのStructureやＣ＋＋でいうClassのような構造を示す。このタグとは異なるデータ構造をある共通のデータ構造で関連付けるものであり、この共通のデータ構造はこれらの異なるデータ構造を区別するための識別子（属性：例えばExecSpaceID mailer）を含むように構成される。さらに、同種類のデータ構造間の区別を与えるための識別子（属性：例えばlongword timeStamp）を有することでより多くのデータ構造が管理できる。詳細は図２１の説明時に行う。また、タグを識別するために必要なＩＤをタグＩＤ（TID）と呼ぶ。
【００８８】
ここで、タグの属性としてタグの型が必要になる。タグの型はそのタグがどの環境で使われるどのようをものかを特定できる必要がある。ただし、タグの型はグローバルに認識ができるものである必要はない。ある環境でそのタグの型を特定できなかった場合には、そのタグの型を特定できる他の独立したオブジェクトに問い合わせなどを行なうことでそれを解決することができればよい。
【００８９】
ここでは、メタスペース（mLocal）とメタスペース（mDrive）におけるフューチャ（Future）、コンティネーション（Continuation）の例を使って、タグを使った異なるメタスペース間の通信について述べる。本実施の形態の例では、メタスペース（mLocal）にオブジェクトＡ、メタスペース(mDrive）にオブジェクトＢが存在し、それぞれ前述同様に、以下のようなメソッドが定義されているとする。
【００９０】
オブジェクトＡ
メソッドＡ１（A::A1）
オブジェクトＢ
メソッドＢ１（B::B1）
メソッドＢ２（B::B2）
このとき、以下の二通りについて、タグを使った異なるメタスペース間通信の基本的な動作について述べる。
【００９１】
１．オブジェクトＡ（メソッドＡ１（A::A1））がメソッドＢ１（B::B1）にセンド及びウェイトフォー（Send＋WaitFor）する場合
２．オブジェクトＢ（メソッドＢ１（B::B1））がメソッドＡ１（A::A1）にセンド（Send）し、継続メソッドとしてメソッドＢ２（B::B2）を指定した場合
［オブジェクトＡ（メソッドＡ１（A::A1））がメソッドＢ１（B::B1）にセンド及びウェイトフォー（Send＋WaitFor）する場合］
メソッドＡ１（A::A1）はセンド（Send）（オブジェクトＢ，メソッドＢ1，メッセージ（mag）,関数sizeof(msg)，フューチャＩＤ(&futureID））を実行する。このとき、実際にこの手続きを処理するメタオブジエクト（MLocalMailer）はフューチャ（Future）を生成する。フューチャ（Future）は次の要件を満たしていればよい。すなわち、
フューチャ（Future）がタグＩＤで特定できるユニークな実体であること、
タグの型がメタスペース（mLocal）のフューチャ（Future）であることを示すこと、及び
図６で示したフューチャ（Future）の属性を持っていること。
【００９２】
メタオブジエクト（MLocalMailer）は、なんらかの方法でメタオブジエクト（MDriveMailer）にメッセージ（msg）をオブジェクトＢまで配送するように依頼すると共に、メソッドＢ１（B::B1）を起動するように依頼をする。このとき、フューチャ（Future）を特定することができるタグＩＤをあわせて配送する。また、このときオブジェクトＡはそのフューチャ（Future）を後に特定することができるようにフューチャＩＤ(futureID）を受け取る。ここではその型の変数をフューチャＩＤ(futureID）としている。このＩＤは、タグＩＤをメタスペース（mLocal）の仕様にあわせてマップしたものであると考えられる。
【００９３】
オブジェクトＢは、そのメッセージ（msg）によってメソッドＢ１（B::B1）が起動されたとき、そのメッセージがどこから配送されたかを知ることはできない（或いは知るべきではない）。これが透明性のあるオブジェクト間通信の実現で要求される。メソッドＢ１（B::B1）は起動されるときに、コンティネーション（Continuation）がメッセージ（msg）といっしょに配送される。コンティネーション（Continuation）は型（コンティネーションＩＤ（contID））として扱い、ここではその変数を（contID）とする。この変数（contID）は先のフューチャＩＤ(futureID）と同じタグを特定していることになる。
【００９４】
メソッドＢ１（B::B1）の実行が進むとキック（Kick（contID））を実行する。このとき、メタオブジエクト（MDriveMailer）はコンティネーションＩＤ（変数contID）で特定できるタグの型をチェックする。このとき、タグＩＤの管理方式の観点から、次の二つの可能性がある。
【００９５】
１．メタオブジエクト（MDriveMailer）がコンティネーションＩＤ（contID）で特定できるタグの型をメタスペース（mLocal）のフューチャ（Future）であるとわかる場合（タグＩＤの管理方式（1））
２．メタオブジエクト（MDriveMailer）がコンティネーションＩＤ（contID）で特定できるタグの型を知ることができない場合（タグＩＤの管理方式（2））
前者の場合、メタオブジエクト（MDriveMailer）はなんらかの方法でメタオブジエクト（MLocalMailer）に直接タグＩＤを配送することができる。メタオブジエクト（MLocalMailer）はタグＩＤが配送されると、それはメタスペース（mLocal）上でリプライ（Reply()）が行われるのとまったく同じように処理を進めることができる。すなわち、タグＩＤ（＝フューチャＩＤ(futureID））に対応したフューチャ（Future）に対して、図１０で示したシナリオと同様にメソッドＡ１（A::A1）の実行を再開させたり、返答メッセージをフューチャ（Future）に一時的に保存しておくことができる。
【００９６】
後者の場合、タグＩＤをメタオブジエクト（MLocalMailer）に配送する方法として、次の方法が考えられる。
【００９７】
１．タグの型を管理している別のオブジェクトがあり、そのオブジェクトはタグＩＤを与えるとそのタグＩＤの型を調べ、そのタグを処理できるＡＰＩとしてのメイラ（Mailer）を教えてくれるメソッドを用意する。メタオブジエクト（MDriveMailer）はこのメソッドを利用して、そのタグＩＤをメタオブジエクト（MLocalMailer）に配送すればよいことを知ることができ、直接メタオブジエクト（MLocalMailer）にタグＩＤを配送する方法（タグＩＤの管理方式（2A））
２．タグの型を管理している別のオブジェクトがあり、そのオブジェクトは与えられたタグＩＤを直接それに対応したタグを処理できるメイラ（Mailer）に配送してくれる方法（タグＩＤの管理方式（2B））
これらの場合も、最終的にはメタオブジエクト（MLocalMailer）にタグＩＤが配送され、図１０で示したシナリオと同様にメソッドＡ１（A::A1）の実行を再開させたり、返答メッセージをフューチャ（Future）に一時的に保存しておくことができる。
【００９８】
[オブジェクトＢ（メソッドＢ１（B::B1））がメソッドＡ１（A::A1）にセンド（Send）し、継続メソッドとしてメソッドＢ２（B::B2）を指定した場合］
メソッドＢ１（B::B1）はセンド（オブジェクトＡ，メソッドＡ１，メッセージ（msg），関数（sizeof(msg)），メソッドＢ２、メッセージ（contMsg））を実行する。このとき、実際にこの手続きを処理するメタオブジエクト（MDriveMailer）はコンティネーション（Continuation）を生成する。コンティネーション（Continuation）は次の用件を満たすことになる。
【００９９】
コンティネーション（Continuation）がタグＩＤで特定できるユニークな実体であること、
タグの型がメタスペース（mDrive）のコンティネーション（Continuation）であることを示すこと、及び
図８で示したコンティネーション（Continuation）の属性を持っていること。
【０１００】
メタオブジエクト（MDriveMailer）を含むＯＳは、なんらかの方法でメタオブジエクト（MLocalMailer）にメッセージ（msg）をオブジェクトＡに配送し、メソッドＡ１を起動するように依頼する。このとき、コンティネーション（Continuation）を特定することができるタグＩＤをあわせて配送する。
【０１０１】
メタスペース(mDrive）の通常のオブジェクト間通信では、このタグＩＤはコンティネーションＩＤ（ContID）として扱われるものになる。しかし、この場合はメタオブジエクト（MLocalMailer）ではそれをコンティネーションＩＤ（ContID）として扱う必要はなく、タグＩＤとして扱う。そして、メタスペース（mLocal）の通常のオブジェクト間通信ではメッセージを配送してあるメソッドを起動すると、それにフューチャ（Future）（またはフューチャＩＤ(futureID））が関係付けられるのと同様に、メタオブジエクト（MDriveMailer）から配送されたタグＩＤが関係付けられる。
【０１０２】
メソッドＡ１（A::A1）の実行が進むとリプライ（Reply()またはReply（ReplyMsg））を実行する。このとき、メタオブジエクト（MLocalMailer）はメソッドＡ１（A::A1）を起動したときに関係付けられたタグＩＤを調べ、タグＩＤが特定するタグの型をチェックする。このとき、メタスペース（mLocal）上のオブジェクトＡからメタスペース(mDrive）上のオブジェクトＢに通信した場合と同様に、タグＩＤの管理方式の観点から、次の二つの可能性がある。
【０１０３】
１．メタオブジエクト（MLocalMailer）がタグＩＤで特定できるタグの型をメタスペース(mDrive）のコンティネーション（Continuation）であるとわかる場合（タグＩＤの管理方式（１））
２．メタオブジエクト（MLocalMailer）がタグＩＤで特定できるタグの型を知ることができない場合（タグＩＤの管理方式（２））
いずれの場合においても、メタスペース（mLocal）上のオブジェクトＡからメタスペース(mDrive）上のオブジェクトＢに通信した場合と同様、なんらかの方法でメタオブジエクト（MDriveMailer）にタグＩＤを配送できる。メタオブジエクト（MDriveMailer）はタグＩＤを受け取ると、図１８で示したシナリオと同様の手続きを行なう。すなわち、はじめにタグＩＤに対応したコンティネーション（Continuation）を開き（Open）し、継続メソッドと継続メッセージを得る。そして、継続メソッドを配送するべきオブジェクト（コンティネーション（Continuation）のクリエータ（creator））のメッセージキューの状態に応じて、スケジューラ（Scheduler）をアクセスし、最終的にメソッドＢ２（B::B2）を起動する。
【０１０４】
「タグを使った通信機構の本実施の形態での実現事例」
本章では、本実施の形態において、タグを使ってそれぞれメタスペース（mLocal）、メタスペース(mDrive）に存在するオブジェクトが透明性を持って通信することを可能にした実現方式について述べる。ここでは異なる通信機構としてメタスペース（mLocal）通信機構とメタスペース(mDrive）通信機構の二つのみが存在することを仮定する。
【０１０５】
［フューチャ（Future），コンティネーション（Continuation）とタグ（Tag）］
メタスペース（mLocal）におけるフューチャ（Future）、メタスペース(mDrive）におけるコンティネーション（Continuation）を、ＯＳではタグ（Tag）として扱うことが可能である。このとき、ＯＳはタグ（Tag）がフューチャ（Future）であるかコンティネーション（Continuation）であるかを識別する必要がある。それを識別するための型としてＡＰＩのメイラ（Mailer）のＩＤを使う。タグの型として使われるメイラＩＤ（MailerID）がメタオブジエクト（MLocalMailer）の場合にはフューチャ（Future）、メタオブジエクト（MDriveMailer）の場合にはコンティネーション（Continuation）であると認識することができる。
【０１０６】
図２１はタグ（Tag）とフューチャ（Future）、コンティネーション（Continuation）の関係、タグ（Tag）とタグＩＤ（TID）の関係をいわゆるＯＭＴ（object modeling technique）法のオブジェクトモデル図で示している。クラスフューチャＣ１と、クラスコンティネーションＣ２はクラスタグＣ３から派生したサブクラスとして定義できる。タグ（Tag）はメイラ（Mailer）を識別するＩＤとして実行場所ＩＤ（ExecSpaceID）を使っている。この場合、実行場所ＩＤ（ExecSpaceID）は、そのオブジェクトを示すＩＤと等価な意味で使われている。タグ（Tag）はタグＩＤ（TID）というＩＤによって特定できる。タグ（Tag）に含まれるタイムスタンプ（timeStamp）はタグ（Tag）をタグＩＤ（TID）を使って特定するとき時間軸に対してユニークであることを保証するために使用される。フューチャ（Future）およびコンティネーション（Continuation）を特定することができれば、タイムスタンプ（timeStamp）は必ずしも使われる必要はない。
【０１０７】
メタスペース（mLocal）通信機構、メタスペース(mDrive）通信機構ではそれぞれフューチャ（Future）、コンティネーション（Continuation）を特定するためにフューチャＩＤ(futureID）、コンティネーションＩＤ（ContID）が使われる。タグ（Tag）を導入した場合、ＯＳ内ではこれらはすべて共通に表記されることのできるタグＩＤ（TID）として特定することができる。
【０１０８】
本実施の形態では、プログラマがメタスペース（mLocal）やメタスペース(mDrive）を提供しているインターフェースをそのまま使用することができるように、インターフェースを定義しているへッダフアイル（MLocal.h、MDrive.h）では型の再定義が行われている。すなわち、メタスペース（mLocal）のへッダフアイル（MLocal.h）ではフューチャＩＤ(futureID）をタグＩＤに再定義する。これを例えばＣ言語やＣ＋＋の定義方法で示すと、typedef TID futureID；となる。なお、typedefは新しい型を定義（define）すると言う意味である。メタスペース(mDrive）のヘッダファイル（MDrive.h）のコンティネーションヘッダファイル（Cont.h）ではコンティネーションＩＤ（ContID）をタグＩＤに再定義している。これも同様に示すと、typedef TID ContID；となる。
【０１０９】
［タグＩＤの管理方式と当該タグＩＤを配送するオブジェクト（Deliverer）］
本実施の形態では、前記タグＩＤの管理方式（2B）を適用している。異なるメタスペース間の通信機構をサポートするメタオブジェクトとして、Delivererを導入する。オブジェクト（Deliverer）は主に二つのインターフェース（メソッド或いはＡＰＩ）を持つ。
【０１１０】
すなわち、その一つであるインターフェース（sError DeliverObject）は、メッセージ（msg）を指定されたオブジェクト（destination）（引数オブジェクトＩＤ（ＯＩＤ）及び宛先メソッド（sel）で示される。）に配送し、最終的にオブジェクト（destination）のメソッド（method）が起動されるよう、オブジェクト（destination）が存在するメタスペースのメイラ（Mailer）に依頼をする。このインターフェース（sError DeliverObject）は更に、引数の一つとして配送されるタグＩＤ（TID）を、オブジェクト（destination）が返答する場合に使用する。
【０１１１】
もう一方のインターフェース（sError DelivereTag）は、タグＩＤ（TID）を配送する。オブジェクト（deliverer）はタグＩＤ（TID）に対応したタグ（Tag）の型を調べ、どのメイラ（Mailer）にタグＩＤ（TID）を配送すればよいかを知る。必要に応じて、返答メッセージ（replyMsg）も配送する。
【０１１２】
相手先オブジェクト（destination）が存在するメタスペースのメイラ（Mailer）を知る方法としては、
１．オブジェクトの生成時にあらかじめオブジェクト（deliverer）に登録をして、オブジェクト（deliverer）がその内容を（テーブルなどを使って）管理する方法
２．オブジェクトから直接たどることができるデータ構造に、そのオブジェクトが所属しているメタスペースまたはメタスペースを識別できるなにかのＩＤを含めておく方法
が考えられる。本実施の形態では、後者の方法を使っている。
【０１１３】
［異なるメタスペース間通信の実際］
この異なるメタスペース間通信では、以下の二つの異なるメタスペース間通信（異なるメタスペースに存在するオブジェクト間通信）が考えられる。
【０１１４】
Ａ．メタスペース（mLocal）オブジェクトがメタスペース(mDrive）オブジェクトと通信する（或いは通信して返答を受け取る）場合
Ｂ．メタスペース(mDrive）オブジェクトがメタスペース（mLocal）オブジェクトに通信する（或いは通信して返答を受け取る）場合
図２２と図２３は、オブジェクト（deliverer）を介して異なるメタスペース（メタスペース（mLocal）とメタスペース(mDrive））間通信を行なう場合の前者Ａを、図２４と図２５は後者Ｂのシナリオを示している。
【０１１５】
図２２において、メタオブジエクト（MLocalMailer）がベースオブジェクトのセンド（Send）の手続きの依頼を受け付けてからフューチャ（Future）を生成する処理（ステップＳＴ１０１）までは、図９と同様である。但し、このフューチャ（Future）はタグのサブクラスとして生成される。
【０１１６】
ここで、ステップＳＴ１０２では、メッセージの配送先の確認を行い、メッセージの配送先がメタスペース（mLocal）オブジェクトではない場合、オブジェクト（Deliverer）のメソッド（DeliverObject）にメッセージを送る。
【０１１７】
オブジェクト（Deliverer）はメソッド（DeliverObject）の引数にてその配送先を知ることができるので、ステップＳＴ１０３のように、そのメイラ（MDriveMailer）にさらに配送する。ステップＳＴ１０６以降に示す、メタオブジエクト（MDriveMailer）がインターフェース（DeliverObject）を通じて配送依頼された後の手続き（ステップＳＴ１０６、ＳＴ１０７、ＳＴ１０８）は、前述した図１７のメタオブジエクト（MDriveMailer）が終了時（Exit）にセンド（Send）のために行なう手続き（ステップＳＴ８３、ＳＴ８４、ＳＴ８５）と同様である。但し、この場合はステップＳＴ１０７にてメッセージキューにタグＩＤ(TID）を加えるようになっている。
【０１１８】
図２３はメタスペース(mDrive）に配送されたタグＩＤ（TID）がメタスペース(mDrive）ではコンティネーションＩＤ（ContID）として扱われて、これをキック（Kick）した場合の手続きを示している。
【０１１９】
この図２３において、メタオブジエクト（MDriveMailer）は、ステップＳＴ１１１にて終了時（Exit）のキック（Kick）のための処理時に指定されたコンティネーションＩＤ（ContID）がメタスペース(mDrive）のコンティネーション（Continuation）のものではないとわかる。そこでオブジェクト（Deliverer）のタグ（DeliverTag）を使ってタグＩＤ（TID）を配送する。
【０１２０】
オブジェクト（Deliverer）はステップＳＴ１１２にてタグＩＤ（TID）からタグ（Tag）を特定し、その属性（ExecSpaceID mailer）から、そのタグ（Tag）がメタオブジエクト（MLocalMailer）のもの（メタスペース（mLocal）のフューチャ（Future））とわかる。そこでメタオブジエクト（MLocalMailer）にそのタグＩＤ（TID）を配送する。
【０１２１】
メタオブジエクト（MLocalMailer）がタグＩＤ（TID）を受け取った後の手続きは、前述した図１０のメタオブジエクト（MLocalMailer）のリプライ（Reply）と同様である（ステップＳＴ１３が真であった場合以降ステップＳＴ１４、ＳＴ１５、ＳＴ１６、ＳＴ１７、ＳＴ２０まで）。
【０１２２】
一方、図２４、図２５はメタスペース(mDrive）からメタスペース（mLocal）にメッセージを送信し、返答を受け取る場合のシナリオである。オブジェクト（Deliverer）の動作は図２２、図２３と同様である。
【０１２３】
すなわち、図２４の例では、メタオブジエクト（MDriveMailer）がベースオブジェクトのセンド（Send）の手続きの依頼を受け付けてからコンティネーション（Continuation）を生成する処理（ステップＳＴ１２１）は、図１７と同様である。
【０１２４】
ここで、ステップＳＴ１２２では、メッセージの配送先の確認を行い、メッセージの配送先がメタスペース（mDrive）オブジェクトではない場合、オブジェクト（mMLocal）のメソッド（DeliverObject）にメッセージを送る。
【０１２５】
オブジェクト（Deliver）はその配送先を知ることができるので、ステップＳＴ１２３のように、そのメイラ（MLocaMailer）にさらに配送する。ステップＳＴ１２６、ＳＴ１２７、ＳＴ１２８に示す、メタオブジエクト（MLocalMailer）がインターフェース（DeliverObject）を通じて配送依頼された後の手続きは、前述した図１８のメタオブジエクト（MDriveMailer）が終了時（Exit）にセンド（Send）のために行なう手続き（ステップＳＴ９４、ＳＴ９５、ＳＴ９６）と同様である。
【０１２６】
また、図２５において、メタオブジエクト（MLocalMailer）は、ステップＳＴ１３１からステップＳＴ１３４にてReply処理時に指定されたフューチャＩＤ（futureID）がメタスペース(mLocal）のフューチャ（Future）のものではないとわかる（図１０のステップＳＴ１１、ＳＴ１２、ＳＴ１３と同様）。そこでオブジェクト（Deliverer）のタグ（DeliverTag）を使ってタグＩＤ（TID）を配送する（図１０のステップＳＴ１３の偽の場合と同じ）。
【０１２７】
オブジェクト（Deliver）はステップＳＴ１３５にてタグＩＤ（TID）からタグ（Tag）を特定し、その属性（ExecSpaceID meiler）から、そのタグ（Tag）がメタオブジェクト（MDriveMailer）のもの（メタスペース（mDrive）のコンティネーション（Continuation））とわかる。そこでメタオブジエクト（MDriveMailer）にそのタグＩＤ（TID）を配送する。
【０１２８】
メタオブジエクト（MDriveMailer）がタグＩＤ（TID）を受け取った後の手続き（ステップＳＴ１３８以降）は、前述した図１８のメタオブジエクト（MDriveMailer）の処理（ステップＳＴ９３、ＳＴ９４、ＳＴ９５、ＳＴ９６）と同様である。
【０１２９】
「その他に考えられる実現方式」
本章ではこれまでに説明した実施の形態での実現方式以外に考えられる「タグを使った通信機構」の実現方式について述べる。
【０１３０】
［タグＩＤでタグの型を認識する方式］
本実施の形態では、タグ（Tag）の属性としてメイラ（Mailer）のＩＤを持っている。これによってタグ（Tag）の型を識別した。つまり、タグＩＤ（TID）からタグ（Tag）を特定し、その属性からタグの型を認識した。別の方法ではタグＩＤにタグの型を認識するための情報を付加する方式である。いまタグＩＤが３２ビットで表わされる整数値だとした場合、例えば下位２ビットをタグ（Tag）の型のために使うという方式が考えられる。図２６には、タグＩＤでタグの型を認証する方式の一例を表す。すなわちこの図２６では、下位２ビットの組み合わせが００のときにはメタスペース（mLocal）のフューチャ（Future）を表すものとし、下位２ビットの組み合わせが０１のときにはメタスペース（mDrive）のコンティネーション（Continuation）を表すものとする。このようにタグの実体を用いずにタグＩＤ（TID）にみを発生させて、このタグＩＤ（TID）にタグの属性を含めたＯＭＴを図２１に対して図２７として示す。なお、図２７中の指示符号Ｃ１，Ｃ２は図２１と同じものである。このようにすれば、タグを介することなくフューチャやコンティネーションを対応付けることができる。この場合は、タグの領域をメモリ内に確保する必要がないので、メモリ領域を削減できる利益がある。なお、本実施の形態ではタグの下位２ビットを利用する例を述べたが、１ビット或いは上位、中位の任意のビットを用いても良いことは勿論である。
【０１３１】
［タグの管理方式］
本実施の形態では、前述したようにタグの管理方式（１）、（２Ａ）、（２Ｂ）の可能性を示したが、いずれの方式もタグにはその属性として型があり、メイラ（Mailer）はその型を調べることで少なくともそのメイラ（Mailer）自身が処理できるタグかどうかを判断する方式について述べた。これらとは別に、タグの属性には型を持たせずに、ただそのメイラ（Mailer）が処理できるタグをメイラ（Mailer）内部に情報として管理するという方式が考えられる。
【０１３２】
この方式では、メイラ（Mailer）がフューチャ（Future）やコンティネーション（Continuation）を生成したら、その情報をメイラ（Mailer）自身が持つテーブルなどに保存する。リプライ（Reply）やキック（Kick）でタグを配送するとき、メイラ（Mailer）はそのテーブルを走査し、そのタグがそのメイラ（Mailer）で処理できる場合は通常のリプライ（Reply）、キック（Kick）の処理を行なう。そうでない場合は、タグの管理方式（２Ａ）のように、どのメイラ（Mailer）にタグを配送すればよいか問い合わせたり、（２Ｂ）のように他のオブジェクトに処理の続きを依頼することができる。
【０１３３】
この場合、メイラ（Mailer）以外に（オブジェクト（Deliverer）のような）タグＩＤとそれに対応したタグを処理できるメイラ（Mailer）を知ることができるオブジェクトも、タグの属性としての型がない場合には、テーブルなどでその対応を管理する必要がある。
【０１３４】
図２８には、スケジューラ（Scheduler）におけるスレッド（Thread）の状態遷移図を示し、以下にスケジューラ（Scheduler）の仕様の例を示す。
【０１３５】
各スレッド（Thread）は実行制御のために各状態を呈する。スケジューラ（Scheduler）はこれらスレッド（Thread）の状態変化を司り、優先順位のような属性（attribute）に基づいて次にどのスレッドを実行すべきかを決定する。
【０１３６】
休止状態（Dormant）はそのスレッド（Thread）に関して実行されるべきものが無いことを示す、このときのメッセージ（message）は受信可能の状態にある。
【０１３７】
実行可能状態（Ready）は、そのスレッド（Thread）は実行可能状態にあることを示し、スケジューラ（Scheduler）内の実行可能状態のスレッド（Thread）のためのキュー（レディキュー（Ready Queues））に入れられる（enqueue）。スレッド（Thread）が実行可能状態（Ready）のときそのスレッド（Thread）に対応付けられたオブジェクトはRで呼び起こされる。
【０１３８】
実行状態（Running）はそのスレッド（Thread）は実行中であることを示す。
【０１３９】
待機状態（Wait）は、オブジェクトの実行中断状態を示し、例えば前述のメタスペース（mLocal）通信機能によってウェイトフォー（WaitFor）がリプライ（Reply）よりも先に発行された場合に生ずる。
【０１４０】
ここでインターフェース（ＡＰＩ）の例をいくつか示す。
【０１４１】
sError MakeReady(thread,sel,msg)
このインターフェース（ＡＰＩ）はスレッド（Thread）によりリンクされた宛先オブジェクトのセレクタ（sel）で指定されるメソッドにメッセージ(msg）を送るためにメーラメタオブジェクト（例えば前述のメタオブジェクト（MLocalMailer））により使用される。
【０１４２】
スケジューラ（Scheduler）はスレッド（Thread）の状態を休止状態（Dormant）から実行可能状態（Ready）に遷移させ、上記レディキュー（Ready Queues）内の列にそれを入れる（enqueue）。
【０１４３】
宛先オブジェクトはスレッド（Thread）がスケジュールされた時、すなわち上記スケジューラ（Scheduler）により実行可能状態（Ready）のスレッド（Thread）が実行されるときに呼び起こされる。
【０１４４】
なお、sErrorはインターフェースの実行結果の状態を示し、メイクレディ（MakeReady）が正しく動作した場合、それを示す返り値（sSuccess）を返す。そうでない場合は各種のエラーを示す値を返す。
【０１４５】
sError MakeReady(thread)
このインターフェース（ＡＰＩ）はスレッド（Thread）の実行を再開するためにメーラによって使用される。スケジューラ（Scheduler）はスレッド（Thread）の状態を待機状態（Wait）から実行可能状態（Ready）に変化させ、レディキュー（Ready Queues）内の列にそれを入れる（enqueue）。このインターフェースは例えば前述のメタスペース（mLocal）通信機能によってウェイトフォー（WaitFor）を発行して待機状態（Wait）にあるオブジェクトが、別のオブジェクトの発行したリプライ（Reply）によって結果メッセージを受け取り、実行可能状態にする必要があるときに使われる。
【０１４６】
sError MakeWait(thread)
このインターフェース（ＡＰＩ）はスレッド（Thread）の実行を停止するために利用される。スケジューラ（Scheduler）はスレッド（Thread）を実行可能状態（Ready）から待機状態（Wait）に遷移させ、レディキュー（Ready Queues）内の列からそれを除く（dequeue）。なお、上記各メーラはベースオブジェクトの実行停止のため、このインターフェースを呼び出す必要はない。なぜならば、ベースオブジェクトが上述のＭ（Meta Computation）を使ってメーラを呼び起こす時にその状態は待機状態（Wait）に変化しているからである。
【０１４７】
sError MakeDormant(thread)
このインターフェース（ＡＰＩ）はスレッド（Thread）の実行を終了するために上記メーラによって利用される。スケジューラ（Scheduler）はスレッド（Thread）の状態を実行可能状態（Ready）から休止状態（Dormant）に変化させ、レディキュー（Rdady Queus）内の列からそれを除く（dequeue）。
【０１４８】
なお、上記メーラ（mailer）からみたオブジェクト（又はそれに関連付けられたスレッド）の状態は、休止状態（Dormant）、実行可能状態（Ready）、待機状態（Wait）の３つである。これは複数の実行可能状態にあるオブジェクトのうち、どのオブジェクトをＣＰＵが処理している（Running）かどうか、メイラは知る必要がないからである。
【０１４９】
【発明の効果】
本発明によれば、異なるオブジェクト間通信機構がそれぞれ固有に持つオブジェクト間通信の同期及び並行性の制御を行うためのタグを導入することによって、異なる環境間のオブジェクト間通信を透明性をもって容易に実現することができる。
【図面の簡単な説明】
【図１】本発明実施の形態のデータ通信方法が適用されるＶＣＲ装置の概略構成を示すブロック回路図である。
【図２】本実施の形態のＶＣＲ装置と通信用ＯＳ、ＡＶ用ＯＳとＡＰＩにより通信が行われる様子の説明に用いる図である。
【図３】メタスペース（mLocal）通信機構（ウェイトフォー（WaitFor）がリプライ（Replay）よりも先に実行された場合）の説明に用いる図である。
【図４】メタスペース（mLocal）通信機構（リプライ（Reply）がウェイトフォー（WaitFor）よりも先に実行された場合）の説明に用いる図である。
【図５】アプリケーションソフトがＡＰＩによってメイラのオブジェクトやスケジューラのオブジェクトに通信を行う様子の説明に用いる図である。
【図６】フューチャ（Future）の属性の説明に用いる図である。
【図７】メタスペース（mDrive）通信機構の説明に用いる図である。
【図８】コンティネーション（Continuation）の属性の説明に用いる図である。
【図９】メタオブジエクト（MLocalMailer）とスケジューラ（Scheduler）の関係（メタスペース（mLocal）におけるセンド（Send）の実現）の手続きの流れを示す図である。
【図１０】メタオブジエクト（MLocalMailer）とスケジューラ（Scheduler）の関係（メタスペース（mLocal）におけるリプライ（Reply）の実現）の手続きの流れを示す図である。
【図１１】メタオブジエクト（MLocalMailer）とスケジューラ（Scheduler）の関係（メタスペース（mLocal）におけるウェイトフォー（WaitFor）でリプライ（Reply）がウェイトフォー（WaitFor）よりも先に実行された場合）の手続きの流れを示す図である。
【図１２】メタオブジエクト（MLocalMailer）とスケジューラ（Scheduler）の関係（メタスペース（mLocal）におけるウェイトフォー（WaitFor）でウェイトフォー（WaitFor）がリプライ（Reply）よりも先に実行された場合）の手続きの流れを示す図である。
【図１３】メッセージキューの説明に用いる図である。
【図１４】メタオブジエクト（MDriveMailer）におけるセンド（Send）の手続きの流れを示す図である。
【図１５】メタオブジエクト（MDriveMailer）におけるキック（Kick）の手続きの流れを示す図である。
【図１６】メタオブジエクト（MDriveMailer）の終了時（Exit）で、メタスペース(mDrive）上のベースオブジェクトが処理を終了するときに呼び出される手続きの流れを示す図である。
【図１７】遅延実行テーブル（DelayeExecutionTable）に登録（メタオブジエクト（MDriveMailer）のセンド（Send）の場合）された手続きを処理する流れを示す図である。
【図１８】遅延実行テーブル（DelayeExecutionTable）に登録（メタオブジエクト（MDriveMailer）のキック（Kick）の場合）された手続きを処理する流れを示す図である。
【図１９】メタメッセージ（MetaMessage）の構成の説明に用いる図である。
【図２０】ベースオブジェクトＩの実行中にベースオブジェクトＩＩが割り込んだ場合の動作説明に用いる図である。
【図２１】タグ（Tag）とフューチャ（Future）、コンティネーション（Continuation）の関係、タグ（Tag）とタグＩＤ（TID）の関係をＯＭＴ法のオブジェクトモデルで示す図である。
【図２２】オブジェクト（deliverer）を介して異なるメタスペース間通信を行なう場合（メタスペース（mLocal）がメタスペース(mDrive）に通信する場合）の往路の流れを示す図である。
【図２３】オブジェクト（deliverer）を介して異なるメタスペース間通信を行なう場合（メタスペース（mLocal）がメタスペース(mDrive）に通信する場合）の復路の流れを示す図である。
【図２４】オブジェクト（deliverer）を介して異なるメタスペース間通信を行なう場合（メタスペース(mDrive）がメタスペース（mLocal）に通信する場合）の往路の流れを示す図である。
【図２５】オブジェクト（deliverer）を介して異なるメタスペース間通信を行なう場合（メタスペース(mDrive）がメタスペース（mLocal）に通信する場合）の復路の流れを示す図である。
【図２６】タグｌＤでタグの型を認証する方式の一例を表す図である。
【図２７】このタグＩＤ（TID）にタグの属性を含めたＯＭＴを示す図である。
【図２８】スレッド（Thread）の状態遷移図を示す。
【符号の説明】
mLocal，mDrive メタスペース、 MLocalMailer，MDriveMailer メタオブジエクト
Claims (6)
- ソフトウェア機能を実現するため複数のオブジェクト間で通信を行うデータ通信方法において、
異なるオブジェクト間通信機構をそれぞれ固有に持つ環境間でそれぞれ異なる実体を用いて通信を行う際、上記異なるオブジェクト間通信機構のデータ構造を共通のデータ構造で関連付けるタグを生成し、
上記タグを生成する際、上記タグを識別するためのタグＩＤと上記環境を特定するタグの型を示す属性とを、少なくとも生成し、
上記タグを通信メッセージと共に通信し、
上記タグの型を示す属性に基づいて上記実体を特定する
ことを特徴とするデータ通信方法。 - 上記タグの型を管理するオブジェクトを有する
ことを特徴とする請求項１記載のデータ通信方法。 - 上記タグＩＤはオブジェクトによって上記通信メッセージと共に配送される
ことを特徴とする請求項１記載のデータ通信方法。 - 上記タグＩＤを配送するオブジェクトは、上記タグの型に基づいて配送先を決定する
ことを特徴とする請求項３記載のデータ通信方法。 - 上記タグＩＤを配送するオブジェクトは、上記タグの型と配送先のテーブルを有する
ことを特徴とする請求項４記載のデータ通信方法。 - 複数ビットにて形成される上記タグＩＤに一部のビットを付加して上記タグの型を表す
ことを特徴とする請求項１記載のデータ通信方法。
Priority Applications (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP09244697A JP3817823B2 (ja) | 1997-04-10 | 1997-04-10 | データ通信方法 |
| KR1019980011458A KR19980080985A (ko) | 1997-04-10 | 1998-04-01 | 데이터 통신방법 |
| US09/055,669 US6466991B1 (en) | 1997-04-10 | 1998-04-07 | Data communication method |
| DE69837825T DE69837825T2 (de) | 1997-04-10 | 1998-04-08 | Datenübertragungsverfahren |
| EP98302757A EP0871119B1 (en) | 1997-04-10 | 1998-04-08 | Data communication method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP09244697A JP3817823B2 (ja) | 1997-04-10 | 1997-04-10 | データ通信方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH10283205A JPH10283205A (ja) | 1998-10-23 |
| JP3817823B2 true JP3817823B2 (ja) | 2006-09-06 |
Family
ID=14054644
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP09244697A Expired - Fee Related JP3817823B2 (ja) | 1997-04-10 | 1997-04-10 | データ通信方法 |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US6466991B1 (ja) |
| EP (1) | EP0871119B1 (ja) |
| JP (1) | JP3817823B2 (ja) |
| KR (1) | KR19980080985A (ja) |
| DE (1) | DE69837825T2 (ja) |
Families Citing this family (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20030079046A1 (en) * | 1996-11-27 | 2003-04-24 | Sony Europa B.V. | Data communication method using typed continuation |
| EP1041485A1 (en) | 1999-03-31 | 2000-10-04 | Sony Service Center (Europe) N.V. | Object with polymorphism |
| KR20000050238A (ko) * | 2000-05-30 | 2000-08-05 | 김호광 | 다수의 운영시스템에서 실행 가능한 프로그램 제작 시스템및 방법 |
| KR20020031511A (ko) * | 2000-10-20 | 2002-05-02 | 김영돈, 정춘보 | 다수의 하드웨어에서 실행가능한 ｐｄａ 어플리케이션제작방법 |
| US7480909B2 (en) * | 2002-02-25 | 2009-01-20 | International Business Machines Corporation | Method and apparatus for cooperative distributed task management in a storage subsystem with multiple controllers using cache locking |
| US20040003007A1 (en) * | 2002-06-28 | 2004-01-01 | Prall John M. | Windows management instrument synchronized repository provider |
| US7124414B2 (en) * | 2002-10-31 | 2006-10-17 | International Business Machines Corporation | Method, system and program product for routing requests in a distributed system |
| JP5150116B2 (ja) * | 2006-03-31 | 2013-02-20 | パナソニック株式会社 | Ｉｃカード及び読み書き装置 |
| US8775651B2 (en) * | 2008-12-12 | 2014-07-08 | Raytheon Company | System and method for dynamic adaptation service of an enterprise service bus over a communication platform |
| US8891411B2 (en) | 2011-09-23 | 2014-11-18 | Avaya Inc. | System and method for a conference foyer |
| KR101389534B1 (ko) * | 2013-06-24 | 2014-04-28 | 액세스모바일 (주) | Ｉｄ 태그 서비스 제공 시스템 및 방법 |
| CN104063285B (zh) * | 2014-01-13 | 2017-06-23 | 惠州华阳通用电子有限公司 | 一种基于车载软件平台进程内模块间的消息广播通信方法 |
Family Cites Families (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0329779B1 (en) * | 1987-09-04 | 1992-12-09 | Digital Equipment Corporation | Session control in network for digital data processing system which supports multiple transfer protocols |
| US5124909A (en) * | 1988-10-31 | 1992-06-23 | Hewlett-Packard Company | Software program for providing cooperative processing between personal computers and a host computer |
| DE69228621T2 (de) * | 1991-02-25 | 1999-07-22 | Hewlett Packard Co | Objektorientiertes verteiltes Rechnersystem |
| SE500673C2 (sv) * | 1991-11-27 | 1994-08-08 | Icl Systems Ab | Förfarande och arrangemang för att åstadkomma en förenklad dialog mellan en central datorenhet och minst en användarenhet |
| US5566302A (en) * | 1992-12-21 | 1996-10-15 | Sun Microsystems, Inc. | Method for executing operation call from client application using shared memory region and establishing shared memory region when the shared memory region does not exist |
| DE69327448T2 (de) * | 1992-12-21 | 2004-03-04 | Sun Microsystems, Inc., Mountain View | Verfahren und Vorrichtung für Teilaufgaben in verteiltem Verarbeitungssystem |
| JP3238788B2 (ja) * | 1993-03-30 | 2001-12-17 | 株式会社エヌ・ティ・ティ・データ | オブジェクト通信方式 |
| AU1747395A (en) | 1994-03-30 | 1995-10-23 | Apple Computer, Inc. | Object oriented message passing system and method |
| US5724503A (en) * | 1995-03-31 | 1998-03-03 | Sun Microsystems, Inc. | Method and apparatus for interpreting exceptions in a distributed object system |
| US5615351A (en) * | 1995-07-07 | 1997-03-25 | Bell Communications Research, Inc. | Method and system for correlating usage data in a distributed architecture |
| US6226692B1 (en) * | 1995-12-15 | 2001-05-01 | Object Dynamics Corporation | Method and system for constructing software components and systems as assemblies of independent parts |
| JP3622313B2 (ja) * | 1996-01-29 | 2005-02-23 | 株式会社日立製作所 | ドキュメント管理システム |
| US6032199A (en) * | 1996-06-26 | 2000-02-29 | Sun Microsystems, Inc. | Transport independent invocation and servant interfaces that permit both typecode interpreted and compiled marshaling |
| US6044409A (en) * | 1996-06-26 | 2000-03-28 | Sun Microsystems, Inc. | Framework for marshaling and unmarshaling argument object references |
| US5966663A (en) * | 1997-01-14 | 1999-10-12 | Ericsson Messaging Systems Inc. | Data communications protocol for facilitating communications between a message entry device and a messaging center |
| US5999988A (en) * | 1997-03-31 | 1999-12-07 | Sun Microsystems, Inc. | Method and apparatus for generating and employing a run-time generated stub to reference an object in object oriented systems |
| US6157959A (en) * | 1997-07-03 | 2000-12-05 | Tandem Computers, Incorporated | Method and apparatus for providing portable kernel-mode support for fast interprocess communication |
-
1997
- 1997-04-10 JP JP09244697A patent/JP3817823B2/ja not_active Expired - Fee Related
-
1998
- 1998-04-01 KR KR1019980011458A patent/KR19980080985A/ko not_active Application Discontinuation
- 1998-04-07 US US09/055,669 patent/US6466991B1/en not_active Expired - Lifetime
- 1998-04-08 EP EP98302757A patent/EP0871119B1/en not_active Expired - Lifetime
- 1998-04-08 DE DE69837825T patent/DE69837825T2/de not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| DE69837825T2 (de) | 2008-01-31 |
| KR19980080985A (ko) | 1998-11-25 |
| EP0871119A1 (en) | 1998-10-14 |
| US6466991B1 (en) | 2002-10-15 |
| JPH10283205A (ja) | 1998-10-23 |
| EP0871119B1 (en) | 2007-05-30 |
| DE69837825D1 (de) | 2007-07-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3817823B2 (ja) | データ通信方法 | |
| EP1025493B1 (en) | Queued method invocations on distributed component applications | |
| US10353749B2 (en) | Lock-free dual queue with condition synchronization and time-outs | |
| US6832367B1 (en) | Method and system for recording and replaying the execution of distributed java programs | |
| JP4550411B2 (ja) | 同期されたコールバック処理特徴をもったトランザクション処理システム及び方法 | |
| US5991823A (en) | Low overhead object adaptor | |
| US6044409A (en) | Framework for marshaling and unmarshaling argument object references | |
| US6901596B1 (en) | Method of communicating asynchronous events to remote procedure call clients | |
| US6557046B1 (en) | Method and system for providing an event system infrastructure | |
| US7424549B2 (en) | System, method, and article of manufacture for using a replaceable component to select a replaceable quality of service capable network communication channel component | |
| WO2004066081A2 (en) | Asynchronous web service invocation model | |
| US7580979B2 (en) | Message ordering in a messaging system | |
| US20030097488A1 (en) | Efficient method for determining record based I/O on top of streaming protocols | |
| US20010037408A1 (en) | Media framework systems | |
| JPH1063506A (ja) | タイプコードで解釈されコンパイル（編集）されたマーシャリングを可能にするトランスポートから独立した呼出しとサーバントインターフェイス | |
| JP2000029707A (ja) | 高速なロ―カルｃｏｒｂａオブジェクトレファレンスのための方法及び装置 | |
| JP2002521765A (ja) | クラスタ化された計算処理環境において実行する分散ネットワークアプリケーションの管理用リクエストを処理するための方法および装置 | |
| US20020091695A1 (en) | Remote computation framework | |
| EP0924606A2 (en) | Method and apparatus for deferred throwing of exceptions in C++ | |
| US5721920A (en) | Method and system for providing a state oriented and event driven environment | |
| US6598049B1 (en) | Data structure identifying method and recording medium | |
| CA2264234A1 (en) | Data processing method, recording medium, and data processing apparatus | |
| JPH07502851A (ja) | 転位疑似通信点（疑似ソケット）の機能を利用する装置 | |
| CN114296809B (zh) | 一种基于操作系统的对象模型构建方法及其系统调用接口 | |
| JP2001344225A (ja) | 分散オブジェクト再起動方法とその処理プログラムを記録した記録媒体および分散オブジェクト再起動装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20050615 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050726 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050926 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060110 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060313 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060523 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060605 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090623 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100623 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100623 Year of fee payment: 4 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
| S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100623 Year of fee payment: 4 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110623 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110623 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120623 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120623 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130623 Year of fee payment: 7 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |