用于在配置管理数据库中识别管理域的方法和系统.pdf

上传人:54 文档编号:966223 上传时间:2018-03-21 格式:PDF 页数:27 大小:1.21MB
返回 下载 相关 举报
摘要
申请专利号:

CN200810108849.5

申请日:

2008.05.29

公开号:

CN101593182A

公开日:

2009.12.02

当前法律状态:

终止

有效性:

无权

法律详情:

专利权的视为放弃IPC(主分类):G06F 17/30放弃生效日:20091202|||实质审查的生效|||公开

IPC分类号:

G06F17/30

主分类号:

G06F17/30

申请人:

国际商业机器公司

发明人:

杨 博; 王 浩; 刘 亮; 刘培妮; 陈 滢; 唐雪峰

地址:

美国纽约阿芒克

优先权:

专利代理机构:

北京市金杜律师事务所

代理人:

吴立明

PDF下载: PDF下载
内容摘要

本发明公开了一种用于在配置管理数据库中识别管理域的方法和系统。所述方法包括:基于所述配置管理数据库中的公共数据模型,对与应用对应的一个或多个已定义管理域进行抽象,以得到表示所述公共数据模型的类和所述类之间关系的拓扑;利用所述拓扑,在配置管理数据库中查找匹配的管理域;以及向用户提供所述匹配的管理域。本发明的方法和系统能够帮助普通用户更加准确、有效地识别管理域,从而节约了劳动成本,并提高了管理效率。另外,由于通过抽象提供了可以作为标准的拓扑,所以能够使服务水平一致化,并且能够降低管理失误的危险。另外,通过进一步地进行相似度评估,为用户提供了更多有用的信息。

权利要求书

1.  一种用于在配置管理数据库中识别管理域的方法,包括:
基于所述配置管理数据库中的公共数据模型,对与应用对应的一个或多个已定义管理域进行抽象,以得到表示所述公共数据模型的类和所述类之间关系的拓扑;
利用所述拓扑,在配置管理数据库中查找匹配的管理域;以及
向用户提供所述匹配的管理域。

2.
  根据权利要求1所述的方法,所述对与应用对应的一个或多个已定义管理域进行抽象包括:
获取所述一个或多个已定义管理域的公共部件及其之间的关系;以及
基于公共数据模型获取所述公共部件的公共属性,
其中所述公共属性表示所述拓扑中的类,所述公共部件之间的关系表示所述类之间的关系。

3.
  根据权利要求1所述的方法,其中所述查找匹配的管理域包括:
基于所述拓扑中的类,从配置管理数据库中获取部件;
基于所述拓扑中类之间的关系,从所述获取的部件中滤除不满足所述关系的部件,以得到匹配的管理域。

4.
  根据权利要求1所述的方法,进一步包括:
评估所述匹配的管理域相对于所述一个或多个已定义管理域的相似度,其中基于所述相似度来向用户提供所述匹配的管理域。

5.
  根据权利要求4所述的方法,其中所述评估相似度基于期望管理域中的关键字、所述期望管理域的管理信息、所述一个或多个管理域的优先级中的任一种或者多种来执行。

6.
  根据权利要求5所述的方法,其中所述期望管理域的管理信息包括管理员信息和部件属性。

7.
  根据权利要求1所述的方法,其中所述一个或多个已定义管理域来自同一配置管理数据库,或者来自具有相同或相似公共数据模型的不同配置管理数据库。

8.
  一种用于在配置管理数据库中识别管理域的系统,包括:
拓扑抽象装置,用于基于所述配置管理数据库中的公共数据模型,对与应用对应的一个或多个已定义管理域进行抽象,以得到表示所述公共数据模型的类和所述类之间关系的拓扑;
管理域查找装置,用于利用所述拓扑在配置管理数据库中查找匹配的管理域;以及
管理域提供装置,用于向用户提供所述匹配的管理域。

9.
  根据权利要求8所述的系统,所述拓扑抽象装置进一步用于:
获取所述一个或多个已定义管理域的公共部件及其之间的关系;以及
基于公共数据模型获取所述公共部件的公共属性,
其中所述公共属性表示所述拓扑中的类,所述公共部件之间的关系表示所述类之间的关系。

10.
  根据权利要求8所述的系统,其中所述管理域查找装置包括:
部件获取装置,用于基于所述拓扑中的类,从配置管理数据库中获取部件;
部件过滤装置,用于基于所述拓扑中类之间的关系,从所述获取的部件中滤除不满足所述关系的部件,以得到匹配的管理域。

11.
  根据权利要求8所述的系统,进一步包括:
相似度评估装置,用于评估所述匹配的管理域相对于所述一个或多个已定义管理域的相似度,其中所述管理域提供装置基于所述相似度来向用户提供所述匹配的管理域。

12.
  根据权利要求11所述的系统,其中所述相似度评估装置基于期望管理域中的关键字、属于所述期望管理域的管理信息、所述一个或多个管理域的优先级中的任一种或者多种来执行相似度评估。

13.
  根据权利要求12所述的系统,其中所述期望管理域的管理信息包括管理员信息和部件属性。

14.
  根据权利要求8所述的系统,其中所述一个或多个已定义管理域来自同一配置管理数据库,或者来自具有相同或相似公共数据模型的不同配置管理数据库。

说明书

用于在配置管理数据库中识别管理域的方法和系统
技术领域
本发明涉及配置管理技术,更具体地,本发明涉及一种用于在配置管理数据库中(Configuration Management Database,CMDB)识别管理域的方法和系统。
背景技术
近年来,信息技术(Information Technology,IT)的快速发展极大地促进了企业的运营效率的提高。另一方面,随着企业的快速发展,对于IT服务的要求也越来越高。CMDB正是在这种情况下出现的一种用于记录IT系统中所有部件的相关信息的数据库系统。
图1示意性地示出了现有技术中的CMDB环境的一个实例的图示。在该图示中,附图标记101指示企业IT系统中的IT基础设施。发现工具102搜集IT基础设施的配置信息,并将发现的配置信息存储在CMDB 103中,从而形成包含该IT基础设施中每个部件(诸如服务器、数据库、软件、硬件、中间件等)的相关细节以及各部件之间的相关细节(即,部件之间的关系)的数据库。CMDB 103中的配置信息可以诸如以列表的方式呈现给管理员(或者专家)104,以便于查看。然后,管理员104可以根据其专业知识和经验从列表中选出期望的配置信息,从而形成与特定应用相关的管理域105。
CMDB中存储着与企业IT系统中的所有部件相关的信息,因而它是一个非常庞大的数据库,要从中选择用于特定应用的管理域,并不是一件简单的事情。在现有技术中,这种选择主要采用两种方式。一种方式是人工选择,即,以类似于数据库操作的方式,从CMDB数据库中手动选择管理该特定应用所涉及的所有部件,而这需要对该特定应用以及对IT基础设施的部件的情况都非常了解。对于具有大量专业知识和丰富经验的管理员来讲,完成这种选择可能不是一件很困难的事情,但是对于新手或者还不熟悉企业情况的人员来讲,这就是一件既困难又耗费精力的工作。由于管理域的识别是企业IT管理中的一件频繁且要求较高技巧的工作,所以手工选择方式成本很高,并且管理效率很低。
现有技术中的另一方式是基于模板的自动化方式,诸如基于Tivoli应用依赖性发现管理器(Tivoli Application DependencyDiscovery Manager,TADDM)用户模板。然而,基于这种模板而找到的管理域等同于“特征节点的集合”,由于没有考虑节点之间的关系,所以通常使得得到的结果不准确。
为此,现有技术中,存在一种对于从CMDB中更加准确地识别管理域的需求。
发明内容
为此,本发明针对一种用于在配置管理数据库中识别管理域的方法和系统,其能够提供更加准确的管理域。
根据本发明的一个方面,提供了一种用于在配置管理数据库中识别管理域的方法,包括:基于所述配置管理数据库中的公共数据模型,对与应用对应的一个或多个已定义管理域进行抽象,以得到表示所述公共数据模型的类和所述类之间关系的拓扑;利用所述拓扑,在配置管理数据库中查找匹配的管理域;以及向用户提供所述匹配的管理域。
在本发明的一个实施例中,所述对与应用对应的一个或多个已定义管理域进行抽象包括:获取所述一个或多个已定义管理域的公共部件及其之间的关系;以及基于公共数据模型获取所述公共部件的公共属性,其中所述公共属性表示所述拓扑中的类,所述公共部件之间的关系表示所述类之间的关系。
在本发明的另一实施例中,其中所述查找匹配的管理域包括:基于所述拓扑中的类,从配置管理数据库中获取部件;基于所述拓扑中类之间的关系,从所述获取的部件中滤除不满足所述关系的部件,以得到匹配的管理域。
在本发明的又一实施例中,所述方法进一步包括:评估所述匹配的管理域相对于所述一个或多个已定义管理域的相似度,其中基于所述相似度来向用户提供所述匹配的管理域。
在本发明的再一实施例中,其中所述评估相似度基于期望管理域中的关键字、所述期望管理域的管理信息、所述一个或多个管理域的优先级中的任一种或者多种来执行。
在本发明的再一实施例中,其中所述期望管理域的管理信息包括管理员信息和部件属性。
在本发明的另一实施例中,其中所述一个或多个已定义管理域来自同一配置管理数据库,或者来自具有相同或相似公共数据模型的不同配置管理数据库。
根据本发明的另一方面,提供了一种用于在配置管理数据库中识别管理域的系统,包括:拓扑抽象装置,用于基于所述配置管理数据库中的公共数据模型,对与应用对应的一个或多个已定义管理域进行抽象,以得到表示所述公共数据模型的类和所述类之间关系的拓扑;管理域查找装置,用于利用所述拓扑在配置管理数据库中查找匹配的管理域;以及管理域提供装置,用于向用户提供所述匹配的管理域。
在本发明的一个实施例中,所述拓扑抽象装置进一步用于:获取所述一个或多个已定义管理域的公共部件及其之间的关系;以及基于公共数据模型获取所述公共部件的公共属性,其中所述公共属性表示所述拓扑中的类,所述公共部件之间的关系表示所述类之间的关系。
在本发明的另一实施例中,其中所述管理域查找装置包括:部件获取装置,用于基于所述拓扑中的类,从配置管理数据库中获取部件;部件过滤装置,用于基于所述拓扑中类之间的关系,从所述获取的部件中滤除不满足所述关系的部件,以得到匹配的管理域。
在本发明的再一实施例中,所述系统进一步包括:相似度评估装置,用于评估所述匹配的管理域相对于所述一个或多个已定义管理域的相似度,其中所述管理域提供装置基于所述相似度来向用户提供所述匹配的管理域。
在本发明的再一实施例中,其中所述相似度评估装置基于期望管理域中的关键字、属于所述期望管理域的管理信息、所述一个或多个管理域的优先级中的任一种或者多种来执行相似度评估。
在本发明的又一实施例中,其中所述期望管理域的管理信息包括管理员信息和部件属性。
在本发明的另一实施例中,其中所述一个或多个已定义管理域来自同一配置管理数据库,或者来自具有相同或相似公共数据模型的不同配置管理数据库。
本发明的方法和系统是基于对已定义的管理域进行抽象而得到包括类和类之间的关系的拓扑来识别管理域的。因此,能够帮助普通用户更加准确、有效地识别管理域,从而节约了劳动成本、提高了管理效率。另外,由于通过抽象提供可以作为标准的拓扑,所以可以使服务水平一致化,并且降低了管理失误的危险。另外,通过进一步地进行相似度评估,为用户提供了更多有用的信息。
附图说明
通过结合附图对本发明的具体实施例进行详细的描述,本发明的上述以及其他方面和优势将更加明显。
在本发明的附图中,相同的附图标识表示相同或者类似的部件,在附图中:
图1示意性地示出了现有技术中CMDB环境的一个示例的图示;
图2示意性示出了根据本发明一个实施例用于在配置管理数据库中识别管理域的方法的流程图;
图3示意性地示出了与一个管理域示例对应的实例关系图;
图4示意性地示出了与另一管理域示例对应的实例关系图;
图5示意性地示出了在配置管理库中定义的公共数据模型,其与图3所示的一个管理域示例对应;
图6示意性地示出了在配置管理库中定义的公共数据模型,其与图4所示的另一管理域示例对应;
图7示意性地示出了根据本发明一个实施例对两个管理域示例进行抽象得到的拓扑的图示;
图8示意性地示出了根据本发明一个实施例用于在配置管理数据库中识别管理域的系统的方框图;
图9示意性地示出了根据本发明另一实施例用于在配置管理数据库中识别管理域的系统的方框图;以及
图10示意性地示出了可以实现根据本发明的实施例的计算设备的结构方框图。
具体实施方式
在下文中,将参考附图通过实施例对本发明用于在配置管理数据库中识别管理域的方法和系统进行描述。
首先,将参考图2-图7对本发明用于在配置管理数据库中识别管理域的方法进行描述。图2示意性示出了根据本发明一个实施例用于在配置管理数据库中识别管理域的方法的流程图。
首先在步骤201,基于配置管理数据库中的公共数据模型(例如IBM Tivoli CCMDB Common Data Model;BMC Atrium Common DataModel;HP Common Data Model等现有公共数据模型),对与应用对应的一个或多个已定义管理域进行抽象,以得到表示所述公共数据模型的类和所述类之间关系的拓扑。
已定义的一个或多个管理域已经预先由管理员或者专家定义。在下面,示出了两个已定义的管理域的示例,其中示例1是在线购书系统,示例2是自助银行系统。
示例1:
Online Book instance is SERIAL with
                      Component 1:Online Book
                      Component 2:OB WAS Server
                      Component 3:192.168.100.1:8080
                      Component 4:DB2:book
                      Component 5:X236
                      Relation 1:Deployed To
                      (Component 1,Component 2)
                      Relation 2:Transactional Dependency
                      (Component 2,Component 3)
                      Relation 3:Transactional Dependency
                      (Component 2,Component 4)
                      Relation 4:Installed on
                      (Component 2,Component 5)
                      Description:Apache+WAS+DB2+X236环境内
                      的在线购书系统
End(Online Book)
示例 2:
Home Banking instance is SERIAL with
                      Component 1:Home Banking
                      Component 2:HB WAS Server
                      Component 3:127.0.0.1:80
                      Component 4:Account DB
                      Relation 1:Deployed To
                      (Component 1,Component 2)
                      Relation 2:Transactional Dependency
                      (Component 2,Component 3)
                      Relation 3:Transactional Dependency
                      (Component 2,Component 4)
                      Description:IIS+WAS+DB2环境内的
              自助银行系统
End(Home Banking)
示例1描述了由管理员或者专家定义的在线购书系统的管理域。该管理域包括5个部件,即部件1-5。在该在线购书系统的管理域中,部件1是提供在线购书业务的J2EE网络应用,其被实例化为“在线购书应用”(Online Book,OB);部件2是为该在线购书应用提供平台的网络应用服务器(Web Application Server,WAS),其被实例化为“OB WAS服务器”;部件3是网络服务器,用于为用户提供用于该在线购书应用的交互式接口(诸如,为用户提供业务界面的网站),其被实例化为“192.168.100.1:8080”(即,互联网协议(Internet Protocol,IP)地址为192.168.100.1、端口为8080的网络服务器);部件4是用于存储与该在线购书应用相关的数据的数据库,被实例化为“DB2:book”;部件5是其上安装了OB WAS服务器的计算机,其被实例化为“X236”(即,IBM X236服务器)。
在示例1中,关系1表示部件1部署在部件2上;关系2表示部件2对部件3具有事务依赖性,即部件2进行事务处理要依赖于部件3;类似地,关系3表示部件2对部件4具有事务依赖性;而关系4表示部件2安装在部件5之上。
图3以更加简洁的方式示出了与该示例1的管理域对应的实例关系图,从中可以明确地看出,“在线购书应用”部署在“OB WAS服务器”上,“OB WAS服务器”安装在“X236”上,“OB WAS服务器”进行与在线购书应用相关的事务处理要依赖于“192.168.100.1:8080”以及“DB2:book”。
类似地,示例2描述了由管理员或者专家定义的自助银行系统的管理域。该管理域中包括4个部件,即部件1-4。在该在自助银行系统的管理域中,部件1是提供自助银行(Home Banking,HB)业务的J2EE网络应用,其被实例化为“自助银行应用”;部件2是为该自助银行应用提供平台的网络应用服务器,其被实例化为“HBWAS服务器”;部件3是网络服务器,用于为用户提供针对该自助银行应用的交互式接口,其被实例化为“127.0.0.1:80”(即IP地址为127.0.0.1、端口为80的网络服务器);部件4是用于存储与该自助银行应用相关的数据的数据库,被实例化为“结算DB2”。
在该示例2中,关系1表示部件1部署在部件2上;关系2表示部件2对部件3具有事务依赖性,即部件2进行事务处理要依赖于部件3;类似地,关系3表示部件2对部件4具有事务依赖性。
图4以更加简洁的方式示出了与示例2的该管理域对应的实例关系图,从中可以明确地看出,“自助银行应用”部署在“HB WAS服务器”上,“HB WAS服务器”进行与自助银行应用相关的事务处理要依赖于“127.0.0.1:80”以及“结算DB2”。
下面将针对给出的管理域的示例1和示例2来描述对管理域进行抽象的方法。
首先,获取所述一个或多个已定义管理域的公共部件及其之间的关系。从上面对示例1和示例2中的描述可以看到,对于示例1和示例2中给出的管理域,公共部件是部件1、部件2、部件3和部件4,其间的关系是关系1、关系2、关系3。
接着,基于公共数据模型获取所述公共部件的公共属性。图5和图6示出了与示例1和示例2对应的公共数据模型。所示公共数据模型是四层公共模型,其中最下层表示部件的实例,上面的各层表示该实例的更高层的类。
在图5中,“在线购书应用”是部件1的实例,“在线购书应用”的上一层类是“WebSphereJ2EE应用”,“WebSphereJ2EE应用”的上一层类是“WebSphere”,“WebSphere”的上一层类是“J2EE”。“OB WAS服务器”是部件2的实例,“OB WAS服务器”的上一层类是“WebSphereServer”,“WebSphereServer”的上一层类是“WebSphere”,“WebSphere”的上一层类是“J2EE”。“192.168.100.1:8080”是部件3的实例,“192.168.100.1:8080”的上一层类是“ApacheServer”,“ApacheServer”的上一层类是“Apache”,“Apache”的上一层类是“Web”。“DB2:book”是部件4的实例,“DB2:book”的上一层类是“DB2Instance”,“DB2Instance”的上一层类是“DB2”,“DB2”的上一层类是“DB”。“X236”是部件5的实例,“X236”的上一层类是“Windows操作系统”,“Windows操作系统”的上一层是“Windows”,“Windows”的上一层是“System”。
类似地,在图6中,“自助银行应用”是部件1的实例,“自助银行应用”的上一层类是“WebSphereJ2EE应用”,“WebSphereJ2EE应用”的上一层类是“WebSphere”,“WebSphere”的上一层类是“J2EE”。“HB WAS服务器”是部件2的实例,“HB WAS服务器”的上一层类是“WebSphereServer”,“WebSphereServer”的上一层类是“WebSphere”,“WebSphere”的上一层类是“J2EE”。“127.0.0.1:80”是部件3的实例,“127.0.0.1:80”的上一层类是“IISWebServer”,“IISWebServer”的上一层类是“IIS”,“IIS”的上一层类是“Web”。“结算DB”是部件4的实例,“结算DB”的上一层类是“DB2Instance”,“DB2Instance”的上一层类是“DB2”,“DB2”的上一层类是“DB”。
从图5和图6可以看出,对于公共部件中其实例分别为“在线购书应用”和“ 自助银行应用”的部件1,第二层类“WebSphereJ2EE应用”即相同。因此,可以将该第二层类“WebSphereJ2EE应用”作为它们的公共属性。类似地,对于公共部件中其实例分别为“OBWAS服务器”和“HB WAS服务器”的部件2,可以将相同的第二层类“WebSphere服务器”作为它们的公共属性。类似地,对于公共部件中其实例分别为“192.168.100.1:8080”和“127.0.0.1:80”的部件3,可以将相同的第四层类“Web”作为它们的公共属性。类似地,对于公共部件中其实例分别为“DB2:book”和“结算DB2”的公共部件的部件4,可以将相同的第二层类“Db2Instance”作为它们的公共属性。
然后,根据上面得到的公共部件的公共属性以及它们之间的关系来形成拓扑,其中拓扑中的类由公共属性表示,类之间的关系由所述公共部件之间的关系表示。下面示出了基于图5和图6示出的公共数据模型对示例1和示例2抽象得到的拓扑的代码描述。
拓扑示例:
Class Online Trade Application{}is SERIAL with
                        Component 1:WebSphereJ2EE Application
                        Component 2:WebSphereServer
                        Component 3:Web
                        Component 4:Db2Instance
                        Relation 1:Deployed To
                        (Component 1,Component 2)
                        Relation 2:Transactional Dependency
                        (Component 2,Component 3)
                        Relation 3:Transactional Dependency
                        (Component 2,Component 4)
                        Description:Web+WAS+DB2构建的在线应用系统
End(Online Trade Application)
另外,图7示出了与上述拓扑示例对应的拓扑示意图。从图7可以非常清楚的看出该拓扑中的类和类之间的关系。
接着,在步骤202,利用所述拓扑,在配置管理数据库中查找匹配的管理域。
在一个实施例中,可以基于所得到的拓扑中的类,从配置管理数据库中获取部件,所获取的部件是其公共数据模型包括拓扑中的类的部件。对于上面给出的拓扑示例,在配置管理数据库中搜索类分别为WebSphereJ2EE应用、WebSphere服务器、Web以及Db2Instance的所有部件。然后基于所述拓扑中类之间的关系,从所述获取的部件中滤除不满足关系的部件,以得到匹配的管理域。对于上面给出的拓扑示例,则利用关系1、关系2和关系3作为条件对所获取的部件进行进一步过滤,以滤除不满足关系1-3的部件,进而得到满足关系1-3的匹配的管理域。
在另一实施例中,可以基于所得到的拓扑中的类及类之间的关系,在一个步骤中同时利用这两个条件进行搜索,以从管理数据库中获取满足关系的部件,进而得到匹配的管理域。
另外,可以进一步在步骤203进行判定,以确定匹配的管理域是否已经满足了要求,即用户对得到的结果是否满意,如果用户认为已经满足了要求,则可以在步骤205向用户提供匹配的管理域。
另一方面,如果不满足要求,则可以在步骤204评估所述匹配的管理域相对于所述一个或多个已定义管理域的相似度,以便基于所述相似度来向用户提供所述匹配的管理域。该相似度评估可以采用多种策略,例如可以基于期望管理域中的关键字、所述期望管理域的管理信息、所述一个或多个管理域的优先级中的任一种或多种来执行。
在一个实施例中,期望的管理域是在线购书系统的管理域,因此可以使用“书”作为关键字进行搜索,相似度就是匹配的管理域与该关键字的关系密切程度。
在另一实施例中,利用管理员信息来执行相似度评估。例如,期望的管理域中的服务器是由管理员“John”管理的,因此可以以管理员的姓名来进行相似度评估,管理员姓名为“John”的管理域具有较高的相似度。在再一实施例中,利用部件属性来执行相似度评估。例如,期望的管理域中的数据库是DB2数据库,因此可以利用数据库的类型来进行相似度评估,数据库类型为DB2的管理域具有较高的相似度。
在又一实施例中,对上述专家定义的一个或更多管理域设置有优先级,与优先级较高的已定义管理域最匹配的匹配管理域具有较高相似度。
另外,还可以将上述策略中的一个或多个结合来进行相似度评估。
在相似度评估之后,在步骤205,基于相似度,向用户提供所述匹配的管理域。例如,可以按照相似度的大小,来确定提供匹配的管理域的前后顺序。
需要说明的是,上面提及的判断和相似度评估并不是实现本发明的目的所必须的,这只是本发明的一个优选实施例。在另一实施例中,在查找到匹配的管理域之后,直接向用户提供匹配的管理域,以供用户查看。并且,在存在多个匹配管理域的情况下,也可以由用户来选择。
从上面的描述可以看出,本发明旨在利用专家或者管理员的域管理知识来帮助普通用户成功地建立管理域。由于普通用户可以在拓扑的帮助下建立管理域而无需管理员或者专家的帮助,因此使管理员或者专家从这种频繁的管理域建立工作中解脱出来,从而节约了劳动成本、提高了管理效率。并且由于通过抽象提供可以作为标准的拓扑,所以可以使服务水平一致化,并且降低了管理失误的危险。并且相对于基于模板的自动化方法,本发明的方法在进行管理域识别时利用了关系,因此提供了更为准确的识别结果。并且,通过进一步的相似度比较,可以为用户提供更多的有用信息。
需要说明的是,在上述实施例中,由管理员或者专家定义的一个或多个管理域被描述为类似应用系统的管理域,即,在线购书系统和自助银行系统。然而,本发明并不仅限于此。管理域也可以是由一个或多个由管理员或者专家定义的相同应用系统的管理域,例如由两个管理员定义的在线购书应用的管理域。
在上述实施例中,进行拓扑抽象基于的是相同的公共数据模型,即都采用的是四层结构的公共数据模型且其模型建立的理念也相同。因此,所述管理域可以来自同一配置管理数据库,但是本发明并不仅限于,所述管理域也可以来自具有相同公共数据模型的不同配置管理数据库。此外,所述管理域也可以来自具有相似公共数据模型的不同配置管理数据库。换句话讲,公共数据模型并非必定完全相同,其中一个公共数据模型可以比其他公共数据模型可以具有更多、更详细的类,但划分的理念应当相同。即,公共属性可以不是不同层的两个属性。例如,在一个配置管理数据库中,某个公共部件具有4层公共数据模型,其实例为C1,第二至四层的类分别为C2、C3、C4,而在另一配置管理数据库中,其具有5层公共数据模型,其实例为C1,第二至五层的类分别为C1-1、C2、C3、C4,即该5层数据模型比四层数据模型多一个类C1-1。尽管在该一个配置管理数据库中C2是第二层的类,而在该另一配置管理数据库中,C2是第三层的类,但是仍然可以将其作为公共属性。但是如果公共数据模型根本不同,那么就不能找到公共属性,并因此无法形成拓扑。从上面对与拓扑抽象的描述可以看出,进行抽象时所基于的公共数据模型需要基于相同或者相似的理念设计的公共数据模型,否则就无法找到公共属性并因此无法进行抽象。
另外需要说明的是,虽然在上面的描述中,对两个管理域示例进行了抽象,但是本发明并不仅限于此。正如本领域技术人员能够想到的那样,可以对多于两个的管理域进行抽象,也可以对一个管理域进行抽象。在对一个管理域进行抽象的情况下,抽象得到的拓扑仅涉及该管理域本身,利用该拓扑仅能找到与该一个管理域或其拓扑类型完全相同的管理域,但是这仍然实现了本发明的目的。在一个实施例中,由该管理域的部件和部件之间的关系来构成拓扑,因此该拓扑可以用于识别与该管理域完全相同的管理域。在另一实施例中,由在公共数据模型中位于该管理域的部件上一层的类和部件之间的关系来构成拓扑,因此该拓扑可以用于识别与该管理域类型相同的管理域。另外,也可以采用公共数据模型中在部件以上的其他层的类来形成拓扑,而不仅限于部件上一层的类。
下面,将参考图8和来图9来描述本发明用于在配置管理数据库中识别管理域的系统。
图8示意性地示出了根据本发明一个实施例用于在配置管理数据库中识别管理域的系统的方框图。如图8所示,管理域识别系统800包括拓扑抽象装置801,用于基于所述配置管理数据库中的公共数据模型,对与应用对应的一个或多个已定义管理域进行抽象,以得到表示所述公共数据模型的类和所述类之间关系的拓扑;管理域查找装置802,用于利用所述拓扑在配置管理数据库中查找匹配的管理域;以及管理域提供装置803,向用户提供所述匹配的管理域。
图9还示意性地示出了根据本发明另一实施例用于在配置管理数据库中识别管理域的系统的方框图。在图9,管理域识别系统900包括:拓扑抽象装置901,其对应于图8的拓扑抽象装置801;管理域查找装置902,其对应于图8的管理域查找装置802;管理域提供装置903,其对应于图8的管理域提供装置803。另外,管理域识别系统900还包括相似度评估装置904,用于评估所述匹配的管理域相对于所述一个或多个已定义管理域的相似度,其中所述管理域提供装置903基于所述相似度来向用户提供所述匹配的管理域。
在本发明的一个实施例中,拓扑抽象装置801、901进一步用于:获取所述一个或多个已定义管理域的公共部件及其之间的关系;以及基于公共数据模型获取所述公共部件的公共属性,其中所述公共属性表示所述拓扑中的类,所述公共部件之间的关系表示所述类之间的关系。
在本发明的另一实施例中,其中所述管理域查找装置802、902包括:部件获取装置,用于基于所述拓扑中的类,从配置管理数据库中获取部件;部件过滤装置,用于基于所述拓扑中类之间的关系,从所述获取的部件中滤除不满足所述关系的部件,以得到匹配的管理域。
在本发明的再一实施例中,其中所述相似度评估装置904基于期望管理域中的关键字、属于所述期望管理域的管理信息、所述一个或多个管理域的优先级中的任一种或者多种来执行相似度评估。
在本发明的又一实施例中,其中所述期望管理域的管理信息包括管理员信息和部件属性。
在本发明的另一实施例中,其中所述一个或多个已定义管理域来自同一配置管理数据库,或者来自具有相同或相似公共数据模型的不同配置管理数据库。
关于管理域识别系统中各个部件的具体操作请参考上面对本明用于在配置管理数据库中识别管理域的方法的相关描述。
从以上描述可以看出,本发明的管理域识别系统能够帮助普通用户更加准确、有效地识别管理域,从而节约了劳动成本并提高了管理效率。另外,由于通过抽象提供了可以作为标准的拓扑,所以可以使服务水平一致化,并且降低了管理失误的危险。并且,通过进一步地进行相似度评估,为用户提供了更多有用的信息。
下面,将参考图10来描述可以实现本发明的计算机设备。图10示意性示出了可以实现根据本发明的实施例的计算设备的结构方框图。
图10中所示的计算机系统包括CPU(中央处理单元)1001、RAM(随机存取存储器)1002、ROM(只读存储器)1003、系统总线1004、硬盘控制器1005、键盘控制器1006、串行接口控制器1007、并行接口控制器1008、显示器控制器1009、硬盘1010、键盘1011、串行外部设备1012、并行外部设备1013和显示器1014。
在这些部件中,与系统总线1004相连的有CPU 1001、RAM1002、ROM 1003、硬盘控制器1005、键盘控制器1006、串行接口控制器1007、并行接口控制器1008和显示器控制器1009。硬盘1010与硬盘控制器1005相连,键盘1011与键盘控制器1006相连,串行外部设备1012与串行接口控制器1007相连,并行外部设备1013与并行接口控制器1008相连,以及显示器1014与显示器控制器1009相连。
图10所述的结构方框图仅仅为了示例的目的而示出的,并非是对本发明的限制。在一些情况下,可以根据需要添加或者减少其中的一些设备。
此外,本发明的实施例可以以软件、硬件或者软件和硬件的结合来实现。硬件部分可以利用专用逻辑来实现;软件部分可以存储在存储器中,由适当的指令执行系统,例如微处理器或者专用设计硬件来执行。
虽然已经参考目前考虑到的实施例描述了本发明,但是应该理解本发明不限于所公开的实施例。相反,本发明旨在涵盖所附权利要求的精神和范围内所包括的各种修改和等同布置。以下权利要求的范围符合最广泛解释,以便包含所有这样的修改及等同结构和功能。

用于在配置管理数据库中识别管理域的方法和系统.pdf_第1页
第1页 / 共27页
用于在配置管理数据库中识别管理域的方法和系统.pdf_第2页
第2页 / 共27页
用于在配置管理数据库中识别管理域的方法和系统.pdf_第3页
第3页 / 共27页
点击查看更多>>
资源描述

《用于在配置管理数据库中识别管理域的方法和系统.pdf》由会员分享,可在线阅读,更多相关《用于在配置管理数据库中识别管理域的方法和系统.pdf(27页珍藏版)》请在专利查询网上搜索。

本发明公开了一种用于在配置管理数据库中识别管理域的方法和系统。所述方法包括:基于所述配置管理数据库中的公共数据模型,对与应用对应的一个或多个已定义管理域进行抽象,以得到表示所述公共数据模型的类和所述类之间关系的拓扑;利用所述拓扑,在配置管理数据库中查找匹配的管理域;以及向用户提供所述匹配的管理域。本发明的方法和系统能够帮助普通用户更加准确、有效地识别管理域,从而节约了劳动成本,并提高了管理效率。另。

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 物理 > 计算;推算;计数


copyright@ 2017-2020 zhuanlichaxun.net网站版权所有
经营许可证编号:粤ICP备2021068784号-1