(57)【要約】【課題】ソフトウエアコンポーネントが、プロセスやCPUをまたがるような分散オブジェクトとして存在する場合の、コンポーネント間の通信のオーバーヘッドを軽減する。【解決手段】PU間通信を伴う通信相手からの応答データが固定データか可変データかを判定し、固定データであった場合に要求パラメータと対にして記憶し、以降の当該固定データに対するリクエスト時にはCPU間通信を行わずに、記憶しておいた応答データを返却する。【選択図】図１
2007172255.tif 000002
【特許請求の範囲】
【請求項１】
ソフトウエアコンポーネントが、プロセス及びCPUをまたがる分散オブジェクトとして存在する場合におけるコンポーネント間の通信装置であって、
データの要求先が同一CPUのコンポーネントか、別CPUのコンポーネントかを判断する通信相手判断手段と、
前記通信相手判断手段により通信相手が前記別CPUであると判断された場合に、通信相手への要求パラメータを一時記憶する記憶手段と、
前記通信相手からの応答データが固定データか可変データかを判定する固定データ判定手段と、
前記固定データ判定手段により前記固定データと判定されたデータを、前記要求パラメータと関連付けて記憶する固定データ記憶手段と、
前記通信相手判断手段により前記要求先が前記別CPUと判定された場合、実際に要求を出す前に、前記固定データ記憶手段に受信済みデータが存在した場合には要求を行わないで、前記固定データ記憶手段に記憶されているデータを返却する手段と
を具備することを特徴とするコンポーネント間通信装置。
【請求項２】
データを要求されたサーバー側コンポーネントで、管理するデータが前記固定データか前記可変データであるとあらかじめ記憶しておき、要求側への応答データに前記固定データか前記可変データかの情報を付加して応答することを特徴とする請求項１に記載のコンポーネント間通信装置。
【請求項３】
特定フェーズの期間で固定データとなるデータを判定する手段と、
前記特定フェーズの期間だけ当該データを前記固定データとして保持することを特徴とする請求項１又は２に記載のコンポーネント間通信装置。
【請求項４】
前記特定フェーズが、システム起動時であることを特徴とする請求項３に記載のコンポーネント間通信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンポーネント間通信方法であって、特にソフトウエアコンポーネントが、プロセスやCPUをまたがるような分散オブジェクトとして存在する場合の、コンポーネント間通信装置に関する。
【背景技術】
【０００２】
多様な製品や機器構成に対応するためには、ソフトウエアでハードやOSの違いを隠蔽できるようにし、さらに、ソフトウエア部品をコンポーネント化して、機器に応じたコンポーネントを選択的に利用できるようにする。このように、ソフトウエア資産の再利用性を高め、さらに、複雑な機器構成に対応するために、コンポーネントが複数のCPUに分散して配置され、それぞれが互いに通信して協調動作するような仕組みの必要性が非常に高くなってきている。
【０００３】
これらのことを解決するために、Java（登録商標）のRMIやCORBAといった分散オブジェクト技術が用いられている。
RMIにより、分散アプリケーションのフレームワークにおいて、オブジェクトを別のマシンに自由に移動することができる。
【０００４】
また、そのためにコードを変更する必要はほとんどなくなった。Java（登録商標）のRMIがJava（登録商標）言語に依存しているのに対して、CORBAはサポート言語を限定しておらず、分散オブジェクトがネットワークを介して通信する方法を定めたものである。
【０００５】
CORBAにおけるORB(Object Request Broker)は、以下の機能を有する。即ち、リモートマシン上のオブジェクトの検索と、それにアクセスするためのスタブオブジェクトの作成、ダウンロードしたスタブを用いたリモートメソッドの静的呼び出し、パラメータの変換、セキュリティの保障などを行う。ORBは、オブジェクトが通信するための通信媒体として働く構成要素である。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
Java（登録商標）のRMIやCORBAの仕組みを利用すれば、ソフトウエアコンポーネントが分散された場合でも、特に意識することなくコンポーネントの設計が可能となった。しかしながら、RMIやCORBAが汎用的なネットワーク、及びアプリケーション間通信のためのフレームワークであるため、組み込み機器内でそのフレームワークを使用しようとすると以下のような問題を持っている。
【０００７】
例えば、第1のCPU側にデータソースとなるコンポーネントが存在し、第2のCPU側にそのデータソースの同一な情報を取得したいコンポーネントが複数存在した場合に問題が生じる。このとき、現在の仕組みでは第2のCPUの要求側コンポーネントの数分だけ、第1CPUと第2CPU間とで通信が発生してしまう。
【０００８】
通常CPU間の通信は同一CPU内における通信に比べ通信速度が著しく低下するので、システムのパフォーマンスの低下を引き起こす。
特に、システムの起動時は、各コンポーネントが初期化に必要なデータを短い期間内に集中的に発生する。この時CPU間通信が多く発生すれば、それだけシステムの起動時間が遅くなってしまう。
【０００９】
ここで、コンポーネント同士のネゴシエーションでこれらの通信オーバーヘッドを減らそうとすると、コンポーネント自体が専用部品となり、コンポーネントのポータビリティを失ってしまう。
【００１０】
このような、組み込み機器のような通信されるオブジェクトの内容をある程度想像できる場合の通信オーバーヘッドの低減を、コンポーネントの独立性を保ったまま実現することが望まれる。
【００１１】
本発明は、上記の課題に鑑みてなされたものであり、通信上に搭載されるソフトウエアコンポーネントは、自身がどこに配置されるかを意識する必要はなく、すなわちコンポーネントのポータビリティを維持したうえで、ソフトウエアコンポーネントと通信手段の間で、CPU間で繰り返し行われる固定データ通信をそれぞれ１度だけにすることで、コンポーネント間通信のオーバーヘッドを軽減させシステムのパフォーマンスを向上させることを可能とするコンポーネント間通信装置を提供することを目的とする。
【課題を解決するための手段】
【００１２】
本発明のコンポーネント間通信装置は、ソフトウエアコンポーネントが、プロセス及びCPUをまたがる分散オブジェクトとして存在する場合におけるコンポーネント間の通信装置であって、データの要求先が同一CPUのコンポーネントか、別CPUのコンポーネントかを判断する通信相手判断手段と、前記通信相手判断手段により通信相手が前記別CPUであると判断された場合に、通信相手への要求パラメータを一時記憶する記憶手段と、前記通信相手からの応答データが固定データか可変データかを判定する固定データ判定手段と、前記固定データ判定手段により前記固定データと判定されたデータを、前記要求パラメータと関連付けて記憶する固定データ記憶手段と、前記通信相手判断手段により前記要求先が前記別CPUと判定された場合、実際に要求を出す前に、前記固定データ記憶手段に受信済みデータが存在した場合には要求を行わないで、前記固定データ記憶手段に記憶されているデータを返却する手段とを具備する。
【発明の効果】
【００１３】
本発明によれば、通信上に搭載されるソフトウエアコンポーネントは、自身がどこに配置されるかを意識する必要はなく、すなわちコンポーネントのポータビリティを維持したうえで、ソフトウエアコンポーネントと通信手段の間で、CPU間で繰り返し行われる固定データ通信をそれぞれ１度だけにすることで、コンポーネント間通信のオーバーヘッドを軽減させシステムのパフォーマンスを向上させることが可能となる。
【発明を実施するための最良の形態】
【００１４】
図２は従来の方法を示すダイアグラム図である。図２において、システムはCPU1とCPU2の２つのCPUから構成され、CPU１側にComponent1とComponent2の２つのソフトウエアコンポーネントが、CPU2側にComponent3とComponent4の２つのソフトウエアコンポーネントが存在する。
【００１５】
Component1はデータベースを持ち、Component2,3,4はComponent1のデータベースを参照するために、それぞれComponent1と通信する必要がある。
Component1とComponent2は同じCPU上で動作しているので、外部通信をしなくても高速な内部通信でデータの送受信が可能である。
【００１６】
Component3、Component4からComponent1へのリクエストはCPU2からCPU1へのCPU間転送を必要とする。CPU間転送は一般的にCPU内部転送よりもはるかに時間がかかる。
例えば、図２の例ではComponent3とComponent4がそれぞれComponent1に対してCPU間転送を使用して通信を行っている。
【００１７】
ところで、Component3とComponent4がまったく同じデータをComponent1にリクエストしたとし、そのデータが不変な固定データだったら、スピードの遅いCPU間転送を繰り返すのは処理速度のネックになる。
【００１８】
そこで本発明では、図３に示すようなSTUBを通信手段とソフトウエアコンポーネント間にいれ、固定データの場合の通信処理の効率化を実現する。図３のSTUBを詳細に示したのが図１である。
【００１９】
図１において、クライアント側通信ポートはソフトウエアコンポーネントのクライアントサイドに接続されている(1-2)。
図３ではクライアントサイドはComponent2, Component3, Componet4となる。サーバー側通信ポートはデータソース側のソフトウエアコンポーネントに接続される。
【００２０】
図３ではComponent1になる。それぞれのコンポーネントはいずれか片方にしかなれないのではなく、サーバーとクライアントの両方の機能を持つことも可能である。
サーバー側の通信ポートに接続される側では、STUBは通信手段とのデータ通信をスルーして何もしない(1-3)。
【００２１】
一方で、クライアント側に接続される側では、STUBはデータの要求先が同一CPUのコンポーネントか、別CPUのコンポーネントかを判断する通信相手判断手段(1-4)を有する。また、通信相手判断手段により通信相手が別CPUだった場合に、通信相手への要求パラメータを一時記憶する記憶手段(1-6)を有する。また、通信相手からの応答データが固定データか可変データかを判定する固定データ判定手段(1-7)を有する。また、固定データ判定手段で固定データと判定されたデータを、要求パラメータと関連付けて記憶する固定データ記憶手段(1-8)を有する。また、通信相手判断手段で、要求先が別CPUと判定された場合、実際に要求を出す前に、固定データ記憶手段に受信済みデータが存在した場合は要求（通信）を行わないで、固定データ記憶手段に記憶されているデータを返却する固定データ管理手段(1-5)を有する。
【００２２】
図６は図１のダイアグラム図のクライアント側の処理を示すフローチャートである。
S6-1でクライアントからのリクエストを受け付ける。S6-2で通信相手が自身と同じCPUか別のCPUかの判断をし、同じCPUと判断した場合はS6-11へ進み、別のCPUと判断した場合はS6-4へ進む(S6-3)。
【００２３】
S6-11では同一CPUなので通常の通信処理を行い、応答があったらS6-10で要求元に応答データを返却する。
S6-4では要求パラメータと、固定データ記憶手段(1-8)に記憶されているデータの要求パラメータとを比較し、同じリクエストに対する応答データが格納されていたらS6-12へ進む。
【００２４】
S6-12では記憶済みのデータから応答データを取り出し、S6-10でデータを返却して処理を終える。S6-4で応答データが記憶されていなかった場合はS6-5へ進み、要求パラメータを一時的に記憶し、S6-6へすすむ。
【００２５】
S6-6では通信手段1-9に依頼して通信を行い、応答を待ち、応答が帰ってきたらS6-7へ進む。
S6-7では応答で帰ってきたデータが固定データか可変データかを判断し、固定データであればS6-8へ、可変データであればS6-9へ進む。
S6-8では応答データをS6-5で一時的に記憶しておいた要求パラメータとセットにして、固定データ記憶手段1-8に記憶する。
【００２６】
次にS6-9でS6-5で一時記憶した要求パラメータを破棄し、S6-10でリクエスト元にデータを返却して処理を終える。
【００２７】
図４は通信手段1-9を使用した、サーバーとクライアントが通信経路を確立するためのフローチャートである。
まず4-1でサーバー側がユニークな"Port Name"で通信手段1-9へサーバーポートを登録する。次に4-2でクライアントがサーバーの"Port Name"を使用して、サーバーとなるコンポーネントの識別子(Component ID)を取得する。
【００２８】
4-1の前に4-2が実行された場合は、通信手段1-9は4-2のリクエストを保留し、サーバーポートが登録された後に4-2の処理を再開させるものとする。
"Component ID"が得られると、以降はクライアントはその"Component ID"を使用してサーバーへの接続（要求）が可能となる(4-3)。
【００２９】
通信手段1-9は、図５に示すような内部データを保持して、"Component ID"と"Port Name"とを対にして管理するものである。
"Component ID"は、そのコンポーネントがどのCPUに属するかを示すフィールド(5-1)と、システムでユニークになるような値(5-2)とからなる。"Component ID"は、さらにサーバーから登録され、クライアントからサーバーポートを探索するために使用される"Port Name"を関連付けて記憶している。
【００３０】
図１０はクライアントからサーバーへの要求パラメータの一例である。
まずリクエストのあて先を示す"Component ID"、次に内容を示す"Request ID"が格納され、続いて応答先（自分）を示す"Reply Port"が格納される。
続いて付加的な引数があればそのサイズ(size)と引数データ実体(arg)を格納する。
【００３１】
図１１はサーバーからクライアントに対する応答データの一例である。
まずどのリクエストに対する応答なのかを示すために、クライアントから要求されたものと同じ"Component ID"と"Request ID"を格納する。続いてその要求に対する応答ステータス(status)が格納され、さらに付加的な情報があれば、そのサイズ(size)、情報のタイプを示すフラグ(flags)、そして付加情報の実体(arg)が格納される。
情報のタイプを示すフラグに固定データか、可変データかを示すフラグも格納される。
【００３２】
図７はインクジェットプリンタにおけるコンポーネント間通信されるデータの一例である。
"出荷情報"には工場出荷時に設定されるパラメータが保持される。
この情報は工場から出荷されて以降は不変である。"ユーザー情報"はユーザーがカスタマイズ可能な情報で、ユーザーの操作によって変化しうる情報である。
【００３３】
"インク情報"はインク残量などを保持し、印刷やクリーニング、インク交換などによって内容が変化する。"電源情報"はAC駆動か、DC駆動か、DC駆動の場合の電池残量などを保持し、常に内容が変わり得る。
"エラー情報"は機器の状態に応じて警告やエラーの情報が逐一更新される。
【００３４】
次にインクジェットプリンタのコンポーネント構成を図８に示す。
CPU１側はシングルファンクションプリンタの機能を担当し、CPU２側はPCレスでのカメラダイレクトプリントや、機器のメンテナンスを行うための機能コンポーネントを搭載し、CPU１側のシングルファンクションプリンタの機能を拡張するハードウエアである。
【００３５】
図８のCPU１側には機器の各種ステータスを管理するステータスマネージャ(STM)というコンポーネントがあり、図７で示したような各種情報を集中管理している。
またプリンターとしての機能(PCPrint)を搭載し、PC等のホストからの印字データを印刷するコンポーネントも搭載している。
【００３６】
図８のCPU2側には、デジタルカメラを接続して、カメラ内の画像を印刷するコンポーネント(DirectPrint)と、PCがなくても単体で機器のメンテナンスや設定を行うためのコンポーネント(Mainte)を搭載している。
【００３７】
図９はSTMで管理する各情報を、その情報を参照するコンポーネントの名前を付して記してある。
()で囲まれているのはその機能が具体的に実行された場合（例えば"PCPrint"ならPCから印刷データが送信されてきて印刷を開始する）に必要な情報で、それ以外の()で囲まれていない情報はコンポーネントの初期化時に必要となる情報である。
【００３８】
各コンポーネントから"STM"に対するリクエストは、情報のブロック単位に行われる。
例えば"出荷情報"の中の"言語"の情報だけほしい場合でも、"出荷情報"を取得して、その中の"言語"の情報を参照するものとする。
【００３９】
次に具体的な処理の流れを説明する。前提として、固定データ記憶手段1-8にはまだ、何もデータが記憶されていないものとする。
まず"PCPrint"から"STM"に対して"出荷情報"をリクエストした場合の処理を示す。
S6-1でリクエストが渡される。次にS6-2に進み、要求先が同一CPUか別のCPUかを、接続に使用される"Component ID"の"CPU ID"(5-1)から判断する。
【００４０】
"PCPrint"と"STM"とは同一CPUに属しているので、S6-11へ進み通信手段1-9に対してリクエストを転送する。
そして返ってきたデータをクライアントに返却して処理を終了する。
【００４１】
次に"DirectPrint"から"STM"に対して"出荷情報"をリクエストした場合の処理を示す。
S6-1でリクエストが渡される。
次にS6-2で、要求先が同一CPUか別のCPUかを判断する。
"Component ID"の"CPU ID"が自身の"CPU ID"と異なっているのでS6-4へ進む。
S6-4ではまだ、固定データ記憶手段1-8に"出荷情報"に関するデータがないので、S6-5へ進み要求パラメータを一時記憶する。
【００４２】
ここでは図10に示す要求パラメータ全体を記憶するものとする。
次にS6-6で通信手段1-8にリクエストを転送し、応答を待つ。
応答が来たら応答データに付加情報があるかどうかを確認し、付加情報があった場合はそこに格納されている情報タイプを示すフラグの中から、固定データか可変データかを示すフラグを参照して固定データかどうかを判断する(S6-7)。
【００４３】
固定データだった場合は、S6-5で記憶した要求パラメータと応答データ(図11)とを対にして固定データ記憶手段(1-8)に記憶する(S6-8)。
そしてS6-5で記憶しておいた要求パラメータを破棄して、クライアントコンポーネントにデータを返却して処理を終了する。
【００４４】
次に"DirectPrint"から"STM"に対する"出荷情報"の応答があった状態で、"Mainte"から"STM"に対して"出荷情報"のリクエストをした場合の処理を示す。
S6-3までは先に示した処理と同様なので省略する。S6-4では、すでに今回の要求パラメータと同じ要求パラメータと関連付けられた応答データが固定データ記憶手段(1-8)に記憶されているので、S6-12に進む。S6-12において、固定データ記憶手段から要求パラメータに関連付けられた応答データを取り出して、クライアントコンポーネントに返却して処理を終了する。
【００４５】
以上説明してきたように、本発明はモジュール間の通信において、同じデータに対するリクエストが繰り返し発生する場合に、より効果的である。
例えば機器の起動時は、多くのモジュールがコンフィギュレーションパラメータによって、それぞれの動作モードなどを初期化する必要がある。
【００４６】
先の図７、図９における"ユーザー情報"はユーザーの設定により、内容が変化する。
しかし、システム起動中などでユーザーによる操作ができない場合は一時的に固定データとして扱うことが可能である。
【００４７】
したがって、システム起動中に限り固定データとして扱うことができるデータをさらに固定データ記憶手段で記憶すれば、さらにモジュール間通信のオーバーヘッドを抑えることが可能となる。
【図面の簡単な説明】
【００４８】
【図１】本発明の一実施形態を示す図である。
【図２】従来の通信形態を示す図である。
【図３】本発明適用後の通信形態を示す図である。
【図４】通信経路確立のフローを示す図である。
【図５】通信ポートの管理方法を示す図である。
【図６】本発明の実施例を示すフローチャートである。
【図７】通信されるデータの例を示す図である。
【図８】プリンターにおけるソフトウエアコンポーネントの例を示す図である。
【図９】ソフトウエアコンポーネントがどのデータを使用するかの例を示す図である。
【図１０】要求パラメータの例を示す図である。
【図１１】応答データの例を示す図である。
【符号の説明】
【００４９】
1-4通信相手判断手段
1-5固定データ管理手段
1-6  記憶手段
1-7  固定データ判定手段
1-8  固定データ記憶手段
【図１】
2007172255.tif 000003
【図２】
2007172255.tif 000004
【図３】
2007172255.tif 000005
【図４】
2007172255.tif 000006
【図５】
2007172255.tif 000007
【図６】
2007172255.tif 000008
【図７】
2007172255.tif 000009
【図８】
2007172255.tif 000010
【図９】
2007172255.tif 000011
【図１０】
2007172255.tif 000012
【図１１】
2007172255.tif 000013