CN103425495A - 业务请求信息的处理方法及*** - Google Patents

Abstract

本发明涉及一种业务请求信息的处理方法及***，包括：第一用户模块接收用户发送的第一业务请求信息；当第一业务请求信息为动态实现信息时，第一用户模块向第一实现模块发送该第一业务请求信息，该第一业务请求信息的格式和定义由第一用户模块对应的第一定义模块提供，由第一实现模块对第一业务请求信息进行实现处理；接收第一实现模块返回的实现处理后的信息；当第一业务请求信息为静态常量信息时，第一用户模块直接引用对应的第一定义模块中所述第一业务请求信息对应的常量数据。由此实现了接口和实现的分离，展现和实现的分离，前台和后台的分离，从而提高了模块的热拔插能力，提高了模块的定制性和模块服务的稳定性。

Description

业务请求信息的处理方法及***

技术领域

本发明涉及移动通信、互联网领域，尤其涉及一种业务请求信息的处理方法及***。

背景技术

传统的技术是面向Java的动态模型***（Open Service GatewayInitiative，OSGi）下软件的模块设计基本上以模块为单位，一个模块提供一到两个子模块，各子模块通过导出的服务组成服务总线，并且通过总线服务获取其他子模块的能力。

图1为传统OSGi下软件的模块设计。图1中，模块设计中没有考虑到当前主流软件设计的三个问题的融合：行为定义、行为实现、行为展现。因此，当模块1的实现发生了变化（行为定义没有变化，仅仅是行为实现变化了），那么根据OSGi的规范模块1需要重新加载，那么导致模块2-4都需要重新加载，即便模块1单独定义了接口，那么行为展现（一般是UI页面）也需要重新加载，因为一个模块在传统OSGi下的定义一般是一个子模块或者分为接口和实现两个子模块。实现中包含了接口的实现和行为的展现能力。

由此可以看出，现有技术中OSGi下软件的模块设计存在以下几个缺陷：

1）传统的OSGi下的设计重后台轻前台，行为展现的设计基本和接口实现合并，没有单独提出，导致行为实现和行为展现没有通过子模块分离，造成设计上的缺陷。

2）传统的OSGi设计重视模块的能力，但是对于一个模块划分几个子模块没有清晰的定义，也没有理论的支持。

发明内容

本发明实施例提供了一种业务请求信息的处理方法及***，以实现接口和实现的分离，展现和实现的分离，前台和后台的分离，从而提高了模块的热拔插能力，提高了模块的定制性和模块服务的稳定性。

第一方面，本发明实施例提供了一种业务请求信息的处理方法，包括：

第一用户模块接收用户发送的第一业务请求信息；

当所述第一业务请求信息为动态实现信息时，所述第一用户模块向第一实现模块发送所述第一业务请求信息，所述第一业务请求信息的格式和定义由所述第一用户模块对应的第一定义模块提供，由所述第一实现模块对所述第一业务请求信息进行实现处理；接收所述第一实现模块返回的实现处理后的信息；

当所述第一业务请求信息为静态常量信息时，所述第一用户模块直接引用对应的第一定义模块中所述第一业务请求信息对应的常量数据。

在一种可能的实现方式中，所述方法还包括：

第一用户模块接收用户发送的第二业务请求信息；

当所述第二业务请求信息为动态实现信息时，所述第一用户模块向第二定义模块对应的第二实现模块发送所述第二业务请求信息，所述第二业务请求信息的格式和定义由所述第二定义模块提供，所述第二定义模块为所述第一定义模块的上级定义模块；由所述第二实现模块对所述第二业务请求信息进行实现处理；接收所述第二实现模块返回的实现处理后的信息；

当所述第二业务请求信息为静态常量信息时，所述第一用户模块间接引用第二定义模块中所述第二业务请求信息对应的常量数据。

在一种可能的实现方式中，所述第一实现模块对所述第一业务请求信息进行实现处理时还包括：所述第一实现模块从所述第二定义模块中调用处理所述第一业务请求信息时的常量数据。

在一种可能的实现方式中，所述第一用户模块向第二定义模块对应的第二实现模块发送所述第二业务请求信息具体包括：

当所述第一定义模块中不包括对应的第一用户模块发送的所述第二业务请求信息时，所述第一用户模块向所述第二定义模块对应的第二实现模块发送所述第二业务请求信息。

第二方面，本发明实施例提供了一种业务请求信息的处理***，该***包括：第一定义模块、第一实现模块以及第一用户模块；

所述第一用户模块用于：接收用户发送的第一业务请求信息；

当所述第一业务请求信息为动态实现信息时，向对应的第一实现模块发送所述第一业务请求信息，所述第一业务请求信息的格式和定义由所述第一用户模块对应的第一定义模块提供，由所述第一实现模块对所述第一业务请求信息进行实现处理；接收所述第一实现模块返回的实现处理后的信息；

当所述第一业务请求信息为静态常量信息时，直接引用对应的第一定义模块中所述第一业务请求信息对应的常量数据。

在一种可能的实现方式中，所述***还包括：第二定义模块、第二用户模块以及第二实现模块，其中，所述第二定义模块为所述第一定义模块的上级定义模块；

所述第一用户模块用于：接收用户发送的第二业务请求信息；

当所述第二业务请求信息为动态实现信息时，向所述第二定义模块对应的第二实现模块发送所述第二业务请求信息，所述第二业务请求信息的格式和定义由所述第二定义模块提供；由所述第二实现模块对所述第二业务请求信息进行实现处理；接收所述第二实现模块返回的实现处理后的信息；

当所述第二业务请求信息为静态常量信息时，间接引用第二定义模块中所述第二业务请求信息对应的常量数据。

在一种可能的实现方式中，所述第一实现模块还用于：在对所述第一业务请求信息进行实现处理时，从所述第二定义模块中调用处理所述第一业务请求信息时的常量数据。

在一种可能的实现方式中，所述第一用户模块具体用于：

当所述第一定义模块中不包括对应的第一用户模块发送的所述第二业务请求信息时，向所述第二定义模块对应的第二实现模块发送所述第二业务请求信息。

本发明实施例中，第一用户模块接收用户发送的第一业务请求信息；当所述第一业务请求信息为动态实现信息时，所述第一用户模块向第一实现模块发送所述第一业务请求信息，所述第一业务请求信息的格式和定义由所述第一用户模块对应的第一定义模块提供，由所述第一实现模块对所述第一业务请求信息进行实现处理；接收所述第一实现模块返回的实现处理后的信息；当所述第一业务请求信息为静态常量信息时，所述第一用户模块直接引用对应的第一定义模块中所述第一业务请求信息对应的常量数据。由此实现了接口和实现的分离，展现和实现的分离，前台和后台的分离，从而提高了模块的热拔插能力，提高了模块的定制性和模块服务的稳定性。

附图说明

图1为传统OSGi下软件的模块设计；

图2为本发明实施例一提供的业务请求信息的处理方法流程图；

图3为本发明实施例二提供的业务请求信息的处理方法流程图；

图4为OSGi新设计模式下模块划分的结果示意图；

图5为本发明实施例三提供的业务请求信息的处理方法流程图；

图6为本发明实施例四提供的业务请求信息的处理***示意图。

具体实施方式

下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。

在本发明的所有实施例中，OSGi下设计一个基础模块及多个其他模块，基础模块不依赖于其他模块，而其他模块直接或间接地依赖于基础模块，且每个模块均实现了行为的定义、实现和展现的分离。

图2为本发明实施例一提供的业务请求信息的处理方法流程图。如图2所示，本发明实施例提供的方法包括：

步骤201，第一用户模块接收用户发送的第一业务请求信息。

第一定义模块、第一用户模块和第一实现模块共同配合完成用户请求的一个动作，所以第一定义模块也可以称为行为定义模块，该行为定义模块中提供了抽象的行为接口、和行为相关的实体类（Plain Old JavaObjects，POJO）以及和行为相关的常量，举例为，用户请求完成一个开灯的动作，那么抽象的行为接口就相当于定义一个能调用其他函数或方法完成开灯这个动作的接口，而实体类相当于开灯这个动作的对象-灯泡，常量就相当于动作对象-灯泡的大小和尺寸等一些静态的不变的信息；第一实现模块也称为行为实现模块，行为实现模块主要是对行为定义模块中定义的接口进行实现，模块的整个核心逻辑实现都在行为实现模块中，同时对服务总线发布服务，即告知其他模块该行为实现模块所能实现的功能；第一用户模块也称为行为展现模块，该行为展现模块提供行为的人机交互能力，需要引入行为定义模块中定义的行为接口、和行为相关的实体类以及和行为相关的常量，并且导入行为实现模块发布的服务，即以WEB（还可以为JSP、HTML、WML和本地应用界面）可视化页面向用户展现上述三个模块共同配合所能实现的功能。需要说明的是，行为展现模块中虽然引入了行为实现模块的服务，但是从静态编译依赖关系上行为展现模块是不依赖行为实现模块，它们的依赖是运行中的动态依赖，即上述任何一个模块更新后，都不中断向其他模块提供服务。

具体地，由第一用户模块接收用户输入的第一业务请求信息。

步骤202，当所述第一业务请求信息为动态实现信息时，所述第一用户模块向对应的第一实现模块发送所述第一业务请求信息，由所述第一实现模块对所述第一业务请求信息进行实现处理。

第一定义模块中提供了抽象的行为接口、和行为相关的实体类以及和行为相关的常量，第一用户模块引用上述行为接口。当第一业务请求信息为动态实现信息时，即需要完成某个动作，那么通过第一用户模块中引用的第一定义模块中定义的动作接口，调用第一实现模块中相应的方法或函数去进行相应的实现处理，其中，第一业务请求信息的格式和定义由第一用户模块引用的第一定义模块提供。举例为，如果在第一定义模块中定义了能调用其他函数或方法完成增加、删除和查询会员动作的接口、上述动作的对象-会员，以及会员的学历等，那么当用户通过第一用户模块去增加会员时，首先查找其引用的第一定义模块中增加会员的动作接口，然后在OSGi的服务总线上查找上述动作接口的实现处理模块，最后通过查找到的第一实现模块中该接口的实现方法或函数进行相应的增加会员的操作。

步骤203，接收所述第一实现模块返回的实现处理后的信息。

通常在第一用户模块中通过引用的接口调用第一实现模块中相应的方法或函数进行相应的实现处理后，该方法或函数会向接口返回实现处理后的信息，并由第一用户模块向用户展现该实现处理后的信息。举例为，在通过步骤202中查找到的第一实现模块中接口的实现方法或函数进行相应的增加会员的操作之后，第一实现模块向第一用户模块返回该新增的会员信息，由第一用户模块向管理员展示该新增的会员。

步骤204，当所述第一业务请求信息为静态常量信息时，所述第一用户模块直接引用对应的第一定义模块中所述第一业务请求信息对应的常量数据。

举例为，如果在第一定义模块中定义了能调用其他函数或方法完成增加、删除和查询会员动作的接口、上述动作的对象-会员，以及会员的学历等，那么当用户通过第一用户模块去选择某个会员性别时，即第一业务请求信息为静态常量信息时，因为第一定义模块中定义了会员的性别：男或女，所以第一用户模块不需要再去调用第一实现模块，而直接引用第一定义模块中性别对应的常量数据-男或女，最后第一定义模块将该常量数据发送给第一用户模块，第一用户模块向用户展示用户所要选择的性别。

图3为本发明实施例二提供的业务请求信息的处理方法流程图。如图3所示，本发明实施例提供的方法包括：

步骤301，第一用户模块接收用户发送的第一业务请求信息。

具体地，用户通过WEB页面执行增加、修改和删除的操作或选择某一常量数据。

步骤302，当所述第一业务请求信息为动态实现信息时，所述第一用户模块向对应的第一实现模块发送所述第一业务请求信息，由所述第一实现模块对所述第一业务请求信息进行实现处理。

第一定义模块中提供了抽象的行为接口、和行为相关的实体类以及和行为相关的常量，第一用户模块引用上述行为接口。当第一业务请求信息为动态实现信息时，即需要完成某个动作，那么通过第一用户模块中引用的第一定义模块中定义的动作接口，调用第一实现模块中相应的方法或函数去进行相应的实现处理，其中，第一业务请求信息的格式和定义由第一用户模块引用的第一定义模块提供。举例为，如果在第一定义模块中定义了能调用其他函数或方法完成增加、删除和查询会员动作的接口、上述动作的对象-会员，以及会员的学历等，那么当用户通过第一用户模块去增加会员时，首先查找其引用的第一定义模块中增加会员的动作接口，然后在OSGi的服务总线上查找上述动作接口的实现处理模块，最后通过查找到的第一实现模块中该接口的实现方法或函数进行相应的增加会员的操作。

在本发明的其他实施例中，当第一定义模块还存在上级定义模块，即还存在第二定义模块时，因为下级定义模块通常会依赖于上级定义模块，即引用上级定义模块中接口、实体类和常量。第一实现模块对第一业务请求信息进行实现处理时还包括：第一实现模块从第二定义模块中调用处理第一业务请求信息时的常量数据。

步骤303，接收所述第一实现模块返回的实现处理后的信息。

通常在第一用户模块中通过引用的接口调用第一实现模块中相应的方法或函数进行相应的实现处理后，该方法或函数会向接口返回实现处理后的信息，并由第一用户模块向用户展现该实现处理后的信息。举例为，在通过步骤302中查找到的第一实现模块中接口的实现方法或函数进行相应的增加会员的操作之后，第一实现模块向第一用户模块返回该新增的会员信息，由第一用户模块向管理员展示该新增的会员。

步骤304，当所述第一业务请求信息为静态常量信息时，所述第一用户模块直接引用对应的第一定义模块中所述第一业务请求信息对应的常量数据。

举例为，如果在第一定义模块中定义了能调用其他函数或方法完成增加、删除和查询会员动作的接口、上述动作的对象-会员，以及会员的学历等，那么当用户通过第一用户模块去选择某个会员性别时，即第一业务请求信息为静态常量信息时，因为第一定义模块中定义了会员的性别：男或女，所以第一用户模块不需要再去调用第一实现模块，而直接引用第一定义模块中性别对应的常量数据-男或女，最后第一定义模块将该常量数据发送给第一用户模块，第一用户模块向用户展示用户所要选择的性别。

步骤305，第一用户模块接收用户发送的第二业务请求信息。

具体地，当第一定义模块还存在上级定义模块-第二定义模块时，因为下级定义模块通常会依赖于上级定义模块，即引用上级定义模块中接口、实体类和常量，当第一定义模块中不包括对应的第一用户模块发送的所述第二业务请求信息时，由上级定义模块对应的实现模块或上级定义模块向该第一用户模块实现处理后的信息或对应的常量数据。

步骤306，当所述第二业务请求信息为动态实现信息时，所述第一用户模块向第二定义模块对应的第二实现模块发送所述第二业务请求信息，由所述第二实现模块对所述第二业务请求信息进行实现处理。

因为第一定义模块引用上级定义模块中接口、实体类和常量，所以当第一定义模块中不包括该动态实现信息的接口时，即第一定义模块中不包括完成某个动作的接口时，通过第一用户模块中间接引用的第二定义模块定义的动作接口，调用第二实现模块中相应的方法或函数去进行相应的实现处理，其中，第二业务请求信息的格式和定义由第一用户模块间接引用的第二定义模块提供。

步骤307，接收所述第二实现模块返回的实现处理后的信息。

通常在第一用户模块中通过间接引用的接口调用第二实现模块中相应的方法或函数进行相应的实现处理后，该方法或函数会向接口返回实现处理后的信息，并由第一用户模块向用户展现该实现处理后的信息。

步骤308，当所述第二业务请求信息为静态常量信息时，所述第一用户模块间接引用第二定义模块中所述第二业务请求信息对应的常量数据。

举例为，第二定义模块为第一定义模块的上级定义模块，且在第二定义模块中定义了能调用其他函数或方法完成增加、删除和查询会员动作的接口、上述动作的对象-会员，以及会员的性别：男或女；那么当用户通过第一用户模块去选择某个会员性别时，即第二业务请求信息为静态常量信息时，因为第一定义模块中没有定义和会员相关的信息，但是它引用的第二定义模块中定义了和会员相关的信息，所以第一用户模块间接引用第二定义模块中性别对应的常量数据-男或女，最后第二定义模块将该常量数据发送给第一用户模块，第一用户模块向用户展示用户所要选择的性别。

需要说明的是，步骤301至步骤304与步骤305至步骤308的先后顺序不做限制。

首先在处理业务请求信息之前，需要根据需求进行模块划分，图4为OSGi新设计模式下模块划分的结果示意图。如图4所示，根据需求可以划分为会员管理模块、订购管理模块和推送管理模块三个模块，其中会员管理模块属于基础模块；订购需要依赖会员，因为订购的时候需要判断会员是否存在，所以订购管理模块依赖于会员管理模块；推送同时依赖于会员和订购，因为推送需要从订购管理模块获取订购关系，匹配会员兴趣进行内容推送，所以推送管理同时依赖会员管理模块和订购管理模块。图4中，每一个模块均包括定义子模块、实现子模块和展现子模块三部分，属于会员管理模块的三部分可以分别表示为：会员定义子模块401、会员实现子模块402和会员展现子模块403；属于订购管理模块的三部分可以表示为：订购定义子模块404、订购实现子模块405和订购展现子模块406；属于推送管理模块的三部分可以表示为：推送定义子模块407、推送实现子模块408和推送展现子模块409。

需要说明的是，会员管理模块、订购管理模块和推送管理模块需要根据需求确定其具体包括的信息，以下对各个子模块的依赖关系及对其他子模块提供的功能进行详细说明。

会员管理模块：从管理员角度上看需要实现会员的维护（包括会员增加、修改、查询），所以会员定义子模块401中具体包括调用其他能实现会员增加、会员修改和会员查询功能的接口，还包括实现上述功能时的操作对象-会员，以及和会员相关的静态不变的信息，举例为：会员的性别，会员所在的区域以及会员的学历等，同时对外其他模块提供引用其内部信息的接口；会员实现子模块402中需要对会员定义子模块401中定义的接口进行实现，在OSGi的服务总线发布服务，即对其他模块提供具体的实现功能，同时依赖会员定义子模块401，即根据会员定义子模块401中定义的接口的变化而相应地更新；会员展现子模块403需要通过可视化的页面向管理员展示其对会员可执行的操作，即引用会员实现子模块402所能实现的功能，依赖会员定义子模块401，即根据会员定义子模块401中接口、实体类和常量的变化而相应地更新。

订购管理模块：需要实现订购关系的增加、删除、查询，所以订购定义子模块404中具体包括能调用其他能实现订购关系增加、订购关系修改和订购关系查询功能的接口，还包括实现上述功能时的操作对象-订购关系，以及和订购关系相关的静态不变的信息，举例为：订购途径：营业厅、短信、电话和自助门户，对外其他模块提供引用其内部信息的接口，依赖会员定义子模块401，即在引用会员定义子模块401中接口、实体类和常量后，根据会员定义子模块401的变化而相应地更新；订购实现子模块405中需要对订购定义子模块404中定义的接口进行实现，在OSGi的服务总线发布服务，即对其他模块提供具体的实现功能，同时依赖订购定义子模块404和会员定义子模块401，即根据订购定义子模块404中定义的接口或会员定义子模块401中定义的实体类及常量的变化而相应地更新，同时引用会员实现子模块402所能实现的功能；订购展现子模块406需要通过可视化的页面向管理员展示其对订购关系和会员可执行的操作，即引用会员实现子模块402和订购实现子模块405所能实现的功能，同时依赖订购定义子模块404（由于订购关系的查询不涉及会员的详细信息，所以不需要依赖会员定义子模块401），即根据订购定义子模块404中接口、实体类和常量的变化而相应地更新。

推送管理模块：推送的实现由***根据推送规则匹配会员兴趣自动推送信息，所以推送定义子模块407中具体包括能调用其他能实现推送任务的创建、推送信息的下发和推送信息的查询功能的接口，还包括实现上述功能时的操作对象-推送信息以及推送信息的状态，举例为：初始状态、推送中和推送结束，对外其他模块提供引用其内部信息的接口，同时依赖会员定义子模块401，即根据会员定义子模块401中接口、实体类和常量的变化而相应地更新；推送实现子模块408中需要对推送定义子模块407中定义的接口进行实现，在OSGi的服务总线发布服务，即对其他模块提供具体的实现功能，同时依赖会员定义子模块401和订购定义子模块404（因为推送需要从订购管理获取订购关系，匹配会员兴趣进行内容推送），即根据会员定义子模块401和订购定义子模块404中定义的实体类及常量的变化而相应地更新，引用会员实现子模块402和订购实现子模块405所能实现的功能；推送展现子模块409需要通过可视化的页面向管理员展示其对推送信息可执行的操作，依赖推送定义子模块407，即根据推送定义子模块407中接口、实体类和常量的变化而相应地更新，引用推送实现子模块408所能实现的功能。

图5为本发明实施例三提供的业务请求信息的处理方法流程图。本实施例中第一定义模块、第一实现模块以及第一用户模块和第二定义模块、第二实现模块以及第二用户模块分别以图4中的订购定义子模块404、订购实现子模块405和订购展现子模块406和会员定义子模块401、会员实现子模块402以及会员展现子模块403为例，会员定义子模块401为订购定义子模块404的上级定义模块，如图5所示，本发明实施例提供的方法包括：

步骤501，订购展现子模块406接收用户发送的第一业务请求信息。

订购定义子模块404、订购实现子模块405以及订购展现子模块406共同实现了管理员对订购关系的管理，管理员通过订购展现子模块406（WEB可视化页面）查询订购途径（如营业厅、短信等）或者增加、删除订购关系等。

步骤502，当第一业务请求信息为动态实现信息时，订购展现子模块406向订购实现子模块405发送该第一业务请求信息，由订购实现子模块405对该第一业务请求信息进行实现处理。

具体地，订购展现子模块406接收到增加、删除或查询订购关系的请求时，首先查找其引用的订购定义子模块404定义的动作接口，然后在OSGi的服务总线上查找上述动作接口的实现处理子模块，最后通过查找到的订购实现子模块405中该接口的实现方法或函数进行相应的实现处理，其中，调用订购实现子模块405中接口的实现方法或函数的格式和定义由订购定义子模块404提供。

步骤503，订购展现子模块406接收订购实现子模块405返回的实现处理后的信息。

举例为，订购实现子模块405实现的功能是增加订购关系，在数据库中添加相应的订购关系信息后，订购实现子模块405向订购展现子模块406发送该结果信息，订购展现子模块406向管理员展现该新增的订购关系。

步骤504，当第一业务请求信息为静态常量信息时，订购展现子模块406直接引用订购定义子模块404中所述第一业务请求信息对应的常量数据。

具体地，当订购展现子模块406接收到选择订购途径时，因为订购途径属于静态常量信息，即只有营业厅、短信、电话和自助门户等几种途径，直接记载在订购定义子模块404中，所以订购展现子模块406直接引用该订购途径的常量数据，并向管理员展现可选择的订购途径。

步骤505，订购定义子模块404接收用户发送的第二业务请求信息。

订购定义子模块404依赖会员定义子模块401，即引用了会员定义子模块401中接口、实体类和常量等信息，因此，当管理员通过订购展现子模块406提供的可视化页面增加、删除或查询会员或选择会员的学历时，因为订购定义子模块404中没有定义和会员相关的动作接口和常量信息，所以订购展现子模块406通过其间接引用的动作接口去获取相应的结果信息或间接引用上级定义模块中的常量数据。

步骤506，当第二业务请求信息为动态实现信息时，订购展现子模块406向会员定义子模块401对应的会员实现子模块402发送该第二业务请求信息，由会员实现子模块402对该第二业务请求信息进行实现处理。

具体地，因为订购定义子模块404中没有定义和会员相关的动作接口，所以订购展现子模块406查找其间接引用的相应的动作接口，然后在OSGi的服务总线上查找上述动作接口的实现处理子模块，最后通过查找到的会员实现子模块402中该接口的实现方法或函数进行相应的实现处理，其中，调用会员实现子模块402中接口的实现方法或函数的格式和定义由会员定义子模块401提供。举例为，当管理员通过订购展现子模块406新增会员时，因为订购定义子模块404中没有定义新增会员的动作接口，即其没有直接引用新增会员的动作接口，所以查找其间接引用的会员定义子模块401中新增会员的动作接口，然后在OSGi的服务总线上查找上述间接引用的动作接口的实现处理子模块，最后通过查找到的会员实现子模块402中新增会员的函数完成新增会员的操作。

步骤507，接收会员实现子模块402返回的实现处理后的信息。

举例为，会员实现子模块402实现的动作接口是新增会员，在数据库中添加相应的会员信息后，会员实现子模块402向订购展现子模块406发送该结果信息，订购展现子模块406向管理员展现该新增的会员。

步骤508，当第二业务请求信息为静态常量信息时，所述订购展现子模块406间接引用会员定义子模块401中第二业务请求信息对应的常量数据。

具体地，当订购展现子模块406接收到选择会员的学历请求时，因为订购定义子模块404中没有定义和会员相关的信息，但是它引用的会员定义子模块401中定义了和会员相关的信息，而且因为会员的学历属于会员的常量信息，即只有小学、初中、高中、大学等几种情况，直接记载在会员定义子模块401中，所以订购展现子模块406间接引用会员定义子模块401中该会员的学历对应的常量数据，订购展现子模块406向管理员展示所要选择的会员的学历。

在本发明的其他实施例中，当管理员通过订购展现子模块406新增订购关系时，订购定义子模块404查找新增订购关系的接口，并通过该接口调用订购实现子模块405中的方法或函数实现新增订购关系的功能时，需要先判断会员是否存在，那么需要在会员定义子模块401中查找该会员，当该会员存在时，才完成订购关系的创建，将新增的订购关系返回给订购定义子模块404，最后再由订购定义子模块404将新增的订购关系转发给订购展现子模块406，由订购展现子模块406向用户展现该新增的订购关系。

综上，对于图4中划分的各子模块，当需求发生变化，则各子模块需要作以下更新：

1）管理页面样式风格需要替换成全新的天蓝色调：管理页面的样式只涉及到UI类型的子模块的修改，通过替换CSS样式可以完成客户的需求，涉及修改的子模块包括会员展现子模块403、订购展现子模块406和推送展现子模块409。

2）订购关系删除下月生效：订购关系删除隔月生效，需要修改订购关系删除的实现，通过延长结束时间，实现隔月生效，涉及修改的子模块包括订购实现子模块405。

3）推送的时候，不仅需要根据会员的兴趣，还需要结合会员的学历和收入：推送的时候同时匹配用户兴趣、学历、收入，需要修改推送执行的实现。在推送的时候增加匹配过滤条件，涉及修改的子模块包括推送实现子模块408。

由以上分析可以在，在OSGi新设计模式下，通过行为的定义、实现、展现分离，同时体现接口和实现的分离，展现和实现的分离，前台和后台的分离。充分保证了架构上各子模块的职责明确，互不干扰，同时对于客户定制需求的及时响应和热部署升级，服务不中断，极大了提高了电信、互联网等服务的稳定性。

图6为本发明实施例四提供的业务请求信息的处理***示意图。图6中，该***包括：第一定义模块601、第一实现模块602、第一用户模块603、第二定义模块604、第二实现模块605、第二用户模块606、第三定义模块607、第三实现模块608、第三用户模块609、第四定义模块610、第四实现模块611、第四用户模块612，其中，第二定义模块604和第三定义模块607为第一定义模块601的下级定义模块，第四定义模块610为第三定义模块607的下级定义模块。

第一用户模块603用于：接收用户发送的第一业务请求信息；当第一业务请求信息为动态实现信息时，向对应的第一实现模块602发送该第一业务请求信息，所述第一业务请求信息的格式和定义由所述第一用户模块603对应的第一定义模块601提供，由第一实现模块602对该第一业务请求信息进行实现处理；接收第一实现模块602返回的实现处理后的信息；当第一业务请求信息为静态常量信息时，直接引用对应的第一定义模块601中该第一业务请求信息对应的常量数据。

需要说明的是，第一用户模块603还用于：接收用户发送的第二业务请求信息；当该第二业务请求信息为动态实现信息时，向第二定义模块604对应的第二实现模块605发送该第二业务请求信息，所述第二业务请求信息的格式和定义由所述第二定义模块604提供；由第二实现模块605对第二业务请求信息进行实现处理；接收第二实现模块605返回的实现处理后的信息；当该第二业务请求信息为静态常量信息时，间接引用第二定义模块604中该第二业务请求信息对应的常量数据。

在本发明的其他实施例中，第一实现模块602还用于：在对第一业务请求信息进行实现处理时，从第二定义模块604中调用处理该第一业务请求信息时的常量数据。

在一种具体实施例中，第一用户模块603具体用于：当第一定义模块601中不包括对应的第一用户模块603发送的第二业务请求信息时，向第二定义模块604对应的第二实现模块605发送该第二业务请求信息。

需要说明的是，第三定义模块607与第一定义模块601、第四定义模块610与第三定义模块607的通信和第二定义模块604与第一定义模块601的通信类似，在此不作重复。

第一用户模块603接收用户发送的第一业务请求信息；当第一业务请求信息为动态实现信息时，向对应的第一实现模块602发送该第一业务请求信息，所述第一业务请求信息的格式和定义由所述第一用户模块603对应的第一定义模块601提供，由第一实现模块602对该第一业务请求信息进行实现处理；接收第一实现模块602返回的实现处理后的信息；当第一业务请求信息为静态常量信息时，直接引用对应的第一定义模块601中该第一业务请求信息对应的常量数据。由此实现了接口和实现的分离，展现和实现的分离，前台和后台的分离，从而提高了模块的热拔插能力，提高了模块的定制性和模块服务的稳定性。

在三个子模块设计下，所有的实现子模块和展现子模块只依赖于各模块的定义子模块，实现子模块和展现子模块之间没有任何依赖关系。同时任何一个实现子模块或者展现子模块的升级更新都不会导致其他子模块的重新加载（因为没有任何子模块依赖实现子模块和展现子模块）。只有当定义子模块发生变化的时候才会导致周边子模块重新加载，从上面我们可以得出一个结论：只要行为的定义没有发生变化，此设计下行为的实现和展现发生了变化，我们可以做到热加载升级，同时不会影响其他模块的行为。

在软件可定制性上，三个子模块的设计定制性较强的展现独立出去，提高了模块的定制性，同时展现的升级更新也不会影响到其他模块服务，热部署能力也得到了充分体现。这样的设计下行为的展现充分融入到整个OSGi的设计中，打破了传统了OSGi的设计重后台轻前台的理念。

专业人员应该还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器（RAM）、内存、只读存储器（ROM）、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (8)

1.一种业务请求信息的处理方法，其特征在于，所述方法包括：

第一用户模块接收用户发送的第一业务请求信息；

当所述第一业务请求信息为动态实现信息时，所述第一用户模块向第一实现模块发送所述第一业务请求信息，所述第一业务请求信息的格式和定义由所述第一用户模块对应的第一定义模块提供，由所述第一实现模块对所述第一业务请求信息进行实现处理；接收所述第一实现模块返回的实现处理后的信息；

当所述第一业务请求信息为静态常量信息时，所述第一用户模块直接引用对应的第一定义模块中所述第一业务请求信息对应的常量数据。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

第一用户模块接收用户发送的第二业务请求信息；

当所述第二业务请求信息为动态实现信息时，所述第一用户模块向第二定义模块对应的第二实现模块发送所述第二业务请求信息，所述第二业务请求信息的格式和定义由所述第二定义模块提供，所述第二定义模块为所述第一定义模块的上级定义模块；由所述第二实现模块对所述第二业务请求信息进行实现处理；接收所述第二实现模块返回的实现处理后的信息；

当所述第二业务请求信息为静态常量信息时，所述第一用户模块间接引用第二定义模块中所述第二业务请求信息对应的常量数据。

3.根据权利要求2所述的方法，其特征在于，所述第一实现模块对所述第一业务请求信息进行实现处理时还包括：所述第一实现模块从所述第二定义模块中调用处理所述第一业务请求信息时的常量数据。

4.根据权利要求2所述的方法，其特征在于，所述第一用户模块向第二定义模块对应的第二实现模块发送所述第二业务请求信息具体包括：

当所述第一定义模块中不包括对应的第一用户模块发送的所述第二业务请求信息时，所述第一用户模块向所述第二定义模块对应的第二实现模块发送所述第二业务请求信息。

5.一种业务请求信息的处理***，其特征在于，所述***包括：第一定义模块、第一实现模块以及第一用户模块；

所述第一用户模块用于：接收用户发送的第一业务请求信息；

当所述第一业务请求信息为动态实现信息时，向第一实现模块发送所述第一业务请求信息，所述第一业务请求信息的格式和定义由所述第一用户模块对应的第一定义模块提供，由所述第一实现模块对所述第一业务请求信息进行实现处理；接收所述第一实现模块返回的实现处理后的信息；

当所述第一业务请求信息为静态常量信息时，直接引用对应的第一定义模块中所述第一业务请求信息对应的常量数据。

6.根据权利要求5所述的***，其特征在于，所述***还包括：第二定义模块、第二用户模块以及第二实现模块，其中，所述第二定义模块为所述第一定义模块的上级定义模块；

所述第一用户模块用于：接收用户发送的第二业务请求信息；

当所述第二业务请求信息为动态实现信息时，向所述第二定义模块对应的第二实现模块发送所述第二业务请求信息，所述第二业务请求信息的格式和定义由所述第二定义模块提供；由所述第二实现模块对所述第二业务请求信息进行实现处理；接收所述第二实现模块返回的实现处理后的信息；

当所述第二业务请求信息为静态常量信息时，间接引用第二定义模块中所述第二业务请求信息对应的常量数据。

7.根据权利要求6所述的***，其特征在于，

所述第一实现模块还用于：在对所述第一业务请求信息进行实现处理时，从所述第二定义模块中调用处理所述第一业务请求信息时的常量数据。

8.根据权利要求6所述的***，其特征在于，所述第一用户模块具体用于：

当所述第一定义模块中不包括对应的第一用户模块发送的所述第二业务请求信息时，向所述第二定义模块对应的第二实现模块发送所述第二业务请求信息。

Images