软件平台，中间件增值新领域

　　我们所说的“软件平台”用一个简单的公式给它定义如下:软件平台=中间件软件+通用业务组件。以中间件为核心的软件平台技术的产生是市场的必然要求，不同于一般国外厂商的基础架构软件,更强调对用户的直接价值。

　　对于政府部门的用户而言，软件平台意味着它一开始就应该具有基本的“业务”功能，可以快速地建立起政府的业务应用，业务系统还能进一步地扩展并随业务的变化而方便地调整。归纳起来，对于最终用户而言，软件平台首先意味着基础功能、快速建立和适应变化。市场上有这样的例子，如某个一站式办公软件平台、互联互通软件平台等。

　　对于应用开发商而言，软件的平台化首先意味着开发商把电子政务的业务需求的一些共性功能已经部分地实现在软件平台中，应用的开发不再是从头开始，可以基于现有软件平台定制，需要新开发的只是一部分应用程序。对于开发商而言，基于软件平台的开发可以有效地减少新代码的开发量，缩短开发周期、减少代码测试的工作量,提高软件的整体可靠性，最终降低成本。

　　对于中间件等基础软件供应商而言，提供平台化的软件包意味着厂商可能需要组合或集成多种中间件技术，在以中间件为核心的基础架构软件的基础上，向特定应用如电子政务，提供更多的、针对领域的通用化的功能，从而增加软件的附加值，为应用开发商提供更多的帮助。

　　软件平台的典型特征

　　我们可以把软件平台的典型特征初步地归纳为以下的几个要点。软件平台以中间件为基础，中间件是软件平台的核心支撑系统。软件平台一般是网络化的应用解决方案，需要基于中间件软件去构建。软件平台是应用系统的核心支撑，整个软件平台需要部署到用户的实际环境中去。

　　软件平台具有业务的通用性

　　软件平台的中间件层之上是通用的业务构件层。有人把这一层叫做业务基础平台，或者叫领域框架层。这一层软件是针对某一行业或特定类型应用（如电子政务）的通用的软件实现，具有业务的通用性。

　　软件平台不是最终的应用

　　虽然软件平台提供了一些针对行业或特定应用（如电子政务）的一些共性的功能，但它毕竟是不完整的。应用开发商需要基于平台开发特定应用需要的特定功能。

　　基于软件平台的应用能够方便地扩充

　　应用系统不可能一次建成，因此软件平台必须支持应用方便地扩充。软件平台的扩展能力来自于中间件软件的通用性和通用业务组件的可扩充能力。

　　提供应用开发工具

　　应用开发需要软件平台提供相应的开发工具。工具可能只是中间件层的，通用业务组件层也可能有工具支持。

　　基于软件平台的电子政务系统体系结构

　　我们这里借用国家电子政务标准化工作对“电子政务标准技术参考模型”的研究来体会电子政务软件平台在政务信息系统中的位置和作用。

　　根据“电子政务标准技术参考模型”，电子政务系统总体上可以建模为横向包含多个层次，管理和信息安全纵向贯穿各个层次的技术架构。参考模型的最底层是网络基础设施层，逐渐向上展开的是应用支撑层、应用层、公众服务网及电子政务的服务对象——政府、企业、社团和公民。其基本含义是，应用支撑层支持应用通过公众服务网向电子政务的服务对象服务;管理和信息安全是贯穿各个层次的保障。

　　在这个参考模型中，应用支撑层向电子政务应用层提供所需的各种通用服务，如资源共享、信息交换服务、业务访问、业务集成、安全可信和可管理等通用性的服务。在这一层中核心的是中间件软件。

　　应用层是基于应用支撑层构造的各种电子政务应用，是电子政务系统中面向最终用户的层面。如果我们进一步把针对电子政务的全部内容或者特定类型的应用的一部分共性功能抽象出来，就是 “通用业务组件”层。把“通用业务组件”层和下面的应用支撑层结合起来就构成了我们所定义的“软件平台”。根据应用的需要，软件平台可能提供更加具体的、不同的功能，如“交换与共享”平台、“互联互平台”和“一站式服务平台”。

软件平台在电子政务技术架构中的位置见图1。

图一

　　通用业务构件层的特点

　　通用业务构件一般表现为针对特定行业或特定类型应用的软件框架，或者说领域框架。框架性的软件是把许多应用需要的功能抽象成公共的设计和部分的实现，为一组类似的问题提供通用的解决方法。框架本质上是不完整的，特定应用需要的功能需要框架的用户——应用开发者去添上。通用业务组件层的出现改变了应用软件的研发模式，一方面它更高程度地实现了软件的复用，同时又支持用户的个性化需求的实现，能够快速地开发用户所需要的应用系统。

　　有观点认为，业务基础软件平台还有另一种表现形式，即“模型化业务基础软件平台”。基本上，组件化可以看成是基础业务平台的本质特征，模型化可以看成是生成业务构件的方法。模型化的方法让业务人员和系统的分析与设计人员在高层定制和开发应用，可以减少代码的编写，最终生成的系统仍然应是组件化的。一种影响越来越大的模型化的开发方法是，使用软件平台工具建立独立于基础架构层的应用模型，再基于应用模型生成运行在底层基础架构层的组件（程序）。

　　在面向对象的软件框架中，核心功能一般被实现为一组以特定方式交互的抽象的类，在导出具体的应用时，这些抽象的类由特定的具体子类替换。一般地说，软件框架的基本功能、通用性、灵活性及易用性决定了其框架是否好用。

　　电子政务互联互通软件平台

图2　基于互联互通平台的解决方案

　　我们来看一个实际的例子——东方通科技针对电子政务互联互通应用研发的互联互通平台。该平台集成了东方通科技自有的应用集成中间件TongIntegrator、消息中间件TongLINK/Q以及基于TongIntegrator、针对应用集成的集成组件。

　　TongIntegrator是一个基于Java的应用集成中间件软件，它支持数据与应用集成，具有一定的流程集成功能，支持组件化的应用集成。TongIntegrator的数据集成功能支持对多种关系数据库系统、XML文件及各种自定义格式文件的方便地访问;TongIntegrator的应用集成功能支持与基于TongLINK/Q、MQSeries、socket通信及提供本地API的任何应用的方便的集成;流程集成功能可以把数据源、应用整合到一个处理流程中。TongIntegrator框架中的集成组件具体负责与外部数据源和应用的交互、数据格式的转换和对数据的处理和加工。TongIntegrator提供一些标准的预置集成组件，针对特定应用特定需求的集成组件可以依据系统提供的组件框架或开发方法新开发。一个TongIntgrator支持多组应用的集成。

　　平台中的另一个中间件TongLINK/Q是一个支持JMS的消息中间件。TongLINK/Q提供基于队列的异步的消息传输功能，支持可靠传输和点对点及订阅和发布消息传输模式。依靠TongLINK/Q的异步消息传输机制，集成中间件TongIntegrator把触角延伸到远地的应用。

　　在整个互联互通平台中，TongIntegrator及TongLINK/Q是集成平台的中间件层，针对数据及应用集成的TongIntegrator预制组件是平台的通用业务组件层。两者结合起来构成了支持电子政务互联互通的“互联互通软件平台”。

　　我们以城市市民卡应用为例来具体说明软件平台在应用中的功能和部署。为达成以卡中心为中心，实现与城市各个只能部门业务系统的互联互通的应用目标，可以把TongIntegrator及TongLINK/Q 服务器端软件部署到市民卡中心，通过在各个职能部门部署的基于TongLINK/Q的应用代理可以把远地各部门的应用系统集成在一起。卡中心的本地数据库系统可以直接被TongIntegrator的集成组件访问。对关系数据库的数据、卡应用相关的XML文档、自定义格式文件的访问，可以比较简单地通过配置文件定制。如果在各职能部门仍需要集成多个应用系统和/或数据源，可以在那里部署同样的一套软件平台。为更方便地实现数据备份功能，软件平台还提供了支持在关系数据库之间备份数据的集成组件。(见图2)

　　在市民卡应用中，软件平台的中间件层较好地解决了异构系统的互联，并且为各种不同的系统的集成提供了一个集成的框架;软件平台的通用业务组件层提供了实现快速的应用集成的预置组件。整个集成过程便捷、快速、可靠。应用系统的集成不必一次完成，可以逐渐、替增地进行。

　　互联互通平台较好地实现了东方通科技针对电子政务互联互通应用需要提出的预先构想。未来软件平台还要不断地完善和扩充，提供更多的满足互联互通的更丰富更深入需求的通用集成组件。

　　满足需要是关键

　　软件平台给国内软件业带来机会。软件平台的良好发展必然会影响电子政务应用的开发模式、服务模式，甚至可能会改变一些软件企业的商业模式。对于一个具体的软件平台，要获得成功关键在于针对应用抽象而实现的通用业务组件是否满足用户的需要、是否做得好。由于中间件软件相对成熟，能否成功通用业务组件就成了问题的关键。

　　通用业务组件层作为软件框架有其自身的技术要求。作为通用性的软件，随着业务的标准化、软件开发方法的标准化，通用业务组件层也要逐渐地走向标准和规范，这是一个比较长期的过程。在当前的国内电子政务应用过程中，软件平台能否切实地满足能否满足业务应用的通用与特殊需要，能否快速、可靠地支持业务系统的逐步地构建、支持变化的业务要求却是最根本性的目标。

原文转自：http://www.ltesting.net