JP3238788B2 - オブジェクト通信方式 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、オブジェクトを単位と
して動作するコンピュータシステムにおけるオブジェク
トの通信方式に関する。

【０００２】

【従来の技術】オブジェクトを単位として動作するコン
ピュータシステムは、システムにおいて扱われるデータ
や手続きをカプセル化することを可能とし、その結果、
システムの安全性を飛躍的に高めることができる。ま
た、アプリケーション開発の過程において、オブジェク
トが有する継承機能及び多態性により、極めて効率的な
システム開発を可能とする。

【０００３】そして、このようなコンピュータシステム
においては、図１４に示されるように、例えばシステム
が、１台のＣＰＵ上で実行されるのか、或いは、ローカ
ルエリアネットワーク（ＬＡＮ）などによって接続され
た異なるＣＰＵ（ノード）上で実行されるのか、などと
いうことを規定するコンピュータレイアでの機能、及び
これらのＣＰＵ上でどのようにプロセス（又はタスク）
が実行されるのかということを規定するプロセスレイア
での機能などは、全てオブジェクトレイアにおけるオブ
ジェクトの構成とオブジェクト間でのメッセージの授受
という抽象的な機能によって隠蔽される。従って、ユー
ザは、オブジェクトの構成とオブジェクト間で授受され
るメッセージを規定するだけで、必要なアプリケーショ
ンを構築することができる。

【０００４】ここで、例えば多数のユーザが分散してア
プリケーションを開発するような場合、それぞれのユー
ザに対応して分散されたタスクの間でデータを通信する
必要性がしばしば生ずる。例えば、データベースシステ
ムの開発用アプリケーションにおいて、個々のデータベ
ースの定義はクライアント端末において実行されるクラ
イアントタスクにおいて行われ、それらの定義に基づく
データベースの構築はサーバ端末において実行されるサ
ーバタスクにおいて行われることがある。このような場
合には、クライアントタスクとサーバタスクとの間で、
種々のデータの通信が必要となる。

【０００５】そして、オブジェクトを単位として動作す
るコンピュータシステムでは、異なる分散されたタスク
の間でデータの通信が行われる場合には、当然、オブジ
ェクトを単位として通信する必要性が生ずる。

【０００６】図１５に、オブジェクト通信方式の従来技
術を示す。１つのタスクが通信を行いたい場合、そのタ
スクは、通信処理を行う専用の通信処理プログラムに対
して、送信依頼を発行する。

【０００７】この結果、通信処理プログラムは、タスク
が送信を行いたい送信オブジェクトの構造を解析した上
で、それをデータパケットに組み立てる。そして、通信
処理プログラムは、データパケットの送信に必要な量の
送信バッファを確保し、送信バッファへデータパケット
をコピーする。

【０００８】その後、通信処理プログラムは、下位レイ
アの通信処理プログラムへ、送信バッファの送信依頼を
発行する。一方、受信側のタスクにおいては、特には図
示しないが、やはり通信処理プログラムが、送信バッフ
ァを受け取った後、それに記憶されているデータで表さ
れるオブジェクトの構造を生成し、所定の順序に従って
共有メモリに記憶されているデータを、生成したオブジ
ェクトに格納する。

【０００９】

【発明が解決しようとする課題】しかし、上述の従来例
では、通信処理プログラムが通信対象のオブジェクトの
構造を認識できなければならない。従って、複雑な構造
を有するオブジェクト又はオブジェクトのグループが通
信される場合、通信処理プログラムが複雑なものとなっ
てしまう。逆に、通信処理プログラムを汎用的なものに
するためには、通信対象のオブジェクトの構造が一定の
構造のものに限定されてしまい、通信できるオブジェク
トの種類が極めて限られてしまうという問題点を有して
いる。

【００１０】また、上述の従来例においては、通信処理
プログラムと通信対象のオブジェクトとの不整合による
通信バッファアクセスエラー等の通信エラーが発生しや
すい、即ち、通信処理プログラムの規約に適合しないオ
ブジェクトが通信されてしまう可能性を完全に排除でき
ないため、通信処理プログラムがオブジェクトを適切に
送信できず（例えば通信バッファに展開できず）、又は
通信処理プログラムが受信内容（例えば通信バッファの
内容）を適切にオブジェクトに戻すことができないとい
う状態が発生しやすく、通信時の信頼性を高くできない
という問題点も有している。

【００１１】本発明は、信頼性が高く、かつ、多様な種
類をサポート可能なオブジェクト通信を実現することを
目的とする。

【００１２】

【課題を解決するための手段】本発明は、オブジェクト
を異なるタスク間で通信するオブジェクト通信方式を前
提とする。

【００１３】そして、まず、自オブジェクトに対応する
通信データの送信機能及び受信機能を有する通信オブジ
ェクトを有する。この通信オブジェクトは、例えば、ク
ライアント・サプライヤ関係を有するグループを形成し
ている各オブジェクトであり、その各オブジェクトがそ
れぞれ、その各オブジェクトに対応する通信データの送
信機能及び受信機能を有する。或いは、この通信オブジ
ェクトは、基底クラスから派生したクラスのオブジェク
トであり、その通信オブジェクトに関連するクラスのそ
れぞれに対応するその通信オブジェクトのメンバの送受
信機能を、例えばそれぞれのクラスで定義されたメンバ
関数として有する。

【００１４】次に、受信側のタスク内に、受信された通
信データに対応する通信オブジェクトを生成する通信オ
ブジェクト生成用オブジェクト（Receiverオブジェクト
に対応する）を有する。この通信オブジェクト生成用オ
ブジェクトは、例えば、受信された通信データに設定さ
れている識別子によって、その通信データに対応する通
信オブジェクトを生成する。また、この通信オブジェク
ト生成用オブジェクトは、リストオブジェクトを所有
し、そのリストオブジェクトは、通信データを判別する
ことによって所定のグループの通信オブジェクトを生成
する通信オブジェクト生成ルーチンオブジェクトを、複
数のグループに対応して複数所有するように構成でき
る。この場合、通信オブジェクト生成用オブジェクト
は、リストオブジェクトを介して各通信オブジェクト生
成ルーチンオブジェクトに受信された通信データを例え
ばそれに付加されている識別子によって判別させること
により、その通信データに対応する何れかの通信オブジ
ェクト生成ルーチンオブジェクトにその通信データに対
応する通信オブジェクトを生成させる。或いは、この通
信オブジェクト生成用オブジェクトは、複数の通信オブ
ジェクトのインスタンスをデータベースとして所有する
データベース管理オブジェクトを所有するように構成で
きる。この場合、通信オブジェクト生成用オブジェクト
は、データベース管理オブジェクトを介して通信オブジ
ェクトのインスタンスに受信された通信データを例えば
それに付加されている識別子判別させることによって、
その通信データに対応する何れかの通信オブジェクトの
インスタンスにそのインスタンス自身をコピーさせるこ
とにより、その通信データに対応する通信オブジェクト
を生成させる。

【００１５】以上の構成のもとで、送信側のタスク内の
通信オブジェクトが有する送信機能は、その通信オブジ
ェクトを、例えば共有メモリに格納する。一方、受信側
のタスク内の通信オブジェクト生成用オブジェクトは、
受信された通信データに対応する通信オブジェクトを生
成する。

【００１６】そして、その生成された通信オブジェクト
が有する受信機能は、例えば共有メモリとして受信され
た通信データを、その通信オブジェクト自身として受信
する。

【００１７】上述した発明の構成において、送信側のタ
スク内の通信オブジェクトによる送信動作時及び受信側
のタスク内の通信オブジェクトによる受信動作時の通信
プロトコルの制御を行う通信プロトコル制御手段（Send
erオブジェクト及びReceiverオブジェクトに対応する）
を更に有するように構成できる。なお、これらの制御
は、通信オブジェクト自身が行うように構成されてもよ
い。

【００１８】

【作用】本発明では、通信対象がオブジェクトであると
いう点を生かして、各通信オブジェクトが、自オブジェ
クトに対応する通信データの送信機能及び受信機能を有
する。この結果、通信オブジェクト自身が、その送信と
受信、例えば、通信バッファである共有メモリへの書込
み（アンパッケージング）と共有メモリからの読出し
（パッケージング）を行うため、通信処理の通信するデ
ータ形式の汎用性を考慮する必要がなくなり、その結
果、通信対象のオブジェクトに対する制限を除くことが
でき、多様なオブジェクトを通信することが可能とな
る。

【００１９】また、オブジェクト自身がそのオブジェク
トの送受信を行う結果、通信バッファアクセスエラー等
の通信エラーが発生する可能性は激減し、通信時の信頼
性を飛躍的に向上させることができる。

【００２０】更に、通信オブジェクト自身にそのオブジ
ェクトの通信機能を持たせる場合、予め基底クラスにそ
のメッセージの通信機能を持たせておき、通信オブジェ
クトを、基底クラスから派生したクラスであって基底ク
ラスにおけるオブジェクトの通信機能を継承した派生ク
ラスのオブジェクトとして生成させることにより、アプ
リケーションのオブジェクトに簡単にそのオブジェクト
の通信機能を持たせることができる。

【００２１】ここで、受信側のタスクでは、通信オブジ
ェクト生成用オブジェクトが、受信された通信データに
対応する通信オブジェクトを生成する。この場合、受信
された通信データに設定されている識別子によってその
通信データに対応する通信オブジェクトを生成すること
により、簡単な制御処理で対応する通信オブジェクトを
生成できる。また、通信オブジェクト生成用オブジェク
トが、所定のグループの通信オブジェクトを生成する通
信オブジェクト生成ルーチンオブジェクトを複数のグル
ープに対応して複数所有するリストオブジェクトを所有
することによって、受信されるオブジェクトのグループ
の種類が変更されても、そのような変更に対して、通信
オブジェクト生成用オブジェクトを修正することなく、
リストオブジェクトに対して通信オブジェクト生成ルー
チンオブジェクトを追加、削除、又は変更させるだけ
で、柔軟に対応することができる。或いは、通信オブジ
ェクト生成用オブジェクトが、複数の通信オブジェクト
のインスタンスをデータベースとして所有するデータベ
ース管理オブジェクトを所有することによって、受信さ
れるオブジェクトが変更されても、そのような変更に対
して、通信オブジェクト生成用オブジェクトを修正する
ことなく、データベース管理オブジェクトに対して通信
オブジェクトのインスタンスを追加、削除、又は変更さ
せるだけで、柔軟に対応することができる。

【００２２】一方、オブジェクト自身により送受信され
るそのオブジェクトが所定の通信プロトコルに従って通
信される場合に、この通信プロトコルに基づく制御を行
う機能を通信プロトコル制御手段として設けることによ
り、通信プロトコルに基づく制御機能を通信プロトコル
制御手段に担当させることができ、通信を行うアプリケ
ーションは、通信プロトコル制御手段にメッセージを送
るだけで、所定の通信プロトコルに沿った通信を実現で
き、アプリケーションにおけるオブジェクトの通信に対
する負荷及びエラー発生の可能性を軽減させることがで
きる。

【００２３】

【実施例】以下、図面を参照しながら本発明の実施例に
つき詳細に説明する。 ＜実施例の構成＞図１は、本発明の実施例の構成図であ
る。

【００２４】本実施例は、パーソナルコンピュータ用の
ウインドウシステムであるWindowsシステム上で実行さ
れるクライアント・サーバ型のWindows アプリケーショ
ンシステムとして実現されている。また、本実施例にお
けるオブジェクトは、コンピュータシステムがＣ＋＋プ
ログラミング言語に基づいて作成されたプログラムを実
行することにより、実現される。

【００２５】相互に通信を行うクライアントタスクとサ
ーバタスクは、それぞれ、１台のコンピュータシステム
上で実行され、或いは、ネットワークによって接続され
た異なるコンピュータシステム（ノード）（図１４参
照）上で実行され、更に、各ノード内には複数のプロセ
ス（タスク）が存在する。しかし、これらの関係は、オ
ブジェクトによって隠蔽されているため、アプリケーシ
ョン側では、オブジェクト通信の対象であるタスクがど
のようなコンピュータシステム上で実行されているかを
意識する必要はなく、オブジェクト間のインタフェース
のみを意識すればよい。

【００２６】クライアントタスクのアプリケーションオ
ブジェクトは、まず、送信されるべき送信オブジェクト
部１０１を生成した後、Senderオブジェクト１０２に対
して送信依頼メッセージを送信する。

【００２７】Senderオブジェクト部１０２は、後述する
ように、送信オブジェクト部１０１の送信受信バッファ
への書き込みを直接制御するものではなく、送信処理に
おける全体的なメッセージの授受のみを制御する。

【００２８】Senderオブジェクト部１０２は、送信依頼
メッセージを受信すると、送信オブジェクト部１０１に
対しバッファ書き込み依頼メッセージ１０７を送信す
る。送信オブジェクト部１０１は、このメッセージを受
信すると、自立的に、自オブジェクト内のメンバの、送
受信バッファオブジェクト部１０３への書込み（アンパ
ッケージング）を実行する。なお、後述するostrstream
オブジェクト及び共有メモリの部分が、送受信バッファ
オブジェクト部１０３に対応している。

【００２９】その後、Senderオブジェクト１０２は、通
信プロトコル制御部１０４に対し、送受信バッファオブ
ジェクト部１０３のサーバタスクへの送信を依頼する。
この結果、通信プロトコル制御部１０４は、予め設定さ
れたパスに沿って、上述の送受信バッファオブジェクト
部１０３をサーバタスクへ転送する。なお、後述するWi
ndows システムが、通信プロトコル制御部１０４に対応
している。

【００３０】サーバタスクのReceiverオブジェクト１０
５は、通信プロトコル制御部１０４から送受信バッファ
オブジェクト部１０３の受信通知を受け取ると、送受信
バッファオブジェクト部１０３内の識別子を判別するこ
とにより、受信すべきオブジェクトである受信オブジェ
クト部１０６を生成し、それに対して、バッファ読み込
み依頼メッセージ１０８を送信する。

【００３１】受信オブジェクト部１０６は、このメッセ
ージを受信すると、自立的に、送受信バッファオブジェ
クト部１０３内のデータの自オブジェクト内のメンバへ
の読み込み（パッケージング）を実行する。なお、後述
するistrstreamオブジェクトは、送受信バッファオブジ
ェクト部１０３の一部である。

【００３２】以上の基本構成に基づく、本実施例の詳細
な動作について以下に説明する。 ＜オブジェクトの基本構成＞アプリケーションの起動時
には、まず、図２及び図３に示されるように、クライア
ントタスクとしてアプリケーションオブジェクトNdbApp
が、また、サーバタスクとしてサーバオブジェクトServ
erが、それぞれ起動する。これらのオブジェクトは、ア
プリケーション又はサーバのインタフェースに関する機
能以外の機能を規定するオブジェクトである。

【００３３】次に、図２及び図３に示されるように、ア
プリケーションオブジェクトNdbApp及びサーバオブジェ
クトServerによって、それぞれ、アプリケーション用メ
インユーザウインドウオブジェクトMainUserWindow（以
下、アプリケーション用MainUserWindowオブジェクトと
いう）及びサーバ用メインユーザウインドウオブジェク
トMainUserWindow（以下、サーバ用MainUserWindowオブ
ジェクトという）が１個ずつ生成され、それぞれがアプ
リケーションオブジェクトNdbApp及びサーバオブジェク
トServerにより所有される。これらのオブジェクトは、
アプリケーションオブジェクトNdbApp及びサーバオブジ
ェクトServerのインタフェースに関する機能、例えば表
示装置に表示されるクライアントタスク及びサーバタス
クに関連するウインドウ上でのデータの表示機能、これ
らのウインドウ上でのコマンドの入力機能とその応答の
表示機能、及び本発明に関連するオブジェクト通信を実
現するためのＤＤＥ(Dynamic Data Exchange) 機能など
を規定するオブジェクトである。なお、アプリケーショ
ンオブジェクトNdbAppとサーバオブジェクトServerは、
それぞれのデータメンバMainWindowに格納されているポ
インタによって、生成されたアプリケーション用MainUs
erWindowオブジェクト及びサーバ用MainUserWindowオブ
ジェクトへアクセスする。

【００３４】また、アプリケーション用MainUserWindow
オブジェクト及びサーバ用MainUserWindowオブジェクト
が生成されるときに、それぞれの生成時に自動的に実行
されるそれらのメンバ関数であるコンストラクタによ
り、センダオブジェクトSender（以下、Senderオブジェ
クトという）とレシーバオブジェクトReceiver（以下、
Receiverオブジェクトという）が生成されて、それらが
アプリケーション用MainUserWindowオブジェクト及びサ
ーバ用MainUserWindowオブジェクトにより所有される。
なお、アプリケーション用MainUserWindowオブジェクト
は、そのデータメンバaReceiver 及びaSender にそれぞ
れ格納されているポインタによって、生成されたReceiv
erオブジェクト及びSenderオブジェクトへアクセスす
る。

【００３５】図６は、アプリケーション用MainUserWind
owオブジェクトとサーバ用MainUserWindowオブジェクト
のクラス構造を示した図である。アプリケーション用Ma
inUserWindowオブジェクトのクラスであるアプリケーシ
ョン用メインユーザウインドウクラスと、サーバ用Main
UserWindowオブジェクトのクラスであるサーバ用メイン
ユーザウインドウクラスは、それぞれ、ＤＤＥ処理を規
定する共通のＤＤＥ処理クラスから派生したクラスであ
る。また、ＤＤＥ処理クラスは、ウインドウ処理の基本
的なインタフェースを規定する基底クラスである共通の
ウインドウ処理クラスから派生したクラスである。

【００３６】従って、クラスが有する継承（インヘリタ
ンス）機能によって、アプリケーション用メインユーザ
ウインドウクラス及びサーバ用メインユーザウインドウ
クラスは、ＤＤＥ処理クラスが有する機能とウインドウ
処理クラスが有する機能を継承している。そして、アプ
リケーション用MainUserWindowオブジェクト及びサーバ
用MainUserWindowオブジェクトの生成時にアプリケーシ
ョン用メインユーザウインドウクラス及びサーバ用メイ
ンユーザウインドウクラスのコンストラクタが実行され
る場合、ＤＤＥ処理クラスのコンストラクタが呼び出さ
れ、このＤＤＥ処理クラスのコンストラクタによって、
図６に示されるように、SenderオブジェクトとReceiver
オブジェクトが生成される。

【００３７】これらのサーバオブジェクトServerとRece
iverオブジェクトの制御下で、アプリケーションオブジ
ェクトNdbApp又はサーバオブジェクトServerによって生
成された通信対象オブジェクトが、自立的に、自分自身
に対して共有メモリへのアンパッケージング又は共有メ
モリからのパッケージングを実行することにより、クラ
イアントタスクとサーバタスクの間のオブジェクト通信
が実現される。 ＜クライアントタスクとサーバタスクとの間のパスの設
定動作＞次に、クライアントタスクとサーバタスクとの
間のオブジェクト通信動作に先立って、クライアントタ
スクとサーバタスクとの間でＤＤＥプロトコルに従って
パスが設定される。この動作について、図２と図３を使
って説明する。

【００３８】まず、ユーザは、クライアントタスクのウ
インドウ画面上でパス設定コマンドを選択する。この結
果、アプリケーションオブジェクトNdbAppのパス設定用
メンバ関数は、Senderオブジェクトに対して、パス設定
を依頼するメッセージSetTarget を送信する（図２のＳ
１）。このメッセージには、オブジェクト通信を行いた
い宛て先のアプリケーション名などが含まれる。例え
ば、クライアントタスクからサーバタスクへのパスが設
定される場合には、アプリケーション名はサーバタスク
の名称である。

【００３９】Senderオブジェクトは、このメッセージに
対応するメンバ関数SetTarget を実行する。メンバ関数
SetTarget は、Windows システムの関数（以下、Window
s 関数という）であって、上記アプリケーション名を含
むパス設定依頼関数InitiateDDE をコールする（図２の
Ｓ２）。

【００４０】Windows 関数InitiateDDE は、サーバタス
クのサーバ用MainUserWindowオブジェクトに対し、その
オブジェクトで定義されているメンバ関数であるコール
バック関数WMDDEInitiate をコールすることにより、Se
nderオブジェクトのメンバ関数SetTarget によって指定
されたトピック名が、サーバ用MainUserWindowオブジェ
クトが所有するReceiverオブジェクトにおいて、サポー
トされているか否かを問い合せる（図３のＳ３）。この
場合、Windows システムは、各アプリケーションのMain
UserWindowオブジェクトの識別子であるハンドルを管理
しており、このハンドルによってサーバ用MainUserWind
owオブジェクトを識別する。

【００４１】コールバック関数WMDDEInitiate は、ま
ず、サーバ用MainUserWindowオブジェクトが所有するSe
nderオブジェクトに対して、リターンパスのハンドルで
あるアプリケーション用MainUserWindowオブジェクトの
ハンドルを設定するためのメッセージSetReturnTarget
を送信する（図３のＳ４）。Senderオブジェクトは、こ
のメッセージに対応するメンバ関数SetReturnTarget を
実行することにより、自オブジェクト内のデータメンバ
に、アプリケーション用MainUserWindowオブジェクトの
ハンドルを設定する。

【００４２】次に、コールバック関数WMDDEInitiate
は、上記問合せに対して、Receiverオブジェクトに予め
設定されているトピック名を検索することにより、Rece
iverオブジェクトにおいて問い合せられたトピック名が
サポートされていると判別すると、Windows 関数SendMe
ssage をコールすることにより、パス設定の依頼をした
クライアントタスクのアプリケーション用MainUserWind
owオブジェクトに対し、サーバ用MainUserWindowオブジ
ェクトのハンドルを通知する（図３のＳ５）。

【００４３】Windows 関数SendMessage は、クライアン
トタスクのアプリケーション用MainUserWindowオブジェ
クトに対し、そのオブジェクトで定義されているメンバ
関数であるコールバック関数WMDDEAckをコールすること
によって、サーバ用MainUserWindowオブジェクトのハン
ドルを通知する（図２のＳ６）。

【００４４】これに対応して、コールバック関数WMDDEA
ckは、アプリケーション用MainUserWindowオブジェクト
が所有するSenderオブジェクトに対して、送信パスのハ
ンドルであるサーバ用MainUserWindowオブジェクトのハ
ンドルを設定するためのメッセージSetTargetWindowHan
dle を送信する（図３のＳ７）。Senderオブジェクト
は、このメッセージに対応するメンバ関数SetTargetWin
dowHandle を実行することにより、自オブジェクト内の
データメンバに、サーバ用MainUserWindowオブジェクト
のハンドルを設定する。

【００４５】以上で、パスの設定動作が完了する。 ＜クライアントタスクとサーバタスクとの間のオブジェ
クト通信の全体動作＞上述の動作によりクライアントタ
スクとサーバタスクとの間に設定されたパスを使用する
ことにより、クライアントタスクとサーバタスクとの間
で実際のオブジェクトの通信が行われる。この動作につ
き、図４と図５を使って説明する。

【００４６】ここでは、まず、説明の簡単のため文字列
のオブジェクトを通信する場合の動作について説明する
が、勿論、オブジェクトの種類は何でもよい。まず、ア
プリケーションオブジェクトNdbAppは、送信対象となる
オブジェクトExStringを生成し、それへのポインタaExS
tring を保持する（図４のＳ１）。

【００４７】次に、アプリケーションオブジェクトNdbA
ppのオブジェクト送信用メンバ関数は、Senderオブジェ
クトに対し、送信対象オブジェクトExStringをSenderオ
ブジェクトにリンクさせるためのメッセージSetExData
を送信する（図４のＳ２）。このメッセージには、送信
対象オブジェクトExStringへのポインタaExString が付
加されている。

【００４８】Senderオブジェクトは、このメッセージに
対応するメンバ関数SetExData を実行する。この結果、
送信対象オブジェクトExStringは、Senderオブジェクト
によって所有される（図４のＳ３）。

【００４９】続いて、アプリケーションオブジェクトNd
bAppのオブジェクト送信用メンバ関数は、Senderオブジ
ェクトに対して、送信開始メッセージExSendを送信する
（図４のＳ４）。

【００５０】Senderオブジェクトは、このメッセージに
対応するメンバ関数ExSendを実行する。この結果とし
て、メモリ上のストリングの出力用のストリームオブジ
ェクトostrstream（以下、ostrstreamオブジェクトとい
う）が生成され、それへのポインタogs がSenderオブジ
ェクトによって保持される（図４のＳ５）。更に、メン
バ関数ExSendによって、Senderオブジェクトが所有して
いる送信対象オブジェクトExStringに対して、ポインタ
ogs によって指示されるostrstreamオブジェクトへの出
力メッセージprintOn が送信される（図４のＳ６）。

【００５１】これを受けて、送信対象オブジェクトExSt
ringは、このメッセージに対応するメンバ関数printOn
を実行する。この結果、送信対象オブジェクトExString
の内容が、自立的にostrstreamオブジェクトへ出力され
る（図４のＳ７）。このように、Senderオブジェクトが
送信対象オブジェクトExStringをostrstreamオブジェク
トへ出力するのではなく、送信対象オブジェクトExStri
ngに定義されたメンバ関数printOn によって自立的にそ
のオブジェクトの出力が行われて送信が実行される点
が、本発明に最も関連する大きな特徴の１つである。

【００５２】次に、Senderオブジェクトのメンバ関数Ex
Sendは、ostrstreamオブジェクトに対し、そこに格納さ
れている文字列の長さを問い合せるメッセージpcountを
送信する。ostrstreamオブジェクトは、このメッセージ
に対応するメンバ関数pcountを実行する。この結果、os
trstreamオブジェクトに格納されている文字列の長さが
Senderオブジェクトに通知される（図４のＳ８）。

【００５３】更に、Senderオブジェクトのメンバ関数Ex
Sendは、ostrstreamオブジェクトから通知された文字列
の長さを格納できるサイズを有する共有メモリを確保し
た後に、ostrstreamオブジェクトに格納されている文字
列を共有メモリにコピーする（図４のＳ９）。

【００５４】なお、共有メモリが共有メモリオブジェク
トとして実現され、送信対象オブジェクトExStringの内
容がostrstreamオブジェクトを介さずにメンバ関数prin
tOnによって直接共有メモリオブジェクトへ出力されて
もよい。

【００５５】Senderオブジェクトのメンバ関数ExSend
は、共有メモリへのコピーを行った後に、Windows 関数
PostMessage をコールすることにより、Windows システ
ムに、ＤＤＥプロトコルに基づく共有メモリの送信依頼
を行う（図４のＳ１０）。この結果、共有メモリが、Wi
ndows システムのメインシステムキューにポストされ、
以下、前述した設定動作によって予めクライアントタス
クとサーバタスクの間で設定されたパスに沿って、Wind
ows システムの制御の下で共有メモリの送信が行われ
る。

【００５６】Windows 関数PostMessage は、サーバタス
クのサーバ用MainUserWindowオブジェクトに対し、その
オブジェクトで定義されているメンバ関数であるコール
バック関数WMDDEData をコールすることにより、共有メ
モリへのポインタが付加されたＤＤＥメッセージをサー
バ用MainUserWindowオブジェクトに送信する（図５のＳ
１１）。

【００５７】コールバック関数WMDDEData は、まず、サ
ーバ用MainUserWindowオブジェクトが所有するReceiver
オブジェクトに対して、共有メモリからオブジェクトへ
のパッケージングを依頼するためのメッセージTakeoutO
bject を送信する（図５のＳ１２）。

【００５８】サーバ用MainUserWindowオブジェクトが所
有するReceiverオブジェクトは、上述のメッセージに対
応するメンバ関数TakeoutObject を実行する。このメン
バ関数TakeoutObject は、メモリへのストリングの入力
用のストリームオブジェクトistrstream（以下、istrst
reamオブジェクトという）を生成し、そのオブジェクト
へのポインタstを保持する（図５のＳ１３）。またメン
バ関数TakeoutObjectは、istrstreamオブジェクトのオ
ペレータ“＜＜”にメッセージを送り、そのオペレータ
に共有メモリのデータをistrstreamオブジェクトへ読み
込ませる（図５のＳ１４）。

【００５９】次に、Receiverオブジェクトは、istrstre
amオブジェクトに読み込まれたデータに設定されている
識別子を判別することにより、受信されるべきオブジェ
クトがExStringオブジェクトであることを判別する。そ
して、Receiverオブジェクトは、ExStringオブジェクト
を生成し、それへのポインタaExString を保持する。こ
こで、ExStringオブジェクトが生成されるときに、その
生成時に自動的に実行されるそのメンバ関数であるコン
ストラクタにより、istrstreamオブジェクトに格納され
ているデータが、自立的にExStringオブジェクトに読み
込まれる（図５のＳ１５）。このように、Receiverオブ
ジェクトがistrstreamオブジェクトの内容をExStringオ
ブジェクトに読み込むのではなく、ExStringのコンスト
ラクタによって自立的にそのオブジェクトへのデータの
読込みが行われて受信が実行される点が、本発明に最も
関連する大きな特徴の１つである。

【００６０】また、前述したように、共有メモリが共有
メモリオブジェクトとして実現される場合には、共有メ
モリの内容がistrstreamオブジェクトを介さずにExStri
ngオブジェクトのコンストラクタによって直接ExString
オブジェクトに格納されてもよい。次に、サーバ用Main
UserWindowオブジェクトが所有するReceiverオブジェク
トは、それが予め所有している受信キューであるQueue
オブジェクトに対し、キュー接続メッセージput を送信
する。Queue オブジェクトは、このメッセージに対応す
るメンバ関数put を実行することにより、ExStringオブ
ジェクトへのポインタaExString を自オブジェクト内の
受信キューへ接続する（図５のＳ１６）。

【００６１】その後、適当なタイミングで、サーバオブ
ジェクトServerのオブジェクト取出し用メンバ関数が、
サーバ用MainUserWindowオブジェクトが所有するReceiv
erオブジェクトに対して、受信されたExStringオブジェ
クトを受信キューから取り出すためのメッセージReceiv
eData を送信する（図５のＳ１７）。

【００６２】Receiverオブジェクトは、このメッセージ
に対応するメンバ関数ReceiveDataを実行する。このメ
ンバ関数ReceiveData は、Receiverオブジェクトが所有
するQueue オブジェクトに対して、キュー取出しメッセ
ージget を送信する。Queueオブジェクトは、このメッ
セージに対応するメンバ関数get を実行することによ
り、ExStringオブジェクトへのポインタaExString をサ
ーバオブジェクトServerに接続する（図５のＳ１８）。

【００６３】以上のようにして、図４に示されるアプリ
ケーションオブジェクトNdbAppが送信したExStringオブ
ジェクトが、図５に示されるサーバオブジェクトServer
に受信される。 ＜共有メモリに対するオブジェクトの入出力処理の詳細
＞上述したクライアントタスクとサーバタスクとの間の
オブジェクト通信の全体動作では、ExStringオブジェク
トという単純な文字列のオブジェクトが通信される場合
について説明した。

【００６４】ここで、実際には、第１の場合として、オ
ブジェクトは、他のオブジェクトへのポインタによっ
て、他のオブジェクトとの間で相互にクライアント・サ
プライヤ関係を有するグループを形成している場合が多
い。このような場合は、グループ内の各オブジェクト
が、各オブジェクト間の関係を維持したまま、それらに
含まれるメンバが一括して通信される必要がある。

【００６５】また、第２の場合として、オブジェクト
は、他の親クラスから派生したクラスのオブジェクトで
ある場合が多い。このような場合には、１つのオブジェ
クトには、そのオブジェクトを直接生成した派生クラス
で定義されるメンバのほかに、その派生クラスの親のク
ラスで定義されるメンバも含まれる。従って、１つのオ
ブジェクトが通信される場合でも、そのオブジェクトに
関連するクラス間の継承関係を維持したまま、そのオブ
ジェクトに含まれる各クラスに対応するメンバが通信さ
れる必要がある。

【００６６】更に、第３の場合として、第１の場合のよ
うにクライアント・サプライヤ関係を有するグループを
形成するそれぞれのオブジェクトが、第２の場合のよう
に他の親クラスから派生したクラスのオブジェクトであ
る場合も多い。このような場合には、グループ内の各オ
ブジェクトが、各オブジェクト間の関係を維持したま
ま、かつ、各オブジェクトに関連するクラス間の継承関
係を維持したまま、一括して通信される必要がある。

【００６７】以上の第１〜第３の場合のそれぞれの場合
におけるostrstreamオブジェクト又はistrstreamオブジ
ェクトを介した共有メモリに対するオブジェクトの入出
力処理の詳細について説明する。第１の場合の共有メモリに対するオブジェクトの入出力
処理 まず、第１の場合として、クライアント・サプライヤ関
係を有するグループを形成している各オブジェクトに含
まれるメンバの、ostrstreamオブジェクト又はistrstre
amオブジェクトを介した共有メモリに対する入出力処理
について、図７及び図８を使用して説明する。

【００６８】図７の例では、４つのデータメンバ（変
数）を有するShSchemaと呼ばれるオブジェクトが、それ
ぞれ３つ及び１つのデータメンバを有するShArray と呼
ばれる２つのオブジェクトを所有し、更に、３つのデー
タメンバを有するShArray オブジェクトが、それぞれ３
つのデータメンバを有するShRecordと呼ばれる２つのオ
ブジェクトを所有しているという、クライアント・サプ
ライヤ関係が示されている。

【００６９】まず、クライアントタスク側では、上述の
オブジェクトのグループが、前述した図４Ｓ７〜Ｓ９に
対応する以下に示される処理により、各グループに含ま
れるメンバを、自立的にostrstreamオブジェクトを介し
て共有メモリに出力する。

【００７０】始めに、前述した図４のＳ１に対応する処
理として、アプリケーションオブジェクトNdbAppは、送
信対象となるオブジェクトのグループとして、図７に示
されるShSchemaオブジェクト、ShArray オブジェクト、
及びShRecordオブジェクトからなるグループを生成す
る。

【００７１】次に、前述した図４のＳ３に対応する処理
として、ShSchemaオブジェクトへのポインタがSenderオ
ブジェクトにより所有される。続いて、前述の図４Ｓ６
に対応する処理として、アプリケーション用MainUserWi
ndowオブジェクトが所有するSenderオブジェクトのメン
バ関数ExSend（Sender.ExSend ）は、Senderオブジェク
トが所有する送信対象オブジェクトShSchemaに対して、
メッセージprintOn を送信する。

【００７２】これを受けて、ShSchemaオブジェクトは、
このメッセージに対応するメンバ関数printOn （ShSche
ma.printOn）を実行する（図７及び図８のＳ１）。メン
バ関数ShSchema.printOnは、まず、ostrstreamオブジェ
クトを介して、図８に示される共有メモリのアドレスＡ
０に、識別子“ShSchema”を書き込んだ後、共有メモリ
のアドレスＡ１とＡ２に、ShSchemaオブジェクトの１番
目及び２番目の非集合変数（図７）を書き込む。続い
て、メンバ関数ShSchema.printOnは、ShSchemaオブジェ
クトの３番目のデータメンバが集合変数であるオブジェ
クトポインタであることを認識することにより、そのポ
インタで指示される#1のShArray オブジェクトに対し、
メッセージprintOn を送信する。

【００７３】これを受けて、#1のShArray オブジェクト
は、このメッセージに対応するメンバ関数printOn （Sh
Array.printOn ）を実行する（図７及び図８のＳ２）。
メンバ関数ShArray.printOn は、ostrstreamオブジェク
トを介して、図８に示される共有メモリのアドレスＡ３
に、識別子“ShArray ”を書き込んだ後、共有メモリの
アドレスＡ４に、#1のShArray オブジェクトの１番目の
非集合変数として配列個数（＝２）（図７）を書込む。
続いて、メンバ関数ShArray.printOn は、#1のShArray
オブジェクトの２番目のデータメンバが集合変数である
オブジェクトポインタであることを認識することによっ
て、そのポインタで指示される#1のShRecordオブジェク
トに対して、メッセージprintOn を送信する。

【００７４】これを受けて、#1のShRecordオブジェクト
は、このメッセージに対応するメンバ関数printOn （Sh
Record.printOn）を実行する（図７及び図８のＳ３）。
メンバ関数ShRecord.printOnは、ostrstreamオブジェク
トを介して、図８に示される共有メモリのアドレスＡ５
に、識別子“ShRecord”を書き込んだ後、共有メモリの
アドレスＡ６〜Ａ８に、#1のShRecordオブジェクトの３
つのデータメンバ（図７）を書き込んで、処理を終了す
る。この結果、#1のShRecordオブジェクトにメッセージ
を送信した#1のShArray オブジェクトのメンバ関数prin
tOn に、制御がリターンする。

【００７５】#1のShArray オブジェクトのメンバ関数pr
intOn は、#1のShArray オブジェクトにおいて、#1のSh
Recordオブジェクトにメッセージを送信したときのデー
タメンバの次の３番目のデータメンバが集合変数である
オブジェクトポインタであることを認識することによ
り、そのポインタで指示される#2のShRecordオブジェク
トに対し、メッセージprintOn を送信する。

【００７６】これを受け、#2のShRecordオブジェクト
は、このメッセージに対応するメンバ関数printOn （Sh
Record.printOn）を実行する（図７及び図８のＳ４）。
メンバ関数ShRecord.printOnは、ostrstreamオブジェク
トを介して、図８に示される共有メモリのアドレスＡ９
に識別子“ShRecord”を書き込んだ後、共有メモリのア
ドレスＡ１０〜Ａ１２に、#2のShRecordオブジェクトの
３つのデータメンバ（図７）を書き込んで、処理を終了
する。この結果、#2のShRecordオブジェクトにメッセー
ジを送信した#1のShArray オブジェクトのメンバ関数pr
intOn に、制御がリターンする。

【００７７】#1のShArray オブジェクトのメンバ関数pr
intOn は、#1のShArray オブジェクトにおいて、#2のSh
Recordオブジェクトにメッセージを送信したときのデー
タメンバの次に処理すべきデータメンバがないことを認
識することにより、そのまま処理を終了する。この結
果、#1のShArray オブジェクトにメッセージを送信した
ShSchemaオブジェクトのメンバ関数printOn に、制御が
リターンする。

【００７８】ShSchemaオブジェクトのメンバ関数printO
n は、ShSchemaオブジェクトにおいて、#1のShArray オ
ブジェクトにメッセージを送信したときのデータメンバ
の次の４番目のデータメンバが集合変数であるオブジェ
クトポインタであることを認識することによって、その
ポインタで指示される#2のShArray オブジェクトに対
し、メッセージprintOn を送信する。

【００７９】これを受け、#2のShArray オブジェクト
は、このメッセージに対応するメンバ関数printOn （Sh
Array.printOn ）を実行する（図７及び図８のＳ５）。
メンバ関数ShArray.printOn は、ostrstreamオブジェク
トを介して、図８に示される共有メモリのアドレスＡ１
３に識別子“ShArray ”を書き込んだ後、共有メモリの
アドレスＡ１４に、#2のShArray オブジェクトの１番目
の非集合変数として配列個数（＝０）（図７）を書込
む。続いて、メンバ関数ShArray.printOn は、#2のShAr
ray オブジェクトにこれ以上データメンバがないことを
認識することによって、処理を終了する。この結果、#2
のShArray オブジェクトにメッセージを送信したShSche
maオブジェクトのメンバ関数printOn に、制御がリター
ンする。

【００８０】ShSchemaオブジェクトのメンバ関数printO
n は、ShSchemaオブジェクトにおいて、#2のShArray オ
ブジェクトにメッセージを送信したときのデータメンバ
の次に処理すべきデータメンバがないことを認識するこ
とにより、そのまま処理を終了する。この結果、ShSche
maオブジェクトにメッセージを送信したSenderオブジェ
クトのメンバ関数ExSendに、制御がリターンする。

【００８１】以上のようにして、クライアントタスクに
おいて、ShSchemaオブジェクト、２つのShArray オブジ
ェクト、及び２つのShRecordオブジェクトからなるオブ
ジェクトのグループのostrstreamオブジェクトを介した
共有メモリへの自立的な出力が終了する。

【００８２】次に、サーバタスク側では、上述の共有メ
モリの内容が、前述した図５のＳ１４に対応する処理に
よってistrstreamオブジェクトに読み込まれた後、前述
した図５のＳ１５に対応する以下に示される処理によっ
て、istrstreamオブジェクトの内容を格納すべきオブジ
ェクトが自動的に生成され、それらのオブジェクトのコ
ンストラクタによって、istrstreamオブジェクトに格納
されているデータが、自立的にそれらのオブジェクトに
読み込まれる まず、前述した図５のＳ１５に対応する処理として、サ
ーバ用MainUserWindowオブジェクトが所有するReceiver
オブジェクトは、istrstreamオブジェクトに読み込まれ
たデータの先頭に設定されている識別子が“ShSchema”
であることを判別することにより、始めに受信されるべ
きオブジェクトがShSchemaオブジェクトであることを判
別する。この結果、Receiverオブジェクトは、図７に示
されるShSchemaオブジェクトを生成する。

【００８３】そして、このShSchemaオブジェクトが生成
されるときに、その生成時に自動的に実行されるそのメ
ンバ関数であるコンストラクタが、istrstreamオブジェ
クトのアドレスＡ１とＡ２に格納されている非集合変数
を、生成されたShSchemaオブジェクトに、その１番目と
２番目のデータメンバとして格納する（図７参照）。こ
の処理は、図８のＳ１の処理とデータの方向が逆の処理
である。続いて、このコンストラクタは、istrstreamオ
ブジェクトのアドレスＡ３に識別子“ShArray”が格納
されていることを認識することにより、図７に示される
#1のShArray オブジェクトを生成する。

【００８４】そして、この#1のShArray オブジェクトが
生成されるときに、そのコンストラクタは、まず、ShSc
hemaオブジェクトの３番目のデータメンバとして、生成
された#1のShArray オブジェクトへのオブジェクトポイ
ンタを格納する（図７参照）。次に、このコンストラク
タは、istrstreamオブジェクトのアドレスＡ４に格納さ
れている非集合変数である配列個数（＝２）を、生成さ
れた#1のShArray オブジェクトに、その１番目のデータ
メンバとして格納する（図７参照）。この処理は、図８
のＳ２の処理とデータの方向が逆の処理である。続い
て、上述のコンストラクタは、istrstreamオブジェクト
のアドレスＡ５に識別子“ShRecord”が格納されている
ことを認識することによって、図７に示される#1のShRe
cordオブジェクトを生成する。

【００８５】そして、この#1のShRecordオブジェクトが
生成されるときに、そのコンストラクタは、まず、#1の
ShArray オブジェクトの２番目のデータメンバとして、
生成された#1のShRecordオブジェクトへのオブジェクト
ポインタを格納する（図７参照）。次に、このコンスト
ラクタは、istrstreamオブジェクトのアドレスＡ６〜Ａ
８に格納されているデータメンバを、生成された#1のSh
Recordオブジェクトに、その１番目〜３番目のデータメ
ンバとして格納する（図７参照）。この処理は、図８の
Ｓ３の処理とデータの方向が逆の処理である。そして、
上記コンストラクタは、istrstreamオブジェクトのアド
レスＡ９に自オブジェクトのクラスと同じクラスのオブ
ジェクトを示す識別子“ShRecord”が格納されているこ
とを認識することにより、処理を終了する。この結果、
#1のShRecordオブジェクトを生成させた#1のShArray オ
ブジェクトのコンストラクタに、制御がリターンする。

【００８６】#1のShArray オブジェクトのコンストラク
タは、istrstreamオブジェクトのアドレスＡ９に識別子
“ShRecord”が格納されていることを認識することによ
り、図７に示される#2のShRecordオブジェクトを生成す
る。

【００８７】そして、この#2のShRecordオブジェクトが
生成されるときに、そのコンストラクタは、まず、#1の
ShArray オブジェクトの３番目のデータメンバとして、
生成された#2のShRecordオブジェクトへのオブジェクト
ポインタを格納する（図７参照）。次に、このコンスト
ラクタは、istrstreamオブジェクトのアドレスＡ１０〜
Ａ１２に格納されているデータメンバを、生成された#2
のShRecordオブジェクトに、その１番目〜３番目のデー
タメンバとして格納する（図７参照）。この処理は、図
８のＳ４の処理とデータの方向が逆の処理である。そし
て、上記コンストラクタは、istrstreamオブジェクトの
アドレスＡ１３に自オブジェクトのクラスより上の階層
のクラスのオブジェクトを示す識別子“ShArray ”が格
納されていることを認識することにより、処理を終了す
る。この結果、#2のShRecordオブジェクトを生成させた
#1のShArray オブジェクトのコンストラクタに、制御が
リターンする。

【００８８】#1のShArray オブジェクトコンストラクタ
は、istrstreamオブジェクトのアドレスＡ１３に自オブ
ジェクトのクラスと同じクラスのオブジェクトを示す識
別子“ShArray ”が格納されていることを認識すること
により、そのまま処理を終了する。この結果、#1のShAr
ray オブジェクトを生成させたShSchemaオブジェクトの
コンストラクタに、制御がリターンする。

【００８９】ShSchemaオブジェクトのコンストラクタ
は、istrstreamオブジェクトのアドレスＡ１３に識別子
“ShArray ”が格納されていることを認識することによ
って、図７に示される#2のShArray オブジェクトを生成
する。

【００９０】そして、この#2のShArray オブジェクトが
生成されるときに、そのコンストラクタは、まず、ShSc
hemaオブジェクトの４番目のデータメンバとして、生成
された#2のShArray オブジェクトへのオブジェクトポイ
ンタを格納する（図７参照）。次に、このコンストラク
タは、istrstreamオブジェクトのアドレスＡ１４に格納
されている非集合変数である配列個数（＝０）を、生成
された#2のShArray オブジェクトに、その１番目のデー
タメンバとして格納する（図７参照）。この処理は、図
８のＳ５の処理とデータの方向が逆の処理である。そし
て、上記コンストラクタは、istrstreamオブジェクトの
アドレスＡ１４以降にデータがないことを認識すること
により、処理を終了する。この結果、#2のShArray オブ
ジェクトを生成させたShSchemaオブジェクトのコンスト
ラクタに制御がリターンする。

【００９１】ShSchemaオブジェクトのコンストラクタ
は、istrstreamオブジェクトのアドレスＡ１４以降にデ
ータがないことを認識することにより、そのまま処理を
終了する。この結果、ShSchemaオブジェクトを生成させ
たReceiverオブジェクトに、制御がリターンする。

【００９２】上述のようにして、サーバタスクにおい
て、ShSchemaオブジェクト、２つのShArray オブジェク
ト、及び２つのShRecordオブジェクトからなるオブジェ
クトのグループの受信が終了する。第２の場合の共有メモリに対するオブジェクトの入出力
処理 次に、第２の場合として、他の親クラスから派生したク
ラスのオブジェクトに含まれる各クラスに対応するメン
バのostrstreamオブジェクト又はistrstreamオブジェク
トを介した共有メモリに対する入出力処理について、図
９〜図１１を使用して説明する。

【００９３】図９の例では、ShSchemaと呼ばれるオブジ
ェクトを生成するためのShSchemaクラスはShObjectと呼
ばれる親のクラスから派生し、ShObjectクラスはTObjec
t と呼ばれる親のクラスから派生している。即ち、ShSc
hemaクラスとShObjectクラスは派生クラスであり、TObj
ect クラスは基底クラスである。このとき、ShSchemaク
ラス、ShObjectクラス、及びTObject クラスの各メンバ
関数printOn は、オーバーロードされており、それぞれ
のクラスに適した機能が定義されている。

【００９４】図９に示されるクラス階層構造の下で、Sh
SchemaクラスのオブジェクトであるShSchemaオブジェク
トが生成される場合、ShSchemaオブジェクトには、図１
０に示されるように、TObject クラスで定義されている
メンバと、ShObjectクラスで定義されているメンバと、
ShSchemaクラスで定義されているメンバとが含まれる。

【００９５】図１０に示されるデータ構造を有するShSc
hemaオブジェクトの通信が行われる場合の動作につい
て、以下に、図１１を使用して説明する。まず、クライ
アントタスク側では、ShSchemaオブジェクトが、前述し
た図４のＳ７〜Ｓ９に対応する以下に示される処理によ
って、TObject クラス、ShObjectクラス、及びShSchema
クラスのそれぞれのクラスに対応するShSchemaオブジェ
クト内のメンバを、自立的にostrstreamオブジェクトを
介して共有メモリに出力する。

【００９６】始めに、前述した図４Ｓ１に対応する処理
として、アプリケーションオブジェクトNdbAppは、送信
対象となるオブジェクトとして、図１０に示されるShSc
hemaオブジェクトを生成する。

【００９７】次に、前述した図４のＳ３に対応する処理
として、ShSchemaオブジェクトへのポインタがSenderオ
ブジェクトにより所有される。続いて、前述の図４Ｓ６
に対応する処理として、アプリケーション用MainUserWi
ndowオブジェクトが所有するSenderオブジェクトのメン
バ関数ExSend（Sender.ExSend ）は、Senderオブジェク
トが所有する送信対象オブジェクトShSchemaに対して、
メッセージprintOn を送信する。

【００９８】これを受け、ShSchemaオブジェクトは、こ
のメッセージに対応するメンバ関数printOn （ShSchem
a.printOn）を実行する（図９及び図１１のＳ１）。メ
ンバ関数ShSchema.printOnは、図１１のＳ１に示される
ように、まず、ostrstreamオブジェクトを介して、共有
メモリのアドレスＡ０に、識別子“ShSchema”を書き込
んだ後に、ShSchemaオブジェクトを生成させたShSchema
クラスがShObjectクラスから派生していることを認識す
ることによって、ShObjectクラスで定義されているメン
バ関数printOn （ShObject.printOn）をコールする（図
９及び図１１のＳ２）。

【００９９】メンバ関数ShObject.printOnは、図１１Ｓ
２に示されるように、まず、ostrstreamオブジェクトを
介して、共有メモリのアドレスＡ１に、識別子“ShObje
ct”を書き込んだ後に、ShObjectクラスがTObject クラ
スから派生していることを認識することで、TObject ク
ラスで定義されているメンバ関数printOn （TObject.pr
intOn ）をコールする（図９及び図１１のＳ３）。

【０１００】メンバ関数TObject.printOn は、図１１Ｓ
３に示されるように、まず、ostrstreamオブジェクトを
介して、共有メモリのアドレスＡ２に、識別子“TObjec
t ”を書き込んだ後、アドレスＡ３以降に、TObject ク
ラスに対応するShSchemaオブジェクト内のメンバを書き
込む。その後、メンバ関数TObject.printOn の処理が終
了して、このメンバ関数をコールしたメンバ関数ShObje
ct.printOnに制御がリターンする（図９及び図１１のＳ
４）。

【０１０１】メンバ関数ShObject.printOnは、図１１の
Ｓ４に示されるように、ostrstreamオブジェクトを介し
て、共有メモリのアドレスＡi 以降に、ShObjectクラス
に対応するShSchemaオブジェクト内のメンバを書き込
む。その後、メンバ関数ShObject.printOnの処理が終了
して、このメンバ関数をコールしたメンバ関数ShSchem
a.printOnに制御がリターンする（図９及び図１１のＳ
５）。

【０１０２】メンバ関数ShSchema.printOnは、図１１Ｓ
５に示されるように、ostrstreamオブジェクトを介し
て、共有メモリのアドレスＡj 以降に、ShSchemaクラス
に対応するShSchemaオブジェクト内のメンバを書き込
む。その後、メンバ関数ShSchema.printOnの処理が終了
し、ShSchemaオブジェクトにメッセージを送信したSend
erオブジェクトのメンバ関数ExSendに制御がリターンす
る。

【０１０３】以上のようにして、クライアントタスクに
おいて、派生クラスShSchemaから生成されたShSchemaオ
ブジェクトのostrstreamオブジェクトを介した共有メモ
リへの自立的な出力が終了する。

【０１０４】次に、サーバタスク側では、上述の共有メ
モリの内容が、前述した図５のＳ１４に対応する処理に
よってistrstreamオブジェクトに読み込まれた後、前述
した図５のＳ１５に対応する以下に示される処理によっ
て、istrstreamオブジェクトの内容を格納すべきShSche
maオブジェクトが自動的に生成され、そのオブジェクト
に含まれるTObject クラス、ShObjectクラス、及びShSc
hemaクラスの各コンストラクタによって、istrstreamオ
ブジェクトに格納されているデータが、自立的にShSche
maオブジェクトに読み込まれる まず、前述した図５Ｓ１５に対応する処理として、サー
バ用MainUserWindowオブジェクトが所有するReceiverオ
ブジェクトは、istrstreamオブジェクトに読み込まれた
データの先頭に設定されている識別子が“ShSchema”で
あることを判別することにより、受信されるべきオブジ
ェクトがShSchemaオブジェクトであることを判別する。
この結果、Receiverオブジェクトは、図１０に示される
ShSchemaオブジェクトを生成する。

【０１０５】そして、このShSchemaオブジェクトが生成
されるときに、その生成時に自動的に実行されるそのメ
ンバ関数であるコンストラクタが起動される。このコン
ストラクタは、istrstreamオブジェクトのアドレスＡ１
に格納されているデータがShSchemaクラスを派生させた
ShObjectクラスを示す識別子“ShObject”であることを
認識することにより、ShObjectクラスで定義されている
コンストラクタをコールする。

【０１０６】ShObjectクラスで定義されているコンスト
ラクタは、istrstreamオブジェクトのアドレスＡ２に格
納されているデータがShObjectクラスを派生させたTObj
ectクラスを示す識別子“TObject ”であることを認識
することにより、そのまま、TObject クラスで定義され
ているコンストラクタをコールする。

【０１０７】TObject クラスで定義されているコンスト
ラクタは、istrstreamオブジェクトのアドレスＡ３以降
に格納されているTObject クラスに対応するメンバを、
生成されたShSchemaオブジェクトに格納する（図１０参
照）。この処理は、図１１のＳ３の処理とデータの方向
が逆の処理である。その後、TObject クラスで定義され
ているコンストラクタの処理が終了して、そのコンスト
ラクタをコールしたShObjectクラスで定義されているコ
ンストラクタに制御がリターンする。

【０１０８】ShObjectクラスで定義されているコンスト
ラクタは、istrstreamオブジェクトのアドレスＡi 以降
に格納されているShObjectクラスに対応するメンバを、
生成されたShSchemaオブジェクトに格納する（図１０参
照）。この処理は、図１１のＳ４の処理とデータの方向
が逆の処理である。その後、ShObjectクラスで定義され
ているコンストラクタの処理が終了して、そのコンスト
ラクタをコールしたShSchemaクラスで定義されているコ
ンストラクタに制御がリターンする。

【０１０９】ShSchemaクラスで定義されているコンスト
ラクタは、istrstreamオブジェクトのアドレスＡj 以降
に格納されているShSchemaクラスに対応するメンバを、
生成されたShSchemaオブジェクトに格納する（図１０参
照）。この処理は、図１１のＳ５の処理とデータの方向
が逆の処理である。その後、ShSchemaクラスで定義され
ているコンストラクタの処理が終了して、ShSchemaオブ
ジェクトを生成させたReceiverオブジェクトに、制御が
リターンする。

【０１１０】上述のようにして、サーバタスクにおい
て、ShSchemaオブジェクトに含まれるTObject クラス、
ShObjectクラス、及びShSchemaクラスのそれぞれに対応
するメンバの受信が終了する。

【０１１１】以上説明した例では、図９に示されるよう
に、ShSchemaクラス及びShObjectクラスは、それぞれ１
つの親クラスから派生されているが、これらのクラスは
２つ以上の親クラスから派生されてもよい。この場合に
は、各親クラスのメンバ関数printOn 及びコンストラク
タが順次実行されることにより、それらの親クラスで定
義されているメンバが共有メモリに対して入出力され
る。第３の場合の共有メモリに対するオブジェクトの入出力
処理 最後に、第３の場合として、他の親クラスから派生した
クラスのオブジェクトを含み、クライアント・サプライ
ヤ関係を有するグループを形成している各オブジェクト
に含まれるメンバの、ostrstreamオブジェクト又はistr
streamオブジェクトを介した共有メモリに対する入出力
処理について説明する。

【０１１２】例えば、図７に示されるクライアント・サ
プライヤ関係を有するオブジェクトのグループにおい
て、ShSchemaオブジェクトが、図９に示される派生クラ
スShSchemaクラスから生成されている場合について説明
する。

【０１１３】まず、クライアントタスク側では、上述の
オブジェクトのグループが、前述した図４Ｓ７〜Ｓ９に
対応する以下に示される処理により、各グループに含ま
れるメンバを、自立的にostrstreamオブジェクトを介し
て共有メモリに出力する。

【０１１４】この場合に、前述した第１の場合における
図８のＳ１に対応する処理としてShSchemaオブジェクト
のメンバ関数printOn が実行されるときに、図１１を使
って説明したようにShObjectクラスで定義されているメ
ンバ関数printOn とTObjectクラスで定義されているメ
ンバ関数printOn が順次呼び出される。その結果、ostr
streamオブジェクトを介して図８の共有メモリのアドレ
スＡ０とＡ１の間に相当する記憶領域に、図１１のアド
レスＡ１〜（Ａj −１）の記憶内容に相当するデータが
記憶され、その記憶領域以降の記憶領域に図８の共有メ
モリのアドレスＡ１以降の記憶内容に相当するデータが
記憶されることになる。

【０１１５】次に、サーバタスク側では、上述の共有メ
モリの内容が、前述した図５のＳ１４に対応する処理に
よってistrstreamオブジェクトに読み込まれた後、前述
した図５のＳ１５に対応する以下に示される処理によっ
て、istrstreamオブジェクトの内容を格納すべきオブジ
ェクトが自動的に生成され、それらのオブジェクトのコ
ンストラクタによって、istrstreamオブジェクトに格納
されているデータが、自立的にそれらのオブジェクトに
読み込まれる この場合に、前述した第１の場合における図８のＳ１に
対応する処理としてShSchemaオブジェクトのコンストラ
クタが実行されるときに、図１１を使って説明したよう
にShObjectクラスで定義されているコンストラクタとTO
bject クラスで定義されているコンストラクタが順次呼
び出される。その結果、図８の共有メモリのアドレスＡ
０とＡ１の間に相当する記憶領域に記憶されている図１
１のアドレスＡ１〜（Ａj −１）の記憶内容に相当する
データが、ShSchemaオブジェクトに順次格納され、続い
て、その記憶領域以降の記憶領域に記憶されている図８
の共有メモリのアドレスＡ１以降の記憶内容に相当する
データが、前述した第１の場合について説明したよう
に、ShSchemaオブジェクト、#1のShArray オブジェク
ト、#1及び#2のShRecordオブジェクト、及び#2のShArra
y オブジェクトに格納されることになる。 ＜Receiverオブジェクトによるオブジェクトの組立て処
理の詳細＞図５のＳ１５の説明で前述したように、Rece
iverオブジェクトは、istrstreamオブジェクトに読み込
まれたデータに設定されている識別子を判別することに
より、受信されるべきオブジェクトを判別し、予めServ
erクラスオブジェクトにおいて定義されているクラスの
うち判別されたオブジェクトに対応するクラスを使っ
て、受信オブジェクトを生成する。従って、Receiverオ
ブジェクトは、予めどのようなオブジェクトが受信され
るかを認識している必要がある。ここで、受信されるオ
ブジェクトの種類が途中で変更されたような場合に、Re
ceiverオブジェクトのメンバ関数をいちいち修正するの
は煩雑であり、汎用性に欠ける。

【０１１６】そこで、受信されるオブジェクト種類の変
更に対し柔軟に対応可能なReceiverオブジェクトによる
オブジェクトの組立て処理の２つの方式について、以下
に説明する。

【０１１７】まず、図１２は、Receiverオブジェクトに
よるオブジェクトの組立て処理の第１の方式の詳細を示
した図である。図１２では、特定のオブジェクトのグル
ープを組立てるための処理がExitルーチンオブジェクト
としてまとめられ、それらがListオブジェクトによって
所有されて管理され、そのListオブジェクトがReceiver
オブジェクトによって所有される。

【０１１８】そして、Receiverオブジェクトは、前述し
た図５のＳ１５に対応する処理において、istrstreamオ
ブジェクトに読み込まれたデータに設定されている識別
子を読み込み、その識別子を含む依頼メッセージをList
オブジェクトに送信する。

【０１１９】Listオブジェクトは、そのリストに登録さ
れている各Exitルーチンオブジェクトに、上記識別子を
含むメッセージを送信し、各Exitルーチンオブジェクト
がその識別子を判別することにより、その識別子に対応
するExitルーチンオブジェクトが、その識別子に対応す
るオブジェクトを組み立てる。例えば識別子が“Ｆ”で
あった場合、ExitルーチンオブジェクトＢの条件文“ca
se F”において条件が成立し、その条件文に対応する処
理としてＦオブジェクトが組み立てられる。

【０１２０】図１２に示される構成により、受信される
オブジェクトのグループが追加される場合には、追加さ
れるオブジェクトのグループを組み立てるためのExitル
ーチンオブジェクトを用意し、それをListオブジェクト
が管理するリストに追加すればよい。また、受信される
オブジェクトのグループが削除される場合には、削除さ
れるオブジェクトのグループを組み立てるためのExitル
ーチンを削除し、それをListオブジェクトが管理するリ
ストから削除すればよい。

【０１２１】従って、受信されるオブジェクトのグルー
プが変更されても、そのような変更に対して、Receiver
オブジェクトのメンバ関数を修正することなく、柔軟に
対応することができる。なお、Listオブジェクトは、周
知のリスト処理を行うオブジェクトであり、リストの追
加、削除、又は変更を簡単に行えるようなインタフェー
スを有している。

【０１２２】次に、図１３は、Receiverオブジェクトに
よるオブジェクトの組立て処理の第２の方式の詳細を示
した図である。図１３では、受信されるべきオブジェク
トのインスタンス（雛型）が、オブジェクトＡ〜オブジ
ェクトＦというように予めデータベースとして登録さ
れ、それらが、それらオブジェクトのインスタンスの一
覧をデータベースとして管理しそれらに対する問合せ機
能を有するList/Dictionary オブジェクトによって所有
され、そのList/Dictionary オブジェクトがReceiverオ
ブジェクトによって所有される。

【０１２３】そして、Receiverオブジェクトは、前述し
た図５のＳ１５に対応する処理において、istrstreamオ
ブジェクトに読み込まれたデータに設定されている識別
子を読み込み、その識別子を含む依頼メッセージをList
/Dictionary オブジェクトに送信する。

【０１２４】List/Dictionary オブジェクトは、それが
有するリストにデータベースとして登録されている各オ
ブジェクトに、上記識別子を含むメッセージを順次送信
し、各オブジェクトがその識別子に対応するか否かを問
い合せる。その結果、その識別子に対応するオブジェク
トが、自オブジェクトをコピーすることにより、そのク
ローンとなるオブジェクトを受信オブジェクトとして生
成する。例えば、識別子が“Ｃ”であった場合、オブジ
ェクトＣがその識別子“Ｃ”に対応する。そこで、オブ
ジェクトＣが、新たなオブジェクトＣを生成し、それを
受信オブジェクトとしてReceiverオブジェクトに渡す。

【０１２５】ここで、図７及び図８を使用して前述した
ように、オブジェクトのグループが受信される場合に
は、ある時点で受信されたオブジェクトのコンストラク
タが、Receiverオブジェクトを介して又は介さずに直
接、List/Dictionary オブジェクトに問合せメッセージ
を送信することにより、データベース内でそのメッセー
ジに対応するオブジェクトに対し、そのクローンオブジ
ェクトを新たに生成させ、それをグループ内の新たな受
信オブジェクトとすればよい。

【０１２６】以上、図１３に示される構成により、受信
されるオブジェクトのグループが追加さる場合には、そ
の追加されるオブジェクトのインスタンスをデータベー
スに追加すればよい。また、受信されるオブジェクトの
グループが削除される場合には、削除されるオブジェク
トのインスタンスをデータベースから削除すればよい。

【０１２７】従って、受信されるオブジェクトのグルー
プが変更されても、そのような変更に対して、Receiver
オブジェクトのメンバ関数を修正することなく、柔軟に
対応することができる。なお、List/Dictionary オブジ
ェクトは、周知のデータベースアクセス処理を行うオブ
ジェクトであり、データベースの構成要素である各オブ
ジェクトのインスタンスの追加、削除、又は変更を簡単
に行えるようなインタフェースを有している。 ＜他の実施例＞以上説明した実施例では、クライアント
タスクからサーバタスクへオブジェクトが送信される場
合の動作について説明したが、勿論、サーバタスクから
クライアントタスクへオブジェクトが送信される場合も
同様である。この場合には、サーバタスクでSenderオブ
ジェクトが生成され、クライアントタスクでReceiverオ
ブジェクトが生成されることになる。

【０１２８】また、以上説明した実施例は、ウインドウ
システムのもとで動作するアプリケーションについての
ものであるが、オブジェクト指向で動作するシステムで
あれば、本発明は様々な形態のシステムに適用できる。

【０１２９】更に、以上説明した実施例におけるオブジ
ェクトは、コンピュータシステムがＣ＋＋プログラミン
グ言語に基づいて作成されたプログラムを実行すること
により実現されているが、オブジェクト処理を行うため
のシステムであればどのようなシステムの上で実現され
てもよい。

【０１３０】加えて、上述した実施例におけるSenderオ
ブジェクトの機能は、通信されるオブジェクトにカプセ
ル化されてもよい。

【０１３１】

【発明の効果】本発明によれば、通信オブジェクト自身
が、そのメンバの送信と受信を行うため、通信データの
汎用性を考慮する必要がなくなり、その結果、通信対象
のオブジェクトに対する制限を除くことができ、多様な
オブジェクトを通信することが可能となる。

【０１３２】また、オブジェクト自身がそのメンバの送
受信を行う結果、通信バッファアクティブエラー等の通
信エラーが発生する可能性は激減し、通信時の信頼性の
飛躍的な向上が可能となる。

【０１３３】更に、通信オブジェクト自身にそのメンバ
の通信機能を持たせる場合に、予め基底クラスにそのメ
ッセージの通信機能を持たせておき、通信オブジェクト
を、基底クラスから派生したクラスであって基底クラス
におけるメンバの通信機能を継承した派生クラスのオブ
ジェクトとして生成させることによって、アプリケーシ
ョンのオブジェクトに簡単にそのメンバの通信機能を持
たせることが可能となる。

【０１３４】一方、受信側のタスクにおいて、通信オブ
ジェクト生成用オブジェクトが、受信された通信データ
に対応する通信オブジェクトを生成する場合、受信され
た通信データに設定されている識別子によってその通信
データに対応する通信オブジェクトを生成することによ
り、簡単な制御処理で対応する通信オブジェクトを生成
することが可能となる。

【０１３５】また、通信オブジェクト生成用オブジェク
トが、所定のグループの通信オブジェクトを生成する通
信オブジェクト生成ルーチンオブジェクトを複数のグル
ープに対応して複数所有するリストオブジェクトを所有
することによって、受信されるオブジェクトのグループ
の種類が変更されても、そのような変更に対して、通信
オブジェクト生成用オブジェクトを修正することなく、
リストオブジェクトに対して通信オブジェクト生成ルー
チンオブジェクトを追加、削除、又は変更させるだけ
で、柔軟に対応することが可能となる。

【０１３６】或いは、通信オブジェクト生成用オブジェ
クトが、複数の通信オブジェクトのインスタンスをデー
タベースとして所有するデータベース管理オブジェクト
を所有することによって、受信されるオブジェクトが変
更されても、そのような変更に対して、通信オブジェク
ト生成用オブジェクトを修正することなく、データベー
ス管理オブジェクトに対して通信オブジェクトのインス
タンスを追加、削除、又は変更させるだけで、柔軟に対
応することが可能となる。

【０１３７】一方、オブジェクト自身により送受信され
るメンバが所定の通信プロトコルに従って通信される場
合に、この通信プロトコルに基づく制御を行う機能を通
信プロトコル制御オブジェクトとしてオブジェクト化す
ることにより、通信プロトコルに基づく制御機能を通信
プロトコル制御オブジェクトにカプセル化することがで
き、通信を行うアプリケーションは、通信プロトコル制
御オブジェクトにメッセージを送るだけで、所定の通信
プロトコルに沿った通信を実現でき、アプリケーション
におけるオブジェクトの通信に対する負荷及びエラー発
生の可能性を軽減させることが可能となる。

【図面の簡単な説明】

【図１】本発明の実施例の構成図である。

【図２】パスの設定動作の説明図（クライアントタスク
側）である。

【図３】パスの設定動作の説明図（サーバタスク側）で
ある。

【図４】オブジェクト通信動作の説明図（クライアント
タスク側）である。

【図５】オブジェクト通信動作の説明図（サーバタスク
側）である。

【図６】メインユーザウインドウオブジェクトのクラス
構造を示した図である。

【図７】オブジェクトのグループの例を示した図であ
る。

【図８】オブジェクトのグループの共有メモリでの記憶
形態を示した図である。

【図９】派生クラスの継承関係の例を示した図である。

【図１０】派生クラスのオブジェクトの例を示した図で
ある。

【図１１】派生クラスのオブジェクトの共有メモリでの
記憶形態を示した図である。

【図１２】Receiverオブジェクトによるオブジェクトの
組立て処理の詳細（その１）を示した図である。

【図１３】Receiverオブジェクトによるオブジェクトの
組立て処理の詳細（その２）を示した図である。

【図１４】オブジェクトを基本要素とするコンピュータ
システムの構成図である。

【図１５】従来のオブジェクト通信の構成図である。

【符号の説明】

１０１ 送信オブジェクト部 １０２ Senderオブジェクト １０３ 送受信バッファオブジェクト部 １０４ 通信プロトコル制御部 １０５ Receiverオブジェクト １０６ 受信オブジェクト部 １０７ バッファ書き込み依頼メッセージ １０８ バッファ読み込み依頼メッセージ

───────────────────────────────────────────────────── フロントページの続き (56)参考文献 特開 平５−20090（ＪＰ，Ａ) 特開 平５−225012（ＪＰ，Ａ) 特開 平６−149600（ＪＰ，Ａ) インターフェース1991年９月号（Ｖｏ ｌ．17、Ｎｏ．９）、ＣＱ出版社、ｐ ｐ．219〜233（特許庁ＣＳＤＢ文献番 号：ＣＳＮＷ199800205006) (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 9/44 G06F 9/46 G06F 13/00 G06F 15/16 ＪＩＣＳＴファイル（ＪＯＩＳ) ＣＳＤＢ（日本国特許庁)

Claims (6)

(57)【特許請求の範囲】
1. 【請求項１】 異なるタスク間のオブジェクト通信方式
   において、前記タスク間で通信されるオブジェクトである通信オブ
   ジェクトに、 自オブジェクトの内容に対応する通信デー
   タの送信機能及び受信機能と、 受 信側の前記タスク内に、受信された前記通信データに
   対応する前記通信オブジェクトを生成する通信オブジェ
   クト生成用オブジェクトと、 を有し、 送信側の前記タスク内の前記通信オブジェクトが有する
   前記送信機能は、該自オブジェクトの内容に対応する通
   信データを送受信バッファオブジェクトに書き込み、 前記送受信バッファオブジェクトに書き込まれた前記通
   信データは、受信側タスクに送信され、 前記受信側のタスク内の前記通信オブジェクト生成用オ
   ブジェクトは、受信した前記通信データに対応する前記
   通信オブジェクトを生成し、 該生成された通信オブジェクトが有する前記受信機能
   は、自オブジェクトが生成される際に、前記送受信バッ
   ファオブジェクトの前記通信データを自オブジェクトに
   読み込む、 ことを特徴とするオブジェクト通信方式。
2. 【請求項２】 前記送信側のタスク内の前記通信オブジ
   ェクトによる送信動作時及び前記受信がわのタスク内の
   前記通信オブジェクトによる受信動作時の通信プロトコ
   ルの制御を行う通信プロトコル制御手段を更に有する、 ことを特徴とする請求項１に記載のオブジェクト通信方
   式。
3. 【請求項３】 前記通信オブジェクトは、クライアント
   ・サプライヤ関係を有するグループを形成している各オ
   ブジェクトであり、該各オブジェクトがそれぞれ、該各
   オブジェクトに対応する通信データの送信機能及び受信
   機能を有する、 ことを特徴とする請求項１又は２の何れか１項に記載の
   オブジェクト通信方式。
4. 【請求項４】 前記通信オブジェクトは、基底クラス
   から派生したクラスのオブジェクトであり、該通信オブ
   ジェクトに関連するクラスのそれぞれに対応する該通信
   オブジェクトのメンバの送受信機能を有する、 ことを特徴とする請求項１乃至３の何れか１項に記載の
   オブジェクト通信方式。
5. 【請求項５】 前記通信オブジェクト生成用オブジェク
   トは、前記受信された通信データに設定されている識別
   子によって、該通信データに対応する前記通信オブジェ
   クトを生成する、 ことを特徴とする請求項１乃至４の何れか１項に記載の
   オブジェクト通信方式。
6. 【請求項６】 前記通信オブジェクト生成用オブジェク
   トは、リストオブジェクトを所有し、 該リストオブジェクトは、所定のグループの通信オブジ
   ェクトを生成する通信オブジェクト生成ルーチンオブジ
   ェクトを、複数のグループに対応して複数所有し、前記リストオブジェクトは、前記通信オブジェクト生成
   ルーチンオブジェクトに前記通信データを送信し、 前記各通信オブジェクト生成ルーチンオブジェクトは、
   受信した前記通信データに含まれる識別子に基づき、組
   み立てる通信オブジェクトを判別し、該通信データに対
   応する前記通信オブジェクトを生成させる、 ことを特徴とする請求項１乃至５何れか１項に記載のオ
   ブジェクト通信方式。