|
|
|
本文是软件架构的基础训练，它介绍了有效的软件架构所需要的基本工具。在军事中，基础训练用于挑战和激发军官学校学生，并示范军事生涯的要求和奖赏。同样地，软件架构必须由个人来推动，这些人必须渴望对抗软件开发工作中的技术领先阶层的挑战。但是，这样的动机还是不够的。软件架构必须等同于认识架构全景的智力手段。
本文提供了一条便利的方法，它不仅显示了行业中最好的架构经验，还提供了具体的现实例子和练习，以便把它提供的素材应用于整个软件行业的普通环境中。基本训练覆盖了软件技术的基本概念，它提供了软件架构的基础。软件技术已经向软件开发的很多趋势和可选的方法不断演化。目前，主流的软件实践从面向过程演化到面向对象，然后又演化到面向组件的开发（图1）。随着企业级Java和微软.Net不断采用，面向组件将成为下一个主要的范式。在共同开发中，大多数新开始的项目都采用了面向组件技术，因为它受到了多数商业开发环境的支持。本文的前面提到，面向对象的软件架构观念非常薄弱，这导致了一些严重的缺陷。正在形成中的面向组件的趋势正在利用架构设计的强大原理代替旧的方法。
软件架构必须能够清晰地描述这些开发范式，同时允许技术适当地使用。在任何给定的项目中，折衷的混合的开发范式（包括关系数据库管理）对于获得最佳结果都是有用的。每个技术都提供了一些优点，包括成熟的开发工具。
目前大多数组织会发现它们的技术技巧基于正在使用的三种主要的技术之一：面向过程的、面向对象的或面向组件的。每个范式对于某个组织和它全部职员的技能都是非常明确的。面向过程和面向对象的范式都被编程语言的选择紧紧地约束了，但是面向组件就不同了，它与下层构造的选择的关系更加紧密。
面向过程的编程语言包括FORTRAN、COBOL、C、Pascal和BASIC。在面向过程的技术中，程序由执行不同算法的过程组成。过程与系统中的数据是分离的，而且过程通过直接访问操作（access operations）使用数据。这是存储过程编程系统的直接后果，而计算机技术就源于此。当程序和数据分离时，在程序的各部分之间存在很多潜在的内部依赖性。如果数据表现被改变了，程序的多个位置都可能受到冲击。
数据－过程分离的一个例子是2000年问题，在这个例子中简单地给日期表现添加一些数字会对面向过程的软件产生灾难性的后果。不幸的是，因为主流的系统都是使用面向过程的技术建立的，对这些数据表现的依赖可能会引起系统范围的程序错误，并引起了逐行检查、修改程序的必要性。
| |
|
|
|
|
面向对象编程语言包括Smalltalk、 C++、 Java编程语言和C#（微软.Net开发环境中提供的一种语言）。这些语言按照抽象数据类型（通常称为类）的要求支持数据和操作代码的封装。在面向对象编程语言中，封装能力对于适度大小的程序是足够的。只要软件模块由单独的程序员维护，封装对于提供一些内在的优点就是完全足够的。但是，特定语言的封装不足以支持软件的重复使用和分布式系统。
在面向对象技术中，基本范例被改变为允许关系的分离。图1显示了面向对象技术的范式，在它里面程序被分成叫做对象（object）的更小的片段。每个对象都包含了系统的一些数据，并且程序封装了这些数据。换句话说，只有通过使用与该数据直接相关的程序才能访问这些数据。通过这种方法，系统被分离成独立改变的模块。数据表现的任何改变仅仅影响封装该数据的直接的对象。
对象使用消息彼此通讯。消息可能影响状态——换句话说就是改变数据——但是只能通过与本地数据密切相关的封装了的过程来改变它。对于小程序，对象范式对于隔离改变来说是有效的。但是，这个范式对于所有可能的使用情形来说并不是完美的。
现在面向对象技术已经被广泛地使用了。一般来说程序上的技术来自于学术界，但是面向对象技术事实上来自于商业组织。实际上面向对象技术有很多有趣的渊源，甚至于可以追溯到计算机科学的开端。现在对象技术是占有统治地位的商业软件范式。事实上每个软件生产商都提供了对象技术的解决方案，并一起提供了组件的下部构造，允许不同软件环境中的软件厂商之间交互操作。
面向对象的架构
对于主要的软件开发从业者来说，面向对象是缺乏软件架构方法的。在面向对象的方法和文化中，这种缺乏在很多方面都有表现。从通常被当作原始来源的OO（面向对象）思考、设计面向对象软件【Wirfs-Brock 1990】开始，已经有了软件架构的概念，包括通过观察协作图（collaboration diagram，它需要一个章节才能讲清楚）发现子系统（subsystem）。在接下来的十年中，在面向对象方法学社团中几乎没有写出什么有关架构的东西。主要的OO方法学的书本中关于架构的章节都很少，它们都是Wirfs-Brock的架构概念的一些模糊的反映。
由于实际上几乎没有关于架构的专著，大多数OO从业者都只有最基础的架构指导。他们没有理由认为架构很重要。这种态度导致OO项目中很大的混乱，因为小组成员必须尽全力去管理那些并非为他们设计的OO方法的复杂性和可伸缩性。
一般而言，OO方法包含了成功的对象模型技巧，在这些模型中大多数分解对象最终被转换为编程对象。这种方法叫做基于模型（model-based）的方法。为了了解架构，认为每个分解对象都不可避免地成为编程对象是所有OO开发人员都需要克服的一个主要障碍。在架构模型中，特定对象表现约束而不是编程对象。它们可能会，也可能不会被转换成编程对象，这是由开发人员的自行的决定。
OO也在其它一些微小的地方与架构矛盾，这与项目文化相关。OO鼓励项目小组平等，这样所有的决定都是民主的。在这样的项目中就没有架构的角了，因为在开发小组的成员之间作出的决定的差别是很小的。
OO鼓励开发中的“bad-is-better”思考方式，实际上这是一种与架构思想背离的哲学。使用bad-is-better思想的时候，任务实现的外部表现远远超过了可以维护的的内部结构的任何需求。换句话说，快速迭代的原型处理，以及对架构原理的无情的漠视对于OO开发来说是一种正常的、健康的环境。
架构的话题只在最近的OO专著中与新发现的组件技术一起被重新提到的。现在大多数方法学的书本都习惯性地包含一个关于架构的象征性的章节，但是在OO的全盛时期，架构实际上是禁止使用的。从感觉上讲，组件是OO的缺点的反映。组件的强调较大“颗粒”的软件接口和模块，是向架构想法方向的改进步骤。
数据库和对象
数据库技术也朝对象的方向演化。数据库技术源于几个不同的模型。近些年，数据库的关系模型是最有影响力的。到最近，面向对象的数据库已经成为重要的技术市场，而联合了面向对象和关系概念的数据库也很平常。大多数主要的行业数据库，例如Oracle 9i和IBM的DB2数据库都包含了对象－关系能力。
数据库查询语言，例如结构化查询语言（SQL），都在标准的工作方面进行了扩展以支持面向对象的概念。发生这种情况的原因之一是人们正在建立的这类应用程序需要充分的、更多的适合显示需要的数据表现类型和查询算法类型以搜索和维护信息。
对象在主流技术中的地位
目前对象技术应用于大多数应用程序范围和垂直的市场中。政府组织和工商企业正在用对象技术运作大量的项目。对象技术的主要优点是它允许为组织提供竞争优势的新业务流程的实现。社会正在朝不断依赖信息技术的方向转变。对象技术的使用通过软件重复使用机制允许快速的系统实现和各种形式的劳动力的节省。尽管大量的软件代码仍然存在于面向过程的语言（例如COBOL）中，但是很清楚这种范式正在改变。
脚本语言
脚本语言的支持者声称使用脚本语言的编程人数比使用其它类型语言的编程人数都要多【Ousterhout 1998】。脚本语言，例如JavaScript语言、TCL shell编程语言和Visual Basic语序可以把先前存在的软件（例如组件）轻易地集成到应用程序构造中去。 | |
|
|
|
|
在上篇文章中，我们介绍了《面向对象的软件技术》，面向对象技术催生了组件技术，组件技术为软件开发提供了改良的方法，它向过时的设想提出了挑战。这些原理共同建立了一种主要的新的技术趋势。组件表现为技术变革的基础，就像面向对象先前表现出的一样。我们在简短地介绍组件的独特原理后再讨论组件技术。
迁移到下一个层次的软件技巧要求系统思想、软件处理和技术工具的基本原理都有所改变。下一个主要的技术范围——组件（或面向组件）包含了解决目前危急的软件问题的关键的原理。
组件的方法引入了一套紧密相关的技巧和工艺。组件技术引入了用于生成业务结果的一套改进的想法。为了产生业务效果，组件引入了一个技巧性的想法。这些组件原理包括：
组件的下层构造
软件模式
软件架构
基于组件的开发
组件与对象的对比
组件可以被认为是面向对象和其它软件技术的化身。区分组件和其它先前的技术有四个原则：封装（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），它把系统分成独立的可以测试的子系统。这些子系统可能被一个或多个分布式项目小组所采用。
| |
|
|
|
|
由于对象技术是占有统治地位的商业范式，所以我们了解可用于软件系统架构的主要的商业技术是很重要的。其中主要的两类包括专利软件和开放系统软件。
专利软件
专利软件（Proprietary software）是单个厂商的非兼容标准的产品。该厂商控制了多个重复的产品版本中的软件的形式和功能。目前的系统在建立的时候，它们在很高程度上依赖于商业软件。商业软件是软件重复使用的主要的形式，并且实际上它是单个企业中的一种更加高效的重复使用的形式。
因经营规模的扩大而得到经济节约是商业软件成为更加强大的重复使用的形式的一个原因。软件的大量副本被分发给客户，并且软件的除错和质量控制的程度远远超过了即使最大的终端用户企业的内部开发能力。当终端用户企业依赖于专利软件的时候，他们都是依赖于该厂商对于已有能力的持续的支持，并且从结构上说，很多终端用户依赖的厂商主张的很多的未来特性都将被添加到软件中。当专利软件以公共规范或标准的形式包装的时候，该规范通常成为单个软件实现的直接表现。
通常，当专利规范进入到公共领域的时候，这种专利实现一般不会被改变。当实际上没有必要修改下层技术的时候，它留下的印象是专利软件也可能成为一种开放系统的标准。当成千上万的软件许可被分发并且在已有的软件系统上运行的时候，这种现象特别真实。当专利技术向前发展的时候，厂商使用软件概念的唯一的解释来描述它们的产品。这种解释可能包括对面向对象原则的基本原理的修改。
“我们规定建筑物的形状；从那以后建筑物就规定了我们的形式。”——Sir Winston Spencer Churchill
专利技术的最重要的方面是应用程序接口（API）的规定。专利软件的API定义了某种专利实现与增值应用软件（可能是独立软件厂商或最终用户提供建立的系统）之间的边界。随着专利软件技术通过多种方式演化，应用程序编程接口也可能改变。
新的能力仍然在持续不断地添加到专利软件中，这加剧了应用程序编程接口的复杂性。在很多情形中，专利软件的编程接口的复杂性远远超过了最终用户组织需要的功能。接着最终用户组织试图用多种方式管理这种复杂性就变为合适的了。
作为给专利编程接口增加新能力的补充，厂商有时可能会废弃软件中的一些接口。这样做会对应用软件产生重大的维护方面的影响。随着专利软件通过多种方式的演化，持续地升级软件以保持与专利厂商提供的主流支持活动同步，这一点对于用户很重要。当最终用户的系统落后了两个以上周期的时候，通常必须重新购买或完全重新修复该商业软件，这样才能与当前版本同步。很多最终用户发现在产品版本的少数周期中应用程序接口几乎全部是废弃的。
总之，专利软件版本和编程接口的演化成为应用程序开发人员和独立的软件厂商为了保持与可以使用的和受到支持的软件同步的单调的工作。这是应用程序用户和专利软件厂商之间的冲突，因为厂商利润的大部分可能由软件升级包的销售来驱动。 | |
|
|
|
|
开放系统软件
另一类主要的商业软件是开放系统技术（图1）。从本质上说开放系统技术与专利技术是不同的。在开放系统技术中，多个厂商达成一致的规范，而这种规范不依赖于专利实现。这就是大多数正式的标准活动和多数社团标准活动的情形，它正在变得更加流行。在开放系统技术中，各种规范都支配着实现的行为。
它的关键的好处是多个厂商的实现接口的一致性。其它的优点还有术语和软件接口的一致，这是因为开放系统技术要求多个厂商达成一致。另一个优点是技术规范水平的增强和生命周期的延长。由于产品的开发是通过多个厂商组织并行进行的，引发市场需求的相应市场活动也是同步的和协调的。开放系统技术关键的优点之一是它提供了商业软件厂商之间的互通性。开放式系统和专利技术之间的差异对于面向对象的系统尤其明显，而它正在成为应用程序开发的主流，因为对象技术已经成为商业技术的主流。
商业信息技术一直在演化。日益满足应用程序需求的额外能力正在添加进来，并且通过商业技术逐渐可以使用了。但是在基础能力的商业技术（例如操作系统和编程语言）方面仍然需要大量的彻底的改造。
在有些商业技术（例如办公自动化、字处理和电子表格）中，很多功能被持续不断地重新组织并提供给最终用户，却没有显著的性能扩充。在很多人看来，商业端的技术演化的速度相对于竞争性的应用程序开发者的需求的增长较慢。商业技术的发布是为了满足大量用户的需求。这种软件的一般性超越了任何个别应用程序用户的需求。为了改变商业技术以满足应用程序的需求，就需要软件的配置和安装，它定制商业软件以适合特定应用程序的需要（图2）。
定制商业技术的需求通常称为profiling。作为定制软件的补充，我们需要用牢固的特定应用软件来建立应用系统。因为对于多数应用需求来说，商业上可以使用的能力相对原始，所以这种需求驱动着一种不断增长的需求——建立越来越多的特定应用软件来完善应用系统的架构。随着系统从单用户演化到部门级再演化到企业级应用程序，其互通性也更强，可供使用的商业软和单独的用户软件之间的功能差异还会不断增加。
应用软件系统的架构在系统如何支持用户需求方面显得日益重要。电信行业之外的多数系统都是使用面向过程或其它的范式集成的，而这样做通常会造成无效的解决方案。实际上，对于共同开发组织建立的系统来说，大多数软件项目在完成时就被认为是失败的。从架构的观点来看，其中很多系统都类似于图3（a）中stovepipe系统中的构造。在stovepipe系统中有大量集成的软件模块，每个软件模块都有独特的软件接口，这些独特的软件接口分别与一种程序的实现相对应。
图3. Stovepipe系统（a）和组件架构（b）
| |
系统集成的时候，它的不同部分之间存在很多一对一的依赖关系。这些依赖关系都是独特的集成方案。伴随着系统的大小随着模块数量不断增长，依赖关系的数量按模块数量的平方增长。这样的复杂性的增加带来了很多负面效果。特别是，随着系统的演化，修改和扩展变得越来越困难了。系统扩展恰恰是应用程序开发中的主要的成本驱动因素；它大约占了所有软件成本的一半【Horowitz 1993】。
建立系统的可选的方法之一是包含计划好的软件接口的定义，由它提供跨越集成方案的更高层次的一致性。组件架构是一种使用了一致的应用程序编程接口、跨越多个软件子系统实例所定义的应用系统（图4）。组件架构减少了软件模块之间的依赖关系，而依赖关系的减少使系统可以扩展，并且支持更大规模的集成。适当地建立的组件系统的软件集成的复杂性依赖于建立该系统所需要的软件模块的数量。
| |
|
|
|
|
在前一节中我们介绍了用于软件系统结构的主要的商业技术：专利软件和开放系统软件。本节我将向大家介绍客户/服务器技术
客户端-服务器技术是支持应用系统的软件技术演化的结果。特别地，客户端-服务器技术的演化已经成为信息技术扩展的一个重要因素，它伴随着应用程序业务流程的范围的不断增长。最初的技术集中于文件共享。文件共享目前仍然是Internet中占有统治地位的范式，它使用HTTP等协议支持可用的全球文件系统的访问。文件服务器技术演化为数据库服务器技术，形成了第二代占有统治地位的能力。我们要重点注意，文件服务器技术与分布式计算技术的演化紧密相关。
最近客户端-服务器技术正在逐渐被N层面向对象解决方案所代替。基于Java应用程序服务器，N层解决方案包含了对瘦客户端用户界面的支持，同时增强了可伸缩性和可靠性。
最成功的网络技术之一来自于太阳微系统公司，称为网络文件服务器。太阳微系统公司通过提供在任意平台上的实现源代码的免费参考技术访问权成功地成为了实际的标准。网络文件服务器技术是基于开放式网络计算的，这是太阳微系统公司的另一项技术，它是第一代成功的分布式计算机技术之一。网络文件服务器是基于面向过程的技术，受到C编程语言的约束，就像其它的重要的远程过程调用技术（分布式计算环境）一样。这两种技术都导致了文件共享能力被广泛地实现了。数据库服务器技术利用这些下层的分布式计算能力来提供不同的客户端平台对数据库系统的远程访问。
在数据库时代产生过程中另一项重要的技术是事务处理监视器。事务处理监视器使我们能够通过分布式系统实现一致的和可靠的数据完整性维护。事务处理监视器技术成为分布式技术的一种重要的附加能力，确保了执行的性能和完整性。
件（Groupware）技术也出现在80年代末90年代初，它是从开始的，演化成更高形式的交互能力，其中的一些目前还能在Internet上看到（例如聊天室和视频会议）。最近，面向对象、分布式计算和Internet技术已经结合在一起以支持自适应的计算环境，其范围可以扩展到了全部的计算机。这一代技术主要受到基于太阳微系统公司的Java和微软的.Net平台的应用程序服务器的支持。
客户端-服务器技术最初是由基于主机的技术演化而来的。基于主机的技术是单处理器系统的自然而然的产物，可以追溯到计算的起源。在主机技术中，系统中的数据的处理和管理都是集中完成的。主机被很多外围客户终端围绕着，而这些终端仅仅简单地支持信息的表现。在客户端-服务器技术时代，客户端计算机成为了重要的处理资源。在个人计算机革命中客户端系统的处理速度不断上升，现在其处理速度可以与以前的小型机和大型机竞争了，甚至于超越了它们。最初为了支持部门和企业的数据访问，客户端-服务器技术支持了通过局域网连接到后端大型机、小型机和工作站服务器系统。在软件层中支持这种通讯的技术称为中间件（middleware）。
"天赋可能就是用简单的方式表达深刻的事情。"--Charles Bukowski
历史
最初，中间件是作为支持PC和服务器平台之间的客户端-服务器网络通讯的常规能力安装。随着技术的发展，中间件被逐渐嵌入操作系统中，这样它就变成了客户端平台和服务器平台的一种普通的能力。嵌有中间件的客户端系统现在支持对本地和通过网络运行的应用程序的服务。客户端-服务器技术向嵌入能力的演化给应用系统的执行增加了少量的挑战。实际上，目前客户端-服务器的演化有多种不同的情形，包括大型机平台的复苏（成为了IBM的重要业务），以及称为网络计算机的能力开始类似大型机时代的哑终端了（图5）。
对象技术是围绕客户端-服务器能力组织起来的。对象技术分成了主要的两类。其中一些被组织起来用于为软件开发的过程服务。这种技术的例子包括面向对象的分析和面向对象的设计。面向对象的分析由当前和未来的业务流程的模型的信息技术能力的定义所组成。面向对象建模为业务实体和业务流程的表现提供了丰富的能力。这与面向过程和关系数据库技术不同，它们要求应用程序设计者把业务环境的表现按照控制流和数据表现的技术约束进行折衷。由于过程中状态信息的简单自然的通信，面向对象分析提供了模拟现实的机制，而它相对容易与最终用户沟通。由于与最终用户的沟通更容易了，面向对象系统的设计和确认就更容易实现了。
面向对象设计是另一种主要的软件阶段，它已经被软件程序市场成功地商业化了。面向对象的设计由支持软件缺陷的减少和软件能力的快速原型方法的软件结构规划和能力共同组成。
对象技术的其它的主要种类集中在实现上。在它的中心是面向对象中间件技术。面向对象中间件支持分布式计算和多种不同的软件技术（包括操作系统、编程语言和数据库）的集成。面向对象的编程语言是对象范式的直接表达。面向对象的编程语言支持数据和过程的封装，采用组件对象中的抽象数据类型的形式。现在有多种面向对象的编程语言，就像有很多面向过程的编程语言一样。占有支配地位的面向对象的编程语言包括C++、Java语言和C#，但是还有大量的团体支持Eiffel和其它语言。面向对象的中间件允许这些语言交互操作来构成应用程序。面向对象的编程语言是实现应用软件的一种可能的选择。我们也可能利用面向对象的分析和设计来支持在面向过程语言的编程。这种情形经常发生，因为很多团体的开发环境都把面向过程的语言（例如C编程语言和COBOL）作为自己的主流语言。
面向对象的一个最重要的特性是开发者不需要关心下层的实现。如果下层的实现是面向过程或面向对象的，只要应用程序被正确地封装了，都没有任何问题。分布式对象中间件支持不透明的封装属性，使这种操作成为可能。商业软件与传统的和面向对象的应用程序的集成也被这些封装属性的结果所激活（图6）。
面向对象的中间件技术可以被看作是面向过程开发的副产品。从操作系统开始，支持进程间通讯的面向过程的技术就已经被添加进来以激活文件共享和客户端-服务器能力的演化（图7）。这些技术包括远程过程调用（RPC）技术（例如开放式网络计算，ONC）和分布式计算环境（Distributed Computing Environment ，DCE）。RPC技术领先于套接字层的技术，而该技术是传递消息的一种更简单的方式。目前，所有这些技术仍然在应用系统中和Internet上被活跃地使用着。面向对象的中间件技术提供了下一代的能力，它把更多的应用程序功能打包到下部构造之中了。
| |
|
|
|
|
分布式组件
我们注意到了一些有趣的东西：前一代的进程间通讯技术在市场上销售的时候都承诺了全部应用程序的互通性。目前面向组件的技术也采用了相同的方式。分布式的面向对象的中间件拥有克服前一代技术的缺陷的优点。我们发现即使远程过程调用技术激活了分布式软件的集成，但是为了认识系统，这些技术的原始层次还是要求牢固的应用程序设计。否则，一旦实现这些系统，它们往往相当地脆弱，并且难于维护。
1996年微软发布DCOM，把它作为在Internet上使用的多媒体中间件技术。DCOM仍然暴露了很多更低层次的原始的细节信息，它意味着远程过程调用的衰落。DCOM添加了一些面向对象的能力和支持C++编程的普通集成。简单地添加支持C++的能力不一定能够克服DCOM的前任（叫做分布式计算环境）中的面向过程的程序给分布式系统开发者暴露了过多的复杂性这个缺陷。但是，有了当前版本的产品--微软.Net后，微软建立一种企业开发环境，它能够顺利地与更加成熟的J2EE应用程序服务器竞争了。
通用对象请求代理架构（Common Object Request Broker Architecture）是从下向上设计的用于支持分布式面向对象计算的第一种技术。图8显示了在技术市场上，微软的技术基础与所有其它厂商的信息技术实际上是隔离的。其它厂商支持多种开放系统技术，它是大家一致同意的标准步骤的结果。CORBA是被广泛接受了，它是不受厂商约束的分布式对象中间件的标准。CORBA在很多方面都简化了分布式计算。其中最重要的进步是CORBA提供了语言的无关性，允许不同环境中的多种编程语言使用对象消息交互操作。
在中间件层之上还有一些其它的技术，它们支持了应用程序功能的进一步集成。在微软技术基础中，这些技术都被归组为一个品牌名称--.Net。.Net技术包含了对中间件能力的彻底改造，它删除了接口定义语言。目前CORBA能力已经广泛地使用了，并且它支持来自多个厂商平台的多种编程语言的集成。
CORBA技术是一家开放系统联盟（叫对象管理工作组，OMG）的产品。OMG拥有大约700个成员组织，包含了所有主要的信息技术厂商，例如太阳微系统公司、惠普、IBM、网景和微软。OMG通过把焦点聚集在编程接口的标准化上解决了应用软件互通性的问题。有了上一代远程调用技术后，唯一被广泛采用的标准接口是网络文件服务器，它是移动媒介交换之上的最原始的软件互通性形式。最终用户提供自己的需求并与开放系统程序交互是很重要的，因为它们决定了最终用户系统的开发将使用的技术的形式。特别地，富有经验的技术用户可以鼓励开放系统社团和软件厂商提供更加完整的能力以开发复杂系统。这将减少技术风险并为应用程序开发者创造更多的方法。
CORBA技术围绕组件标准化了的对象请求调用（图9）。在对象管理架构（它是OMG范式的路线节点）中有几种类型的对象。对象请求代理是很重要的，因为所有其它类型的对象都要通过它来通讯。对象管理架构是一种概念上的分层的架构，它包含的域应用程序（domain application）实现的特征的水平正在不断地增长。对象技术包含的大多数通用的能力都通过对象请求代理被标准化了。下一层次的能力被称为CORBA服务，它为系统的实现提供启用功能。CORBA服务的功能比得上当前操作系统的服务，而操作系统的服务一般却被捆绑在平台上。CORBA服务迈出了分布式操作能力（它支持应用软件和业务软件跨平台、跨环境的集成）向前的第一步。
目前CORBA技术已经可以广泛地使用了，而且事实上它是每种操作系统平台上都可以使用的主流技术。某些更加创新的平台，包括Netscape Communicator（客观的说，它可以被看作是一种操作系统平台），都集成了CORBA和所有的可交付使用的许可。微软也通过发布规范（使它与微软下部构造工作可以交互作用）支持CORBA技术市场。OMG为COM和COM＋代的微软技术制定了交互作用规范。这些标准在目前主要的CORBA执行系统上的产品中都是可以使用的。
此外，第三方厂商也提供了对CORBA的直接支持。这些厂商包括Black and White software（它提供图形化用户界面工具包）、数据库厂商、系统管理厂商和专业市场厂商（例如实时和计算机辅助软件工程工具）。CORBA提供了接口定义语言（IDL），它是面向对象的关键的基本能力。接口定义语言是定义软件边界的符号。IDL是一种规范语言，它允许我们描述应用系统的计算机软件架构，并包含了供交互操作能力的国际标准。
CORBA的接口定义语言已经被国际标准化组织采用了，并作为电信系统的正式的标准副本。IDL是国际标准DIS14750。同样地，IDL是软件架构中定义应用程序编程接口的通用符号。因为IDL是独立于编程语言的，单一规范对于定义任何语言或平台环境上的软件接口都是足够的。IDL接口支持面向对象的设计和传统软件的集成。由于对象管理工作组是开发软件接口的面向对象的标准规范的唯一的权威社团，IDL与对象技术开放系统是同义的。
IDL支持支持多种编程语言和计算平台不同组合的集成（图10）。有了IDL，任何人都可以指定软件接口，它很容易编译并集成到可用的编程语言中。这些能力在商业中也是可以使用的，并且一般支持分布式的通讯。
这一部分讨论了主流技术是如何演化为客户端-服务器技术、以及中间件是如何提供分布式计算软件能力的。由于客户端-服务器技术与对象技术已经结合在一起了，现在可以提供面向对象的能力，它可以使传统系统跨越所有的编程环境。此外，CORBA和微软的COM＋之间的互通性覆盖了很多组织的流行的桌面平台。支持开放式系统的厂商也支持CORBA。占统治地位的Internet厂商都在交付CORBA，并把协议堆栈与众多获许可的人相关联。CORBA是面向对象中间件的标准。其产品现在可以使用了，它作为让应用程序开发能够进行的水平的（horizontal）服务规范。OMG正在开发垂直的规范，它将为应用程序级的互通性提供直接的支持。
ISO已经把CORBA IDL名称作为跨越多种平台的软件接口定义的标准。
面向对象是现实世界的信息和业务流程建模的普通的范式。对象技术支持不同种类的和分布式的信息技术（包括传统系统）的集成（图11）。把面向对象和组件技术结合在一起就能进行大型系统概念的创建，而它正在变成应用程序公司和终端用户的竞争优势。
| |
|
|
|
|
上一节中我介绍了客户/服务器技术的发展演化，互联网的发展对技术提出了更高的要求，传统的html标记语言逐渐不能满足企业大规模运算的需要，可扩展标记语言(XML)逐渐成为业界的标准。
在主流新闻中很少技术引起可扩展标记语言那么大混乱。尽管XML是一种基础的、可以利用的技术，但是其趋势却是与其它的技术方案一起组合使用，并且弄不清XML与其它技术（通常是专利方案）的能力差异。下面将要讨论的是关于XML是什么以及为什么预计它会有很长的技术生命周期的等核心内容。
可扩展标记语言（XML）
创造XML的目的是终结特定应用的程序数据的交换问题。XML不是让两个或多个应用程序来决定它们之间使用什么样的格式来进行数据交换、在每个应用程序中使用什么样的代码逻辑按约定的格式读取和写入数据，而是提供与应用程序无关的方式描述数据的方法。XML使用标记（tags）来包含应用程序的数据并描述数据的信息。XML是一种环球网联盟的标准，并且被其它的大量标准使用。
XML的一个优点是它解决了先前的开发中的一个实际问题：为每个与数据集交互操作的应用程序编写导入和导出程序是昂贵的和脆弱的。每次数据改变的时候，必须修改与该数据交互操作的每个应用程序以了解新的数据格式，即使那种改变对于不同的应用程序使用的数据元素几乎没有影响。在没有确保所有的应用程序都升级到可以处理某种变化的之前，应用程序不能够扩展已有的数据格式。从本质上说，数据的设计与负责读取和写入数据的应用程序是紧密关联的。这给共享数据的所有应用程序（趋向于包含多数环境中的很多应用程序）增加了很大的成本。XML提供的不依赖于使用数据的应用程序的数据建模的简单方式是革命性的。
XML最终还是一种数据格式。原始的XML 1.0规范十分简明，主要定义了使用标记来描述数据元素的方法。这些标记都是用户定义的，有下面一些特性：
结构化的（Structured）。XML使用标记来描述数据，使得数据文件可以自我描述（self-describing）。读取和处理XML文档的程序可以轻易地检测到某个文档是否包含特定的数据元素。同样，让程序检测某个XML文档是否被切断了或者格式不完整都很很容易的。
灵活的（Flexible）。对于任何数据集合，XML都提供了表现数据的几种方法。灵活性有利有弊：它允许开发者为如何表现某个XML文件中的数据进行恰当的选择；它也允许开发者作出数据表现的不恰当或不明智的选择。
验证的（Validated）。文档类型描述（Document Type Description，DTD）或XML大纲（Schema）让开发者能够定义指导数据表现的规则。XML分析器被广泛地用于根据大纲验证文档的正确性。
可适应的（Adaptable）。生成XML文件的应用程序、操作系统、编程语言和数据管理系统都可能改变，然而XML文件仍然是可以读取的。
标准的（Standard）。使用XML不需要许可，任何公司都不能改变它，使它与其它应用程序不兼容。
可读的（Readable）。XML文件可以被编辑、修改并保存为纯文本。
举个例子，建立一个描述冰淇淋口味的XML文档就十分简单，先决定要描述什么，接着记载特定的实例就行了。
为什么这种技术如此强大？与其它的数据格式不同，即使这么简单的XML文档在二十年、五十年甚至成百上千年之后都能够被理解。十年前使用的数据格式中只有很少的可以被当前的应用程序理解了。而且如果数据可以被理解，那么它就能够被利用/处理。此外，有了XML分析器和其它补充的技术，不同的XML格式（和其它格式）之间的转换处理工作可以自动化进行。
但是，这种灵活性也是有交换条件的。XML是一种描述数据的冗长的方法。在存储和传输同样的信息内容的时候，很少数据格式需要的空间有XML文档需要的大。其结果是，当性能和存储空间是约束条件的时候，其它的数据格式也是合乎需要的。当然，在目前硬件处理和传输速度快速发展的情形下，XML文件的大小通常仅仅是一种次要的考虑因素。在管理大量XML文档时会出现较大的问题。搜索大量的XML文档通常是有问题的。但是，XML文档索引系统、甚至于XML特定的硬件已经在帮助我们减轻搜索大量的XML文档所遇到的问题了。有些数据库厂商也正在自己的数据库中实现XML类型以处理存储和搜索的问题；例如，类似的增强功能在XML数据库产品Oracle 9i中是可以使用的。其它的大量公司也开发了XML特定的数据库，它们带有用于提高搜索性能和高效存储XML内容的一些定制的内容。最后，要清楚尽管我提到的很多XML的优点确实是可能的，但是它们中很少是自动的。XML本身的使用不是独立地完成大量的事务，而是需要很多的想法、计划和设计来把XML与其它技术一起高效率地使用。
Sun公司的J2EE与微软的.Net
首先，我介绍行业中最主要的两种企业开发平台（太阳微系统公司的Java 2企业版和微软的.Net）的基本信息。J2EE是以Java为中心的操作环境，它正在努力变成的平台无关的。这意味着J2EE开发者都在Java编程语言中工作；但是该语言本身对于所有主要的硬件环境和软件操作系统来说都是很轻便的。与此对照的是，微软的.Net环境支持多种编程语言，但是目前聚焦于运行在微软Windows操作系统上的开发环境。此外，J2EE根本上是一种由大量不同的厂商实现的一个规范集合。微软的.Net是作为基于微软的知识产权专利的一套产品销售的。策略上的基本差异造成了软件行业的很多有趣的分化。Sun和一些主要的玩家，例如IBM和Oracle投入和大量的资金，聚集了主要的厂商支持J2EE标准。它们中的大多数都把J2EE集成到自己的旗舰产品线中，并且很多厂商都有自己的J2EE实现。在另一个阵营，微软用.Net促进自己与已有的厂商关系，引起企业软件开发中支持.Net解决方案的厂商范围的快速增长。他们自动的把基本的.Net核心服务集合让给微软，并朝着从基于核心下部构造的增值软件中获利的方向来建立业务模型。
J2EE环境要求所有的组件都使用Java编程语言编写。Java虚拟机（JVM）把Java编写的程序编译为特定的Java字节码（byte code），JVM在运行时执行编译的字节码。这与.Net的方法显著不同，.Net使用通用语言运行时（CLR）引擎把大量的编程语言编译成真正的语言无关的中间代码。CLR允许开发者使用.Net开发工具支持的任何编程语言，并且定义了从其它任何受到支持的语言中轻易地调用某个语言编写的组件的机制。从某种意义上讲这允许多种编程语言开发，它在引入到.Net之前还没有被广泛地接受。审查委员会仍然没有考虑行业中到底多需要这种能力，但是重复使用大量的已有的代码而不管它的实现语言的呼吁的确出现了。
在完备性方面，J2EE环境有更长的历史，并且在它的开发和演化有更多的行业参与。J2EE已经被成地部署在大量的最有挑战意义的垂直行业（例如财政服务和通讯）的重要事务应用程序中了。而且，由于J2EE解决方案来自很多不同的厂商，在不同的实现、工具集和增值产品方面都有更大的多样性。不幸的是，作为应付大量的厂商解决方案的结果，我们必须小心处理产品的兼容性问题，这个问题在单个厂商的解决方案（例如.Net）中要少得多。
总之，J2EE为富有经验的开发小组提供了很多优点，因为J2EE提供了比.Net更大的编程灵活性，并且能够开发性能很好、高度定制的应用程序。但是，这种更高的灵活性在某些方面（例如内存和资源管理）也更容易引入严重的错误。最初在.Net中建立多层应用程序并运行要容易得多，但是J2EE赋予富有经验的开发者开发强大的应用程序的更大的自由性。.Net架构更多地聚焦于使用的简单，因此它提供的对更低层状态管理和频繁使用的缓冲技术的访问权并没有J2EE应用程序开发提供的那么大。
Web服务
XML是一种数据格式，它允许数据在不同的计算环境之间交换。Web服务是重要的，因为它们把Internet作为数据传输层来使用，允许我们共享分布式程序。通过使用Internet，这些程序对于潜在的数百万的用户都是普遍可用的，并且可以作为更大的分布式应用程序的构建模块。Web服务可以在任何计算平台上使用任何语言实现，接下来使用标准的Web服务描述语言（WSDL， Web服务专用的一种XML大纲）把该服务的接口记录在XML中。Web服务的客户端可以使用标准的简单对象访问协议（SOAP，它提供了表现Web服务的接口以及通过HTTP调用的XML格式）调用WSDL。由于HTTP是Internet的标准协议，Web服务可以在已有的Internet下部构造上配置和使用。Web服务提供程序也可以在普遍的描述、发现和集成（UDDI）登记中注册它们的Web服务，这样就能让客户端动态地搜索、发现和访问它们的Web服务了。
允许建立和使用Web服务的基本技术都符合行业标准，并且同时受到微软.Net和Sun的J2EE平台的支持。但是，与安全性和电子商务相关的增值服务都正在进行中。Web服务的潜能不可能被完全了解，直到这些关键的技术都达成一致并在整个行业中被广泛地采用。 | |
|
|
|
|
在上文中，我介绍了Internet技术，WEB服务在家够方面给了我们更多的选择，但软件设计中采用何种架构仍然是件令人头痛的事情。
两层系统（图12）允许用户界面和应用程序代码直接访问数据库和网络存储的API。应用程序使用数据库中存储的数据模型，但是不需要在该模型之上建立逻辑模型。当开发中的系统是一个原型系统或者已经知道其生命周期较短，期间API不会发生变化的时候，两层应用程序是理想的。典型情形下，这种方式用于小型的应用程序，它们的开发成本和时间都很少。
此外，两层系统对于面向组件的开发环境也有意义，这种方式用在特定组件的实现之中。组件接口提供了一个隔离层，与这种方式的后果相反。使用脚本语言建立的多数应用程序都属于这一类，因为这种情况下多架构层的开发可能非常麻烦，不切实际。
最后，两层的方式将提供更好的性能，并减少控制资源锁定的机制的需求。尽管两层模型在处理多个并发用户使用应用程序方面的能力有些欠缺，但是它的简单性可能远远优于其它的选择。此外，通过向数据库应用程序添加通用的数据处理程序，常常能用数据存储过程来消除一些简单的共享数据的问题。
随着数据库的发展，三层（Three-tier）应用程序已经很普通了。三层系统（图13）满足了执行的隔离的需求。它基本上对于存储/数据库层可能被修改的任何应用系统都是理想的。但是，这种技术的隔离并不仅限于数据库。它能够，并且应该用在任何不要求应用程序开发者，或更重要的应用程序维护人员对于最低层有详细的了解就能共享代码的环境。
相当频繁的重复使用是一个主要的设计考虑因素，在这种情形下需要建立应用程序模型以允许它的一部分被多个用户界面查看组件重复使用。它有一个指导方针是，在应用程序需要相同数据的多个视图的任何时候，开发者应该考虑使用三层方式代替两层方式。
从两层模型迁移到三层模型需要考虑的主要问题包括适当的网络资源的可用性和管理并发数据访问的加锁方案。
作为越来越强调网络计算的结果，最近出现了一种新的趋势，就是四层系统（图14）。当应用程序层需要支持高级行为的时候，可以考虑四层系统。四层模型与三层模型相似，但是其应用程序层被分解为表现层和对话层。表现层呈现了应用程序模型的视图部分，以及被特定视图的操作所约束的应用程序逻辑。对话层处理表现组件之间的资源共享的问题，包括与潜在的分布式业务对象模型通讯。
当表现组件之间需要大量的协调，并且需要在它们之间共享很多资源的时候就需要四层开发方式。例如，由于性能问题的缘故，缓冲是必要的。对话层允许很多不同的表现组件利用缓冲提供的性能优势。同样，如果某个客户端被迫作出多个、潜在的复杂的分布式结论，就可以考虑把这种逻辑封装到应用程序的一个对话层中。
很多因素表明考虑四层开发方式的需求为数众多。很明显，任何四层系统预期的生命周期很长。已有的组件和子系统的重复使用对于引发与四层系统相关的费用来说通常都是足够充分的理由。同样，预计个别组件会频繁改变设计的目标的环境需要把系统的主要部分与组件实现中的变化隔离开来。四层方式提供了对随技术的发展（包括传统的和新的技术）组件和子系统不断地移植的支持。此外，四层系统比三层系统更容易升级。
其它一些考虑因素包括组件的可靠性是未知的或可变的系统。在间歇性的组件失败中，四层系统可以轻易地合并运行时发现机制（runtime discovery mechanisms）以切换到不同的组件实现上。有四个或多个层次的很多复杂系统最少提供了发现新能力（例如，涉及到新的Web服务实现时，它们就实现了UDDI记录）的一些能力。如果环境利用了多个、潜在地冲突的技术，四层系统提供了用于管理对话管理层（session management layer）或业务域对象层中的差异的机制。同样，如果客户端有多种不同的应用模型，而这些模型都需要共享共同的数据资源，那么四层模型也可能是理想的。经常地，在其它的应用程序组件不希望阻塞并等待资源，不得不在对话层中管理客户端的访问的环境中，应用程序组件允许业务域组件处理资源管理的问题并能够经受得住等待大多数资源。
对等（peer-to-peer，P2P）架构方式对于多数需要高度可升级的系统是理想的。同样，当分布式组件需要协调完成某种事务并且通讯以及其它组件的可靠性可能变化的时候，它们也是有用的。在开发P2P系统的时候操作环境很容易被理解是非常重要的，因为不好的习惯可能导致重大的灾难。同样，当使用P2P技术的时候，接口的标准化和不允许修改也是很重要的。被迫应付多个P2P网络的不兼容的版本简直是个梦魇。
N层和/或这些方式的组合（图15）应该仅仅用于十分复杂的、由多个软件生命周期不同的子系统和组件构成的系统。这对于大多数大型的不同种类的企业系统是真实的，在这种情况下，在任何时候组件都在升级、更换或添加。对于这种系统，考虑的事项必须通知系统组件的管理部门。
哪些特性值得使用复杂的N层系统呢？通常，它包括管理用于增强用户体验的大量数据的系统。其需求可能包括记载了用户的概要信息、允许用户设置参数控制Web页面和应用程序、管理复杂的安全需求（例如用于控制资源的访问控制列表）、允许用户要求后端应用程序中的存储管理和规则执行的进行改变等一些Web站点和应用程序。
有了N层应用程序，应用程序的功能被分解为大量的逻辑层，它们可以分开维护和配置。每个层次的功能没有三层应用程序那么标准，并且经常把很多层合并成一组来提供表现、应用和/或业务逻辑和存储管理功能。支持多个层次的主要优点是更容易修改某个层次而不需要改变很多层次（在大多数情形中不需要改变其它任何层次）。此外，通过变更一个或多个层次的分布或载入，应用程序能够被扩大为处理大量的用户负载和/或数据。通常这种缩放对于其它层次是透明的，在很多情况下还是自动的。实际上，多层架构被设想为跨多个计算机和处理器分布程序，而不是在某个应用程序中定义软件的边界。
| |
|
|
|
|
在商业终端用户环境中，对象技术已经应用于很多产生了商业效益的重要的应用程序中。其示例包括世界上最大的共同基金公司之一的Fidelity投资公司，它在大约五年前就把自己的基金管理工作站集成为支持多源信息，包含了决策支持能力（这对于基金管理业务是至关重要的）。
他们选择的下部构造是一种符合CORBA标准的对象请求代理的实现。通过使用CBRBA，Fidelity投资公司能够按单独的基金经理的需求定制信息的收集并分析环境。本文的一些读者可能已经投资了一种或多种CORBA支持的有价证券。大型银行机构Wells Fargo也在应用程序中使用了对象技术以形成竞争优势。其示例有，五个月之内开发、定型和配置的财务处理系统都是基于对象技术和CORBA实现的。在这类系统中，他们集成了运行IBM操作系统、支持在线事务终端的大型机环境的框架组件环境。
在Wells Fargo的另一个应用程序中，他们集成了不同种类的系统以支持跨越大型企业的系统管理。系统管理是客户端服务器建立的富有挑战意义的，并且必要的应用程序之一，因为信息技术的操作和管理不再是集中的，但是仍然需要跨越多个自治的（autonomous）的部门系统和用户桌面进行协同。Wells Fargo利用对象技术的优点实现了这样的分布式系统管理能力，并极大地减少了自己的成本，减少了系统支持挑战的响应能力方面的问题。
对象技术的另一个生动的例子是由一个大型的保险公司实现的。USAA有一个汽车保险索赔系统，客户服务代理商可以使用它通过电话接收损害索赔的报告。除了汽车保险外，USAA还有大量的相关产品线（包括生命保险和借贷能力）。通过使用对象把自己的信息技术集成到一起，USAA能够为客户服务代理商提供USAA全部产品线的信息。如果某个客户报告了汽车损害索赔，该汽车已经被评估了并且需要更换，客户服务代理商就能够处理该保险索赔并为交通工具的更换提供一辆新车贷款。此外，客户服务代理商还有该客户的相关信息，例如年龄、小孩的数量，能在这个保险索赔电话之中的适当的时候提供更多的保险覆盖范围。有了这些增强的能力（本质上重新构造了自己的客户服务流程），USAA能够在已有的客户身上获得30％的收入增长，而这仅仅是通过为呼叫USAA进行汽车索赔为目的的客户提供额外的服务获得的。
在公共部门，对象技术也被广泛地应用了，并带来了显著的优点。其中有几个例子是通过数据交互和增进间接使用研究（Data Interchange and Synergistic Collateral Usage Study，DISCUS）项目实现的。这个项目和其学术课程都在The Essential CORBA【Mowbray 1995】一书中描述过。最前面的学术课程是讨论使用对象技术来重复使用设计信息的能量的。一旦建立并使用IDL指定了软件的接口，那么让承包人（contractors）和商业厂商支持互通性的接口就相对廉价了。这种能力是在Internet革命之前定义的，当它变得适合于集成Internet能力的时候，其相同的封装能够同样地集成通过Internet浏览器查看数据的新方法。接着它实现的已有的传统集成可以用于在Internet浏览器上查看数据提取信息。
作者实现的另一个案例研究包含了一组信息访问服务，它在Inside CORBA 【Mowbray 1997c】一书中有记载。在这个应用程序中，研究了一个事实，即政府已经实现了多个能力相似的系统，而终端用户要求这些系统能够交互操作并支持对信息资源的扩展访问。为了解决用户需求的问题，作者引导我们对已有的系统进行研究，其焦点在通过多种技术支持的软件接口。通过研究传统系统接口的细节信息，可以阐述新的面向对象的设计，在其中采用一般方式跨越传统系统的环境捕捉已有的功能。通过给IDL规范提供新的接口设计，其它的承包人可以用它来辅助实现原型并通过政府标准化进程来推进该规范。在两年之内，互通性的概念演化成了包含正式测试的可以运转的软件，确定了规格的多个实现之间的一致。
很多企业都有机会认识这类结果。由于大型企业中的信息技术正在从桌面和部门级信息系统演化成互通性的企业系统，大多数组织中都不存在的企业架构层可以用分布式对象技术（它用普通的方式提供了互通性）使用一般的方式来实现。
总之，商业组织从对象技术中得到了很多优势，而这些优势与它们共同的竞争优势直接相关。作者在研究和开发方面的经验显示，设计的重复使用是用于实现这类结果的最重要的观念。规定了适当的软件接口规范后，软件开发者相对比较容易通过训练了解规范并容易进行规范的实现。开发者在没有这类指导的情形下集成系统要困难得多。换句话说，彻底改造一个新的定制的互通性的链接明显地比给予开发者系统如何交互操作的设计，并且只需要实现执行该能力的代码要困难多了。在研究和开发的过程中，作者发现即使在系统最小的情形下（只集成两个或三个子系统）也有这种好处；随着集成的子系统上升到七个或十个或更多，它优势也增加。
目前通过对象技术可以实现系统的互通性，并且这些优势已经被已有商业系统和公共部门中的系统认识到了。 | |
|
|
|
|
软件架构同时包括应用程序功能和商业技术改变的管理。前面提到的一些优点并不是采用特定技术的直接结果，而是用效率最高的方式采用某种技术以实现系统的商业目标。采用CORBA或COM+这样的简单决定对于保证实际的商业成果并不充分。其中一个关键的挑战是如何管理那些支持长时间系统生命周期，并且随着技术的演化需要扩展那些没有持续地维护的系统。
图16是一些必须被面向对象架构管理的技术挑战的例子。图16涉及到中间件技术的演化，从套接字技术开始演化到远程过程调用和分布式计算环境，再到目前的J2EE和ActiveX技术。没有人可以准确地预料未来，但是有了专利技术演化和开放系统演化的知识后，我们可以看出目前正在流行的大多数技术最终都有自己的生命周期，因而它们都有一个明确的终止点，这依赖于厂商什么时候终止对自己产品的支持并把他们的注意力移到新的产品线上。中间件的特殊的技术演化对应用软件有戏剧般的影响，因为中间件与很多已有的应用程序能力是紧密集成的。当某种技术（例如ActiveX）被废除的适合，为了受到厂商的支持和集成新的能力，把应用系统升级到新的技术是必要的。ActiveX的让位的情形在COM+（一种随后的技术）中也可以看到了，它更替了技术的核心原理。它的软件接口可能明显不同，特别是由于COM和COM+都是以一种接口定义语言为基础的，但是它与CORBA的接口定义语言不同，而且COM+没有接口定义语言，至少在目前市场中是没有的。软件架构能够预料到这类必然的改变并且能够计划把应用系统迁移到新架构的能力是很重要的，而且不会降低当前系统开发的商业目标。
架构在应用程序方面面临着很多挑战。其中最艰难的挑战莫过于改变当前正在使用的业务流程。所有的部门都面临着越来越多的竞争，通过技术把多种能力合并在一起，例如通过Internet，类似报纸、计算机公司、有线电视厂商、电讯运营商都开始在同一个竞争空间中工作了，并且正在经受着强大的竞争压力，这些都是信息技术革新和应用系统中实现的革新概念的直接结果。即使有了先前的技术，我们也相当清楚需求发生了很大的改变。实际上，软件开发中的应用程序成本的大部分都直接归咎于需求的改变【Horowitz 1993】。
在历史上第一次出现了信息技术的预算超过了类似金融服务行业中的很多组织的工资总额。在这类领域中信息技术正在成为竞争优势的同义词。但是，系统开发的基本能力仍然远远落后于需要充分了解的竞争能力。例如，在共同开发中，三个已经开始的系统中大约有一个以项目取消为结束【Johnson 1995】。这类统计数据表明小型和中型企业面临过度异常的风险，他们的成本和对信息系统的依赖都在不断增长。
计算机行业中重要的基本原则之一是没有任何技术会真正地“离开”。我们可以想象，有些早期的IBM小型机至今仍然在世界范围内忠诚地执行各种业务系统中的任务。随着信息技术的演化，集成越来越多的不同系统和软件的需求开始变成重大的挑战了。随着跨越企业或者在企业之间使用内部网和外部网集成成为必须的，架构的挑战成为了现实。其中有一个问题是当前信息技术的下部构造的不充分，包括COM+和CORBA，它们在某些重要的方面与现实的应用程序需求之间有差异。
随着信息技术的挑战逐步上升，另一个与软件技能基础相关的问题浮出了水面。在某些行业中，软件工程师是不够的。与此同时，估计在美国软件工程行业最少有10％的失业率。某些行业想成功还要困难一些，其中包括公共部门系统承包商。为了建立已经考虑到的挑战的一些系统，面向对象架构必须计划系统的开发并采用比以往效率更高的方式控制关键的软件边界。
在应用程序开发者和软件架构的面前还有很多重大的挑战。应用系统开发的复杂性在逐步升高。这种复杂性是由不断增加的不同信息系统和在公司内部和外部集成的范围不断增加而导致的。此外，用户的需求不仅增加了用户的期望（这是暴露的Internet技术和其它惊奇的现代生活的结果），而且驱动着软件开发者使用更复杂的和矫饰的的系统概念，导致了风险增加。面向对象架构的关键角是改变（change）的管理。管理不同步的产品生命周期的商业技术创新是它的一个方面。另一个方面是管理信息技术支持和实现的业务流程的改变。可能的解决方案之一是由用户来引导开放系统技术的演化，要求软件厂商提供完整的技术能力，影响立法者为系统架构和开发的设想目标设置一些商业性的和适用的恰当的保证。
| |
|
|
|
|
在采用面向对象架构和技术的时候会出现一些问题。这些问题必须被解决以完整地了解架构和技术含意。定义面向对象的问题以及包含对象技术的组件技术在前面已经讨论过了，并且已经经讨论了对象技术与其它技术（例如面向过程的技术）的比较情况了。
对于特定类别的应用程序而言还有一些其它问题和需求是至关紧要的。性能、可靠性和Internet上的安全性问题，以及如何把这些技术与占有重要市场份额的厂商集成都是我们在采用这些技术的适合需要考虑的重要问题。下面一些内容解释了一些基本的概念，这些概念描述了商业和应用程序端的面向对象的架构。而且，其中的案例是为面向对象软件开发实践中的开放系统技术的应用程序设计的。此外，它还谈到了在实现和开发过程中应用对象技术、集成传统系统、监视这些技术的影响等应用程序开发的问题。 我们要重点注意基于开放系统的商业技术是按照确定的基本原理演化的。这些原理是由Carl Cargill建立的一个模型清晰地定义的，该模型描述了标准化的五个阶段（图17）。创建一个开放系统标准步骤的时候，有必要定义一个参考模型。参考模型定义了公用的规则、概念和整个标准家族所使用的术语。这些参考模型也应用于面向对象架构和应用系统的集成。参考模型是软件工程步骤中经常被遗忘的一个元素，但是它可以解决复杂的问题。通过正式的开放系统步骤建立一个正式的参考模型需要很多人花费大量的精力。
国际标准化组织的一个典型的参考模型大约需要花费十年时间来形成明确的表述。根据参考模型，可以建立和采用大量的行业标准，它正式标准化的时间稍微短一些，大约需要七年。参考模型和行业标准通常都是很多技术厂商的智力成果。这些标准根据最大数量的消费者基础表现为最通用的技术名称。为了应用这些技术，有必要定义很多概要以充当减少特定范围或应用系统集合中使用某种标准的复杂性的角（图2.13b）。
概要描述分为两类：功能性概要（Functional profiles）概括地定义了特定范围中某种应用程序的标准。这些典型的范围可能包括抵押贷款或汽车制造业。功能性概要定义了相同行业中多个公司的通用惯例。功能性概要可以是信息技术厂商的产品，但是通常是技术的使用者和厂商产品的结合。
下一层次的概要称为系统概要（system profiles）。系统概要定义了特定的一组系统如何使用某种或某些标准。该组系统通常与某个企业或虚拟的企业相关联。例如，Ford Motor公司使用的一组电子数据交换标准定义了公司和它的制造过程供应商如何提供实时的存货管理，这样Ford的生产线就能有组织地生产而不会中断。
系统概要之上是应用系统（application systems），它们是特定的实现。尽管概要的概念对于很多软件工程师来说是全新的，但是在所有的系统中概要都被实现了，当然可能是隐含地实现的。无论什么时候应用某种一般目的的标准或商业技术，都会作出一些关于如何使用该技术的惯例的决定，而这些这些决定组成了概要。不幸的是，很多重要的概要都被信息系统的实现细节隐藏了。请注意，建立每种类型的规范的时间跨度都在缩短。其意图在于参考模型为长期开发的所有标准、概要和系统提供了稳固架构的框架。行业标准提供了下一个层次的稳定性和连贯性，概要提供了跨越多个范围和应用程序组的稳定性和一致，所有这些机制都支持属于半年到一年半的应用系统的快速建立。
图18显示了某个特定的信息技术厂商的角度的参考模型。一般来说，某个厂商会使用跨越多个行业标准的单个参考模型。该厂商实现符合这些标准的技术，接着与不同的应用程序开发者和垂直市场一起来定义在颇有价值的业务系统中这些技术的用法。这对于厂商来说有一个放大因子，通过使用这种方式，潜在的大量消费者都被它们提供的技术所激活了。
图19从终端应用程序开发者的角度描述了这个概念。根据模糊判断，这个图表有点好笑，但是它是目前各类信息技术中的面向对象架构所面临的有代表性的挑战。对于一个给定的应用系统，大量的标准和参考模型都潜在地能够应用于该系统的开发。可以通过框架得到少量的功能性概要和系统概要以指导应用系统的开发。通常在应用程序实现和行业标准的概要方面会有一些出入。因为概要根本上是用户的责任，在指导过程中认为用户应该受到责备是恰当的。
图19.用户和应用程序开发者角度的标准编程语言培训
| |
当应用系统项目之间没有达成概要一致的时候，可能的结果是系统将不能交互操作，即使它们使用一样的行业标准，甚至于是来自同一个厂商的产品。这对于应用程序架构来说是一种糊涂的和有阻碍的情况。为了解决未来系统开发中的这类问题，我们了解这些原理是有必要的。
| |
|
|
|
|
|
早期引入了中间件的概念。中间件为集成服务器平台和计算机客户端提供了网络硬件之上的软件下部构造，它有可能包含所有的平台。
分布式的下部构造是面向对象和其它信息技术的广义描述，而软件架构可以从中选择技术。图20显示了客户端服务器和中间件操作系统平台上可以选择的技术【Orfali 1996】。在客户端平台上，其技术包括Internet Web浏览器、图形用户界面开发能力、系统管理能力和操作系统。在服务器平台上，是相似的一组技术，包括对象服务、件能力、事务能力和数据库。前面提到，随着客户端－服务器技术的演化，服务器的能力都迁移到客户端平台上了。在中间件的舞台上，也有相当大的一组客户端－服务器能力。其中包括大量的可以选择的不同的传输堆栈、网络操作系统、系统管理环境和。这些技术都在Bob Orfali、Dan Harkey和Jeri Edwards合写的一本书《The Client Server Survival Guide》【Orfali 1996】中有详细的说明。
我们需要知道客户端－服务器技术的一些关键点包括一个事实，即被采用的重要的客户端－服务器技术都是基于标准的。标准的伟大的方面是有太多的可供选择。一个典型的应用程序的简单的概要就包含了超过300种技术标准。这些标准概要将可以适用于一个典型的大型企业信息政策。现在已经为美国政府和工商行业建立了很多类似的概要。信息技术市场是巨大的、并且在不断增长。这个市场中的面向对象部分仍然相对较小，但是已经形成了充足的市场，因此它是大多数应用程序环境中的一个要素。
标准在演化，商业技术也在演化。标准可能花费七年时间才会被正式采用，但是在类似OMG的团体中在一年半的时间中它就会被完善。商业技术演化的速度更快，在80年代末90年代初技术特征以三年为周期，目前下降到18个月到一年为周期。例如，很多厂商开始把年份组合它们的产品的名称中，这样程序每次被调用的时候技术的落后都是很明显的，用户不得不每年升级它们的软件。厂商会把创新的时间减少到小于一年并且开始把月份与年份一起绑定到他们的产品中吗？
产品版本之间的兼容性的管理逐渐成为一种困难的挑战，使最终用户企业依赖于自己的信息技术环境中成百甚至于成千个独立的产品版本。一个典型的中型独立软件厂商大约依赖于200个软件卖主，通过它们发送产品和服务，而六年前这个数值大约只有十二个。图21更详细地显示了中间件市场中的商业技术是如何朝着增加应用程序功能的方向演化的。它以网络源开始，协议堆栈（例如传输控制协议，TCP）提供了在网络上移动未加工的数据的基本能力。
| |
|
|
|
|
下一层次的技术包括套接字服务（socket services），它在多数平台上是可以使用的，位于Internet技术之下。套接字服务解决了平台依赖之间的差异。在接下来的一层中是一些服务接口，例如传输层自主（transport-layer independence，TLI），它允许我们替代应用软件下的多套接字层的消息服务。由于每一项技术都改善了它的前任技术，额外的功能（它一般被编写到应用软件中）被包含到下层的基本构造中。这样提高抽象层次的结果是在服务质量方面我们丢掉了对很多下层网络细节的控制权，而更原始的层次都暴露了这些控制能力。在传输过程无法看见的基础之上，远程过程调用技术为基于网络的通讯提供正常的高级语言机制。分布式的计算环境表现了面向过程的技术支持分布式计算的颠峰。面向对象扩展到了DCE，包含了面向对象的DCE和微软的COM+，目前为使用面向对象编程语言和这些下部构造提供了机制。
最后，CORBA对象请求代理通过把对象类引用的方式与独立的服务引用的方式统一起来，从而抽象了上述的远程进程机制。换句话说，CORBA技术删除了另一个层次的网络细节信息，简化了分布式计算环境中对对象和服务的引用。技术演化的进步不一定始终是直接向前的。有些拥有架构上的优点的重要技术没有在技术市场上取得成功。其例子有OpenDoc技术，很多权威认为它的架构上的优点超越了当前的类似ActiveX和JavaBeans的技术。
标准组织的成员重叠得太多了，造成了大公司主宰着多数论坛。这些组织随着技术演化的潮流来来去去。最近Internet论坛（W3C， IETF）也被控制了，它就如同JavaSoft和微软开放论坛一样了。
很多网络和开放系统技术和其它面向对象标准都是现在的已经不存在的团结的成果。团体的情况是动态的。有些先前的团体（例如开放软件基金和X Open）现在被合并了（合并为Open Group）。其它一些团体，例如对象管理工作组和通用开放软件工作组的成员也是高度重叠的。最近还添加了Active工作组，它负责发布微软开发的已经发布的技术的规范（图22）。开放软件基金发起了支持远程进程调用和其它分布式服务的分布式计算环境。而分布式计算环境是微软COM+技术直接的前身。分布式计算环境反映了微软之外的厂商团体对于程序的分布式计算的一致意见。
有了CORBA，分布式计算环境就是大型企业利用的一种主流技术了（图23）。分布式计算环境的重要缺陷之一是单协议堆栈（single-protocol-stack）实现的规定。随着分布式计算技术的演化，它为了满足不同的服务质量需求提供多种网络实现逐渐变成必要的。这些要求可能包括消息传递的实时性、性能、吞吐量、可靠性、安全性和其它非功能性需求。在单协议堆栈实现中，应用程序的开发者没有能力提供适当层次的服务。此处描述的技术缺口完全可以用访问透明度（access transparency）来表述，它是国际标准化组织的参考模型定义的术语。适当的面向对象的分布式计算的下部构造的确提供了访问透明度并赋予开发者选择适当的协议堆栈以符合应用程序服务质量需求的自由。
图24显示了微软的COM+和ActiveX产品线的下部构造技术。分布式计算使用的这些技术的基础来自原始的OSF环境，但是人们通过不同的方式利用专利接口扩展了这种技术，使它也支持使用C++编程（作为DCE支持的C编程的补充）。ActiveX技术在支持分布式计算的能力和局限于单个桌面系统的能力之间有一道分割线。特定的桌面能力包括复合文档工具。复合文档工具支持将来自多个应用程序的数据集成到一个office文档中。把文档从一个桌面迁移到另一个桌面的时候，可能会出现一些问题，因为它缺乏与分布式环境的完善的集成。
图25显示了组件对象模型和COM+模型是如何与应用软件对接的一些低层细节信息。应用软件被暴露给微软生成的功能表，而这个功能表直接与微软Visual C++的运行时系统相关。应用软件中的这种连接Visual C++的紧密耦合的结果是，向其它编程语言的映射不是标准化的，并且在某些情形中这是很困难的（例如，把原始的C程序与COM+下部构造一起应用）。CORBA技术提供了克服这些缺点的一种方法。
| |
|
|
|
|
图26显示了对象请求代理（ORB）背后的一些基础概念。ORB的目的是为了提供应用软件的不同元素之间的通讯。提供服务的应用软件表现为对象。这种对象可能封装了并非面向对象的软件。应用程序客户端可以通过ORB发送请求从对象中要求某些服务。我们定义CORBA的机制是为了帮助自己简化分布式系统中客户端的角。这种方法的优点是它减少了必须编写建立应用程序客户端并使它在分布式环境中交互操作的软件的数量。
图27显示了CORBA模型的一些出的细节信息。图27与图26相对应，在图26中客户端和对象软件通过ORB交互操作。CORBA所标准化的这部分下部构造局限为应用软件和ORB下部构造之间的屏蔽接口。CORBA并没有标准化下层机制或者协议堆栈。这种实现的自由度有优点，而且很重要。由于不同的实现可以在CORBA接口之下提供不同的机制和协议堆栈，大量的不同的产品支持这种标准，并且提供了不同的服务质量。实际上，有些实现提供了动态的服务质量，它可以在本地类型和远程类型的调用之间变更。这种实现的自由度的结果是被选择的机制在不同的厂商之间可能是不兼容的。一个附加的协议Internet Inter ORB协议（IIOP）定义了不同的ORB机制如何能够透明地交互操作。所有的CORBA产品都必须有IIOP的实现部分。
CORBA下部构造同时为客户端和通讯服务的实现端提供了两种不同类型的机制。在客户端，客户端开发者可以选择使用预编译的存根（stub）程序，它类似于对应用软件的普通调用。静态存根的使用最小化了所需要的专用的编程，因为应用程序是潜在的分布式的。存根程序看起来类似应用程序环境中的本地对象，但是存根表现为远程对象的一个代理。
客户端开发者也可以使用动态调用（图27）。动态调用是一种接口，它允许客户端调用自己动态发现的对象上的任何消息请求。动态调用赋予CORBA机制可扩展性，这仅仅在某些类型的专业应用程序中是有用的。而这些应用程序可能包括程序调试器、移动代理程序和操作系统。CORBA环境中的对象服务的工具也拥有选择静态调用或动态调用的能力。这两种选择都是随着静态程序框架（skeleton）或动态程序框架产生的。
这些程序框架为软件提供了ORB通讯下部构造和应用程序之间的接口，而且它们是用软件开发者自然了解的方式实现这种操作的。通过在相同的程序中使用动态程序框架和动态调用，就可能实现一些有趣的能力。例如，软件防火墙，它提供了在不同的应用程序组之间的过虑，可以被这两种动态能力轻易地实现。
图28显示了对象管理架构中的CORBA技术和这些技术如何与前面讨论的Cargill模型相关联的。图9中显示的对象管理架构提供了所有CORBA技术的参考模型。CORBA和其相关的标准，例如CORBA服务和CORBA工具，都是广泛地应用于多个域的行业标准的例子。
CORBA域包含了Cargill模型中的功能性概要。换句话说，CORBA接口规范描述了如何使用CORBA技术提供互通性的特定域互通性协定。最后，对象管理架构中的应用程序对象直接与Cargill模型中的应用程序实现相对应。
其它一些主动者（除CORBA之外）也试图规定全面的标准层次。首先是Taligent，其次是IBM的San Francisco项目试图定义对象的标准框架，但是都没有获得预期的流行。Java J2EE最接近于达到这种情形，并且表现出了向着完成标准全景的方向的显著的进步。
结论
本文介绍了面向对象、开放系统和面向对象架构的基本概念。它还讨论了面向对象在软件系统方面的独立改变，它把数据和过程组合到称为对象的模块中。对象技术是一种已经出现并进入软件开发主流的能力。对象技术已经通过软件出售被工商业和很多主流的终端用户组织在它们的应用程序开发中广泛地支持了。
本文还讨论到，唯一可以维持的商业进步都是以商业技术的开放系统形式存在的。在专利技术中，能力的废弃与建立支持应用程序功能扩展的稳定应用程序环境是相互使矛盾的。
此外，stovepipe系统是应用程序架构的普遍形式，但是它可以被革新成为效率更高的组件对象架构。在后面的部分中，描述了对象技术和形成这些可以理解的技术的多种参考模型。
本文考虑了面向对象架构的关键观念之一——软件开发中的应用程序的标准。对如何利用标准的适当的了解对于成功的采用商业技术和应用程序功能的互通性是很重要的。
在本文中也描述面向对象的客户端－服务器技术。这些技术聚焦于下层的分布式的计算能力，以及它们与面向过程的一些相关技术的对比。支持这些技术的公司都有高度重复的利益，这都通过商业标准组织和正式的标准团体表达的。实际上，分布式的计算环境不同于CORBA机制和微软技术，这两种技术与远程进程调用更相近。最后，讲述了CORBA下部构造的一些细节和它们如何与Cargill模型关联。
同时本文还谈到了不同的架构层，包括两层、三层、N层和对等的方式。本文讲到了使用不同方式的优点并为什么时候选择一种或多种复杂的架构的决定提供了一些本质性的指导。
总之，大量的开放系统客户端－服务器技术支持面向对象。这些技术允许我们构造基于对象和组件的大量的分布式的系统。
| |
|
|
发表评论