JP5077430B2 - 管理装置および管理装置のプログラム - Google Patents

Description

本発明は調和（Reconciliation）機能を持つ仮想統合管理装置（FCMDB: Federated Configuration Management Database）において、ＦＣＭＤＢに対して情報の更新系処理、例えば登録／更新／削除が行なわれた際に、ＦＣＭＤＢの管理対象である装置構成情報管理装置（MDR: Management Data Repository）の各々に対して効率的に更新系処理の依頼を行なう仮想統合管理装置およびそのためのプログラムに関する。

図１はＦＣＭＤＢの基本機能を説明するためのＦＣＭＤＢによるＭＤＲの管理体系を示す図である。ここで、ＦＣＭＤＢとは複数のＭＤＲに格納された異種のデータベースＤＢ（Database）を仮想統合する管理システムを意味し、ＭＤＲは管理するデータベースの記憶装置を意味する。ＦＣＭＤＢ１０は仮想統合している複数のＭＤＲ１１〜１６に格納されたデータベースＤＢに対して横断的に操作を行なうことが可能である。各ＭＤＲ１１〜１６が構成情報、インシデント情報、トラブル情報、リリース情報、変更情報またはアプリケーション情報等のリソースに関する情報（CI & Relationship）と情報間の関連（Relationship）を管理し、ＦＣＭＤＢ１０が整合化された情報を管理する。ＦＣＭＤＢ１０は外部のコンピュータまたは自身の入力デバイスを介して検索要求を受け、複数のＭＤＲ１１〜１６から検索結果を導出し応答する。なお、以降の図において「アプリケーション」は「アプリ」と略記する。

図２はＦＣＭＤＢの調和機能を説明するためのＦＣＭＤＢによるＭＤＲの管理体系を示す図である。図２のＦＣＭＤＢ２０は図１のＦＣＭＤＢ１０と同一機能を有する。ＦＣＭＤＢ２０は仮想統合している複数のＭＤＲ２１〜２６に格納されたデータベースＤＢに対して横断的に操作を行なうことが可能であり、情報のリコンシリエーション機能 （調和を図る機能）を有する。ＦＣＭＤＢ２０による情報の調和機能には下記の２点がある。
第１点：データベースＤＢ毎に異なる名前（サーバ、ホスト、ノード）で管理されている同一の更新系処理の依頼（以下、アイテムと記す）アイテム２１Ａ〜２４Ａの情報を統合する。具体的には、名前を「サーバ」に統一する。
第２点：データベースＤＢ毎に異なるロ−カルＩＤ（Webserver1、192.168.10.1、hostnameX）で管理されている同一アイテム２１Ａ〜２４Ａの情報を統合する。具体的には、ＩＤを「Serial Number-XXX」に統一する。

特許文献１には、更新を一部の主コピーを有する主データベースでのみ行ない、同期時期になったら主コピー以外の他のコピーを有する従データベースへ主データベースから更新履歴を送信し、更新履歴に従って従コピーを主コピーと同じ内容に更新することにより分散データベースの更新時間の短縮を実現する技術が開示されている。しかしながら、特許文献１に記載の発明は、更新が行なわれる情報に関連する情報を持つＭＤＲ（データベース）に対して同期時期に更新履歴を送信し、同ＭＤＲが情報を更新するが、登録／更新／削除等の更新系の処理依頼そのものを送信するものではない。

特開平６−１１９２２７号公報 http://cmdbf.org/schema/1-0-0/CMDBf%20v1.0.pdf

図３は従来技術の課題を説明するためのＦＣＭＤＢによるＭＤＲの管理体系を示す図である。従来のＦＣＭＤＢ３０は検索機能のみを提供するが、登録／更新／削除機能を提供しない。仮に、ＦＣＭＤＢ３０が仮想統合している全ＭＤＲ３１〜３３に対して登録／更新／削除等の更新系処理の依頼を個別にＭＤＲ３１〜３３に直接アクセスせずにＦＣＭＤＢ２０経由で行なう場合を想定すると、本来処理依頼を行なう必要のないＭＤＲ３２に対しても処理依頼を行ってしまう。換言すれば、処理依頼を受理する／行なうべきＭＤＲが存在しない場合に、処理依頼をどのＭＤＲ３１〜３３に対して行なえばよいのか分からないので本来処理依頼を行なう必要のないＭＤＲ３２に対して不要な処理依頼を行ってしまい、非効率的であるという問題がある。

図４は従来技術の課題を解決するＦＣＭＤＢによるＭＤＲの管理体系を示す図である。上記従来技術の問題を解決するには、現存するＦＣＭＤＢ４０が登録／更新／削除等の更新系処理の依頼を受けた場合に、本来処理依頼を行なう必要のないＭＤＲ４２に対しあるいは処理依頼を受理するＭＤＲが存在しない場合に全てのＭＤＲ４〜４３に対し、不要な処理依頼を行なわないようすればよい。

それゆえ、本発明は、ＦＣＭＤＢによるＭＤＲの管理体系において、ＦＣＭＤＢ４０が登録／更新／削除等の更新系処理の依頼に対して、処理依頼を受理する／行なうべきＭＤＲが存在しない場合に対応できる、各ＭＤＲ４１〜４３に対し効率的に更新系処理を依頼できるようにする更新系処理の依頼を行う情報管理装置およびそのためのプログラムを提供することを目的とする。

本実施例によれば、複数の記憶装置を管理し、前記複数の記憶装置へ情報の更新処理を行なう管理装置であって、処理要求を受け付ける受付部と、前記複数の記憶装置に格納されたデータ相互の関連情報を管理し、前記受付部が検索に関する処理要求を受け付けたときは、前記関連情報に基づいて前記複数の記憶装置それぞれから検索結果を取得し応答を作成する検索処理部と、前記複数の記憶装置に格納されたデータそれぞれが、いずれの前記複数の記憶装置に格納されているか、および、未完了の更新処理要求を管理するメタ情報を記憶するメタ情報管理部と、前記受付部が更新に関する処理要求を受け付けたときは、前記メタ情報に基づき、前記更新に関する処理要求の対象となるデータが格納されている記憶装置に対して、前記更新に関する処理要求の対応依頼を行なうとともに、前記更新に関する処理要求が完了したときは、前記メタ情報の前記未完了の更新処理要求の内容を変更する更新系処理部と、を備えた管理装置が提供される。
上記従来技術の課題を解決するＦＣＭＤＢによるＭＤＲの管理体系における情報管理装置には第１形態〜第５形態がある。

第１形態の情報管理装置は、管理している情報がどこから来たかを示すメタ情報を記憶しておき、該メタ情報から登録／更新／削除等の更新系処理の情報の元となった情報を持っているＭＤＲを絞り込み、絞り込んだＭＤＲに対してのみ、登録／更新／削除等の更新系処理の依頼を行なう。

第２形態の情報管理装置は、更新系処理の依頼であるアイテムの属性情報を記憶しておき、該属性情報から登録／更新／削除等の更新系処理の情報の元となった情報を持っているＭＤＲを絞り込み、絞り込んだＭＤＲに対してのみ、登録／更新／削除等の更新系処理の依頼を行なう。

第３形態の情報管理装置は、どのＭＤＲも登録／更新／削除等の更新系処理の依頼を受理しなかった場合に、ＦＣＭＤＢに登録／更新／削除等の更新系処理の情報を一時保存しておく。

第４形態の情報管理装置は、新しいＭＤＲがＦＣＭＤＢに登録された時、当該ＭＤＲは処理依頼を受理する可能性があるので一時保存していた情報の更新系処理の依頼を行ない、当該ＭＤＲが依頼を受理した場合は一時保存していた処理依頼を完了し削除する。

第５形態の情報管理装置は、ＭＤＲ側の状況変化（アクセス設定の変更など）により、処理依頼を受理するように状況が変化したかも知れないので受理しなかったＭＤＲに対して再度、例えば定期的に処理依頼を行ない、当該ＭＤＲが依頼を受理した場合は一時保存していた処理依頼を完了し削除する。

第１形態に係る複数のＭＤＲを管理するＦＣＭＤＢからＭＤＲへ情報の更新系処理を行なう情報管理装置のプログラムは、
コンピュータに、
管理している情報がＭＤＲの何れから来たかを示すメタ情報を記憶する第１手順と、
前記メタ情報から登録／更新／削除等の更新系処理の情報の元となった情報を持つ処理依頼を行なうＭＤＲを絞り込む第２手順と、
絞り込んだＭＤＲに対してのみ、登録／更新／削除等の更新系処理の依頼を行なう第３手順と、を実行させる。

第２〜５形態に係る情報管理装置のプログラムは、上記第２〜５形態に係る情報管理装置の処理をコンピュータに実行させる。

第１形態および第２形態によれば、調和に使った管理している情報の出元を記憶しておくことにより、従来技術では実現されていなかった更新系処理を依頼するＭＤＲを不可欠かつ必要最小限に留めることができる。

第３〜５形態によれば、どのＭＤＲも処理依頼を受理しない場合や処理依頼を行なうＭＤＲが存在しない場合でも、適切なＭＤＲが現れた時に一時保存していた処理依頼を行なうことが可能となり、ＭＤＲが依頼を受理した場合はＦＣＭＤＢで管理している一時保存していた処理依頼を減らすことができる。

図５はＦＣＭＤＢによるＭＤＲの管理体系における実施形態に係る情報管理装置のブロック構成図である。図５に示す本実施形態に係る情報管理装置５１０はＦＣＭＤＢ５０内に組み込まれている。しかし、他の実施形態では情報管理装置５１０はＦＣＭＤＢ５０に通信可能に接続しＦＣＭＤＢ５０の外部に設置してもよい。本実施形態の情報管理装置５１０はＦＣＭＤＢ５０と同様、少なくとも不図示のＣＰＵ、主記憶（メモリ）、補助記憶（磁気ディスク）を備えたコンピュータ装置である。以下に記す情報は補助記憶に格納され、処理は主記憶に書込まれるプログラムにより実行される。

図５に示すように、ＦＣＭＤＢ５０は従来の要求受付部５０１と検索処理部５０２と回答通知部５０３の他に情報管理装置５１０に設けられたメタ情報管理部５１１と更新系処理部５１２と更新系再処理部５１３とを有する。

要求受付部５０１は検索／登録／更新／削除の依頼の要求を受け付ける。
検索処理部５０２は要求受付部５０１から検索依頼の要求を受け、ＭＤＲ５１、ＭＤＲ５２、…、ＭＤＲ５Ｎに同要求を送信し、検索結果を受信し、受信した検索結果を回答通知部５０３に送る。検索処理部５０２は検索先が見つかれば検索先の通知を、見つからなければ検索先無しの通知を、検索結果として回答通知部５０３に送る。
回答通知部５０３は検索／登録／更新／削除の依頼の要求元に依頼に対する処理結果を通知することで応答する。

メタ情報管理部５１１はメタ情報を管理する。メタ情報は下記の３つの情報を含む。（１）CI／Relationshipメタ情報：管理している情報がどのＭＤＲから来たかを示す元情報を含むメタ情報であり、CI情報とRelationship情報とを含み、CI（Configuration Item）情報は管理している更新系処理の依頼であるアイテムを示す。Relationship情報はアイテム間の関係付けを示し各アイテムがどのＭＤＲのＤＢに格納されているかを示す。

（２）Propertyメタ情報：アイテムの属性についての情報であり、アイテムのPropertyの名前とそのアイテムがどのＭＤＲから来たかを示す元情報とを含み、Propertyの名前はアイテムのハードウェア、ソフトウェア等の属性を示し、元情報はPropertyの名前に対応する属性情報がどのＭＤＲのＤＢに格納されているかを示す。

（３）未処理情報：更新系処理の依頼が未完了であることを示す情報であり、依頼ＩＤ、CI／RelationshipＩＤ、種別、PropertyおよびValueの情報を含む。ここで、依頼ＩＤは、未完了の更新系処理の依頼を識別するための情報であり、例えば依頼の名前がこの情報である。CI／RelationshipＩＤは、CI／Relationship情報を識別するための情報である。種別は、更新系処理の依頼が登録／更新／削除の何れであるかを示す情報である。Propertyは、未完了の更新系処理の依頼のアイテムに関連付けられたアイテムのハードウェア、ソフトウェア等の属性を示す情報である。Valueは、Propertyのデータである。

更新系処理部５１２は登録／更新／削除等の更新系処理をメタ情報管理部５１１の持つ情報を参照して行なう。
更新系再処理部５１３は更新系処理部５１２で未処理となった更新系処理をメタ情報管理部５１１の持つ情報を参照して新しいＭＤＲに対し、または先に処理依頼が受理されなかったＭＤＲに対し再度定期的に更新系処理を行なう。この処理は再度行なえば定期的に行なわなくてもよい。
以下の説明において、情報管理装置５１０はＦＣＭＤＢ５０に含められるのでＦＣＭＤＢ５０と記す。

図６はＦＣＭＤＢによるＭＤＲの管理体系における情報管理装置の第１実施形態を示す図である。ＦＣＭＤＢ５０はCI及びRelationshipメタ情報を使ってＭＤＲを絞込む。

図６に示す第１実施形態では、ＦＣＭＤＢ５０はCI／Relationshipメタ情報のテーブル５００とPropertyメタ情報のテーブル５０１〜５０６を格納している。CI／Relationshipメタ情報は、ＦＣＭＤＢに既に登録されているCI／Relationshipの識別子と元情報との対応を管理している。テーブル５００にはCI／Relationshipの識別子であるアイテムＧＩＤ１およびＧＩＤ２に関する情報が登録され、元情報の欄にはアイテムＧＩＤ１に対応してアイテムＧＩＤ１に関連する情報は、ＤＢ１のＬＩＤ１１に、ＤＢ２のＬＩＤ２１、ＤＢ３のＬＩＤ３１およびＤＢ４のＬＩＤ４１に在ることが示されている。アイテムＧＩＤ２に対しても同様であるので説明は省略する。ここで、ＬＩＤ１１、ＬＩＤ２１、ＬＩＤ３１、ＬＩＤ４１は更新系の処理が行なわれる情報である。

アイテムＧＩＤ１は更新依頼された情報であり、更新前と更新後のアイテムＧＩＤ１を比較しても判るように、テーブル５００から関連情報Ｍｅｍｏｒｙ、ＣＰＵ、Ａｐｐ（Application）およびＥＲＲＯＲがそれぞれＬＩＤ１１、ＬＩＤ２１、ＬＩＤ３１およびＬＩＤ４１に在ることが判る。ＬＩＤ１１、ＬＩＤ２１、ＬＩＤ３１およびＬＩＤ４１はそれぞれＤＢ１のＭＤＲ５１、ＤＢ２のＭＤＲ５２、ＤＢ３のＭＤＲ５３およびＤＢ４のＭＤＲ５４に格納されているので、ＦＣＭＤＢ５０はこれらのＭＤＲ５１〜５４の４つの候補に絞り込んで更新依頼を行なう。

ＤＢ１のＬＩＤ１１でＣＰＵの情報が、ＤＢ２のＬＩＤ２１でＭｅｍｏｒｙの情報が、ＤＢ３のＬＩＤ３１でＥＲＲＯＲの情報が、ＤＢ４のＬＩＤ４１でＡｐｐの情報が、それぞれ更新される。

図７はＦＣＭＤＢによるＭＤＲの管理体系における情報管理装置の第２実施形態を示す図である。ＦＣＭＤＢ５０においてメタ情報管理部５１１はPropertyメタ情報を管理する。更新系処理部５１２はPropertyメタ情報を使ってＭＤＲを絞込む。

図７に示す第２実施形態では、Propertyメタ情報のテーブル５０１にはアイテムのPropertyの名前の欄にはＩＤ、ＨＤＤ、Ｍｅｍｏｒｙ、ＣＰＵ、ＡｐｐおよびＥＲＲＯＲが示され、元情報の欄にはPropertyの名前ＩＤ、ＨＤＤ、Ｍｅｍｏｒｙ、ＣＰＵ、ＡｐｐおよびＥＲＲＯＲに対応して関連する情報がそれぞれどのＭＤＲのＤＢに格納されているかが示されている。例えば、ＩＤに関連する情報がＭＤＲ（ＤＢ）１のＬＩＤ１１とＭＤＲ（ＤＢ）３のＬＩＤ３１に格納されていることが示されている。

アイテムＧＩＤ１は更新依頼された情報であり、更新前と更新後のアイテムＧＩＤ１を比較しても判るように、テーブル５０１からPropertyの名前がＣＰＵ、ＡｐｐおよびＥＲＲＯＲがアイテムＧＩＤ１において更新された情報であることが判る。したがって、ＦＣＭＤＢ５０はＣＰＵ、ＡｐｐおよびＥＲＲＯＲに対応する元情報からＭＤＲ（ＤＢ）１、ＭＤＲ（ＤＢ）２およびＭＤＲ（ＤＢ）４の３つの候補に絞り込んで更新依頼を行なう。

図８はＦＣＭＤＢによるＭＤＲの管理体系における情報管理装置の第３実施形態を示す図である。

図８に示す第３実施形態では、メタ情報管理部５１１が、関連する情報を持つＭＤＲに登録／更新／削除依頼を行ない、どのＭＤＲでも登録／更新／削除依頼が受理されなかった未処理部分を管理する。登録／更新／削除依頼の未処理部分の情報（以下、未処理情報と記す）をテーブル８００に格納する。

未処理情報を格納するテーブル８００は、依頼ＩＤ、CI／RelationshipＩＤ、種別、PropertyおよびValueの欄を有する。依頼ＩＤの欄には未処理情報の名前ＵＤ−０００１、ＵＤ−００１２、ＵＤ−００１３が格納されている。CI／RelationshipＩＤの欄には未処理情報の名前に対応するアイテムＧＩＤ１、ＧＩＤ−１１１、ＧＩＤ−１１２が格納されている。種別の欄には登録／更新／削除が格納されている。Propertyの欄には図示のPropertyの名前ＩＤ、ＩＰＡｄｄｒ、ＵＳＥ、Ｎａｍｅが格納されている。Valueの欄にはPropertyの名前に対応するProperty（属性）値が格納されている。例えば、Propertyの名前ＳＮに対応してその属性値SerialNumber-XXXが格納されている。

ＦＣＭＤＢ５０は、アイテムＧＩＤ１の更新での未処理情報、ＣＰＵ、ＡＰＰ、ＥＲＲＯＲを持つアイテムＧＩＤ１を依頼ＩＤ、種別、Property、Valueと共にテーブル８００に格納する。

図９はＦＣＭＤＢによるＭＤＲの管理体系における情報管理装置の第４実施形態を示す図である。

図９に示す第４実施形態では、更新系再処理部５１３は、メタ情報管理部５１１を参照して、新しいＭＤＲ５がＦＣＭＤＢに登録された時には、更新系処理部５１２がそのＭＤＲ５に対してテーブル９００に格納された完了していない登録／更新／削除の依頼を行なう。また、更新系再処理部５１３は、未処理部分がなくなった登録／更新／削除の依頼に対して、すなわち依頼が受理された場合は、テーブル９００からその依頼を削除する。図９に示す例では、依頼ＩＤがＵＤ−０００１に対し、完了していない更新の依頼を行ない、ＧＩＤ１に関連する更新依頼が受理されたのでテーブル９００からＵＤ−０００１の関連情報を削除する。

図１０はＦＣＭＤＢによるＭＤＲの管理体系における情報管理装置の第５実施形態を示す図である。

図１０に示す第５実施形態では、更新系再処理部５１３は、メタ情報管理部５１１を参照して、定期的に関連する情報を持つＭＤＲに登録／更新／削除依頼を行ない、どのＭＤＲでも登録／更新／削除の依頼が受理されなかった未処理部分を管理する。更新系処理部５１２が再度定期的に関連する情報を持つＭＤＲに登録／更新／削除依頼を行なう。この処理は再度行なえば定期的に行なわなくてもよい。また、更新系再処理部５１３は、未処理部分がなくなった登録／更新／削除依頼をテーブル１０００から削除する。

図１０に示す例では、依頼ＩＤがＵＤ−０００１に対し、完了していない更新の依頼再度を行ない、ＧＩＤ１に関連する更新依頼が受理されたのでテーブル９００からＵＤ−０００１の関連情報を削除する。

図１１は実施形態に係る情報管理装置による処理のフローチャートである。以下に、上述した第１実施形態〜第５実施形態に係る情報管理装置による処理を説明する。
第１実施形態では、ステップＳ１でCI／Relationshipメタ情報を使って処理依頼を行なうＭＤＲを絞込む。

第２実施形態では、ステップＳ２でPropertyメタ情報を使って処理依頼を行なうＭＤＲを絞込む。

第３実施形態では、以下の処理を実行する。
ステップＳ１１で絞込んだ結果、該当するＭＤＲが有るか否かをチェックし、ＹＥＳのときはステップＳ１２に進み、ＮＯのときはステップＳ１４に進む。
ステップＳ１２で絞込んだ全ＭＤＲに対して処理依頼を行ない、ステップＳ１３に進む。
ステップＳ１３で何れかのＭＤＲが処理依頼を受理したか否かをチェックし、ＹＥＳのときは本処理を終了し、ＮＯのときはステップＳ１４に進む。
ステップＳ１４で処理依頼をＦＣＭＤＢに保存する。

第４実施形態では、以下の処理を実行する。
ステップＳ２１で新しいＭＤＲがＦＣＭＤＢに登録されたか否かをチェックし、ＹＥＳのときはステップＳ２２に進み、ＮＯのときはステップＳ２３に進む。
ステップＳ２２で新しく登録されたＭＤＲに保存してある処理依頼を行なう。
ステップＳ２３で新しいＭＤＲが処理依頼を受理したか否かをチェックし、ＹＥＳのときは本処理を終了し、ＮＯのときはステップＳ２１に戻る。ステップＳ２３でＹＥＳのとき、保存した処理依頼を削除してから本処理を終了する。

第５実施形態では、以下の処理を実行する。
ステップＳ３１で一定時間待ち、一定時間が経過したらステップＳ３２に進む。
ステップＳ３２で絞込んだ全ＭＤＲに対して処理依頼を行なう。
ステップＳ３３で何れかのＭＤＲが処理依頼を受理したか否かをチェックし、ＹＥＳのときは本処理を終了し、ＮＯのときはステップＳ３１に戻る。ステップＳ３３でＹＥＳのとき、保存した処理依頼を削除してから本処理を終了する。

ＦＣＭＤＢの基本機能を説明するためのＦＣＭＤＢによるＭＤＲの管理体系を示す図である。（従来技術） ＦＣＭＤＢの調和機能を説明するためのＦＣＭＤＢによるＭＤＲの管理体系を示す図である。（従来技術） 従来技術の課題を説明するためのＦＣＭＤＢによるＭＤＲの管理体系を示す図である。（従来技術） 従来技術の課題を解決するＦＣＭＤＢによるＭＤＲの管理体系を示す図である。 ＦＣＭＤＢによるＭＤＲの管理体系における実施形態に係る情報管理装置のブロック構成図である。 ＦＣＭＤＢによるＭＤＲの管理体系における情報管理装置の第１実施形態を示す図である。 ＦＣＭＤＢによるＭＤＲの管理体系における情報管理装置の第２実施形態を示す図である。 ＦＣＭＤＢによるＭＤＲの管理体系における情報管理装置の第３実施形態を示す図である。 ＦＣＭＤＢによるＭＤＲの管理体系における情報管理装置の第４実施形態を示す図である。 ＦＣＭＤＢによるＭＤＲの管理体系における情報管理装置の第５実施形態を示す図である。 実施形態に係る情報管理装置による処理のフローチャートである。

５０ ＦＣＭＤＢ
５１、５２、５３、５４、５５、…、５Ｎ ＭＤＲ
５００ CI／Relationshipメタ情報
５０１〜５０６ Propertyメタ情報
５１０ 情報管理装置
５１１ メタ情報管理部
５１２ 更新系処理部
５１３ 更新系再処理部
８００、９００、１０００ 未処理情報テーブル

Claims (10)

1. 複数の記憶装置を管理し、前記複数の記憶装置へ情報の更新処理を行なう管理装置であって、
   処理要求を受け付ける受付部と、
   前記複数の記憶装置に格納されたデータ相互の関連情報を管理し、前記受付部が検索に関する処理要求を受け付けたときは、前記関連情報に基づいて前記複数の記憶装置それぞれから検索結果を取得し応答を作成する検索処理部と、
   前記複数の記憶装置に格納されたデータそれぞれが、いずれの前記複数の記憶装置に格納されているか、および、未完了の更新処理要求を管理するメタ情報を記憶するメタ情報管理部と、
   前記受付部が更新に関する処理要求を受け付けたときは、前記メタ情報に基づき、前記更新に関する処理要求の対象となるデータが格納されている記憶装置に対して、前記更新に関する処理要求の対応依頼を行なうとともに、前記更新に関する処理要求が完了したときは、前記メタ情報の前記未完了の更新処理要求の内容を変更する更新系処理部と、
   を備えた管理装置。
2. 前記メタ情報管理部は、前記更新に関する処理要求の依頼である識別子の属性情報を記憶し、
   前記更新系処理部は、前記属性情報から前記更新に関する処理要求の対象となるデータが格納されている記憶装置に対して、前記更新に関する処理要求の依頼を行なう、請求項１に記載の管理装置。
3. 前記メタ情報管理部は、前記更新に関する処理要求の依頼を受理する記憶装置が存在しなかった場合に、前記更新に関する処理要求を一時保存する、請求項１または２に記載の管理装置。
4. 新しい記憶装置が前記管理装置に登録された時、該記憶装置に前記メタ情報管理部が一時保存した前記更新に関する処理要求の依頼を行ない、当該記憶装置が依頼を受理した場合は一時保存していた前記更新に関する処理要求の依頼を完了する更新系再処理部を備えた、請求項３に記載の管理装置。
5. 前記更新系再処理部は、受理しなかった記憶装置に対して一時保存した前記更新に関する処理要求の依頼を再度行ない、当該記憶装置が依頼を受理した場合は一時保存していた前記更新に関する処理要求の依頼を完了する、請求項４に記載の管理装置。
6. 複数の記憶装置を管理し、前記複数の記憶装置へ情報の更新処理を行なう管理装置のプログラムであって、
   コンピュータに、
   処理要求を受け付ける手順と、
   前記複数の記憶装置に格納されたデータ相互の関連情報を管理し、検索に関する処理要求を受け付けたときは、前記関連情報に基づいて前記複数の記憶装置それぞれから検索結果を取得し応答を作成する手順と、
   前記複数の記憶装置に格納されたデータそれぞれが、いずれの前記複数の記憶装置に格納されているか、および、未完了の更新処理要求を管理するメタ情報を記憶する手順と、
   前記更新に関する処理要求を受け付けたときは、前記メタ情報に基づき、前記更新に関する処理要求の対象となるデータが格納されている記憶装置に対して、前記更新に関する処理要求の対応依頼を行なうとともに、前記更新に関する処理要求が完了したときは、前記メタ情報の前記未完了の更新処理要求の内容を変更する手順と、
   を実行させるプログラム。
7. 複数の記憶装置を管理し、前記複数の記憶装置へ情報の更新処理を行なう管理装置のプログラムであって、
   コンピュータに、
   処理要求を受け付ける手順と、
   前記複数の記憶装置に格納されたデータ相互の関連情報を管理し、検索に関する処理要求を受け付けたときは、前記関連情報に基づいて前記複数の記憶装置それぞれから検索結果を取得し応答を作成する手順と、
   更新に関する処理要求の依頼である識別子の属性情報を記憶する手順と、
   前記更新に関する処理要求を受け付けたときは、前記属性情報に基づき、前記更新に関する処理要求の対象となるデータが格納されている記憶装置に対して、前記更新に関する処理要求の対応依頼を行なうとともに、前記更新に関する処理要求が完了したときは、前記属性情報の前記未完了の更新処理要求の内容を変更する手順と、
   を実行させるプログラム。
8. コンピュータに、
   前記更新に関する処理要求の対象となるデータが格納されている記憶装置に対して、前記更新に関する処理要求の対応依頼を行なう手順と、
   前記更新に関する処理要求の依頼を受理する記憶装置が存在しなかった場合に、前記更新に関する処理要求を一時保存する手順と、
   を実行させる請求項６または７に記載のプログラム。
9. コンピュータに、
   新しい記憶装置が前記管理装置に登録されたか否かを判定する手順と、
   新しい記憶装置が前記管理装置に登録された時、該記憶装置に一時保存した前記更新に関する処理要求の依頼を行なう手順と、
   を実行させる請求項８に記載のプログラム。
10. コンピュータに、
    一定時間待ち、一定時間が経過したら前記更新に関する処理要求の対象となるデータが格納されている全ての記憶装置に対して、一時保存した前記更新に関する処理要求の依頼を再度行なう手順を実行させる請求項８に記載のプログラム。

Images