JP5610773B2 - メッセージ処理装置およびメッセージ処理方法 - Google Patents

Description

本発明は、ソフトウェアをコンポーネントという単位で扱い、複数のコンポーネント間でメッセージ交換を行って処理を進める分散システムのメッセージ処理方法に関する。

分散オブジェクト技術は、複数のプロセスやネットワーク上に分散されているソフトウェアコンポーネント（以下、コンポーネントと呼ぶ）間において、お互いに相手の物理的な配置を気にせずに電子情報のやりとりを利用可能とする技術である。本明細書ではこのような電子情報をメッセージと呼ぶ。分散オブジェクト技術では、同一コンピュータ上の異なるプロセス上で動作するコンポーネントや、ネットワークを介して異なるコンピュータ上で動作するコンポーネントに対して相互にメッセージ通信が行われる。このような分散オブジェクトシステムの代表的なものとして以下のようなシステムが存在する。
(1) RPC (Remote Procedure Call) （非特許文献１参照）
(2) CORBA (Common Object Request Broker Architecture（登録商標）)（非特許文献２参照）
(3) JavaRMI (Java Remote Method Invocation（Javaは登録商標）)（非特許文献３参照）
これら分散オブジェクト技術は、トランザクション処理システムやデータ収集システム、Webサービスといった比較的大規模なシステムでの実績が多い。しかし、近年では組込み領域においても、複数CPUやマルチプロセッサOSを搭載する製品が増え、RPCやCORBAと同等の機能を有する通信ミドルウェアを採用する機会が増えてきている。

通信ミドルウェアは、煩雑なスレッド／プロセス間通信やネットワーク処理の実装を隠蔽する。コンポーネント間でメッセージやデータやイベント（以下、まとめてメッセージと呼ぶ）のやり取りを行う際、通信ミドルウェアの決められたAPIを用いて行うことで、コンポーネントの移植性が向上する。

分散オブジェクト技術を実現するための代表的な実装形態の一つがサーバ/クライアントモデルである。サーバ/クライアントモデルでは、サービスを提供する側のサーバ・コンポーネント（以下、サーバと呼ぶ）に対して、クライアント・コンポーネント（以下、クライアントと呼ぶ）がサービス利用の依頼を行う。サーバは依頼に応じてサービスを実行したり、要求されたメッセージをクライアントに送信したりといったことを行う。サーバ/クライアントモデルで構成されるシステムにおいては、クライアントとサーバが1対１とは限らない。すなわち、１つのサーバに対して複数のクライアントが処理を依頼する構成をとることが多い。その為サーバ側はキューを備え、複数のクライアントからの処理依頼メッセージを一旦キューに登録し、前の処理が完了した後にキューから次のメッセージを取り出して処理するように構成される。ここで、サーバはサービス要求を行うクライアントが誰であるかを想定せず、クライアントからの要求に対して返信を行う構成にすることで、通信相手のことを考えずにサーバを実装することが可能となり、移植性の高いサーバ・コンポーネントを実現できる。このように、コンポーネントの移植性を向上させるためには、通信しあうコンポーネント間で、一方のコンポーネントが他方のコンポーネントを指定せずに通信を行うことが肝心である。

また、近年成長を続けているメッセージ通信技術としてPublish/Subscribeモデル（以下、Ｐｕｂ／Ｓｕｂモデルと呼ぶ）がある。Ｐｕｂ／Ｓｕｂモデルもサーバ/クライアントモデルと同様に、多対多通信を実現するためメッセージキューイングを行う。Ｐｕｂ／Ｓｕｂモデルでは、受信者（以下、Subscriberと呼ぶ）は受信したいメッセージ属性（以下、トピックと呼ぶ）に興味があるとあらかじめ宣言しておく（以下、購読予約と呼ぶ）。また、送信者（以下、Publisherと呼ぶ）はあるトピックに対してメッセージを発行する。このようにして発行されたメッセージは、通信ミドルウェアによって、購読予約をしている全てのSubscriberに対して配信される。この方式の特徴は、PublisherとSubscriberが互いに相手の情報を知る必要が無い点にある。

このように、Ｐｕｂ／Ｓｕｂモデルはトピックに関して通信さえできれば、Publisher、Subscriber両者はシステムのネットワーク構成も知る必要がない。また、相手の状態がどうであろうと個々のシステムは正常に稼動し続ける。まとめると、Ｐｕｂ／Ｓｕｂモデルは疎結合なシステムであり、サーバを指定してクライアントがメッセージを送信するようなサーバ/クライアントモデルのシステムに比べて、コンポーネントの移植性が高いという特徴がある。

ところで、組み込みシステムにおいて上述したような１対多もしくは多対多のメッセージ配信システムを実現する際、過去に配信されたメッセージを後になって受信したいというユースケースは少なくない。例えば、マルチＣＰＵ上で複数のコンポーネントが協調して動作するような複写機を、高速で起動させることを考える。一般に、複写機を構成するコンポーネントは他のコンポーネントとメッセージ通信を行い、自身の状態を正常に更新しながらシステムの起動を行う。しかしながら、ＣＰＵやメモリ等のリソース制限により全てのコンポーネントを同時に起動することはできないため、いくつかのコンポーネントはシーケンシャルに起動させることになる。また、システムを高速で起動させるためには、システムが最低限動作するために必要なコンポーネントを優先的に起動する必要がある。それらの際でも先に起動したコンポーネントが配信したメッセージを、遅れて起動したコンポーネントが受け取り、あたかも始めから起動していたかのように状態を正常に更新したいというユースケースがある。

別のユースケースとしては、Ｐｕｂ／Ｓｕｂモデルを実現するシステムにおいて、通信経路の障害などによって一時的にSubscriberの購読予約が受理されない場合でも、期待するメッセージを受信したいというものがある。しかしながら、サーバやPublisherといった送信コンポーネントに後からくるコンポーネントを意識してメッセージを保持させておく実装をするのは、前述したように移植性を低下させる要因となり望ましくない。

上記問題を解決する為に、メッセージを配信後すぐに削除してしまわないように、通信ミドルウェアが一定期間メッセージを保持する方式が考えられている(特許文献１参照)。また、Publisherの発行したメッセージのメッセージ発行時刻がSubscriberの購読予約時刻以降である場合に、当該メッセージをそのSubscriberに配信する方式が知られている(特許文献２参照)。

特許第０３７３２６７１号公報 特開２００８−１２４９７７号公報

「RPC: Remote ProcedureCallProtocol Specification Version 2」，Sun Microsystems 「Common Object Request Broker Architecture: Core Specification」，Object Management Group, Inc. 「Ｊａｖａ分散コンピューティング（Javaは登録商標）」、Jim Farley 著、小俣 裕一監訳、株式会社オライリー・ジャパン

特許文献１に開示された技術によれば、送信コンポーネントが発行したメッセージを一定期間保持しておくことで、遅れて起動した受信コンポーネントへメッセージを送信することが可能である。ここで、前述した起動時間短縮のユースケースを実現するために受信コンポーネントの起動を後回しにする場合を考える。このとき、受信コンポーネントの起動タイミングによってはメッセージの保持期間を過ぎてしまうことがあり、期待するメッセージを受信できない可能性がある。また、それに備えてメッセージの保持期間を長めに設定すると、送信コンポーネントのメッセージ発行間隔が短いとすぐにデータ保持領域を逼迫してしまう。通常受信コンポーネントが起動してメッセージ受信を開始するタイミングは起動モードや製品の使用状況に左右される。また、受信コンポーネントがシステムの使用状況に合わせて動的に生成されるケースも多くある。これらより、メッセージの保持期間を正確に予測することは困難であり、遅れて起動するコンポーネントが期待するメッセージを確実に受信するためには、メッセージ保持期間のみでメッセージの削除タイミングを判断するのは不十分である。

また、特許文献２に開示された技術によれば、Subscriberが購読予約時刻を付与して購読予約を行う。こうすることで、仮にネットワーク障害などで購読予約が一時的に受理されなくても、購読予約時刻以降にPublisherが発行したメッセージを受信することができる。しかしながら、機器組込みのソフトウェアにおいては、複写機の高速起動のユースケースに代表されるように、動作するコンポーネント数を限定しなければならない状況が多く存在する。そのため、Publisherが動作する前にあらかじめSubscriberを動作させ購読予約を行うことが困難になるケースが多い。

本発明は上記の課題に鑑みてなされたものであり、メモリを逼迫させずに、より確実に受信コンポーネントにメッセージを受信させることが可能なメッセージ処理装置及び方法を提供することを目的とする。

上記の目的を達成するための本発明の一態様によるメッセージ処理装置は以下の構成を備える。すなわち、
複数のソフトウェアコンポーネントと通信し、ソフトウェアコンポーネントから受け取ったメッセージを他のソフトウェアコンポーネントへ渡すメッセージ処理装置であって、
ソフトウェアコンポーネントからメッセージを受信し、受信したメッセージに送信数を設定して当該受信したメッセージを保持する保持手段と、
前記受信したメッセージと、前記送信数および保持期間を対応させて管理する管理手段と、
他のソフトウェアコンポーネントからの配信要求に応じて、前記保持手段に保持されている前記受信したメッセージを、前記他のソフトウェアコンポーネントへ送信する送信手段と、
前記受信したメッセージが、前記送信手段により前記管理手段により管理されている前記送信数だけ送信された後、前記保持期間にわたって新たな配信要求がない場合に、前記受信したメッセージを、前記保持手段から削除する削除手段とを備える。

本発明によれば、メモリを逼迫させずに、より確実に受信コンポーネントにメッセージを受信させることが可能となる。

実施形態に係るシステムのソフトウェア構成を示したブロック図。 実施形態に係るシステムのハードウェア構成を示したブロック図。 実施形態の通信ミドルウェアが管理するテーブルの一例を示す図。 実施形態によるメッセージ購読予約処理の流れの例を示す図。 実施形態によるメッセージ送信処理の流れの例を示す図。 実施形態によるメッセージ削除処理の流れの例を示す図。 実施形態によるメッセージ配信処理の流れの例を示す図。 実施形態によるメッセージ要求処理の流れの例を示す図。 実施形態によるメッセージ返信処理の流れの例を示す図。 実施形態によるデータの関連を示す図。 実施形態による、メッセージに着目した処理の流れの例を示す図。 実施形態によるメッセージに着目した処理の流れの例を示す図。

以下、添付の図面に従って本発明の実施形態を説明する。ただし、以下の実施形態は本発明の一例に過ぎず、本発明の範囲を限定するものではない。

＜第１実施形態＞
図２は実施形態による情報処理装置（コンピュータ・システム）の全体構成例を示すブロック図である。ＣＰＵ１は、以下に説明する３からから１１の装置をバス２を介してアクセスし、各種制御を行う。ＲＯＭ３は、バス２を介してＣＰＵ１からアクセス可能な読み出し専用メモリであり、複数のソフトウェアコンポーネント３ａを含む処理プログラム及びソフトウェアコンポーネント３ａにより使用されるパラメータ３ｂを格納する。ＲＡＭ４は読み書き可能なメモリであり、ソフトウェアコンポーネント３ａにより作成／変更がなされる、メッセージ格納領域４ａやテーブル管理領域４ｂ等を保持する。入力インターフェース５は、スイッチ、キー、ボタン、タッチパネル等の入力装置６を介してなされる入力を受け取る。出力インターフェース７は、ＣＲＴ，ＬＣＤ等の表示媒体８に対し、データの表示／出力を行う。また、外部記憶装置インターフェース９は、ＨＤＤ、不揮発性メモリ等の外部記憶装置１０に対するデータの入出力を行う。

なお、本実施形態では、ソフトウェアコンポーネント３ａやパラメータ３ｂがＲＯＭ３上に、また、処理対象となる各データの格納領域（４ａ、４ｂ）がＲＡＭ４上にあるものとして説明を行うが、これに限られるものではない。たとえば、これらのデータをすべて外部記憶装置１０に配置することも可能である。この場合、これらのデータは必要に応じて、外部記憶装置１０からＲＡＭ４にロードされ、ＣＰＵ１により使用される。また、ＣＰＵ１のキャッシュメモリ上に配置することも同様に可能である。また、メッセージ格納領域４ａは、ソフトウェアコンポーネントが送受信するメッセージを格納する場所であり、テーブル管理領域４ｂは、メッセージを管理するための情報を格納する場所である。また、ネットワークインターフェース１１は、ローカルエリアネットワーク（ＬＡＮ）、無線ＬＡＮ、シリアルバス等の他ノード（ＣＰＵ）との通信を行う装置である。他のノードとの接続形態のバリエーションとして、ハードウェアのバスやDual PortのＲＡＭを介してＣＰＵとＣＰＵが接続される形態が挙げられる。この場合は、バス間通信を行うドライバを経由し、ネットワークインターフェースと同様にデータの交換が可能である。本実施形態に関するシステムでは、これらの物理的な通信方式を隠蔽するミドルウェアを介して異なるＣＰＵ上のアプリケーション・プログラム同士がメッセージの交換（メッセージ処理）を行う事ができるように構成されている。

図１は、本システムにおけるソフトウェアの構成を詳細化した一例である。図１は、協調して動作する複数のソフトウェアコンポーネント３ａの構成要件と、それらの構成要件が格納領域４ａに格納される管理データとどのような関係にあるかを示している。図２で示したコンピュータ・システム上では、オペレーティング・システム（不図示）が動作しているものとする。また、オペレーティング・システム上では複数のソフトウェアコンポーネント３ａが動作しているとする。送信コンポーネント１０１はメッセージを送信するソフトウェアコンポーネントであり、本実施形態ではデバイスから周期的にもしくは任意のタイミングで情報を取得するリアルタイムデバイスコンポーネントを想定している。受信コンポーネント１０２、１０３は、メッセージを受信するソフトウェアコンポーネントであり、コンピュータ・システム上または他のコンピュータ・システム上で動作するものである。本実施形態では、リアルタイムデバイスから得た情報に応じて、各種デバイスを制御するデバイス制御コンポーネントＡ、Ｂを想定している。また、本実施形態においては、Ｐｕｂ／Ｓｕｂモデルの実現をサポートする通信ミドルウェア１０５を想定し、送信コンポーネント１０１をPublisher、受信コンポーネント１０２、１０３をSubscriberと考える。なお、本構成例ではシステムを構成するコンピュータの数を明記していないが、１つ以上のコンピュータから構成されるシステムにおいて、本実施形態を適用することが可能である。また、送信および受信コンポーネントの分類はある２つのソフトウェアコンポーネント間の関係のみを示している。つまり、あるソフトウェアコンポーネントは、送信コンポーネントにも、受信コンポーネントにも成り得る。

メッセージ書き込み部１０１１は、送信コンポーネント１０１が発行するメッセージを受信する。メッセージ書き込み部１０１１は、Ｐｕｂ／Ｓｕｂモデルにおいてはトピックごとに存在する。メッセージ格納部１０１２は、送信コンポーネントが発行するメッセージを保持する。メッセージ格納部１０１２に格納されている各メッセージはメッセージ管理部１０１３によって、送信先コンポーネント数を管理されている。また、メッセージ保持期間管理部１０１４は、トピックに応じてメッセージを保持しておく期間を管理している。メッセージ削除部１０１５はメッセージ管理部１０１３に管理されている送信先コンポーネント数が０になったメッセージを削除する。このとき、メッセージ削除部１０１５は、メッセージ保持期間管理部１０１４に管理されている保持期間だけ保持したあと、メッセージ格納部１０１２およびメッセージ管理部１０１３から該当するメッセージを削除する。送信先情報管理部１０１６は、トピックの購読予約をしている送信先コンポーネントの情報を管理する。要求応答部１０１７は、トピックの購読予約や、保持しているメッセージを配信する要求を受け付ける。要求応答部１０１７は、トピックの購読予約を受け付けた場合には、送信先情報管理部１０１６に購読予約を行った送信先コンポーネントの情報を格納する。メッセージ読出し部１０２１、１０３１は、メッセージを受信して受信コンポーネント１０２、１０３へそのメッセージを受け渡す。要求監視部１０２２、１０３２は、受信コンポーネント１０２，１０３からのトピックへの購読の予約要求や、過去のメッセージの配信要求を監視し、それらの要求が来た場合は、要求応答部１０１７に対して通知を行う。通信制御部１０４は、メッセージ書き込み部１０１１、メッセージ読み出し部１０２１、１０３１間でメッセージのやりとりを制御する。、通信制御部１０４は、１つ以上のコンピュータ間での通信を可能としている。

図１０は、第１実施形態で用いられるデータの関連を示す図である。１１０１はコンポーネント間で送受信されるメッセージであり、メッセージ格納部１０１２にて保持される。各メッセージ１１０１にはメッセージを識別するためのメッセージＩＤ１１０２、送信先コンポーネント数１１０３（メッセージに対して規定された送信数）のデータが、メッセージ管理部１０１３により付与される。また、メッセージ１１０１の送信先である送信先コンポーネント情報１１０４、およびメッセージ１１０１の保持期間１１０５とも関連づけられる。図中、「１」は対応関係において対応するデータ数が１であることを表わし、「＊」は対応するデータ数が不特定多数であることを表わしている。

図１１を用いて、通信ミドルウェア１０５がメッセージ１１０１を送信コンポーネント１０１から受け取って削除するまでの処理を説明する。送信コンポーネント１０１からメッセージ１１０１の送信指示を受け取ると、メッセージ書き込み部１０１１は、メッセージ１１０１にメッセージＩＤ１１０２、送信先コンポーネント数１１０３を対応させてメッセージ格納部１０１２に保持する（Ｓ１２０１）。続いて、メッセージ書き込み部１０１１は、送信先情報管理部１０１６により管理されているメッセージ１１０１に対応する送信先コンポーネント情報１１０４を参照し、未送信のコンポーネントが存在するか判断する（Ｓ１２０２）。未送信のコンポーネントが存在する場合、メッセージ書き込み部１０１１は、該当するコンポーネントにメッセージ１１０１を送信する（Ｓ１２０２でＹｅｓ、Ｓ１２０３）。そして、メッセージ管理部１０１３は、メッセージ１１０１の送信先コンポーネント数１１０３を１つデクリメントする（Ｓ１２０４）。メッセージ書き込み部１０１１は、Ｓ１２０３からＳ１２０４の処理を、送信先情報管理部１０１６で管理されている未送信のコンポーネントが存在しなくなるまで繰り返す。

未送信のコンポーネントが存在しなくなり（Ｓ１２０２でＮｏ）、さらにメッセージ１１０１の送信先コンポーネント数１１０３が０より大きい場合（Ｓ１２０５でＹｅｓ）、要求応答部１０１７は、メッセージ１１０１の配信指示を待つ（Ｓ１２０６）。要求応答部１０１７は、メッセージ配信指示を受け取ると（Ｓ１２０７でＹｅｓ）、指示されたコンポーネントにメッセージ１１０１を送信する（Ｓ１２０８）。そして、メッセージ管理部１０１３は送信先コンポーネント数１１０３を１つデクリメントする（Ｓ１２０９）。Ｓ１２０６からＳ１２０９の処理は、送信先コンポーネント数１１０３が０以下になるまで繰り返される。送信先コンポーネント数１１０３が０以下になったら（Ｓ１２０５でＮｏ）、メッセージ削除部１０１５は、メッセージ削除処理のために、タイマをスタートする（Ｓ１２１０）。メッセージ保持期間管理部１０１４により管理されているメッセージ保持期間１１０５が過ぎる前に（Ｓ１２１２でＮｏ）メッセージ配信指示を受け取ったら（Ｓ１２１１でＹｅｓ）、一旦メッセージ削除処理を終えＳ１２０８のメッセージ送信処理に移る。その後、再度Ｓ１２１０へ処理が進んだ場合は、メッセージ削除部１０１５は、メッセージ削除処理のためのタイマをリセットしてからスタートさせる。メッセージ配信指示を受け取らないままメッセージ保持期間１１０５が過ぎたら（Ｓ１２１２でＹｅｓ）、メッセージ１１０１を削除する。

図３は、第１実施形態で用いられるデータ構造例を示す図である。図３の（ａ）は送信先情報管理部１０１６で管理するデータ構造の一例であり、送信先コンポーネント情報１１０４を要素に持つ。図３の（ｂ）はメッセージ管理部１０１３で管理するデータ構造の一例であり、メッセージＩＤ１１０２、送信先コンポーネント数１１０３を要素に持つ。さらに本実施形態ではメッセージが送信された順序を管理するための送信順序カウンタ３０１を要素に持つ。図３の（ｃ）はメッセージ保持期間管理部１０１４で管理するデータ構造の一例であり、メッセージ保持期間１１０５を要素に持つ。

図４は、第１実施形態における、あるトピックに対するSubscriber登録処理の流れを示す図である。以下、図４における受信コンポーネント１０２は、SubscriberＡとして説明をする。トピック毎に存在する要求応答部１０１７は、Subscriber登録要求に備えるため、通信制御部１０４に対して要求受信待ちを指示する（Ｓ４０１）。SubscriberＡが通信ミドルウェア１０５に対してトピックの購読予約を行うと（Ｓ４０２）、要求監視部１０２２がその指示を受け取り、通信制御部１０４を通じてトピックに対して購読予約を行う（Ｓ４０３）。要求応答部１０１７は、受け取ったSubscriberＡの情報を送信先情報管理部１０１６に登録する（Ｓ４０３）。

図５は、第１実施形態における、Publisherのメッセージ送信処理の流れを示す図である。以下、図５における送信コンポーネント１０１は、PublisherＡとして説明をする。PublisherＡは通信ミドルウェア１０５に対してあるトピックのメッセージを送信する旨を指示する。該当するトピックに対応するメッセージ書き込み部１０１１がその指示を受け取ると（Ｓ５００）、メッセージ格納部１０１２とメッセージ管理部１０１３に対してそのメッセージを登録する（Ｓ５０１、Ｓ５０２）。メッセージ管理部１０１３は、何番目に送信するメッセージかを示す送信順序カウンタ３０１と、該当するトピックに指定されている送信先コンポーネント数１１０３とを対応させて保持しておく（Ｓ５０３）。本実施形態ではトピックごとに送信先コンポーネント数１１０３を通信ミドルウェアに対してあらかじめ設定しておくことを想定しているが、トピック登録時にPublisherから指定するようにしてもよい。また、送信順序カウンタ３０１は、メッセージに付与する直前に値が１つインクリメントされ、当該メッセージに付与されるようにすればよい。また、送信先コンポーネント数１１０３は、対応するメッセージの送信に応じてその数値が減算される「残り参照カウンタ」として機能するものである。以上のＳ５０１〜Ｓ５０３は図１１のＳ１２０１に対応する。

次に、メッセージ書き込み部１０１１は、送信先情報管理部１０１６より、該当するトピックの送信先Subscriber情報（送信先コンポーネント情報）を取得する（Ｓ５０４）。そして、メッセージ書き込み部１０１１は、送信先Subscriberが存在したら（Ｓ５０５でＹｅｓ）、通信制御部１０４を介してメッセージを送信する（Ｓ５０６）。その後、メッセージ管理部１０１３に対して、送信したメッセージの送信先コンポーネント数１１０３を１つデクリメントするよう指示をする（Ｓ５０７）。以上のＳ５０５〜Ｓ５０７の処理が、Ｓ５０４において取得された全ての送信先Subscriberについて実行される。これらの処理は図１１のＳ１２０２〜Ｓ１２０４に対応する。登録されている全ての送信先Subscriberにメッセージの送信を終えると、当該メッセージの送信先コンポーネント数１１０３をチェックする（Ｓ５０８）。メッセージの送信先コンポーネント数１１０３が０以下の場合（Ｓ５０８でＮｏ）、メッセージ書き込み部１０１１は、メッセージ削除部１０１５にメッセージ削除処理を依頼する（Ｓ５０９）。Ｓ５０８〜ＳＳ５１０の処理はＳ１２０５、Ｓ１２１０Ｓ１２１２に対応する。メッセージ削除処理については、図６で詳細に説明する（Ｓ５１０）。

図６は、第１実施形態における、メッセージ削除処理の流れを示す図である。メッセージ削除部１０１５は、まずメッセージ削除依頼の通知待ちを行う（Ｓ６０１）。メッセージ削除部１０１５は、メッセージ書き込み部１０１１よりメッセージ削除依頼を受け取ると（Ｓ５０９）、メッセージ保持期間管理部１０１４からメッセージ保持期間１１０５を獲得する（Ｓ６０２）。続いて、タイマをクリアしてから起動する（Ｓ６０３）。メッセージ削除処理中にメッセージ配信処理を受け取ると、当該メッセージ削除処理を終了する（Ｓ６０４でＹｅｓ）。図には記述していないが、メッセージ削除部１０１５はメッセージ削除処理を終了すると、Ｓ６０１に戻りメッセージ削除依頼の通知待ち処理を繰り返す。メッセージ配信処理を受け取らない場合（Ｓ６０４でＮｏ）、メッセージ保持期間１１０５とタイマの値を比較する（Ｓ６０５）。タイマの値がメッセージ保持期間を超えていたら（Ｓ６０５でＹｅｓ）、メッセージ格納部１０１２、メッセージ管理部１０１３にメッセージ解放の指示を行う（Ｓ６０６、Ｓ６０７）。なお、タイマはトピックごとに用意されるものとし、同時期に異なるトピックのメッセージ削除処理が発生したとしても、それぞれのメッセージ削除処理は独立したタイマで管理される。

図７は、第１実施形態における、新規参入したSubscriberに対して保持しておいたメッセージを配信する処理の流れを示す図である。以下、図７における受信コンポーネント１０３は、SubscriberＢとして説明をする。本実施形態では、起動時間短縮要求により、SubscriberＢは、システム起動からある程度時間が経ってから起動するケースを想定している。

まず、要求応答部１０１７は他コンポーネントからのメッセージ配信の要求を受け付けるため、通信制御部１０４に要求受信待ちを指示する（Ｓ７００）。要求監視部１０３２はSubscriber Ｂからの配信指示を受け取ると（Ｓ７０１）、通信制御部１０４を通じてトピックへのメッセージ配信指示を行う（Ｓ７０２）。要求応答部１０１７はその指示を受け取ると、配信要求のあったメッセージが削除処理中であるか判断し、削除中であったら（Ｓ７０３でＹｅｓ）、メッセージ削除部１０１５に対してメッセージ配信受付を通知する（Ｓ７０４）。これは現在進行中のメッセージ削除処理をストップさせるためであり、メッセージ配信受付通知を受け取った後のメッセージ削除停止処理（Ｓ７０５）のフローについては図６で述べたとおりである。その後、要求応答部１０１７はメッセージ書き込み部１０１１に対してメッセージ配信の指示をする（Ｓ７０６）。メッセージ書き込み部１０１１は、メッセージ管理部１０１３に管理されているメッセージを獲得する（Ｓ７０７）。本実施形態では、メッセージに対応づけられた送信順序カウンタを参照し、送信順序にしたがって獲得することを想定している。もしメッセージ管理部１０１３に管理されているメッセージが存在しないか、配信要求のあったメッセージを全て送信し終えていたら、処理を終了する（Ｓ７０８でＹｅｓ）。一方、送信するべきメッセージが存在したら（Ｓ７０８でＮｏ）、通信制御部１０４を通じて配信要求のあったSubscriberＢに対してメッセージを送信する（Ｓ７０９）。メッセージを送信したら送信したメッセージの送信先コンポーネント数１１０３を１つデクリメントする（Ｓ７１０）。このとき送信先コンポーネント数１１０３が０以下になったら（Ｓ７１１でＮｏ）メッセージ削除部１０１５に対してメッセージ削除依頼を指示する（Ｓ７１２）。メッセージ削除依頼を受け取ったメッセージ削除部１０１５によるメッセージ削除処理については図６で述べたとおりである。その後メッセージ書き込み部１０１１は、Ｓ７０６以下の処理を送信順序カウンタの順番に沿って繰り返し、処理するメッセージが存在しなくなったら（Ｓ７０８でＹｅｓ）、メッセージ配信処理を終える。なお、本実施形態では新規参入したSubscriberＢが自身への配信指示を行う例を用いて説明したが、通信ミドルウェア１０５がSubscriberＢから購読予約をされた段階で保持しておいたメッセージを送信するよう実装してもよい。なお、図示していないが、通常、メッセージ配信処理終了後、要求応答部１０１７は通信制御部１０４に再度要求受信待ち指示を行い（Ｓ７００）、図７のメッセージ配信処理を繰り返す。

以上説明したとおり、第１実施形態によれば、送信済みのメッセージであっても送信先コンポーネント数とメッセージ保持期間に従ってメッセージを保持しておき、新規参入したSubscriberに対して保持しておいたメッセージを送信する。Subscriberはメッセージ発行後時間が経ってから起動しても、メッセージを受信することができる。

すなわち、第１実施形態によれば、メッセージが送信される回数をあらかじめ決めておくことにより、送信コンポーネントが送信したメッセージを、時間を置いて後から起動した受信コンポーネントに確実に送信することが可能となる。これにより、例えば、起動時間短縮モードなどで起動優先度の低いコンポーネントも後から必要なメッセージが得られ、あたかも最初から起動していたかのように振舞うことができる。また、所定数のコンポーネントに送信済みのメッセージであっても、一定期間保持しておきメッセージ送信要求の度に保持期間をリセットすることによって、想定していない受信コンポーネントからのメッセージ送信要求に応えることができる。例えば、受信コンポーネントが一定期間置きに不特定数生成されるような場合、想定していたメッセージの送信回数を超えても、新規受信コンポーネントのメッセージ送信要求に応えることが可能となる。これらメッセージ送信回数とメッセージ保持期間を組み合わせることにより、必要以上にメッセージ保持期間を長く設定する必要がなくなり、データ保持領域の逼迫を低減することができる。

＜第２実施形態＞
次に、第２実施形態を説明する。第２実施形態のソフトウェア構成の詳細は第１実施形態で用いた図１と同様であるが、本実施形態では、サーバ／クライアントモデルの実現をサポートする通信ミドルウェア１０５を想定する。そのため、送信コンポーネント１０１をサーバ・コンポーネント（以下、サーバ１０１という）、受信コンポーネント１０２、１０３をクライアント・コンポーネント（以下、クライアント１０２，１０３という）と考える。

第２実施形態で用いられるデータの構造について図３を用いて説明する。図３の（ａ）は送信先情報管理部１０１６で管理するデータ構造の一例であり、送信先コンポーネント情報１１０４としてメッセージ送信のリクエストがあった返信先コンポーネントの情報を示している。図３の（ｂ）はメッセージ管理部１０１３で管理するデータ構造の一例、図３の（ｃ）はメッセージ保持期間管理部１０１４で管理するデータ構造の一例を示している。

図８は、第２実施形態における、クライアント１０２からサーバ１０１へのメッセージ要求処理の流れを示す図である。サーバ１０１からメッセージ要求の受信待ち指示を受け取ると（Ｓ９０１）、メッセージ書き込み部１０１１は要求応答部１０１７に対して要求受信待ち指示を行う（Ｓ９０２）。要求応答部１０１７は、メッセージ要求に備えるため、通信制御部１０４に対して要求受信待ちを指示する（Ｓ９０３）。クライアント１０２が通信ミドルウェア１０５に対してメッセージ要求を行うと（Ｓ９０４）、要求監視部１０２２はその指示を受け取り、通信制御部１０４を通じてサーバ１０１に対してメッセージ要求を行う（Ｓ９０５）。要求応答部１０１７は受け取ったクライアント１０２の情報を送信先情報管理部１０１６に登録する（Ｓ９０６）。その後、メッセージ要求を受け取ったサーバ１０１は、メッセージ書き込み部１０１１に対して返信メッセージを登録する（Ｓ９０７）。この後のメッセージ返信処理の流れについては、図９で説明する。

図９は、第２実施形態における、サーバのメッセージ返信処理の流れを示す図である。サーバ１０１がメッセージ書き込み部１０１１に対して返信メッセージを登録すると（Ｓ１０００）、メッセージ書き込み部１０１１は、メッセージ格納部１０１２とメッセージ管理部１０１３に対してそのメッセージを登録する（Ｓ１００１、Ｓ１００２）。メッセージ管理部１０１３は、図３の（ｂ）に示すように、サーバ１０１が送信するメッセージか何番目かを示す送信順序カウンタと、あらかじめ指定された送信先コンポーネント数１１０３とを対応させて、保持しておく（Ｓ１００３）。続いて、送信先情報管理部１０１６より、メッセージの返信先コンポーネント情報を取得し（Ｓ１００４）、通信制御部１０４を介してメッセージを送信する（Ｓ１００５）。その後、メッセージ管理部１０１３は送信したメッセージの送信先コンポーネント数１１０３（残り参照カウンタ）を１つデクリメントする（Ｓ１００６）。このとき、メッセージの送信先コンポーネント数１１０３が０以下になったら（Ｓ１００７でＮｏ）、メッセージ削除部１０１５にメッセージ削除処理を依頼する（Ｓ１００８）。メッセージ削除処理Ｓ１００９については、第１実施形態で述べた図６の処理と同等である。メッセージを返信し終えたら、メッセージ返信処理を終了する。なお、図示していないが、通常、メッセージ返信処理終了後、図８のメッセージ要求処理が繰り返される（Ｓ９０１）。

次に、新規参入したクライアントに対して保持しておいたメッセージを配信する処理の流れを、第１実施形態の説明で用いた図７を用いて説明する。以下、図７における受信コンポーネント１０３はクライアント１０３として説明をする。第２実施形態でも、起動時間短縮要求により、クライアント１０３は、システム起動からある程度時間が経ってから起動するケースを想定している。

まず、要求応答部１０１７は他コンポーネントからのメッセージ配信の要求を受け付けるため、通信制御部１０４に要求受信待ちを指示する（Ｓ７００）。要求監視部１０３２はクライアント１０３からの配信指示を受け取ると（Ｓ７０１）、通信制御部１０４を通じてサーバ１０１へのメッセージ配信指示を行う（Ｓ７０２）。要求応答部１０１７はその指示を受け取ると、配信要求のあったメッセージが削除処理中であるか判断し、削除中であったら（Ｓ７０３でＹｅｓ）、メッセージ削除部１０１５に対してメッセージ配信受付を通知する（Ｓ７０４）。これは現在進行中のメッセージ削除処理をストップさせるためであり、メッセージ配信受付通知を受け取った後のメッセージ削除停止処理（Ｓ７０５）のフローについては第１実施形態で述べた図６の処理と同等である。その後要求応答部１０１７はメッセージ書き込み部１０１１に対してメッセージ配信の指示をする（Ｓ７０６）。

メッセージ書き込み部１０１１は、メッセージ管理部１０１３に管理されているメッセージを獲得する（Ｓ７０７）。本実施形態では、メッセージに対応づけられた送信順序カウンタを参照し、送信順序にしたがって獲得することを想定している。もしメッセージ管理部１０１３に管理されているメッセージが存在しないか、配信要求のあったメッセージを送信し終えたら、処理を終了する（Ｓ７０８でＹｅｓ）。管理されている未送信のメッセージが存在したら（Ｓ７０８でＮｏ）、通信制御部１０４を通じて配信要求のあったクライアント１０３に対してメッセージを送信する（Ｓ７０９）。メッセージを送信したら送信したメッセージの送信先コンポーネント数１１０３を１デクリメントする（Ｓ７１０）。このとき送信先コンポーネント数１１０３が０以下になったらメッセージ削除部１０１５に対してメッセージ削除依頼を指示する（Ｓ７１２）。メッセージ削除依頼を受け取ったメッセージ削除処理Ｓ７１３のフローについては第１実施形態で述べた図６の処理と同等である。その後メッセージ書き込み部１０１１は、Ｓ７０６以下の処理を送信順序カウンタの順番に沿って繰り返し、処理するメッセージが存在しなくなったら（Ｓ７０８でＹｅｓ）、メッセージ配信処理を終える。なお、本実施形態では新規参入したクライアント１０３が自身への配信指示を行う例を用いて説明したが、通信ミドルウェア１０５がクライアント１０３からメッセージ要求をされた段階で保持しておいたメッセージを送信するよう実装してもよい。もしくは、クライアントの参入を監視する監視コンポーネントを別途用意し、監視コンポーネントが通信ミドルウェアに対して新規参入したクライアントへの配信指示を行ってもよい。なお、図示していないが、通常、メッセージ配信処理終了後、要求応答部１０１７は通信制御部１０４に再度要求受信待ち指示を行い（Ｓ７００）、図７のメッセージ配信処理を繰り返す。

＜第３実施形態＞
次に、第３実施形態を説明する。第３実施形態のソフトウェア構成は、第１実施形態（図１）とほぼ同じである。但し、図１において、要求応答部１０１７からメッセージ管理部１０１３との間の通信が追加される。

次に、図１２を用いて、第３実施形態における通信ミドルウェア１０５がメッセージ１１０１を送信コンポーネント１０１から受け取って削除するまでの処理を説明する。送信コンポーネント１０１からメッセージ１１０１の送信指示を受け取ると、メッセージ管理部１０１３は、メッセージ１１０１にメッセージＩＤ１１０２、送信先コンポーネント数１１０３を対応させて保持する（Ｓ１４０１）。続いて、メッセージ書き込み部１０１１は、メッセージ１１０１に対応する送信先コンポーネント情報１１０４を参照する（Ｓ１４０２）。そして、未送信のコンポーネントが存在したら（Ｓ１４０２でＹｅｓ）、メッセージ書き込み部１０１１は該当する送信先コンポーネントにメッセージ１１０１を送信する（Ｓ１４０３）。その後、メッセージ１１０１の送信先コンポーネント数１１０３を１つデクリメントする（Ｓ１４０４）。Ｓ１４０３からＳ１４０４の処理を未送信のコンポーネントが存在しなくなるまで繰り返す。

未送信のコンポーネントが存在しなくなり（Ｓ１４０２でＮｏ）、メッセージ１１０１の送信先コンポーネント数１１０３が０より大きい場合（Ｓ１４０５でＹｅｓ）、メッセージ書き込み部１０１１は、受信コンポーネントからの指示を待つ（Ｓ１４０６）。メッセージ書き込み部１０１１は、メッセージ配信指示を受け取ったら（Ｓ１４０７でＹｅｓ）、指示された送信先コンポーネントにメッセージ１１０１を送信し（Ｓ１４０８）、送信先コンポーネント数１１０３を１つデクリメントする（Ｓ１４０９）。その後、Ｓ１４０５の処理に戻る。また、メッセージ管理部１０１３は、要求応答部１０１７から送信先コンポーネント数１１０３を増加する指示を受け取ったら（Ｓ１４１３でＹｅｓ）、送信先コンポーネント数１１０３を１つインクリメントして（Ｓ１４１４）、Ｓ１４０５の処理に戻る。ここで、第３実施形態では送信先コンポーネント数１１０３増加の指示は、受信コンポーネント１０２、１０３からされるものと想定している。このように、受信コンポーネントに応じて送信先コンポーネント数１１０３変更の指示を行うことにより、あらかじめ参入を想定されていなかった受信コンポーネントへのメッセージ配信を可能としている。

送信先コンポーネント数１１０３が０以下になったら（Ｓ１４０５でＮｏ）、メッセージ削除処理のために、タイマをスタートする（Ｓ１４１０）。このとき、メッセージ保持期間１１０５が過ぎる前に（Ｓ１４１２でＮｏ）メッセージ配信指示を受け取ったら（Ｓ１４１１でＹｅｓ）、メッセージ削除処理を終えＳ１４０８のメッセージ送信処理に移る。他方、メッセージ配信指示を受け取らずメッセージ保持期間１１０５が過ぎたら（Ｓ１４１２でＹｅｓ）、メッセージ１１０１を削除する。

なお、メッセージ保持期間１１０５の変更の指示を受信コンポーネント１０２、１０３から受け付け、メッセージ保持期間１１０５を変更するようにしてもよい。例えば、受信コンポーネント１０２，１０３からの保持期間変更要求を要求監視部１０２２，１０２３が受信して要求応答部１０１７に通知する。保持期間変更要求を通知された要求応答部１０１７は、メッセージ管理部１０１３によって管理されているメッセージ保持期間１１０５を変更する。なお、更新の単位は、たとえば＋１０ｍｓとすることが挙げられる。

また、メッセージ格納部１０１２に保持され、メッセージ管理部１０１３により管理されているメッセージのうち特定のメッセージをソフトウェアコンポーネントから削除できるようにしてもよい。この場合、例えば、受信コンポーネント１０２，１０３からのメッセージＩＤを含む削除要求を要求監視部１０２２，１０２３が受信して要求応答部１０１７に通知する。削除要求を通知された要求応答部１０１７は、メッセージ格納部１０１２に保持され、メッセージ管理部１０１３により管理されているメッセージのうち、削除要求で指定されているメッセージＩＤを持つメッセージを削除する。

また、メッセージ保持期間管理部１０１４は、システムの起動モード毎に異なるソフトウェアコンポーネントのシステム起動時からの起床時間（遅延時間）を管理し、起動モードに応じてメッセージ保持期間を変更するようにしてもよい。なお、起動モードはユーザにより指定されるものとする。

＜第４実施形態＞
なお、本発明は、上記第１乃至第３の実施形態と同等の処理を、コンピュータプログラムでも実現できる。この場合、図１をはじめとする構成要素の各々は関数、もしくはＣＰＵが実行するサブルーチンで機能させれば良い。また、通常、コンピュータプログラムは、ＣＤ−ＲＯＭ等のコンピュータ可読記憶媒体に格納されており、それを、コンピュータが有する読取り装置（ＣＤ−ＲＯＭドライブ等）にセットし、システムにコピーもしくはインストールすることで実行可能になる。従って、かかるコンピュータ読み取り可能な記憶媒体も本発明の範疇にあることは明らかである。

Claims (9)

1. 複数のソフトウェアコンポーネントと通信し、ソフトウェアコンポーネントから受け取ったメッセージを他のソフトウェアコンポーネントへ渡すメッセージ処理装置であって、
   ソフトウェアコンポーネントからメッセージを受信し、受信したメッセージに送信数を設定して当該受信したメッセージを保持する保持手段と、
   前記受信したメッセージと、前記送信数および保持期間を対応させて管理する管理手段と、
   他のソフトウェアコンポーネントからの配信要求に応じて、前記保持手段に保持されている前記受信したメッセージを、前記他のソフトウェアコンポーネントへ送信する送信手段と、
   前記受信したメッセージが、前記送信手段により前記管理手段により管理されている前記送信数だけ送信された後、前記保持期間にわたって新たな配信要求がない場合に、前記受信したメッセージを、前記保持手段から削除する削除手段とを備えることを特徴とするメッセージ処理装置。
2. ソフトウェアコンポーネントから予約要求を受け付け、予約を行ったソフトウェアコンポーネントを登録する送信先情報管理手段を更に備え、
   前記送信手段は、更に、前記受信したメッセージの受信のタイミングで、前記送信先情報管理手段によって登録されているコンポーネントに前記受信したメッセージを送信し、
   前記削除手段は、前記受信したメッセージが、前記送信先情報管理手段に登録されている全てのコンポーネントに送信され、かつ、前記管理手段により管理されている前記送信数またはそれ以上の数の送信が行われた後、前記保持期間にわたって新たな配信要求がない場合に、前記受信したメッセージを前記保持手段と前記管理手段から削除することを特徴とする請求項１に記載のメッセージ処理装置。
3. 前記管理手段は、前記複数のソフトウェアコンポーネントのいずれかから前記保持期間の変更の指示に応じて、前記保持期間を変更することを特徴とする請求項１または２に記載のメッセージ処理装置。
4. 前記管理手段は、前記複数のソフトウェアコンポーネントのいずれかから前記送信数の変更の指示を受け付け、前記送信数を変更することを特徴とする請求項１乃至３のいずれか１項に記載のメッセージ処理装置。
5. 前記複数のソフトウェアコンポーネントのいずれかより特定のメッセージを削除する指示を受け付けると、前記保持手段と前記管理手段が前記特定のメッセージに関わる情報を削除することを特徴とする請求項１乃至４のいずれか１項に記載のメッセージ処理装置。
6. 前記管理手段は、
   起動モード毎に、前記複数のソフトウェアコンポーネントの各々に関してシステム起動時からの遅延時間を管理し、
   起動モードに応じてメッセージ保持期間を変更することを特徴とする請求項１乃至５のいずれか１項に記載のメッセージ処理装置。
7. 複数のソフトウェアコンポーネントと通信し、ソフトウェアコンポーネントから受け取ったメッセージを他のソフトウェアコンポーネントへ渡すメッセージ処理装置によるメッセージ処理方法であって、
   保持手段が、ソフトウェアコンポーネントからメッセージを受信し、受信したメッセージに送信数を設定して該受信したメッセージを保持する保持工程と、
   管理手段が、前記受信したメッセージと、前記送信数および保持期間を対応させて管理する管理工程と、
   送信手段が、他のソフトウェアコンポーネントからの配信要求に応じて、前記保持手段に保持されている前記受信したメッセージを、前記他のソフトウェアコンポーネントへ送信する送信工程と、
   削除手段が、前記受信したメッセージが、前記送信手段により前記管理手段により管理されている前記送信数だけ送信された後、前記保持期間にわたって新たな配信要求がない場合に、前記受信したメッセージを、前記保持手段から削除する削除工程とを有することを特徴とするメッセージ処理方法。
8. 請求項７に記載されたメッセージ処理方法の各工程をコンピュータに実行させるためのコンピュータプログラム。
9. 請求項７に記載されたメッセージ処理方法の各工程をコンピュータに実行させるためのコンピュータプログラムを格納したコンピュータ読み取り可能な記憶媒体。

Images