JP2000242587A - オブジェクト処理装置及びそのプログラム記憶媒体 - Google Patents

Abstract

(57)【要約】 【課題】 本発明は、オブジェクト処理装置及びそのプ
ログラム記憶媒体に関し、プロトコルに依存することな
くデータ転送を行いその中断及び再開を自動的に行うこ
とを目的とする。 【解決手段】 複数転送制御部２２０は、アプリケーシ
ョン１００からの通信プロトコルにかかわりないオブジ
ェクトの送信の指示を、統一インタフェースに従って受
け付ける。プロトコル制御部２６０は、このオブジェク
トの送信の指示を、その送信を行うべき通信処理部３０
５に渡す。通信処理部３０５は、定められた通信プロト
コルに従って、渡されたオブジェクトの送信を行う。送
信を中断したオブジェクトの送信の指示が再度アプリケ
ーション１００からあった場合、中断再開制御部２２１
が、オブジェクトの内の送信済の部分についての送信済
情報に基づいて、送信済でない部分から複数転送制御部
２２０に送信を行わせる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、オブジェクト処理
装置及びそのプログラム記憶媒体に関し、特に、通信の
プロトコル等に依存することなくデータ転送の処理に関
する少なくともコンテント、ユーザ又はノードを含む操
作対象物を含む操作対象物をオブジェクトとして統一的
に管理すると共に、データ転送の中断及び再開を自動的
に行うオブジェクト処理装置及びそのプログラム記憶媒
体に関する。

【０００２】

【従来の技術】インターネット等の発達により、ネット
ワークコンピューティング環境が著しく整備されてい
る。このような環境下では、アプリケーション（プログ
ラム）がインターネット等を利用して処理を行い、コン
ピュータ間において頻繁にデータ転送を行う。例えば、
同一ネットワーク内におけるサーバやクライアントの間
でのデータ転送に限らず、異なるネットワークに接続さ
れたコンピュータ間でのデータ（プログラムを含む）転
送も行われる。このようなアプリケーションの開発に当
たっては、次の点に留意する必要がある。

【０００３】第１に、インターネットを利用した分散環
境で業務を構築する場合、業務アプリケーションの動作
するプラットフォームを制限することは難しい。また、
制限するとスケーラビリティが失われてしまうという問
題がある。従って、このようなアプリケーションには、
マルチプラットフォーム上で動作することが求められ
る。

【０００４】第２に、インターネットでの技術革新は目
覚ましく、新しい通信媒体やプロトコルが次々と採用さ
れる。これら利用するためには、進歩する通信媒体やプ
ロトコルなどのインターネット技術に追従していく必要
がある。

【０００５】第３に、分散した拠点間で業務を構築する
場合、業務で利用するアプリケーションの配布を従来の
ように人手を掛けて行うと、時間とコストが問題とな
る。従って、アプリケーションを配布／管理する機能が
求められる。

【０００６】第４に、ネットワークインフラストラクチ
ャーの整備により、帯域幅は拡大する傾向にある。しか
し、イメージデータや動画、アプリケーションの配布な
ど、転送データ自身のデータ容量も増大しているため、
何らかの回線負荷軽減の手段が必要である。

【０００７】第５に、インターネットを利用するアプリ
ケーションは、セキュリティを考慮して作成しなければ
ならない。さらに、作成したアプリケーションを企業に
導入する場合、企業内ネットワークのセキュリティ強度
を落とすことなく、導入できなければならない。

【０００８】

【発明が解決しようとする課題】インターネットを利用
するアプリケーションを開発する場合において、及び、
前述の第２の点に関して、アプリケーション（及びその
開発者）の負担が大きい。即ち、複数のファイルやメッ
セージ等を転送する場合には、ファイル毎に転送に使用
するプロトコルが異なることがある。この場合、プロト
コルごとにその転送処理の方法が異なり、それらをアプ
リケーションが意識しなければならなかった。即ち、ア
プリケーションの開発者が意識してプログラミングを行
わなければならなかった。

【０００９】また、前述の第４の点に関して、転送を行
っている途中で当該転送処理を中断し、後にその中断し
た時点から送信を再開することは一部のプロトコルでし
かサポートされていなかった。この点からも、アプリケ
ーションは、使用するプロトコルを意識しないで、転送
の中断・再開を行うことは不可能であった。また、多く
のプロトコルでは、何らかの原因で転送の中断・再開が
生じた場合、当該転送データを最初から全て送信し直さ
なければならず、回線負荷の増加の一因となっていた。
これは、アプリケーションが信頼性の低い回線を使用し
て大量にデータ送信しなければならない場合において
は、無駄なトラフィックを生じ、特に大きな問題とな
る。

【００１０】また、前述の第２の点に関して、新しい技
術に追従しようとすると、アプリケーション（及びその
開発者）の負担が大きい。即ち、新しいデータの表現形
式、管理形式、アクセス方式、プロトコル等が開発され
た場合、アプリケーションの汎用性を確保しようとする
と、アプリケーション開発者がインターネットを利用す
るアプリケーションの処理コードを逐次書き換えること
により、当該アプリケーションを更新する必要がある。

【００１１】本発明は、プロトコルに依存することな
く、データ転送の処理に関する少なくともコンテント、
ユーザ又はノードを含む操作対象物を含む操作対象物を
オブジェクトとして統一的に管理するオブジェクト処理
装置を提供することを目的とする。

【００１２】また、本発明は、データ転送の処理の中断
及び再開を自動的に行うオブジェクト処理装置を提供す
ることを目的とする。

【００１３】また、本発明は、プロトコルに依存するこ
となく、データ転送の処理に関する少なくともコンテン
ト、ユーザ又はノードを含む操作対象物を含む操作対象
物をオブジェクトとして統一的に管理する処理を、コン
ピュータである当該オブジェクト処理装置に実行させる
プログラムを記憶したプログラム記憶媒体を提供するこ
とを目的とする。

【００１４】

【課題を解決するための手段】図１は本発明の原理構成
図であり、本発明のオブジェクト処理装置を示す。オブ
ジェクト処理装置は、複数転送制御部２２０と、プロト
コル制御部２６０と、通信処理部３０５とからなる。複
数転送制御部２２０は、アプリケーション１００からの
オブジェクトの送信の指示を統一転送インタフェースに
従って受け付け、これをプロトコル制御部２６０に渡
す。アプリケーション１００は、通信プロトコルにかか
わりなく、送信対象をオブジェクトとして送信を指示す
る。プロトコル制御部２６０は、複数転送制御部２２０
から渡されたオブジェクトの送信の指示を、当該送信を
行うべき通信処理部３０５に渡す。複数の通信処理部３
０５の各々は、予め定められた異なる通信プロトコルに
従って、プロトコル制御部２６０から渡されたオブジェ
クトの送信を行う。

【００１５】また、本発明のオブジェクト処理装置は、
以上の構成に加えて、中断再開制御部２２１とからな
る。中断再開制御部２２１は、複数転送制御部２２０を
監視し、当該オブジェクトの内の送信済の部分について
の送信済情報を保持する。先に送信を中断したオブジェ
クトの送信の指示が再度アプリケーション１００からあ
った場合、中断再開制御部２２１が、送信済情報に基づ
いて、当該オブジェクトの内の送信済でない部分から複
数転送制御部２２０に送信を行わせる。

【００１６】本発明のオブジェクト処理装置によれば、
アプリケーション１００は、送信の対象であるファイル
やメッセージ（コンテント又はコンテンツ）を、それら
の種々の異なる通信プロトコルを意識することなく、オ
ブジェクトとして送信を指示するのみで良い。従って、
アプリケーションは、様々なプロトコルを用いて同時に
複数のオブジェクト（ファイルやメッセージなど）の転
送を行うことができる。このため、アプリケーション開
発者も煩雑な処理コードを記述する必要がない。従っ
て、本発明によれば、アプリケーション１００は、種々
の通信プロトコルを意識することなく一元的に取り扱う
ことができる。従って、新しいプロトコルが開発された
場合でも、アプリケーション１００の処理コードを書き
換ええなくても、容易に対応できる。

【００１７】また、本発明のオブジェクト処理装置によ
れば、中断再開制御部２２１が送信済情報を保持するの
で、転送を一時中断した後に再び中断した時点からの転
送を継続することができる。従って、アプリケーション
１００が信頼性の低い回線を使用して大量データ送受信
しなければならない場合においても、無駄なトラフィッ
クを低減した転送を行うことができる。

【００１８】

【発明の実施の形態】最初に、本発明の適用されるオブ
ジェクト処理装置の概要について簡単に説明する。図２
乃至図４はオブジェクト処理装置構成図であり、本発明
の適用されるオブジェクト処理装置の構成を示す。

【００１９】図２は本発明のオブジェクト処理装置の構
成を示す。オブジェクト処理装置は、その上位レイアか
ら、フレームワークレイア２００、機能実装レイア３０
０、データ格納手段４００等の物理レイアからなる。フ
レームワークレイア２００と機能実装レイア３００とで
オブジェクトアクセス管理手段３５０を構成する。フレ
ームワークレイア２００はアプリケーション１００に本
発明のオブジェクト処理装置の機能をフレームワークと
して提供するための共通サービス処理部２０１を備え
る。機能実装レイア３００はオブジェクト処理装置がア
プリケーション１００に提供する種々の機能（管理処理
部）を備える（実装する）。例えば、セキュア通信管理
処理部３０３、マルチキャスト管理処理部３０２、デー
タ格納手段管理手段３０１であるリポジトリ管理処理部
３０１等である。

【００２０】上位統一インタフェース１５０はアプリケ
ーション１００と共通サービス処理部２０１との間のイ
ンタフェース（ＡＰＩ）であり、下位統一インタフェー
ス２５０は共通サービス処理部２０１とリポジトリ管理
処理部３０１との間のインタフェース（ＡＰＩ）であ
る。即ち、リポジトリインタフェースである。統一イン
タフェース１５０は、アプリケーション１００が少なく
ともコンテント、ユーザ又はノードを含む操作対象物を
含む操作対象物についてのデータの操作をオブジェクト
の操作として指示するためのものであり、共通サービス
処理部２０１又はオブジェクトサービス処理部２０３が
アプリケーション１００からの指示をオブジェクトの操
作についての指示として受け付けるためのものである。
統一インタフェース２５０は共通サービス処理部２０１
又はオブジェクトサービス処理部２０３が受け付けたオ
ブジェクトの操作についての指示を当該操作を行うべき
データ格納手段管理手段３０１に渡すためのものであ
る。アプリケーション１００は、当該種々の機能を利用
する場合、共通サービス処理部２０１との間で統一イン
タフェース１５０に従って、オブジェクトの操作の指示
を行うのみであり、機能実装レイア３００を意識するこ
とはない。

【００２１】本発明のオブジェクト処理装置では、図６
を参照して後述するベースオブジェクトクラスに定義で
きる対象、即ち、コンテント、ユーザ、クライアント等
をオブジェクトと呼ぶ。何をオブジェクトとして定義す
るかは、アプリケーション１００の自由である。従っ
て、コンテント等以外のものでもオブジェクトとして定
義できる。オブジェクトの操作とは、オブジェクトに何
らかの変更を加え得ることを言う。例えば、後述する作
成、登録、更新、取得、削除、検索、一覧等の処理であ
る。

【００２２】更に、本発明のオブジェクト処理装置で
は、コンテント、ユーザ、クライアント自体をオブジェ
クトとして管理するのではなく、実際には、コンテン
ト、ユーザ、クライアントの管理情報をオブジェクトと
して管理する。これにより、コンテント、ユーザ、クラ
イアントをオブジェクトとして一元的に管理すると共
に、これらの管理情報を用いてオブジェクトの操作を変
換する。これにより、アプリケーション１００は仮想的
に統一されたオブジェクトにより命令を記述でき、一
方、オブジェクトの操作を実際のデータの処理に変換で
きる。

【００２３】図３は主としてフレームワークレイア２０
０の構成の概要について示す。フレームワークレイア２
００又は共通サービス処理部２０１は、アプリケーショ
ン１００にとって必要な共通の機能を、統一インタフェ
ース１５０で提供する。

【００２４】データやプログラムを集配信するアプリケ
ーション１００には大きく３つのタイプがある。第１
に、情報のブロードキャストを行うアプリケーション１
００は、ニュースやアナウンスなどの情報を配信し、ま
た、視聴者の視聴率情報などを集計する。第２に、拠点
支援を行うアプリケーション１００は、拠点（支店や関
係会社など）へ業務情報や業務アプリケーション１００
を配信し、また、拠点からは業務データ（売り上げデー
タなど）を集計する。第３に、業務システム間の連携を
行うアプリケーション１００は、ネットワークで接続さ
れた業務システム間でデータのやり取りを行う。多くの
システムにおいてはデータはデータベースで管理され
る。共通サービス処理部２０１は、このようなアプリケ
ーション１００にとって必要な共通の機能を、統一イン
タフェース１５０であるＡＰＩで提供する。即ち、共通
サービス処理部２０１は、このようなアプリケーション
１００に共通して必要な機能である、業務データなどの
コンテント（集配信対象）の管理、ユーザ（集配信先）
の管理、クライアント（集配信先）の管理、及び、セキ
ュリティを確保したネットワーク経由でのコンテントの
集配信を、統一インタフェース１５０の下で行う。

【００２５】共通サービス処理部２０１がアプリケーシ
ョン１００に提供するフレームワークは、以下の６つの
サービス処理部により与えられる。

【００２６】オブジェクトサービス処理部２０３は、オ
ブジェクト処理装置で集配信する対象であるコンテント
および集配信先であるクライアント・ユーザなどを管理
する。このオブジェクト処理装置では、コンテントはＲ
ＤＢ、ファイル、ディレクトリ等の種々のデータ格納手
段４００に存在する。本発明のオブジェクト処理装置で
はこれらの種々のデータ格納手段４００をリポジトリ４
００と呼ぶ。従って、データ格納手段管理手段３０１は
リポジトリ管理処理部３０１と呼ぶ。オブジェクトサー
ビス処理部２０３は、アプリケーション１００からの依
頼を受けて、リポジトリ４００に存在するデータを操作
する。従って、オブジェクトサービス処理部２０３はリ
ポジトリ管理部３０１の上位層である。これにより、ア
プリケーション１００が、リポジトリ４００の種別（Ｒ
ＤＢ、ファイル、ディレクトリなど）や管理方法（オブ
ジェクトの永続保存なのか、他のリポジトリのマッピン
グなのか）を意識する必要はなく、アプリケーション開
発者がアプリケーション作成に専念できる。

【００２７】オブジェクトサービス処理部２０３では、
図６を参照して後述するように、リポジトリ４００への
保存が可能なベースオブジェクトクラスを定義し、この
クラスを操作対象とする。これにより、オブジェクトサ
ービス処理部２０３はアプリケーション１００に対して
統一インタフェース１５０としてのＡＰＩを提供する。
従って、アプリケーション１００は、このベースオブジ
ェクトクラスを拡張することにより、アプリケーション
１００に適したデータ構造を表現することができる。

【００２８】転送サービス処理部２０４は、以上のよう
に定義されたオブジェクトをネットワーク経由で集配信
する。転送サービス処理部２０４は、集配信という観点
から統一インタフェース１５０であるＡＰＩを提供す
る。アプリケーション１００は統一インタフェース１５
０を介して転送サービス処理部２０４にオブジェクトを
渡すだけで、そのオブジェクトの転送が実現できる。こ
れにより、アプリケーション１００は、実際の通信に使
用する通信プロトコルや通信のための処理ロジックを意
識する必要が無い。また、管理されているオブジェクト
との親和性が高いため、煩雑な処理コ−ドを記述する必
要も無い。

【００２９】転送サービス処理部２０４は、図示しない
が、統一インタフェース１５０を提供する転送マネージ
ャと、通信プロトコルを制御する通信プロトコルハンド
ラとからなる。これらは、実際の通信処理を行うセキュ
ア通信管理処理部３０３およびマルチキャスト管理処理
部３０２の上位層である。セキュア通信管理処理部３０
３およびマルチキャスト管理処理部３０２は、物理層で
ある通信手段５００を介して他のアプリケーション６０
０との間での通信を行う。このような階層構成により、
新規の通信プロトコルの追加にも柔軟に対応できる。

【００３０】後述するように、本発明の複数転送制御部
２２０及び中断再開制御部２２１は転送サービス処理部
２０４に設けられる。即ち、複数転送制御及び中断再開
制御の処理は、転送サービス処理部２０４の実現するサ
ービスの一部と考えて良い。複数転送制御部２２０及び
中断再開制御部２２１の転送対象であるオブジェクト
は、前述のように、オブジェクトサービス処理部２０３
において統一的に管理されている（又は、新たに作成し
た直後で登録前の）オブジェクト、即ち、コンテントで
ある。また、転送先も、オブジェクトサービス処理部２
０３において統一的に管理されているオブジェクト、即
ち、ノード（クライアント）又はユーザである。

【００３１】オブジェクトサービス処理部２０３及び転
送サービス処理部２０４により、差分管理及び差分転送
機能２０８、配布管理機能２０９が実現される。差分管
理及び差分転送機能２０８は、アプリケーション１００
からのオブジェクトサービス処理部２０３に対する指示
により、自己のリポジトリ４００に格納されたコンテン
トが更新された場合、更新前のコンテントと更新後のコ
ンテントとの差分についての情報（差分情報）を作成
し、これを予め定められた他のノード、クライアントに
転送する。配布管理機能２０９は、アプリケーション１
００からのオブジェクトサービス処理部２０３に対する
指示により、自己のリポジトリ４００に格納されたコン
テントが他のノード、クライアントに配布された場合、
その配布についての情報（配布情報）を作成し、管理す
る。

【００３２】イベントサービス処理部２０５は、オブジ
ェクト処理装置内のさまざまな事象をイベントとしてア
プリケーション１００へ通知する。

【００３３】監視サービス処理部２０６は、オブジェク
ト処理装置外のさまざまな事象（ＤＢの更新やファイル
システムの更新の他に、日付時刻の監視といったスケジ
ューリングなど）を監視し、事象発生時にイベントとし
てアプリケーション１００に通知する。

【００３４】コマンドサービス処理部２０７は、以上の
サービス処理部における処理を総合的に扱った機能の実
装をオブジェクト処理装置にプラグインする。コマンド
サービス処理部２０７は、オブジェクト処理装置の標準
として、いくつかのコマンドを用意する。

【００３５】コマンドサービス処理部２０７は、各サー
ビスを複合的に利用したロジックを一つのコマンドとし
てオブジェクト処理装置にプラグインする。例えば、監
視サービス処理部２０６を利用してリポジトリ４００の
ＤＢを監視し、これが更新されたらその情報をpushする
という複合ロジックを、アプリケーション１００がコマ
ンドサービス処理部２０７にコマンドとして登録するこ
とができる。また、コマンドサービス処理部２０７は、
転送先のオブジェクト処理装置内で、アクションを実行
する。即ち、コンテントと共にアクションも配信でき
る。これにより、実行形式のアプリケーション１００を
転送先で起動することができる。

【００３６】管理サービス処理部２０２は、アプリケー
ション１００が共通サービス処理部２０１に対して種々
のサービスを要求する場合のアプリケーション１００に
対する窓口となり、フレームワークとしての基本構造を
提供する。

【００３７】アプリケーション１００は、オブジェクト
サービス処理部２０３等を利用することにより、情報の
転送形式（ネットワークプロトコル等）や情報の格納形
式（データベース種別等）を意識することなく、コンテ
ント、クライアント、ユーザなどの管理、コンテント、
メッセージ、ファイルの集配信、及び、イベント、スケ
ジュールの制御を、統一インタフェース１５０で利用で
きる。また、アプリケーション１００の開発者は、共通
サービス処理部２０１を利用してアプリケーション１０
０を開発することにより、統一インタフェース１５０に
沿ってプログラムコ−ドを記述するだけで、マルチコン
テントの集配信機能を持つアプリケーション１００を作
成することができる。即ち、アプリケーション１００の
開発者は、プリミティブレベルでの操作を意識すること
なく、アプリケーション１００本来のソリューション
（ビジネスロジック）の開発に専念することができる。

【００３８】図４は主として機能実装レイア３００の構
成の概要について示す。

【００３９】リポジトリ管理部３０１は、オブジェクト
を永続的に管理し、オブジェクトの検索・更新・取り出
しを行う。また、リポジトリ管理部３０１では、各種の
コンテントや接続するクライアントなどの管理情報をオ
ブジェクトとして管理する。リポジトリ管理部３０１
は、オブジェクトサービス処理部２０３に対して、リポ
ジトリ４００の種類（格納庫の種類）を意識させない統
一インタフェース２５０を提供する。

【００４０】リポジトリ管理部３０１でサポートするリ
ポジトリ４００の種類は、独自ファイル・ＲＤＢ・ディ
レクトリなど多岐に渡る。リポジトリ管理部３０１に対
するアクセスでは、アプリケーション１００がリポジト
リ４００の種別を意識することなく、同一の手順でアク
セスできる統一インタフェース２５０を提供する。即
ち、リポジトリ管理部３０１は、図示しないが、アプリ
ケーション１００又はオブジェクトサービス処理部２０
３が利用する共通のＡＰＩと、リポジトリ４００の各々
に対応するアダプタとからなる。リポジトリ４００の切
り替えは、リポジトリ管理部３０１のＡＰＩからリポジ
トリ４００の種類を指定することにより、ダイナミック
に変更することができる。

【００４１】リポジトリ管理部３０１は、オブジェクト
を永続的に管理するために、クラス定義情報及びフィー
ルド定義情報を保持し、また、継承関係、参照関係、及
びデータ管理の情報を保持する。これにより、リポジト
リ管理部３０１は、複雑なオブジェクトの検索、復元を
高速に処理する。また、リポジトリ管理部３０１は、リ
ポジトリ４００がＲＤＢやディレクトリである場合に
は、クラス・フィールドと各リポジトリ４００とのマッ
ピング情報の管理により、円滑にオブジェクトの授受を
行う。

【００４２】マルチキャスト通信管理処理部３０２はマ
ルチキャストを利用して多数のクライアントへのコンテ
ントの一斉配信を行う。マルチキャストを利用した通信
では、サーバはパケットを一つしか送信しなくて良い。
データは次々と複製されグループ内のクライアント全体
にデータが配信される。例えば天気予報などのコンテン
トを配信するサーバ（配信元）であるアプリケーション
１００はクライアント（配信先）に指定時間に一斉にコ
ンテントを配信し、すべてのクライアントがほぼ同時に
コンテントを受信することが可能である。また、マルチ
キャスト通信管理処理部３０２は通信基盤に通信衛星を
利用したマルチキャスト通信にも対応している。

【００４３】これにより、マルチキャスト通信管理処理
部３０２は、回線負荷の軽減、サーバ負荷の軽減、及
び、同報性の確保を実現することができる。即ち、従来
のInternet Protocol(ＩＰ）通信（ユニキャスト）を使
った一般的なコンテント配信では、サーバはクライアン
トに対してポイント・ツー・ポイントでそれぞれにデー
タを転送するので、クライアントの台数を増やした時に
はネットワーク上に流れるパケットが増加する。これに
より、回線負荷、配信時間、回線使用料金が増加する。
また、一斉配信での同報性が期待できず、クライアント
間で時間差が生じる。マルチキャスト通信によれば、こ
のような不都合を防止できる。

【００４４】更に、マルチキャスト通信管理処理部３０
２は、パケットの送出後にパケットロスト等により通信
が中断した場合、クライアントからＮＡＫ(Negative Ac
knowledgment、不着通知）をサーバに返す等の手段を採
用する。この通知により、サーバであるアプリケーショ
ン１００はロストしたパケットを再送して、信頼性を確
保する。これにより、マルチキャスト通信管理処理部３
０２は信頼性のある一斉配信を実現することができる。
即ち、マルチキャスト通信ではトランスポート層のプロ
トコルとしてＵＤＰ（User Datagram Protocol) を使用
する。ＵＤＰはデータが正しく転送されることを保証す
るＴＣＰ（Transmission Control Protocol)とは異なり
信頼性がなく、経路中でパケットロストする可能性があ
る。このため、コンテントがプログラムデータ等である
場合には向いていなかった。マルチキャスト通信管理処
理部３０２によれば、信頼性のある一斉配信を実現する
ことができる。

【００４５】また、マルチキャスト通信管理処理部３０
２は、図示しないが、マルチキャスト中継ゲートウェイ
に接続される。マルチキャスト通信管理処理部３０２に
対するマルチキャスト中継ゲートウェイは、リポジトリ
管理部３０１に対するリポジトリ４００に相当する。マ
ルチキャスト中継ゲートウェイは、マルチキャストのデ
ータをユニキャストデータにカプセル化してルータを経
由させ、中継先のゲートウェイで元のマルチキャストデ
ータに復元して再送する。これにより、マルチキャスト
通信管理処理部３０２はマルチキャストをユーザのネッ
トワーク環境に合わせて運用することが可能である。即
ち、ユーザのネットワーク環境において、マルチキャス
ト通信に対応していないルータが存在する場合でもマル
チキャストによる一斉配信を可能とするため、マルチキ
ャスト中継ゲートウェイによりマルチキャストのデータ
をユニキャストデータにカプセル化してルータを経由さ
せる。マルチキャスト通信管理処理部３０２によれば、
マルチキャストをユーザの環境に合わせて運用すること
ができる。

【００４６】各種の通信管理部３０５はＩＰ通信（ユニ
キャスト）によるクライアントへのコンテントの配信を
行う。各種の通信管理部３０５は種々のプログラムをサ
ポートする。即ち、ＨＴＴＰ（及びＨＴＴＰＳ）、ＦＴ
Ｐ、ＳＭＴＰ、ＳＳＬ、Ｓｏｃｋｓ等である。

【００４７】図５はオブジェクト処理装置説明構成図で
あり、本発明の適用されるオブジェクト処理装置の構成
を示す。

【００４８】アプリケーション１００は、少なくともコ
ンテント、ユーザ又はノードを含む操作対象物を含む操
作対象物についてのデータの操作をオブジェクトの操作
として指示する。この時、アプリケーション１００は、
オブジェクトサービス処理部２０３の統一インタフェー
ス１５０のみを意識する。従って、リポジトリ４００に
ついての意識はない。

【００４９】複数のリポジトリ（データ格納手段）４０
０は、少なくともコンテント、ユーザ又はノードを含む
操作対象物を含む操作対象物についてのデータを各々が
異なる形態で格納する。複数のリポジトリ４００は、図
５に示すように、例えば、ＲＤＢ（４００Ａ）、ファイ
ル（４００Ｂ）、ディレクトリ（４００Ｃ）、その他の
例えば、独自のデータベース（４００Ｄ）からなる。こ
れらは、全てデータのアクセス手段、管理手段、格納形
式等が異なる。なお、必要に応じて、Ａ乃至Ｄの符号を
付けて区別する。

【００５０】オブジェクトアクセス管理手段３５０は、
アプリケーション１００と複数のリポジトリ４００との
間に設けられ、複数のリポジトリ４００に格納された少
なくともコンテント、ユーザ又はノードを含む操作対象
物を含む操作対象物についてのデータをオブジェクトと
して統一的に管理する。このために、オブジェクトアク
セス管理手段３５０は、オブジェクトサービス処理部２
０３と、複数のリポジトリ４００の各々に対応して設け
られた複数のリポジトリ管理部（データ格納手段管理手
段）３０１とからなる。リポジトリ管理部３０１Ａ、
Ｂ、Ｃ及びＤは、各々、ＲＤＢ管理部、ファイル管理
部、ディレクトリ管理部、独自のデータベース管理部で
ある。

【００５１】オブジェクトサービス処理部２０３は、ア
プリケーション１００からのオブジェクトの操作につい
ての指示を統一インタフェース１５０に従って受け付
け、当該操作を行うべきリポジトリ管理部３０１を選択
して、これに受け付けたオブジェクトの操作についての
指示を統一インタフェース２５０に従って渡す。このた
めに、オブジェクトサービス処理部２０３はオブジェク
トと複数のリポジトリ管理部３０１との対応を記述した
第１テーブル（リポジトリテーブル）２１０を備える。
オブジェクトサービス処理部２０３は、リポジトリテー
ブル２１０を参照して、受け付けたオブジェクトの操作
についての指示を渡すべきリポジトリ管理部３０１を求
める（選択する）。このために、リポジトリテーブル２
１０は、図７を参照して後述するように、オブジェクト
型毎に、対応するデータ格納手段４００の種別とリポジ
トリ管理部３０１とを記述してなる。オブジェクト型と
複数のリポジトリ管理部３０１との対応は、当該オブジ
ェクト型をリポジトリテーブル２１０に登録したアプリ
ケーション１００が、当該対応をリポジトリテーブル２
１０に記述することにより定める。

【００５２】リポジトリ管理部３０１は、オブジェクト
サービス処理部２０３から渡された受け付けたオブジェ
クトの操作についての指示を、当該データの操作につい
ての指示に変換し、これに基づいて、対応するリポジト
リ４００に格納された少なくともコンテント、ユーザ又
はノードを含む操作対象物を含む操作対象物についての
データを操作する。このために、複数のリポジトリ管理
部３０１（３０１Ａ乃至３０１Ｄ）は、各々、オブジェ
クトと対応するリポジトリ４００の格納する少なくとも
コンテント、ユーザ又はノードを含む操作対象物を含む
操作対象物についてのデータとの関係を記述した第２テ
ーブル（マップテーブル）３０６（３０６Ａ乃至３０６
Ｄ）を備える。リポジトリ管理部３０１は、自己の持つ
第２テーブルを参照して、受け付けたオブジェクトの操
作についての指示を当該データの操作についての指示に
変換する。このために、第２テーブルは、図８を参照し
て後述するように、オブジェクト型及びこれに対応する
データ毎に、これらの間における相互の変換規則を記述
してなる。オブジェクトの操作についての指示を当該デ
ータの操作についての指示に変換するための変換規則
は、当該オブジェクト型及びこれに対応するデータを第
２テーブルに登録したアプリケーション１００が、当該
変換規則を第２テーブルに記述することにより定める。
また、当該アプリケーション１００は、変換規則におい
て、当該オブジェクト型に対応するデータのフォーマッ
トを記述する。

【００５３】以上により、前述のマルチプラットフォー
ム上での動作を保証することができ、アプリケーション
（及びその開発者）の負担を小さくすることができる。
即ち、スキーマ定義、ファイルフォーマット等のデータ
の表現の形式、関係データベース（ＲＤＢ）、ディレク
トリ、そのシステムやアプリケーション独自のデータベ
ース（独自ＤＢ）、ファイルシステム等のデータの管理
の形式、ＲＤＢ用のストラクチャードクエリランゲージ
（ＳＱＬ）、オープンデータベースコネクティビティ
（ＯＤＢＣ）、ライトウェイトディレクトリアクセスプ
ロトコル（ＬＤＡＰ）、そのデータベースコンピュータ
独自のプロトコル（独自プロトコル）、低位のＡＰＩ
（アプリケーションプログラミングインタフェース）等
のデータへのアクセス方法の方式を意識する必要がな
い。このため、アプリケーション開発者がインターネッ
トを利用するアプリケーションにおいて煩雑な処理コー
ドを記述する必要がない。具体的には、その独自のフォ
ーマットのファイル等にオブジェクトをそのまま管理す
る一般的なオブジェクト指向データベース（ＯＯＤＢ）
のように、他の種類のＲＤＢやディレクトリは取り扱え
ないと言う不都合はない。また、ＲＤＢのテーブルをオ
ブジェクトとして操作する機能を有するオブジェクト指
向関係データベース（ＯＲＤＢ）のように、他のファイ
ルやディレクトリをも含めた上で同一のインタフェース
で取り扱うことはできないと言う不都合はない。また、
操作対象のデータフォーマットをユーザ側で定義するこ
とができる。

【００５４】図６はオブジェクト説明図であり、オブジ
ェクトの種類及び階層の一例を示す。即ち、アプリケー
ション１００が登録しオブジェクトサービス処理部２０
３が管理するオブジェクトの一例であり、オブジェクト
の種類（何をオブジェクトとして登録するか）及び階層
（当該オブジェクトをどこに位置付けるか）は登録する
アプリケーション１００が、オブジェクトサービス処理
部２０３の提供するベースオブジェクトクラス、ベクタ
ークラス、ディクショナリクラスを利用して、自由に定
める。

【００５５】図６において、ベースオブジェクトクラス
は、コンテント、ユーザ、クライアント（ノード）の３
種類のグループと、ベクタークラスと、ディクショナリ
クラスとからなる。コンテントはデータやプログラム等
の処理の対象、即ち、情報である。コンテントは、更
に、ニュースサービスにおける（新聞）記事、業務を行
うクライアントにおける業務データ、プログラムからな
る。ノードはコンテントの処理を行う装置（コンピュー
タ）である。ユーザはノードへの指示によりコンテント
及びノードを利用する人間である。ベクタークラスは、
Ｊａｖａ言語における配列用のクラスであり、記事の集
合であるチャネルと、会社組織等の集合単位を表す組織
と、ユーザ、クライアント、コンテント等の集合を表す
グループ等とからなる。ディクショナリクラスは、アプ
リケーション１００の利用するコンテント所有者及びコ
ンテント配布管理と、これらの上位のコンテント所有者
とコンテント配布管理の関係とからなる。

【００５６】以上から判るように、アプリケーション１
００は、オブジェクトを登録することにより、何をオブ
ジェクトとするかを、即ち、操作対象データの定義を自
由に定めることができる。図６の定義は、その一例であ
る。従って、例えば、図６において、「集合」の下位の
「グループ」の下位に、更に、図８に示す「ユーザグル
ープ」「クライアントグループ」「コンテントグルー
プ」を付加することが、自由にできる。

【００５７】また、本発明におけるオブジェクトは、全
て少なくともコンテント、ユーザ又はノードを含む操作
対象物を含む操作対象物、オブジェクト間の関係、オブ
ジェクトのグループ、及びその他オブジェクトとして定
義された事項についての管理情報である。アプリケーシ
ョン１００はオブジェクトの操作をその管理情報の操作
を指示することにより行う。この指示は統一インタフェ
ース１５０によるので、アプリケーション１００はこれ
以外を意識することはない。オブジェクトの実態である
データはリポジトリ４００に存在する。アプリケーショ
ン１００から与えられた管理情報の操作は、統一インタ
フェース２５０により、当該操作を行うべきリポジトリ
管理部３０１に渡される。このリポジトリ管理部３０１
が、その実態であるデータを操作するために、管理情報
の操作をデータの操作に変換して、当該操作を実行す
る。

【００５８】図７はリポジトリテーブル説明図であり、
オブジェクトサービス処理部２０３の備えるリポジトリ
テーブル２１０の構成を示す。リポジトリテーブル２１
０は、オブジェクトとそれに対応するリポジトリ４００
とを管理する。具体的には、リポジトリテーブル２１０
は、図７に示すように、オブジェクト（名）毎に、対応
する（当該オブジェクトの実態であるデータを格納す
る）リポジトリ４００の種別と、その対応する（リポジ
トリ）管理部（名）とを格納する。リポジトリ管理部３
０１はオブジェクトのインスタンスである。

【００５９】オブジェクトサービス処理部２０３は、ア
プリケーション１００からオブジェクトの操作を与えら
れると、当該オブジェクトを用いてリポジトリテーブル
２１０を参照し、当該オブジェクトのリポジトリ４００
の種別及びそのリポジトリ管理部３０１とを知る。これ
に基づいて、オブジェクトサービス処理部２０３は、複
数のリポジトリ管理部３０１の中から当該リポジトリ管
理部３０１を自動的に選択して、オブジェクトの操作を
依頼する。

【００６０】図８はマップテーブル説明図であり、各々
のリポジトリ管理部３０１の備えるマップテーブル３０
６の構成を示す。マップテーブル３０６は、当該リポジ
トリ管理部３０１の管理する種々の形式のデータと、オ
ブジェクトサービス処理部２０３から与えられるオブジ
ェクトとの間の対応関係（マッピング）を管理する。具
体的には、マップテーブル３０６は、図８に示すよう
に、データ格納部３０７と、オブジェクト格納部３０９
と、これらの間に設けられるマップ方法格納部３０８と
からなる。データ格納部３０７は当該リポジトリ管理部
３０１の管理する種々の形式のデータを格納する。即
ち、データ（名）毎に、その全ての属性を格納する。オ
ブジェクト格納部３０９はオブジェクトサービス処理部
２０３から与えられるオブジェクトを格納する。即ち、
オブジェクト（名）毎に、その全ての属性を格納する。
マップ方法格納部３０８は、当該属性のデータ及びオブ
ジェクトが、各々、どのような形態で格納されているか
（表現形式）を示す情報を格納する。

【００６１】図８に示すマップテーブルにおいて、デー
タ名「person」の属性「description 」が定義されてい
るのに対して、オブジェクトの側に対応する定義及びマ
ップ方法が存在しない。属性「description 」は、例え
ば、当該「person」である利用者についての備考的な記
事であり、アプリケーション１００が他に公開したくな
い（アクセスを許さない）場合にこのようにされる。他
のアプリケーション６００は、オブジェクト側のマップ
方法が存在しないので、変換できず、アクセスできな
い。また、オブジェクト名「content 」の属性「Date c
reate 」が定義されているのに対して、データの側に対
応する定義及びマップ方法が存在しない。属性「Date c
reate 」は、例えば、当該オブジェクトを作成した日付
であり、特にデータとしては保存の必要がない場合にこ
のようにされる。他のアプリケーション６００は、デー
タ側のマップ方法が存在しないので、特にこれを定義す
る必要はない。

【００６２】当該リポジトリ管理部３０１は、オブジェ
クトサービス処理部２０３からオブジェクトとその操作
を与えられると、当該オブジェクトのオブジェクト型を
用いてリポジトリテーブルを参照し、当該オブジェクト
の属性毎にマップ方法を知る。これに基づいて、当該リ
ポジトリ管理部３０１は、当該オブジェクトを操作す
る。即ち、オブジェクトサービス処理部２０３は、アプ
リケーション１００からの要求に応じて、オブジェクト
型の「登録（add ）」、及び各オブジェクトの「更新
（up to date）」「取得（get ）」「追加（insert）」
「削除（delete）」「検索（search）」「一覧（lis
t）」の処理を行う。

【００６３】「登録」は、あるリポジトリ４００に作成
したデータを、オブジェクト型としてオブジェクトアク
セス管理手段３５０又はオブジェクトサービス処理部２
０３に登録する操作である。これにより、オブジェクト
としての操作が可能となる。この登録のために、オブジ
ェクトアクセス管理手段３５０等は、統一インタフェー
ス１５０の一部として、登録用のインタフェース（例え
ば、登録用の画面）を用意する。アプリケーション１０
０はこのインタフェースに従って所定の内容を入力する
のみで、オブジェクトを容易に登録することができる。
例えば、アプリケーション１００が、使用するオブジェ
クト型と当該データの存在するアドレス（又はリポジト
リ４００）を入力すると、オブジェクトアクセス管理手
段３５０等が、リポジトリ４００の種別、リポジトリ管
理部３０１、データ名、データの属性、オブジェクトの
属性を求めて、自動的にリポジトリテーブル２１０及び
マップテーブル３０６を作成する（追加する）。

【００６４】「更新」は登録したオブジェクトの内容を
変更する操作である。例えば、追加や書き換え等であ
る。「取得」は、更新や転送等のために、登録したオブ
ジェクトの内容を読み出す操作である。「削除」は一旦
登録したオブジェクトを当該登録から削除する操作であ
る。「検索」は、登録したオブジェクトからオブジェク
ト名、属性、オブジェクトの内容等を指定して該当する
オブジェクト等を読み出す操作である。「一覧」は、登
録したオブジェクトからグループ名を指定して当該グル
ープのオブジェクトを全て取得する操作である。これら
の操作のためにも、オブジェクトアクセス管理手段３５
０等は、統一インタフェース１５０の一部として、所定
のインタフェースを用意する。アプリケーション１００
はこのインタフェースに従って所定の内容を入力するの
みで、オブジェクトを容易に操作することができる。

【００６５】次に、図５及び図９を参照して、図２のオ
ブジェクト処理装置の動作について具体的に説明する。

【００６６】例えば、アプリケーション１００が、オブ
ジェクト「User」を、オブジェクト「Group 」のメンバ
に追加しようとする場合について説明する。図５におい
て、アプリケーション１００は、自己が操作しようとす
るオブジェクトがどのような形式でどのリポジトリ４０
０に管理されているかを意識する必要はない。アプリケ
ーション１００はオブジェクトの操作を指定するのみで
ある。図７に示すように、オブジェクト「User」は実際
にはディレクトリ４００Ｃで管理されており、オブジェ
クト「Group 」は実際にはＲＤＢ４００Ａで管理されて
いる。図８に示すように、オブジェクト「User」として
マップされているのはデータ「person」である。

【００６７】図９において、最初に、アプリケーション
１００が、オブジェクトサービス処理部２０３に対し
て、統一インタフェース１５０により、オブジェクト
「User」の「取得」を依頼する。

【００６８】オブジェクトサービス処理部２０３は、リ
ポジトリテーブル２１０を参照して、オブジェクト「Us
er」に対応するリポジトリ管理部３０１Ｃを選択し、統
一インタフェース２５０により、オブジェクト「User」
の「取得」を依頼する。

【００６９】リポジトリ管理部３０１Ｃは、マップテー
ブル３０６Ｃを参照して、オブジェクト「User」として
マップされているデータ「person」を選択し、その内容
をディレクトリ４００Ｃから「取得」する。そして、リ
ポジトリ管理部３０１Ｃは、マップテーブル３０６Ｃを
参照して、取得したデータ「person」の内容をオブジェ
クト「User」の内容に変換した上で、統一インタフェー
ス２５０により、先の依頼に対する応答としてオブジェ
クトサービス処理部２０３に返す。なお、この変換で
は、「cn」の文字列はそのまま「String name」の文字
列とし、「employee Number 」の文字列は「int id」の
数値に変換する。

【００７０】オブジェクトサービス処理部２０３は、リ
ポジトリ管理部３０１Ｃから受け取ったオブジェクト
「User」の内容を、統一インタフェース１５０により、
先の依頼に対する応答としてアプリケーション１００に
返す。

【００７１】次に、アプリケーション１００が、オブジ
ェクトサービス処理部２０３に対して、オブジェクト
「Group 」の「取得」を依頼する。

【００７２】オブジェクトサービス処理部２０３は、リ
ポジトリテーブル２１０を参照して、オブジェクト「Gr
oup 」に対応するリポジトリ管理部３０１Ａを選択し、
これにオブジェクト「Group 」の「取得」を依頼する。

【００７３】リポジトリ管理部３０１Ａは、マップテー
ブル３０６Ａを参照して、オブジェクト「Group 」とし
てマップされているデータ「Group of Name 」を選択
し、その内容をＲＤＢ４００Ａから「取得」する。そし
て、リポジトリ管理部３０１Ａは、マップテーブル３０
６Ａを参照して、取得したデータ「Group of Name 」の
内容をオブジェクト「Group 」の内容に変換した上で、
先の依頼に対する応答としてオブジェクトサービス処理
部２０３に返す。

【００７４】オブジェクトサービス処理部２０３は、リ
ポジトリ管理部３０１Ａから受け取ったオブジェクト
「Group 」の内容を、先の依頼に対する応答としてアプ
リケーション１００に返す。

【００７５】次に、アプリケーション１００が、取得し
たオブジェクト「User」の内容を、取得したオブジェク
ト「Group 」の内容に追加した上で、オブジェクトサー
ビス処理部２０３に対して、オブジェクト「Group 」の
「更新」を依頼する。

【００７６】オブジェクトサービス処理部２０３は、リ
ポジトリテーブル２１０を参照して、オブジェクト「Gr
oup 」に対応するリポジトリ管理部３０１Ａを選択し、
これにオブジェクト「Group 」の「更新」を依頼する。

【００７７】リポジトリ管理部３０１Ａは、マップテー
ブル３０６Ａを参照して、オブジェクト「Group 」とし
てマップされているデータ「Group of Name 」を選択
し、オブジェクト「Group 」の内容をデータ「Group of
Name 」の内容に変換した上で、当該新しい「Group of
Name 」でＲＤＢ４００Ａ内の（古い）「Group of Nam
e 」を上書きする。

【００７８】以上は、アプリケーション１００がオブジ
ェクトサービス処理部３０２に対して行うオブジェクト
の操作の例である。この他に、アプリケーション１００
は、データの転送等もオブジェクトの操作として行う。
これらの操作のためにも、オブジェクトアクセス管理手
段３５０等は、統一インタフェース１５０の一部とし
て、所定のインタフェースを用意する。アプリケーショ
ン１００はこのインタフェースに従って所定の内容を入
力するのみで、オブジェクトを容易に転送する等の操作
することができる。

【００７９】アプリケーション１００は、転送サービス
処理部２０４に対して、統一インタフェース１５０によ
り、オブジェクトの転送を依頼する。この時、アプリケ
ーション１００は、転送先としてある（ノード又はクラ
イアントである）オブジェクトを指定し、転送対象とし
てある（コンテントである）オブジェクトを指定するの
みで良い。転送のプロトコルを意識する必要はない。転
送サービス処理部２０４は、オブジェクトサービス処理
部２０３に依頼して転送先及び転送対象のオブジェクト
を取得し、これに基づいて転送対象を転送先へ転送す
る。

【００８０】アプリケーション１００は、イベントサー
ビス処理部２０５に対して、統一インタフェース１５０
により、オブジェクトについてのイベントの通知を依頼
する。この時、アプリケーション１００は、通知の対象
としてあるオブジェクトを指定するのみで良い。イベン
トサービス処理部２０５は、オブジェクトサービス処理
部２０３に依頼して通知対象のオブジェクトを取得し、
これに基づいてイベントが発生したらこれを通知する。

【００８１】アプリケーション１００は、監視サービス
処理部２０６に対して、統一インタフェース１５０によ
り、オブジェクトについての監視を依頼する。この時、
アプリケーション１００は、監視の対象としてあるオブ
ジェクトを指定するのみで良い。監視サービス処理部２
０６は、オブジェクトサービス処理部２０３に依頼して
監視対象のオブジェクトを取得し、これに基づいて監視
を行う。

【００８２】アプリケーション１００は、コマンドサー
ビス処理部２０７に対して、統一インタフェース１５０
により、オブジェクトについての用意されたコマンドへ
のプラグインを依頼する。この時、アプリケーション１
００は、プラグインの対象としてあるオブジェクトを指
定するのみで良い。コマンドサービス処理部２０７は、
オブジェクトサービス処理部２０３に依頼してプラグイ
ンの対象のオブジェクトを取得し、これに基づいてプラ
グインを行う。

【００８３】図１０はオブジェクト処理装置説明図であ
り、主として、本発明のオブジェクト処理装置にのける
複数転送制御部２２０、プロトコル制御部２６０、通信
処理部３０５を示す。

【００８４】アプリケーション１００は、通信プロトコ
ルにかかわりなく、送信対象をオブジェクトとして送信
を指示する。この時、アプリケーション１００は、転送
サービス処理部２０４の統一転送インタフェース１６０
をのみ意識する。従って、通信プロトコルについての意
識はなく、送信対象のオブジェクト（コンテント）及び
送信先のオブジェクト（ノード（クライアント）又はユ
ーザ）を指示するのみである。なお、統一転送インタフ
ェース１６０は、オブジェクトアクセス管理手段３５０
又はフレームワークレイア２００の用意する統一インタ
フェース１５０の一部であると考えても良い。

【００８５】アプリケーション１００からのオブジェク
トの送信の指示は、当該アプリケーション１００が他の
アプリケーション６００へ何らかのオブジェクトを送信
する場合に行われる。又は、当該オブジェクトの送信の
指示は、他のアプリケーション６００との通信における
当該他のアプリケーション６００からの受信要求に基づ
いて行われる。

【００８６】アプリケーション１００が送信するオブジ
ェクトは、アプリケーション１００が新たに作成しオブ
ジェクトサービス処理部２０３に登録する前のものか、
又は、オブジェクトサービス処理部２０３に登録しすで
にオブジェクトとして管理されているものである。いず
れの場合も、アプリケーション１００は、その相違を意
識することはない。

【００８７】即ち、送信するオブジェクトが登録された
オブジェクトである場合でも、アプリケーション１００
は、複数転送制御部２２０に当該オブジェクトを指定し
て送信を依頼するのみである。アプリケーション１００
からのオブジェクトの送信の指示を受けた複数転送制御
部２２０は、当該オブジェクトである少なくともコンテ
ント、ユーザ又はノードを含む操作対象物を含む操作対
象物についての取得をオブジェクトサービス処理部２０
３に指示する。これに応じて、オブジェクトサービス処
理部２０３は、複数転送制御部２２０からのオブジェク
トの取得の指示を上位統一インタフェース１５０に従っ
て受け付け、受け付けたオブジェクトの取得についての
指示を当該取得を行うべきリポジトリ管理部３０１に下
位統一インタフェース２５０に従って渡す。リポジトリ
管理部３０１は、オブジェクトサービス処理部２０３か
ら渡されたオブジェクトの取得についての指示を当該デ
ータの取得についての指示に変換し、これに基づいて対
応するリポジトリ４００に格納された少なくともコンテ
ント、ユーザ又はノードを含む操作対象物を含む操作対
象物についてのデータを取得して、これをオブジェクト
に逆変換してオブジェクトサービス処理部２０３に渡
す。オブジェクトサービス処理部２０３は、逆変換され
たオブジェクトを複数転送制御部２２０に渡す。

【００８８】複数転送制御部２２０は、アプリケーショ
ン１００からのオブジェクトの送信の指示を統一転送イ
ンタフェース１６０に従って受け付け、これをプロトコ
ル制御部２６０に渡す。複数転送制御部２２０は、送信
が正常に終了したことを示す信号を送信先から受け取
り、アプリケーション１００に正常終了を知らせる。こ
の信号が中断再開制御部２２１により監視される。

【００８９】プロトコル制御部２６０は、複数転送制御
部２２０から渡されたオブジェクトの送信の指示を、当
該送信を行うべき通信処理部３０５に渡す。

【００９０】複数の通信処理部３０５の各々は、予め定
められた異なる通信プロトコルに従って、プロトコル制
御部２６０から渡されたオブジェクトの送信を行う。複
数の通信処理部３０５の各々は、図１０等に示すよう
に、ＨＴＴＰ、ＨＴＴＰＳ、ＦＴＰ、ＰＯＰ３、ＩＭＡ
Ｐ４等の異なる通信プロトコルによる通信を行う。

【００９１】中断再開制御部２２１は、複数転送制御部
２２０を監視し、当該オブジェクトの内の送信済の部分
についての送信済情報を、送信済情報ファイル２２２に
保持する。先に送信を中断したオブジェクトの送信の指
示が再度アプリケーション１００からあった場合、中断
再開制御部２２１が、送信済情報に基づいて、当該オブ
ジェクトの内の送信済でない部分から複数転送制御部２
２０に送信を行わせる。当該オブジェクトのすべてにつ
いて送信が正常に終了した場合、送信済情報は記録され
ないか、又は、正常終了が記録される。

【００９２】オブジェクトの送信の中断の原因は、回線
７００（図１１参照）の状態の不良、送信元のアプリケ
ーション１００からの中断の要求、及び、送信先の他の
アプリケーション６００（図１１参照）からの中断の要
求等である。従って、アプリケーション１００は、転送
を行っている任意の時点で当該転送を中断することがで
きる。即ち、アプリケーション１００が先に指示したオ
ブジェクトの送信の中断を指示すると、複数転送制御部
２２０が当該中断の指示に従って当該送信を中断する。
又は、受信先の他のアプリケーション６００が先に指示
したオブジェクトの受信の中断を指示すると、受信側の
複数転送制御部２２０が当該中断の指示に従って当該受
信を中断する。これにより、送信側の複数転送制御部２
２０において送信エラーが発生し、中断再開制御部２２
１による送信の中断及び再開の処理の対象とされる。

【００９３】アプリケーション１００は、複数のオブジ
ェクトについての送信を指示するのみで、使用するプロ
トコルを意識することなく、異なるプロトコルの複数の
オブジェクト（ファイルやメッセージなど）を送受信す
ることができる。この場合、複数転送制御部２２０が、
当該複数のオブジェクトを、各々の通信プロトコルに応
じたアーカイブとし、プロトコル制御部２６０に渡す。
プロトコル制御部２６０は、アーカイブ毎にこれを当該
送信を行うべき通信処理部３０５に渡す。例えば、オブ
ジェクトＡ、ＢをプロトコルＣ、Ｄで送信する場合、プ
ロトコルＣ、Ｄの２個のアーカイブが作成され、各々の
アーカイブがオブジェクトＡ、Ｂを含む。通信処理部３
０５は、渡されたアーカイブを予め定められた大きさの
複数のパケットに分割して送信する。この時、中断再開
制御部２２１は、送信済情報として、当該アーカイブの
名前と送信済のパケットに付加された番号とを、送信済
情報ファイル２２２に保持する。

【００９４】中断したオブジェクトの転送を再開する場
合、アプリケーション１００は通常のオブジェクトの送
信と全く同様の処理を行う。従って、アプリケーション
１００は送信エラーを受け取ったオブジェクトを指定し
て受信要求を行うだけでよく、送信の中断の位置等を意
識する必要がない。送信側の転送中断・再開制御部が自
動的に転送済みのオブジェクトをスキップして送信を再
開するため、無駄なトラフィックの低減を実現してい
る。

【００９５】図１１は、オブジェクト送受信処理説明図
である。図１１に示すように、本発明のオブジェクト処
理装置は、オブジェクトの送信側（図中左側）及び受信
側（図中右側）において、同様の構成を備える。従っ
て、少なくともコンテント、ユーザ又はノードを含む操
作対象物を含む操作対象物は、双方において統一インタ
フェース１５０等に従うようにオブジェクトとして管理
され、アプリケーション１００がこれを意識することは
ない。なお、以下の説明において、オブジェクトの送信
側及び受信側に、各々、符号Ａ及びＢを付して区別す
る。

【００９６】即ち、受信側において、アプリケーション
１００Ｂは、通信プロトコルにかかわりなく、受信対象
をオブジェクトとして受信を指示する。複数転送制御部
２２０Ｂは、アプリケーション１００Ｂからのオブジェ
クトの受信の指示を統一転送インタフェース１６０Ｂに
従って受け付け、これをプロトコル制御部２６０Ｂに渡
す。プロトコル制御部２６０Ｂは、複数転送制御部２２
０Ｂから渡されたオブジェクトの受信の指示を、当該受
信要求及び受信を行うべき通信処理部３０５Ｂに渡す。
通信処理部３０５Ｂの各々は、予め定められた異なる通
信プロトコルに従って、プロトコル制御部２６０Ｂから
渡されたオブジェクトの受信要求及び受信を行う。

【００９７】更に、中断再開制御部２２１Ｂが、複数転
送制御部２２０Ｂを監視し、当該オブジェクトの内の受
信済の部分及びこれについての受信済情報を、受信済情
報ファイル２２３に保持する。当該オブジェクトの内の
受信済の部分が保持される点が送信側と異なる。先に受
信を中断したオブジェクトの受信の指示が再度アプリケ
ーション１００Ｂからあった場合、中断再開制御部２２
１Ｂが、受信済情報に基づいて、保存していた当該オブ
ジェクトの内の受信済の部分へ、再度の受信により受信
した当該オブジェクトの内の受信済でない部分を付加す
る。当該オブジェクトのすべてについて受信が正常に終
了した場合、受信済情報は記録されないか、又は、正常
終了が記録される。

【００９８】アプリケーション１００Ｂは複数のオブジ
ェクトについての受信を指示することができる。この場
合、複数転送制御部２２０Ｂの受信した当該複数のオブ
ジェクトは通信プロトコルに応じたアーカイブとされて
おり、かつ、当該アーカイブは予め定められた大きさに
分割したの複数のパケットからなる。中断再開制御部２
２１Ｂは、送信済情報として、当該アーカイブの名前と
送信済のパケットに付加された番号とを、受信済情報フ
ァイル２２３に保持する。これにより、当該オブジェク
トの内の受信済の部分へ、再度の受信により受信した当
該オブジェクトの内の受信済でない部分を付加すること
ができる。

【００９９】図１２乃至図１４は送信処理フローであ
る。特に、図１２は全体の送信処理フローであり、図１
３はプロトコルに応じたアーカイブ処理（送信側）フロ
ーであり、図１４は中断・再開制御処理（送信側）フロ
ーである。

【０１００】図１２において、複数転送制御部２２０
が、インタフェース１６０を介して、アプリケーション
１００Ａから、送信データ（オブジェクト）と送信先を
受け取る（ステップＳ１）。

【０１０１】複数転送制御部２２０Ａが、当該オブジェ
クトが複数オブジェクトか（オブジェクトが内部に更に
オブジェクトを含むか）否かを調べる（ステップＳ
２）。

【０１０２】複数オブジェクトの場合、複数転送制御部
２２０Ａが、プロトコルに応じたアーカイブ処理を行い
（ステップＳ３）、ステップＳ４に進む。アーカイブ処
理については、図１３を参照して後述する。

【０１０３】複数転送制御部２２０Ａが、プロトコル制
御部２６０Ａを介して、当該プロトコルで送信を行う通
信処理部３０５Ａにオブジェクトの送信を依頼し、通信
処理部３０５Ａが当該オブジェクトの送信を行う（ステ
ップＳ４）。このステップＳ４乃至ステップＳ８につい
ては、図１４を参照して後述する。

【０１０４】複数転送制御部２２０Ａが、送信先から正
常終了信号が通信処理部３０５Ａから帰ってきたか、即
ち、正常終了か否かを調べる（ステップＳ５）。正常終
了である場合、処理を終了する。

【０１０５】正常終了でない場合、これを監視していた
中断再開制御部２２１Ａが、アプリケーション１００Ａ
による中断要求があるか否かを調べる（ステップＳ
６）。

【０１０６】中断要求がない場合、中断再開制御部２２
１Ａが、アプリケーション１００にエラーを通知して
（ステップＳ７）、ステップＳ８へ進む。

【０１０７】中断要求がある場合、中断再開制御部２２
１Ａが、オブジェクトの再送に備えて、送信が完了して
いるオブジェクトの部分を送信済情報ファイル２２２Ａ
に記録する（ステップＳ８）。

【０１０８】図１３において、複数転送制御部２２０Ａ
が、転送プロトコルの判定処理を行う（ステップＳ
９）。

【０１０９】判定書の結果に基づいて、複数転送制御部
２２０Ａが、転送プロトコルがＨＴＴＰ若しくはＨＴＴ
ＰＳのいずれかか又はそれ以外かを調べる（ステップＳ
１０）。

【０１１０】転送プロトコルがＨＴＴＰ若しくはＨＴＴ
ＰＳの場合、複数転送制御部２２０Ａが、Ｍｉｍｅ Ｍ
ｕｌｔｉｐａｒｔを作成する。即ち、各パートが１オブ
ジェクトに対応するようにし、全体として一つになった
メッセージを作成する（ステップＳ１１）。

【０１１１】ステップＳ１０において、転送プロトコル
がＨＴＴＰ若しくはＨＴＴＰＳ以外の場合、複数転送制
御部２２０Ａが、各パートの情報（ファイル名、サイ
ズ、ｃｈｃｃｋｓｕｍなど）を元に、ヘッダを生成する
（ステップＳ１２）。

【０１１２】複数転送制御部２２０Ａが、オブジェクト
（群）にヘッダも含めて、全体を一つのファイルにアー
カイブする（ステップＳ１３）。

【０１１３】図１４において、前述のように、アプリケ
ーション１００Ａから複数転送制御部２２０Ａが転送オ
ブジェクト、転送先を受け取る（ステップＳ１４）。

【０１１４】複数転送制御部２２０Ａが、当該送信に使
用するプロトコルを調べ、当該プロトコルに応じたプロ
トコル制御部２６０Ａを通して、通信手段５００に回線
開設要求を行う（ステップＳ１５）。

【０１１５】複数転送制御部２２０Ａ又は中断再開制御
部２２１Ａが、送信済情報ファイル２２２に送信途中の
オブジェクトがあるか否かを調べる（ステップＳ１
６）。

【０１１６】送信途中のオブジェクトがある場合、中断
再開制御部２２１Ａが、送信済情報ファイル２２２か
ら、転送データのアーカイブ名を用いて送信済みのパケ
ット番号を取り出し、当該パケット番号に「１」をプラ
スした値を送信パケット番号の初期値として設定し（ス
テップＳ１７）、ステップＳ１８へ進む。

【０１１７】送信途中のデータがない場合、複数転送制
御部２２０Ａが、通信プロトコルがＨＴＴＰ若しくはＨ
ＴＴＰＳのいずれかか又はそれ以外かを調べる（ステッ
プＳ１８）。

【０１１８】通信プロトコルがＨＴＴＰ若しくはＨＴＴ
ＰＳである場合、複数転送制御部２２０Ａが、Ｃｈｕｎ
ｋ（ＨＴＴＰプロトコルで定められた分割転送処理する
ためのパケット）の作成処理を行う（ステップＳ１
９）。

【０１１９】通信プロトコルがＨＴＴＰ若しくはＨＴＴ
ＰＳ以外である場合、複数転送制御部２２０Ａが、転送
オブジェクトを一定サイズのパケットに分割し、パケッ
トにパケット番号を付加し、パケット番号とパケットの
ペアを生成する（ステップＳ２０）。

【０１２０】複数転送制御部２２０Ａ又は中断再開制御
部２２１Ａが、アプリケーション１００からの中断要求
があるか否かを調べる（ステップＳ２１）。中断要求が
ある場合、ステップＳ２７に進む。

【０１２１】中断要求がない場合、複数転送制御部２２
０Ａが、プロトコル制御部２６０及び当該通信処理部３
０５を介して、１つのパケットを送信する（ステップＳ
２２）。

【０１２２】複数転送制御部２２０Ａが、ステップＳ２
２において送信したパケットが正常に送信できたか否か
を調べる（ステップＳ２３）。

【０１２３】正常に送信できた場合、複数転送制御部２
２０Ａが、Ｃｈｕｎｋまたは送信パケット番号をインク
リメント（＋１）する（ステップＳ２４）。

【０１２４】複数転送制御部２２０Ａが、当該転送デー
タを最後まで送信したか否かを調べる（ステップＳ２
５）。最後まで送信した場合には処理を終了し、最後ま
で送信していない場合にはステップＳ２１以下を繰り返
す。

【０１２５】ステップＳ２３において正常に送信できな
かった場合、複数転送制御部２２０Ａが、アプリケーシ
ョン１００にエラーを通知する（ステップＳ２６）。

【０１２６】中断再開制御部２２１Ａが、送信済みのデ
ータの情報（アーカイブ名とパケット番号）を制御ファ
イルに保存して、当該送信処理を終了する（ステップＳ
２７）。

【０１２７】図１５乃至図１７は受信処理フローであ
る。図１５は全体の受信処理フローであり、図１６はプ
ロトコルに応じたアーカイブ処理（受信側）フローであ
り、図１７は中断・再開制御部（受信側）の処理フロー
である。

【０１２８】図１５において、アプリケーション１００
から、統一転送インタフェース１６０を介して、複数転
送制御部２２０Ｂが、受信したいデータ（オブジェク
ト）の名前と受信元を受け取る（ステップＳ２８）。

【０１２９】中断再開制御部２２１Ｂが、受信済情報フ
ァイル２２３を参照して、当該オブジェクトの受信が先
に途中まで受信したオブジェクトの受信の再開か否かを
調べる（ステップＳ２９）。

【０１３０】オブジェクトの受信の再開である場合、中
断再開制御部２２１Ｂが、受信済情報ファイル２２３を
参照して、途中まで受信してあるオブジェクトを読み出
して、受信再開の準備を行う（ステップＳ３０）。

【０１３１】複数転送制御部２２０Ｂ又は中断再開制御
部２２１Ｂが、プロトコル制御部２６０Ｂ及び通信処理
部３０５を介して、オブジェクトの送信元（アプリケー
ション１００Ａ）へ送信要求を送る（ステップＳ３
１）。

【０１３２】複数転送制御部２２０Ｂ又は中断再開制御
部２２１Ｂが、データの受信を行う（ステップＳ３
２）。このステップＳ３２乃至ステップＳ３６の処理に
ついては、図１７を参照して後述する。

【０１３３】複数転送制御部２２０Ｂが、正常終了か否
かを調べる（ステップＳ３３）。

【０１３４】正常終了でない場合、中断再開制御部２２
１Ｂが、アプリケーション１００による中断要求か否か
を調べる（ステップＳ３４）。

【０１３５】中断要求でない場合、中断再開制御部２２
１Ｂが、アプリケーション１００にエラーを通知する
（ステップＳ３５）。

【０１３６】中断要求である場合、中断再開制御部２２
１Ｂが、データ受信の再開に備えて、受信済ファイル２
２３に受信済み情報を保存する（ステップＳ３６）。

【０１３７】図１６において、複数転送制御部２２０Ｂ
が、上記オブジェクトの受信の正常終了の後、転送プロ
トコルの判定処理を行う（ステップＳ３７）。

【０１３８】判定処理の結果に基づいて、複数転送制御
部２２０Ｂが、転送プロトコルがＨＴＴＰ若しくはＨＴ
ＴＰＳのいずれかか又はそれ以外かを調べる（ステップ
Ｓ３８）。

【０１３９】ＨＴＴＰ若しくはＨＴＴＰＳである場合、
複数転送制御部２２０Ｂが、Ｍｕｌｔｉｐａｒｔか否か
を調べる（ステップＳ３９）。

【０１４０】Ｍｕｌｔｉｐａｒｔである場合、複数転送
制御部２２０Ｂが、各パートにオブジェクトへアクセス
する手段を準備する。即ち、Ｍｕｌｔｉｐａｒｔのオブ
ジェクトへの分解を行う（ステップＳ４０）。

【０１４１】Ｍｕｌｔｉｐａｒｔでない場合、複数転送
制御部２２０Ｂが、オブジェクトをそのまま上位（アプ
リケーション１００Ｂ）へ渡す（ステップＳ４１）。

【０１４２】ステップＳ３８においてＨＴＴＰ若しくは
ＨＴＴＰＳ以外である場合、複数転送制御部２２０Ｂ
が、アーカイブの先頭にヘッダ情報があるか、即ち、Ｍ
ｕｌｔｉｐａｒｔかどうかの判定を行う（ステップＳ４
２）。Ｍｕｌｔｉｐａｒｔでない場合、ステップＳ４１
へ進む。

【０１４３】Ｍｕｌｔｉｐａｒｔである場合、複数転送
制御部２２０Ｂが、ヘッダ情報を元にアーカイブを各々
のオブジェクトに分解し、各オブジェクトへのアクセス
手段を準備する（ステップＳ４３）。

【０１４４】図１７において、前述のように、通信処理
部３０５Ｂ及びプロトコル制御部２６０Ｂから、複数転
送制御部２２０Ｂへオブジェクトの到着が通知される
（ステップＳ４４）。

【０１４５】中断再開制御部２２１Ｂが、受信済ファイ
ル２２３に受信済オブジェクトがあるか否かを調べる
（ステップＳ４５）。受信済オブジェクトがない場合、
ステップＳ４７へ進む。

【０１４６】受信済オブジェクトがある場合、中断再開
制御部２２１Ｂが、保存しておいたデータを取り出し、
オブジェクトの受信の再開ができるように準備する（ス
テップＳ４６）。

【０１４７】中断再開制御部２２１Ｂが、アプリケーシ
ョン１００Ｂからの受信の中断要求があるか否かを調べ
る（ステップＳ４７）。中断要求がある場合、ステップ
Ｓ５６へ進む。

【０１４８】中断要求がない場合、複数転送制御部２２
０Ｂが、１つのパケットを受信する（ステップＳ４
８）。

【０１４９】複数転送制御部２２０Ｂが、正常に受信で
きたか否かを調べる（ステップＳ４９）。正常に受信で
きなかった場合、ステップＳ５５へ進む。

【０１５０】正常に受信できた場合、複数転送制御部２
２０Ｂが、プロトコル種別の判定処理を行う（ステップ
Ｓ５０）。

【０１５１】複数転送制御部２２０Ｂが、当該通信プロ
トコルがＨＴＴＰ若しくはＨＴＴＰＳのいずれかか又は
それ以外かを調べる（ステップＳ５１）。

【０１５２】ＨＴＴＰ若しくはＨＴＴＰＳである場合、
複数転送制御部２２０Ｂが、受信オブジェクトのＣｈｕ
ｎｋ番号をチェックし、これを受信済情報に追加する
（ステップＳ５２）。

【０１５３】ＨＴＴＰ若しくはＨＴＴＰＳ以外である場
合、複数転送制御部２２０Ｂが、受信オブジェクトのパ
ケット番号をチェックし、受信済情報に追加する（ステ
ップＳ５３）。

【０１５４】複数転送制御部２２０Ｂが、当該オブジェ
クトを最後まで受信したか否かを、Ｃｈｕｎｋまたはパ
ケット番号により判定する（ステップＳ５４）。最後ま
で受信した場合、受信処理を終了する。最後まで受信し
ていない場合、ステップＳ４７以下を繰り返す。

【０１５５】ステップＳ４９において正常に受信できな
かった場合、中断再開制御部２２１Ｂが、アプリケーシ
ョン１００にエラーを通知する（ステップＳ５５）。

【０１５６】中断再開制御部２２１Ｂが、受信済オブジ
ェクトと、Ｃｈｕｎｋまたはパケット番号を受信済ファ
イル２２３に記録する（ステップＳ５６）。

【０１５７】例えば、図１３において、アプリケーショ
ン１００Ａが、転送対象のオブジェクト及び転送先のオ
ブジェクト（アプリケーション１００Ｂ）を指定して、
複数転送制御部２２０Ａにオブジェクトの送信を指示す
る。この送信の指示は、アプリケーション１００Ａがア
プリケーション１００Ｂからの送信要求を受け取った場
合、又は、アプリケーション１００Ｂがオブジェクトの
送信を常に受信する場合に、行われる。

【０１５８】複数転送制御部２２０Ａは、転送対象のオ
ブジェクトの名前を指定して、その取得をオブジェクト
サービス処理部２０３Ａに依頼する。オブジェクトサー
ビス処理部２０３Ａは、当該リポジトリ管理部３０１Ａ
を介して、リポジトリ４００Ａから当該オブジェクトを
取得して、複数転送制御部２２０Ａに渡す。

【０１５９】複数転送制御部２２０Ａは、当該オブジェ
クトのアーカイブを作成して、プロトコル制御部２６０
Ａ及び通信処理部３０５Ａ等を介して、アプリケーショ
ン１００Ｂへ送信する。

【０１６０】アプリケーション１００Ａが送信中断を中
断再開制御部２２１Ａに指示した場合、又は、アプリケ
ーション１００Ｂが受信中断を中断再開制御部２２１Ｂ
に指示した場合、その時点までの送信済情報が中断再開
制御部２２１Ａにより送信済ファイル２２２に保存さ
れ、その時点までの受信オブジェクト及び受信済情報が
中断再開制御部２２１Ｂにより受信済ファイル２２３に
保存される。

【０１６１】アプリケーション１００Ａ又はアプリケー
ション１００Ｂが再度当該オブジェクトの送信を指示し
た場合、前述と同様にして、当該オブジェクトのアーカ
イブが作成される。この後、中断再開制御部２２１Ａ
は、送信済ファイル２２２を参照して、送信済でないパ
ケットからの送信を行う。中断再開制御部２２１Ｂは、
受信済ファイル２２３から読み出した受信済のパケット
に、新たに受信したパケットを付加して、アプリケーシ
ョン１００Ｂに渡す。

【０１６２】

【発明の効果】以上説明したように、本発明によれば、
オブジェクト処理装置において、アプリケーションが送
信をオブジェクトの送信として行うように指示すると共
にこの送信の指示統一転送インタフェースに従って受け
付けることにより、アプリケーションはオブジェクトを
通信プロトコルを意識することなくオブジェクトとして
の送信を指示することができるので、様々なプロトコル
を用いて同時に複数のオブジェクトの転送を行うことが
でき、アプリケーション開発者も煩雑な処理コードを記
述する必要がない。

【０１６３】また、本発明によれば、オブジェクト処理
装置において、転送を監視し当該オブジェクトの内の送
信済の部分についての送信済情報を保持することによ
り、送信を中断したオブジェクトの送信の指示が再度あ
った場合、当該オブジェクトの内の送信済でない部分か
ら送信を行うことができるので、アプリケーションが信
頼性の低い回線を使用して大量データ送受信しなければ
ならない場合においても、無駄なトラフィックを低減し
た転送を行うことができる。

【図面の簡単な説明】

【図１】本発明の原理構成図である。

【図２】オブジェクト処理装置構成図である。

【図３】オブジェクト処理装置構成図である。

【図４】オブジェクト処理装置構成図である。

【図５】オブジェクト処理装置説明図である。

【図６】オブジェクト説明図である。

【図７】リポジトリテーブル説明図である。

【図８】マップテーブル説明図である。

【図９】オブジェクト処理説明図である。

【図１０】オブジェクト処理装置説明図である。

【図１１】オブジェクト送受信処理説明図である。

【図１２】送信処理フローである。

【図１３】送信処理フローである。

【図１４】送信処理フローである。

【図１５】受信処理フローである。

【図１６】受信処理フローである。

【図１７】受信処理フローである。

【符号の説明】

１００ アプリケーション １６０ 統一転送インタフェース ２０３ オブジェクトサービス処理部 ２０４ 転送サービス処理部 ２２０ 複数転送制御部 ２２１ 中断再開制御部 ２２２ 送信済情報ファイル ２５０ 下位統一インタフェース ２６０ プロトコル制御部 ３０５ 通信処理部 ５００ 通信手段 ６００ 他のアプリケーション

Claims (15)

【特許請求の範囲】
1. 【請求項１】 通信プロトコルにかかわりなく、送信対
   象をオブジェクトとして送信を指示するアプリケーショ
   ンからのオブジェクトの送信の指示を統一転送インタフ
   ェースに従って受け付け、これをプロトコル制御部に渡
   す複数転送制御部と、 前記複数転送制御部から渡されたオブジェクトの送信の
   指示を、当該送信を行うべき通信処理部に渡すプロトコ
   ル制御部と、 各々が、予め定められた異なる通信プロトコルに従っ
   て、前記プロトコル制御部から渡されたオブジェクトの
   送信を行う複数の通信処理部とからなることを特徴とす
   るオブジェクト処理装置。
2. 【請求項２】 前記アプリケーションが複数のオブジェ
   クトについての送信を指示し、 前記複数転送制御部が、当該複数のオブジェクトを、各
   々の通信プロトコルに応じたアーカイブとし、前記プロ
   トコル制御部に渡し、 前記プロトコル制御部が、アーカイブ毎にこれを当該送
   信を行うべき前記通信処理部に渡すことを特徴とする請
   求項１に記載のオブジェクト処理装置。
3. 【請求項３】 当該オブジェクト処理装置が、更に、 少なくともコンテント、ユーザ又はノードを含む操作対
   象物を含む操作対象物についてのデータを各々が異なる
   形態で格納する複数のデータ格納手段と、 前記アプリケーションと前記複数のデータ格納手段との
   間に設けられ、前記複数のデータ格納手段に格納された
   少なくともコンテント、ユーザ又はノードを含む操作対
   象物を含む操作対象物についてのデータをオブジェクト
   として統一的に管理するオブジェクトアクセス管理手段
   とからなり、 前記オブジェクトアクセス管理手段が、更に、オブジェ
   クトサービス処理部と、前記複数のデータ格納手段の各
   々に対応して設けられた複数のデータ格納手段管理手段
   とからなり、 前記アプリケーションからのオブジェクトの送信の指示
   を受けた複数転送制御部が、当該オブジェクトである少
   なくともコンテント、ユーザ又はノードを含む操作対象
   物を含む操作対象物についての取得を前記オブジェクト
   サービス処理部に指示し、 前記オブジェクトサービス処理部が、前記複数転送制御
   部からのオブジェクトの取得の指示を上位統一インタフ
   ェースに従って受け付け、受け付けたオブジェクトの取
   得についての指示を当該取得を行うべき前記データ格納
   手段管理手段に下位統一インタフェースに従って渡し、 前記データ格納手段管理手段が、前記オブジェクトサー
   ビス処理部から渡されたオブジェクトの取得についての
   指示を当該データの取得についての指示に変換し、これ
   に基づいて対応する前記データ格納手段に格納された少
   なくともコンテント、ユーザ又はノードを含む操作対象
   物を含む操作対象物についてのデータを取得して、これ
   をオブジェクトに逆変換して前記オブジェクトサービス
   処理部に渡し、 前記オブジェクトサービス処理部が、逆変換されたオブ
   ジェクトを前記複数転送制御部に渡すことを特徴とする
   請求項１に記載のオブジェクト処理装置。
4. 【請求項４】 前記アプリケーションからのオブジェク
   トの送信の指示は、他のアプリケーションとの通信にお
   ける当該他のアプリケーションからの受信要求に基づく
   ことを特徴とする請求項３に記載のオブジェクト処理装
   置。
5. 【請求項５】 通信プロトコルにかかわりなく送信対象
   をオブジェクトとして送信を指示するアプリケーション
   からのオブジェクトの送信の指示を、統一転送インタフ
   ェースに従って受け付け、これをプロトコル制御処理に
   渡す複数転送制御処理と、 渡されたオブジェクトの送信の指示を、当該送信を行う
   べき通信処理に渡すプロトコル制御処理と、 予め定められた異なる通信プロトコルに従って、渡され
   たオブジェクトの送信を行う通信処理とを、 コンピュータである当該オブジェクト処理装置に実行さ
   せるプログラムを記憶したことを特徴とするプログラム
   記憶媒体。
6. 【請求項６】 通信プロトコルにかかわりなく、送信対
   象をオブジェクトとして送信を指示するアプリケーショ
   ンからのオブジェクトの送信の指示を統一転送インタフ
   ェースに従って受け付け、これをプロトコル制御部に渡
   す複数転送制御部と、 前記複数転送制御部から渡されたオブジェクトの送信の
   指示を、当該送信を行うべき通信処理部に渡すプロトコ
   ル制御部と、 各々が、予め定められた異なる通信プロトコルに従っ
   て、前記プロトコル制御部から渡されたオブジェクトの
   送信を行う通信処理部と、 前記複数転送制御部を監視し、当該オブジェクトの内の
   送信済の部分についての送信済情報を保持する中断再開
   制御部とからなり、 先に送信を中断したオブジェクトの送信の指示が再度前
   記アプリケーションからあった場合、前記中断再開制御
   部が、前記送信済情報に基づいて、当該オブジェクトの
   内の送信済でない部分から前記複数転送制御部に送信を
   行わせることを特徴とするオブジェクト処理装置。
7. 【請求項７】 前記アプリケーションが先に指示したオ
   ブジェクトの送信の中断を指示し、 前記複数転送制御部が当該中断の指示に従って当該送信
   を中断することを特徴とする請求項６に記載のオブジェ
   クト処理装置。
8. 【請求項８】 前記アプリケーションが複数のオブジェ
   クトについての送信を指示し、 前記複数転送制御部が、当該複数のオブジェクトを、各
   々の通信プロトコルに応じたアーカイブとし、前記プロ
   トコル制御部に渡し、 前記プロトコル制御部が、アーカイブ毎にこれを当該送
   信を行うべき前記通信処理部に渡し、 前記通信処理部が、渡されたアーカイブを予め定められ
   た大きさの複数のパケットに分割して送信し、 前記中断再開制御部が、前記送信済情報として、当該ア
   ーカイブの名前と送信済のパケットに付加された番号と
   を保持することを特徴とする請求項６に記載のオブジェ
   クト処理装置。
9. 【請求項９】 通信プロトコルにかかわりなく送信対象
   をオブジェクトとして送信を指示するアプリケーション
   からのオブジェクトの送信の指示を統一転送インタフェ
   ースに従って受け付け、これをプロトコル制御処理に渡
   す複数転送制御処理と、 渡されたオブジェクトの送信の指示を、当該送信を行う
   べき通信処理に渡すプロトコル制御処理と、 予め定められた異なる通信プロトコルに従って、渡され
   たオブジェクトの送信を行う通信処理と、 前記複数転送制御処理を監視し、当該オブジェクトの内
   の送信済の部分についての送信済情報を保持する中断再
   開制御処理と、 先に送信を中断したオブジェクトの送信の指示が再度前
   記アプリケーションからあった場合、前記送信済情報に
   基づいて、当該オブジェクトの内の送信済でない部分か
   ら送信を行う処理とを、 コンピュータである当該オブジェクト処理装置に実行さ
   せるプログラムを記憶したことを特徴とするプログラム
   記憶媒体。
10. 【請求項１０】 通信プロトコルにかかわりなく、受信
    対象をオブジェクトとして受信を指示するアプリケーシ
    ョンからのオブジェクトの受信の指示を統一転送インタ
    フェースに従って受け付け、これをプロトコル制御部に
    渡す複数転送制御部と、 前記複数転送制御部から渡されたオブジェクトの受信の
    指示を、当該受信要求及び受信を行うべき通信処理部に
    渡すプロトコル制御部と、 各々が、予め定められた異なる通信プロトコルに従っ
    て、前記プロトコル制御部から渡されたオブジェクトの
    受信要求及び受信を行う通信処理部とからなることを特
    徴とするオブジェクト処理装置。
11. 【請求項１１】 通信プロトコルにかかわりなく受信対
    象をオブジェクトとして受信を指示するアプリケーショ
    ンからのオブジェクトの受信の指示を統一転送インタフ
    ェースに従って受け付け、これをプロトコル制御処理に
    渡す複数転送制御処理と、 渡されたオブジェクトの受信の指示を、当該受信要求及
    び受信を行うべき通信処理に渡すプロトコル制御処理
    と、 予め定められた異なる通信プロトコルに従って、渡され
    たオブジェクトの受信要求及び受信を行う通信処理と
    を、 コンピュータである当該オブジェクト処理装置に実行さ
    せるプログラムを記憶したことを特徴とするプログラム
    記憶媒体。
12. 【請求項１２】 通信プロトコルにかかわりなく、受信
    対象をオブジェクトとして受信を指示するアプリケーシ
    ョンからのオブジェクトの受信の指示を統一転送インタ
    フェースに従って受け付け、これをプロトコル制御部に
    渡す複数転送制御部と、 前記複数転送制御部から渡されたオブジェクトの受信の
    指示を、当該受信要求及び受信を行うべき通信処理部に
    渡すプロトコル制御部と、 各々が、予め定められた異なる通信プロトコルに従っ
    て、前記プロトコル制御部から渡されたオブジェクトの
    受信要求及び送信を行う通信処理部と、 前記複数転送制御部を監視し、当該オブジェクトの内の
    受信済の部分及びこれについての受信済情報を保持する
    中断再開制御部とからなり、 先に受信を中断したオブジェクトの受信の指示が再度前
    記アプリケーションからあった場合、前記中断再開制御
    部が、前記受信済情報に基づいて、保存していた当該オ
    ブジェクトの内の受信済の部分へ、再度の受信により受
    信した当該オブジェクトの内の受信済でない部分を付加
    することを特徴とするオブジェクト処理装置。
13. 【請求項１３】 前記アプリケーションが先に指示した
    オブジェクトの受信の中断を指示し、 前記複数転送制御部が当該中断の指示に従って当該受信
    を中断することを特徴とする請求項１２に記載のオブジ
    ェクト処理装置。
14. 【請求項１４】 前記アプリケーションが複数のオブジ
    ェクトについての受信を指示し、 前記複数転送制御部の受信した当該複数のオブジェクト
    は通信プロトコルに応じたアーカイブとされており、か
    つ、当該アーカイブは予め定められた大きさに分割した
    の複数のパケットからなり、 前記中断再開制御部が、前記送信済情報として、当該ア
    ーカイブの名前と送信済のパケットに付加された番号と
    を保持することを特徴とする請求項１２に記載のオブジ
    ェクト処理装置。
15. 【請求項１５】 通信プロトコルにかかわりなく受信対
    象をオブジェクトとして受信を指示するアプリケーショ
    ンからのオブジェクトの受信の指示を統一転送インタフ
    ェースに従って受け付け、これをプロトコル制御処理に
    渡す複数転送制御処理と、 渡されたオブジェクトの受信の指示を、当該受信要求及
    び受信を行うべき通信処理に渡すプロトコル制御処理
    と、 予め定められた異なる通信プロトコルに従って、渡され
    たオブジェクトの受信要求及び送信を行う通信処理と、 前記複数転送制御処理を監視し、当該オブジェクトの内
    の受信済の部分及びこれについての受信済情報を保持す
    る中断再開制御処理と、 先に受信を中断したオブジェクトの受信の指示が再度前
    記アプリケーションからあった場合、前記受信済情報に
    基づいて、保存していた当該オブジェクトの内の受信済
    の部分へ、再度の受信により受信した当該オブジェクト
    の内の受信済でない部分を付加する処理とを、 コンピュータである当該オブジェクト処理装置に実行さ
    せるプログラムを記憶したことを特徴とするプログラム
    記憶媒体。