WO2009122527A1 - 装置構成情報管理装置へ情報の更新系処理を行なう仮想統合管理装置 - Google Patents

装置構成情報管理装置へ情報の更新系処理を行なう仮想統合管理装置 Download PDF

Info

Publication number
WO2009122527A1
WO2009122527A1 PCT/JP2008/056399 JP2008056399W WO2009122527A1 WO 2009122527 A1 WO2009122527 A1 WO 2009122527A1 JP 2008056399 W JP2008056399 W JP 2008056399W WO 2009122527 A1 WO2009122527 A1 WO 2009122527A1
Authority
WO
WIPO (PCT)
Prior art keywords
update
management device
information management
information
configuration information
Prior art date
Application number
PCT/JP2008/056399
Other languages
English (en)
French (fr)
Inventor
裕二 和田
松原　正純
森本　健司
昭 勝野
松本　安英
幸洋 渡辺
邦昭 嶋田
Original Assignee
富士通株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 富士通株式会社 filed Critical 富士通株式会社
Priority to PCT/JP2008/056399 priority Critical patent/WO2009122527A1/ja
Priority to GB1015946A priority patent/GB2470865A/en
Priority to JP2010505186A priority patent/JP5077430B2/ja
Publication of WO2009122527A1 publication Critical patent/WO2009122527A1/ja
Priority to US12/884,308 priority patent/US8650274B2/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • G06F16/256—Integrating or interfacing systems involving database management systems in federated or virtual databases
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/907—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually

Definitions

  • the present invention manages FCMDB when information update processing, for example, registration / update / deletion, is performed on FCMDB in a virtual integrated management device (FCMDB: “Federated Configuration Management Database”) having a reconciliation function.
  • FCMDB virtual integrated management device
  • the present invention relates to a virtual integrated management apparatus that efficiently requests update system processing for each target device configuration information management apparatus (MDR: Management Data Repository) and a program therefor.
  • MDR Management Data Repository
  • FIG. 1 is a diagram showing an MDR management system by FCMDB for explaining the basic functions of FCMDB.
  • FCMDB means a management system that virtually integrates different types of databases DB (Database) stored in a plurality of MDRs
  • MDR means a storage device for the database to be managed.
  • the FCMDB 10 can operate across the database DB stored in the plurality of MDRs 11 to 16 that are virtually integrated.
  • Each MDR 11 to 16 manages information (CI & Relationship) related to resources such as configuration information, incident information, trouble information, release information, change information or application information and the relationship (Relationship) between the information, and FCMDB 10 has been coordinated Manage information.
  • the FCMDB 10 receives a search request via an external computer or its own input device, derives a search result from the plurality of MDRs 11 to 16, and responds.
  • “application” is abbreviated as “application”.
  • FIG. 2 is a diagram showing a management system of MDR by FCMDB for explaining the harmony function of FCMDB.
  • the FCMDB 20 in FIG. 2 has the same function as the FCMDB 10 in FIG.
  • the FCMDB 20 can perform operations across the databases DB stored in the plurality of MDRs 21 to 26 that are virtually integrated, and has an information reconciliation function (a function for achieving harmony).
  • the information harmony function by FCMDB 20 has the following two points.
  • First point The information of the same update system processing request (hereinafter referred to as item) items 21A to 24A managed under different names (server, host, node) for each database DB is integrated. Specifically, the name is unified to “server”.
  • Second point Information of the same items 21A to 24A managed by different local IDs (Webserver1, 192.168.10.1, hostnameX) for each database DB is integrated. Specifically, the ID is unified to “Serial Number-XXX”.
  • Patent Document 1 updating is performed only in the main database having a part of the primary copy, and when the synchronization time comes, the update history is transmitted from the primary database to the slave database having another copy other than the primary copy, and according to the update history A technique for shortening the update time of the distributed database by updating the slave copy with the same content as the main copy is disclosed.
  • an update history is transmitted to a MDR (database) having information related to information to be updated at the synchronization time, and the MDR updates the information. It does not send the update processing request itself such as / deletion.
  • FIG. 3 is a diagram showing an MDR management system by FCMDB for explaining the problems of the prior art.
  • the conventional FCMDB 30 provides only a search function, but does not provide a registration / update / delete function. If it is assumed that all the MDRs 31 to 33 virtually integrated with the FCMDB 30 are requested via the FCMDB 20 without directly accessing the MDRs 31 to 33 individually, such as registration / updating / deleting requests.
  • a processing request is also sent to the MDR 32 that does not need to make a request. In other words, when there is no MDR to accept / perform a processing request, it is not known to which MDR 31 to 33 the processing request should be made, so it is unnecessary for the MDR 32 that does not need to make a processing request originally. There is a problem that the processing request is made and it is inefficient.
  • FIG. 4 is a diagram showing an MDR management system by FCMDB that solves the problems of the prior art.
  • the existing FCMDB 40 receives a request for an update system process such as registration / update / deletion, the process request is accepted for the MDR 42 that does not originally need to make a process request.
  • the process request is accepted for the MDR 42 that does not originally need to make a process request.
  • it is only necessary not to make an unnecessary processing request to all the MDRs 4 to 43.
  • An object of the present invention is to provide an information management apparatus that makes an update system process request to the MDRs 41 to 43 so that an update system process can be efficiently requested, and a program therefor.
  • the information management apparatus stores meta information indicating where the managed information has come from, and information from which the information of update processing such as registration / update / deletion is based on the meta information.
  • the MDRs having the ID are narrowed down, and only the narrowed-down MDRs are requested to perform update processing such as registration / update / deletion.
  • the information management apparatus stores the attribute information of an item that is a request for update processing, and has information that is the basis of information of update processing such as registration / update / deletion from the attribute information.
  • the selected MDRs are narrowed down, and only for the narrowed down MDRs, a request for update processing such as registration / update / deletion is made.
  • the information management apparatus temporarily stores information on update processing such as registration / update / deletion in FCMDB when no MDR accepts a request for update processing such as registration / update / deletion. Keep it.
  • the information management apparatus may accept the processing request, so that the MDR requests the update processing of the temporarily stored information.
  • the request is accepted, the temporarily saved processing request is completed and deleted.
  • the information management apparatus may again change the situation of the MDR that has not been accepted because the situation may have changed so as to accept the processing request due to the situation change on the MDR side (change of access setting, etc.), for example, periodically. If the MDR accepts the request, the temporarily saved processing request is completed and deleted.
  • a program of an information management apparatus that performs an update process of information from FCMDB to MDR that manages a plurality of MDRs according to the first form is as follows: On the computer, A first step of storing meta-information indicating which of the MDRs the managed information is from; A second step of narrowing down MDRs that perform processing requests having information that is the basis of information of update processing such as registration / update / deletion from the meta information; A third step of requesting update processing such as registration / update / deletion only for the narrowed MDR; Let it run.
  • the program of the information management device according to the second to fifth modes causes the computer to execute the processing of the information management device according to the second to fifth modes.
  • an MDR that requests an update process that has not been realized in the prior art is indispensable and necessary. Can be kept to a minimum.
  • FIG. 5 is a block configuration diagram of the information management apparatus according to the embodiment in the MDR management system based on FCMDB.
  • An information management apparatus 510 according to this embodiment shown in FIG. 5 is incorporated in the FCMDB 50.
  • the information management apparatus 510 may be connected to the FCMDB 50 so as to be communicable and installed outside the FCMDB 50.
  • the information management apparatus 510 of this embodiment is a computer apparatus including at least a CPU (not shown), a main memory (memory), and an auxiliary memory (magnetic disk). The information described below is stored in the auxiliary memory, and the processing is executed by a program written in the main memory.
  • the FCMDB 50 includes a meta information management unit 511, an update system processing unit 512, and an update system provided in the information management apparatus 510 in addition to the conventional request reception unit 501, search processing unit 502, and response notification unit 503. And a reprocessing unit 513.
  • the request reception unit 501 receives a request for search / registration / update / deletion.
  • the search processing unit 502 receives a request for a search request from the request reception unit 501, transmits the request to the MDR 51, MDR 52,..., MDR 5 N, receives the search result, and sends the received search result to the answer notification unit 503. If the search destination is found, the search processing unit 502 sends a search destination notification to the answer notification unit 503 as a search result.
  • the reply notification unit 503 responds by notifying the request source of the request for search / registration / update / deletion of the processing result for the request.
  • the meta information management unit 511 manages meta information.
  • the meta information includes the following three pieces of information.
  • Property meta information information about the item's attributes, including the item's Property name and original information indicating which MDR the item came from.
  • the Property name is the item's hardware, software, etc.
  • the attribute indicates the attribute, and the original information indicates in which MDR DB the attribute information corresponding to the name of Property is stored.
  • Unprocessed information Information indicating that an update process request has not been completed, and includes request ID, CI / Relationship ID, type, Property, and Value information.
  • the request ID is information for identifying a request for an incomplete update processing, for example, the name of the request is this information.
  • the CI / Relationship ID is information for identifying CI / Relationship information.
  • the type is information indicating whether the request for update processing is registration / update / deletion.
  • Property is information indicating the hardware, software, and other attributes of the item associated with the incomplete update-type process request item.
  • Value is Property data.
  • the update processing unit 512 performs update processing such as registration / update / deletion with reference to information held by the meta information management unit 511.
  • the update system reprocessing unit 513 refers to the information held by the meta information management unit 511 regarding the update system processing that has not been processed by the update system processing unit 512, or the MDR for which the processing request has not been received earlier. Then, the update processing is periodically performed again. If this process is performed again, it may not be performed periodically.
  • the information management apparatus 510 since the information management apparatus 510 is included in the FCMDB 50, it is referred to as FCMDB 50.
  • FIG. 6 is a diagram showing a first embodiment of the information management apparatus in the MDR management system based on FCMDB.
  • the FCMDB 50 uses the CI and Relationship meta information to narrow down the MDR.
  • the FCMDB 50 stores a CI / Relationship meta information table 500 and Property meta information tables 501 to 506.
  • the CI / Relationship meta information manages the correspondence between the CI / Relationship identifier already registered in the FCMDB and the original information.
  • Information related to items GID1 and GID2 which are identifiers of CI / Relationship is registered in the table 500, and information related to the item GID1 corresponding to the item GID1 is stored in LID11 of DB1, LID21 of DB2, It is shown that it exists in LID31 of DB3 and LID41 of DB4. Since the same applies to item GID2, description thereof will be omitted.
  • LID11, LID21, LID31, and LID41 are information on which update processing is performed.
  • the item GID1 is information requested to be updated, and as can be seen from the comparison between the item GID1 before and after the update, the related information Memory, CPU, App (Application), and ERROR from the table 500 are LID11, LID21, and LID31, respectively. And LID41. Since LID11, LID21, LID31, and LID41 are respectively stored in the MDR51 of DB1, the MDR52 of DB2, the MDR53 of DB3, and the MDR54 of DB4, the FCMDB 50 narrows down to these four candidates of MDRs 51 to 54 and makes an update request.
  • the CPU information is updated with the LID 11 of the DB1, the Memory information with the LID 21 of the DB 2, the ERROR information with the LID 31 of the DB 3, and the App information with the LID 41 of the DB 4, respectively.
  • FIG. 7 is a diagram showing a second embodiment of the information management apparatus in the MDR management system based on FCMDB.
  • the meta information management unit 511 manages Property meta information.
  • the update processing unit 512 uses the Property meta information to narrow down the MDR.
  • ID, HDD, Memory, CPU, App, and ERROR are shown in the Property name column of the item, and Property column is in the original information column. It is shown in which MDR DB each related information corresponding to name ID, HDD, Memory, CPU, App and ERROR is stored. For example, it is shown that information related to ID is stored in LID 11 of MDR (DB) 1 and LID 31 of MDR (DB) 3.
  • the item GID1 is information requested to be updated, and the property name “CPU”, “App”, and “ERROR” are updated in the item GID1 from the table 501, as can be seen by comparing the item GID1 before and after the update. I understand that. Therefore, the FCMDB 50 narrows down the original information corresponding to the CPU, App, and ERROR to the three candidates MDR (DB) 1, MDR (DB) 2, and MDR (DB) 4 and makes an update request.
  • FIG. 8 is a diagram showing a third embodiment of the information management apparatus in the MDR management system based on FCMDB.
  • the meta information management unit 511 makes a registration / update / deletion request to an MDR having related information, and an unprocessed portion where the registration / update / deletion request is not accepted by any MDR.
  • Information on the unprocessed portion of the registration / update / deletion request (hereinafter referred to as unprocessed information) is stored in the table 800.
  • the table 800 for storing unprocessed information has columns of request ID, CI / Relationship ID, type, Property, and Value.
  • request ID column names UD-0001, UD-0012, and UD-0013 of unprocessed information are stored.
  • items GID1, GID-111, and GID-112 corresponding to the names of unprocessed information are stored. Registration / update / deletion is stored in the type column.
  • the Property column stores the name ID, IPAddr, USE, and Name of the illustrated Property.
  • a Property (attribute) value corresponding to the Property name is stored.
  • the attribute value SerialNumber-XXX is stored corresponding to the Property name SN.
  • the FCMDB 50 stores the item GID1 having unprocessed information, CPU, APP, and ERROR in the update of the item GID1 together with the request ID, type, Property, and Value in the table 800.
  • FIG. 9 is a diagram showing a fourth embodiment of the information management apparatus in the MDR management system based on FCMDB.
  • the update system reprocessing unit 513 refers to the meta information management unit 511, and when a new MDR 5 is registered in the FCMDB, the update system processing unit 512 stores a table for the MDR 5.
  • the incomplete registration / update / deletion request stored in 900 is requested.
  • the update system reprocessing unit 513 deletes the request from the table 900 in response to a registration / update / deletion request with no unprocessed portion, that is, when the request is accepted.
  • an uncompleted update request is made for the request ID UD-0001, and the update request related to GID1 is accepted, so the related information of UD-0001 is deleted from the table 900.
  • FIG. 10 is a diagram showing a fifth embodiment of the information management apparatus in the MDR management system based on FCMDB.
  • the update reprocessing unit 513 refers to the meta information management unit 511 and periodically makes a registration / update / deletion request to an MDR having related information. Manage unprocessed parts for which registration / update / deletion requests have not been accepted.
  • the update processing unit 512 makes a registration / update / deletion request to the MDR having periodically related information again. If this process is performed again, it may not be performed periodically. Further, the update system reprocessing unit 513 deletes the registration / update / deletion request from which the unprocessed portion disappears from the table 1000.
  • an uncompleted update request is made for the request ID UD-0001 again, and the update request related to GID1 is accepted, so the related information of UD-0001 is deleted from the table 900. .
  • FIG. 11 is a flowchart of processing by the information management apparatus according to the embodiment. The processing by the information management apparatus according to the first to fifth embodiments will be described below.
  • step S1 MDRs for which processing is requested are narrowed down using CI / Relationship meta information.
  • MDRs for which processing is requested using Property meta information are narrowed down in step S2.
  • step S11 As a result of narrowing down in step S11, it is checked whether or not there is a corresponding MDR. If YES, the process proceeds to step S12, and if NO, the process proceeds to step S14. A processing request is made for all the MDRs narrowed down in step S12, and the process proceeds to step S13. In step S13, it is checked whether or not any MDR has accepted the processing request. If YES, the process ends. If NO, the process proceeds to step S14. In step S14, the processing request is stored in the FCMDB.
  • step S21 it is checked whether or not a new MDR is registered in FCMDB. If YES, the process proceeds to step S22. If NO, the process proceeds to step S23. In step S22, a processing request stored in the newly registered MDR is made. In step S23, it is checked whether or not the new MDR has accepted the processing request. If YES, this processing ends. If NO, the processing returns to step S21. When YES is determined in the step S23, the stored process request is deleted, and then this process is terminated.
  • step S31 the process waits for a predetermined time. When the predetermined time has elapsed, the process proceeds to step S32. A processing request is made for all the MDRs narrowed down in step S32. In step S33, it is checked whether any of the MDRs has accepted the processing request. If YES, the process ends. If NO, the process returns to step S31. If YES in step S33, the process ends after the saved processing request is deleted.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Business, Economics & Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Economics (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • Library & Information Science (AREA)
  • Tourism & Hospitality (AREA)
  • Quality & Reliability (AREA)
  • General Business, Economics & Management (AREA)
  • Operations Research (AREA)
  • Game Theory and Decision Science (AREA)
  • Educational Administration (AREA)
  • Marketing (AREA)
  • Development Economics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

　複数のＭＤＲを管理するＦＣＭＤＢからＭＤＲへ情報の更新系処理を行なう情報管理装置は、管理している情報がＭＤＲの何れから来たかを示すメタ情報を記憶するメタ情報管理部と、メタ情報から登録／更新／削除等の更新系処理の情報の元となった情報を持っているＭＤＲを絞り込み、絞り込んだＭＤＲに対してのみ、登録／更新／削除等の更新系処理の依頼を行なう更新系処理部とを備える。

Description

[規則37.2に基づきISAが決定した発明の名称]　装置構成情報管理装置へ情報の更新系処理を行なう仮想統合管理装置
　本発明は調和（Reconciliation）機能を持つ仮想統合管理装置（FCMDB: Federated Configuration Management Database）において、ＦＣＭＤＢに対して情報の更新系処理、例えば登録／更新／削除が行なわれた際に、ＦＣＭＤＢの管理対象である装置構成情報管理装置（MDR: Management Data Repository）の各々に対して効率的に更新系処理の依頼を行なう仮想統合管理装置およびそのためのプログラムに関する。
　図１はＦＣＭＤＢの基本機能を説明するためのＦＣＭＤＢによるＭＤＲの管理体系を示す図である。ここで、ＦＣＭＤＢとは複数のＭＤＲに格納された異種のデータベースＤＢ（Database）を仮想統合する管理システムを意味し、ＭＤＲは管理するデータベースの記憶装置を意味する。ＦＣＭＤＢ１０は仮想統合している複数のＭＤＲ１１～１６に格納されたデータベースＤＢに対して横断的に操作を行なうことが可能である。各ＭＤＲ１１～１６が構成情報、インシデント情報、トラブル情報、リリース情報、変更情報またはアプリケーション情報等のリソースに関する情報（CI &　Relationship）と情報間の関連（Relationship）を管理し、ＦＣＭＤＢ１０が整合化された情報を管理する。ＦＣＭＤＢ１０は外部のコンピュータまたは自身の入力デバイスを介して検索要求を受け、複数のＭＤＲ１１～１６から検索結果を導出し応答する。なお、以降の図において「アプリケーション」は「アプリ」と略記する。
　図２はＦＣＭＤＢの調和機能を説明するためのＦＣＭＤＢによるＭＤＲの管理体系を示す図である。図２のＦＣＭＤＢ２０は図１のＦＣＭＤＢ１０と同一機能を有する。ＦＣＭＤＢ２０は仮想統合している複数のＭＤＲ２１～２６に格納されたデータベースＤＢに対して横断的に操作を行なうことが可能であり、情報のリコンシリエーション機能 （調和を図る機能）を有する。ＦＣＭＤＢ２０による情報の調和機能には下記の２点がある。
　第１点：データベースＤＢ毎に異なる名前（サーバ、ホスト、ノード）で管理されている同一の更新系処理の依頼（以下、アイテムと記す）アイテム２１Ａ～２４Ａの情報を統合する。具体的には、名前を「サーバ」に統一する。
　第２点：データベースＤＢ毎に異なるロ－カルＩＤ（Webserver1、192.168.10.1、hostnameX）で管理されている同一アイテム２１Ａ～２４Ａの情報を統合する。具体的には、ＩＤを「Serial Number-XXX」に統一する。
　特許文献１には、更新を一部の主コピーを有する主データベースでのみ行ない、同期時期になったら主コピー以外の他のコピーを有する従データベースへ主データベースから更新履歴を送信し、更新履歴に従って従コピーを主コピーと同じ内容に更新することにより分散データベースの更新時間の短縮を実現する技術が開示されている。しかしながら、特許文献１に記載の発明は、更新が行なわれる情報に関連する情報を持つＭＤＲ（データベース）に対して同期時期に更新履歴を送信し、同ＭＤＲが情報を更新するが、登録／更新／削除等の更新系の処理依頼そのものを送信するものではない。
特開平6-119227号公報 http://cmdbf.org/schema/1-0-0/CMDBf%20v1.0.pdf
　図３は従来技術の課題を説明するためのＦＣＭＤＢによるＭＤＲの管理体系を示す図である。従来のＦＣＭＤＢ３０は検索機能のみを提供するが、登録／更新／削除機能を提供しない。仮に、ＦＣＭＤＢ３０が仮想統合している全ＭＤＲ３１～３３に対して登録／更新／削除等の更新系処理の依頼を個別にＭＤＲ３１～３３に直接アクセスせずにＦＣＭＤＢ２０経由で行なう場合を想定すると、本来処理依頼を行なう必要のないＭＤＲ３２に対しても処理依頼を行ってしまう。換言すれば、処理依頼を受理する／行なうべきＭＤＲが存在しない場合に、処理依頼をどのＭＤＲ３１～３３に対して行なえばよいのか分からないので本来処理依頼を行なう必要のないＭＤＲ３２に対して不要な処理依頼を行ってしまい、非効率的であるという問題がある。
　図４は従来技術の課題を解決するＦＣＭＤＢによるＭＤＲの管理体系を示す図である。上記従来技術の問題を解決するには、現存するＦＣＭＤＢ４０が登録／更新／削除等の更新系処理の依頼を受けた場合に、本来処理依頼を行なう必要のないＭＤＲ４２に対しあるいは処理依頼を受理するＭＤＲが存在しない場合に全てのＭＤＲ４～４３に対し、不要な処理依頼を行なわないようすればよい。
　それゆえ、本発明は、ＦＣＭＤＢによるＭＤＲの管理体系において、ＦＣＭＤＢ４０が登録／更新／削除等の更新系処理の依頼に対して、処理依頼を受理する／行なうべきＭＤＲが存在しない場合に対応できる、各ＭＤＲ４１～４３に対し効率的に更新系処理を依頼できるようにする更新系処理の依頼を行う情報管理装置およびそのためのプログラムを提供することを目的とする。
　上記従来技術の課題を解決するＦＣＭＤＢによるＭＤＲの管理体系における情報管理装置には第１形態～第５形態がある。
　第１形態の情報管理装置は、管理している情報がどこから来たかを示すメタ情報を記憶しておき、該メタ情報から登録／更新／削除等の更新系処理の情報の元となった情報を持っているＭＤＲを絞り込み、絞り込んだＭＤＲに対してのみ、登録／更新／削除等の更新系処理の依頼を行なう。
　第２形態の情報管理装置は、更新系処理の依頼であるアイテムの属性情報を記憶しておき、該属性情報から登録／更新／削除等の更新系処理の情報の元となった情報を持っているＭＤＲを絞り込み、絞り込んだＭＤＲに対してのみ、登録／更新／削除等の更新系処理の依頼を行なう。
　第３形態の情報管理装置は、どのＭＤＲも登録／更新／削除等の更新系処理の依頼を受理しなかった場合に、ＦＣＭＤＢに登録／更新／削除等の更新系処理の情報を一時保存しておく。
　第４形態の情報管理装置は、新しいＭＤＲがＦＣＭＤＢに登録された時、当該ＭＤＲは処理依頼を受理する可能性があるので一時保存していた情報の更新系処理の依頼を行ない、当該ＭＤＲが依頼を受理した場合は一時保存していた処理依頼を完了し削除する。
　第５形態の情報管理装置は、ＭＤＲ側の状況変化（アクセス設定の変更など）により、処理依頼を受理するように状況が変化したかも知れないので受理しなかったＭＤＲに対して再度、例えば定期的に処理依頼を行ない、当該ＭＤＲが依頼を受理した場合は一時保存していた処理依頼を完了し削除する。
　第１形態に係る複数のＭＤＲを管理するＦＣＭＤＢからＭＤＲへ情報の更新系処理を行なう情報管理装置のプログラムは、
　コンピュータに、
　管理している情報がＭＤＲの何れから来たかを示すメタ情報を記憶する第１ステップと、
　前記メタ情報から登録／更新／削除等の更新系処理の情報の元となった情報を持つ処理依頼を行なうＭＤＲを絞り込む第２ステップと、
　絞り込んだＭＤＲに対してのみ、登録／更新／削除等の更新系処理の依頼を行なう第３ステップと、
実行させる。
　第２～５形態に係る情報管理装置のプログラムは、上記第２～５形態に係る情報管理装置の処理をコンピュータに実行させる。
　第１形態および第２形態によれば、調和に使った管理している情報の出元を記憶しておくことにより、従来技術では実現されていなかった更新系処理を依頼するＭＤＲを不可欠かつ必要最小限に留めることができる。
　第３～５形態によれば、どのＭＤＲも処理依頼を受理しない場合や処理依頼を行なうＭＤＲが存在しない場合でも、適切なＭＤＲが現れた時に一時保存していた処理依頼を行なうことが可能となり、ＭＤＲが依頼を受理した場合はＦＣＭＤＢで管理している一時保存していた処理依頼を減らすことができる。
ＦＣＭＤＢの基本機能を説明するためのＦＣＭＤＢによるＭＤＲの管理体系を示す図である。（従来技術） ＦＣＭＤＢの調和機能を説明するためのＦＣＭＤＢによるＭＤＲの管理体系を示す図である。（従来技術） 従来技術の課題を説明するためのＦＣＭＤＢによるＭＤＲの管理体系を示す図である。（従来技術） 従来技術の課題を解決するＦＣＭＤＢによるＭＤＲの管理体系を示す図である。 ＦＣＭＤＢによるＭＤＲの管理体系における実施形態に係る情報管理装置のブロック構成図である。 ＦＣＭＤＢによるＭＤＲの管理体系における情報管理装置の第１実施形態を示す図である。 ＦＣＭＤＢによるＭＤＲの管理体系における情報管理装置の第２実施形態を示す図である。 ＦＣＭＤＢによるＭＤＲの管理体系における情報管理装置の第３実施形態を示す図である。 ＦＣＭＤＢによるＭＤＲの管理体系における情報管理装置の第４実施形態を示す図である。 ＦＣＭＤＢによるＭＤＲの管理体系における情報管理装置の第５実施形態を示す図である。 実施形態に係る情報管理装置による処理のフローチャートである。
符号の説明
　５０　　ＦＣＭＤＢ
　５１、５２、５３、５４、５５、…、５Ｎ　　ＭＤＲ
　５００　　CI／Relationshipメタ情報
　５０１～５０６　　Propertyメタ情報
　５１０　　情報管理装置
　５１１　　メタ情報管理部
　５１２　　更新系処理部
　５１３　　更新系再処理部
　８００、９００、１０００　　未処理情報テーブル
　図５はＦＣＭＤＢによるＭＤＲの管理体系における実施形態に係る情報管理装置のブロック構成図である。図５に示す本実施形態に係る情報管理装置５１０はＦＣＭＤＢ５０内に組み込まれている。しかし、他の実施形態では情報管理装置５１０はＦＣＭＤＢ５０に通信可能に接続しＦＣＭＤＢ５０の外部に設置してもよい。本実施形態の情報管理装置５１０はＦＣＭＤＢ５０と同様、少なくとも不図示のＣＰＵ、主記憶（メモリ）、補助記憶（磁気ディスク）を備えたコンピュータ装置である。以下に記す情報は補助記憶に格納され、処理は主記憶に書込まれるプログラムにより実行される。
　図５に示すように、ＦＣＭＤＢ５０は従来の要求受付部５０１と検索処理部５０２と回答通知部５０３の他に情報管理装置５１０に設けられたメタ情報管理部５１１と更新系処理部５１２と更新系再処理部５１３とを有する。
　要求受付部５０１は検索／登録／更新／削除の依頼の要求を受け付ける。
　検索処理部５０２は要求受付部５０１から検索依頼の要求を受け、ＭＤＲ５１、ＭＤＲ５２、…、ＭＤＲ５Ｎに同要求を送信し、検索結果を受信し、受信した検索結果を回答通知部５０３に送る。検索処理部５０２は検索先が見つかれば検索先の通知を、見つからなければ検索先無しの通知を、検索結果として回答通知部５０３に送る。
　回答通知部５０３は検索／登録／更新／削除の依頼の要求元に依頼に対する処理結果を通知することで応答する。
　メタ情報管理部５１１はメタ情報を管理する。メタ情報は下記の３つの情報を含む。（１）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メタ情報を使って処理依頼を行なうＭＤＲを絞込む。
　第３実施形態では、以下の処理を実行する。
　ステップＳ１１で絞込んだ結果、該当するＭＤＲが有るか否かをチェックし、ＹＥＳのときはステップＳ１２に進み、ＮＯのときはステップＳ１４に進む。
　ステップＳ１２で絞込んだ全ＭＤＲに対して処理依頼を行ない、ステップＳ１３に進む。
　ステップＳ１３で何れかのＭＤＲが処理依頼を受理したか否かをチェックし、ＹＥＳのときは本処理を終了し、ＮＯのときはステップＳ１４に進む。
　ステップＳ１４で処理依頼をＦＣＭＤＢに保存する。
　第４実施形態では、以下の処理を実行する。
　ステップＳ２１で新しいＭＤＲがＦＣＭＤＢに登録されたか否かをチェックし、ＹＥＳのときはステップＳ２２に進み、ＮＯのときはステップＳ２３に進む。
　ステップＳ２２で新しく登録されたＭＤＲに保存してある処理依頼を行なう。
　ステップＳ２３で新しいＭＤＲが処理依頼を受理したか否かをチェックし、ＹＥＳのときは本処理を終了し、ＮＯのときはステップＳ２１に戻る。ステップＳ２３でＹＥＳのとき、保存した処理依頼を削除してから本処理を終了する。
　第５実施形態では、以下の処理を実行する。
　ステップＳ３１で一定時間待ち、一定時間が経過したらステップＳ３２に進む。
　ステップＳ３２で絞込んだ全ＭＤＲに対して処理依頼を行なう。
　ステップＳ３３で何れかのＭＤＲが処理依頼を受理したか否かをチェックし、ＹＥＳのときは本処理を終了し、ＮＯのときはステップＳ３１に戻る。ステップＳ３３でＹＥＳのとき、保存した処理依頼を削除してから本処理を終了する。

Claims (10)

  1. 　複数の装置構成情報管理装置を管理する仮想統合管理装置から装置構成情報管理装置へ情報の更新系処理を行なう情報管理装置であって、
    　管理している情報が装置構成情報管理装置の何れから来たかを示すメタ情報を記憶するメタ情報管理部と、
    　前記メタ情報から登録／更新／削除等の更新系処理の情報の元となった情報を持っている装置構成情報管理装置を絞り込み、絞り込んだ装置構成情報管理装置に対してのみ、登録／更新／削除等の更新系処理の依頼を行なう更新系処理部と、
    を備えた仮想統合管理装置。
  2. 　前記メタ情報管理部は、更新系処理の依頼である識別子の属性情報を記憶し、
    　前記更新系処理部は、前記属性情報から登録／更新／削除等の更新系処理の情報の元となった情報を持っている装置構成情報管理装置を絞り込み、絞り込んだ装置構成情報管理装置に対してのみ、登録／更新／削除等の更新系処理の依頼を行なう、
    請求項１に記載の仮想統合管理装置。
  3. 　前記メタ情報管理部は、登録／更新／削除等の更新系処理の依頼を受理する装置構成情報管理装置が存在しなかった場合に、登録／更新／削除等の更新系処理の情報を一時保存する、
    請求項１または２に記載の仮想統合管理装置。
  4. 　新しい装置構成情報管理装置が前記仮想統合管理装置に登録された時、該装置構成管理装置に前記メタ情報管理部が一時保存した情報の更新系処理の依頼を行ない、当該装置構成情報管理装置が依頼を受理した場合は一時保存していた処理依頼を完了する更新系再処理部を備えた、
    請求項１乃至３の何れか１項に記載の仮想統合管理装置。
  5. 　前記更新系再処理部は、受理しなかった装置構成情報管理装置に対して再度処理依頼を行ない、当該装置構成情報管理装置が依頼を受理した場合は一時保存していた処理依頼を完了する、
    請求項１乃至４の何れか１項に記載の情報管理装置。
  6. 　複数の装置構成情報管理装置を管理する仮想統合管理装置から装置構成情報管理装置へ情報の更新系処理を行なう仮想統合管理装置のプログラムであって、
    　コンピュータに、
    　調和に使った情報が装置構成情報管理装置の何れにあるのかを示すメタ情報を記憶する第１ステップと、
    　前記メタ情報から登録／更新／削除等の更新系処理の情報の元となった情報を持つ装置構成情報管理装置を絞り込む第２ステップと、
    　絞り込んだ装置構成情報管理装置に対してのみ、登録／更新／削除等の更新系処理の依頼を行なう第３ステップと、
    実行させるプログラム。
  7. 　複数の装置構成情報管理装置を管理する仮想統合管理装置から装置構成情報管理装置へ情報の更新系処理を行なう仮想統合管理装置のプログラムであって、
    　コンピュータに、
    　更新系処理の依頼である識別子の属性情報を記憶する第１ステップと、
    　前記属性情報から登録／更新／削除等の更新系処理の情報の元となった情報を持っている装置構成情報管理装置を絞り込む第２ステップと、
    　絞り込んだ装置構成情報管理装置に対してのみ、登録／更新／削除等の更新系処理の依頼を行なう第３ステップと、
    を実行させるプログラム。
  8. 　コンピュータに、
    　前記第２ステップで絞込んだ結果、
    　該当する装置構成情報管理装置が有ると判定されたときは絞込んだ全装置構成情報管理装置に対して処理依頼を行なう第４ステップと、
    　該当する装置構成情報管理装置が無いと判定され、かつ何れかの装置構成情報管理装置も処理依頼を受理していないと判定されたときは、処理依頼を前記仮想統合管理装置に保存する第５ステップと、
    を実行させる請求項６または７に記載のプログラム。
  9. 　コンピュータに、
    　新しい装置構成情報管理装置が前記仮想統合管理装置に登録されたか否かを判定する第６ステップと、
    　新しく登録された装置構成情報管理装置に対し前記仮想統合管理装置に保存した処理依頼を行なう第７ステップと、
    を実行させる請求項８に記載のプログラム。
  10. 　コンピュータに、
    　一定時間待ち、一定時間が経過したら絞込んだ全装置構成情報管理装置に対して前記仮想統合管理装置に保存した処理依頼を再度行なう第８ステップと、
    を実行させる請求項８に記載のプログラム。
PCT/JP2008/056399 2008-03-31 2008-03-31 装置構成情報管理装置へ情報の更新系処理を行なう仮想統合管理装置 WO2009122527A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
PCT/JP2008/056399 WO2009122527A1 (ja) 2008-03-31 2008-03-31 装置構成情報管理装置へ情報の更新系処理を行なう仮想統合管理装置
GB1015946A GB2470865A (en) 2008-03-31 2008-03-31 Virtual integrated management device for performing information update process for device configuration information management device
JP2010505186A JP5077430B2 (ja) 2008-03-31 2008-03-31 管理装置および管理装置のプログラム
US12/884,308 US8650274B2 (en) 2008-03-31 2010-09-17 Virtual integrated management device for performing information update process for device configuration information management device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2008/056399 WO2009122527A1 (ja) 2008-03-31 2008-03-31 装置構成情報管理装置へ情報の更新系処理を行なう仮想統合管理装置

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US12/884,308 Continuation US8650274B2 (en) 2008-03-31 2010-09-17 Virtual integrated management device for performing information update process for device configuration information management device

Publications (1)

Publication Number Publication Date
WO2009122527A1 true WO2009122527A1 (ja) 2009-10-08

Family

ID=41134948

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2008/056399 WO2009122527A1 (ja) 2008-03-31 2008-03-31 装置構成情報管理装置へ情報の更新系処理を行なう仮想統合管理装置

Country Status (4)

Country Link
US (1) US8650274B2 (ja)
JP (1) JP5077430B2 (ja)
GB (1) GB2470865A (ja)
WO (1) WO2009122527A1 (ja)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2476570A (en) * 2009-12-22 2011-06-29 Fujitsu Ltd Configuration information management in a distributed system
JP2011133985A (ja) * 2009-12-22 2011-07-07 Fujitsu Ltd 構成情報管理システム、構成情報管理方法、分散情報管理装置及び分散情報管理プログラム
JP2011197808A (ja) * 2010-03-17 2011-10-06 Fujitsu Ltd 構成情報管理装置、構成情報管理プログラム及び構成情報管理方法
JP5177223B2 (ja) * 2008-06-13 2013-04-03 富士通株式会社 情報処理装置、情報処理プログラム及び方法
JP2013206123A (ja) * 2012-03-28 2013-10-07 Fujitsu Ltd 管理プログラム、管理装置および情報処理システム
JP2015518601A (ja) * 2012-03-28 2015-07-02 ビーエムシー ソフトウェア，インコーポレーテッド 仮想的なデータベースに対するビジネスサービスコンテキストの要求、及び表示

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5146020B2 (ja) * 2008-03-10 2013-02-20 富士通株式会社 情報処理装置、リソース同定プログラム、リソース同定方法
JP5035417B2 (ja) * 2008-07-04 2012-09-26 富士通株式会社 情報処理装置、情報処理プログラム、情報処理方法
US9154942B2 (en) 2008-11-26 2015-10-06 Free Stream Media Corp. Zero configuration communication between a browser and a networked media device
JP5966765B2 (ja) * 2012-08-22 2016-08-10 富士通株式会社 情報処理システム、中継装置、情報処理プログラム、及び情報処理方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10307743A (ja) * 1997-05-09 1998-11-17 Nippon Telegr & Teleph Corp <Ntt> 複数データベース柔軟検索方法及び装置
JP2004280528A (ja) * 2003-03-17 2004-10-07 Hitachi Ltd データベースシステム、サーバ、問い合わせ投入方法及びデータ更新方法
JP2006018607A (ja) * 2004-07-01 2006-01-19 Fujitsu Ltd メタデータエディタプログラムおよびその記録媒体、メタデータ編集方法ならびにメタデータ編集装置

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06119227A (ja) 1992-10-06 1994-04-28 Oki Electric Ind Co Ltd 分散データベース制御システム
US6085238A (en) * 1996-04-23 2000-07-04 Matsushita Electric Works, Ltd. Virtual LAN system
US6892230B1 (en) * 1999-06-11 2005-05-10 Microsoft Corporation Dynamic self-configuration for ad hoc peer networking using mark-up language formated description messages
US7194538B1 (en) * 2002-06-04 2007-03-20 Veritas Operating Corporation Storage area network (SAN) management system for discovering SAN components using a SAN management server
US20070208832A1 (en) * 2006-01-31 2007-09-06 Bea Systems, Inc. RFID edge server allowing configuration updates without restart
WO2009144821A1 (ja) * 2008-05-30 2009-12-03 富士通株式会社 装置構成情報最適配置方法及び装置構成情報最適配置システム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10307743A (ja) * 1997-05-09 1998-11-17 Nippon Telegr & Teleph Corp <Ntt> 複数データベース柔軟検索方法及び装置
JP2004280528A (ja) * 2003-03-17 2004-10-07 Hitachi Ltd データベースシステム、サーバ、問い合わせ投入方法及びデータ更新方法
JP2006018607A (ja) * 2004-07-01 2006-01-19 Fujitsu Ltd メタデータエディタプログラムおよびその記録媒体、メタデータ編集方法ならびにメタデータ編集装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
YASUTAKA TANIUCHI ET AL.: "Data Center Togo Joho Kiban", FUJITSU, vol. 59, no. 1, 10 January 2008 (2008-01-10), pages 45 - 49, XP008141553 *

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5177223B2 (ja) * 2008-06-13 2013-04-03 富士通株式会社 情報処理装置、情報処理プログラム及び方法
GB2476570A (en) * 2009-12-22 2011-06-29 Fujitsu Ltd Configuration information management in a distributed system
JP2011133985A (ja) * 2009-12-22 2011-07-07 Fujitsu Ltd 構成情報管理システム、構成情報管理方法、分散情報管理装置及び分散情報管理プログラム
US8782079B2 (en) 2009-12-22 2014-07-15 Fujitsu Limited Configuration information management device, distributed information management system and method
JP2011197808A (ja) * 2010-03-17 2011-10-06 Fujitsu Ltd 構成情報管理装置、構成情報管理プログラム及び構成情報管理方法
JP2013206123A (ja) * 2012-03-28 2013-10-07 Fujitsu Ltd 管理プログラム、管理装置および情報処理システム
JP2015518601A (ja) * 2012-03-28 2015-07-02 ビーエムシー ソフトウェア，インコーポレーテッド 仮想的なデータベースに対するビジネスサービスコンテキストの要求、及び表示
US9075857B2 (en) 2012-03-28 2015-07-07 Fujitsu Limited Computer-readable non-transitory medium storing therein a control program, management apparatus, and information processing system

Also Published As

Publication number Publication date
US20110004675A1 (en) 2011-01-06
JP5077430B2 (ja) 2012-11-21
JPWO2009122527A1 (ja) 2011-07-28
GB201015946D0 (en) 2010-11-03
GB2470865A (en) 2010-12-08
US8650274B2 (en) 2014-02-11

Similar Documents

Publication Publication Date Title
JP5077430B2 (ja) 管理装置および管理装置のプログラム
US9715518B2 (en) Cross-ACL multi-master replication
US10078676B2 (en) Schema evolution in multi-tenant environment
KR20200096309A (ko) 분산된 데이터 스토어 내의 버젼형 계층 데이터 구조
US10275347B2 (en) System, method and computer program product for managing caches
CN110555015B (zh) 数据库实体管理方法、装置、电子设备及存储介质
JP2006178554A (ja) 分散ポリシー連携方法
WO2014177515A1 (en) Integration database framework
US10705832B2 (en) Efficient storage and analysis of source code modification history data
US20060271384A1 (en) Reference data aggregate service population
US11811851B2 (en) Method and system for enforcing governance across multiple content repositories using a content broker
US20180300369A1 (en) Secure query interface
US20110276572A1 (en) Configuration management device, medium and method
US10185735B2 (en) Distributed database system and a non-transitory computer readable medium
CN113641686B (zh) 数据处理方法、装置、电子设备、存储介质及程序产品
US9846695B2 (en) Information processing apparatus, control method, and storage medium storing program
AU2022203732B2 (en) System and method for reference validation of spreadsheets
JP5316015B2 (ja) 情報処理装置及びプログラム
JP2003036190A (ja) アンドゥ処理システム及びアンドゥ処理方法
JP5818750B2 (ja) 検索装置、検索方法および検索プログラム
Brumm et al. Updating or Deleting a Table
JP5625858B2 (ja) 構成要素の管理装置、管理プログラムおよび管理方法
JPWO2008007735A1 (ja) 情報検索システム
JP2017167958A (ja) データベースクライアント、データベースクライアントプログラム、データベースクライアント制御方法及びデータベースシステム
JPH1165913A (ja) 分散データベースシステム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08739512

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2010505186

Country of ref document: JP

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 1015946

Country of ref document: GB

Kind code of ref document: A

Free format text: PCT FILING DATE = 20080331

WWE Wipo information: entry into national phase

Ref document number: 1015946.5

Country of ref document: GB

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08739512

Country of ref document: EP

Kind code of ref document: A1