loading从要素组件中得到了联合的规范。
如果组件符合了客户端调用和服务的规范，那么它们不需要额外编写代码就能够实现交互操作（interoperate）。这一般被称为即插即用（plug-and-play）集成。在运行时间执行的时候，这是后期连接的一种形似。例如，某个客户端组件可以通过在线目录发现组件服务器（类似CORBA Trader服务）。组件符合客户端和服务接口规范后，就能够建立彼此之间的运行时绑定，并通过组件的下部构造无缝地交互作用。
在完美的情形中，所有组件都将完全符合它们的规范，并且从所有的缺陷中解放了出来。组件的成功的运行和交互操作依赖于很多内部和外部因素。安全性（Safety）属性可能是有用的，因为它可以最小化某个组件环境中的全部类的缺陷。随着社会日益依赖于软件技术，安全性已经成为一种重要的法定利害关系，并成为计算机科学研究中的最重要的课题之一。例如，Java的垃圾收集（garbage collection）特性保证了内存的安全性，或者说从内存分配缺陷（在C++程序中这是有问题的）中解放出来了。其它类型的安全性包括类型安全性（type safety，用于保证数据类型的兼容性）和模块安全性，它控制着软件扩展和组件合成的效果。
面向组件技术
上一页 1 2
组件的下部构造
组件革命已经发展到组件下部构造的形式上了。主要的平台厂商都把自己的未来寄托在组件产品线上。特别地，微软、太阳微系统公司、IBM和CORBA社团都已经通过大量的技术和市场投资建立了重要的组件下部构造。
这些组件下部构造（微软的.Net和太阳微系统公司的Java Enterprise JavaBeans包含了CORBA）都是与行业中面向对象的企业应用程序开发部分竞争的主要的下部构造。有趣的是，这些技术通过共同支持的XML、Web服务和其它企业应用程序开发的标准把互相之间的交互操作进行了很大的扩充。
微软在当前的.Net产品套件中完全修复了自己的组件下部构造。微软.Net产品套件聚焦于企业级应用程序和分布式服务的开发和布署。尽管它混合了大量的新代码，但是它也包含了微软前期的分布式开发平台——微软分布式网络架构（DNA）和类似微软事务处理服务器（MTS）、微软SQL Server等分布式通用对象模型（DCOM）和长期存在的通用对象模型（COM）/COM＋——的很多成功的产品和技术。已有的.Net套件在集成的企业产品套件中更新了这些产品，增加了对XML数据、Web服务和大量改善的开发环境的新的支持。微软.Net是软件行业需要验证的有形证据，证明微软在可以预见的未来的正在形成的组件世界中将扮演主要角色。
太阳微系统公司发明的Java语言是编程语言特性、下部构造和相关的类库的持续的演化。Java语言技术引起了行业极大的骚动，并受到独立开发者的支持。Java-Beans 和Enterprise JavaBeans的扩展建立了一种进化的组件模型，它可以在跨平台的应用范围之中与COM和ActiveX竞争。Enterprise JavaBeans和IBM的San Francisco项目正在使用Java远程方法调用
（RMI）做分布式计算，它是Java语言程序员可以使用的几个专利下部构造之一。最近，Java语言已经在OMG的Internet内部ORB协议（Internet Inter ORB Protocol ，IIOP）之上包含了RMI，它允许Java与其它拥有CORBA IDL接口的编程语言中的分布式组件交互操作。尽管专利Java语言下部构造的确为程序员提供了便利，但是为了与其它编程语言之间交互操作，它们需要额外的复杂性，特别是在局部使用Java本地接口（JNI）调用Java之外的编程语言中的程序的情形中。这对于共同的项目有重大的障碍，因为它减慢了传统技术的集成和跨语言的开发，而这些对于服务器应用程序是很常见的。
在很多了解Internet的组织中Java应用程序服务器已经取代了CORBA的角色。CORBA缺乏的是对可伸缩性、可靠性和可维护性的直接的支持。现在这些能力都是大多数Java应用程序服务器支持的标准特征了。
组件的下部构造对于软件开发有重要的影响。在很多方面，这些下部构造正在向成为主流开发平台的方向前进。因为它们都变成了可以交互操作的（通过CORBA IIOP），下部构造模型之间的关系都很好理解了。它们的相似点远远大于它们的专利的差异。
下部构造的选择是讨论得最多的一个问题，但是对于组件的实现而言，其重要性却最低。对于共同开发者来说，最重要的问题会在选择下部构造之后遇到。这些问题包括如何掌握使用这种技术进行设计、如何架构系统、如何协调彼此之间的开发工作。
组件软件的设计模式
软件设计模式由能够应用于所有组件下部构造的软件知识的共同主体组成。软件设计模式是检验过的用于解决特定类别的结构上的软件问题的设计方法，它们已经备案以供其它开发者重复使用。其它重要的模式类别还包括分析模式和AntiPatterns。分析模式定义了对业务信息进行建模的检验过的方法，它可以直接应用于新软件系统和数据库的建模。
软件设计模式是组件的一个必要的元素。新的、可以重复使用的组件的开发要求的设计、规范和实现都有专家级的质量。经过检验的设计方案对于建立成功的应用程序系列的组件架构和框架是有必要的。通常，在没有检验过的设计观念中偶然性变数太多了。
软件设计模式的流行可以看作是对面向对象在实践中的缺点的反映。AntiPatterns解释了人们开发面向对象软件系统（以及其它类型的系统）的时候通常犯的错误。想要建立成功的系统不仅需要基础的面向对象的原理。设计模式解释了有效的软件设计所需要的额外的、改善的想法。分析模式提出了概念和数据的有效建模所必须包含的改善的想法。
在软件开发中彻底改造设计思想仍然是很普遍的，这导致了“试验－错误”实验法的风险和延迟。实际上，大多数软件方法鼓励彻底地改造，把它作为开发的一般模式。给定了需求的改变、技术革新和分布式计算的挑战压力之后，彻底改造对于很多环境都是不必要的风险。这种意见特别适用于组件的开发，在这种情形中缺陷和重新设计的代价可能影响多个系统。
总而言之，软件设计模式可以用知识的重复使用（knowledge reuse）来描述。有趣的是大多数模式都被认为像专家级开发者的常识一样简单。但是，对于大多数开发者来说，模式是技术训练中必要的部分，它可以帮助开发者获得世界级的结果。
组件软件的架构
软件的架构涉及到从早期的系统概念到开发和操作范围内的系统结构的计划和维护。好的架构是稳定的系统结构，它可以适应需求和技术的改变。好的架构确保了系统的生命周期中人们需求（例如质量）的持续的满意度。可以重复使用的组件是良好的架构的例子。它们支持稳定的接口规范，可以适应改变，是在很多系统环境中重复使用的结果。
软件架构在组件的设计、规范和使用中扮演着重要角色。软件的架构提供了组件设计和重复使用的设计环境。组件在软件架构的预定义方面扮演一定的角色。例如，组件框架就可能预定义了系统的某个重要部分的架构。
组件的软件架构的最令人兴奋的方面之一是支持分布式项目小组。软件的架构包含一个系统规范，它允许系统或系统的部分并行地、独立的开发。适当的软件架构定义了计算的边界（例如API），它把系统分成独立的可以测试的子系统。这些子系统可能被一个或多个分布式项目小组所采用。
技术所有权
1 2 下一页
由于对象技术是占有统治地位的商业范式，所以我们了解可用于软件系统架构的主要的商业技术是很重要的。其中主要的两类包括专利软件和开放系统软件。
专利软件
专利软件（Proprietary software）是单个厂商的非兼容标准的产品。该厂商控制了多个重复的产品版本中的软件的形式和功能。目前的系统在建立的时候，它们在很高程度上依赖于商业软件。商业软件是软件重复使用的主要的形式，并且实际上它是单个企业中的一种更加高效的重复使用的形式。
因经营规模的扩大而得到经济节约是商业软件成为更加强大的重复使用的形式的一个原因。软件的大量副本被分发给客户，并且软件的除错和质量控制的程度远远超过了即使最大的终端用户企业的内部开发能力。当终端用户企业依赖于专利软件的时候，他们都是依赖于该厂商对于已有能力的持续的支持，并且从结构上说，很多终端用户依赖的厂商主张的很多的未来特性都将被添加到软件中。当专利软件以公共规范或标准的形式包装的时候，该规范通常成为单个软件实现的直接表现。
通常，当专利规范进入到公共领域的时候，这种专利实现一般不会被改变。当实际上没有必要修改下层技术的时候，它留下的印象是专利软件也可能成为一种开放系统的标准。当成千上万的软件许可被分发并且在已有的软件系统上运行的时候，这种现象特别真实。当专利技术向前发展的时候，厂商使用软件概念的唯一的解释来描述它们的产品。这种解释可能包括对面向对象原则的基本原理的修改。
“我们规定建筑物的形状；从那以后建筑物就规定了我们的形式。”——Sir Winston Spencer
Churchill
专利技术的最重要的方面是应用程序接口（API）的规定。专利软件的API定义了某种专利实现与增值应用软件（可能是独立软件厂商或最终用户提供建立的系统）之间的边界。随着专利软件技术通过多种方式演化，应用程序编程接口也可能改变。
新的能力仍然在持续不断地添加到专利软件中，这加剧了应用程序编程接口的复杂性。在很多情形中，专利软件的编程接口的复杂性远远超过了最终用户组织需要的功能。接着最终用户组织试图用多种方式管理这种复杂性就变为合适的了。
作为给专利编程接口增加新能力的补充，厂商有时可能会废弃软件中的一些接口。这样做会对应用软件产生重大的维护方面的影响。随着专利软件通过多种方式的演化，持续地升级软件以保持与专利厂商提供的主流支持活动同步，这一点对于用户很重要。当最终用户的系统落后了两个以上周期的时候，通常必须重新购买或完全重新修复该商业软件，这样才能与当前版本同步。很多最终用户发现在产品版本的少数周期中应用程序接口几乎全部是废弃的。
总之，专利软件版本和编程接口的演化成为应用程序开发人员和独立的软件厂商为了保持与可以使用的和受到支持的软件同步的单调的工作。这是应用程序用户和专利软件厂商之间的冲突，因为厂商利润的大部分可能由软件升级包的销售来驱动。
技术所有权
上一页 1 2
开放系统软件
另一类主要的商业软件是开放系统技术（图1）。从本质上说开放系统技术与专利技术是不同的。在开放系统技术中，多个厂商达成一致的规范，而这种规范不依赖于专利实现。这就是大多数正式的标准活动和多数社团标准活动的情形，它正在变得更加流行。在开放系统技术中，各种规范都支配着实现的行为。
图1.专利技术(a)和开放系统技术 (b)
它的关键的好处是多个厂商的实现接口的一致性。其它的优点还有术语和软件接口的一致，这是因为开放系统技术要求多个厂商达成一致。另一个优点是技术规范水平的增强和生命周期的延长。由于产品的开发是通过多个厂商组织并行进行的，引发市场需求的相应市场活动也是同步的和协调的。开放系统技术关键的优点之一是它提供了商业软件厂商之间的互通性。开放式系统和专利技术之间的差异对于面向对象的系统尤其明显，而它正在成为应用程序开发的主流，因为