突破时间、空间及不同硬件设备的限制,利用客户和软件之间统一的接口实现跨平台的互操作。
为满足上述要求,软件构件技术出现了。而构件重用的目标是达到需求、分析、设计、编码、测试的重用。从此,一种影响软件产业发展的新的软件开发方法诞生了。
从抽象程度来看,面向对象技术已达到了类级重用(代码重用),它以类为封装的单位。这样的重用粒度还太小,不足以解决异构互操作和效率更高的重用。构件将抽象的程度提到一个更高的层次,它是对一组类的组合进行封装,并代表完成一个或多个功能的特定服务,也为用户提供了多个接口。整个构件隐藏了具体的实现,只用接口提供服务。这样,在不同层次上,
构件均可以将底层的多个逻辑组合成高层次上的粒度更大的新构件,甚至直接封装到一个系统,使模块的重用从代码级、对象级、架构级到系统级都可能实现,从而使软件像硬件一样,能任人装配定制而成的梦想得以实现。近几年来,构件技术的发展已证明了它的巨大威力,在这其中,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)具有集成能力和其他的一些特性。所以,对构件概念的理解,必然与体系结构强加于构件的这些限制密切相关。
许多专家认为,尽管构件与其所属的体系结构密切相关,但是上述的两种接口仍然过于强调构件框架在软件体系结构中的地位。而实际上,很多人都曾极力地寻求软件体系结构和构件框架的区别。但是通过对体系结构的三种不同观点的定义,保留构件框架概念的二义性: