发明内容
本发明的一个目标是提供一种系统,用于使无IT技能或低IT技能的人员有效地处理资源管理任务。
本发明的另一个目标是提供一种系统,其允许容易地规定和可视化地显现管理策略。
本发明的再一个目标是提供对个别策略元素(即事件、条件和动作)的访问控制。
本发明的进一步的目标是提供一种机制,通过这种机制,策略元素(事件、条件和动作)可以个别地与分布式资源相联系,并且这些策略元素可以在集中管理的策略执行装置中被采用和处理。
根据本发明的一个方面,提供了一种使用多个策略来管理资源的系统,所述策略存储在一策略数据库中,所述策略是由事件、条件和动作规定的,该系统包括:
第一设备,用于使一用户能够以一种直观的方式规定、修改、删除和可视化所述策略;
第二设备,用于部署由所述用户规定的策略,该第二设备包括:
转换器,用于将以一直观方式规定的策略转换为可以直接存储在所述策略数据库中的格式;
第三设备,用于执行所述已部署的策略;以及
接口,用于在所述资源与所述第一设备、第二设备和第三设备之间提供接口。
根据本发明的另一方面,提供了一种用于使用多个策略来管理资源的方法,所述策略存储在一策略数据库中,所述策略是由事件、条件和动作规定的,该方法包括:
以一种直观的方式规定策略;
将以所述直观的方式规定的所述策略转换为可以直接存储在所述策略数据库中的格式;
验证所述规定的策略为无冲突的策略;
将无冲突的策略部署到所述策略数据库中;以及
执行存储在所述策略数据库中的所述策略,所述策略是在发生了与所述策略相应的一事件时执行的。
根据本发明的再一方面,提供了一种使用多个策略来管理资源的系统,所述策略存储在一策略数据库中,所述策略是由事件、条件和动作规定的,该系统包括:
多个客户端机器,其使得一用户能够以一种直观的方式规定、修改和可视化所述策略;
与所述多个客户端机器中的每一个连接的一服务器,该服务器包括:
第一设备,用于部署所述已创建的策略,该第一设备包括一转换器,该转换器用于将以一直观方式规定的策略转换为以一关系型查询格式规定的策略,该格式可以直接存储在所述策略数据库中;
第二设备,用于执行所述已部署的策略;以及
接口,用于在资源与所述多个客户端机器、所述转换器、所述第一设备和所述第二设备之间提供接口。
根据本发明的另一个方面,提供了一种用于使用多个策略来管理资源的基于策略的系统,所述策略存储在一策略数据库中,所述策略是由事件、条件和动作规定的,该系统具有多个客户端机器,该些客户端机器使得用户能够以一种直观的方式规定、修改和可视化所述策略,该系统进一步包括:
与所述多个客户端机器中的每一个连接的一服务器,该服务器包括:
第一单元,用于部署所述已创建的策略,该第一单元包括一转换器,该转换器用于将以一直观方式规定的策略转换为可以直接存储在一策略数据库中的格式;
第二单元,用于执行已部署的策略,其中策略的执行导致对资源的管理;以及
接口,用于在资源与所述第一单元和所述第二单元之间提供接口,所述资源包括一策略数据库,该策略数据库以一关系型格式存储所述已部署的策略。
根据本发明的再一方面,提供了一种用于管理多个资源的基于策略的系统,所述系统包括与多个客户端机器连接的一服务器,该服务器包括用于在一策略数据库中部署策略的第一设备,该第一设备包括一转换器,该转换器用于将以一直观方式规定的策略转换为以一种关系型格式规定的策略,其中所述客户端机器中的每一个包括:
第一组件,用于使得一用户可以所述直观的方式规定、修改和可视化策略,其中所述第一组件包括:
多个用户接口,用于从所述用户接受命令和数据;以及
用于将预先规定的一组系统命令映射到多个用户接口的单元,其中一个系统命令映射到至少一个用户接口;
第二组件,用于与一服务器交换信息,以便规定、修改和可视化策略。
根据本发明的另一方面,提供了一种使用多个策略来管理资源的系统,所述资源包括多个数据库,所述策略是由事件、条件和动作规定的,所述策略包括用于管理资源的记录保持策略,所述策略包括用于控制对资源的访问的访问控制策略,该系统包括:
第一组件,用于使得用户可以一直观的方式规定、修改、删除和可视化所述策略;
第二组件,用于部署由所述用户规定的策略,该第二组件包括:
转换器,用于将以所述直观方式规定的策略转换为以关系型格式规定的策略;
第三组件,用于执行已部署的策略;以及
第四组件,用于在所述资源与所述第一组件、所述第二组件和所述第三组件之间提供接口。
根据本发明的再一方面,提供了一种用于执行使用多个策略来管理资源的方法的计算机程序产品,所述策略存储在一策略数据库中,所述策略是由事件、条件和动作规定的,所述方法包括:
使用户能够以直观的方式规定、修改、删除和可视化所述策略;
部署由所述用户规定的所述策略,其进一步包括:
将以所述直观方式规定的策略转化为可以直接存储在所述策略数据库中的格式;
执行已部署的策略;以及
在所述资源与所述用户之间提供接口。
具体实施方式
本发明提供了一用户友好的机制,藉此非IT专家者可以规定、修改和执行管理任务。本发明提供了灵活的基于策略的机制,用于管理诸如数据库、信息库、应用模块等资源。本系统也可以用于规定用于不同资源上的事务处理以及用于在诸系统中传输数据的策略。
策略包括事件规定、触发条件和一旦事件发生且相应的条件满足时将采取的动作。
策略的例子可以是:
示例策略:如果在一刑事数据库中报告了一犯罪,则通知当地警官。
在该例中,动作(报告当地警官)是在发生了事件(在数据库中报告了犯罪)时采取的。
示例策略:在每年第一天的上午9点,对于存储时间已超过5年的税务记录,如果在过去5年内没有向该纳税人发出过通知,则将该税务记录存档。
在该策略中,随着事件的发生(每年的第一天的上午9点),对存储时间超过5年的记录检查其条件(在过去5年内没有向纳税人发出过通知),并采取动作(将税务记录存档)。
如上例所述的事件可被定义为一原子实体,即它或者完全发生,或者完全不发生。事件可以是基本事件,也可以是基本事件的组合,称为复合事件。
基本事件是不能分解为进一步的独立事件的事件。基本事件可以有3种类型,即数据库事件、时间事件和由外部通知产生的事件。数据库事件包括对数据库的插入、删除、访问和更新操作。时间事件是其发生依赖于时间的事件。外部通知是应用规定的事件。外部通知的形式是来自外部环境的“中断”,其中外部环境由排除了本机数据库(native database)(在其中执行插入、更新和删除操作)的该域组成。
复合事件可以通过在基本事件上使用逻辑运算符如OR、AND、ANY、NOT、TIMES、SEQUENCE来规定。
具有一复合事件的策略的例子如下:每当一人被一公司X雇佣(事件1),且每当新雇员适应培训的日期已确定(事件2)时,则向该人发送一电子邮件,通过他适应培训的日期(动作)。注意在本示例策略中,条件总是真的。
本发明也提供了与记录保持和访问控制有关的策略。与记录保持有关的策略包括规定这样的策略,其处理在数据库和信息库中插入、更新和删除记录。这种策略的一个例子可以是:每当在刑事数据库中添加了一人员条目(事件),而且该人所犯罪的类型是涉及5万美元或以上的偷窃时,则将其通知税务检查官(动作)。
访问控制策略包括这样的策略,其涉及规定对数据或对访问资源的访问控制。这种策略的一例子是-“属于公司财务部门的用户只能访问工资数据库,并规定与雇员工资有关的策略”。访问控制可以是在事件和/或条件和/或动作水平上。例如,可能不被允许一般用户(不同于系统管理员)规定这样的动作:删除由另一用户生成的策略。
以上策略的例子只是为了描述可以根据本发明规定的策略类型。
图1给出了根据本发明的一优选实施例的基于策略的系统和方法的概览。该系统包括一策略规定层102、一策略部署层104和一策略执行层106。策略规定层102提供了以用户友好的和直观的方式规定策略的功能。实现这一点的一个办法是通过使用图形用户接口(GUI)。GUI使用简单的语言构件(以下拉菜单和可点击标记形式),其不需要用户深刻地理解资源或用于管理这些资源的语言。在本发明中可以使用的GUI的一个例子是使用Java Server Pages(JSP)产生的一HTML页。该HTML页可以是菜单驱动的,以用户可以容易地规定策略的方式。这样,图形用户接口(GUI)使得非IT专家者可以容易地规定策略,以管理诸如数据库或其它信息库等资源。本发明中所使用的GUI结合图5-9进行了解释。
一旦用户已规定了策略,则策略部署层104将这些规定的策略部署在策略数据库108中。在将策略存储在策略数据库108之前,策略部署层104检查在新规定的策略和已经存在于策略数据库108中的策略之间是否存在任何冲突,并只将无冲突的策略存储在策略数据库108中。策略部署过程将在下文更详细地解释。
对于系统中发生的每一事件,检查策略数据库108中是否存在为该事件规定的策略。如果存在该事件的策略,则策略执行层106根据在该策略中指定的条件执行在该策略中规定的动作。策略执行过程将结合图10更详细地描述。
图2示出了大体描述了上述过程的一流程图。用户在步骤200通过一GUI使用简单的语言构件规定一些策略。这些策略在步骤202转换为系统可理解的格式。此后,在步骤204,系统检查新规定或修改的策略和在策略数据库中已经存在的策略之间的任何冲突。然后,在新规定或修改的策略存在冲突的情况下,在步骤206,冲突被解决。解决策略的确切方式将在后面结合图4讨论部署时进行解释。在步骤208,无冲突的策略被部署在策略数据库中。最后,当发生了事件时,策略在步骤210被执行,藉此来管理系统资源。
上面给出了本发明的概述,现在开始在下文中描述实施本发明的环境。
图3示出了由基于策略的系统所管理的计算机网络的简化的示意图,在其中可以实现本发明的一优选实施例。网络302与需要由该基于策略的系统管理的多个资源相连接。资源包括多个实体,如终端站304和服务器306,这些实体由多个中间设备如路由器308、交换器和桥接器310互连在一起。诸如打印机312、扫描器314、信息库和数据库316等资源也可以连接到网络302。该网络也可以连接到因特网318,以便对于处于该网络之外的资源,接收或提供任何服务。
以上给出了本发明的概述和环境,现在更详细地描述本发明。
图4示出了根据本发明的一优选实施例的用于在一分布式环境中管理资源的分层的体系结构的详细图示。该体系结构包括3层,即策略规定层102、策略部署层104和策略执行层106。通过该体系结构,用户可以执行各种任务,如资源注册、识别和事务管理。此外,该分层方法使得更容易遵循面向对象的设计原则。在一优选实施例中,这3层可以部署在一单个服务器实例上。
第一层或策略规定层102具有一策略规定用户接口402,其提供直观的和简单的用户接口,使得用户可以用简单的语言构件规定策略。该语言提供了一组模板,其中构成一合法策略所需的变量值和运算符是通过在用户接口上提供易于使用的下拉菜单选项而从用户获得的。可以指定在策略模板和系统命令之间直接的一一映射,来进行策略规定。一策略语言中的这一组变量和运算符应当遵循在一个元语言(如数据字典或XML DTD)中规定的语法。该元语言规定运算符与变量之间的联系。例如,大于运算符(“>”)可以与数字相联系,而不可与字符串相联系。应当注意的是,上述技术只是根据基础的系统命令构建策略模板的一个简单例子。本领域的技术人员可以理解,也可以使用其它技术,如规定用于构建这些模板的一单独的语法。因此,提供给用户的用户接口使得策略创建过程简单和不易出错,并需要最少的IT技能。通过使用GUI以一种直观方式规定策略的一优选方式结合图5-9作了说明。
策略规定层102也包括授权与验证管理器404,其提供了对用户访问/修改应用数据的权限和权利的单一访问入口。例如,策略数据库108中的任何更新(用于规定/修改策略)需要验证(以检查该用户是否为合法用户),并检查用户权限(以检查用户是否被授予了足够的对事务的权限)。
第二层是策略部署层104,其为部署这些策略提供了应用编程接口(API)。它包括一策略转换器406和一策略部署引擎408。策略转换器406验证由用户通过策略规定层102提供的策略规定。策略转换器406分析由策略规定层102提供给它的策略规定(由用户通过GUI使用简单的语言而规定的)。此后,它提取出关于策略元素的细节,即事件细节(如事件ID、事件名称、事件的所有者等)以及在该事件上规定的条件和动作的细节。提取出的细节随后由策略部署引擎408用于将规定的策略存储在策略数据库108中。这些细节被存储的精确方式将在下文结合表1-5解释。在将策略存储在策略数据库108中之前,冲突检测器410检查已经存在于策略数据库108中的策略和新生成的或修改的策略之间的任何冲突。策略转换器也用于检索存储在策略数据库108中的策略,以便用户可以修改和可视化现存的策略。
当对于相同的事件和条件规定了相互冲突的动作时,就会发生冲突动作。为了更清楚地说明冲突的概念,请考虑以下的例子:设想一个数据库具有个人的纳税记录,其中有关于该个人、已纳税款、雇主姓名、适用的所得税率和其它与纳税有关的信息。设想一策略P1,其由税务部门所采用,其中规定如果一个人的纳税记录的存储时间已超过5年,则所有这些纳税记录将被清除。设想另一个策略P2,在其中刑事部门拥有的一项策略是保留涉及任何财务犯罪的个人的所有财务记录(包括纳税记录),直到与其犯罪有关的所有刑事案件已获解决。如果税务部门和刑事部门在规定这些策略时未曾合作,则对于犯了财务罪且具有来自过去5年的未决刑事案件的一个人,P1和P2将处于冲突中。在这种情况下,一当5年时间已过,策略P1将试图清除该个人的纳税记录,而策略P2将试图保留该个人的纳税记录,直到与其犯罪有关的所有刑事案件都已了结。
这样的冲突既可以在规定策略的阶段也可以在执行策略的阶段进行检测。为了保证在策略规定阶段检测到并解决冲突,在本发明的一优选实施例中规定了元策略。元策略是对策略的一组规则或限制。具有深厚的关于资源和策略的本领域知识的负责人员,如系统管理员,规定元策略。例如,在上述例子中,系统管理员可以规定一个元策略,其设置P2优先于P1。以这种方式,对策略和策略制定者施加了一项约束,藉此来禁止两冲突策略的同时执行。换言之,元策略建立对每一资源对象的诸操作之间的优先权,以及策略的诸创建者之间进行每一资源操作的优先权。考虑上例的一个一般情况,假设有两个管理员AD1和AD2,其中AD1是主要管理员。可以规定这样一个元策略,即AD1规定的策略优先于AD2规定的策略。因而,当AD2规定的策略与AD1规定的策略冲突时,该元策略发挥作用,从而AD1规定的策略获得对AD2规定的策略的优先权。本领域的技术人员可以理解,现有的冲突检测方案,尤其是那些用于在运行时检测和避免冲突的方案,可以经改造而适用于本发明。关于冲突检测的进一步细节可以参阅参考文献-Sin Yeung Lee,Tok Wang Ling‘Refined Terminationdecision in active databases’DEXA 1997;以及Sin Yeung Lee,Tok WangLing‘Unrolling cycles to decide trigger termination’VLDB 1999。
冲突检测器410检查新生成或更新的策略与已经存在于策略数据库中的策略之间可能存在的冲突。在发生冲突的情况下,它通过检查策略数据库中的元策略,来检查是否可以保留新策略。例如,在上例中,如果AD1(管理员1)创建了一策略,该策略与AD2(管理员2)规定并存储在策略数据库中的策略相冲突,则AD1的策略将被执行(因为AD1优先于AD2)。如果AD2创建了一个与已经规定的AD1的策略相冲突的策略,则所产生的策略不会存储在策略数据库中,并且向用户AD2返回一错误消息。此后,策略部署引擎408将无冲突的策略存储在策略数据库108中。以这种方式,策略规定层102和策略部署层104确保将策略存储在策略数据库108中。
资源抽象与通知层420提供了一个用于访问和监视资源的集中管理的系统。所有与资源有关的事件和事务都是借助于该层而被通知的。策略规定层102、策略部署层104和策略执行层106与资源抽象与通知层420相互作用,以访问策略数据库108和其它内部和外部的资源。资源抽象与通知层420通过提供用于查看、更新、删除和插入数据库(包括策略数据库)中的记录的单一访问入口,而帮助维护数据的一致性。该层只在授权与验证管理器404已经验证了用户的真实身份和权限后才允许数据库中的事务处理。该层也通过将数据库中的所有事务和数据变化通知给事件检测器412,来帮助进行事件检测。该层可以通过标准的ODBC技术(如Java平台上使用的JDBC)来实施。
资源抽象与通知层420包括3个模块,即资源访问与事务管理模块、条件评估器框架和动作执行器框架。资源访问与事务管理模块与连接到系统的不同资源相互作用。它也可以与外部应用相互作用。该模块执行许多功能,如通过与数据库相互作用而列出注册的资源、执行资源查询、列出策略、添加新的策略、删除策略、更新策略以及注册外部资源。条件评估器框架列出系统中已注册的条件评估器组件。因为该层是基于“即插即用”原则实现的,所以现有的条件评估器可以删除,其它条件评估器组件可以容易地以后添加。添加和删除条件评估器组件是由一负责人员如系统管理员进行的。动作执行器框架类似于条件评估器框架,只是它列出的是已注册的动作执行器组件,并提供添加和删除动作执行器组件的功能。
第三层是策略执行层106,其提供用于执行在系统中部署的策略的API。事件检测器412侦听资源抽象与通知层420,以获知在系统中发生的所有事件,并检查在策略数据库的事件表中指定的事件(后面将结合表1-5和图10更详细地解释)。对于每一相关事件的发生,该层将事件广播给在系统中注册的相应事件侦听器(如策略部署层104和条件评估器416)。资源抽象与通知层420将系统中的数据库事务和数据改变通知给事件检测器。事件可以是系统内部的或外部的。内部事件是由于该网络的任何组件的状态的任何改变而发生的事件。例如,在一本地数据库中的更新操作是一内部事件。外部事件涉及由于外部系统414如外部温度变化而发生的事件。当检测到一事件后,策略执行引擎106在策略数据库108中搜索所需要的事件标识符及其相应策略。然后,条件评估器416确定与该事件相联系的条件。在多个条件与一个特定事件相联系的情况下,可以并行地评估每个条件。如果条件评估为真,则条件评估器416通知动作执行器418以执行动作。最后,当成功地进行了事件检测和条件评估之后,动作执行器418执行该策略中规定的动作。可以执行的动作的例子有邮件通知(用于发送电子邮件)、数据库事务(插入或更新数据库中的表,如将活动记入日志)、数据存档和备份(执行数据存档和备份操作)等。对于本领域的技术人员显而易见的是,也可以采取其它类型的动作,而不偏离本发明的范围。策略执行过程将结合图10作更详细的描述。
现在借助图5-9和表1-5描述以一种直观方式规定和存储策略的机制。尽管该机制是借助于GUI描述的,其它方法,如果提供了用于规定策略的直观方式,也可以使用,而不偏离本发明的范围。用于策略规定的GUI具有三个主屏幕,一个用于事件规定,一个用于条件规定,一个用于动作规定。每个屏幕具有规定策略的各个策略元素(即事件、条件或动作)的完整功能。因而策略的每个元素被当作一个原子实体,其对该策略的任何其它元素的规定没有直接影响。
图5示出了根据本发明的一优选实施例的用于在规定策略之前验证用户的GUI的一个例子。该GUI处理策略创建者的登录和验证。与每次登录及其角色有关的访问权限被利用来规定事件、条件和动作屏幕。
一旦用户已通过用于验证的GUI而登录,则为其提供以下选项供其选择:规定新的策略,修改现存的策略,删除现存的策略和查看现存的策略;选项取决于访问权限。图6示出了用于为用户提供这种选择的一GUI。用户可以通过点击意欲的超链接来选择意欲的选项。
图7-9示出了当用户从图6所示的GUI中选择“规定新策略”选项之后,显示给该用户的不同GUI的例子。图7示出了用于根据本发明的一优选实施例规定事件的GUI的例子。为了规定一事件,可以在事件规定屏幕中的框702中输入一唯一的事件名称。如果该事件名称已经存在于策略数据库中,则GUI提示用户检查该事件的名称和规定。事件的类型是在“事件类型”下拉框704中指定的。该下拉框可以有3种基本事件类型,即数据库事件、时间事件和外部事件。用户既可以创建一新事件,也可以使用已经存在的(基本的或复合的)事件来创建一新的复合事件。将取决于访问权限的数据库、表、字段以及所允许操作的下拉列表显示给策略创建者,以便指定事件发生的位置。一旦用户已填充了所需的参数并点击了提交按钮706,则事件规定被暂时缓存,而条件屏幕,如图8所示,被显示给用户。
在图8所示的条件屏幕GUI中,用户可以在框802中指定数据库站点(即需要在何处检查条件),在框804中指定部门(数据库的所有者),在框806中指定表(在其上检测条件的表的名称),在框808中指定需检查其值的字段,并在框810中指定特定的二元运算符,以及比较值。使用这些运算符,可以构成复合条件。当点击提交按钮812后,该条件就被存储在一临时的会话变量中,同时服务器向用户提供如图9所示的动作规定屏幕。
如图9所示的动作规定屏幕显示了管理数据所可能需要的4种类型的动作,即通知、清除、存档或数据库动作。数据库动作可进一步分类为插入、删除或更新。通知动作发送一通知(如一电子邮件或即时消息)给一外部系统。该通知可用于在该外部系统上触发一动作。清除动作从数据库中清除记录,而存档动作从主存储器中清除记录,并将其备份在一个次级存储设备中。数据库动作包括插入、删除和更新。每个动作接受固定的一组参数,并将其附加于动作字符串之后。一旦动作字符串被提交,该策略的完整规定就在动作规定框902中显示给该用户。该用户可以通过按下“提交”超链接904而确认一策略。可选地,用户可以在提交一策略之前,通过点击“附加”超链接906而改变任何组件(即事件、条件或动作)的规定。
一旦策略元素通过如图7-9所示的各GUI被规定,它们就被传递给策略转换器。策略转换器包括一符号器(tokenizer)和一分析器。符号器提取策略规定中使用的符号。来自符号器的输出被输入到分析器中,后者接受这些符号,并将它们转换为XML格式。然后,它应用一组规则(产生式规则)以解释策略规定的意义并检查其合法性。为了验证一策略规定的合法性,即检查策略规定的语法是否正确,该分析器可以使用与规定一策略相联系的、预先规定的产生式规则。完成此的一种方法是通过规定适当的文件类型定义(DTD)。DTD是一种语法和语义规则,并可用于验证XML格式的策略规定。
然后将XML输出传递给冲突检测器,其检查该策略,以查看其是否与策略数据库中现存的策略有冲突。当检测到一冲突,而且该冲突无法通过元策略获得解决时,系统向用户返回一错误消息。如果没有检测到冲突(或如果该冲突已通过使用策略数据库中的元策略获得解决),则策略部署引擎使用适当的转换器,将该无冲突的策略(XML格式的)转换为关系型格式,并将其存储在策略数据库中。标准的系统语言,如结构化查询语言(SQL)、数据定义语言(DDL)、数据操纵语言(DML)等,可用于向策略数据库中添加策略。
策略以关系型格式存储在策略数据库中的两个表即事件表和规则表中。每一事件类型(即基本的、复合的和时间的)存储在不同的事件表中。其中每种表的模式显示在表1、2和3中。
事件ID |
整型 |
生成时间 |
变长字符串 |
事件名称 |
变长字符串 |
事件类型 |
变长字符串 |
事件所有者 |
变长字符串 |
数据库名称 |
变长字符串 |
表名称 |
变长字符串 |
表1.基本事件表的模式
事件ID |
整型 |
生成时间 |
变长字符串 |
事件名称 |
变长字符串 |
事件所有者 |
变长字符串 |
基本事件名称 |
变长字符串 |
运算符 |
变长字符串 |
下一ID |
整型 |
表2.复合事件表的模式
生成时间 |
变长字符串 |
事件名称 |
变长字符串 |
事件类型 |
变长字符串 |
事件所有者 |
变长字符串 |
开始时间 |
变长字符串 |
事件发生时间 |
变长字符串 |
结束时间 |
变长字符串 |
表3.时间事件表的模式
“事件ID”是系统生成的事件标识号码,其与“事件名称”结合而构成主键。生成时间是事件的生成时间。事件类型指明该事件将要执行的操作的类型,即插入、更新或删除。“事件所有者”字段存储创建了策略的创建者的姓名。在复合事件表的模式(表2)中,“基本事件名称”表示构成了复合事件树的一部分的基本事件的名称。“运算符”表示把相应的基本事件与由“下一ID”所表示的事件联系起来的运算符。
在时间事件表的模式(表3)中,“生成时间”存储为格式为秒/分钟/小时/星期/日期/月/年的字符串。“事件类型”指出它是一绝对事件还是一周期性事件。“开始时间”是开始检测相对的或称周期性事件的时间;当事件是绝对事件时,该项是空值。在周期性事件的情况下,“事件发生时间”表示一期间/间隔,在该期间/间隔之后该事件将再次发生。“停止时间”是周期性事件将停止发生的时间。
一旦一策略已被规定,则需要把其条件和动作部分存储在如表4和5所示的规则表中,以便完全地确定规则规定。动作字符串是SQL、DDL、DML语句形式的,其可由资源抽象与通知层的查询处理器接受,以便执行动作。
规则名称 |
变长字符串 |
规则创建时间 |
变长字符串 |
事件名称 |
变长字符串 |
条件字符串 |
变长字符串 |
动作字符串 |
变长字符串 |
类名称 |
变长字符串 |
表4.规则表的模式
规则名称 |
规则创建时间 |
事件名称 |
条件字符串 |
动作字符串 |
类名称 |
Rule 1 |
10/07/10/Th/22/11/2001 |
Primitive.el |
Cond_str |
Act_str |
AcitonDbClass |
表5.规则表中一个条目的例子
注意在策略数据库中存储策略的上述方案是一说明性方案。对本领域的技术人员显而易见的是各种其它方案也可用于部署策略。
现在使用图10描述如何在发生了一事件后执行一已部署的策略。如上所述,发生的事件可以是时间事件、资源事件(如数据库事件)或者外部事件。事件检测器412借助于资源抽象与通知层420来检测这些事件。可用于进行检测的一种可能方式如下:首先,识别所发生的事件的各种属性。这些属性可以包括事件名称、事件类型、生成时间(用于时间事件)、涉及的数据库(用于数据库事件)等。应注意任何一组事件属性都可被用于确定存储在策略数据库108中的一事件表中的一事件。下一个步骤涉及使用识别出的已发生事件的属性,来确定事件表中的相关事件。事件检测器412侦听资源抽象与通知层420,以获知发生在系统中的所有事件,并检查在策略数据库的事件表中指定的事件。一旦一相关的事件被检测出来,其标识符(如事件ID)信息就被发送到条件评估器416。然后,条件评估器416取出存储在策略数据库108的规则表中的所有适用的策略(条件和动作)。它可以简单地使用事件ID,并从规则表中获得相应的条件和动作字符串。条件评估器416现在检查与每个策略对应的条件。这些条件可能涉及外部系统,以及资源,如系统数据库。通常而言,条件是简单的逻辑运算,如比较表征了一外部系统或一内部系统(如一数据库)的两个值。因此,条件评估器416接收来自系统内部及系统外部的资源的输入。条件评估器也可以执行系统命令(例如使用SQL查询),以便评估一条件(例如检查资源的状态)。当条件评估完成后,条件评估器416或者拒绝该规则(如果该条件不为真),或者将该规则的动作部分传给动作执行器418(如果该条件为真)。
动作执行器418控制一组动作组件1002。这些动作组件可以采取的形式有DML(数据操纵语言)、DDL(数据定义语言)、SQL(结构化查询语言)、通知和警告。动作执行器418通过资源抽象层420将适当的指令发送给资源(其应当执行动作),以便执行在该策略中规定的动作。例如,它可以通过资源抽象层420将一SQL指令发送给DBMS(数据库管理系统)。
以上解释了根据本发明的一优选实施例的管理资源的系统和方法,现在举一个策略的例子,并表明在本发明的一优选实施例中创建和处理策略的方式。这有助于更清楚地解释至此描述的方法和系统。
示例
下面将借助于一例子说明本发明。
考虑以下策略的例子“(事件)自2002年1月至2005年1月,在每月的第一天,上午9点,(条件)检查DELHI:EBIZ数据库的大小是否大于200MB,然后(动作)将该数据库备份到Delhi Backup服务器即DELHI EBIZ的磁带上”。用户可以通过GUI以一种直观的方式(使用简单的语言构件)来规定这一策略,如图11-14所示。用户可以通过下拉菜单和可点击标记来规定事件、条件和动作。图11和12示出了用于事件规定的GUI。在图11中,用户指定事件名称和事件类型(时间的)。在图12中,用户进一步规定时间事件中的诸值。图13和14示出了分别用于指定条件和动作的GUI。
策略规定层通过GUI捕获用户的选择。经过简单的预处理,用户所作的选择以下列格式排列起来:
事件:(New_Temporal)(Starting From(2002-Jan-1 1:00)OnEveryMonth On Date 1 StartAt 9:00 EndAt(2005-Jan-1 1:00))
条件:(database_state Size_of_database(DELHI:EBIZ)>200MB)
动作:[(Backup Database:DELHI:EBIZ At DELHI:Tape AsBackup_EBIZ)]
应注意,这些值也可以可选地在GUI中显示给用户,用户也可以直接添加这些值(而不需选择适当的可点击标记或下拉菜单)以进一步定制和规定复杂的策略。图12-14的GUI显示了这些规定框的图示,在其中用户可以可视化地显现和修改规定。
上述格式的规定的事件、条件和动作被传递给策略转换器。策略转换器包括一符号器和一分析器。符号器提取上述规定中所使用的符号。在上例中,符号器返回用于事件规定的以下符号:
LEFT_BRACKET NEW_TEMPORAL RIGHT_BRACKETLEFT_BRACKET STARTING STRING LEFT_BRACKET STRINGRIGHT_BRACKET STRING EVERYMONTH STRING DATENUMBER STARTAT STRING ENDAT LEFT_BRACKET STRINGRIGHT_BRACKET RIGHT_BRACKET
来自符号器的输出被输入到分析器,该分析器接受符号,并将它们转换成XML格式。在上例中,XML格式的事件规定可能看起来如下:
<temporal_event>
<temporal_event_id=”1”/>
<event name>New temp</event_name>
<event_type>relative</event_type>
<event_owner>db2admin</event_owner>
<creation_time_stamp>2:49:22:Sat:5:Oct:2002</creation_time_stamp>
<start_event>2002:jan:1:9:00</start_event>
<period_unit>months</period_unit>
<sub_period>9:00</sub_period>
<periodicity>Month:1</periodicity>
<sub_period_unit>t</sub_period_unit>
<next_occurrence>2002:Feb:1:9:00</next_occurrence>
</temporal_event>
此后,分析器应用一组规则(产生式规则)来解释策略规定的意义,并检查其合法性。为了验证一策略的合法性,即检查策略规定的语法是否正确,分析器可以使用与规定一策略相联系的预先规定的产生式规则。完成此的一种方式是通过规定适当的文档类型定义(DTD)。DTD是一种语法和语义规则,并可用于验证XML格式的策略规定。
然后,上述XML输出被传递给冲突检测器,其检查该策略是否与策略数据库中现存的策略相冲突。如果没有检测到冲突,则策略部署引擎将无冲突的策略以关系型格式存储在策略数据库中。标准的系统语言,如结构化查询语言(SQL)、数据定义语言(DDL)、数据操纵语言(DML)等可用于向策略数据库中添加策略。SQL查询的一个例子是:INSERTINTO TemporalEvents VALUES(1,‘New_temp’,‘Relative’,‘db2admin’,‘2:49:22:Sat:5:oct:2002’,‘2002:Jan:1:9:00’,‘2005:Jan:1:9:00’,‘month’,‘9:00’,‘Month:1’,‘t’,‘2002:Feb:1:9:00’)。
策略以关系型格式存储在策略数据库的两个表,即事件表和规则表中。在上例中,策略数据库中的关系型格式的条目可以如下:
事件表:
事件ID: 1
事件名称: New_temp
事件类型: Relative
事件所有者: db2admin
生成时间: 2:49:22:Sat:5:Oct:2002
开始事件: 2002:Jan:1:9:00
结束事件: 2005:Jan:1:9:00
周期单位: months
子周期: 9:00
周期: Month:1
子周期单位: t
下次发生: 2002:Feb:1:9:00
规则表:
规则ID: 2
规则名称: New_temporal
事件ID: 1
条件字符串: (database_state Size_of_database(DELHI:EBIZ)>200MB)
动作字符串: [(Backup Database:DELHI_EBIZ At DELHI:Tape As Backup_EBIZ)]
规则类型: TEMPORAL
规则所有者: DB2ADMIN
生成时间: 3:49:22:Sat:5:Oct:2002
上述策略的执行可以下述方式进行。事件检测器通过资源抽象与通知层检测事件。当事件检测器检测到已在策略数据库的一事件表中规定的一事件时,它就从该策略数据库中提取相应的策略规定。在上例中,当事件发生时(即由2002年1月1日上午9点所规定的时间事件),使用该事件的信息(如事件ID、生成时间等)将条件规定和动作规定从规则表中取出来。将与该事件相应的规则字符串(包括条件和动作)传递给条件评估器。为了验证该条件,该条件处理器可以形成和执行适当的命令。在上例中,其中条件字符串是-“如果数据库DELHI:EBIZ的大小大于200MB”,条件评估器可以通过适当的SQL命令确定DELHI:EBIZ数据库的大小。在上例中,可以通过SQL查询-“list tablespaces show detail”来提取一数据库中所有表的大小。已使用页的列表的总和可以给出该数据库大小的估计值。
将由SQL查询结果获得的大小与阈值(在条件字符串中规定的)即200MB进行比较。如果该大小小于200MB,则条件评估器查看该条件字符串中规定的其它规则,并以与上述同样的方式验证它们。如果在该字符串中没有其它规则了,则条件评估器关闭数据库连接并结束。
如果条件为真,即其大小大于200MB,则条件评估器将动作字符串传给动作执行器。该动作执行器解释该动作字符串(利用其自己的分析器),并形成适当的SQL查询。然后,该SQL查询被传给资源抽象与通知层中的一查询处理器,以便执行规定的动作。在当前例子中,将用于备份DELHI:EBIZ数据库的SQL查询发送给查询处理器,该SQL查询为“BACKUP DATABASE DELHI_EBIZ ONLINE TO\\DELHI\\TAPE\\DELHI_EBIZ”。
硬件和软件实现
本发明可以在一计算机系统或任何其它处理系统中实施。图15示出了一个这样的计算机系统。该计算机系统包括一微处理器1502。该微处理器连接到一通信总线1504。该计算机系统还包括一随机存取存储器(RAM)1506、一只读存储器(ROM)1508和次级存储器1510。次级存储器1510可以是一硬盘驱动器,或者一可移动存储驱动器,如一软盘驱动器、光盘驱动器等。次级存储器1510也可以是其它类似的、用于把计算机程序或其它指令装入计算机系统的装置。该计算机系统也包括一通信单元1512。通信单元1512使得计算机可以连接到其它数据库和因特网。通信单元1512使得能够传输和接收来自其它数据库的数据。通信单元1512可以包括一调制解调器、一以太网卡或任何类似的设备,其使得计算机系统连接到诸数据库和网络,如LAN、MAN、WAN和因特网。计算机系统也包括用于提供用户接口的一显示单元1514,以及使用户能够输入策略的一输入设备1516。
本发明的优选实施例可以在这样的系统上实施,该系统具有如在UNIX、Windows 2000和Windows NT操作系统上可以看到的某些结构要素;更具体地说,是与数据库管理系统(DBMS),如Risc System/6000上的IBM DB2/Common-Server,结合起来。也可以使用其它的关系型数据库,如Sybase、Oracle等。
用于实施本发明的软件代码可以任何编程语言如C、JAVA、C#等来编写。本发明也可以部署为一Web服务。其主要的后端模块可以编写为服务小程序(servlet)(被设计在一应用服务器或一服务小程序引擎上运行的JAVA程序),而前端模块可以编写为JSP(Java Server Page)、HTML、JAVA-Script和Applet。本发明使用JDBC API与后端数据库通信。
本发明提供了几个API用于实施策略规定、策略部署和策略执行的各个方面。在本发明中可以使用的API可以根据本发明的使用所在的系统,以任何编程语言编写。JavaTM Enterprise API、Java基础类(JFC)、Swing等是在JavaTM平台上提供的一些工具。在各层中使用的一些重要的API已经在描述各层时进行了讨论。
本发明的优点
本发明提供了很多优点。它使资源管理的任务更容易了。用户友好的接口和简单的语言构件使得甚至非IT专家者也能规定、修改、删除或可视化地显现策略。因此,资源和数据管理的成本显著降低了。
可视化地显现和理解给定系统中的策略的任务可以图形化地表现为树形结构。即将可视化显现的策略由策略转换器406以关系型格式从策略数据库中取回。此后,策略转换器将策略元素的细节转换为XML格式。本领域的技术人员可以理解,所提取的XML格式的策略细节,利用适当的软件工具,可以容易地转换并嵌入用户接口中。例如,通过使用XML格式的规定,所提取的策略可以树型结构显示给用户。图16示出了以树型数据结构可视化地显现策略的一个例子。事件E1可能包含诸如名称、站点、数据库、表、操作等详细信息。如图16所示,当在位于BLUEDOT站点的I_TAX数据库的PAYROLL表中进行了AFTER_INSERT(插入后)操作后,事件E1发生。该策略是“当在所得税数据库(I-TAX)中发生事件E1以及事件E2或事件E3中的任何一个、且条件C1满足时,则执行动作A1。”为了表示多个事件,使用诸如AND、ANY等连接符。将存储在策略数据库中的策略转换为树型结构是由策略转换器完成的。例如,图16中示出了3个事件,其由2个连接符AND和ANY连接起来。因而,当E1以及E2和E3中的任何一个发生时,该策略被启动。与这些事件有关的诸参数显示在图中所示的框中。这些参数可以是事件的名称、站点名称(资源所在之处)、数据库名称、表名称、操作类型(插入、删除、更新)。相似类型的树也用于描述所规定的策略的条件和动作。基于树的结构显然有助于理解、可视化地显现和修改策略及其个别元素,尤其从非IT专家者的观点看更是这样。对本领域的技术人员显而易见的是,向用户可视化地显现策略的方式可以有几种修改。例如,在另一种实施例中,策略可以表示由一HTML文件中的文本描述的表示。
本发明的另一个优点是它提供了对个别策略元素的访问控制。通过直观的简单语言构件,用户可以为数据、资源(例如数据库、网络设备)规定权限和访问控制规则。进一步地,访问控制可以在事件和/或条件和/或动作水平上进行配置。一策略的条件子句可以返回非二元的值,而动作可以根据该返回值而被执行。例如,设想一策略,其事件为“在存货中输入新项目”。该策略的条件子句在该项目是普通类别时返回值1,在该项目是特殊类别时返回值2,在该项目是重要的被要求类别时返回值3。可以为这些返回值中的每一个规定不同的动作。例如,如果返回值是1或2,则系统可以通知销售部门,而如果返回值是3,则系统可以连同要求该项目的用户id(标识)通知给销售部门,并且还向要求该项目的用户发送一通知。
本发明的另一优点是它提供了检测冲突的机制,藉此保持了系统的完整性。通过使用元策略(其包括诸策略及策略创建者之间的优先权),可以决定在新的/修改的策略与现在的策略之间是否存在任何冲突。如果存在这种冲突,则拒绝该新的/修改的策略,并通知该策略的创建者此事。以这种方式,只有无冲突的策略才部署在策略数据库中。
本发明的另一个优点是它提供了集中的访问入口以管理和监视分布式资源。网络中的所有资源都可以通过规定适当的策略而集中地控制。
尽管以上说明和描述了本发明的一些优选实施例,显然本发明不仅限于这些实施例。对本领域的技术人员而言显而易见的是,可以有多种修改、改变、变化、替换和等价做法,而不脱离如权利要求所述的本发明的精神和范围。