CN101030271B - 一种资源业务对象的持久化和查询方法 - Google Patents

Abstract

一种电信运营支撑系统的本地网资源管理系统中的业务对象的持久化方法，其特征在于包括步骤：在客户端对业务对象和/或其关联业务对象进行修改，并针对所修改的业务对象设定与所述修改相应的持久化类型标记；将包括所述被修改的业务对象的对象树提交到服务器以请求持久化；在服务器端根据持久化标记对所提交的对象树实施修改，以得到最终的对象树；以及将最终的对象树持久化到数据库中。

Description

一种资源业务对象的持久化和查询方法

技术领域

本发明涉及一种适用于电信运营支撑系统(简称OSS)的本地网资源管理系统中的业务对象的持久化方法和基于该持久化方法的查询方法。

背景技术

经过十几年的高速发展，通信网络规模已经非常庞大。电信运营商如何通过一种网络资源动态管理体系，调度企业各部门有效配置网络资源，盘活网络存量资产，提高资源利用率，最大限度满足客户需要，支撑前端业务，是提高网络综合效能和企业竞争力的重要保证。

为此，电信运营商普遍采用了基于计算机信息管理技术的电信OSS本地网资源管理系统，其参照了eTom的模型体系，以计算机系统为基础，实现传输网、数据网、交换网、动力网等各专业网的物理设备资源、逻辑配置资源、业务调度和业务开通流程的集中统一管理，为电信运营商提供了电信网络管理的综合解决方案，不仅使新的网络资源的快速方便的扩展成为可能，并帮助电信运营商极大地提高了新业务生成的速度。

通常以管理人员操作客户端上运行的管理系统的方式对资源(即对象)进行管理和查询，而所管理的各种资源最终均存储在服务器端的数据库中，并最终通过服务器端的数据库管理系统来查询。

在电信OSS本地网资源管理系统中，通常采用面向对象技术对资源进行建模，其中管理许多不同类型的资源业务对象，如空间资源(站点、机房等)、物理资源(网元、端口、端子等)、逻辑资源(SDH、PDH、电路等)，而且每个资源业务对象都会有许多属性，如网元就有名称、编码、厂商、设备种类、客户等数十个属性。当前，在把业务对象持久化到数据库的过程中，即在数据库对象持久化层上，或者采用直接使用JDBC写sql语句的方式，或者采用O/R Mapping中间件工具，把数据库表和字段封装成对象和属性。现在已经有不少成熟的中间件产品，如JDO、Toplink、Hibernate等。

但对于现有的电信OSS本地网资源管理系统，在涉及到具体业务领域时，直接使用这些产品仍有一些不足之处。例如，应用代码和具体O/R Mapping产品绑定，如果以后要迁移到其他产品的话，则需要重新编写代码，代价很大；对于每一种资源业务对象的持久化和查询，都需要写许多定制的代码；缺乏有效封装，客户端可以直接获取数据库的对象，可以直接对数据库进行操作，违反了分层的原则，并降低安全性；调用方法分散，缺乏统一的管理，无法在性能和功能上进行统一处理和维护；对于带有多层关联子业务对象的资源对象，无法做到灵活查询；无法满足资源统一命名规范，同时又兼顾拼装名称的灵活定制显示。

发明内容

为克服以上的不足，本发明的目的是提供一种电信OSS本地网资源管理系统中的业务对象持久化方法和以此为基础的业务对象查询方法，它们是统一的和对象类型无关的。

本发明提供了一种电信运营支撑系统的本地网资源管理系统中的业务对象的持久化方法，其特征在于包括步骤：在客户端对业务对象和/或其关联业务对象进行修改，并针对所修改的业务对象设定与所述修改相应的持久化类型标记；将包括所述被修改的业务对象的对象树提交到服务器以请求持久化；在服务器端根据持久化标记对所提交的对象树实施修改，以得到最终的对象树；以及将最终的对象树持久化到数据库中。

根据一个实施例，所述实施修改的步骤包括：遍历该对象树，当遍历经过一个业务对象时，实施该业务对象的简单属性的修改；以及当遍历经过一个关联时，判断与该关联相关的父业务对象和子业务对象之间的关系，如果父业务对象和子业务对象之间是1:1或n:1的关系，则根据子对象的持久化类型不同，重新设置该父业务对象和子业务对象的关系；以及如果该父业务对象和子业务对象是1:n或n:n的关系，则先递归持久化子业务对象，然后在递归返回父业务对象时重新设置该父业务对象和子业务对象之间的关系。

根据一个实施例，所述持久化类型包括新增，修改和删除。

根据一个实施例，所述客户端通过统一的入口来进行所述请求。

根据一个实施例，所述客户端能够通过该入口提交多个对象树。

根据一个实施例，所述持久化步骤是通过中间件工具进行的。

本发明还提供一种电信运营支撑系统的本地网资源管理系统中的业务对象查询方法，其特征在于包括步骤：在客户端定义查询请求，该查询请求包括查询表达式和关联对象组装字符串；发送查询请求到服务器；服务器根据预定的查询表达式映射将所接收的查询请求中的查询表达式转换成针对相应中间件的表达式；根据转换的查询表达式执行查询并根据关联对象组装字符串来生成查询结果；以及将生成的查询结果返回给客户端。

根据一个实施例，所述执行查询并生成查询结果的步骤包括：查询出满足查询表达式的业务对象的集合；针对该集合中的每个对象，查询出满足要求的对象；以及解析关联对象组装字符串，递归组装业务对象树，以生成查询结果。

根据一个实施例，所述查询请求还包括资源命名拼装字符串，并且所述执行查询并生成查询结果的步骤包括：解析资源命名拼装字符串，以及得到业务对象类型和命名上下文名称；根据该业务对象类型和命名上下文名称从预定义的命名规则中找到对应的命名规则；根据命名规则的前提条件，生成相应拼装的SQL语句，查询出命名显示子项；对所述命名显示子项进行命名显示名称取值转换；以及用经过转换后的名称替换查询结果中与所述业务对象类型相应的对象的名称。

根据一个实施例，所述解析并递归组装的步骤包括：针对每个解析出的关联子对象，根据预定映射关系得到相应的设置方法；以及调用该设置方法，以设置该关联子对象。

根据一个实施例，所述中间件为Toplink或Hibernate。

根据一个实施例，所述查询请求包括指定当前查询的页数和每页查询的记录数目的信息，并且所述查询业务对象集合的步骤包括根据分页号和每页的数目进行查询。

根据本发明，资源业务查询服务器有预定义的查询表达式，能转换成不同O/R Mapping产品的查询表达式，以支持不同的O/RMapping产品。

根据本发明，查询时能够方便地设置查询业务对象的任意关联子对象。

根据本发明，提供了满足本地网资源统一命名规范，同时又能实现命名灵活定制显示。

附图说明

通过下面结合附图所进行的对本发明的描述，能够明白本发明的上述及其它目的，特征和优点，其中

图1示出了根据本发明的业务对象持久化方法的一个实施例；

图2示出了根据本发明的业务对象查询方法的一个实施例；

图3示出了修改之前的对象树的例子；

图4示出了客户端所提交的对象树；

图5示出了在服务器端的数据库中持久化后的对象树；

图6示出了一个资源对象树的例子；

图7示出了一棵端口的对象树的例子。

具体实施方式

下面结合附图来说明本发明的具体实施例。

图1示出了根据本发明的业务对象持久化方法的一个实施例。

如图1所示，在步骤S1，由用户在系统客户端对业务对象的持久化进行设定。根据业务对象之间的关联，可以在逻辑上将存在关联的若干对象视为对象树。对象树的一个特例是单节点树，即单个对象。对象树在面向对象程序设计语言中得到广泛的支持。例如系统可采用开发语言Java，Java本身是一个面向对象的语言，每一个资源业务对象都会对应到一个Java的Object对象。

一个业务对象持久化，可分为新增、修改、删除三种情况。持久化既包括持久化业务对象本身的基本属性，也包括持久化该业务对象关联的子业务对象。对于修改的情况，既包括对象基本属性的修改，如修改了名称，也包括关联子对象的改动，子对象的增、删、改都意味着父对象做了修改。这些子对象的类和父对象的类之间有多对一、一对多、一对一、多对多等多种关联关系，比如类A和类B有关联关系，反映在具体实现上就是类A有例如getB()的方法，类B有例如getA()的方法，通过两者get方法返回值是单个还是集合可以确定两者之间的关联关系类型，子对象的持久化也分新增、修改、删除三种情况，子对象又有子对象，所以每个对象的持久化操作都是一棵对象树的持久化操作。

业务对象持久化包括新增、修改、删除三种情况。在步骤S1的设定操作中，把有关业务对象打上不同的持久化标记来表示新增、修改和删除。

接着，在步骤S3，当用户选择保存对象树时，系统客户端将包含加有持久化标记的对象的对象树提交到系统服务器端以请求在数据库中持久化。业务对象持久化方法提供了一个远程接口方法persistBObjects(long_sessionKey，List_objects)，作为统一的操作入口，可以完成对不同类型资源对象树的持久化操作。其中参数sessionKey为长整型，记录了当前用户的信息，参数objects为要持久化的对象树集合，该接口方法支持批量的对象树持久化操作。对象树的传送方法是本领域已知的。以Java为例，这里所有对象可以都实现Java的Serializable接口，这样在远程RMI调用时，对象会被自动的序列化和反序列化。

接着，在步骤S5，系统服务器端在接收到所提交的对象树之后，在对象树中遵循对象之间的关联进行遍历。在遍历过程中，通过确定对象关联的方法(例如Java的反射功能，遍历该对象所有的get/set方法)来进行遍历。当遍历经过一个业务对象时，根据业务对象的持久化类型，实施简单属性的修改；当遍历经过一个关联时，判断父业务对象和关联子对象之间的关系，如果父业务对象和子业务对象(例如对应的get方法返回值是集合)之间是1:1或n:1的关系，则根据子对象的持久化类型不同，重新设置该父业务对象和子业务对象的关系；如果该父业务对象和子业务对象是1:n或n:n的关系(例如对应的get方法返回值是单个实体)，则先递归持久化子业务对象，然后在递归返回父业务对象时重新设置该父业务对象和子业务对象之间的关系。由于查找对象关联关系是通过例如Java的反射功能来实现的，所以不需要任何的硬编码，也不依赖业务对象的具体类型。在遍历完成后，系统服务器端形成最终的对象树。

接着，在步骤S7，系统服务器端将所形成的对象树通过持久化工具保存在数据库中。

该方法在步骤S9结束。

在一个可选实施例中，本发明的持久化方法可以和常规方法结合使用。例如，对于大部分的资源业务对象，在持久化的时候都遵循着本发明的方法，只有少部分的业务对象持久化时需要额外的定制操作。

下面结合图3-5示出的对象树更详细地说明图1的方法。图3示出了修改之前的对象树的例子。图4示出了通过客户端的修改而要持久化的对象树。图5示出了在服务器端的数据库中持久化后的对象树。

对于步骤S1，在客户端保存之前，对业务对象进行修改，并把业务对象打上相应的持久化的标记，标记有A、U、D三种，分别表示新增、修改和删除。

对比图3示出的对象树，如图4所示，对象A修改时，会新增子对象B，同时修改子对象C，子对象C修改时，会删除子对象D，同时会对关联的E对象(C和E之间是1对多关系)进行修改。

对于步骤S3，提交到服务器端的输入是一棵打上持久化标记的对象树，以下面网元的修改为例，对象树如图6所示。

网元修改时，同时会修改机框1，新增机框2(新增机框2时同时新增机框2包含的插盘)，修改所属客户。

对于步骤S5，服务器端处理时实现如下：

先根据该业务对象的持久化类型，调用简单属性的修改操作。简单的持久化操作只持久化对象的简单属性，比如网元的名称、编码等一些简单属性，不包括网元和机框之间这种对象间的属性关系。

通过Java的反射功能获得对应get方法，根据返回类型判断该业务对象和关联子对象之间的关系。这又分成两种情况

该业务对象和子对象之间是1:1或n:1的关系

在这种情况下，根据子对象的持久化类型不同，重新设置该业务对象和子对象的关系。如网元类有getCustomer()方法，返回类型是Customer对象，这样我们就知道网元和客户的关系是n:1(或1:1，这里关系是n:1，两种关系处理方法相同)，这里就会调用网元的类对应的setCustomer(Customer customer)方法，重新设置网元的所属客户对象。

该业务对象和子对象是1:n或n:n的关系

在这种情况下，先递归持久化子业务对象，然后重新设置父对象和子对象之间的关系。比如网元和机框的关系是1:n，这里就会递归持久机框对象，修改机框1，新增机框2，同时新增机框2所包含的插盘。1:n和n:n两种情况对于对象的处理方式相同，只是数据库中的持久化方式不同，O/R Mapping工具会屏蔽掉持久化方式上的不同。

最后调用O/R Mapping工具的接口持久化修改后的对象树，并把保存后的网元对象作为方法输出返回

下面参照图2和7描述本发明的业务对象查询方法。

本发明的业务对象查询方法提供了一个统一的操作入口，可以完成不同类型资源对象的查询和资源命名定制显示的操作。客户端在查询资源之前，设置查询关联对象组装字符串和资源命名拼装格式，然后系统服务器会解析组装字符串和资源命名拼装格式，实现不同对象的关联查询和资源命名灵活显示功能。

已有的技术方案一般都偏向技术实现的底层，用于简化数据库操作和软件模块的整合等，比如O/R Mapping工具或是其他一些中间件产品，而缺乏适用于上层OSS业务领域的实现方案。本发明设计面向电信OSS领域，能有效的解决OSS领域资源业务对象管理的实际问题。

在电信本地网资源管理系统中，用户最基本的操作就是对业务对象的增、删、改、查，所有基本操作都离不开对业务对象的查询和显示。每个操作对查询的要求都会不同，所以需要有一种通用的查询方法来支持所有情况。该查询方法实现了业务对象的查询功能，支持任意多层关联对象组合查询，并可扩展支持不同类型的O/R Mapping产品。

当查询某个业务对象时，有时希望返回的结果不只是对象本身，还有该对象关联的其他对象。比如查询“端口”对象，在某些情况下，希望返回的结果中还要有端口所属属网元的信息，希望返回的是一棵端口的对象树，如图7所示。

在不同的情况下客户端对业务对象展现的层次要求不同，所以在查询结果中对组装对象的要求也不一样。如果为每一种组装情况都提供不同的查询方法，这样查询方法数目就会很多，如果通过实现一个最复杂组装的方法来满足所有情况，性能的代价又太大。而且这都是针对单个业务对象而言，而系统中有成百上千的不同类型的业务对象，一个统一的查询方法非常必要。

图2示出了本发明的业务对象查询方法的一个实施例的示意流程图。

如图2所示，方法从步骤S11开始，其中由用户在客户端输入查询请求。该查询请求包含有对象组装字符串，来满足不同的查询情况。例如，一个对象组装字符串格式可以如下。以端口为例，格式为“[Port[NE]]”，这表示返回的结果中，端口(Port)需要设置网元(NE)对象，设置是通过调用相应方法，例如setNE()来实现，其中可以采用方法名和组装字符串相匹配的方式，但也可以采用其它关联方式。对于复杂的情况，比如需要端口(Port)关联上插盘(CircuitPack)，插盘还要关联上插盘类型(CircuitPackType)，网元(NE)要关联上机房(Host)等，只需修改一下组装字符串为“[Port[CircuitPack[CircuitPackType]][NE[Host]]]”就可以了，不需要修改其他代码。本领域技术人员明白，上面只是对象组装字符串的具体例子，本发明并不局限于这样的例子。

可选地，查询请求也可包含命名拼装字符串，来满足不同的资源命名需要。虽然在所有的本地网中资源都有统一的命名规范，但是不同用户在不同资源使用场合下需要不同的资源名称。在不同的上下文环境中，用户可能希望看到不同的显示名称。比如以“端子”这个资源为例，端子是在某个连接面板上，连接面板有可能在机架上，也可能在连接设备上，机架和连接设备可以是单面，也可以是双面。对于上述不同情况的组合，用户希望能够得到不同的显示名称，也就是需要为不同上下文情况提供不同的拼装显示规则。而且由于各个用户情况不同，即使对于同一种上下文情况，拼装显示的规则可能也不相同。如果命名拼装逻辑和代码绑定，只能通过为不同的用户开发不同的命名代码，为不同的资源使用场合开发不同的资源命名代码。实现和维护代价大，而且对现场修改要求的响应时间长。

本发明的资源命名灵活定制方法将命名逻辑从代码中分离，并保存到外部配置中，而代码中仅仅保留通用的处理逻辑。当用户有对命名逻辑的修改要求时，直接修改外部配置即可。同时为不同的命名上下文，定义不同的命名规则，以实现命名拼装的灵活性。

命名规则包括：

·名称，命名规则的唯一标识。每个资源实体在系统中都有一套缺省命名规则。

·前提条件。一个命名规则中会有多个前提条件，可以针对不同的前提条件生成不同的拼装命名，前提条件可以是一个sql表达式，用于限定哪些对象满足这个前提。

·拼装方法

命名拼装过程如下，以关于端口的命名拼装字符串“Port{显示名称-系统缺省：setNameObj}”为例：

根据该业务对象(Port)的类型和命名上下文名称(“显示名称-系统缺省”)，找到对应的命名规则。

根据命名规则的前提条件，筛选出满足要求的业务对象。其中可根据不同的前提条件，生成不同拼装的SQL语句，查询出命名显示子项。比如前提条件是“端口有插盘，插盘有机框，机框无子架”，系统就会根据对应的拼装方法“网元Name+机框No+插盘PackNo+端口Position+端口种类信息”生成相应的sql语句。

对所述命名显示子项进行命名显示名称取值转换。因为查询出的值可能是某个数据字典值或者定义的常量等，要把这些值转换成相应的可阅读的显示名称。比如端口光电特性在数据库中是用数值0、1来表示，在显示时会根据数据字典转换成“光口”或“电口”。

因此，能够形成定制的业务对象显示名称。

虽然前面参照一个具体实施例描述了本发明的资源命名特征，然而本领域技术人员明白，能够得到其它达到同样目的的资源命名方法。

接着在步骤S13，从客户端将查询请求发送到服务器端以请求查询。

接着在步骤S15，服务器将接收的查询请求中的自定义的查询表达式转换成某个具体O/R Mapping产品的查询表达式，例如支持Toplink。不同的O/R Mapping产品都提供了各自的数据库查询表达式，这些查询表达式之间互不兼容。为了做到对具体产品透明，根据本发明，在服务器端定义了自己的查询表达式映射，客户端在查询时设置好表达式的内容，服务器端会根据该映射把表达式解释成O/RMapping产品的表达式。这样首先使客户端独立于具体的第三方产品，而且也使服务器端能够很方便的通过扩展支持不同的产品，例如Toplink和Hibernate等。

接着在步骤S17，根据转换的查询表达式执行查询并根据业务对象组装字符串来生成查询结果。

例如，在步骤S17中，查询出满足查询表达式的业务对象的集合，例如在通过id标识对象的情况下，先查出满足要求的业务对象的id集合，接着根据对象id，查询出对象集合。

接着解析业务对象组装字符串，递归组装业务对象树。

接着在步骤S19，将最终结果，即递归组装的对象树返回给客户端。

该方法在步骤S21结束。

下面通过具体的例子详细解释该实施例。在这个例子中，假设查询的对象为端口Port，组装字符串为“[Port[NE[Host]]]”，表示端口查询返回时要关联上网元对象，网元要关联上机房对象，命名拼装字符串为“Port{显示名称-系统缺省：setNameObj}”，表示命名拼装上下文为“显示名称-系统缺省”。

对于步骤S17，在组装端口对象树的时候，会递归组装下层网元对象，关联上机房对象。

在一个可选实施例中，如果查询请求包括命名拼装字符串，则在步骤17中，还解析命名拼装字符串，定制业务对象的拼装命名。在这个例子中，根据命名上下文“显示名称-系统缺省”找到对应的命名规则，然后根据这个命名规则拼装端口命名。

在一个可选实施例中，如果业务对象查询结果的数据量很大，可以支持分页查询。即每次只查询和展现一页的数据，可以任意指定当前查询的页数和每页查询的记录数目。对于步骤S17，根据分页号和每页的数目查询出满足要求的业务对象的集合。

采用本方法后，可以实现各种不同类型资源业务对象的持久化和查询功能，可以灵活定制各种资源的命名显示，减轻了系统的复杂度，大大提高了整个系统的灵活性和显示的友好性。

Claims (5)

1.一种电信运营支撑系统的本地网资源管理系统中的业务对象的持久化方法，其特征在于，所述方法包括步骤：

在客户端对业务对象和/或其关联业务对象进行修改，并针对所修改的业务对象设定与所述修改相应的持久化类型标记；

将包括所述被修改的业务对象的对象树提交到服务器以请求持久化；

在服务器端根据持久化标记对所提交的对象树实施修改，以得到最终的对象树；以及

将最终的对象树持久化到数据库中；

其中，所述实施修改的步骤包括：

遍历该对象树，

当遍历经过一个业务对象时，实施该业务对象的简单属性的修改；以及

当遍历经过一个关联时，判断与该关联相关的父业务对象和子业务对象之间的关系，

如果父业务对象和子业务对象之间是1:1或n:1的关系，则根据子对象的持久化类型不同，重新设置该父业务对象和子业务对象的关系；以及

如果该父业务对象和子业务对象是1:n或n:n的关系，则先递归持久化子业务对象，然后在递归返回父业务对象时重新设置该父业务对象和子业务对象之间的关系。

2.根据权利要求1所述的持久化方法，其特征在于所述持久化类型包括新增，修改和删除。

3.根据权利要求1所述的持久化方法，其特征在于所述客户端通过统一的入口来进行所述请求。

4.根据权利要求3所述的持久化方法，其特征在于所述客户端能够通过该入口提交多个对象树。

5.根据权利要求1所述的持久化方法，其特征在于，所述将最终的对象树持久化到数据库中的步骤是通过中间件工具进行的。

Images