构件技术应运而生 

　　在信息时代,新的技术革命正在改变我们日常生活的面貌，而这场技术革命的核心是计算机软件系统。在面向对象技术给解决软件危机带来曙光之时, 分布式网络计算的巨大压力又给软件开发提出了许多新的难题,使软件开发仍处于高风险状态。新的分布式网络计算要求软件实现跨空间、跨时间、跨设备、跨用户的共享，导致软件在规模、复杂度、功能上的极大增长，迫使软件要向异构协同工作、各层次上集成、可反复重用的工业化道路上前进。为适应软件的这种需求，新的软件开发模式必须支持分布式计算、浏览器/服务器结构、模块化和构件化集成，使软件类似于硬件一样，可用不同的标准构件拼装而成。具体地说可实现下列几点要求： 

　　● 提供一种手段，使应用软件可用预先编好的、功能明确的产品部件定制而成, 并可用不同版本的部件实现应用的扩展和更新。 

　　● 利用模块化方法，将复杂的难以维护的系统分解为互相独立、协同工作的部件，并努力使这些部件可反复重用。 

　　● 突破时间、空间及不同硬件设备的限制，利用客户和软件之间统一的接口实现跨平台的互操作。 

　　为满足上述要求，软件构件技术出现了。而构件重用的目标是达到需求、分析、设计、编码、测试的重用。从此，一种影响软件产业发展的新的软件开发方法诞生了。 

　　从抽象程度来看，面向对象技术已达到了类级重用(代码重用)，它以类为封装的单位。这样的重用粒度还太小，不足以解决异构互操作和效率更高的重用。构件将抽象的程度提到一个更高的层次，它是对一组类的组合进行封装，并代表完成一个或多个功能的特定服务，也为用户提供了多个接口。整个构件隐藏了具体的实现，只用接口提供服务。这样，在不同层次上， 构件均可以将底层的多个逻辑组合成高层次上的粒度更大的新构件，甚至直接封装到一个系统，使模块的重用从代码级、对象级、架构级到系统级都可能实现，从而使软件像硬件一样，能任人装配定制而成的梦想得以实现。近几年来，构件技术的发展已证明了它的巨大威力，在这其中，CORBA标准和Java技术的突破，功不可没！ 

　　至今, 构件技术已形成三个流派:Sun的Java平台、Microsoft的COM+、IBM的CORBA。 

构件发展自律当先 

　　基于构件的软件开发技术近年来取得了突飞猛进的发展，这不仅对软件产业的技术革新影响深远，还将为许多其他领域带来巨大的效益。早在1998年4月，在日本京都召开的基于构件的软件开发(CBSD)国际专题学术会议上达成了两个共识： 

1. 对于CBSD而言，对象技术并不是必需的，同时仅仅依靠对象技术也不能实现CBSD。 

　　这似乎有些难以理解。对象技术仅仅是CBSD的开始，但是就对象技术本身而言，它并不能全面地表述CBSD所需的抽象概念，而且脱离对象技术，CBSD也完全可以实现。因此，对于CBSD而言，对象技术既不是必需的，仅有对象技术也是不够的。CBSD将导致使用对象技术的系统设计方法、项目管理方法和组织形式的实质性变革。 

　　具体地说，将构件看做是一个可替换的单元时，单纯的对象技术就不够了。构件的各种定义中都或多或少地强调了构件的一个特性：对上下文的依赖性。这一特性能够通过在规范中定义一种“use”语句而实现，也就是对所需系统资源的一种声明。尽管对这种方式很多人持有异议，他们认为使用这种“use”语句,意味着接口描述就是一种实现机制，而不是一种对实现方法的抽象，但是,对象技术却根本不支持构件的这种特性，这样不利于进行设计层的抽象，特别是在试图使用已有的构件进行集成时,经常会遇到麻烦。 

　　现在人们比较一致的观点是将分布式对象技术当做是一种基础设施，而把构件看做是能够应用于不同的基础设施的抽象和实现。 在实践中人们也体会到这一点，如长事务的处理不能靠对象技术来解决。由于事务的原子性、一致性、隔离性和持久性的特点，不能把长事务简单地看成一个对象,它是一连串处理步骤的序列。这也是企业应用软件中常遇到的问题,目前一些服务器上的软件提供的事务服务,就是为了解决这个复杂的疑难问题。

2．构件离不开体系结构 

　　由于发展CBSD的一个初衷是通过一种集成的开发方式来增强系统的灵活性，因此自然要考虑这种集成方式的可行性。然而,通过抽象接口来描述,已经超出了对象技术的能力。但是，对“插件”式构件的重用程度，与构件对一套预先定义的限制和约定的依赖程度有直接的关系。 

　　大多数构件技术如EJB、ActiveX、CORBA等对于构件都有一定的限制。例如，尽管构件基础设施对构件的接口有一定的访问能力，但这种能力要求构件必须能够实现一定的服务或遵循构件基础设施所定义的一些规范。 

　　许多专家认为，构件应当实现两种接口：一种是功能性接口，能够反映构件在系统中的角色；另一种是非功能性接口，能够反映由底层的构件框架所定义的构件模型。非功能性接口描述了一种体系结构上的限制，这种限制允许CBS（components-based system）具有集成能力和其他的一些特性。所以，对构件概念的理解,必然与体系结构强加于构件的这些限制密切相关。 

　　许多专家认为，尽管构件与其所属的体系结构密切相关，但是上述的两种接口仍然过于强调构件框架在软件体系结构中的地位。而实际上，很多人都曾极力地寻求软件体系结构和构件框架的区别。但是通过对体系结构的三种不同观点的定义,保留构件框架概念的二义性： 

　　● 运行期间：包括为基于构件的系统提供运行时服务的框架和模型。 

　　● 设计期间：包括对构件的特定观点，如功能性接口和构件依赖性。 

　　● 集成期间：包括系统对各种构件进行集成时所需的各种因素，如生成器和一些构造期间的服务，一个构件框架可能就会提供这些服务。 

　　在研讨中出现的这些关于构件的更多特性,表明构件是一种设计阶段的复杂实体，它包括抽象的概念和具体的实现。 因此，许多专家认为，使用现成构件的CBSD,把构件视为一种商业上的现成商品，在这种情况下，CBSD必须建立关于构件框架的行业规范。 

构件影响不可小觑 

　　要实现构件技术必须具备下列几个条件: 

　　● 有标准软件体系结构,保证构件间通信协议统一, 实现同步和异步操作控制，突破本地空间限制,充分利用网络环境。 

　　● 构件有标准接口, 保证系统可分解成多个功能独立的单元, 用构件组装而成。 

　　● 构件独立于编程语言。 

　　● 构件提供版本兼容, 来实现应用系统的扩展和更新。 

　　总之，CBSD为软件开发技术带来了新的生机，其影响力正在显现。