CN103309674A - 一种软件架构系统 - Google Patents

Abstract

本发明提供了一种软件架构系统，所述软件架构系统基于OSGI规范和REST原则实现，包括：监听管理模块，用于监听OSGI容器内的所有业务插件和/或服务，业务插件用于根据外部的数据请求执行相应的业务逻辑；依赖管理模块，用于提供和管理多个业务插件之间的OSGI服务依赖；服务管理模块，用于控制业务插件执行业务逻辑，控制OSGI容器内的服务的发布和停止；路由分发模块，用于接收来自浏览器的数据请求，根据数据请求的扩展属性的数值确定其对应的处理方法，并将数据请求分发至对应于所述处理方法的业务插件，由该业务插件进行处理，或按照REST原则的默认规则处理。通过本发明的技术方案，可以实现对web应用的模块化开发管理、动态化配置和扩展。

Description

一种软件架构系统

技术领域

本发明涉及业务数据处理技术领域，具体而言，涉及一种软件架构系统。

背景技术

在传统的web应用开发中，由于架构上的先天缺陷，实现组件式开发很难，且没有标准的规范去约束，导致软件复杂度越来越高，且组件复用困难、难以解耦，造成开发效率低。同时，对于现有的web应用的软件开发架构，系统不稳定因素难以控制，热插拔难度非常大，当某一模块出现异常或不能使用，往往会导致其他模块不能正常使用甚至宕机。

因此，需要一种新的技术方案，可以实现对web应用的模块化开发管理、动态化配置和扩展。

发明内容

本发明正是基于上述问题，提出了一种新的技术方案，可以实现对web应用的模块化开发管理、动态化配置和扩展。

有鉴于此，本发明提出了一种软件架构系统，所述软件架构系统基于OSGI规范和REST原则实现，所述系统包括：监听管理模块，用于监听OSGI容器内的所有业务插件和/或服务，所述业务插件用于根据外部的数据请求执行相应的业务逻辑；依赖管理模块，用于提供和管理多个所述业务插件之间的OSGI服务依赖；服务管理模块，用于控制所述业务插件执行业务逻辑，控制所述OSGI容器内的服务的发布和停止，以及实现对所述OSGI容器内的资源插件的静态资源管理；路由分发模块，用于接收来自浏览器的数据请求，若所述数据请求存在扩展属性，则根据所述数据请求的扩展属性的数值确定其对应的处理方法，并将所述数据请求分发至对应于所述处理方法的业务插件，由该业务插件进行处理，若不存在扩展属性，则按照REST原则的默认规则进行分发至对应的业务插件。在该技术方案中，使用OSGI规范和REST原则搭建起用于web应用的软件开发的OSGI框架。通过对框架内的插件和/或服务的监听，能够了解到框架内的插件运行和依赖情况，从而实现对插件的热插拔；通过对框架内的插件的依赖控制，从而避免插件之间的过度依赖，有利于生成的web应用的模块化设计和动态化调整；通过对数据请求的路由分发，从而有利于对来自浏览器（客户端）的请求的及时、有效地处理。

在上述技术方案中，优选地，还包括中间件模块，所述中间件模块具体包括：格式管理子模块，用于将所述数据请求统一映射到PageJSON对象中，并将返回值所述浏览器的返回数据统一封装为ResultData对象、且所述返回数据的数据格式为JSON字符串；请求转发子模块，用于将接收到的所述数据请求转换为REST请求，以由所述路由分发模块根据所述REST请求的PageJSON扩展属性的数值确定其对应的处理方法，并将所述REST请求分发至对应于所述处理方法的业务插件，由该业务插件进行处理。在该技术方案中，通过对数据请求的格式的转换和统一管理，从而能够对采用传统的、非OSGI架构的web应用进行更好地兼容。

在上述技术方案中，优选地，所述系统中设置有核心插件，所述监听管理模块通过所述核心插件实现对所述业务插件和/或服务的监听。在该技术方案中，在OSGI框架内存在核心（core）插件，则可以直接利用该核心插件对系统内的业务插件和/或服务进行监听。

在上述技术方案中，优选地，所述依赖管理模块还为每个所述业务插件内部的对象之间提供依赖，具体包括：所述系统启动时为指定的业务插件创建一个IocContext类，并根据所述IocContext类的配置注解对应的实例化对象，并管理所述实例化对象的生命周期，实现自定义的扩展点，然后利用所述自定义的扩展点为所述指定的业务插件内部的对象之间提供依赖。在该技术方案中，还对业务插件内部的对象进行依赖管理，有利于实现对业务插件的动态管理和热插拔。

在上述技术方案中，优选地，所述路由分发模块还用于：在当前节点上的业务插件不可用或抛出特定异常时，将所述数据请求分发至另一可用节点的业务插件。在该技术方案中，路由分发模块既能够实现节点内的分发，还能够实现节点之间的分发操作，从而有利于提高对数据请求进行处理的成功率。

在上述技术方案中，优选地，所述服务管理模块通过钩子机制统一管理发布的服务。在该技术方案中，利用钩子机制有利于提升框架的稳定性。

在上述技术方案中，优选地，所述服务管理模块发布的服务为REST服务，指定的业务插件利用所述服务管理模块发布REST服务的过程包括：与所述指定的业务插件相关联的类继承基础服务资源（Base ServerResource），并由所述指定的业务插件按照默认配置项或按照通过实时注解而标注的配置项，发布对应的REST服务。在该技术方案中，采用本发明的框架的服务器或后台发布的服务均为REST服务，从而统一的服务类型，有利于框架的稳定性和可扩展性。

在上述技术方案中，优选地，所述配置项包括以下至少之一或其组合：服务名、端口、连接数。

在上述技术方案中，优选地，还包括：依赖状态判断模块，用于判断所述指定的业务插件是否依赖于restful插件，若依赖，则按照所述restful插件对应的配置项进行发布REST服务，否则按照默认配置项进行发布。

在上述技术方案中，优选地，还包括：资源插件扩展模块，用于在默认映射规则不符合当前业务需求时，按照所述资源插件提供的定制接口中的方法，扩展URL地址和实际资源路径之间的映射。在该技术方案中，还能够对框架内的资源插件进行扩展，从而适应于实时的业务需求。

通过以上技术方案，可以实现对web应用的模块化开发管理、动态化配置和扩展。

附图说明

图1示出了根据本发明的实施例的软件架构系统的框图；

图2示出了根据本发明的实施例的软件构架的部署结构的示意图；

图3示出了根据本发明的实施例的OSGI系统框架的示意图；

图4A示出了PageJSON数据结构的示意图；

图4B示出了ResultData数据结构的示意图；

图5示出了根据本发明的实施例的HTTP服务请求的流向示意图。

具体实施方式

为了能够更清楚地理解本发明的上述目的、特征和优点，下面结合附图和具体实施方式对本发明进行进一步的详细描述。需要说明的是，在不冲突的情况下，本申请的实施例及实施例中的特征可以相互组合。

在下面的描述中阐述了很多具体细节以便于充分理解本发明，但是，本发明还可以采用其他不同于在此描述的其他方式来实施，因此，本发明的保护范围并不受下面公开的具体实施例的限制。

图1示出了根据本发明的实施例的软件架构系统的框图。

如图1所示，根据本发明的实施例的软件架构系统100，所述软件架构系统100基于OSGI规范和REST原则实现，所述系统100包括：监听管理模块102，用于监听OSGI容器内的所有业务插件和/或服务，所述业务插件用于根据外部的数据请求执行相应的业务逻辑；依赖管理模块104，用于提供和管理多个所述业务插件之间的OSGI服务依赖；服务管理模块106，用于控制所述业务插件执行业务逻辑，控制所述OSGI容器内的服务的发布和停止，以及实现对所述OSGI容器内的资源插件的静态资源管理；路由分发模块108，用于接收来自浏览器的数据请求，若所述数据请求存在扩展属性，则根据所述数据请求的扩展属性的数值确定其对应的处理方法，并将所述数据请求分发至对应于所述处理方法的业务插件，由该业务插件进行处理，若不存在扩展属性，则按照REST原则的默认规则进行分发至对应的业务插件。在该技术方案中，使用OSGI规范和REST原则搭建起用于web应用的软件开发的OSGI框架。通过对框架内的插件和/或服务的监听，能够了解到框架内的插件运行和依赖情况，从而实现对插件的热插拔；通过对框架内的插件的依赖控制，从而避免插件之间的过度依赖，有利于生成的web应用的模块化设计和动态化调整；通过对数据请求的路由分发，从而有利于对来自浏览器（客户端）的请求的及时、有效地处理。

在上述技术方案中，优选地，还包括中间件模块110，所述中间件模块110具体包括：格式管理子模块1102，用于将所述数据请求统一映射到PageJSON对象中，并将返回值所述浏览器的返回数据统一封装为ResultData对象、且所述返回数据的数据格式为JSON字符串；请求转发子模块1104，用于将接收到的所述数据请求转换为REST请求，以由所述路由分发模块根据所述REST请求的PageJSON扩展属性的数值确定其对应的处理方法，并将所述REST请求分发至对应于所述处理方法的业务插件，由该业务插件进行处理。在该技术方案中，通过对数据请求的格式的转换和统一管理，从而能够对采用传统的、非OSGI架构的web应用进行更好地兼容。

在上述技术方案中，优选地，所述系统中设置有核心插件，所述监听管理模块102通过所述核心插件实现对所述业务插件和/或服务的监听。在该技术方案中，在OSGI框架内存在核心（core）插件，则可以直接利用该核心插件对系统内的业务插件和/或服务进行监听。

在上述技术方案中，优选地，所述依赖管理模块104还为每个所述业务插件内部的对象之间提供依赖，具体包括：所述系统启动时为指定的业务插件创建一个IocContext类，并根据所述IocContext类的配置注解对应的实例化对象，并管理所述实例化对象的生命周期，实现自定义的扩展点，然后利用所述自定义的扩展点为所述指定的业务插件内部的对象之间提供依赖。在该技术方案中，还对业务插件内部的对象进行依赖管理，有利于实现对业务插件的动态管理和热插拔。

在上述技术方案中，优选地，所述路由分发模块108还用于：在当前节点上的业务插件不可用或抛出特定异常时，将所述数据请求分发至另一可用节点的业务插件。在该技术方案中，路由分发模块既能够实现节点内的分发，还能够实现节点之间的分发操作，从而有利于提高对数据请求进行处理的成功率。

在上述技术方案中，优选地，所述服务管理模块106通过钩子机制统一管理发布的服务。在该技术方案中，利用钩子机制有利于提升框架的稳定性。

在上述技术方案中，优选地，所述服务管理模块106发布的服务为REST服务，指定的业务插件利用所述服务管理模块106发布REST服务的过程包括：与所述指定的业务插件相关联的类继承基础服务资源（BaseServer Resource），并由所述指定的业务插件按照默认配置项或按照通过实时注解而标注的配置项，发布对应的REST服务。在该技术方案中，采用本发明的框架的服务器或后台发布的服务均为REST服务，从而统一的服务类型，有利于框架的稳定性和可扩展性。

在上述技术方案中，优选地，所述配置项包括以下至少之一或其组合：服务名、端口、连接数。

在上述技术方案中，优选地，还包括：依赖状态判断模块112，用于判断所述指定的业务插件是否依赖于restful插件，若依赖，则按照所述restful插件对应的配置项进行发布REST服务，否则按照默认配置项进行发布。

在上述技术方案中，优选地，还包括：资源插件扩展模块114，用于在默认映射规则不符合当前业务需求时，按照所述资源插件提供的定制接口中的方法，扩展URL地址和实际资源路径之间的映射。在该技术方案中，还能够对框架内的资源插件进行扩展，从而适应于实时的业务需求。

本发明希望利用OSGI规范和REST原则的优势，实现对传统的软件架构系统的突破，设计出稳定、高效、动态化、模块化、可扩展性、实用性强的基于的OSGI软件架构。

其中，OSGI(Open Service Gateway Initiative)开放服务网关实际是一个由OSGI联盟发起、以Java为技术平台的动态模块化规范。目前业界实现OSGI规范的平台主要有Apache Felix、Eclipse Equinox、Knopflerfish等。其实，OSGI不仅仅是一种技术或规范，更是一种软件架构设计的理念、方法。构建基于OSGI的软件架构至少有以下几个优势：在规范的架构、组件标准统一约束下，去实现组件复用并加强软件架构的自我约束能力；更加适用于团队敏捷协作开发；提升框架的稳定性、扩展性，从而达到有效提升产品质量的目的。

而REST（Representational State Transfer）是Roy Fielding博士在2000年他的博士论文中提出的一种软件架构风格。REST将web服务视为资源，可以由其唯一的URI唯一标识。REST的主要规范包括了客户/服务器、无状态、缓存、统一接口、分层系统以及按需代码等。REST服务相对SOAP、XML-RPC来讲，更加轻量、简单，同时还能满足异构平台的互访，具备高度的可重用特性。

因此，通过对OSGI规范和REST原则的利用，能够很容易在标准的架构模块化规范约束下引导程序员实现模块化的拆分、重用，从而有效地控制软件复杂度增长、加强架构的约束力。

下面将结合图2至图5，对基于本发明的技术方案的软件架构系统进行详细说明。具体地，在以下实施例中，将采用遵循OSGI标准规范的Apache Felix作为OSGI平台，并基于此平台整合Restlet构建软件架构。

图2示出了根据本发明的实施例的软件构架的部署结构的示意图。

如图2所示，根据本发明的实施例的软件构架的部署结构包括：

OSGI容器204，用于接收浏览器202发送的HTTP请求。OSGI容器204是基于Apache Felix平台、依照REST规范要求而建立的，其中包含有如业务插件206等，用于实现具体的业务逻辑等。对于OSGI容器204的具体构成和功能，下文将结合图3进行详细说明。

该软件构件中还包含有J2EE容器208，其中包含有若干个war包。对于本领域的技术人员应该了解的是：对于J2EE容器208，通常是在做好一个web应用之后，可以将其打包后部署到J2EE容器208中；而在图2所示的技术方案中，J2EE208实际上是用于对采用传统平台（具体是指区别与本申请的软件架构的平台）开发的web应用进行兼容的中间件，具体比如用于对浏览器202发出的HTTP请求的格式进行统一转换等。

图3示出了根据本发明的实施例的OSGI系统框架的示意图。

如图3所示，示出了图2中的OSGI容器204的具体结构示意图，其中包括：

路由分发器302，用于对来自浏览器的数据请求（比如HTTP请求）进行路由和分发。具体地，通过查看数据请求所要求的执行方法，从而将其分发至对应的业务插件304，以进行具体的业务逻辑处理。

业务插件304，接收路由分发器302分发的数据请求，并执行具体的业务逻辑处理工作。

服务管理器306，提供扩展机制，需要各个业务插件304实现具体的业务逻辑，支持服务的动态发布和停止等。

资源插件(即Resource Bundle)308，用于为服务的发布、业务逻辑的处理过程等，提供所需要的资源。其中，可以基于开源HTTP Service310进行扩展扩展点主要是扩展资源映射规则即URL地址和实际资源路径之间的映射，若默认映射规则符合业务需求，则业务bundle不需要扩展，直接按照默认规则将资源存放于相关目录；若需要定制，则需要实现资源bundle提供的定制接口中的方法。

管理控制台314，或称为模块仓库，用于通过利用框架提供的核心插件(core bundle)312监听OSGI容器中各插件、服务的整个生命周期，具体由Context Manager类实现。监听操作的具体实现原理是Bundle Context通过注册自定义Service Listener（服务监听）、Bundle Listener（插件监听）等实现；二是通过Apache Fleix平台内置的命令由程序执行对插件的操作。

通过本发明的技术方案，其核心需要实现的实际上包括“六统一”，即：统一数据模型，由框架提供统一的数据交互模型，包括请求、返回数据对象；统一请求交互模式；统一服务风格，由框架提供统一的REST服务发布机制；统一组件依赖，由框架提供统一的服务依赖机制、IOC机制；统一静态资源处理机制，框架提供统一的资源注册、管理机制；统一模块仓库，支持动态禁用、增加、更新、卸载模块。

统一数据模型：对于页面数据，传统的Spring MVC、Struts往往为不同的页面请求创建多个view或form，其实页面过来的请求数据无非就是一个表单或请求参数，因此可以将页面请求数据统一映射到PageJSON对象中，其中PageJSON数据结构如图4A所示。服务端或后台返回给页面的数据全部封装为ResultData对象，最终返回给页面的数据格式同样也为JSON字符串，其中ResultData数据结构如图4B所示。对于一般业务功能处理模块而言，只需要向上述2类对象set相关业务数据，其它均由框架统一处理。

统一请求交互模式：基于统一的数据模型，因此前后交互的数据格式均为JSON字符串，页面的请求统一为post请求(当然框架自身也支持get请求等)。

统一服务风格，即服务端或后台发布的服务均为REST服务，其发布的细节如下：若一个业务插件需要发布REST服务，只需相关类继承BaseServerResource（基础服务资源）并根据实际需要通过注解的方式标注服务名、端口、连接数等配置项（若没有标注注解，则框架采用默认配置项）。至于restful bundle（restful插件，用于对服务的风格进行统一）统一发布rest服务的实现原理：业务插件启动时，restful bundle会动态判断业务插件是否依赖restful bundle，若依赖则优先按照其配置发布，否则就按默认配置发布。基于业务特性，大概90%的请求都是post或put请求，因此对此两种方法做了资源映射扩展支持，如果请求的PageJSON扩展属性extra的值不为null，则框架restful bundle对自动将请求转发到extra指定的方法去执行；否则由直接请求的方法执行逻辑处理。通常情况下，某一节点上restful bundle在容器内分发路由REST请求即可。不过，也存在单一节点上业务bundle的服务可用，但执行方法的逻辑运行过程中抛出特定异常(RestUnusedException)或突然不可用，此时路由分发器会将该请求分发到另一可用节点上。即路由分发器存在两重路由功能：容器内路由（即同一节点内部的路由和分发）、容器间路由（即不同节点之间的路由和分发）。

统一组件依赖：基于开源组件框架iPOJO进行扩展，框架约定各业务插件之间的依赖均为OSGI服务依赖(业务逻辑上存在层次关系的业务插件禁止包依赖或完全的插件依赖)，而OSGI服务依赖由原生的iPOJO管理，业务插件的内部对象之间的依赖由自定义的扩展点进行处理。自定义扩展点利用Spring Ioc原理，框架启动时为每个业务插件创建一个IocContext，然后根据每个类的配置注解实例化相关对象，并管理对象的生命周期。

统一静态资源处理：资源插件(即Resource Bundle)基于开源HTTPService进行扩展。扩展点主要是扩展资源映射规则即URL地址和实际资源路径之间的映射，若默认映射规则符合业务需求，则业务插件不需要扩展，直接按照默认规则将资源存放于相关目录；若需要定制，则需要实现资源插件提供的定制接口中的方法。

统一模块仓库：模块仓库就是框架的管理控制台，利用框架提供的核心bundle(core bundle)监听OSGI容器中各bundle、服务的整个生命周期,具体由ContextManager类实现。具体实现原理是BundleContext通过注册自定义ServiceListener、BundleListener等实现；二是通过Fleix内置的命令由程序执行对bundle的操作。

图5示出了根据本发明的实施例的HTTP服务请求的流向示意图。

如图5所示，基于本发明的技术方案建立的软件架构系统（或称OSGI框架），对于HTTP服务请求进行处理的过程如下：

假定由浏览器501发出某个HTTP服务请求，则存在两种情况，一种情况下，由完全基于本发明的技术方案生成的web应用进行处理，则直接传输至路由分发器504；另一种情况下，若由传统的web应用进行处理，则传输至中间件502，由中间件502进行处理后，再转发给路由分发器504。

中间件502主要是对来自浏览器501的HTTP服务请求进行统一封装数据格式，然后根据映射规则发送REST请求到OSGI容器。映射规则支持动态配置。因此，通过中间件502对HTTP服务请求的格式进行统一封装，使得本发明能够对传统web应用进行兼容，具有很好的兼容性。

路由分发器504提供扩展、钩子机制。支持业务插件采用默认的路由分发，也可由业务插件去扩展，框架通过钩子机制统一管理对外发布的服务。具体地，路由分发器504根据HTTP服务请求所需要的处理方法进行路由分发。

基础服务资源506，匹配HTTP服务请求到业务插件对应的方法，以进行具体的业务逻辑处理。

比如将HTTP服务请求分配至业务插件508A，则由业务插件508A执行业务逻辑处理；而当业务插件508A返回如特定异常或突然不可用时，则路由分发器504可以将HTTP服务请求分发至另一节点上的业务插件，比如业务插件508B，以提升整个框架的可靠性。

以上结合附图详细说明了本发明的技术方案，通过本发明的技术方案，能够实现以下有益效果：

1）模块化，特别是对于复杂的系统集成，能有效控制软件复杂度增长、避免或延缓架构腐化。

2）动态化，解决发版停机问题。

3）扩展性、稳定性更好。

4）采用此方案的老项目，迁移到OSGI非常平滑，对其应用架构冲击非常小。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种软件架构系统，所述软件架构系统基于OSGI规范和REST原则实现，其特征在于，所述系统包括：

监听管理模块，用于监听OSGI容器内的所有业务插件和/或服务，所述业务插件用于根据外部的数据请求执行相应的业务逻辑；

依赖管理模块，用于提供和管理多个所述业务插件之间的OSGI服务依赖；

服务管理模块，用于控制所述业务插件执行业务逻辑，控制所述OSGI容器内的服务的发布和停止，以及实现对所述OSGI容器内的资源插件的静态资源管理；

路由分发模块，用于接收来自浏览器的数据请求，若所述数据请求存在扩展属性，则根据所述数据请求的扩展属性的数值确定其对应的处理方法，并将所述数据请求分发至对应于所述处理方法的业务插件，由该业务插件进行处理，若不存在扩展属性，则按照REST原则的默认规则进行分发至对应的业务插件。

2.根据权利要求1所述的系统，其特征在于，还包括中间件模块，所述中间件模块具体包括：

格式管理子模块，用于将所述数据请求统一映射到PageJSON对象中，并将返回值所述浏览器的返回数据统一封装为ResultData对象、且所述返回数据的数据格式为JSON字符串；

请求转发子模块，用于将接收到的所述数据请求转换为REST请求，以由所述路由分发模块根据所述REST请求的PageJSON扩展属性的数值确定其对应的处理方法，并将所述REST请求分发至对应于所述处理方法的业务插件，由该业务插件进行处理。

3.根据权利要求1所述的系统，其特征在于，所述系统中设置有核心插件，所述监听管理模块通过所述核心插件实现对所述业务插件和/或服务的监听。

4.根据权利要求1所述的系统，其特征在于，所述依赖管理模块还为每个所述业务插件内部的对象之间提供依赖，具体包括：所述系统启动时为指定的业务插件创建一个IocContext类，并根据所述IocContext类的配置注解对应的实例化对象，并管理所述实例化对象的生命周期，实现自定义的扩展点，然后利用所述自定义的扩展点为所述指定的业务插件内部的对象之间提供依赖。

5.根据权利要求1所述的系统，其特征在于，所述路由分发模块还用于：在当前节点上的业务插件不可用或抛出特定异常时，将所述数据请求分发至另一可用节点的业务插件。

6.根据权利要求1至5中任一项所述的系统，其特征在于，所述服务管理模块通过钩子机制统一管理发布的服务。

7.根据权利要求1至5中任一项所述的系统，其特征在于，所述服务管理模块发布的服务为REST服务，指定的业务插件利用所述服务管理模块发布REST服务的过程包括：

与所述指定的业务插件相关联的类继承基础服务资源，并由所述指定的业务插件按照默认配置项或按照通过实时注解而标注的配置项，发布对应的REST服务。

8.根据权利要求7所述的系统，其特征在于，所述配置项包括以下至少之一或其组合：服务名、端口、连接数。

9.根据权利要求7所述的系统，其特征在于，还包括：

依赖状态判断模块，用于判断所述指定的业务插件是否依赖于restful插件，若依赖，则按照所述restful插件对应的配置项进行发布REST服务，否则按照默认配置项进行发布。

10.根据权利要求1至5中任一项所述的系统，其特征在于，还包括：

资源插件扩展模块，用于在默认映射规则不符合当前业务需求时，按照所述资源插件提供的定制接口中的方法，扩展URL地址和实际资源路径之间的映射。

Images