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
【発明の属する技術分野】
本発明は、オブジェクト指向オペレーティング・システム(OS)又はその他のオブジェクト指向プログラミングシステムにおいてオブジェクト間のデータ通信方法に関する。
【0002】
【従来の技術】
最近のソフトウェア技術には、いわゆるオブジェクト指向技術がある。オブジェクト指向技術を適用したソフトウェアでは、ソフトウエア内部の各機能はオブジェクトとしてモジュール化されている。ソフトウエア全体の機能を実現するために、各オブジェクトはオブジェクト間通信を行なう。オブジェクト間通信では送信内容をメッセージに詰めて配送する。
【0003】
オブジェクト間通信には同期方法やメッセージの管理方法について、いろいろな方式が考えられる。これらの方式はアプリケーションからの要求に応じて決定される必要がある。そのため、いろいろな要求に応えるためには、アプリケーションに応じた性質(意味構造、セマンティクス)やそれに応じたインターフェース(Application Programming Interface:APIs)を持ったオブジェクト間通信機構が必要になる。なお、以下で扱うAPIとは、OSの機能を用いるインターフェース或いはプログラミングシステムの機能としてのインターフェースを示す。
【0004】
ある性質やインターフェースを持ったオブジェクト間通信機構が存在することを「環境」があると呼ぶことにする。一つの機器やホストにはただ一つの環境が実現されることもあるし、異なる複数の環境が同時に実現されることもある。特に異なる環境に存在するオブジェクト間の通信は相互の環境の協調動作を行わしめるという点から重要である。
【0005】
ここで、異なる環境に存在するオブジェクトにメッセージを送る機能を提供する考え方として、本質的に以下の二つがある。すなわち、
1.異なる環境に存在するオブジェクトにメッセージを送るために、同じ環境に存在するオブジェクトにメッセージを送るときとは異なるインターフェースや手続きを提供するという考え方と、
2.異なる環境に存在するオブジェクトにメッセージを送るために、同じ環境に存在するオブジェクトにメッセージを送るときと同じインターフェースや手続きを使うことができるという考え方とがある。
【0006】
前者の方法は、比較的容易に実現できる。なぜなら、全ての環境をプログラマが意識しなくてもよい考え方なので、インターフェースや手続きの違いが環境の違いによって各々異なる機能を提供することで吸収させればよいからである。
【0007】
【発明が解決しようとする課題】
しかし、プログラマのためには異なる環境に対してプログラムコードが左右されない、いわゆる透明性を提供した方がよい。
【0008】
そこで本発明は、上述した課題に鑑みてなされたものであり、プログラマのために異なる環境に対して透明性を提供することを可能にするデータ通信方法を提供することを目的とするものである。
【0009】
【課題を解決するための手段】
本発明は、ソフトウェア機能を実現するため複数のオブジェクト間で通信を行うデータ通信方法において、異なるオブジェクト間通信機構をそれぞれ固有に持つ環境間でそれぞれ異なる実体を用いて通信を行う際、上記異なるオブジェクト間通信機構のデータ構造を共通のデータ構造で関連付けるタグを生成し、上記タグを生成する際、上記タグを識別するためのタグIDと上記環境を特定するタグの型を示す属性とを、少なくとも生成し、上記タグを通信メッセージと共に通信し、上記タグの型を示す属性に基づいて上記実体を特定することを特徴としている。
本発明は、同一又は相違OSを問わずオブジェクト間通信が必要なソフトウェアであって、ソフトウェア間が透明性をもって通信することを実現するタグと、それを適用したソフトウェアシステムを実現することにより、上述した課題を解決する。
【0010】
すなわち、本発明は、上記「タグ」を導入することによって、異なる環境間で透明性のある通信機構を実現したソフトウェア、またはその実現方式を提供する。本発明によって、ある通信機構が固有に持つオブジェクト間通信の同期や並行性の制御に必要な実体が環境によって異なっている場合でも、異なる環境に存在しているオブジェクトが互いにその違いを意識することなく、通信可能になる。
【0011】
【発明の実施の形態】
本発明の一実施の形態について、図面を参照しながら説明する。
【0012】
本発明実施の形態のデータ通信方法は、異なる複数の環境を実現できるソフトウェア・システムに適用することを基本的な特徴の一つとしている。本発明の実施の形態では「環境」のことを特にメタスペースと呼んでいる。また、本発明の実施の形態におけるメタスペースでは、オブジェクト間通信機構以外の機能についても異なる「環境」を提供できる。なお、上記異なる複数の環境を実現できるソフトウェア・システムとしては、例えば本件出願人が先に提案している特願平8−67881号の明細書及び図面に記載したデータ処理方法及び装置を挙げることができる。このデータ処理方法は、複数のオブジェクトで構成されるアプリケーションプログラムと、複数のオブジェクトで構成される前記アプリケーションプログラムの動作を規定する実行環境と、前記アプリケーションプログラムと前記実行環境の間のインターフェースを規定するアプリケーションプログラムインターフェースとを備えるサーバと、前記サーバより前記アプリケーションプログラムをダウンロードするクライアントとを備えるデータ処理システムにおけるデータ処理方法であって、前記サーバは前記クライアントに前記アプリケーションプログラムをダウンロードするとき、前記クライアントがダウンロードする前記アプリケーションプログラムの実行環境を有するか否かを検査し、その検査結果に対応して前記アプリケーションプログラムを前記クライアントにダウンロードすることを特徴とするものである。
【0013】
図1には、本発明実施の形態のデータ通信方法が適用される装置構成の一例を示す。
【0014】
この図1の装置は、カセット内にビデオテープを収納したビデオカセットを用いて信号の記録再生を行うビデオカセットレコーダ(以下、VCR装置と呼ぶ)である。勿論VCR装置以外のオーディオ・ビジュアル機器(いわゆるAV機器)や事務機器等のその他の装置、一般のコンピュータ装置にも本発明は適用可能である。
【0015】
図1のVCR装置において、VCR機能部14はビデオカセットを用いてデータの記録再生を行うビデオカセットレコーダとしての主要機能を備え、当該VCR機能部14にてビデオカセットに記録/再生されるデータは、バス/IOブリッジ15を介して装置の他の構成に送られ、また端子23を介して外部との入出力が行われる。CPU(中央処置ユニット)12は、バス/メモリブリッジ13を介して各部を制御する制御部である。RAM(ランダム・アクセス・メモリ)10は、比較的小容量で構成され、ワークエリアを有する。ROM(リード・オンリ・メモリ)11は、基本的な機能に関するプログラムを記憶していると共に、本発明で言うOSに係るプログラムも記憶されている。すなわち、上記CPU12は、上記ROM11が記憶するプログラムに基づいて各部を制御し、上記RAM10をワークエリアとして使用する。
【0016】
ICカードドライブ16は、カード状の筐体内にIC(集積回路)を備えた記憶媒体であるICカードが挿入されるスロットと、当該ICカードに対するデータの書き込み/読み出しを行うICカード駆動部とを有する。フロッピィディスクドライブ17は、フロッピィディスが挿入されるスロットと、当該フロッピィディスクを回転駆動する回転駆動部と、フロッピィディスクに対してデータの記録/再生を行うヘッド部とを有し、各種データの記録やアプリケーションソフトのインストールなどが行われる。ハードディスクドライブ18は、当該ハードディスクを回転駆動する回転駆動部と、ハードディスクに対してデータの記録/再生を行うヘッド部とを有する。バススロット19は、拡張ボードを追加する際の拡張端子である。シリアルポート20は、モデム(MODEM)を介して外部との間でデータ通信を行うための入出力部である。
【0017】
このVCR装置は、一般のVCRの機能に追加して、付加的なアプリケーションソフトを与えることができるようになっている。例えばユーザがバージョンアップを図りたい(新しい機能をこのVCR装置に付加したい)場合等は、ICカードやフロッピディスク或いはインターネット等のネットワーク回線を介して付加的な機能ソフトをインストールできる。したがってユーザは、VCR装置本体を買い換えることなく装置の機能アップが行える。アプリケーションプログラムはプログラマによって作成されてユーザに供給されるものである。ここでこれらソフトウェアをいわゆるオブジェクト指向型プログラミングソフトで構築する場合を考える。
【0018】
上記の例の場合、異なる複数の環境(メタスペース)間で通信が必要となる場合がある。
【0019】
例えば図2に示すように外部からMODEM(モデム)、シリアルポートを介して通信されてきたアプリケーションソフトと予めVCR装置内に存在するアプリケーションソフトは異なる環境(メタスペース)下にあり、それぞれは通信用OS(後述するメタスペース(mLocal)、メタスペース(mDrive)等)、AV用OSとAPI(後述するセンド(Send)、リプライ(Reply)等)により通信が行われるようになっている。
【0020】
先ず初めに、上記「異なる通信機構について具体的な二つの例」を本発明のデータ通信方法にて実現した例を使って述べる。この例では後述するフューチャ(Future)と呼ぶ実体を使った通信セマンティクス(性質、意味構造)を実現したメタスペース(mLocal)と、コンティネーション(Continuation)と呼ぶ実体を使った通信セマンティクスを実現したメタスペース(mDrive)の例で示す。
【0021】
本実施の形態では、上記「異なる通信機構の具体的な例」として、
[メタスペース(mLocal)通信機構]
[メタスペース(mDrive)通信機構]
[メタスペース(mLocal)通信機構とメタスペース(mDrive)通信機構の比較]
[本発明方法における通信機構の実現方式]
[フューチャ(Future)とメタスペース(mLocal)通信機構の実現方式]
[コンティネーション(Continuation)とメタスペース(mDrive)通信機構の実現方式]
の順に説明する。
【0022】
次に、「タグを使った通信機構の基本的な説明」を述べる。ここでもメタスペース(mLocal)とメタスペース(mDrive)を例に述べる。なお、メタスペース(mLocal)、メタスペース(mDrive)は、1つのOS又はプログラミングシステムとして捉えることができる。本実施の形態では、上記「タグを使った通信機構の基本的な説明」として、
[オブジェクトA(メソッドA1(A::A1))がオブジェクトB(メソッドB1(B::B1))にセンド及びウェイトフォー(Send+WaitFor)する場合]
[オブジェクトB(メソッドB1(B::B1))がオブジェクトA(メソッドA1(A::A1))にセンド(Send)し、継続メソッドとしてオブジェクトB(メソッドB2(B::B2))を指定した場合]
の順に説明する。
【0023】
その後、「タグを使った通信機構の本発明方法での実現事例」についての詳細を述べる。本実施の形態では、上記「タグを使った通信機構の本発明方法での実現事例」として、
[フューチャ(Future)、コンティネーション(Continuation)、タグ(Tag)]
[タグIDの管理方式と当該タグIDを配送するオブジェクト(Deliverer)]
[異なるメタスペース間通信の実際]
の順に説明する。
【0024】
最後に「他に考えられる些細な点で他に異なる方式」について述べる。本実施の形態では、上記「その他に考えられる実現方式」として、
[タグIDでタグの型を認識する方式]
[タグの管理方式]
の順に説明する。
【0025】
先ず、上記本発明方法における「異なる通信機構の具体的な例」の場合の説明を行う。
【0026】
本章では、「異なる通信機構の具体的な例」として、本発明のデータ通信方法におけるオブジェクト間通信の具体的な仕様と実現方式について述べる。本章に続く本発明の具体的な事例では、本章で述べる二つの異なる(通信機構を提供している)環境間でのオブジェクト間通信の実現方式を説明する。
【0027】
[メタスペース(mLocal)通信機構]
上記メタスペース(mLocal)は上記フューチャ(Future)を基本にした通信機構をサポートした環境(オブジェクト間通信機構)である。このメタスペース(mLocal)はアプリケーションを記述するためのものである。メタスペース(mLocal)通信機構の仕様のうち、インターフェースについては後述する。
【0028】
ここでは、メタスペース(mLocal)通信機構を使ったオブジェクト間通信の基本的を動作について述べる。この通信機構の実現方式、説明で使用されるフューチャ(Future)が持つ属性については後に述べる。
【0029】
図3と図4はメタスペース(mLocal)通信機構を使ったオブジェクト間通信の基本的な動作を示している。図3にはメタスペース(mLocal)通信機構において、ウェイトフォー(WaitFor)がリプライ(Reply)よりも先に実行された場合を示し、図4にはメタスペース(mLocal)通信機構においてリプライ(Reply)がウェイトフォー(WaitFor)よりも先に実行された場合を示している。これら図3、図4ともにA、Bはオブジェクト、A::A1、B::B1はそれぞれオブジェクトAのメソッドA1、オブジェクトBのメソッドB1、縦の実線矢印はメソッドの実行、縦の破線矢印はメソッドの待ち状態、斜めの実線矢印はメッセージの配送を示している。なお、上記ウェイトフォー(WaitFor)は、メタスペース(mLocal)におけるAPI(Application Programming Interface)の一つであり、本実施の形態ではオブジェクトAがオブジェクトBの結果を待つ場合に用いられる。当該ウェイトフォー(WaitFor)には、その引数として後述するフューチャID(futureID)、上記リプライ(Reply)から送られた返答メッセージ(&msg)及びそのサイズ(sizeof(msg))を備える。なお、上記リプライ(Reply)は、メタスペース(mLocal)におけるAPIの一つであり、本実施の形態ではオブジェクトBがオブジェクトAの返答する場合に用いられる。当該リプライ(Reply)には、その引数としてメソッドB1の実行結果として得られる返答メッセージ(msg)及びそのサイズ(sizeof(msg))を備える。
【0030】
また図3、図4ともに、オブジェクトAがオブジェクトBにメッセージを送信し、その返答を受け取る例である。はじめにオブジェクトAはオブジェクトBにセンド( Send)を使ってメッセージを送信する。メソッドB1(B::B1)はこれによって起動するメソッドであり、図中msgは配送されるメッセージ(のポインタ)である。これによって、メソッドB1(B::B1)が起動される。メソッドA1(A::A1)、メソッドB1(B::B1)は並行に動作する。このとき、メソッドA1(A::A1)のウェイトフォー(Waitfor)とメソッドB1(B::B1)のリプライ(Reply)のどちらが先に実行されるかという保証はない。なお、センド(Send)とは、メタスペース(mLocal)におけるAPIの一つであり、本実施の形態ではメイルの送信を行う場合に用いられる。当該センド(Send)には、その引数として宛先(B)と選択メソッド(B1)、メッセージ(msg)及びそのサイズ(sizeof(msg))とフューチャID(&futureID)とを備える。
【0031】
オブジェクトAがオブジェクトBにメッセージ送信したとき、オブジェクトAはフューチャID(futureID)を受け取る。このフューチャIDはOS(オペレーティング・システム)がメッセージを配送する際にOSが内部的に生成する上記フューチャ(Future)と呼ばれる実体に対応するIDである。ここで、生成とはオブジェクトを構成する属性に必要なメモリの領域を確保すること及び当該属性を初期化することを示す。図5に示すように、アプリケーションソフトはAPIを介してメイラ(例えば後述するメタオブジエクト(MLocalMailer))のオブジェクトや後述するスケジューラ(Scheduler)のオブジェクトに通信を行う。メイラの実行がオブジェクト内の実行コードに基づいてCPUによって行われ、CPUはフューチャ(Future)に必要なメモリ領域をOS領域内に確保する。フューチャID(futureID)はオブジェクトAが後にこのメッセージの配送に対する返答を受け取るとき、どのメッセージ送信に対する返答メッセージの受信なのかを識別するために使われる。
【0032】
図6はフューチャ(Future)の属性を示している。この属性としては、フューチャ(Future)を生成したオブジェクトを特定するためのID(ThreadID creator)、返答が済んでいるかどうかを調べるためのフラグ(bool isReplyDone)、返答メッセージがある場合にはこれを保存しておくための領域( void* replyMessage )が定義されている。例えば図3、図4の例ならば、ID(ThreadID creator)はオブジェクトAが、返答メッセージ(void* replyMessage)にはメッセージ(msg)が保存される。
【0033】
図3はウェイトフォー(Waitfor)がリプライ(Reply)よりも先に実行された場合を示しており、この場合、ウェイトフォー(Waitfor)の引数として上記フューチャID(futureID)を与える。このとき、指定されたフューチャID(futureID)に対する返答のための処理が行われていないので、メソッドA1(A::A1)の実行は待ち状態になる。その間、メソッドB1(B::B1)は処理を続け、返答のための手続きをするときリプライ(Reply)を実行する。リプライ(Reply)が実行されると、OSがメソッドB1(B::B1)を起動するときに生成したフューチャ(Future)の状態を観察する。この場合、OSはそのフューチャ(Future)に対して待ち状態のメソッドがあることを知ることができるので、ここでメソッドA1(A::A1)を再び実行状態に戻す。その後、メソッドA1(A::A1)、メソッドB1(B::B1)は再び並行に動作する。
【0034】
一方、図4はリプライ(Reply)がウェイトフォー(Waitfor)よりも先に実行された場合を示している。リプライ(Reply)が実行されたとき、OSがメソッドB1(B::B1)を起動するときに生成したフューチャ(Future)の状態を観察する。この場合、OSはそのフューチャ(Future)に対応したメッセージの送信者(この場合はオブジェクトA)はまだ待ち状態にないことを知ることができるので、フューチャ(Future)に返答済みである印を付ける。メソッドB1(B::B1)はそのまま残り部分の実行を続ける。メソッドA1(A::A1)がメソッドB1(B::B1)からの返答を必要としたとき、メソッドA1(A::A1)はウェイトフォー(Waitfor)の引数としてフューチャID(futureID)を与える。この場合、指定されたフューチャID(futureID)に対する返答のための処理がすでに行われているので、メソッドA1(A::A1)は実行を継続することができる。
【0035】
このように、フューチャ(Future)は並行動作している二つのオブジェクトの同期を取るための仲介的な役割を果たしている。メタスペース(mLocal)通信機構の仕様では、メッセージの送信側はどのメッセージに対する返答待ちかを明示的に示す必要があるので、フューチャID(futureID)によってフューチャ(Future)を特定する。メッセージの受信側はどの送信者に対する返信なのかを意識する必要がないように定めているので、フューチャID(futureID)は明示的に現れていない。
【0036】
[メタスペース(mDrive)通信機構]
メタスペース(mDrive)はコンティネーション(Continuation)を基本にした通信機構をサポートした環境である。このメタスペース(mDrive)はデバイスドライバを記述するためのものである。
【0037】
ここでは、メタスペース(mDrive)通信機構を使ったオブジェクト間通信の基本的な動作について述べる。この通信機構の実現方式、説明で使用されるコンティネーション(Continuation)が持つ属性や状態遷移などの詳細は後述する。
【0038】
図7はメタスペース(mDrive)通信機構を使ったオブジェクト間通信の基本的な動作を示している。図3、図4と同様にA、Bはともにオブジェクト、A::A1、A::A2及びB::B1はそれぞれのオブジェクトA、BのメソッドA1、A2、B1、縦の実線矢印はメソッドの実行、斜めの実線矢印はメッセージの配送を示している。
【0039】
オブジェクトAはセンド(Send)を使ってオブジェクトBにメッセージを送信する。図7の例ではオブジェクトBのメソッドB1(B::B1)にメッセージ(msg)を配送する。このとき、オブジェクトAはセンド(Send)に対して5番目の引数として継続メソッド(A2)を、さらに6番目の引数として継続メッセージ(contMsg)を与える。このときのメソッドA2(A::A2)は、メソッドA1(A::A1)の処理が終了した後、メソッドB1(B::B1)からの返答を受け取って処理を継続するメソッドである。また、このときのメッセージ(contMsg)は、継続メソッド(A2)の処理を補助するためのメッセージで、メソッドA1(A::A1)が継続メソッドA2(A::A2)に渡す内容を含んだメッセージである。
【0040】
OSは継続メソッド、継続メッセージを含む上記コンティネーション(Continuation)と呼ばれる実体を内部に生成する。ここでのコンティネーション(Continuation)の生成は前記図5での説明で述べたフューチャ(Future)の例と同様、後述するメタオブジエクト(MDriveMailre)等のメイラオブジェクトの実行によりメモリ内にコンティネーション(Continuation)に必要な領域を確保する。
【0041】
図8はコンティネーション(Continuation)の属性を示している。ここにはコンティネーション(Continuation)を生成したオブジェクトを特定するためのID(Thread IDcreator)、継続メソッド(Selector method)、継続メッセージ(void*message)を格納する領域が定義されている。このコンティネーション(Continuation)の属性は、図8に示されており、コンティネーション(Continuation)を生成したオブジェクトを特定するためのID(ThreadID creator)、選択される継続メソッド(Selector method)及び継続メッセージ(void* Message)を保存する領域が定義されている。図7の例ではセンド(Send)により、オブジェクトA、メソッドA2、メッセージ(contMsg)が送られると、OSがコンティネーション(Continuation)を生成し、ID(ThreadID creator)にはオブジェクトA、継続メソッド(Selector Method)にはメソッドA2、及び継続メッセージ(void* Message)にはメッセージ(contMsg)が保存される。
【0042】
メソッドB1(B::B1)はメソッドA1(A::A1)から配送されたメッセージの内容の他、そのコンティネーション(Continuation)を特定するためのIDとしてOSにより生成されたコンティネーションID(ContID)を受け取る。図7の例では、contIDとして受け取っている。このコンティネーションID(ContID)はキック(Kick)の引数として使われる。なお、キック(Kick)とはメタスペース(mDrive)におけるAPIの一つであり、本実施の形態ではコンティネーションID(ContID)をオブジェクトAに与えることでコンティネーション(Continuation)の中味の情報を得る際に用いられる。このキック(Kick)には、その引数として上記コンティネーションID(ContID)を備える。メタスペース(mDrive)のオブジェクトはコンティネーション(Continuation)をキック(Kick)することで、コンティネーション(Continuation)に含まれる情報を意識せずに継続メソッドを起動することができる。図7の例では、メソッドB1(B::B1)は受け取ったコンティネーションID(contID)をそれ自身がキック(Kick)し、これによりメソッドA1(A::A1)が指定した継続メソッドA2(A::A2)が起動され、メソッドB1の結果と継続メッセージ(contMsg)が渡される。
【0043】
このように、コンティネーション(Continuation)は、メッセージを受信したオブジェクトが、誰がメッセージを送信したのか、あるいはどこに返答を送信すればよいのかを意識することなく、継続メソッドを起動できる(そのときに、返答を送信することができる)。メタスペース(mDrive)通信機構の仕様では、コンティネーションID(ContID)はOSがメッセージの受信側にメッセージと共に配送するので、送信側にはコンティネーションID(ContID)は現れない。
【0044】
[メタスペース(mLocal)通信機構とメタスペース(mDrive)通信機構の比較]
メタスペース(mLocal)通信機構の仕様において、メソッドの実行の並行性は、あるメソッドの開始から終了までの間にのみ存在する。このセマンティクスは並行性は高くないが(メタスペース(mDrive)通信機構の仕様に比べて)、プログラマが直感的に理解しやすい、記述しなければならないコードの量を少なくし易いなどの利点がある。しかし、この仕様では、割込みを使ったデバイスドライバのような非同期な事象を効率的に記述することができない。
【0045】
メタスペース(mDrive)通信機構の仕様では、メソッドを一度終了した後の継続メソッドを指定することができる。割込みのような非同期な事象に対応して返答を送信するとき、コンティネーション(Continuation)をキック(Kick)することによってあらかじめ指定された継続メソッドを起動できる。そのため、デバイスドライバのような非同期な事象を処理するプログラムを効率的に記述することができる。これは並行性の高いプログラムを記述できるが(メタスペース(mLocal)通信機構の仕様に比べて)、プログラマが直感的に理解し難い、記述しなければならないコードの量が多くなり易いなどの欠点がある。
【0046】
[本発明方法における通信機構の実現方式]
本発明方法では、メタスペースが提供する機能は、メタスペースを構成するオブジェクトによって実現する。このようなオブジェクトを、メタスペースが提供する機能を使うオブジェクトに対して特にメタレベルオブジェクト、またはメタオブジエクトと呼ぶ。一方、メタスペースが提供する機能を使うオブジェクトをベースレベルオブジェクト、またはベースオブジェクトと呼ぶ。
【0047】
各メタスペースに共通な機能を提供するオブジェクトとして(これから説明を進める各通信機構を実現するための構成要素として)、例えばスケジューラ(Scheduler)と呼ぶものを用いることができる。スケジューラ(Scheduler)はオブジェクトの状態を管理するメタオブジェクトである。本実施の形態で必要になるスケジューラ(Scheduler)の仕様は後述する。
【0048】
一方、メタスペース(mLocal)とメタスペース(mDrive)の通信機構はそれぞれのメタスペースで異なる機構なので、それを実現するための機能を提供するメタオブジエクトは、それぞれに定義することができる。ここでは、メタスペース(mLocal)通信機構にてメッセージの配送を実現するメタオブジエクトをメタオブジエクト(MLocalMailer)、メタスペース(mDrive)通信機構にてメッセージの配送を実現するメタオブジエクトをメタオブジエクト(MDriveMailer)と呼ぶ。
【0049】
メタスペース(mLocal)通信機構はメタオブジエクト(MLocalMailer)、スケジューラ(Scheduler)、そしてそれらの実行を支援する他のモジュールによって実現される。また、メタスペース(mDrive)通信機構はメタオブジエクト(MDriveMailer)、スケジューラ(Scheduler)、そしてそれらの実行を支援する他のモジュールによって実現される。ここではメタオブジエクト(MLocalMailer)とスケジューラ(Scheduler)、メタオブジエクト(MDriveMailer)とスケジューラ(Scheduler)の関係にシナリオを与え、各通信機構の実現方式を示す。また、それぞれフューチャ(Future)とコンティネーション(Continuation)の属性を与え、シナリオによってそれらの状態遷移を示す。
【0050】
[フューチャ(Future)とメタスペース(mLocal)通信機構の実現方式]
図9から図12はメタオブジエクト(MLocalMailer)とスケジューラ(Scheduler)の関係をシナリオ(フローチャート)によって与える。
【0051】
図9はメタスペース(mLocal)のセンド(Send)の手続きを示している。
【0052】
この図9において、先ずメタスペース(mLocal)上のベースオブジェクトがセンド(Send)を実行すると、メタスペース(mLocal)を構成する通信機構のためのメタオブジェクト(MLocalMailer)に処理が移ると共にベースオブジェクトはステップST7のようにウェイト(Wait)の状態となる。ここで、ベースオブジェクトからメタオブジエクトへ処理の状態が移ることを、以下にM(Meta Computation)と表現する。
【0053】
このように処理が移ると、メタオブジエクト(MLocalMailer)は、ステップST1として、フューチャ(Future)を生成する。
【0054】
次に、ステップST2として、メッセージ(ActiveMessage)を配送する宛て先のオブジェクトのメッセージキュー(メッセージの並び)の状態を調べる。このとき、メッセージキューにメッセージがない場合(FALSE、偽)には、そのオブジェクトは休眠状態(スケジューラ(Scheduler)が管理している状態では休止(Dormant))なので、ステップST5として、スケジューラ(Scheduler)にメイクレディ(MakeReady)を発行(issue)してオブジェクトを実行可能状態(スケジューラ(Scheduler)が管理している状態ではレディ(Ready))にする。ここで簡単にメッセージキューについて解説する。図13に示すように、CPUはオブジェクト内の1つのスレッドを実行する際、配送されたメッセージを利用する。メッセージキューはメッセージの並びを示し、メッセージキュー内のメッセージを順次利用するように構成される。なお、メイクレディ(MakeReady)はスケジューラ(Scheduler)にそのオブジェクトが実行可能とするために用いられるAPIであり、上記レディ(Ready)は実行可能状態を、上記ドーマント(Dormant)はオブジェクトが休止状態であることを表す。上記ドーマント(Dormant)時は、オブジェクトが何も実行せずメッセージを受信できる状態を表す。メイクレディ(MakeReady)には、引数としてベースオブジェクトを特定する(Thread of base)(この実施の形態ではオブジェクトB)、宛先のメソッド(method)、メッセージ(msg)を持つ。よって、この実施の形態ではベースオブジェクトBを指定してメソッドBにメッセージ(msg)を送るように管理する命令をスケジューラ(Scheduler)に送ることになる。
【0055】
一方、ステップST2において、メッセージキューにメッセージがある場合(TRUE、真)には、すでにそのメッセージが宛て先のオブジェクトに配送されて、そのオブジェクトが実行可能状態(レディ(Ready))、オブジェクトが実行状態(ランニング(RUNNING))なので、ステップST4として、メッセージキューの最後にそのメッセージを入れて終了する。このとき、メッセージ送信に対応したフューチャ(Future)を特定できるフューチャID(futureID)もあわせてメッセージキューで管理する。なお、これらの状態については後述する図28にて説明する。
【0056】
その後は、ステップST6で配送完了であることを示す返り値サクセス(sSuccess)をメタメッセージ(MetaMessage)に入れ、ベースオブジェクトに状態遷移を戻す。その後ベースオブジェクトはステップST8のように実行或いは実行可能状態となる。ここで、これ以降、メタオブジェクトからベースオブジェクトへ状態遷移が戻ることをR(Resume)と表す。上記メタメッセージ(MetaMessage)とは、メタスペース(mLocal)上のベースオブジェクトがセンド(Send)をするとき、当該センド(Send)に必要なパラメータ(引数)を持ったメッセージである。
【0057】
なお、上述したM(Meta Computation),R(Resume)については、先に示した特願平8−67881号の明細書及び図面に詳しく示されている。
【0058】
図10はメタオブジエクト(MLocalMailer)によるリプライ(Reply)に関する手続きを示している。
【0059】
この図10において、初めにステップST11として、メタオブジエクト(MLocalMailer)はどのベースオブジェクトがリプライ(Reply)してきたのかを確認する。図3、図4の例で言えば、ベースオブジェクトBがリプライ(Reply)を発行(issue)することが確認される。なお、この確認として、本実施の形態ではAPIの例えば関数GetLast()を使うようにしているが、ここではどのような方法でもよい。またこのときのベースオブジェクトはステップST24のようにウェイト(Wait)の状態となる。
【0060】
次に、ステップST12からステップST14として、このベースオブジェクトを起動したときに一緒に配送されたフューチャID(futureID)が特定するフューチャ(Future)が本当にメタスペース(mLocal)のフューチャ(Future)かどうか確認する。ステップST12,ST14で偽と判断されたらエラーとし、ステップST22へ進む。ステップST13が偽のときは、本実施の形態の主題であるタグを使った通信機構で他のメタスペースと通信する場合に相当し、後述するメタオブジェクト(Deliverer)に処理を依頼する。
【0061】
ステップST12からステップST14において、そうであることが確認されたら、ステップST15として、そのフューチャ(Future)の属性(creator)の状態を調べる。このとき、属性(creator)はリプライ(Reply)をしたベースオブジェクトにメッセージを送ったオブジェクトを含み、図3、図4の例で言えばリプライ(Reply)をしたベースオブジェクトBにメッセージを送ったオブジェクトはAであり、領域(ThreadID Creator)に保存されている。
【0062】
次に、ステップST16として、そのオブジェクトが待ち状態(ウェイト(Wait))になっているかどうかを調べ、そのオブジェクトが待ち状態(ウェイト(Wait))になっている場合は、ステップST17のようにそのオブジェクトがウェイトフォー(WaitFor)を実行している場合である。ウェイトフォー(WaitFor)の実行は前に図3、図4の説明で述べているように、引数としてフューチャID(futureID)、返答メッセージ(&msg)、サイズ(sizeof(msg))を有し、いま扱っているフューチャID(futureID)とウェイトフォー(WaitFor)に与えられたフューチャID(futureID)は等しく、リプライ(Reply)により送られたメッセージ(msg)が引数(&msg)に与えられる。待ち状態のオブジェクトは前記メイクレディ(MakeReady)によって再び実行可能状態になる。つまり、図3、図4の例では、オブジェクトAが実行可能状態に復帰する。
【0063】
なお、この場合の宛先のメソッドはウェイト(wait)状態なので、指定は不要だからUNDEF(undefine)、メッセージ(msg)も不要なのでNULLとされている。
【0064】
一方、ステップST16において、属性(creator)が待ち状態でない場合は、まだウェイトフォー(Waitfor)を実行していない。したがってこのとき、メタオブジエクト(MLocalMailer)は、ステップST19としてフューチャ(Future)の属性(isReplyDone)をセットし、リプライ完了のマークを入れる。さらに必要に応じてステップST18のようにメッセージ(message)に返答メッセージを一時的に保存する。
【0065】
その後は、ステップST20にてフューチャ(Future)を削除し、さらにステップST21では配送完了の返り値サクセス(sSuccess)をメタメッセージ(MetaMessage)に入れ、ステップST22ではエラーを示す返り値をメタメッセージ(MetaMessage)に入れ、ステップST23では配送完了の返り値サクセス(sSuccess)をメタメッセージ(MetaMessage)に入れる。その後ベースオブジェクトはステップST25のように実行或いは実行可能状態となる。
【0066】
図11と図12はウェイトフォー(WaitFor)の手順であり、図11はリプライ(Reply)がウェイトフォー(WaitFor)よりも先に実行された場合(図4の場合)、図12はその逆(図3の場合)を示している。これらは図10の説明に対応している。なお、これ以降、ベースオブジェクトの流れは図示を省略する。
【0067】
図11において、初めにステップST31ではフューチャ(Future)の確認を行い、ステップST32ではフューチャ(Future)の属性(isReplyDone)がセットされている(リプライ(Reply)が既に行われている)かどうかの確認を行う。これらステップST31、ST32にて共に真(TRUE)とされた時には、ステップST33にてフューチャ(Future)内にセットされた結果、メッセージをウェイトフォー(WaitFor)のメッセージ(&msg)に入力し、その後は、ステップST34にてフューチャ(Future)を削除し、さらにステップST35では配送完了のサクセス(sSuccess)をメタメッセージ(MetaMessage)に入れる。ステップST31で偽と判断されたら、ステップST36ではエラーコードをメタメッセージ(MetaMessage)に入れ、R(Resume)を行う。なお、ステップST32で偽と判断されたら、図12に示すステップST43へ移行する。
【0068】
一方、図12において、初めにステップST41ではフューチャ(Future)の確認を行い、ステップST42ではフューチャ(Future)の属性(isReplyDone)がセットされていないかどうかの確認を行う。これらステップST41、ST42にて共に真(TRUE)とされた時には、ステップST43にて待ち状態となされ、その後、ステップST44ではサクセス(sSuccess)をメタメッセージ(MetaMessage)に入れ、ステップST45ではメタコール(MetaCall)を終了する。ステップST41にて偽と判断されたらステップST46にてエラーコードをメタメッセージ(MetaMessage)に入れ、R(Resume)を行う。ステップST42にて偽と判断されたら図11のステップST33へ移行する。なお、図11、図12の例は共にベースオブジェクトがメタオブジエクト(MLocalMailer)にウェイトフォー(WaitFor)を依頼し、R(Resume)されるまでウェイト(Wait)の状態となる(図示せず)。
【0069】
[コンティネーション(Continuation)とメタスペース(mDrive)通信機構の実現方式]
図14から図18にはメタオブジエクト(MDriveMailer)とスケジューラ(Scheduler)の関係をシナリオによって与える。メタオブジエクト(MDriveMailer)はデバイスドライバのためのメタスペースなので、その手続きは前記メタオブジエクト(MLocalMailer)に比べてやや複雑である。その一つに遅延実行テーブル(DelayedExecutionTable)がある。メタオブジエクト(MDriveMailer)においてセンド(Send)やキック(Kick)の手続きは、メタスペース(mDrive)上のオブジェクトがセンド(Send)やキック(Kick)を依頼したときに、遅延実行テーブル(DelayedExecutionTable)への登録だけが行われ、実際のメッセージの配送は、メソッドの終了時(Exitするとき)にまとめて行われる。
【0070】
図14はメタオブジエクト(MDriveMailer)におけるセンド(Send)の手続きを示す。
【0071】
この図14において、ステップST51では、すでに述べたようにセンド(Send)の処理を遅延実行テーブル(DelayedExecutionTable)に登録する。すなわち、当該テーブルにメタメッセージ内の遅延実行用引数を登録する。ここでは、メタスペース(mDrive)上のベースオブジェクトがセンド(Send)をするとき、センド(Send)に必要なパラメータが入った実体としてのメタメッセージ(MetaMessage)が遅延実行テーブル(DelayedExecutionTable)に登録される。その後、ステップST52ではサクセス(sSuccess)をメタメッセージ(MetaMessage)に入れ、R(Resume)を行う。
【0072】
ここで、上述のメタメッセージ(MetaMessage)の構成について簡単に説明する。
【0073】
メタメッセージ(MetaMessage)は図19に示すように、2つの領域に分かれ、メタコール(metacall)のAPIを実行するために必要な情報(例えば引数)のための領域Aとエラー用コードを納める領域Bとを有する。なお、遅延実行テーブル(DelayedExecutionTable)は前記図5で示したフューチャ(Future)の生成と同じく、メイラ(mailer)のオブジェクトがメモリ内に当該テーブル用の領域を確保することで生成される。
【0074】
図15は、メタオブジエクト(MDriveMailer)におけるキック(Kick)の手続きである。
【0075】
この図15において、ステップST61では、図14と同様にキック(Kick)の処理を遅延実行テーブル(DelayedExecutionTable)に登録する。その後は、ステップST62にてサクセス(sSuccess)をメタメッセージ(MetaMessage)に入れ、R(Resume)を行う。
【0076】
図16はメタオブジエクト(MDriveMailer)の終了時(Exit)で、メタスペース(mDrive)上のベースオブジェクトが処理を終了するときに呼び出される手続きである。ここでは、遅延実行テーブル(DelayedExecutionTable)に登録された手続きを、処理の依頼された順序で実行し、最後にオブジェクトのメソッドの終了手続きをする。
【0077】
この図16のおいて、初めにステップST71として、終了(Exit)の手続きを依頼したベースオブジェクトを特定する(例えば関数GetLast()を使って特定する)。
【0078】
次に、ステップST72にて当該ベースオブジェクトが割込みによって起動されたかどうかを調べる。すなわち、終了(Exit)メソッドが起動された原因がベースオブジェクトの割り込みによるものか判断する。割り込みで起動された場合、その割り込みの前に更に別の割り込みが生じていた可能性が考えられる。図20に示すように、ベースオブジェクトIの実行中にベースオブジェクトIIが割り込んだ場合、ステップST73では今回の終了(Exit)が当該ベースオブジェクトIIの割り込みの終了(Exit)か否かを判断する。ステップST72、ステップST73にて共に真(TRUE)であると判断された場合は、ステップST74にて上記別の割り込みに戻る(Resume Interrupt)。また、ベースオブジェクトIが割り込みによって起動されたものではないとき(ステップST72:偽)、ステップST73は偽である。このように、ステップST72およびステップST73で偽と判断されたら、ステップST75のように、遅延実行テーブル(DelayedExecutionTable)に登録された手続きを処理する。この処理について、センド(Send)については後述する図17、キック(Kick)については後述する図18が示している。
【0079】
上記ステップST75の遅延実行テーブル(DelayedExecutionTable)のための処理を終えると、ステップST76にて再びそのベースオブジェクトが割込みで起動されたかどうか調べる。このステップST76は、ステップST72と実質的に同じである。ここで、もし割込みで起動されている場合は、ステップST77にて、そこから復帰するための手続き(ExitFromInterrupt())を実行して最初の割り込みを終了する。一方、割り込みで起動されていない場合は通常のオブジェクト間通信で起動された場合である。この場合、それまで実行していたオブジェクトを休眠状態にするために、ステップST78にて遅延実行テーブル(DelayedExecutionTable)を初期化し、スケジューラ(Scheduler)に休止(MakeDormant)するようにメッセージを送る。引数(BaseThread)はステップST71で特定されたベースオブジェクトである。さらに、ステップST79にて、そのベースオブジェクトのメッセージキューからそれまで実行していたメッセージを取り除く。
【0080】
ここでメッセージキューが空になった場合はそれで終了である。もしもメッセージキューが空ではなかった場合には、次に配送されるべきメッセージを引数にして、スケジューラ(Scheduler)に(再び、そのオブジェクトが引数で与えられるメッセージによって起動されるように)メイクレディ(MakeReady)を発行(issue)し、次のメッセージのためにそのオブジェクトを実行可能状態(Ready)にする。
【0081】
次に、図17と図18には、遅延実行テーブル(DelayedExecutionTable)に登録された手続きの一つを処理するシナリオを示す。当該テーブルに例えば10個が発行されれば10回実行が行われる。メッセージの有無によるスケジューラ(Scheduler)への依頼事項はメタオブジエクト(MLocalMailer)の場合と同じである。
【0082】
図17におけるメタオブジエクト(MDriveMailer)のセンド(Send)の場合は、先ず、ステップST81にてコンティネーション(Continuation)を生成する。
【0083】
次のステップST82にてメッセージの宛先がメタスペース(mDrive)オブジェクトか判断する。もし偽であれば、後述するメタオブジエクト(Deliverer)に処理の依頼を行わない、タグ通信が行われる。ステップST83ではメッセージ(ActiveMessage)を配送する宛て先のオブジェクトのメッセージキューの状態を調べる。このとき、メッセージキューにメッセージがない場合には、そのオブジェクトは休眠状態(スケジューラ(Scheduler)が管理している状態では休止(Dormant))なので、ステップST85として、スケジューラ(Scheduler)にメイクレディ(MakeReady)を発行(issue)してオブジェクトを実行可能状態(スケジューラ(Scheduler)が管理している状態ではレディ(Ready))にする。メッセージキューにメッセージが存在しない状態になると、ステップST84として、配送メッセージとコンティニュエーションをメッセージキューに格納する。
【0084】
一方、ステップST82及びステップST83において、真の場合には、すでにそのメッセージが宛て先のオブジェクトに配送されて、そのオブジェクトが実行可能状態、実行状態(RUNNING)、または実行中断状態(Suspend)なので、ステップST84として、メッセージキューの最後にそのメッセージを入れて終了する。このとき、メッセージ送信に対応したコンティネーション(Continuation)或いはそれを指し示すTID(後述する)もあわせてメッセージキューで管理する。
【0085】
図18におけるメタオブジエクト(MDriveMailer)のキック(Kick)の場合は、ステップST91において、与えられたコンティネーション(Continuation)がメタオブジエクト(MDriveMailer)のコンティネーション(Continuation)なのかどうかを確認する。ステップST91が真の場合はステップST92にてコンティネーション(Continuation)の存在を確認する。このコンティネーションが確認されたら、ステップST93で当該コンティネーション(Continuation)を開き、コンティネーション内の属性(宛先、メソッド、メッセージ(msg))をチェックし、それに基づいてセンド(Send)を行う。次のステップST94にてメッセージの確認を行い、ステップST95では、メッセージキューの最後にそのメッセージを入れて終了する。このとき、メッセージ送信に対応した後述するタグID(TID)もあわせてメッセージキューで管理する。
【0086】
一方、ステップST92、ST94にて、偽である場合は、ステップST96にてスケジューラ(Scheduler)にメイクレディ(MakeReady)を発行してオブジェクトを実行可能状態にする。そして、ステップST95として、メッセージキューにメッセージとメッセージ送信に対応したタグID(TID)とを格納する。なお、ステップST94、ST95、ST96は、図17のステップST83、ST84、ST85と同様の機能である。ステップST91で偽と判断されたら、後述するタグを使った通信機構で他のメタスペースと通信する場合に相当し、メタオブジェクト(Deliverer)に処理の依頼を行う。
【0087】
「タグを使った通信機構の基本的な説明」
オブジェクト間通信をするには、単純なメッセージ送信の他に、返答を受け取ったり他のメソッドの実行と同期をとることが必要になる。このとき、フューチャ(Future)やコンティネーション(Continuatin)のようなものが必要になる。このような複数のオブジェクト間通信(本実施の形態ではフューチャやコンティネーション等)で必要とされる同期や並行性を制御するデータ構造を本実施の形態ではタグと呼ぶ。ここでいうデータ構造とは例えばC言語やPASCALでいうところのStructureやC++でいうClassのような構造を示す。このタグとは異なるデータ構造をある共通のデータ構造で関連付けるものであり、この共通のデータ構造はこれらの異なるデータ構造を区別するための識別子(属性:例えばExecSpaceID mailer)を含むように構成される。さらに、同種類のデータ構造間の区別を与えるための識別子(属性:例えばlongword timeStamp)を有することでより多くのデータ構造が管理できる。詳細は図21の説明時に行う。また、タグを識別するために必要なIDをタグID(TID)と呼ぶ。
【0088】
ここで、タグの属性としてタグの型が必要になる。タグの型はそのタグがどの環境で使われるどのようをものかを特定できる必要がある。ただし、タグの型はグローバルに認識ができるものである必要はない。ある環境でそのタグの型を特定できなかった場合には、そのタグの型を特定できる他の独立したオブジェクトに問い合わせなどを行なうことでそれを解決することができればよい。
【0089】
ここでは、メタスペース(mLocal)とメタスペース(mDrive)におけるフューチャ(Future)、コンティネーション(Continuation)の例を使って、タグを使った異なるメタスペース間の通信について述べる。本実施の形態の例では、メタスペース(mLocal)にオブジェクトA、メタスペース(mDrive)にオブジェクトBが存在し、それぞれ前述同様に、以下のようなメソッドが定義されているとする。
【0090】
オブジェクトA
メソッドA1(A::A1)
オブジェクトB
メソッドB1(B::B1)
メソッドB2(B::B2)
このとき、以下の二通りについて、タグを使った異なるメタスペース間通信の基本的な動作について述べる。
【0091】
1.オブジェクトA(メソッドA1(A::A1))がメソッドB1(B::B1)にセンド及びウェイトフォー(Send+WaitFor)する場合
2.オブジェクトB(メソッドB1(B::B1))がメソッドA1(A::A1)にセンド(Send)し、継続メソッドとしてメソッドB2(B::B2)を指定した場合
[オブジェクトA(メソッドA1(A::A1))がメソッドB1(B::B1)にセンド及びウェイトフォー(Send+WaitFor)する場合]
メソッドA1(A::A1)はセンド(Send)(オブジェクトB,メソッドB1,メッセージ(mag),関数sizeof(msg),フューチャID(&futureID))を実行する。このとき、実際にこの手続きを処理するメタオブジエクト(MLocalMailer)はフューチャ(Future)を生成する。フューチャ(Future)は次の要件を満たしていればよい。すなわち、
フューチャ(Future)がタグIDで特定できるユニークな実体であること、
タグの型がメタスペース(mLocal)のフューチャ(Future)であることを示すこと、及び
図6で示したフューチャ(Future)の属性を持っていること。
【0092】
メタオブジエクト(MLocalMailer)は、なんらかの方法でメタオブジエクト(MDriveMailer)にメッセージ(msg)をオブジェクトBまで配送するように依頼すると共に、メソッドB1(B::B1)を起動するように依頼をする。このとき、フューチャ(Future)を特定することができるタグIDをあわせて配送する。また、このときオブジェクトAはそのフューチャ(Future)を後に特定することができるようにフューチャID(futureID)を受け取る。ここではその型の変数をフューチャID(futureID)としている。このIDは、タグIDをメタスペース(mLocal)の仕様にあわせてマップしたものであると考えられる。
【0093】
オブジェクトBは、そのメッセージ(msg)によってメソッドB1(B::B1)が起動されたとき、そのメッセージがどこから配送されたかを知ることはできない(或いは知るべきではない)。これが透明性のあるオブジェクト間通信の実現で要求される。メソッドB1(B::B1)は起動されるときに、コンティネーション(Continuation)がメッセージ(msg)といっしょに配送される。コンティネーション(Continuation)は型(コンティネーションID(contID))として扱い、ここではその変数を(contID)とする。この変数(contID)は先のフューチャID(futureID)と同じタグを特定していることになる。
【0094】
メソッドB1(B::B1)の実行が進むとキック(Kick(contID))を実行する。このとき、メタオブジエクト(MDriveMailer)はコンティネーションID(変数contID)で特定できるタグの型をチェックする。このとき、タグIDの管理方式の観点から、次の二つの可能性がある。
【0095】
1.メタオブジエクト(MDriveMailer)がコンティネーションID(contID)で特定できるタグの型をメタスペース(mLocal)のフューチャ(Future)であるとわかる場合(タグIDの管理方式(1))
2.メタオブジエクト(MDriveMailer)がコンティネーションID(contID)で特定できるタグの型を知ることができない場合(タグIDの管理方式(2))
前者の場合、メタオブジエクト(MDriveMailer)はなんらかの方法でメタオブジエクト(MLocalMailer)に直接タグIDを配送することができる。メタオブジエクト(MLocalMailer)はタグIDが配送されると、それはメタスペース(mLocal)上でリプライ(Reply())が行われるのとまったく同じように処理を進めることができる。すなわち、タグID(=フューチャID(futureID))に対応したフューチャ(Future)に対して、図10で示したシナリオと同様にメソッドA1(A::A1)の実行を再開させたり、返答メッセージをフューチャ(Future)に一時的に保存しておくことができる。
【0096】
後者の場合、タグIDをメタオブジエクト(MLocalMailer)に配送する方法として、次の方法が考えられる。
【0097】
1.タグの型を管理している別のオブジェクトがあり、そのオブジェクトはタグIDを与えるとそのタグIDの型を調べ、そのタグを処理できるAPIとしてのメイラ(Mailer)を教えてくれるメソッドを用意する。メタオブジエクト(MDriveMailer)はこのメソッドを利用して、そのタグIDをメタオブジエクト(MLocalMailer)に配送すればよいことを知ることができ、直接メタオブジエクト(MLocalMailer)にタグIDを配送する方法(タグIDの管理方式(2A))
2.タグの型を管理している別のオブジェクトがあり、そのオブジェクトは与えられたタグIDを直接それに対応したタグを処理できるメイラ(Mailer)に配送してくれる方法(タグIDの管理方式(2B))
これらの場合も、最終的にはメタオブジエクト(MLocalMailer)にタグIDが配送され、図10で示したシナリオと同様にメソッドA1(A::A1)の実行を再開させたり、返答メッセージをフューチャ(Future)に一時的に保存しておくことができる。
【0098】
[オブジェクトB(メソッドB1(B::B1))がメソッドA1(A::A1)にセンド(Send)し、継続メソッドとしてメソッドB2(B::B2)を指定した場合]
メソッドB1(B::B1)はセンド(オブジェクトA,メソッドA1,メッセージ(msg),関数(sizeof(msg)),メソッドB2、メッセージ(contMsg))を実行する。このとき、実際にこの手続きを処理するメタオブジエクト(MDriveMailer)はコンティネーション(Continuation)を生成する。コンティネーション(Continuation)は次の用件を満たすことになる。
【0099】
コンティネーション(Continuation)がタグIDで特定できるユニークな実体であること、
タグの型がメタスペース(mDrive)のコンティネーション(Continuation)であることを示すこと、及び
図8で示したコンティネーション(Continuation)の属性を持っていること。
【0100】
メタオブジエクト(MDriveMailer)を含むOSは、なんらかの方法でメタオブジエクト(MLocalMailer)にメッセージ(msg)をオブジェクトAに配送し、メソッドA1を起動するように依頼する。このとき、コンティネーション(Continuation)を特定することができるタグIDをあわせて配送する。
【0101】
メタスペース(mDrive)の通常のオブジェクト間通信では、このタグIDはコンティネーションID(ContID)として扱われるものになる。しかし、この場合はメタオブジエクト(MLocalMailer)ではそれをコンティネーションID(ContID)として扱う必要はなく、タグIDとして扱う。そして、メタスペース(mLocal)の通常のオブジェクト間通信ではメッセージを配送してあるメソッドを起動すると、それにフューチャ(Future)(またはフューチャID(futureID))が関係付けられるのと同様に、メタオブジエクト(MDriveMailer)から配送されたタグIDが関係付けられる。
【0102】
メソッドA1(A::A1)の実行が進むとリプライ(Reply()またはReply(ReplyMsg))を実行する。このとき、メタオブジエクト(MLocalMailer)はメソッドA1(A::A1)を起動したときに関係付けられたタグIDを調べ、タグIDが特定するタグの型をチェックする。このとき、メタスペース(mLocal)上のオブジェクトAからメタスペース(mDrive)上のオブジェクトBに通信した場合と同様に、タグIDの管理方式の観点から、次の二つの可能性がある。
【0103】
1.メタオブジエクト(MLocalMailer)がタグIDで特定できるタグの型をメタスペース(mDrive)のコンティネーション(Continuation)であるとわかる場合(タグIDの管理方式(1))
2.メタオブジエクト(MLocalMailer)がタグIDで特定できるタグの型を知ることができない場合(タグIDの管理方式(2))
いずれの場合においても、メタスペース(mLocal)上のオブジェクトAからメタスペース(mDrive)上のオブジェクトBに通信した場合と同様、なんらかの方法でメタオブジエクト(MDriveMailer)にタグIDを配送できる。メタオブジエクト(MDriveMailer)はタグIDを受け取ると、図18で示したシナリオと同様の手続きを行なう。すなわち、はじめにタグIDに対応したコンティネーション(Continuation)を開き(Open)し、継続メソッドと継続メッセージを得る。そして、継続メソッドを配送するべきオブジェクト(コンティネーション(Continuation)のクリエータ(creator))のメッセージキューの状態に応じて、スケジューラ(Scheduler)をアクセスし、最終的にメソッドB2(B::B2)を起動する。
【0104】
「タグを使った通信機構の本実施の形態での実現事例」
本章では、本実施の形態において、タグを使ってそれぞれメタスペース(mLocal)、メタスペース(mDrive)に存在するオブジェクトが透明性を持って通信することを可能にした実現方式について述べる。ここでは異なる通信機構としてメタスペース(mLocal)通信機構とメタスペース(mDrive)通信機構の二つのみが存在することを仮定する。
【0105】
[フューチャ(Future),コンティネーション(Continuation)とタグ(Tag)]
メタスペース(mLocal)におけるフューチャ(Future)、メタスペース(mDrive)におけるコンティネーション(Continuation)を、OSではタグ(Tag)として扱うことが可能である。このとき、OSはタグ(Tag)がフューチャ(Future)であるかコンティネーション(Continuation)であるかを識別する必要がある。それを識別するための型としてAPIのメイラ(Mailer)のIDを使う。タグの型として使われるメイラID(MailerID)がメタオブジエクト(MLocalMailer)の場合にはフューチャ(Future)、メタオブジエクト(MDriveMailer)の場合にはコンティネーション(Continuation)であると認識することができる。
【0106】
図21はタグ(Tag)とフューチャ(Future)、コンティネーション(Continuation)の関係、タグ(Tag)とタグID(TID)の関係をいわゆるOMT(object modeling technique)法のオブジェクトモデル図で示している。クラスフューチャC1と、クラスコンティネーションC2はクラスタグC3から派生したサブクラスとして定義できる。タグ(Tag)はメイラ(Mailer)を識別するIDとして実行場所ID(ExecSpaceID)を使っている。この場合、実行場所ID(ExecSpaceID)は、そのオブジェクトを示すIDと等価な意味で使われている。タグ(Tag)はタグID(TID)というIDによって特定できる。タグ(Tag)に含まれるタイムスタンプ(timeStamp)はタグ(Tag)をタグID(TID)を使って特定するとき時間軸に対してユニークであることを保証するために使用される。フューチャ(Future)およびコンティネーション(Continuation)を特定することができれば、タイムスタンプ(timeStamp)は必ずしも使われる必要はない。
【0107】
メタスペース(mLocal)通信機構、メタスペース(mDrive)通信機構ではそれぞれフューチャ(Future)、コンティネーション(Continuation)を特定するためにフューチャID(futureID)、コンティネーションID(ContID)が使われる。タグ(Tag)を導入した場合、OS内ではこれらはすべて共通に表記されることのできるタグID(TID)として特定することができる。
【0108】
本実施の形態では、プログラマがメタスペース(mLocal)やメタスペース(mDrive)を提供しているインターフェースをそのまま使用することができるように、インターフェースを定義しているへッダフアイル(MLocal.h、MDrive.h)では型の再定義が行われている。すなわち、メタスペース(mLocal)のへッダフアイル(MLocal.h)ではフューチャID(futureID)をタグIDに再定義する。これを例えばC言語やC++の定義方法で示すと、typedef TID futureID;となる。なお、typedefは新しい型を定義(define)すると言う意味である。メタスペース(mDrive)のヘッダファイル(MDrive.h)のコンティネーションヘッダファイル(Cont.h)ではコンティネーションID(ContID)をタグIDに再定義している。これも同様に示すと、typedef TID ContID;となる。
【0109】
[タグIDの管理方式と当該タグIDを配送するオブジェクト(Deliverer)]
本実施の形態では、前記タグIDの管理方式(2B)を適用している。異なるメタスペース間の通信機構をサポートするメタオブジェクトとして、Delivererを導入する。オブジェクト(Deliverer)は主に二つのインターフェース(メソッド或いはAPI)を持つ。
【0110】
すなわち、その一つであるインターフェース(sError DeliverObject)は、メッセージ(msg)を指定されたオブジェクト(destination)(引数オブジェクトID(OID)及び宛先メソッド(sel)で示される。)に配送し、最終的にオブジェクト(destination)のメソッド(method)が起動されるよう、オブジェクト(destination)が存在するメタスペースのメイラ(Mailer)に依頼をする。このインターフェース(sError DeliverObject)は更に、引数の一つとして配送されるタグID(TID)を、オブジェクト(destination)が返答する場合に使用する。
【0111】
もう一方のインターフェース(sError DelivereTag)は、タグID(TID)を配送する。オブジェクト(deliverer)はタグID(TID)に対応したタグ(Tag)の型を調べ、どのメイラ(Mailer)にタグID(TID)を配送すればよいかを知る。必要に応じて、返答メッセージ(replyMsg)も配送する。
【0112】
相手先オブジェクト(destination)が存在するメタスペースのメイラ(Mailer)を知る方法としては、
1.オブジェクトの生成時にあらかじめオブジェクト(deliverer)に登録をして、オブジェクト(deliverer)がその内容を(テーブルなどを使って)管理する方法
2.オブジェクトから直接たどることができるデータ構造に、そのオブジェクトが所属しているメタスペースまたはメタスペースを識別できるなにかのIDを含めておく方法
が考えられる。本実施の形態では、後者の方法を使っている。
【0113】
[異なるメタスペース間通信の実際]
この異なるメタスペース間通信では、以下の二つの異なるメタスペース間通信(異なるメタスペースに存在するオブジェクト間通信)が考えられる。
【0114】
A.メタスペース(mLocal)オブジェクトがメタスペース(mDrive)オブジェクトと通信する(或いは通信して返答を受け取る)場合
B.メタスペース(mDrive)オブジェクトがメタスペース(mLocal)オブジェクトに通信する(或いは通信して返答を受け取る)場合
図22と図23は、オブジェクト(deliverer)を介して異なるメタスペース(メタスペース(mLocal)とメタスペース(mDrive))間通信を行なう場合の前者Aを、図24と図25は後者Bのシナリオを示している。
【0115】
図22において、メタオブジエクト(MLocalMailer)がベースオブジェクトのセンド(Send)の手続きの依頼を受け付けてからフューチャ(Future)を生成する処理(ステップST101)までは、図9と同様である。但し、このフューチャ(Future)はタグのサブクラスとして生成される。
【0116】
ここで、ステップST102では、メッセージの配送先の確認を行い、メッセージの配送先がメタスペース(mLocal)オブジェクトではない場合、オブジェクト(Deliverer)のメソッド(DeliverObject)にメッセージを送る。
【0117】
オブジェクト(Deliverer)はメソッド(DeliverObject)の引数にてその配送先を知ることができるので、ステップST103のように、そのメイラ(MDriveMailer)にさらに配送する。ステップST106以降に示す、メタオブジエクト(MDriveMailer)がインターフェース(DeliverObject)を通じて配送依頼された後の手続き(ステップST106、ST107、ST108)は、前述した図17のメタオブジエクト(MDriveMailer)が終了時(Exit)にセンド(Send)のために行なう手続き(ステップST83、ST84、ST85)と同様である。但し、この場合はステップST107にてメッセージキューにタグID(TID)を加えるようになっている。
【0118】
図23はメタスペース(mDrive)に配送されたタグID(TID)がメタスペース(mDrive)ではコンティネーションID(ContID)として扱われて、これをキック(Kick)した場合の手続きを示している。
【0119】
この図23において、メタオブジエクト(MDriveMailer)は、ステップST111にて終了時(Exit)のキック(Kick)のための処理時に指定されたコンティネーションID(ContID)がメタスペース(mDrive)のコンティネーション(Continuation)のものではないとわかる。そこでオブジェクト(Deliverer)のタグ(DeliverTag)を使ってタグID(TID)を配送する。
【0120】
オブジェクト(Deliverer)はステップST112にてタグID(TID)からタグ(Tag)を特定し、その属性(ExecSpaceID mailer)から、そのタグ(Tag)がメタオブジエクト(MLocalMailer)のもの(メタスペース(mLocal)のフューチャ(Future))とわかる。そこでメタオブジエクト(MLocalMailer)にそのタグID(TID)を配送する。
【0121】
メタオブジエクト(MLocalMailer)がタグID(TID)を受け取った後の手続きは、前述した図10のメタオブジエクト(MLocalMailer)のリプライ(Reply)と同様である(ステップST13が真であった場合以降ステップST14、ST15、ST16、ST17、ST20まで)。
【0122】
一方、図24、図25はメタスペース(mDrive)からメタスペース(mLocal)にメッセージを送信し、返答を受け取る場合のシナリオである。オブジェクト(Deliverer)の動作は図22、図23と同様である。
【0123】
すなわち、図24の例では、メタオブジエクト(MDriveMailer)がベースオブジェクトのセンド(Send)の手続きの依頼を受け付けてからコンティネーション(Continuation)を生成する処理(ステップST121)は、図17と同様である。
【0124】
ここで、ステップST122では、メッセージの配送先の確認を行い、メッセージの配送先がメタスペース(mDrive)オブジェクトではない場合、オブジェクト(mMLocal)のメソッド(DeliverObject)にメッセージを送る。
【0125】
オブジェクト(Deliver)はその配送先を知ることができるので、ステップST123のように、そのメイラ(MLocaMailer)にさらに配送する。ステップST126、ST127、ST128に示す、メタオブジエクト(MLocalMailer)がインターフェース(DeliverObject)を通じて配送依頼された後の手続きは、前述した図18のメタオブジエクト(MDriveMailer)が終了時(Exit)にセンド(Send)のために行なう手続き(ステップST94、ST95、ST96)と同様である。
【0126】
また、図25において、メタオブジエクト(MLocalMailer)は、ステップST131からステップST134にてReply処理時に指定されたフューチャID(futureID)がメタスペース(mLocal)のフューチャ(Future)のものではないとわかる(図10のステップST11、ST12、ST13と同様)。そこでオブジェクト(Deliverer)のタグ(DeliverTag)を使ってタグID(TID)を配送する(図10のステップST13の偽の場合と同じ)。
【0127】
オブジェクト(Deliver)はステップST135にてタグID(TID)からタグ(Tag)を特定し、その属性(ExecSpaceID meiler)から、そのタグ(Tag)がメタオブジェクト(MDriveMailer)のもの(メタスペース(mDrive)のコンティネーション(Continuation))とわかる。そこでメタオブジエクト(MDriveMailer)にそのタグID(TID)を配送する。
【0128】
メタオブジエクト(MDriveMailer)がタグID(TID)を受け取った後の手続き(ステップST138以降)は、前述した図18のメタオブジエクト(MDriveMailer)の処理(ステップST93、ST94、ST95、ST96)と同様である。
【0129】
「その他に考えられる実現方式」
本章ではこれまでに説明した実施の形態での実現方式以外に考えられる「タグを使った通信機構」の実現方式について述べる。
【0130】
[タグIDでタグの型を認識する方式]
本実施の形態では、タグ(Tag)の属性としてメイラ(Mailer)のIDを持っている。これによってタグ(Tag)の型を識別した。つまり、タグID(TID)からタグ(Tag)を特定し、その属性からタグの型を認識した。別の方法ではタグIDにタグの型を認識するための情報を付加する方式である。いまタグIDが32ビットで表わされる整数値だとした場合、例えば下位2ビットをタグ(Tag)の型のために使うという方式が考えられる。図26には、タグIDでタグの型を認証する方式の一例を表す。すなわちこの図26では、下位2ビットの組み合わせが00のときにはメタスペース(mLocal)のフューチャ(Future)を表すものとし、下位2ビットの組み合わせが01のときにはメタスペース(mDrive)のコンティネーション(Continuation)を表すものとする。このようにタグの実体を用いずにタグID(TID)にみを発生させて、このタグID(TID)にタグの属性を含めたOMTを図21に対して図27として示す。なお、図27中の指示符号C1,C2は図21と同じものである。このようにすれば、タグを介することなくフューチャやコンティネーションを対応付けることができる。この場合は、タグの領域をメモリ内に確保する必要がないので、メモリ領域を削減できる利益がある。なお、本実施の形態ではタグの下位2ビットを利用する例を述べたが、1ビット或いは上位、中位の任意のビットを用いても良いことは勿論である。
【0131】
[タグの管理方式]
本実施の形態では、前述したようにタグの管理方式(1)、(2A)、(2B)の可能性を示したが、いずれの方式もタグにはその属性として型があり、メイラ(Mailer)はその型を調べることで少なくともそのメイラ(Mailer)自身が処理できるタグかどうかを判断する方式について述べた。これらとは別に、タグの属性には型を持たせずに、ただそのメイラ(Mailer)が処理できるタグをメイラ(Mailer)内部に情報として管理するという方式が考えられる。
【0132】
この方式では、メイラ(Mailer)がフューチャ(Future)やコンティネーション(Continuation)を生成したら、その情報をメイラ(Mailer)自身が持つテーブルなどに保存する。リプライ(Reply)やキック(Kick)でタグを配送するとき、メイラ(Mailer)はそのテーブルを走査し、そのタグがそのメイラ(Mailer)で処理できる場合は通常のリプライ(Reply)、キック(Kick)の処理を行なう。そうでない場合は、タグの管理方式(2A)のように、どのメイラ(Mailer)にタグを配送すればよいか問い合わせたり、(2B)のように他のオブジェクトに処理の続きを依頼することができる。
【0133】
この場合、メイラ(Mailer)以外に(オブジェクト(Deliverer)のような)タグIDとそれに対応したタグを処理できるメイラ(Mailer)を知ることができるオブジェクトも、タグの属性としての型がない場合には、テーブルなどでその対応を管理する必要がある。
【0134】
図28には、スケジューラ(Scheduler)におけるスレッド(Thread)の状態遷移図を示し、以下にスケジューラ(Scheduler)の仕様の例を示す。
【0135】
各スレッド(Thread)は実行制御のために各状態を呈する。スケジューラ(Scheduler)はこれらスレッド(Thread)の状態変化を司り、優先順位のような属性(attribute)に基づいて次にどのスレッドを実行すべきかを決定する。
【0136】
休止状態(Dormant)はそのスレッド(Thread)に関して実行されるべきものが無いことを示す、このときのメッセージ(message)は受信可能の状態にある。
【0137】
実行可能状態(Ready)は、そのスレッド(Thread)は実行可能状態にあることを示し、スケジューラ(Scheduler)内の実行可能状態のスレッド(Thread)のためのキュー(レディキュー(Ready Queues))に入れられる(enqueue)。スレッド(Thread)が実行可能状態(Ready)のときそのスレッド(Thread)に対応付けられたオブジェクトはRで呼び起こされる。
【0138】
実行状態(Running)はそのスレッド(Thread)は実行中であることを示す。
【0139】
待機状態(Wait)は、オブジェクトの実行中断状態を示し、例えば前述のメタスペース(mLocal)通信機能によってウェイトフォー(WaitFor)がリプライ(Reply)よりも先に発行された場合に生ずる。
【0140】
ここでインターフェース(API)の例をいくつか示す。
【0141】
sError MakeReady(thread,sel,msg)
このインターフェース(API)はスレッド(Thread)によりリンクされた宛先オブジェクトのセレクタ(sel)で指定されるメソッドにメッセージ(msg)を送るためにメーラメタオブジェクト(例えば前述のメタオブジェクト(MLocalMailer))により使用される。
【0142】
スケジューラ(Scheduler)はスレッド(Thread)の状態を休止状態(Dormant)から実行可能状態(Ready)に遷移させ、上記レディキュー(Ready Queues)内の列にそれを入れる(enqueue)。
【0143】
宛先オブジェクトはスレッド(Thread)がスケジュールされた時、すなわち上記スケジューラ(Scheduler)により実行可能状態(Ready)のスレッド(Thread)が実行されるときに呼び起こされる。
【0144】
なお、sErrorはインターフェースの実行結果の状態を示し、メイクレディ(MakeReady)が正しく動作した場合、それを示す返り値(sSuccess)を返す。そうでない場合は各種のエラーを示す値を返す。
【0145】
sError MakeReady(thread)
このインターフェース(API)はスレッド(Thread)の実行を再開するためにメーラによって使用される。スケジューラ(Scheduler)はスレッド(Thread)の状態を待機状態(Wait)から実行可能状態(Ready)に変化させ、レディキュー(Ready Queues)内の列にそれを入れる(enqueue)。このインターフェースは例えば前述のメタスペース(mLocal)通信機能によってウェイトフォー(WaitFor)を発行して待機状態(Wait)にあるオブジェクトが、別のオブジェクトの発行したリプライ(Reply)によって結果メッセージを受け取り、実行可能状態にする必要があるときに使われる。
【0146】
sError MakeWait(thread)
このインターフェース(API)はスレッド(Thread)の実行を停止するために利用される。スケジューラ(Scheduler)はスレッド(Thread)を実行可能状態(Ready)から待機状態(Wait)に遷移させ、レディキュー(Ready Queues)内の列からそれを除く(dequeue)。なお、上記各メーラはベースオブジェクトの実行停止のため、このインターフェースを呼び出す必要はない。なぜならば、ベースオブジェクトが上述のM(Meta Computation)を使ってメーラを呼び起こす時にその状態は待機状態(Wait)に変化しているからである。
【0147】
sError MakeDormant(thread)
このインターフェース(API)はスレッド(Thread)の実行を終了するために上記メーラによって利用される。スケジューラ(Scheduler)はスレッド(Thread)の状態を実行可能状態(Ready)から休止状態(Dormant)に変化させ、レディキュー(Rdady Queus)内の列からそれを除く(dequeue)。
【0148】
なお、上記メーラ(mailer)からみたオブジェクト(又はそれに関連付けられたスレッド)の状態は、休止状態(Dormant)、実行可能状態(Ready)、待機状態(Wait)の3つである。これは複数の実行可能状態にあるオブジェクトのうち、どのオブジェクトをCPUが処理している(Running)かどうか、メイラは知る必要がないからである。
【0149】
【発明の効果】
本発明によれば、異なるオブジェクト間通信機構がそれぞれ固有に持つオブジェクト間通信の同期及び並行性の制御を行うためのタグを導入することによって、異なる環境間のオブジェクト間通信を透明性をもって容易に実現することができる。
【図面の簡単な説明】
【図1】本発明実施の形態のデータ通信方法が適用されるVCR装置の概略構成を示すブロック回路図である。
【図2】本実施の形態のVCR装置と通信用OS、AV用OSとAPIにより通信が行われる様子の説明に用いる図である。
【図3】メタスペース(mLocal)通信機構(ウェイトフォー(WaitFor)がリプライ(Replay)よりも先に実行された場合)の説明に用いる図である。
【図4】メタスペース(mLocal)通信機構(リプライ(Reply)がウェイトフォー(WaitFor)よりも先に実行された場合)の説明に用いる図である。
【図5】アプリケーションソフトがAPIによってメイラのオブジェクトやスケジューラのオブジェクトに通信を行う様子の説明に用いる図である。
【図6】フューチャ(Future)の属性の説明に用いる図である。
【図7】メタスペース(mDrive)通信機構の説明に用いる図である。
【図8】コンティネーション(Continuation)の属性の説明に用いる図である。
【図9】メタオブジエクト(MLocalMailer)とスケジューラ(Scheduler)の関係(メタスペース(mLocal)におけるセンド(Send)の実現)の手続きの流れを示す図である。
【図10】メタオブジエクト(MLocalMailer)とスケジューラ(Scheduler)の関係(メタスペース(mLocal)におけるリプライ(Reply)の実現)の手続きの流れを示す図である。
【図11】メタオブジエクト(MLocalMailer)とスケジューラ(Scheduler)の関係(メタスペース(mLocal)におけるウェイトフォー(WaitFor)でリプライ(Reply)がウェイトフォー(WaitFor)よりも先に実行された場合)の手続きの流れを示す図である。
【図12】メタオブジエクト(MLocalMailer)とスケジューラ(Scheduler)の関係(メタスペース(mLocal)におけるウェイトフォー(WaitFor)でウェイトフォー(WaitFor)がリプライ(Reply)よりも先に実行された場合)の手続きの流れを示す図である。
【図13】メッセージキューの説明に用いる図である。
【図14】メタオブジエクト(MDriveMailer)におけるセンド(Send)の手続きの流れを示す図である。
【図15】メタオブジエクト(MDriveMailer)におけるキック(Kick)の手続きの流れを示す図である。
【図16】メタオブジエクト(MDriveMailer)の終了時(Exit)で、メタスペース(mDrive)上のベースオブジェクトが処理を終了するときに呼び出される手続きの流れを示す図である。
【図17】遅延実行テーブル(DelayeExecutionTable)に登録(メタオブジエクト(MDriveMailer)のセンド(Send)の場合)された手続きを処理する流れを示す図である。
【図18】遅延実行テーブル(DelayeExecutionTable)に登録(メタオブジエクト(MDriveMailer)のキック(Kick)の場合)された手続きを処理する流れを示す図である。
【図19】メタメッセージ(MetaMessage)の構成の説明に用いる図である。
【図20】ベースオブジェクトIの実行中にベースオブジェクトIIが割り込んだ場合の動作説明に用いる図である。
【図21】タグ(Tag)とフューチャ(Future)、コンティネーション(Continuation)の関係、タグ(Tag)とタグID(TID)の関係をOMT法のオブジェクトモデルで示す図である。
【図22】オブジェクト(deliverer)を介して異なるメタスペース間通信を行なう場合(メタスペース(mLocal)がメタスペース(mDrive)に通信する場合)の往路の流れを示す図である。
【図23】オブジェクト(deliverer)を介して異なるメタスペース間通信を行なう場合(メタスペース(mLocal)がメタスペース(mDrive)に通信する場合)の復路の流れを示す図である。
【図24】オブジェクト(deliverer)を介して異なるメタスペース間通信を行なう場合(メタスペース(mDrive)がメタスペース(mLocal)に通信する場合)の往路の流れを示す図である。
【図25】オブジェクト(deliverer)を介して異なるメタスペース間通信を行なう場合(メタスペース(mDrive)がメタスペース(mLocal)に通信する場合)の復路の流れを示す図である。
【図26】タグlDでタグの型を認証する方式の一例を表す図である。
【図27】このタグID(TID)にタグの属性を含めたOMTを示す図である。
【図28】スレッド(Thread)の状態遷移図を示す。
【符号の説明】
mLocal,mDrive メタスペース、 MLocalMailer,MDriveMailer メタオブジエクト
Claims (6)
- ソフトウェア機能を実現するため複数のオブジェクト間で通信を行うデータ通信方法において、
異なるオブジェクト間通信機構をそれぞれ固有に持つ環境間でそれぞれ異なる実体を用いて通信を行う際、上記異なるオブジェクト間通信機構のデータ構造を共通のデータ構造で関連付けるタグを生成し、
上記タグを生成する際、上記タグを識別するためのタグIDと上記環境を特定するタグの型を示す属性とを、少なくとも生成し、
上記タグを通信メッセージと共に通信し、
上記タグの型を示す属性に基づいて上記実体を特定する
ことを特徴とするデータ通信方法。 - 上記タグの型を管理するオブジェクトを有する
ことを特徴とする請求項1記載のデータ通信方法。 - 上記タグIDはオブジェクトによって上記通信メッセージと共に配送される
ことを特徴とする請求項1記載のデータ通信方法。 - 上記タグIDを配送するオブジェクトは、上記タグの型に基づいて配送先を決定する
ことを特徴とする請求項3記載のデータ通信方法。 - 上記タグIDを配送するオブジェクトは、上記タグの型と配送先のテーブルを有する
ことを特徴とする請求項4記載のデータ通信方法。 - 複数ビットにて形成される上記タグIDに一部のビットを付加して上記タグの型を表す
ことを特徴とする請求項1記載のデータ通信方法。
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 | 김영돈, 정춘보 | 다수의 하드웨어에서 실행가능한 pda 어플리케이션제작방법 |
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 | パナソニック株式会社 | Icカード及び読み書き装置 |
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 | 액세스모바일 (주) | Id 태그 서비스 제공 시스템 및 방법 |
CN104063285B (zh) * | 2014-01-13 | 2017-06-23 | 惠州华阳通用电子有限公司 | 一种基于车载软件平台进程内模块间的消息广播通信方法 |
Family Cites Families (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH01502861A (ja) * | 1987-09-04 | 1989-09-28 | ディジタル イクイプメント コーポレーション | 多重転送プロトコルを支援するデジタル処理システム用回路網内のセッション制御 |
US5124909A (en) * | 1988-10-31 | 1992-06-23 | Hewlett-Packard Company | Software program for providing cooperative processing between personal computers and a host computer |
EP0501610B1 (en) * | 1991-02-25 | 1999-03-17 | Hewlett-Packard Company | Object oriented distributed computing system |
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 |
EP0604010B1 (en) * | 1992-12-21 | 1999-12-29 | Sun Microsystems, Inc. | Method and apparatus for subcontracts in distributed processing systems |
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 |
CA2240194C (en) * | 1995-12-15 | 2003-06-03 | Object Dynamics Corp. | 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 DE DE69837825T patent/DE69837825T2/de not_active Expired - Lifetime
- 1998-04-08 EP EP98302757A patent/EP0871119B1/en not_active Expired - Lifetime
Also Published As
Publication number | Publication date |
---|---|
EP0871119B1 (en) | 2007-05-30 |
KR19980080985A (ko) | 1998-11-25 |
EP0871119A1 (en) | 1998-10-14 |
JPH10283205A (ja) | 1998-10-23 |
DE69837825T2 (de) | 2008-01-31 |
DE69837825D1 (de) | 2007-07-12 |
US6466991B1 (en) | 2002-10-15 |
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 | |
US6157927A (en) | Methods and apparatus for enabling a component in a first transaction processing environment to access a resource in another environment that is under the control of an Xatmi complaint transaction manager | |
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 | |
EP2270657A1 (en) | Data processing method and device | |
JPH1063506A (ja) | タイプコードで解釈されコンパイル(編集)されたマーシャリングを可能にするトランスポートから独立した呼出しとサーバントインターフェイス | |
JP2000029707A (ja) | 高速なロ―カルcorbaオブジェクトレファレンスのための方法及び装置 | |
EP0850444A1 (en) | Support for application programs in a distributed environment | |
JP2002521765A (ja) | クラスタ化された計算処理環境において実行する分散ネットワークアプリケーションの管理用リクエストを処理するための方法および装置 | |
JP2000505224A (ja) | タイプされた継続を使用したデータ通信方法 | |
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 | |
JPH076043A (ja) | マルチスレッド・サーバ | |
JPH07502851A (ja) | 転位疑似通信点(疑似ソケット)の機能を利用する装置 | |
CN114296809B (zh) | 一种基于操作***的对象模型构建方法及其***调用接口 |
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 |