众说纷纭话构件

标准不统一

软件界对于构件的确切定义并没有完全达成一致。EJB显然是一种构件;同时，J2EE的整个表达层也可以被看成为一个构件;此外，以Web服务形式包装好的任何应用资源应该也是构件。

通常而言，“构件”这个术语表示一个软件模块，这个模块可以包装成编译好的形式，因此可以独立地作为应用程序地一部分，或者被组装到更大的构件中去。

为了规范对构件的认识，有必要建立构件技术的标准。一般而言，这样的标准应该由代表广大厂商的工业标准化组织来制定以便被广泛地遵守。所以，拥有着全球800多家成员企业的对象管理组（OMG）承担起了制定构件标准的重任，并最终制定出完善的CORBA规范，成为构件技术的最重要标准。

但是由于工业标准的制定牵涉到的成员企业非常多，因此不易统一认识，所以这种标准的制定周期往往很长。这就导致少数心急的企业自起炉灶，制定自己的标准。同时也有些企业认为工业的标准过于复杂，不容易完全实现，所以可能会对标准做出取舍和简化。另外还有些企业，出于自身利益的考虑，吸收工业标准的精华，但是完全基于自己的平台制定类似的标准。自定义的标准往往生命力不强，很快会被淘汰，但是某些大公司却可能由于广泛的用户群的存在，使得自己的标准甚至超过工业标准的影响力。

同时，也是由于CORBA规范过于庞大，几乎没有任何一家软件厂商，包括IONA和Visigenic等少数能够提供ORB基础设施的企业在内，能够完整地实现整个CORBA的重量级体系结构，这无疑会影响CORBA规范的应用，最终导致CORBA成为一个只能借鉴无法效仿的构件技术标准。

相反，Sun公司所提出的JavaBean/EJB和微软提出的COM/DCOM/COM+两大构件模型却显示出巨大的生命力，成为现在主流软件世界中的两个事实上的标准。

阐述不一致

目前，一些软件公司的应用系统已经越做越大，自身积累了大量的软件资产，但是与此同时，在系统维护和升级上的开销也随着越来越大。为此，各个企业都不同程度地考虑到系统扩充和拓展的需要，对自己的软件产品做了提炼，从中萃取出了许多可重用的系统模块，并顺应潮流地称之为“构件”，然后基于构件组装的思想分别做了适应性的“重构”，以便支持更灵活的软件改进和定制。

最终，在“构件”一词的遮蔽下，存在着各种不同角度的阐述。在不同的语境下，构件有可能是指一个标准的CORBA/EJB/DCOM构件，也可能是一个较宏观的系统模块，还可能只是一个非常微观的某个类的操作。

虽然这些称谓存在一定的混乱，但是还好与构件思想的精髓出入不大。总地来看，大家对构件的定义还是基本上达成了共识。

一般而言，构件应该是一个可以独立配置的单元，因此构件必须是自包含的;构件既然是可以独立使用的，那么它就可以与环境和其它构件相分离，所以构件的实现应该是严格封装的，外界没机会也没有必要了解构件内部的实现细节;多个构件可以在适当的环境中被组装到一起使用，因此每个构件需要提供清楚的接口规范，以便与环境和其它构件交互;构件在运行时应当是从属于它所部署的环境的，它的生命周期不应当超越外界环境的支持，等等。

在构件的定义上，不同的企业和个人可以大同小异或者求同存异，只要大家对于构件的认识基本到位，并基于某个互操作标准来实现构件的组装，就可以比较容易地解决各种历史遗留问题，在不必重砌炉灶的前提下，将过去留下的软件遗产变成重新焕发生命力的重要资产。