(57)【特許請求の範囲】
【請求項１】
分散処理環境上で、一方のアプリケーションが要求を起こし、他方のアプリケーションがそれに応答する要求応答型の分散処理システムにおいて、アプリケーション間で無限長データの通信を行うために、無限長データのためのデータ型としてストリーム型を分散処理環境に定義し、一方のアプリケーションが、他方のアプリケーションが提供するストリーム型を含むパラメータを有するオペレーションを呼び出すとき両アプリケーション側各々で該パラメータに対応するトリーム型の変数を生成し、分散処理環境がアプリケーション間の無限長データの通信を、該変数を通じて連続的に反復する複数回の有限長データの授受として実行することを特徴とする要求応答型無限長データ通信方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、分散システムにおけるアプリケーション間の無限長データの通信方法に関する。
【０００２】
近年、クライアント／サーバシステム等、多くの分散システム技術が開発されている。三喜、土屋、リー「３層クライアント／サーバ・システム構築技法」（ソフトリサーチセンター，  １９９６年）によれば、分散されたアプリケーション間の通信方法には、二つに大別して、要求応答型及びピアツーピア型がある。要求応答型は、一方のアプリケーションが要求を起こし、他方がそれに対して応答する。一方、ピアツーピア型は、双方のアプリケーションが相互の等しい権利と条件のもとに単純に情報を交換する。
【０００３】
要求応答型を実装した代表的なものに遠隔手続き呼出し（ＲＰＣ）技術及び共通オブジェクト要求ブローカアーキテクチャ（ＣＯＲＢＡ）等による分散オブジェクト技術がある。ＲＰＣでは、例えば、サーバアプリケーションが手続きを定義し、クライアントがサーバアプリケーションに対して手続きを呼出す時及びサーバがクライアントに対して応答する時に、パラメータを介してクライアントとサーバとの間でデータの授受を行う。同様に、ＣＯＲＢＡでも、サーバとしてのオブジェクトがオペレーションの集合であるインタフェースを定義し、クライアントがオブジェクトに対してオペレーションを呼出す時及びオブジェクトからクライアントに応答する時に、パラメータを介してクライアントとサーバとの間でデータの授受を行う。
【０００４】
これらの技術の特長の一つとして、プログラミングを行う時にネットワークを意識する必要がなく、クライアントがサーバの手続き又はオペレーションを呼出す方法でデータの通信を行うことができる点が挙げられる。
【０００５】
しかし、ＲＰＣ及びＣＯＲＢＡを含め、従来の要求応答型のアプリケーション間の通信は、授受を行うデータとして有限長のデータのみを対象としており、無限長のデータの授受はできない。即ち、無限長データをクライアントとサーバとの間で授受を行うためには、従来はピアツーピア型の通信しか存在していない。例えば、ＵＮＩＸ環境では、クライアント及びサーバ双方でそれぞれソケットを生成し、両者がそれぞれ自己のソケットにアクセスすることにより、無限長データの授受を行うことが一般的である。
【０００６】
ここで「有限長データ」とは、データの通信を開始する時にデータの全体の長さを特定できるデータをいう。一方、「無限長データ」とは、データの通信を開始する時にデータの大きさを特定できないデータをいう。無限長データの例としては、テレビ会議システムの画像音声データがある。このシステムのサービス終了時期は一般には不定であることから、画像音声データの通信開始時点にはデータの全体の長さを指定できない。無限長データの別の例としては、ビデオオンデマンドサービスがある。映画の長さは予め分かっているので有限長データとして扱うことも可能であるが、アプリケーションの実装如何によっては、無限長データと捉えて開発することも可能である。
【０００７】
アプリケーション間における無限長データの通信に要求応答型を用いずピアツーピア型を用いることには、以下に挙げるような欠点がある。第一の欠点は、有限長データと無限長データの通信作法が異なるので、一貫したシステム開発が困難なことである。例えば、ＣＯＲＢＡ等の分散オブジェクト環境では、有限長データの通信に関しては要求応答型なので、コード実装の時点で有限長データを提供し又は処理する主体をオブジェクトとして表すことができる。よって、システムの分析、設計及び実装をオブジェクト指向という一貫した手法で開発することが可能である。一方、無限長データの通信に関しては要求応答型ではないので、実装の時点で無限長データを提供し又は処理する主体をオブジェクトとして表すことができない。よって、システム開発を一貫した手法で行うことができない。このため、一貫性を保つことかできず、システム開発手法の利点が失われることになり、システム開発の効率及び品質が低下することにつながる。
【０００８】
第二の欠点は、クライアントとサーバの双方が、コードを実装する時に前述のソケットのようなネットワークインタフェースを意識しなければならないことである。即ち、ＲＰＣ及びＣＯＲＢＡ等の技術を利用できるにも拘らず、無限長データを通信することになると、ネットワークインタフェースを意識したプログラミングを行わざるを得なくなる。これは、アプリケーション開発の負担を増すことになる。特に、動画又は音声のような無限長データに分類できるデータを主に扱うマルチメディアシステムの開発においては、この負担は極めて大きくなる。
【０００９】
【発明が解決しようとする課題】
本発明の目的は、アプリケーション間における無限長データの通信に関して、上記の欠点を解決し、有限長データ及び無限長データ双方に関して同一の通信作法を提供し、一貫したシステム開発手法の適用を可能にし、各アプリケーションのコードを実装する時にネットワークのインタフェースを意識することなく、無限長データの通信を可能にすることにある。
【００１０】
【課題を解決するための手段】
本発明の要求応答型無限長データ通信方法は、上記の目的を達成するため、アプリケーション間で、分散処理環境上で、一方のアプリケーションが要求を起こし、他方のアプリケーションがそれに応答する要求応答型の分散処理システムにおいて、アプリケーション間で無限長データの通信を行うために、無限長データのためのデータ型としてストリーム型を分散処理環境に定義し、一方のアプリケーションが、他方のアプリケーションが提供するストリーム型を含むパラメータを有するオペレーションを呼び出すとき両アプリケーション側各々で該パラメータに対応するトリーム型の変数を生成し、分散処理環境がアプリケーション間の無限長データの通信を、該変数を通じて連続的に反復する複数回の有限長データの授受として実行することを特徴とする。
【００１１】
このような本発明の要求応答型無限長データ通信方法によれば、分散処理環境は、クライアントアプリケーション及びサーバオブジェクト共に、無限長データを通信するためにネットワーク管理インタフェースを使用する必要がなく、また、意識する必要もない。また、無限長データへのアクセス手段をオペレーションのパラメータとして提供しており、無限長データへのアクセスを可能にするための通信開始或いは通信停止等のオペレーションの定義を必要としない。
【００１２】
【発明の実施の形態】
次に図面を用いて本発明の実施例を詳細に説明する。図１は分散処理環境とアプリケーションとの全体構成を機能分類したものである。１はクライアントアプリケーションである。これは、無限長データに関するサービスを受けるために、サーバとしてのオブジェクトのオペレーションを呼出す。
【００１３】
２はクライアント側データ処理部である。これは、クライアントアプリケーション１からのオペレーションの呼出し要求を受けて、サーバオブジェクト５のオブジェクトリファレンス、オペレーション呼出し要求及びオペレーションのパラメータとしてのデータをデータ通信部３に渡す。また、これは、データ通信部３から受取ったオペレーション呼出し応答及びパラメータとしてのデータをクライアントアプリケーション１に渡す。
【００１４】
３はデータ通信部である。これは、クライアント側データ処理部２から受取ったオブジェクトリファレンスからサーバオブジェクト５の位置を割り出し、そのサーバオブジェクト５のサーバ側データ処理部４に、オブジェクトリファレンス、オペレーション呼出し要求及びパラメータとしてのデータを渡す。また、これは、サーバ側データ処理部４から受取ったオペレーション呼出し応答及びそのオペレーションのパラメータとしてのデータをクライアント側データ処理部２に渡す。
【００１５】
４はサーバ側データ処理部である。これは、データ通信部３からオブジェクトリファレンス、オペレーション呼出し要求及びパラメータとしてのデータを受取ると、サーバオブジェクト５に、呼出し要求及びパラメータとしてのデータを渡す。また、これは、サーバオブジェクト５からオペレーション呼出し応答及びそのパラメータとしてのデータを受取ると、それらをデータ通信部３に渡す。
【００１６】
５はサーバオブジェクトである。これは、無限長データに関するサービスを提供する。また、これは、呼出し要求を受けたオペレーションを実行する。
以上のうち、クライアント側データ処理部２、データ通信部３及びサーバ側データ処理部４が、分散処理環境６として、アプリケーション開発者に対して提供される。
【００１７】
クライアントアプリケーション１及びサーバオブジェクト５から見た簡単なシナリオは以下のとおりである。（１）  クライアントアプリケーション１は、ネームサービス又はトレーダサービス等を利用して、呼出したいサーバオブジェクト５のオブジェクトリファレンスを得る。（２）  クライアントアプリケーション１は、オブジェクトリファレンスを用いて、サーバオブジェクト５のオペレーションを呼出す。（３）  サーバオブジェクト５は、呼出されたオペレーションを実行する。（４）  サーバオブジェクト５は、クライアントアプリケーション１に呼出されたオペレーションの応答を返す。この（２）  及び（４）  のいずれか又は両者の段階で、クライアントアプリケーション１とサーバオブジェクト５との間で無限長データの授受が行われる。
【００１８】
図２は分散処理環境の全体構成を示す図である。各コンピュータ１０ａ，１０ｂ  に分散するアプリケーションは、各コンピュータ上の分散処理環境６を通して、分散を意識しないアプリケーション間通信を可能にしている。この実施例においては、分散処理環境６が無限長データのためのデータ型を定義し、アプリケーションがその型を利用する。
【００１９】
以下の説明では、無限長データ型をストリーム型と呼ぶこととする。このストリーム型は、アプリケーションが無限長データを直接処理する場合を想定した抽象データ型である。ストリーム型は、分散処理環境により定義され、アプリケーションに提供される。アプリケーションは、オペレーションの中で無限長データをオペレーション呼出しのパラメータとして扱い、そのパラメータにアクセスすることにより無限長データを処理する。
【００２０】
分散処理環境は、ストリーム型として、インタフェース定義言語（ＩＤＬ）上のデータ型及びプログラミング言語（例えばＣ＋＋）上のデータ型を提供する。また、ストリーム変数のＩＤＬ記述からプログラミング言語へのマッピングも行う（そのマッピングはＩＤＬコンパイラによって行われる）。
【００２１】
オペレーション呼出しのパラメータのデータ型としてストリーム型が提供されるので、クライアント側アプリケーション１及びサーバオブジェクト５によるストリーム型の変数の生成は、ＣＯＲＢＡの従来のデータ型と同じ方法で行われる。即ち、両者のいずれかがストリーム型の変数の生成の契機を与える。両者から見えるオペレーションの呼出しのパラメータとしての、ストリーム型の変数の実体は、あたかも一つであるように見えるが、実際には変数の実体はクライアント及びサーバ双方に存在することになる。
【００２２】
なお、ストリーム型を流れる個々のデータは、整数型及び浮動小数点型等とは異なり、単なるビット列である。従って、それらの型のデータと異なり、通信の前後でマーシャリング及びアンマーシャリングは行わない。
【００２３】
次に、ストリーム型における実装方法について説明する。ストリーム型の変数（インスタンス）は、各変数毎に以下の情報を持つ。大きく二分してユーザデータ部と管理部とに分かれる。ユーザデータ部の構成要素としてバッファがある。これは、アプリケーションからのデータの書込みを一旦受けてから、ネットワークインタフェースに書出すまで、及び、ネットワークインタフェースからデータを読込んでから、アプリケーションに読込まれるまでのデータの一時格納である。アプリケーションは、ストリーム型の変数に１回アクセスする度に１バッファ分の有限長データを読み書きし、それを繰り返すことによって無限長データを処理する。
【００２４】
以下の説明では、バッファをサイクリックに実装してあることを前提としているが、本発明においては必ずしもサイクリックでなくてもよい。また、管理部の構成要素として、バッファ情報（バッファのサイクル数、１サイクル当たりのデータサイズ、先頭アドレス）、及び、ネットワーク情報（ネットワークプロトコルスタック、サービス品質、自己及び相手のネットワークロケーション情報）がある。バッファ情報は前述のバッファに関する情報、ネットワーク情報はクライアントとサーバとの間の無限長データ用の通信チャネルに関する情報である。
【００２５】
なお、アプリケーションとネットワークインタフェースとの間でデータのコピーを防ぐために、ストリーム型の中にバッファを設けない構成とすることも可能である。
【００２６】
以下に、クライアントアプリケーション１がサーバオブジェクト５のオペレーションを呼出し、サーバオブジェクト５からクライアントアプリケーション１に無限長データが流れる場合の動作シーケンスを、図３乃至６を用いて説明する。ここでは、ＵＮＩＸ等のオペレーティングシステムが提供するネットワークインタフェースの一つであるソケットを分散処理環境６が使用する場合を想定している。図３は動作シーケンスの例を示す図、図４はクラス「ストリーム」を定義するコード記述例、図５はクライアントコードの記述例、図６はサーバの実装コードの記述例である。
【００２７】
先ず、クライアント側アプリケーション１の動作について説明する。クライアント側アプリケーション１は、従来のＣＯＲＢＡの要領でサーバオブジェクト５のリファレンスを得る（図５の（１０２）  ）。このリファレンスには、サーバ側のネットワークロケーション情報（ＩＰアドレス及びポート番号）等が含まれている（これはＣＯＲＢＡが規定するＩＯＲ（Ｉｎｔｅｒ−Ｏｐｅｒａｂｌｅ  Ｏｂｊｅｃｔ  Ｒｅｆｅｒｅｎｃｅ）  に準ずるものである）。この段階では、クライアント側アプリケーション１ではストリーム型の変数はまだ生成されていない。
【００２８】
次に、クライアント側アプリケーション１は、自ノードの分散処理環境６に対してサーバオブジェクト５へのオペレーション呼出しを行い、ブロック状態に入る（図３の（１）  、図５の（１０４）  ）。クライアント側アプリケーション１は、サーバオブジェクト５からのリターン（オペレーション呼出しに伴う処理の終了通知）を待たずに、ブロック状態から解放される（図３の（７）  ）。ブロック状態から解放されたときに、ストリーム型の変数がクライアント側でも生成されている。クライアント側アプリケーション１は、この変数の属性（変数内のバッファ情報）を得る（  図５の（１０６），（１０７）  ）。
【００２９】
クライアント側アプリケーション１は、ストリーム型の変数にアクセスして無限長データを読込む。１回のアクセスで全データの読込みが終了しない場合は繰り返し変数にアクセスする（図３の（１０）、図５の（１０９）  〜（１１６））。読込みの終了は、クライアント側アプリケーション１がデータの内容を判断して自主的に終了してもよいし（図５の（１１３），（１１５））、割込みを受けて中断してもよい。
【００３０】
次に、サーバオブジェクト５の動作について説明する。サーバオブジェクト５は、オペレーションの呼出しを受けると（図３の（３）  ）、ストリーム型の変数を生成する（図３の（４），（８）  、図４の（６）  ）。変数を生成するときのパラメータにはバッファ情報（サイクル数、１サイクル当たりのデータサイズ）及びサービス品質情報（ＱｏＳ  ）が含まれる。
【００３１】
変数生成の後、サーバオブジェクト５はストリーム型の変数にアクセスして無限長データを書込む。１回のアクセスで全データの書込みが終了しない場合は繰り返し変数にアクセスする（図３の（９）  、図６の（２０８）  〜（２１６））。書込みの終了は、サーバオブジェクト５が書込むべきデータの内容を判断して自主的に終了してもよいし（図６の（２１２），（２１４））、割込みを受けて中断してもよい。
【００３２】
最後にクライアント側及びサーバ側の分散処理環境６ａ及び６ｂの動作を説明する。クライアント側の分散処理環境６ａは、クライアント側アプリケーション１からオペレーション呼出しを受けると（図３の（１）  ）、サーバ側の分散処理環境６ｂにオペレーション呼出しのメッセージを送る（図３の（２）  ）。その内容は、サーバオブジェクト５のリファレンス、クライアント側のネットワークロケーション情報（ＩＰアドレス及びポート番号）、オペレーションの種類、パラメータの処理及び値を含む。次いで、サーバ側の分散処理環境６ｂは、サーバを起動して該当するオブジェクトに対してオペレーションを呼出す（図３の（３）  ）。ここまでのシーケンスは従来のＣＯＲＢＡのオペレーション呼出しと同一である。
【００３３】
次に、サーバオブジェクト５がストリーム型の変数インスタンスを生成すると（図３の（３）  ）、サーバ側の分散処理環境６ｂは、無限長データの通信用に新たな通信チャネルを生成する。そのため、新しいソケットを生成し、空いているポート番号を取得して新しいソケットに設定する。続いて、サーバ側の分散処理環境６ｂは、クライアント側の分散処理環境６ａに対して新たなチャネルへの接続要求のメッセージを送る（図３の（５）  ）。その内容にはサーバ側が新たに生成したソケットの情報（ネットワークアドレス、ポート番号）が含まれる。
【００３４】
クライアント側の分散処理環境６ａは、サーバ側に新しいソケットを生成する。次に、空いているポート番号をソケットに設定する。そしてサーバ側に完了通知のメッセージを送る（図３の（６）  ）。更に、クライアントアプリケーション１のブロックを解除する（図３の（７）  ）。このとき、クライアント側のストリーム型の変数インスタンスも生成されている。サーバ側の分散処理環境６ｂは、クライアント側から接続完了の通知を受けると、変数の生成に関わる処理を終了する（図３の（８）  ）。
【００３５】
サーバ側の分散処理環境６ｂは、サーバオブジェクト５からストリーム型の変数（内のバッファ）への書込みを受けると（図３の（９）  ）、変数内のバッファのデータを無限長データの通信用のソケットに対して書込む。一方、クライアント側の分散処理環境６ａは、クライアントアプリケーション１からストリーム型の変数からの読込み要求を受けると（図３の（１０））、無限長データの通信用のソケットからデータを読込み、そのデータをクライアントアプリケーション１に渡す。
【００３６】
なお、この実施例においては、無限長データ用の通信チャネルのインタフェースとしてソケットを用いたが、勿論他のものでもよい。必要なことは、サーバ側及びクライアント側双方の分散処理環境が互いにネットワークロケーション情報の授受及び接続要求等を行うことである。また、分散処理環境間のやりとり及び処理は、サーバオブジェクト及びクライアントアプリケーションには見えないものであり、サーバはストリーム型の変数を生成する（プログラミング上では、変数宣言する）のみであることに注意すべきである。
【００３７】
次に、アプリケーション開発者のコード記述例を説明する。ＩＤＬ記述は、図４のＡに示すとおり、シグネチャ「ｓｔｒｅａｍ」がストリーム型を意味する。アプリケーション開発者は、このシグネチャを用いてストリーム型のパラメータを宣言する。「ｏｕｔ  」とあるのは、従来のデータ型と同じように、サーバ側からクライアント側に無限長データが流れることを示している。
【００３８】
Ｃ＋＋をプログラミング言語としたコード記述例は、図４のＢ、図５及び図６に示すとおりである。図４のＢはストリーム型のクラス宣言である。これは、ＩＤＬコンパイラが、上述のＩＤＬ記述を入力とし、ヘッダファイルとしてストリーム型のクラス宣言を出力するものである。（３）  〜（８）  は、ストリーム型に対するオペレーションである。そのうち（３），（４）  はストリーム型の変数の初期化に用いられる。特に（４）  ではバッファサイズ等の情報を同時に設定する。（５），（６）  はバッファサイズ等の情報を得るためのオペレーションである。（７）  はバッファサイクルのインデックスを指定してそのインデックスのバッファにあるデータを読込むオペレーションである。（８）  は（７）  とは逆にデータを書込むオペレーションである。
【００３９】
図５は、クライアント側アプリケーションの実装コード、図６はサーバのオペレーションの実装コードである。これらのコードについては、上述の動作シーケンスの説明の中で述べたとおりである。なお、図５の（１０４），（１１２）  は、ストリーム型の変数から読込んだデータの処理に関するものである。また、図６の（２０４），（２１０）  は、ストリーム型の変数に書込むべきデータの処理に関するものである。
【００４０】
上述の実施例の説明においては、無限長データの流れがサーバオブジェクトからクライアントアプリケーションに向かう例について説明したが、逆に、クライアントアプリケーションからサーバオブジェクトに向かう場合も同様にして実現できることは勿論である。
【００４１】
以上の実施例の説明から、分散処理環境は、クライアントアプリケーション及びサーバオブジェクト共に、無限長データを通信するためにネットワーク管理インタフェースを使用する必要がなく、また、意識する必要もないことが分かる。従って、アプリケーション開発者にとって無限長データの扱いが簡素化され、アプリケーション開発負担を軽減できる利点を持つ。
【００４２】
また、実施例の説明から、無限長データへのアクセス手段をオペレーションのパラメータとして提供しており、無限長データへのアクセスを可能にするための通信開始或いは通信停止等のオペレーションの定義を必要としないことが分かる。従って、この実施例によれば、アプリケーション開発の柔軟性を損なわないという利点を持つ。
【００４３】
【発明の効果】
以上説明したとおり、本発明は以下のような効果を奏する。即ち、第１に、有限長データの通信と無限長データの通信とを、要求応答型という同一の通信作法で行うことができるようになった。実現の形態の例としては、ＲＰＣ又は分散処理環境において、サーバの手続き又はサーバオブジェクトのオペレーションを呼出すという作法で、有限長データの通信及び無限長データの通信双方を実現できる。これは、両種類のデータを扱うシステムでも、一貫したシステム開発が可能になることを示している。特に、ＣＯＲＢＡ等の分散オブジェクト環境では、有限長データに限らず無限長データに関するサービスを提供する主体をもオブジェクトと表すことができるので、システムの分析、設計、実装といった一連の開発サイクルを、オブジェクト指向という一貫した手法で行うことができる。また、トレーダ及びネームサービス等の汎用のオブジェクトサービスを、無限長データのサービスを提供するオブジェクトに関してそのまま利用できる利点もある。第２には、ネットワーク管理インタフェースを意識せずに無限長データの通信を開発でき、無限長データの扱いを簡素化してアプリケーション開発の負担を軽減することができる利点がある。
【図面の簡単な説明】
【図１】分散処理環境とアプリケーションとの全体構成の機能分類を示す図である。
【図２】分散処理環境の全体構成を示す図である。
【図３】動作シーケンスの例を示す図である。
【図４】クラス「ストリーム」を定義するコード記述例を示す図である。
【図５】クライアントコードの記述例を示す図である。
【図６】サーバの実装コードの記述例を示す図である。
【符号の説明】
１  クライアントアプリケーション
２  クライアント側データ処理部
３  データ通信部
４  サーバ側データ処理部
５  サーバオブジェクト
６  分散処理環境
６ａ  クライアント側分散処理環境
６ｂ  サーバ側分散処理環境
１０  コンピュータ
【図１】
0003569114.tif 000002
【図２】
0003569114.tif 000003
【図３】
0003569114.tif 000004
【図４】
0003569114.tif 000005
【図５】
0003569114.tif 000006
【図６】
0003569114.tif 000007