[软件架构训练基础教程-3]面向组件技术

　　在上篇文章中，我们介绍了《面向对象的软件技术》，面向对象技术催生了组件技术，组件技术为软件开发提供了改良的方法，它向过时的设想提出了挑战。这些原理共同建立了一种主要的新的技术趋势。组件表现为技术变革的基础，就像面向对象先前表现出的一样。我们在简短地介绍组件的独特原理后再讨论组件技术。

　　迁移到下一个层次的软件技巧要求系统思想、软件处理和技术工具的基本原理都有所改变。下一个主要的技术范围——组件（或面向组件）包含了解决目前危急的软件问题的关键的原理。
　　
　　组件的方法引入了一套紧密相关的技巧和工艺。组件技术引入了用于生成业务结果的一套改进的想法。为了产生业务效果，组件引入了一个技巧性的想法。这些组件原理包括：

　　组件的下层构造
　　软件模式
　　软件架构
　　基于组件的开发

　　组件与对象的对比

　　组件可以被认为是面向对象和其它软件技术的化身。区分组件和其它先前的技术有四个原则：封装（encapsulation）、多态性（polymorphism）、后期连接（late binding）和安全性（safety）。这个列表与面向对象是重复的，除了它删除了继承（inheritance）这个重点。在组件思想中，继承是紧密耦合的、白盒（white-box）关系，它对于大多数形式的包装和重复使用都是不适合的。作为代替，组件通过调用其它的对象和组件重复使用功能，代替了从它们那儿继承。在组件术语中，这些调用叫做委托（delegations）。

　　 “把各部分装配在一起，一个放在另一个里面，像木匠修建房屋一样建立你自己的轮廓。每样东西都必须建造好，各部分组合在一起就形成了全部…”——Henri Matisse

　　根据惯例，所有组件都拥有与它们的实现对应的规范。这种规范定义了组件的封装（例如它为其它组件提供的公共接口）。组件规范的重复使用是多态性的一种形式，它受到高度鼓励。理想情形是，组件规范是本地的或全局的标准，它在系统、企业或行业中被广泛地重复使用。

　　组件利用合成（composition）来建立系统。在合成中，两个或多个组件集成到一起以建立一个更大的实体，而它可能是一个新组件、组件框架或整个系统。合成是组件的集成。结合的组件从要素组件中得到了联合的规范。

　　如果组件符合了客户端调用和服务的规范，那么它们不需要额外编写代码就能够实现交互操作（interoperate）。这一般被称为即插即用（plug-and-play）集成。在运行时间执行的时候，这是后期连接的一种形似。例如，某个客户端组件可以通过在线目录发现组件服务器（类似CORBA Trader服务）。组件符合客户端和服务接口规范后，就能够建立彼此之间的运行时绑定，并通过组件的下部构造无缝地交互作用。

　　在完美的情形中，所有组件都将完全符合它们的规范，并且从所有的缺陷中解放了出来。组件的成功的运行和交互操作依赖于很多内部和外部因素。安全性（Safety）属性可能是有用的，因为它可以最小化某个组件环境中的全部类的缺陷。随着社会日益依赖于软件技术，安全性已经成为一种重要的法定利害关系，并成为计算机科学研究中的最重要的课题之一。例如，Java的垃圾收集（garbage collection）特性保证了内存的安全性，或者说从内存分配缺陷（在C++程序中这是有问题的）中解放出来了。其它类型的安全性包括类型安全性（type safety，用于保证数据类型的兼容性）和模块安全性，它控制着软件扩展和组件合成的效果。


　　组件的下部构造

　　组件革命已经发展到组件下部构造的形式上了。主要的平台厂商都把自己的未来寄托在组件产品线上。特别地，微软、太阳微系统公司、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），它把系统分成独立的可以测试的子系统。这些子系统可能被一个或多个分布式项目小组所采用。