JP2019028599A - 情報処理システムおよび制御方法 - Google Patents

Abstract

【課題】Ｐｕｂｌｉｓｈｅｒがメッセージを送信するＴｏｐｉｃに複数のＳｕｂｓｃｒｉｂｅｒが存在する場合でも、疎結合性を確保しつつ、複数のＳｕｂｓｃｒｉｂｅｒに適切にメッセージを配信できる情報処理システムを提供する。【解決手段】ネットワークデバイスをパブリッシャーとしてメッセージを受け取るデバイス情報Ｔｏｐｉｃ３２１と、ネットワークデバイスをサブスクライバーとしてメッセージの処理の成功を示すメッセージを配信するための成功確認Ｔｏｐｉｃ３２２を含む情報処理システムを設ける。情報処理システムは、デバイス情報Ｔｏｐｉｃにより配信された第１メッセージの即時処理Ａｃｔｉｏｎ３６１及び非即時処理Ａｃｔｉｏｎ３６２での処理の完了に応じて処理結果を情報管理サービスに登録し、上記処理結果に従い、成功確認Ｔｏｐｉｃに対し、第１メッセージの処理の成功を示す第２メッセージを配信する。【選択図】図４

Description

本発明は、情報処理システムおよび制御方法

インターネットに家電や自動車などのオブジェクトをクライアントとして接続する「Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ」（以下、「ＩｏＴ」と記載）を実現するシステムが提案されている。また、近年、画像処理装置の多機能化が進み、ＭＦＰと呼ばれる複合機もＩｏＴクライアントに対応することが可能となった。ＭＦＰは、Ｍｕｌｔｉｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌの略称である。また、ＩｏＴは、Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓの略称である。ＩｏＴにおいて、ＩｏＴクライアントとなるオブジェクトは、不特定多数存在するので、ＩｏＴシステムは、様々なオブジェクトの膨大な情報を収集することが可能となる。一方で、不特定多数存在するＩｏＴクライアントとの情報の送受信を、ＩｏＴシステムが管理することは容易ではない。したがって、ＩｏＴを実現する多くのシステムは、ＩｏＴデバイスとシステム間のメッセージの送受信方法に「出版−購読型モデル」を採用している。また、特許文献１は、Ｐｕｂｌｉｓｈ、Ｓｕｂｓｃｒｉｂｅ方式で実現されたソーシャルネットワーキングシステムを開示している。

出版−購読型モデルとは、Ｐｕｂｌｉｓｈ、Ｓｕｂｓｃｒｉｂｅ方式でメッセージを送受信するためのモデルである。出版−購読型モデルでは、メッセージを作成し、送信するクライアントを「Ｐｕｂｌｉｓｈｅｒ（パブリッシャー）」と定義する。また、メッセージを受信するクライアントを「Ｓｕｂｓｃｒｉｂｅｒ（サブスクライバー）」と定義する。そして、ＰｕｂｌｉｓｈｅｒとＳｕｂｓｃｒｉｂｅｒ間のメッセージの送受信を管理するサービスを「Ｂｒｏｋｅｒ」と定義する。Ｂｒｏｋｅｒは、Ｐｕｂｌｉｓｈｅｒから送信されたメッセージを仕分けした上で、Ｓｕｂｓｃｒｉｂｅｒに届けるために、「Ｔｏｐｉｃ」というメッセージの送信先としてのメッセージ管理サービスを用意する。この際、Ｔｏｐｉｃは、階層構造を持つことができる。例えば、ＭＦＰの現在のトナー情報を管理するサービスの場合には、「ＤｅｖｉｃｅＡ／Ｔｏｎｅｒ」という階層構造でＴｏｐｉｃを定義することで分かりやすく表現できる。

Ｐｕｂｌｉｓｈｅｒは、順次メッセージを作成し、送信先であるＴｏｐｉｃに登録する行為であるＰｕｂｌｉｓｈ（以下、「Ｐｕｂ」と記載）を行う。一方、Ｓｕｂｓｃｒｉｂｅｒは、順次Ｔｏｐｉｃからメッセージを受信する行為であるＳｕｂｓｃｒｉｂｅ（以下、「Ｓｕｂ」と記載）を行う。上記のように、ＰｕｂｌｉｓｈｅｒとＳｕｂｓｃｒｉｂｅｒがそれぞれ独立して、ＰｕｂとＳｕｂを行うことが出版−購読型モデルの特徴である。したがって、ＰｕｂｌｉｓｈｅｒとＳｕｂｓｃｒｉｂｅｒは、高い疎結合性を実現している。高い疎結合性がもたらす最大のメリットとして、ＰｕｂｌｉｓｈｅｒとＳｕｂｓｃｒｉｂｅｒは、お互いの構成に依存せずにそれぞれが拡張、縮小を行うことができる点が挙げられる。このメリットは、ＩｏＴにおいて、最大限に発揮される。一例をあげると、Ｓｕｂｓｃｒｉｂｅｒを追加しつつも、Ｐｕｂｌｉｓｈｅｒの修正影響なしという構成を容易に実現できる。したがって、出版−購読型モデルはＩｏＴを実現するための強力なメッセージングモデルである。

特開２０１６−１９７４４４号公報

出版−購読型モデルにおいて、ＰｕｂｌｉｓｈｅｒからＴｏｐｉｃへＰｕｂしたメッセージの到達は保証される。一方で、ＳｕｂｓｃｒｉｂｅｒがＴｏｐｉｃからのＳｕｂの成功は保証されない。ＳｕｂｓｃｒｉｂｅｒがＳｕｂに失敗した場合、ＰｕｂｌｉｓｈｅｒがＰｕｂのリトライを行う対処が一般的である。しかし、出版−購読型モデルは、ＰｕｂｌｉｓｈｅｒとＳｕｂｓｃｒｉｂｅｒがそれぞれ独立して処理を行うので、Ｐｕｂｌｉｓｈｅｒは、Ｓｕｂｓｃｒｉｂｅｒの処理結果を知ることはできない。したがって、ＰｕｂｌｉｓｈｅｒがＰｕｂのリトライを行うべきかどうかを判断することができないという問題がある。この問題に対する対処として、システムにＳｕｂｓｃｒｉｂｅｒの処理結果通知用Ｔｏｐｉｃを設けることが考えられる。このシステムでは、Ｓｕｂｓｃｒｉｂｅｒが処理に成功した場合、処理結果通知用Ｔｏｐｉｃにその旨をＰｕｂする。Ｐｕｂｌｉｓｈｅｒは、処理結果通知用ＴｏｐｉｃをＳｕｂし、処理に成功した旨のメッセージを受信した場合は、Ｐｕｂのリトライを行わない。しかし、所定の時間が経過しても処理に成功した旨のメッセージを受信できない場合は、Ｐｕｂのリトライを行う。

出版−購読型モデルにおいて、１つのＴｏｐｉｃに対し、Ｓｕｂｓｃｒｉｂｅｒが複数存在するシステムを想定する。このシステムに従来技術を適用すると、Ｐｕｂｌｉｓｈｅｒは、複数のＳｕｂｓｃｒｉｂｅｒの処理の内、いずれかが失敗した場合、Ｐｕｂのリトライを行うことになる。より具体的には、Ｐｕｂｌｉｓｈｅｒは、第１のＳｕｂｓｃｒｉｂｅｒの処理結果通知用Ｔｏｐｉｃと、第２のＳｕｂｓｃｒｉｂｅｒの処理結果通知用ＴｏｐｉｃをそれぞれＳｕｂし、処理結果を判断することになる。したがって、ＰｕｂｌｉｓｈｅｒがＳｕｂｓｃｒｉｂｅｒの構成に依存することになり、出版−購読型モデルの利点である疎結合性を失ってしまう。また、例えば、さらに第３のＳｕｂｓｃｒｉｂｅｒを追加した場合に、Ｐｕｂｌｉｓｈｅｒが当該Ｓｕｂｓｃｒｉｂｅｒの処理結果を判断するように変更する必要性が生じる。したがって、Ｓｕｂｓｃｒｉｂｅｒの追加を行ってもＰｕｂｌｉｓｈｅｒの影響を受けない、という疎結合性のメリットを失ってしまう。本発明は、Ｐｕｂｌｉｓｈｅｒがメッセージを送信するＴｏｐｉｃに複数のＳｕｂｓｃｒｉｂｅｒが存在する場合でも、疎結合性を確保しつつ、複数のＳｕｂｓｃｒｉｂｅｒに適切にメッセージを配信できる情報処理システムの提供を目的とする。

本発明の一実施形態の情報処理システムは、ネットワークデバイスをパブリッシャーとしてメッセージを受け取る第１メッセージ管理サービスと、該ネットワークデバイスをサブスクライバーとして前記メッセージの処理の成功を示すメッセージを配信するための第２メッセージ管理サービスを含むシステムである。前記情報処理システムは、前記第１メッセージ管理サービスにより配信された第１メッセージの第１サービスでの処理の完了に応じて、前記第１サービスでの処理結果を情報管理サービスに登録する第１登録手段と、前記第１メッセージ管理サービスにより配信された前記第１メッセージの第２サービスでの処理の完了に応じて、前記第２サービスでの処理結果を前記情報管理サービスに登録する第２登録手段と、前記第１メッセージの処理結果に従い、前記第２メッセージ管理サービスに対して、前記第１メッセージの処理の成功を示す第２メッセージを配信する配信手段と、を有する。

本発明の情報処理システムによれば、Ｐｕｂｌｉｓｈｅｒがメッセージを送信するＴｏｐｉｃに複数のＳｕｂｓｃｒｉｂｅｒが存在する場合でも、疎結合性を確保しつつ、複数のＳｕｂｓｃｒｉｂｅｒに適切にメッセージを配信できる。

実施例１の全体システム構成を示す図である。 ＩｏＴ管理サービス乃至ＭＦＰのハードウェア構成例を示す図である。 実施例１のソフトウェア構成を示す図である。 実施例１のシステム全体の処理シーケンスを示す図である。 デバイス情報Ｔｏｐｉｃに登録されるメッセージである。 Ｓｕｂイベント情報通知Ｔｏｐｉｃに登録されるメッセージである。 Ａｃｔｉｏｎ処理状況の判定処理の一例を説明する図である。 Ａｃｔｉｏｎ処理結果Ｔｏｐｉｃに登録されるメッセージである。 成功確認Ｔｏｐｉｃに登録されるメッセージの一例である。 実施例２の全体システム構成を示す図である。 実施例２のソフトウェア構成を示す図である。 実施例２のシステム全体の処理シーケンスを示す図である。 実施例３の全体システム構成を示す図である。 実施例３のソフトウェア構成を示す図である。 実施例３のシステム全体の処理シーケンスを示す図である。

（実施例１)
［システムの全体構成］
図１は、実施例１の全体システム構成を示す図である。
図１に示す情報処理システムは、ＩｏＴ管理サービス１０１、Ｔｏｐｉｃイベント管理サービス１０２、データベース管理サービス１０３、スクリプト管理サービス１０４、ＭＦＰ１１１を備える。ＩｏＴ管理サービス１０１乃至ＭＦＰ１１１は、ネットワーク１２０を介して接続されている。ネットワーク１２０は、例えば、インターネット等のＬＡＮ、ＷＡＮ、電話回線、専用デジタル回線等であり、またこれらの組み合わせにより実現される通信ネットワークである。ＬＡＮは、Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋの略称である。また、ＷＡＮは、Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋの略称である。

ＩｏＴ管理サービス１０１、Ｔｏｐｉｃイベント管理サービス１０２、データベース管理サービス１０３、スクリプト管理サービス１０４は、例えば、ＡｍａｚｏｎＷｅｂＳｅｒｖｉｃｅ株式会社が提供するクラウドサービスを想定する。一方で、本発明における上記サービスは、ＡｍａｚｏｎＷｅｂＳｅｒｖｉｃｅ株式会社が提供するクラウドサービスに限定されないものとする。例えば、ＩｏＴ管理サービス１０１乃至スクリプト管理サービス１０４が、ＧｏｏｇｌｅＣｌｏｕｄＰｌａｔｆｏｒｍや、ＭｉｃｒｏｓｏｆｔＡｚｕｒｅなどのクラウドサービスで実現されても良い。

ＩｏＴ管理サービス１０１は、ＩｏＴに関する各種機能を提供するクラウドサービスである。ＩｏＴ管理サービス１０１は、例えば、ＡｍａｚｏｎＷｅｂＳｅｒｖｉｃｅ株式会社が提供するＡＷＳＩｏＴを想定する。Ｔｏｐｉｃイベント管理サービス１０２は、ＩｏＴ管理サービス１０１が提供するメッセージ管理システムであるＴｏｐｉｃのＰｕｂ，Ｓｕｂイベントに関する情報を管理する。

以下の説明において、「Ｐｕｂする」あるいは「Ｓｕｂする」とは、識別情報（ＩＤ）付きでメッセージを送信することをいう。「Ｐｕｂする」とは、例えば、Ｐｕｂｌｉｓｈｅｒとしてのネットワークデバイスが、自身の所定の稼働情報を示すメッセージをＴｏｐｉｃに対して送信することをいう。また、「Ｓｕｂする」とは、例えば、Ｓｕｂｓｃｒｉｂｅｒとしての仮想マシンなどで実現されたサービスに対して、受信した所定のメッセージを配信することをいう。

Ｔｏｐｉｃイベント管理サービス１０２は、例えば、ＡｍａｚｏｎＷｅｂＳｅｒｖｉｃｅ株式会社が提供するクラウド上の仮想サーバである、ＡｍａｚｏｎＥＣ２上で稼働するＷｅｂサービスを想定する。データベース管理サービス１０３は、例えば、ＮｏＳＱＬ型構造のデータベース管理サービス（情報管理サービス）である。データベース管理サービス１０３は、例えば、ＡｍａｚｏｎＷｅｂＳｅｒｖｉｃｅ株式会社が提供するＡｍａｚｏｎＤｙｎａｍｏＤＢを想定する。また、データベース管理サービス１０３は、ＮｏＳＱＬ型構造のデータベース管理サービスであるとしたが、本発明に適用可能なデータベースの構造に関して特に限定しないものとする。例えば、データベース管理サービス１０３が、ＲＤＳ型のデータベース管理サービスなどでもよい。

スクリプト管理サービス１０４は、ＩｏＴ管理サービス１０１や、データベース管理サービス１０３の各種イベントをトリガーとして駆動するスクリプトを管理するサービスである。スクリプト管理サービス１０４は、例えば、ＡｍａｚｏｎＷｅｂＳｅｒｖｉｃｅ株式会社が提供するＡＷＳＬａｍｂｄａを想定する。

ＭＦＰ１１１は、ＩｏＴクライアントとなる複合機であり、ＩｏＴ管理サービス１０１が提供するＴｏｐｉｃに対し、デバイスの情報をＰｕｂする機能を有する。また、ＭＦＰ１１１は、複数台存在していてもよく、それぞれのＭＦＰ１１１がＩｏＴ管理サービス１０１と接続することも可能である。

［ハードウェア構成］
図２は、ＩｏＴ管理サービス１０１、Ｔｏｐｉｃイベント管理サービス１０２、データベース管理サービス１０３、スクリプト管理サービス１０４、ＭＦＰ１１１のハードウェア構成例を示す図である。

ＩｏＴ管理サービス１０１乃至ＭＦＰ１１１は、図２に示すような一般的なコンピュータのハードウェア構成を適用できる。図２に示すコンピュータは、ユーザインタフェース２０１乃至入出力インタフェース２０７を備える。
ユーザインタフェース２０１は、ディスプレイ、キーボード、マウス、タッチパネル等のハードウェアによって、情報の入出力を行う。これらのハードウェアを備えないコンピュータは、リモートデスクトップやリモートシェルなどにより、他のコンピュータから接続・操作することも可能である。ネットワークインタフェース２０２は、ＬＡＮなどのネットワークに接続して、他のコンピュータやネットワーク機器との通信を行う。ＣＰＵ２０３は、コンピュータ全体を制御する。具体的には、ＣＰＵ２０３は、ＲＯＭ２０４、ＲＡＭ２０５、記憶装置２０６などから読み込んだプログラムを実行する。ＣＰＵは、Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔの略称である。ＲＯＭは、Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙの略称で３ある。ＲＡＭは、Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙの略称である。ＲＯＭ２０４には、組込済みプログラムおよびデータが記録されている。ＲＡＭ２０５は、一時メモリ領域として機能する。記憶装置２０６は、例えばＨＤＤ等の記憶手段である。ＨＤＤは、Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅの略称である。各部は、入出力インタフェース２０７を介して接続されている。

［ソフトウェア構成］
図３は、実施例１のソフトウェア構成を示す図である。
ＭＦＰ１１１は、デバイス情報送信アプリケーション３００を有する。デバイス情報送信アプリケーション３００は、ＭＦＰ１１１の記憶装置２０６に格納され、ＣＰＵ２０３によって実行される。デバイス情報送信アプリケーション３００は、通信部３０１、デバイス情報管理部３０２、メッセージ生成部３０３、メッセージ解析部３０４、再送判定部３０５を有する。

通信部３０１は、ネットワークインタフェース２０２を介して、ＩｏＴ管理アプリケーション３１０と通信を行う。デバイス情報管理部３０２は、ＭＦＰ１１１で発生したエラー情報や、機器の構成などのデバイス情報を管理する。メッセージ生成部３０３は、デバイス情報Ｔｏｐｉｃ３２１にＰｕｂｌｉｓｈ（Ｐｕｂ）するメッセージの生成を行う。この際、メッセージ生成部３０３は、メッセージごとの一意のメッセージＩＤを発行し、ＰｕｂメッセージにメッセージＩＤを含める。さらに、メッセージ生成部３０３は、通信部３０１を介して、デバイス情報Ｔｏｐｉｃ３２１へメッセージをＰｕｂする。なお、メッセージ生成部３０３が生成したメッセージＩＤは、ＲＡＭ２０５に記憶される。

メッセージ解析部３０４は、通信部３０１を介して、成功確認Ｔｏｐｉｃ３２２とのＳｕｂｓｃｒｉｂｅ（Ｓｕｂ）の開始を行う。さらに、メッセージ解析部３０４は、成功確認Ｔｏｐｉｃ３２２から受信したメッセージの解析を行い、メッセージの中に含まれるメッセージＩＤを取得する。メッセージ解析部３０４は、取得したメッセージＩＤとメッセージ生成部３０３が生成したメッセージＩＤを照合し、処理の成功を判定する。再送判定部３０５は、Ｐｕｂのリトライの必要性を判断する。再送判定部３０５は、Ｐｕｂを行ったタイミングから所定の時刻が経過した場合に、Ｐｕｂのリトライが必要であると判断する。

ＩｏＴ管理サービス１０１は、ＩｏＴ管理アプリケーション３１０を有する。ＩｏＴ管理アプリケーション３１０は、ＩｏＴ管理サービス１０１の記憶装置２０６に格納され、ＣＰＵ２０３によって実行される。ＩｏＴ管理アプリケーション３１０は、通信部３１１、Ｔｏｐｉｃ情報管理部３２０を有する。

通信部３１１は、ネットワークインタフェース２０２を介して、デバイス情報送信アプリケーション３００、スクリプト管理アプリケーション３３０、Ｔｏｐｉｃイベント管理アプリケーション３４０と通信を行う。Ｔｏｐｉｃ情報管理部３２０は、Ｐｕｂ、Ｓｕｂ通信におけるメッセージの登録先であるＴｏｐｉｃを管理する。Ｔｏｐｉｃ情報管理部３２０は、デバイス情報Ｔｏｐｉｃ３２１、成功確認Ｔｏｐｉｃ３２２、Ａｃｔｉｏｎ処理結果Ｔｏｐｉｃ３２３、Ｓｕｂイベント情報通知Ｔｏｐｉｃ３２４を管理する。

Ｔｏｐｉｃ情報管理部３２０は、通信部３１１を介して受信したＰｕｂリクエストを解析し、対応するＴｏｐｉｃに対し、メッセージの登録を行う。また、Ｔｏｐｉｃ情報管理部３２０は、通信部３１１を介して受信したＳｕｂ開始リクエストを解析し、リクエストを送信したクライアントとの接続を確立する。

デバイス情報Ｔｏｐｉｃ３２１は、ＭＦＰ１１１のデバイス情報を登録するためのＴｏｐｉｃであり、ネットワークデバイス（ＭＦＰ１１１）をパブリッシャーとしてメッセージを受け取る第１メッセージ管理システムとして機能する。成功確認Ｔｏｐｉｃ３２２は、該ネットワークデバイスをサブスクライバーとしてメッセージの処理の成功を示すメッセージを配信するための第２メッセージ管理サービスとして機能する。すなわち、成功確認Ｔｏｐｉｃ３２２は、デバイス情報Ｔｏｐｉｃ３２１のＳｕｂｓｃｒｉｂｅｒの処理が成功したことをデバイス情報送信アプリケーション３００が確認するためのＴｏｐｉｃである。Ａｃｔｉｏｎ処理結果Ｔｏｐｉｃ３２３は、デバイス情報Ｔｏｐｉｃ３２１のＳｕｂｓｃｒｉｂｅｒの処理結果をＴｏｐｉｃイベント管理サービス１０２に伝えるためのＴｏｐｉｃである。Ｓｕｂイベント情報通知Ｔｏｐｉｃ３２４は、ＩｏＴ管理アプリケーション３１０のすべてのＴｏｐｉｃのＳｕｂイベントが登録されるＴｏｐｉｃである。

スクリプト管理サービス１０４は、スクリプト管理アプリケーション３３０を有する。スクリプト管理アプリケーション３３０は、スクリプト管理サービス１０４の記憶装置２０６に格納され、ＣＰＵ２０３によって実行される。スクリプト管理アプリケーション３３０は、通信部３３１、スクリプト管理部３６０を有する。

通信部３３１は、ネットワークインタフェース２０２を介して、ＩｏＴ管理アプリケーション３１０と通信を行う。スクリプト管理部３６０は、ＩｏＴ管理アプリケーション３１０のＴｏｐｉｃのＰｕｂイベントを受けて駆動するスクリプトを管理する。スクリプト管理部３６０は、即時処理Ａｃｔｉｏｎ３６１、非即時処理Ａｃｔｉｏｎ３６２を管理する。

即時処理Ａｃｔｉｏｎ３２１は、メッセージにエラーコードがあった場合に関係者に通知を行う処理を担当し、非即時処理Ａｃｔｉｏｎ３２２は、メッセージを加工せず、ストレージ環境などに保管する処理を行う。即時処理Ａｃｔｉｏｎ３６１は、デバイス情報Ｔｏｐｉｃ３２１に対するＰｕｂが行われたことを受けて駆動するスクリプトである。即時処理Ａｃｔｉｏｎ３６１は、デバイス情報Ｔｏｐｉｃ３２１に対するＳｕｂを開始し、Ｐｕｂされたメッセージを受信する。さらに、即時処理Ａｃｔｉｏｎ３６１は、受信したメッセージを解析し、エラーコードが含まれるなど即時対処を要すると判断した場合に、エラー通知などの処理を行う。そして、即時処理Ａｃｔｉｏｎ３６１は、スクリプト処理の結果をＰｕｂメッセージとして生成し、Ａｃｔｉｏｎ処理結果Ｔｏｐｉｃ３２３にＰｕｂする。

非即時処理Ａｃｔｉｏｎ３６２は、デバイス情報Ｔｏｐｉｃ３２１に対するＰｕｂが行われたことを受けて駆動するスクリプトである。非即時処理Ａｃｔｉｏｎ３６２は、デバイス情報Ｔｏｐｉｃ３２１に対するＳｕｂを開始し、Ｐｕｂされたメッセージを受信する。非即時処理Ａｃｔｉｏｎ３６２は、即時処理Ａｃｔｉｏｎ３６１とは異なり、メッセージの解析は行わず、受信したメッセージをストレージ環境などに保存する。そして、非即時処理Ａｃｔｉｏｎ３６２は、スクリプト処理の結果をＰｕｂメッセージとして生成し、Ａｃｔｉｏｎ処理結果Ｔｏｐｉｃ３２３にＰｕｂする。

Ｔｏｐｉｃイベント管理サービス１０２は、Ｔｏｐｉｃイベント管理アプリケーション３４０を有する。Ｔｏｐｉｃイベント管理アプリケーション３４０は、Ｔｏｐｉｃイベント管理サービス１０２の記憶装置２０６に格納され、ＣＰＵ２０３によって実行される。Ｔｏｐｉｃイベント管理アプリケーション３４０は、通信部３４１、メッセージ生成部３４２、メッセージ解析部３４３を有する。

通信部３４１は、ネットワークインタフェース２０２を介して、ＩｏＴ管理アプリケーション３１０、データベース管理アプリケーション３５０と通信を行う。メッセージ生成部３４２は、成功確認Ｔｏｐｉｃ３２２にＰｕｂするメッセージの生成を行う。さらにメッセージ生成部３０３は、通信部３１１を介して、成功確認Ｔｏｐｉｃ３２２へメッセージのＰｕｂを行う。

メッセージ解析部３４３は、通信部３４１を介して、Ｓｕｂイベント情報通知Ｔｏｐｉｃ３２４、Ａｃｔｉｏｎ処理結果Ｔｏｐｉｃ３２３とのＳｕｂを開始する。メッセージ解析部３４３は、通信部３４１を介して、Ｓｕｂイベント情報通知Ｔｏｐｉｃ３２４から受信したメッセージの解析を行い、即時処理Ａｃｔｉｏｎ３６１、非即時処理Ａｃｔｉｏｎ３６２がＳｕｂを開始したことを検知する。この際、メッセージ解析部３４３は、通信部３４１を介して、当該Ａｃｔｉｏｎ情報の登録をデータベース管理アプリケーション３５０に要求する。また、メッセージ解析部３４３は、通信部３４１を介して、Ａｃｔｉｏｎ処理結果Ｔｏｐｉｃ３２３から受信したメッセージの解析を行い、特定メッセージＩＤに紐づくＡｃｔｉｏｎの処理が完了したことを検知する。この際、メッセージ解析部３４３は、通信部３４１を介して、メッセージの管理情報（メッセージ情報）の登録をデータベース管理アプリケーション３５０に要求する。

また、メッセージ解析部３４３は、通信部３４１を介して、データベース管理アプリケーション３５０に、特定メッセージＩＤに紐づくＡｃｔｉｏｎの処理状況の要求を行う。メッセージ解析部３４３は、通信部３４１を介して、特定メッセージＩＤに紐づくＡｃｔｉｏｎの処理状況を受信し、すべてのＡｃｔｉｏｎが完了していると判断した場合、メッセージ生成部３４２にＰｕｂ要求を行う。

データベース管理アプリケーション３５０は、データベース管理サービス１０３の記憶装置２０６に格納され、ＣＰＵ２０３によって実行される。データベース管理アプリケーション３５０は、通信部３５１、データベース管理部３５２、オブジェクトデータベース３５３を有する。通信部３５１は、ネットワークインタフェース２０２を介して、Ｔｏｐｉｃイベント管理アプリケーション３４０と通信を行う。データベース管理部３５２は、オブジェクトデータベース３５３の管理を行う。データベース管理部３５２は、通信部３５１を介して、オブジェクトデータベース３５３のテーブル情報更新要求や、取得要求を受信する。データベース管理部３５２は、通信部３５１を介した要求を受けて、オブジェクトデータベース３５３に対し、テーブル情報更新操作やデータの取得処理を行い、通信部３５１を介して、処理結果を返す。

オブジェクトデータベース３５３は、ＮｏＳＱＬ型のデータベースである。オブジェクトデータベース３５３は、スクリプト管理部３６０のスクリプトの処理結果を管理するＡｃｔｉｏｎ情報テーブルと、デバイス情報Ｔｏｐｉｃ３２１のメッセージ情報を管理するメッセージ情報テーブルとを有する。
Ａｃｔｉｏｎ情報テーブルの一例を表１に示す。

ＡｃｔｉｏｎＩｄカラムは、スクリプト管理部３６０の各スクリプトを一意に識別するための値を格納するカラムである。Ｔｏｐｉｃカラムは、ＡｃｔｉｏｎＩｄに対応するスクリプトがＳｕｂを行っている登録先Ｔｏｐｉｃのキーを格納するカラムである。
メッセージ情報テーブルの一例を表２に示す。

ＭｅｓｓａｇｅＩｄカラムは、各メッセージを一意に識別する値を格納するカラムである。Ｔｏｐｉｃカラムは、ＭｅｓｓａｇｅＩｄに対応するＴｏｐｉｃの登録先を格納するカラムである。ＡｃｔｉｏｎＩｄカラムは、ＭｅｓｓａｇｅＩｄに紐づいた処理を行っているスクリプト管理部３６０のスクリプトを一意に識別する値を格納するカラムである。Ｒｅｓｕｌｔカラムは、ＡｃｔｉｏｎＩｄに対応するスクリプトの処理結果を示す値を格納するカラムである。「Ｓｕｃｃｅｓｓ」は、処理の成功、「Ｅｒｒｏｒ」は、処理の失敗、「Ｕｎｎｅｃｅｓｓａｒｙ」は、結果を無視しても構わない状態、空白は初期状態であることを示す。

［処理シーケンス］
図４は、実施例１のシステム全体の処理シーケンスを示す図である。
図４の処理シーケンスは、ＭＦＰ１１１のトナーカートリッジのエンプティエラーが発生してから、エラーに対する処理が完了したことをＭＦＰ１１１が検知するまでの処理シーケンスである。前提として、デバイス情報送信アプリケーション３００による成功確認Ｔｏｐｉｃ３２２からのメッセージのＳｕｂ、Ｔｏｐｉｃイベント管理アプリケーション３４０によるデバイス情報Ｔｏｐｉｃ３２１からのメッセージのＳｕｂが開始されているものとする。

Ｓ４００において、デバイス情報送信アプリケーション３００が有するデバイス情報管理部３０２が、トナーカートリッジのエンプティエラーを検知し、メッセージ生成部３０３がエラー情報のＰｕｂメッセージを生成する。そして、通信部３０１が、メッセージ生成部３０３が生成したＰｕｂメッセージを、デバイス情報Ｔｏｐｉｃ３２１にＰｕｂする。また、メッセージのＰｕｂが行われると同時に、再送判定部３０５が、Ｐｕｂのリトライを判断するための時刻カウントを開始する。Ｐｕｂされたメッセージは、ＩｏＴ管理アプリケーション３１０のＴｏｐｉｃ管理部３２０によって、デバイス情報Ｔｏｐｉｃ３２１に登録される。登録されるメッセージの内容に関して、図５を参照して説明する。

図５は、デバイス情報Ｔｏｐｉｃ３２１に登録されるメッセージの一例である。
メッセージ５００は、ｊｓｏｎ形式で構成されている。「ｍｅｓｓａｇｅＩｄ」は、メッセージ５００を一意に識別するＩＤであり、メッセージ生成部３０３が発行したＩＤである「ＭＥＳＳＡＧＥ００１」が記載されている。「ｔｏｐｉｃｓ」はメッセージの登録先を示す値であり、ＭＦＰ１１１のデバイス情報Ｔｏｐｉｃを示す「ＤｅｖｉｃｅＡ／ＤｅｖｉｃｅＩｎｆｏ」が記載されている。「ｅｖｅｎｔＴｙｐｅ」は、メッセージのイベント種別であり、カートリッジエラーを示す値が記載されている。「ｅｒｒｏｒＣｏｄｅ」は、エラーを一意に識別するＩＤであり、カートリッジのエンプティエラーを示す値が記載されている。

図４の説明に戻る。Ｓ４０１において、Ｔｏｐｉｃイベント管理アプリケーション３４０が有するメッセージ解析部３４３が、通信部３４１を介して、デバイス情報Ｔｏｐｉｃ３２１からメッセージ５００を受信する。続いて、Ｓ４０２において、Ｓ４００でデバイス情報Ｔｏｐｉｃ３２１にメッセージが登録されたことがスクリプト管理アプリケーション３３０に通知される。スクリプト管理アプリケーション３３０が有するスクリプト管理部３６０が、即時処理Ａｃｔｉｏｎ３６１と、非即時処理Ａｃｔｉｏｎ３６２とを駆動させる。そして、即時処理Ａｃｔｉｏｎ３６１が、デバイス情報Ｔｏｐｉｃ３２１に対し、Ｓｕｂの開始リクエストを行い、デバイス情報Ｔｏｐｉｃ３２１からメッセージの受信が開始される。

Ｓ４０３において、Ｓ４０２で即時処理Ａｃｔｉｏｎ３６１がＳｕｂを開始したことに応じて、Ｔｏｐｉｃ情報管理部３２０が、即時処理Ａｃｔｉｏｎ３６１がＳｕｂを開始したことをＳｕｂイベント情報通知Ｔｏｐｉｃ３２４にメッセージとして登録する。このメッセージの内容に関して、図６を参照して説明する。

図６は、Ｓｕｂイベント情報通知Ｔｏｐｉｃ３２４に登録されるメッセージの一例である。
図６（Ａ）のメッセージ６００は、即時処理Ａｃｔｉｏｎ３６１のＳｕｂ開始イベントを示し、ｊｓｏｎ形式で構成されている。「ｃｌｉｅｎｔＩｄ」は、Ｓｕｂを開始したクライアントを一意に特定するＩＤである。なお、この例では、即時処理Ａｃｔｉｏｎ３６１のＣｌｉｅｎｔＩｄは「ＩｍｍｅｄｉａｔｅＡｃｔｉｏｎ」、非即時処理Ａｃｔｉｏｎ３６２のＣｌｉｅｎｔＩｄは「ＳｔｏｒｅＡｃｔｉｏｎ」であるものとする。メッセージ６００の「ｃｉｌｅｎｔＩｄ」は、即時処理Ａｃｔｉｏｎ３６１を示す「ＩｍｍｅｄｉａｔｅＡｃｔｉｏｎ」である。「ｔｉｍｅＳｔａｍｐ」は、イベント発生時刻を示す。「ｅｖｅｎｔＴｙｐｅ」はイベントの種別を示し、Ｓｕｂの開始を示すｓｕｂｓｃｒｉｂｅｄが記載されている。「ｔｏｐｉｃｓ」は、イベントが発生した登録先を示す値であり、ＭＦＰ１１１のデバイス情報Ｔｏｐｉｃを示す「ＤｅｖｉｃｅＡ／ＤｅｖｉｃｅＩｎｆｏ」が記載されている。

図６（Ｂ）のメッセージ６０１は、非即時処理Ａｃｔｉｏｎ３６１のＳｕｂ開始イベントを示し、ｊｓｏｎ形式で構成されている。メッセージ６０１の「ｃｉｌｅｎｔＩｄ」は、非即時処理Ａｃｔｉｏｎ３６２を示す「ＳｔｏｒｅＡｃｔｉｏｎ」である。その他の要素に関しては、メッセージ６００に準じているので、詳細な説明は割愛する。

図４の説明に戻る。Ｓ４０４において、Ｔｏｐｉｃイベント管理アプリケーション３４０が有するメッセージ解析部３４３が、通信部３４１を介して、Ｓｕｂイベント情報通知Ｔｏｐｉｃ３２４からメッセージ６００を受信する。メッセージ解析部３４３は、受信したメッセージ６００を解析することによって、即時処理Ａｃｔｉｏｎ３６１がデバイス情報Ｔｏｐｉｃ３２１からＳｕｂを開始したことを検知する。

Ｓ４０５において、メッセージ解析部３４３が、通信部３４１を介して、データベース管理アプリケーション３５０に、即時処理Ａｃｔｉｏｎ３６１が処理を開始した旨を送信し、情報の更新を要求する。データベース管理アプリケーション３５０が有するデータベース管理部３５２が、通信部３５１を介して更新要求を受信する。データベース管理部３５２は、受信した更新要求に従って、オブジェクトデータベース３５３のＡｃｔｉｏｎ情報テーブルとメッセージ情報テーブルを更新する。
表３は、実施例１におけるＳ４０５の処理が完了した時のＡｃｔｉｏｎ情報テーブルを示す。

ＡｃｔｉｏｎＩｄカラムには、即時処理Ａｃｔｉｏｎ３６１のＡｃｔｉｏｎＩｄである「ＩｍｍｅｄｉａｔｅＡｃｔｉｏｎ」が格納される。Ｔｏｐｉｃカラムには、即時処理ＡｃｔｉｏｎがＳｕｂを開始したＴｏｐｉｃであるデバイス情報Ｔｏｐｉｃ３２１を示す「ＤｅｖｉｃｅＡ／ＤｅｖｉｃｅＩｎｆｏ」が格納される。
表４は、実施例１におけるＳ４０５の処理が完了した時のメッセージ情報テーブルを示す。

ＭｅｓｓａｇｅＩｄカラムには、処理結果に対応するＭｅｓｓａｇｅＩｄである「ＭＥＳＳＡＧＥ００１」が格納される。Ｔｏｐｉｃカラムには、ＭｅｓｓａｇｅＩｄに対応するＴｏｐｉｃの登録先である「ＤｅｖｉｃｅＡ／ＤｅｖｉｃｅＩｎｆｏ」が格納される。ＡｃｔｉｏｎＩｄカラムには、即時処理Ａｃｔｉｏｎ３６１のＡｃｔｉｏｎＩｄである「ＩｍｍｅｄｉａｔｅＡｃｔｉｏｎ」が格納される。Ｒｅｓｕｌｔカラムは、処理初期状態のため空白となっている。なお、Ａｃｔｉｏｎがユースケースにおいて重要なＡｃｔｉｏｎでない場合は、この時点で、Ｒｅｓｕｌｔを「Ｕｎｎｅｃｅｓｓａｒｙ」の値にする。なお、即時処理Ａｃｔｉｏｎ３６１、非即時処理Ａｃｔｉｏｎ３６２は、ユースケースにおいて重要なＡｃｔｉｏｎであるため、Ｒｅｓｕｌｔは「Ｕｎｎｅｃｅｓｓａｒｙ」に設定されない。

図４の説明に戻る。Ｓ４０６において、非即時処理Ａｃｔｉｏｎ３６２が、デバイス情報Ｔｏｐｉｃ３２１に対し、Ｓｕｂの開始リクエストを行う。これにより、デバイス情報Ｔｏｐｉｃ３２１からメッセージの受信が開始される。Ｓ４０６で非即時処理Ａｃｔｉｏｎ３６２がＳｕｂを開始したことに応じて、Ｓ４０７において、Ｔｏｐｉｃ情報管理部３２０が、その旨をＳｕｂイベント情報通知Ｔｏｐｉｃ３２４にメッセージとして登録する。登録されるメッセージは、図６（Ｂ）のメッセージ６０１である。

Ｓ４０８において、Ｔｏｐｉｃイベント管理アプリケーション３４０が有するメッセージ解析部３４３が、通信部３４１を介して、デバイス情報Ｔｏｐｉｃ３２１からメッセージ６０１を受信する。メッセージ解析部３４３は、受信したメッセージ６０１を解析することによって、非即時処理Ａｃｔｉｏｎ３６２がデバイス情報Ｔｏｐｉｃ３２１からＳｕｂを開始したことを検知する。

Ｓ４０９において、メッセージ解析部３４３が、通信部３４１を介して、データベース管理アプリケーション３５０に、非即時処理Ａｃｔｉｏｎ３６２が処理を開始した旨をＡｃｔｉｏｎ情報更新要求として送信する。データベース管理アプリケーション３５０が有するデータベース管理部３５２は、通信部３５１を介して、Ａｃｔｉｏｎ情報更新要求を受信する。そして、データベース管理部３５２は、Ａｃｔｉｏｎ情報更新要求に従って、オブジェクトデータベース３５３のＡｃｔｉｏｎ情報テーブルを更新する。
表５は、実施例１におけるＳ４０９の処理が完了した時のＡｃｔｉｏｎ情報テーブルを示す。

ＡｃｔｉｏｎＩｄカラムには、非即時処理Ａｃｔｉｏｎ３６２のＡｃｔｉｏｎＩｄである「ＳｔｏｒｅＡｃｔｉｏｎ」が格納される。Ｔｏｐｉｃカラムには、非即時処理Ａｃｔｉｏｎ３６２がＳｕｂを開始したＴｏｐｉｃであるデバイス情報Ｔｏｐｉｃ３２１を示す「ＤｅｖｉｃｅＡ／ＤｅｖｉｃｅＩｎｆｏ」が格納される。つまり、Ｓ４０９の処理が完了した時点では、Ａｃｔｉｏｎ情報テーブルに、デバイス情報Ｔｏｐｉｃ３２１のＳｕｂｓｃｒｉｂｅｒとして、即時処理Ａｃｔｉｏｎ３６１と非即時処理Ａｃｔｉｏｎ３６２とが登録されている。
表６は、実施例１におけるＳ４０９の処理が完了した時のメッセージ情報テーブルを示す。

ＭｅｓｓａｇｅＩｄカラムには、処理結果に対応するＭｅｓｓａｇｅＩｄである「ＭＥＳＳＡＧＥ００１」が格納される。Ｔｏｐｉｃカラムには、ＭｅｓｓａｇｅＩｄに対応するＴｏｐｉｃの登録先である「ＤｅｖｉｃｅＡ／ＤｅｖｉｃｅＩｎｆｏ」が格納される。ＡｃｔｉｏｎＩｄカラムには、非即時処理Ａｃｔｉｏｎ３６２のＡｃｔｉｏｎＩｄである「ＳｔｏｒｅＡｃｔｉｏｎ」が格納される。Ｒｅｓｕｌｔカラムは、処理初期状態のため空白となっている。

図４の説明に戻る。Ｓ４１０において、即時処理Ａｃｔｉｏｎ３６１が、デバイス情報Ｔｏｐｉｃ３２１からメッセージ５００（第１メッセージ）を受信する。即時処理Ａｃｔｉｏｎ３６１が、受信したメッセージ５００を解析し、即時処理を要するかを判定し、所定の処理を行う。例えば、即時処理Ａｃｔｉｏｎ３６１は、トナーカートリッジのエンプティエラーを受けて、関係者へのメール通知処理を行う処理を行う。即時処理の判定および処理の内容に関しては、特に限定しない。

Ｓ４１１において、即時処理Ａｃｔｉｏｎ３６１が、処理の結果をＰｕｂメッセージとして生成し、Ａｃｔｉｏｎ処理結果Ｔｏｐｉｃ３２３にＰｕｂする。Ｐｕｂされたメッセージは、ＩｏＴ管理アプリケーション３１０のＴｏｐｉｃ管理部３２０によって、Ａｃｔｉｏｎ処理結果Ｔｏｐｉｃ３２３に登録される。すなわち、Ａｃｔｉｏｎ処理結果Ｔｏｐｉｃ３２３は、以下の処理を行う第３メッセージ管理サービスとして機能する。Ａｃｔｉｏｎ処理結果Ｔｏｐｉｃ３２３は、即時処理Ａｃｔｉｏｎ３６１をパブリッシャーとして、第１メッセージ（メッセージ５００）の即時処理Ａｃｔｉｏｎ３６１での処理結果に対応するメッセージを受け取る。Ａｃｔｉｏｎ処理結果Ｔｏｐｉｃ３２３に登録されるメッセージの内容に関して、図８を参照して説明する。なお、Ｓ４１１において、即時処理Ａｃｔｉｏｎ３６１は、処理に成功したことをＰｕｂしたものとする。

図８は、Ａｃｔｉｏｎ処理結果Ｔｏｐｉｃ３２３に登録されるメッセージの一例である。
図８（Ａ）のメッセージ８００は、ｊｓｏｎ形式で構成されている。「ｃｌｉｅｎｔＩｄ」は、Ａｃｔｉｏｎを一意に識別するＩＤである。メッセージ６００の「ｃｉｌｅｎｔＩｄ」は、非即時処理Ａｃｔｉｏｎ３６２を示す「ＩｍｍｅｄｉａｔｅＡｃｔｉｏｎ」である。「ｔｏｐｉｃｓ」は、Ａｃｔｉｏｎが処理を行う際の、メッセージを受信した登録先を示すキーである。「ｔｏｐｉｃｓ」には、ＭＦＰ１１１のデバイス情報Ｔｏｐｉｃを示す「ＤｅｖｉｃｅＡ／ＤｅｖｉｃｅＩｎｆｏ」が記載されている。「ｒｅｓｕｌｔ」は、処理の結果を示す値である。「ｍｅｓｓａｇｅＩｄ」は、メッセージ５００を一意に識別するＩＤである。「ｒｅｓｕｌｔ」には、メッセージ５００の「ｍｅｓｓａｇｅＩｄ」がそのまま転載される。

図８（Ｂ）のメッセージ８０１は、非即時処理Ａｃｔｉｏｎ３６１のＳｕｂ開始イベントを示し、ｊｓｏｎ形式で構成されている。メッセージ６０１の「ｃｉｌｅｎｔＩｄ」は、非即時処理Ａｃｔｉｏｎ３６２を示す「ＳｔｏｒｅＡｃｔｉｏｎ」である。その他の要素に関しては、メッセージ８００に準じているので、詳細な説明は割愛する。

図４の説明に戻る。Ｓ４１２において、Ｔｏｐｉｃイベント管理アプリケーション３４０が有するメッセージ解析部３４３が、Ａｃｔｉｏｎ処理結果Ｔｏｐｉｃ３２３からメッセージ８００を受信する。メッセージ解析部３４３は、受信したメッセージ８００の解析を行い、即時処理Ａｃｔｉｏｎ３６１がＭＥＳＳＡＧＥ００１に紐づく処理に成功したことを検知する。

Ｓ４１３において、メッセージ解析部３４３が、Ｓ４１２での解析結果に従い、データベース管理アプリケーション３５０にデータの更新依頼を行う。データベース管理アプリケーション３５０が有するデータベース管理部３５２は、更新依頼を受けて、オブジェクトデータベース３５３の更新を行う。即時処理Ａｃｔｉｏｎ３６１のＭＥＳＳＡＧＥ００１に紐づく処理が完了したことが、メッセージ情報テーブルに反映される。すなわち、Ｔｏｐｉｃイベント管理アプリケーション３４０は、デバイス情報Ｔｏｐｉｃ３２１から配信された第１メッセージの第１サービス（即時処理Ａｃｔｉｏｎ３６１）での処理の完了に応じ、以下の処理を行う第１登録手段として機能する。Ｔｏｐｉｃイベント管理アプリケーション３４０は、即時処理Ａｃｔｉｏｎ３６１での第１メッセージの処理結果をデータベース管理サービス１０３に登録する。
表７は、実施例１におけるＳ４１３の処理が完了した時のメッセージ情報テーブルを示す。

表７では、１行目のＲｅｓｕｌｔカラムの処理結果が、空白から「Ｓｕｃｃｅｓｓ」に更新されている。その他の要素に関しては、表６と同様であるので、詳細な説明は割愛する。
Ｓ４１４において、Ｔｏｐｉｃイベント管理アプリケーション３４０が、即時処理Ａｃｔｉｏｎ３６１、非即時処理Ａｃｔｉｏｎ３６２の処理状況の確認と、処理の完了の判定を行う。本処理に関しては、図７のフローチャートを参照して説明する。

図７は、Ｔｏｐｉｃイベント管理アプリケーション３４０によるＡｃｔｉｏｎ処理状況の判定処理の一例を説明するフローチャートである。
Ｓ７００において、Ｔｏｐｉｃイベント管理アプリケーション３４０が、通信部３４１を介して、データベース管理アプリケーション３５０からＡｃｔｉｏｎ情報を取得する。Ｔｏｐｉｃイベント管理アプリケーション３４０は、表３に示すＡｃｔｉｏｎ情報を取得する。

Ｓ７０１において、メッセージ解析部３４３が、Ｓ７００で取得したＡｃｔｉｏｎ情報を参照して、デバイス情報Ｔｏｐｉｃ３２１のＳｕｂｓｃｒｉｂｅｒとなっているＡｃｔｉｏｎを特定する。デバイス情報Ｔｏｐｉｃ３２１のＳｕｂｓｃｒｉｂｅｒが即時処理Ａｃｔｉｏｎ３６１と非即時処理Ａｃｔｉｏｎ３６２であることが特定される。

Ｓ７０２において、メッセージ解析部３４３が、通信部３４１を介して、データベース管理アプリケーション３５０からメッセージ情報を取得する。取得されるメッセージ情報は、Ｓ７０１で特定されたＡｃｔｉｏｎに限定される。即時処理Ａｃｔｉｏｎ３６１と非即時処理Ａｃｔｉｏｎ３６２のメッセージ情報が取得される。

Ｓ７０３において、メッセージ解析部３４３が、Ｓ７０２で取得したメッセージ情報を参照して、Ｓ７０１で特定したＡｃｔｉｏｎの処理のうち、予め決められた重要なＡｃｔｉｏｎが完了しているかを判定する。具体的には、メッセージ解析部３４３は、メッセージ情報の「Ｒｅｓｕｌｔ」を参照して判定を行う。「Ｒｅｓｕｌｔ」に空白の値が存在する場合、あるいは要素が見つからなかった場合、メッセージ解析部３４３は、まだ重要なＡｃｔｉｏｎが完了していないと判断して、処理を終了する。「Ｒｅｓｕｌｔ」に空白の値が存在しない場合、メッセージ解析部３４３は、重要なＡｃｔｉｏｎが完了していると判断して、処理がＳ７０４に進む。Ｓ７０４において、Ｔｏｐｉｃイベント管理アプリケーション３４０が有するメッセージ生成部３４２が、重要なＡｃｔｉｏｎの処理が成功したことを示すＰｕｂメッセージを生成する。

図４の説明に戻る。Ｓ４１４における処理が完了した時点では、メッセージ情報は、表７が示す通りであり、非即時処理Ａｃｔｉｏｎ３６２の「Ｒｅｓｕｌｔ」が空白であるので、重要なＡｃｔｉｏｎが完了していないと判断される。Ｓ４１５において、非即時処理Ａｃｔｉｏｎ３６２が、デバイス情報Ｔｏｐｉｃ３２１からメッセージ５００を受信する。非即時処理Ａｃｔｉｏｎ３６２は、受信したメッセージ５００を、例えばＡｍａｚｏｎＳ３やＡｍａｚｏｎ Ｋｉｎｅｓｉｓストリームなどに送信し、メッセージの保管処理を行うが、処理の内容に関しては、特に限定しない。

Ｓ４１６において、非即時処理Ａｃｔｉｏｎ３６２が、処理の結果をＰｕｂメッセージとして生成し、Ａｃｔｉｏｎ処理結果Ｔｏｐｉｃ３２３にＰｕｂする。すなわち、Ａｃｔｉｏｎ処理結果Ｔｏｐｉｃ３２３は、非即時処理Ａｃｔｉｏｎ３６２をパブリッシャーとして、第１メッセージの非即時処理Ａｃｔｉｏｎ３６２での処理結果に対応するメッセージを受け取る。具体的には、Ｐｕｂされたメッセージは、ＩｏＴ管理アプリケーション３１０が有するＴｏｐｉｃ管理部３２０によって、Ａｃｔｉｏｎ処理結果Ｔｏｐｉｃ３２３に登録される。なお、Ｓ４１６において、非即時処理Ａｃｔｉｏｎ３６２は、処理に成功したことを示すメッセージをＰｕｂしたものとし、Ａｃｔｉｏｎ処理結果Ｔｏｐｉｃ３２３に登録されたメッセージは、メッセージ８０１とする。

Ｓ４１７において、Ｔｏｐｉｃイベント管理アプリケーション３４０が有するメッセージ解析部３４３が、Ａｃｔｉｏｎ処理結果Ｔｏｐｉｃ３２３からメッセージ８０１を受信する。メッセージ解析部３４３は、受信したメッセージ８０１の解析を行い、非即時処理Ａｃｔｉｏｎ３６１がＭＥＳＳＡＧＥ００１に紐づく処理に成功したことを検知する。また、メッセージ解析部３４３は、メッセージ８０１を解析することで、非即時処理Ａｃｔｉｏｎ３６２がＭＥＳＳＡＧＥ００１に紐づく処理に成功したことを検知する。

Ｓ４１８において、メッセージ解析部３４３が、Ｓ４１６で解析した結果に従い、Ｔｏデータベース管理アプリケーション３５０にデータの更新依頼を行う。データベース管理アプリケーション３５０が有するデータベース管理部３５２は、更新依頼を受けて、オブジェクトデータベース３５３の更新を行う。非即時処理Ａｃｔｉｏｎ３６２のＭＥＳＳＡＧＥ００１に紐づく処理が完了したことが、メッセージ情報テーブルに反映される。すなわち、Ｔｏｐｉｃイベント管理アプリケーション３４０は、デバイス情報Ｔｏｐｉｃ３２１により配信された第１メッセージの第２サービス（非即時処理Ａｃｔｉｏｎ３６２）での処理の完了に応じて、以下の処理を行う第２登録手段として機能する。Ｔｏｐｉｃイベント管理アプリケーション３４０は、非即時処理Ａｃｔｉｏｎ３６２での第１メッセージの処理結果をデータベース管理サービス１０３に登録する。
表８は、実施例１におけるＳ４１８の処理が完了した時のメッセージ情報テーブルを示す。

表８に示すメッセージ情報テーブルでは、２行目のＲｅｓｕｌｔカラムの処理結果が、空白から「Ｓｕｃｃｅｓｓ」に更新されている。

Ｓ４１９において、Ｓ４１４と同様に、図７のフローチャートの処理が実行される。つまり、Ｔｏｐｉｃイベント管理アプリケーション３４０が、即時処理Ａｃｔｉｏｎ３６１、非即時処理Ａｃｔｉｏｎ３６２の処理状況の判定処理を実行する。Ｓ４１９における処理が完了した時点では、メッセージ情報は、表８に示す通りであり、「Ｒｅｓｕｌｔ」が空白のＡｃｔｉｏｎは存在しない。したがって、重要なＡｃｔｉｏｎが完了していると判定される。その結果、メッセージ生成部３４２が、重要なＡｃｔｉｏｎの処理が成功したことを示すＰｕｂメッセージを生成する。この例では、デバイス情報Ｔｏｐｉｃ３２１の全てのＳｕｂｓｃｒｉｂｅｒでの処理結果が成功を示している場合に、重要なＡｃｔｉｏｎの処理が成功したことを示すＰｕｂメッセージが生成される。もちろん、デバイス情報Ｔｏｐｉｃ３２１の予め決められた一部のＳｕｂｓｃｒｉｂｅｒでの処理が成功した場合に、重要なＡｃｔｉｏｎの処理が成功したことを示すＰｕｂメッセージが生成されるようにしてもよい。

Ｓ４２０において、メッセージ生成部３４２が、Ｓ４１９で生成されたＰｕｂメッセージを、通信部３４１を介して、成功確認Ｔｏｐｉｃ３２２にＰｕｂする。Ｐｕｂされたメッセージは、ＩｏＴ管理アプリケーション３１０のＴｏｐｉｃ管理部３２０によって、成功確認Ｔｏｐｉｃ３２２に登録される。すなわち、Ｔｏｐｉｃイベント管理アプリケーション３４０は、第１メッセージの処理結果に従い、以下の処理を行う配信手段として機能する。Ｔｏｐｉｃイベント管理アプリケーション３４０は、成功確認Ｔｏｐｉｃ３２２に対し、第１メッセージの処理の成功を示す第２メッセージを配信する。成功確認Ｔｏｐｉｃ３２２に登録される第２メッセージに関して、図９を参照して説明する。

図９は、成功確認Ｔｏｐｉｃ３２２に登録されるメッセージの一例である。
メッセージ９００は、ｊｓｏｎ形式で構成されている。「ｍｅｓｓａｇｅＩｄ」には、図５のメッセージ５００を示す「ＭＥＳＳＡＧＥ００１」が記載されている。「ｒｅｓｕｌｔ」は、処理の結果を示す値である。図９に示す例では、「ｒｅｓｕｌｔ」には、ＳｕｂｓｃｒｉｂｅｒとしてのＡｃｔｉｏｎでのメッセージ５００の処理が全て成功したことを示す「Ｓｕｃｃｅｓｓ」が記載されている。

図４の説明に戻る。Ｓ４２１において、デバイス管理アプリケーション３００のメッセージ生成部３０４が、通信部３０１を介して、成功確認Ｔｏｐｉｃ３２２からメッセージ９００を受信する。メッセージ解析部３４３は、受信したメッセージ９００を解析することで、Ｓ４００で発行したメッセージＩＤである「ＭＥＳＳＡＧＥ００１」に関連するＡｃｔｉｏｎが全て正常に成功したと判断する。「ＭＥＳＳＡＧＥ００１」に関連するＡｃｔｉｏｎがすべて正常に成功したので、再送判定部３０５が、Ｓ４００で開始した時刻カウントのカウントアップを終了する。これにより、デバイス管理アプリケーション３００は、Ｓ４００を再度実行する必要がないと判断する。なお、Ｓ４００からＳ４２１の処理が、リトライの所定時間を超えていないものとする。Ｓ４００からＳ４２１の処理の途中で、リトライの所定時間を超えた場合、Ｓ４００の処理が再度実行される。実施例１の情報処理システムによれば、１つのＰｕｂｌｉｓｈｅｒがメッセージを送信するＴｏｐｉｃに複数のＳｕｂｓｃｒｉｂｅｒが存在する場合でも、疎結合性を確保しつつ、複数のＳｕｂｓｃｒｉｂｅｒに適切にメッセージを届けることができる。

（実施例２)
実施例２の情報処理システムは、実施形態２では、ＷｅｂサービスとしてのＴｏｐｉｃイベント管理サービス１０２を稼働させないことで、運用コストの削減を図る。

図１０は、実施例２の全体システム構成を示す図である。
ＩｏＴ管理サービス１０１、データベース管理サービス１０３、スクリプト管理サービス１０４、ＭＦＰ１１１は、ネットワーク１２０を介して接続されている。その他の要素に関しては、図１と同様のため、詳細な説明は割愛する。

図１１は、実施例２のソフトウェア構成を示す図である。
図３を参照して説明したシステムの要素と同様の要素については同じ符号を付し、詳細な説明は割愛する。

データベース管理アプリケーション１１００は、データベース管理サービス１０３の記憶装置２０６に格納され、ＣＰＵ２０３によって実行される。データベース管理アプリケーション１１００は、通信部１１０１、データベース管理部３５２、オブジェクトデータベース３５３を有する。通信部１１０１は、ネットワークインタフェース２０２を介して、スクリプト管理アプリケーション３３０と通信を行う。

ＩｏＴ管理アプリケーション３１０のＴｏｐｉｃ情報管理部１１１０は、デバイス情報Ｔｏｐｉｃ３２１、成功確認Ｔｏｐｉｃ３２２、Ｓｕｂイベント情報通知Ｔｏｐｉｃ３２４を有する。

スクリプトアプリケーション３３０のスクリプト管理部１１２０は、即時処理Ａｃｔｉｏｎ１１２１、非即時処理Ａｃｔｉｏｎ１１２２、Ｓｕｂイベント解析Ａｃｔｉｏｎ１１２３を管理する。即時処理Ａｃｔｉｏｎ１１２１は、図３の即時処理Ａｃｔｉｏｎ３６１の機能に加えて、図７を参照して説明したＡｃｔｉｏｎ処理状況の判定処理を行うことが可能である。また、非即時処理Ａｃｔｉｏｎ１１２２は、図３の非即時処理Ａｃｔｉｏｎ３６２の機能に加えて、図７を参照して説明したＡｃｔｉｏｎ処理状況の判定処理を行うことが可能である。

Ｓｕｂイベント解析Ａｃｔｉｏｎ１１２３は、Ｓｕｂイベント情報通知Ｔｏｐｉｃ３２４に対するＰｕｂが行われたことを受けて駆動するスクリプトである。Ｓｕｂイベント解析Ａｃｔｉｏｎ１１２３は、Ｓｕｂイベント情報通知Ｔｏｐｉｃ３２４に対するＳｕｂを開始し、Ｐｕｂされたメッセージを受信する。Ｓｕｂイベント解析Ａｃｔｉｏｎ１１２３は、受信したメッセージの解析を行い、即時処理Ａｃｔｉｏｎ１１２１、非即時処理Ａｃｔｉｏｎ１１２２がＳｕｂを開始したことを検知する。そして、Ｓｕｂイベント解析Ａｃｔｉｏｎ１１２３は、Ａｃｔｉｏｎ情報の登録をデータベース管理アプリケーション１１００に要求する。

図１２は、実施例２のシステム全体の処理シーケンスを示す図である。
図１２の処理シーケンスの前提として、デバイス情報送信アプリケーション３００による成功確認Ｔｏｐｉｃ３２２からのメッセージのＳｕｂが開始されているものとする。Ｓ１２００の処理は、図４のＳ４００の処理と同様であるので、詳細な説明は割愛する。また、Ｓ１２０１乃至Ｓ１２０２の処理は、図４のＳ４０２乃至Ｓ４０３の処理と同様であるので、詳細な説明は割愛する。

Ｓ１２０３において、Ｓ１２０２でＳｕｂイベント情報通知Ｔｏｐｉｃ３２４にメッセージが登録されたことが、スクリプト管理アプリケーション３３０に通知される。スクリプト管理アプリケーション３３０のスクリプト管理部１１２０は、この通知を受けて、Ｓｕｂイベント解析Ａｃｔｉｏｎ１１２３を駆動させる。Ｓｕｂイベント解析Ａｃｔｉｏｎ１１２３は、Ｓｕｂイベント情報通知Ｔｏｐｉｃ３２４に対し、Ｓｕｂの開始リクエストを行い、Ｓｕｂイベント情報通知Ｔｏｐｉｃ３２４からのメッセージの受信を開始する。Ｓ１２０４において、Ｓｕｂイベント解析Ａｃｔｉｏｎ１１２３が、Ｓｕｂイベント情報通知Ｔｏｐｉｃ３２４からメッセージ６００を受信する。Ｓｕｂイベント解析Ａｃｔｉｏｎ１１２３は、受信したメッセージ６００を解析することで、即時処理Ａｃｔｉｏｎ１１２１がデバイス情報Ｔｏｐｉｃ３２１からＳｕｂを開始したことを検知する。

Ｓ１２０５において、Ｓｕｂイベント解析Ａｃｔｉｏｎ１１２３が、データベース管理アプリケーション３５０に、即時処理Ａｃｔｉｏｎ１１２１が処理を開始したことを示すメッセージを送信することで、情報の更新要求を行う。データベース管理アプリケーション３５０のデータベース管理部３５２は、通信部３５１を介して、情報の更新要求を受信し、オブジェクトデータベース３５３のＡｃｔｉｏｎ情報テーブルを更新する。Ｓ１２０５の処理が完了した時のＡｃｔｉｏｎ情報テーブルの状態は表３の通りとなる。

Ｓ１２０６乃至Ｓ１２０７の処理は、図４のＳ４０６乃至Ｓ４０７の処理と同様であるので、詳細な説明は割愛する。Ｓ１２０８において、Ｓｕｂイベント解析Ａｃｔｉｏｎ１１２３が、Ｓｕｂイベント情報通知Ｔｏｐｉｃ３２４からメッセージ６０１を受信する。Ｓｕｂイベント解析Ａｃｔｉｏｎ１１２３は、受信したメッセージ６０１を解析することで、非即時処理Ａｃｔｉｏｎ１１２２がデバイス情報Ｔｏｐｉｃ３２１からＳｕｂを開始したことを検知する。

Ｓ１２０９において、Ｓｕｂイベント解析Ａｃｔｉｏｎ１１２３が、データベース管理アプリケーション３５０に、非即時処理Ａｃｔｉｏｎ１１２２が処理を開始したことを示すメッセージを送信することで、情報の更新要求を行う。データベース管理アプリケーション３５０のデータベース管理部３５２は、通信部３５１を介して、情報の更新要求を受信し、オブジェクトデータベース３５３のＡｃｔｉｏｎ情報テーブルを更新する。Ｓ１２０９の処理が完了した時のＡｃｔｉｏｎ情報テーブルの状態は表５の通りとなる。

Ｓ１２１０の処理は、図４のＳ４１０の処理と同様であるので、詳細な説明は割愛する。Ｓ１２１１において、即時処理Ａｃｔｉｏｎ１１２１が、処理の結果をデータベース管理アプリケーション３５０に送信することで、情報の更新要求を行う。データベース管理アプリケーション３５０のデータベース管理部３５２は、通信部３５１を介して、情報の更新要求を受信し、オブジェクトデータベース３５３のメッセージ情報テーブルを更新する。すなわち、即時処理Ａｃｔｉｏｎ１１２１自身が、第１登録手段として、即時処理Ａｃｔｉｏｎ１１２１での処理結果をデータベース管理サービス１０３に登録する。表９は、Ｓ１２１１の処理が完了した時のメッセージ情報テーブルを示す。

Ｓ１２１２において、即時処理Ａｃｔｉｏｎ１１２１が、図７を参照して説明したＡｃｔｉｏｎ処理状況の判定処理を実行する。Ｓ１２１２の処理の時点では、メッセージ情報は、表９の通りである。非即時処理Ａｃｔｉｏｎの情報が登録されていない。したがって、Ａｃｔｉｏｎ処理状況の判定処理において、重要なＡｃｔｉｏｎが完了していないと判断される。Ｓ１２１３の処理は、図４のＳ４１５の処理と同様であるので、詳細な説明は割愛する。

Ｓ１２１４において、非即時処理Ａｃｔｉｏｎ１１２２が、処理結果をデータベース管理アプリケーション３５０に送信することで、情報の更新要求を行う。データベース管理アプリケーション３５０のデータベース管理部３５２は、通信部３５１を介して、情報の更新要求を受信し、オブジェクトデータベース３５３のメッセージ情報テーブルを更新する。すなわち、非即時処理Ａｃｔｉｏｎ１１２２自身が、第２登録手段として、非即時処理Ａｃｔｉｏｎ１１２２での処理結果をデータベース管理サービス１０３に登録する。Ｓ１２１４の処理が完了した時のメッセージ情報テーブルの状態は、表８の通りとなる。

Ｓ１２１５において、非即時処理Ａｃｔｉｏｎ１１２２が、図７を参照して説明したＡｃｔｉｏｎ処理状況の判定処理を実行する。Ｓ１２１５の処理の時点では、メッセージ情報は、表８の通りである。「Ｒｅｓｕｌｔ」が空白のＡｃｔｉｏｎは存在しないので、重要なＡｃｔｉｏｎが完了していると判断される。したがって、非即時処理Ａｃｔｉｏｎ１１２２が、重要なＡｃｔｉｏｎの処理が成功したことを示すＰｕｂメッセージを生成する。Ｓ１２１６において、Ｔｏｐｉｃイベント管理アプリケーション３４０が有するメッセージ生成部３４２が、Ｓ１２１５で生成されたＰｕｂメッセージを、通信部３４１を介して、成功確認Ｔｏｐｉｃ３２２にＰｕｂする。Ｓ１２１７の処理は、図４のＳ４２１の処理と同様であるので、説明は割愛する。実施例２の情報処理システムによれば、Ｔｏｐｉｃイベント管理サービス１０２を稼働させずに、実施例１の情報処理システムと同様の効果を得ることができる。

（実施例３）
実施例３の情報処理システムは、Ｔｏｐｉｃイベント管理サービス１０２、データベース管理サービス１０３を稼働させずに、実施例１と同様の効果を得る。

図１３は、実施例３の全体システム構成を示す図である。
ＩｏＴ管理サービス１０１、スクリプト管理サービス１０４、ＭＦＰ１１１は、ネットワーク１２０を介して接続されている。その他の要素に関しては、図１と同様のため、詳細な説明は割愛する。

図１４は、実施例３のソフトウェア構成を示す図である。
図３を参照して説明したシステムの要素と同様の要素については同じ符号を付し、詳細な説明は割愛する。
ＩｏＴ管理アプリケーション３１０が有するＴｏｐｉｃ情報管理部１４００は、デバイス情報Ｔｏｐｉｃ３２１、成功確認Ｔｏｐｉｃ３２２、非即時処理Ｔｏｐｉｃ１４０１を管理する。非即時処理Ｔｏｐｉｃ１４０１は、非即時処理Ａｃｔｉｏｎ１４１２にデバイス情報を伝えるためのＴｏｐｉｃである。

スクリプト管理アプリケーション１１１０が有するスクリプト管理部１４１０は、即時処理Ａｃｔｉｏｎ１４１１、非即時処理Ａｃｔｉｏｎ１４１２を管理する。即時処理Ａｃｔｉｏｎ１４１１は、スクリプト処理の結果をＰｕｂメッセージとして生成し、非即時処理Ｔｏｐｉｃ１４０１にＰｕｂする。即時処理Ａｃｔｉｏｎ１４１１のその他の機能に関しては、図３の即時処理Ａｃｔｉｏｎ３６１と同様のため、詳細な説明は割愛する。

非即時処理Ａｃｔｉｏｎ１４１２は、非即時処理Ｔｏｐｉｃ１４０１に対するメッセージのＰｕｂが行われたことを受けて駆動するスクリプトである。非即時処理Ａｃｔｉｏｎ１４１２は、非即時処理Ｔｏｐｉｃ１４０１に対するＳｕｂを開始し、Ｐｕｂされたメッセージを受信する。非即時処理Ａｃｔｉｏｎ１４１２のその他の機能に関しては、図３の非即時処理Ａｃｔｉｏｎ３６２と同様のため、詳細な説明は割愛する。

図１５は、実施例３のシステム全体の処理シーケンスを示す図である。
図１５の処理シーケンスの前提として、デバイス情報送信アプリケーション３００による成功確認Ｔｏｐｉｃ３２２からのメッセージのＳｕｂが開始されているものとする。Ｓ１５００，Ｓ１５０１，Ｓ１５０２の処理は、それぞれ、図４のＳ４００，Ｓ４０２，Ｓ４１０の処理と同様であるので、詳細な説明は割愛する。

Ｓ１５０３において、即時処理Ａｃｔｉｏｎ１４１１が、Ｓ１５０２で受信したメッセージ６００を非即時処理Ｔｏｐｉｃ１４０１にＰｕｂする。Ｓ１５０４において、Ｓ１５０３で非即時処理Ｔｏｐｉｃ１４０１にメッセージが登録されたことがスクリプト管理アプリケーション３３０に通知される。スクリプト管理アプリケーション３３０が有するスクリプト管理部１４１０が、この通知を受けて、非即時処理Ａｃｔｉｏｎ１４１２を駆動させる。非即時処理Ａｃｔｉｏｎ１４１２は、非即時処理Ｔｏｐｉｃ１４０１に対し、Ｓｕｂの開始リクエストを行う。これにより、非即時処理Ｔｏｐｉｃ１４０１からのメッセージの受信が開始される。

Ｓ１５０５において、非即時処理Ａｃｔｉｏｎ１４１２が、非即時処理Ｔｏｐｉｃ１４０１からメッセージ６００を受信し、図４のＳ４１５と同様に、メッセージの保管処理を行う。続いて、Ｓ１５０６において、非即時処理Ａｃｔｉｏｎ１４１２が、メッセージ９００と同様のＰｕｂメッセージを生成し、成功確認Ｔｏｐｉｃ３２２にＰｕｂする。Ｓ１５０７の処理は、図４のＳ４２１の処理と同様であるので、詳細な説明は割愛する。

（その他の実施形態）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

Claims (8)

1. ネットワークデバイスをパブリッシャーとしてメッセージを受け取る第１メッセージ管理サービスと、該ネットワークデバイスをサブスクライバーとして前記メッセージの処理の成功を示すメッセージを配信するための第２メッセージ管理サービスを含むシステムにおいて、
   前記第１メッセージ管理サービスにより配信された第１メッセージの第１サービスでの処理の完了に応じて、前記第１サービスでの処理結果を情報管理サービスに登録する第１登録手段と、
   前記第１メッセージ管理サービスにより配信された前記第１メッセージの第２サービスでの処理の完了に応じて、前記第２サービスでの処理結果を前記情報管理サービスに登録する第２登録手段と、
   前記第１メッセージの処理結果に従い、前記第２メッセージ管理サービスに対して、前記第１メッセージの処理の成功を示す第２メッセージを配信する配信手段と、を有する
   ことを特徴とする情報処理システム。
2. 前記第１サービスをパブリッシャーとして、前記第１メッセージの前記第１サービスでの処理結果に対応するメッセージを受け取り、前記第２サービスをパブリッシャーとして前記第１メッセージの前記第２サービスでの処理結果に対応するメッセージを受け取る第３メッセージ管理サービスを有し、
   前記第１登録手段および前記第２登録手段は、前記第３メッセージ管理サービスから前記第１メッセージの処理結果を受信して、前記第１メッセージの処理結果を含む前記第１メッセージの管理情報を前記情報管理サービスに登録する
   ことを特徴とする請求項１に記載の情報処理システム。
3. 前記情報管理サービスは、メッセージの識別情報と、前記第１メッセージ管理サービスの登録先と、前記第１メッセージを処理するサービスの識別情報と、前記第１メッセージの処理結果を管理する
   ことを特徴とする請求項１または請求項２に記載の情報処理システム。
4. 前記情報管理サービスには、前記第１メッセージ管理サービスのサブスクライバーとして、前記第１サービスと前記第２サービスとが登録され、
   前記配信手段によって、前記サブスクライバーでの前記第１メッセージの処理結果に従い、前記第２メッセージ管理サービスに対して前記第２メッセージが配信される
   ことを特徴とする請求項１乃至３のいずれか１項に記載の情報処理システム。
5. 前記第１サービスが、前記第１登録手段として、前記第１メッセージの前記第１サービスでの処理の完了に応じて、前記第１サービスでの処理結果を前記情報管理サービスに登録し、
   前記第２サービスが、前記第２登録手段として、前記第１メッセージの前記第２サービスでの処理の完了に応じて、前記第２サービスでの処理結果を前記情報管理サービスに登録し、
   前記第２サービスが、前記配信手段として、前記第１メッセージの処理結果に従い、前記第２メッセージ管理サービスに対して、前記第２メッセージを配信する
   ことを特徴とする請求項１乃至３のいずれか１項に記載の情報処理システム。
6. 前記ネットワークデバイスは、画像処理装置を含み、
   前記画像処理装置は、前記パブリッシャーとして、自身の所定の稼働情報を示すメッセージを前記第１メッセージ管理サービスに対して送信する
   ことを特徴とする請求項１乃至３のいずれか１項に記載の情報処理システム。
7. 前記配信手段は、前記第１サービスと前記第２サービスにおける前記第１メッセージの処理結果が全て成功を示している場合に、前記第２メッセージ管理サービスに対して、前記第２メッセージを配信する
   ことを特徴とする請求項１乃至６のいずれか１項に記載の情報処理システム。
8. ネットワークデバイスをパブリッシャーとしてメッセージを受け取る第１メッセージ管理サービスと、該ネットワークデバイスをサブスクライバーとして前記メッセージの処理の成功を示すメッセージを配信するための第２メッセージ管理サービスを含むシステムにおける制御方法であって、
   前記第１メッセージ管理サービスにより配信された第１メッセージの第１サービスでの処理の完了に応じて、前記第１サービスでの処理結果を情報管理サービスに登録する第１登録工程と、
   前記第１メッセージ管理サービスにより配信された前記第１メッセージの第２サービスでの処理の完了に応じて、前記第２サービスでの処理結果を前記情報管理サービスに登録する第２登録工程と、
   前記第１メッセージの処理結果に従い、前記第２メッセージ管理サービスに対して、前記第１メッセージの処理の成功を示す第２メッセージを配信する配信工程と、を有する
   ことを特徴とする制御方法。

Images