软件系统开发中的组件框架技术研究、设计和应用

计算机的应用已经从过去单纯的科学计算渗透到政务管理、商品交易、金融证券、军事指挥、航天航空、通讯导航、生物工程、医疗服务等多个领域。随着计算机技术的发展和应用范围的不断延伸，作为计算机灵魂的软件系统，其规模也在不断扩大，结构越来越复杂，代码越来越长、维护越来越困难，从过去几百行代码扩大到几万甚至几十万、几百万行代码的软件系统俯首皆是。因此，设计一个功能完善、结构优良，开发效率高，稳定性和安全性强，扩展方便，维护简单，易于复用，生命周期长，投资成本低的软件系统，一直是系统管理、设计和开发者所追求的目标之一。遗憾的是，现实生活中，被抛弃的软件系统随处可见，造成极大的投资浪费。原因之一是系统开发仓促编码，结构拙劣，功能扩展困难，稍有修改，便错误百出，无法维护，唯有弃之不用。 

软件发展的实践证明，模块化的分层设计模型是提高系统可用性和可维护性的主要途径。分层模型设计，既将整个软件系统划分为若干个相互独立的层次进行描述，层与层之间通过事先约定的接口相互通讯。某个层只负责一个或多个功能，各负其则，不越俎代庖。分层设计把一个复杂的问题分而治之，降低了复杂性，功能清晰、易于实现、修改和维护。

分层设计可以分为面向过程、面向对象、面向组件等设计模式。面向过程的设计使用结构化的面向过程的计算机语言来编码；面向对象的设计则使用面向对象的计算机语言来实现，而面向组件的设计则既可用面向过程，也可用面向对象的语言来实现。由于面向组件的设计，系统的耦合度低、复用性强、维护容易，已经成为软件系统设计和开发的主流技术。

组件软件技术的基本思想是：将大而复杂的软件应用分成一系列可先行实现、易于开发、理解和调整的软件单元组件。每个组件功能确定，单独设计，分开编码，最后用组件组装应用，完成系统开发和部署。因此，以组件为基础的软件系统解决方案，开发效率高，投资少，维护成本低，复用能力强，软件升级简单。

1、组件技术的发展现状

目前常用的组件框架模型，一类是与某一计算机操作系统密切相关，而另一类是跨计算机操作系统平台的。前者的典型代表是COM组件对象模型，以及在此基础上发展起来的ActiveX、DCOM、COM+、MTS和.NET等技术。COM组件具有二进制一级的兼容性，基本上与计算机编程语言无关，其缺点是目前只能运行在Windows 操作系统平台上，而不能在Linux 和Unix 系统中运行。COM并不只是面向对象的组件对象模型，它既可用面向过程，也可用面向对象的语言编码。但多采用的编码语言是VC++、VB和Delphi，性能要求高的场合也可用C语言来编码。COM已经广泛使用在Windows
操作系统中，浏览器、邮件收发系统，Web服务器、字处理软件中都广泛使用COM组件。跨计算机操作系统平台的组件模型其典型代表是CORBA，CORBA主要使用在Unix 类型的操作系统中，但它也可在Windows平台上运行。

从计算机语言来讲，组件模型有以Java语言为代表的框架和以C语言为基础的框架。前者在理论上可以跨平台运行，底层平台支持是JVM 技术，而后者则与虚拟机无关，直接在操作系统中运行，因此，速度快，运行效率高。从应用系统的角度来讲，目前市场上，主要是J2EE和.NET的竞争，两者理论上没有本质的区别，都是采用虚拟机技术。但J2EE可以跨平台运行，而.NET 则基本不行。在企业级的应用系统中，以Java 技术为基础的J2EE似乎更占优势。Java和. NET技术各有特长，因此，在信息系统建设中，应该允许两种技术存在，取长补短，协同发展，最大限度地提高系统开发的性价比和稳定性。

2、组件框架的体系结构

2.1、描述组件的要素

组件是事先定义了编程接口和功能、相互独立的软件单元。一个组件一般有组件标识符、接口、创建方法和功能等要素组成。组件标识符也就是组件的名字，在整个体系结构中必须是唯一的，它是客户程序使用组件的唯一标识。如在COM规范中，组件用一个128位的clsid，通过注册表将clsid与组件真实的物理文件名关联，实现组件的位置无关性。而J2EE框架中的组件则多使用名称服务和事先约定的特殊字符串表示。组件接口是组件与客户程序、容器交互和通讯的API。具体包括函数名称、参数和参数类型等内容。如在Java
语言中可用接口表示，在C语言中用相互有关系的一组函数表示，在C++中则可用虚函数描述。组件多有组件工厂创建，组件工厂也是组件，其创建一般由组件框架提供的系统函数来生成。组件的功能定义了组件需要完成的事情。通常情况下，组件标识符、组件接口、创建方法是组件对用户程序的契约和承诺，设计好后不能轻易改变，但组件的功能可以修改，体现多态性。

2.2、组件体系结构图 




总结目前常用的组件框架体系结构，组件框架的通用体系结构如图1所示。组件框架通常由容器、组件和粘合剂三部分组成。容器就是一个根据框架体系结构的API管理应用程序组件以及提供API访问的系统运行环境，容器是一个递归概念，它也是组件。组件则是遵循容器规范、实现API接口的功能部件。粘合剂主要供容器用来组装组件之间的相互关系，其多表现为一个或多个部署描述符和配置文件，流行的描述语法格式包括XML、属性文件和Windows系统中常用的段节式结构等。通过粘合剂，整个框架就能够实现组件的动态加载、相互去耦和多态性。组件框架体系结构也具有递归结构，即框架之中存在框架。

组件框架的通用体系结构除了上述三个功能部件外，还包括要求应用程序必须实现的组件协议API、容器服务API，容器声明服务API等。后两者一般由容器提供商开发，供应用程序组件通过容器上下文环境引用。

常见的组件体系结构J2EE、Struts、Spring、PicoContainer等均基于上述结构设计，具有非常高的开放性和可扩展性。

3、组件框架设计和开发 

3.1、组件框架设计的方法

实践中，组件框架设计应该采用分层设计模型，组件采用递归结构。每个框架不能依赖其他框架而存在，应该能够独立开发和部署。组件和组件之间，组件和框架之间只能通过API通讯。

将组件框架应该再细分成表现层框架、业务层框架、数据层框架、公共服务框架、基础框架、系统框架和与业务系统密切相关的业务框架等构成，除了具体的业务框架外，其他框架必须优先选择比较成熟的产品和免费框架。

组件设计过程中要精心定义组件的创建方法、组件标识符、接口规范和组件的功能等要素。组件多采用定义了良好接口的工厂组件创建，而工厂组件则由系统函数或系统对象创建。组件标识符主要采用GUID、接口名称、其他特定的字符串等表示，它是客户程序使用组件的逻辑名，应用系统在运行过程中，由容器将其与组件的具体实现映射。接口规范多用函数和抽象类的形式表现。组件的内部结构如图2所示。有组件工厂、组件服务提供者、抽象服务等。抽象服务是实现组件接口的一个抽象类，其目的是为了简化应用程序对组件的编码。应用程序只要继承该抽象类即可满足接口规范需要，而把精力集中到核心功能的实现上。




组件采用组件工厂、组件服务提供者、抽象服务等内部设计模式，可以极大地降低组件与使用该组件的客户程序的耦合度，客户程序只要使用组件的逻辑名，通过容器提供的名称服务得到组件接口即可利用组件提供的功能，而不必关心组件的内部具体实现，组件具有非常好的封装性。

系统函数或系统对象、组件标识符、接口规范一旦定义则不能轻易改变，否则，就会造成整个框架体系和使用此框架的所有应用程序的修改。这里唯一需要改变的是组件的功能，它由具体的应用程序实现。

框架设计需要解决的问题还包括容器规范、组件规范、容器提供服务和部署描述符设计、类装入方案等。部署描述符定义容器和组件之间的协议，并封装组件之间的相互关系。部署描述符要优先选择XML语言表达。
3.2、设计组件框架的原则和评价标准

当一个组件框架设计完成后，应该按照开闭原则、依赖倒转原则、接口隔离原则等对其进行评价，检查和评价整个系统的可维护性和可复用性。

按照开闭原则，要检查设计的组件框架是否满足对扩展开发，而对修改关闭，即整个框架在扩展其功能时，应当是在不修改代码的前提下便可，换言之，源代码不修改，框架行为就可改变。要实现开闭原则，组件的抽象化是关键，实践中，检查在框架中是否容易加入“即插即用”的组件便是经验之一。

依赖倒转原则，就是要检查系统要依赖于抽象，而不是依赖于具体的实现。即客户端编程要依赖于抽象耦合，而不是具体耦合，要针对接口编程，而不是针对实现编程。具体的讲，就是看一个组件在其逻辑名称、接口不改变的情况下，修改其对象名称、类名称以及具体实现的情况下，客户程序是否需要修改。如果不是，则该框架不符合依赖倒转原则，可扩展性和可维护性存在问题。

通过接口隔离原则，可以检查一个组件是使用了多个专门的接口，还是使用单一的总接口进行编程。如果使用过于臃肿的接口，便存在接口污染。一个接口应当简单地只代表一个角色，而不是多个角色。如果组件涉及多个角色，那么每一个角色应当由一个特定的接口代表。也就是说，一个接口其中的函数数量应该越少越好。

符合上述原则的框架，基本上是在高层次实现了系统的复用，也是一个易于维护的系统，才值得投入人力和物力去编码，否则，该框架的生命周期不会太长，系统开始修改之时，可能也是其终结之日。

4、组件框架的选择和应用

选择组件框架设计模式开发信息系统已经成为当今缩短系统开发周期、提高稳定性、降低维护成本、延长生命周期的主流技术。目前，从运行环境、基础框架到专业的业务实现方面均有可资利用的成熟框架。我们在开发专业的应用系统时，无论从时间，还是资金方面考虑，都有必要充分利用现成的框架体系结构。选择框架应该综合考虑，跨平台、成熟度、稳定性和规范程度等多种因素。

（1）在容器选择方面，对于需要跨平台的企业级应用，应该优先考虑Websphere、Weblogic等支持J2EE构架的商用服务器端系统。而对于访问量低、并发用户不多的应用则可以选择Tomcat、Jboss、Jfox等开源项目作为系统运行环境，其性价比非常高。对于图形界面要求高的系统也可以选择.NET作为系统运行容器。而开发客户端应用程序首选Eclipse、Netbeans等作为系统的运行容器。Eclipse和Netbeans都是用Java语言开发的基于插件的体系结构，源码开发，成熟度较高。前者目前主要用于集成C++、Java编译器和其他开发工具，以及整合工作流、系统部署等方面，得到了IBM等大公司的支持。后者主要的应用集中在Java应用程序方面的开发。它们的可扩展性和可维护性都比较高，作为客户端应用程序的容器非常理想，应用的部署和运行比较简单，比如Eclipse只要将开发好的插件压缩封装成jar包，拷贝到系统规定的Plugins目录中便可，几乎不需要什么配置，在因特网中有许多开源的插件可供使用，应用涉及的范围很广。

（2）对于基础框架，可供选择的框架有PicoContainer、Spring和Avalon等。PicoContainer框架基于注册模式封装组件关系。而Spring框架其组件均利用Java beans实现，支持国际化、事件监听、事务管理，支持内省反射和AOP技术，易于和Mail、JNDI及数据库集成。对于Avalon框架，定义的组件接口非常简单，比如，组件创建、销毁、服务等接口，函数单一，结构清晰，充分体现了接口隔离原则，实现起来均比较容易。这些框架属开源项目，帮助文档较多，有许多人在研究和开发，它们均可脱离J2EE应用服务器运行，是开发专用业务系统比较理想的基础框架。

（3）在系统的表现层，如果系统需要单点登录、能够集成其他应用和服务、提供个性化支持，则应该选择支持Ｐortal规范的框架作为表现层的容器。此类框架如   Weblogic Portal、IBM Websphere Portal等，其特点是系统比较成熟，但结构复杂，投资成本较高，页面的美工设计不够灵活，系统集成需要比较多的编程经验和编程知识，不适合系统维护力量较低，页面设计频繁改动的应用。免费的Ｐortal框架典型的是Jetspeed，其Portal组装使用PSML语言，结构良好，运行在Turbine框架之中，Turbine将页面视图划分为页面、布局、屏幕、导航和动作等组件，并利用属性文件封装，使用Velocity模板语言，表现和业务代码分离。Jetspeed和前述商用Portal相比，缺乏好的开发工具支持，比较适合技术力量雄厚的部门使用。

表现层还可以选择的一个框架就是Struts，其在许多系统开发中得到了广泛的支持。该框架有控制器组件、视图组件和插件等组成。完全基于MVC模式设计，组件关系利用符合XML规范的配置文件封装，并提供了控制器、插件等许多扩展点，支持国际化、无编程数据验证、配置性异常处理以及多应用部署，能够和EJB、SOAP集成，其中内置了几乎所有的HTML标签，和Tiles模板框架配合使用，能够开发出高质量的应用系统。

（4）在模型层和数据层，主要是将数据的概念模型映射成设计模型，大多数框架都是将和数据库通讯的JDBC驱动程序通过二次封装，屏蔽掉不同数据库之间在SQL语言方面的差异，减少开发人员用数据库系统实现数据持久化方面的知识，并为上层模块提供比较统一的系统调用。可资选择的框架除了著名的实体EJB外，还有如Hibernate、Toplink和Torque等轻量级的持久化框架，其实现大同小异，基本都是通过XML配置文件将数据概念模型中的字段映射成Java语言中的对象属性，编程人员一般只要按照DAO设计模式，用Java语言定义业务对象BO，并完成数据映射配置文件便可，减少了通过JDBC直接使用SQL语言的复杂度。此类框架的选择，一般应考虑支持目前的主流数据库系统，如Oracle、SQL
Server等。对于小型的应用还要考虑支持MYSQL、PostgreSQL等免费的数据库管理系统。这样更换数据库时，只要修改数据映射配置文件、数据库驱动程序和数据源配置便可，整个系统框架不用修改，提高了系统的稳定性和可维护性。

（5）在系统日志管理方面选择Log4j、XML解析框架选择Degester，工作流引擎选择OFBIZ、SHARK、OBE或JBPM等，内容管理选择基于管道技术的COCOON这些开源框架，均会缩短编码时间，提高系统的开发效率。

总之，在信息系统的开发中，重点应该放在规划业务系统，开发业务型框架，定义和实现信息系统本身的业务逻辑上，而对于所有业务系统通用的功能和逻辑应优先选择现有框架的有效组合实现，以期达到事半功倍的效果。