[软件架构训练基础教程-11]下部构造

　　早期引入了中间件的概念。中间件为集成服务器平台和计算机客户端提供了网络硬件之上的软件下部构造，它有可能包含所有的平台。

　　分布式的下部构造是面向对象和其它信息技术的广义描述，而软件架构可以从中选择技术。图20显示了客户端服务器和中间件操作系统平台上可以选择的技术【Orfali 1996】。在客户端平台上，其技术包括Internet Web浏览器、图形用户界面开发能力、系统管理能力和操作系统。在服务器平台上，是相似的一组技术，包括对象服务、群件能力、事务能力和数据库。前面提到，随着客户端－服务器技术的演化，服务器的能力都迁移到客户端平台上了。在中间件的舞台上，也有相当大的一组客户端－服务器能力。其中包括大量的可以选择的不同的传输堆栈、网络操作系统、系统管理环境和特殊服务。这些技术都在Bob Orfali、Dan Harkey和Jeri Edwards合写的一本书《The Client Server Survival Guide》【Orfali 1996】中有详细的说明。

图20.下部构造的参考模型

　　我们需要知道客户端－服务器技术的一些关键点包括一个事实，即被采用的重要的客户端－服务器技术都是基于标准的。标准的伟大的方面是有太多的可供选择。一个典型的应用程序的简单的概要就包含了超过300种技术标准。这些标准概要将可以适用于一个典型的大型企业信息政策。现在已经为美国政府和工商行业建立了很多类似的概要。信息技术市场是巨大的、并且在不断增长。这个市场中的面向对象部分仍然相对较小，但是已经形成了充足的市场，因此它是大多数应用程序环境中的一个要素。

　　标准在演化，商业技术也在演化。标准可能花费七年时间才会被正式采用，但是在类似OMG的团体中在一年半的时间中它就会被完善。商业技术演化的速度更快，在80年代末90年代初技术特征以三年为周期，目前下降到18个月到一年为周期。例如，很多厂商开始把年份组合它们的产品的名称中，这样程序每次被调用的时候技术的落后都是很明显的，用户不得不每年升级它们的软件。厂商会把创新的时间减少到小于一年并且开始把月份与年份一起绑定到他们的产品中吗？

　　产品版本之间的兼容性的管理逐渐成为一种困难的挑战，使最终用户企业依赖于自己的信息技术环境中成百甚至于成千个独立的产品版本。一个典型的中型独立软件厂商大约依赖于200个软件卖主，通过它们发送产品和服务，而六年前这个数值大约只有十二个。图21更详细地显示了中间件市场中的商业技术是如何朝着增加应用程序功能的方向演化的。它以网络源开始，协议堆栈（例如传输控制协议，TCP）提供了在网络上移动未加工的数据的基本能力。

图21分布式计算技术的演化

　　下一层次的技术包括套接字服务（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+技术直接的前身。分布式计算环境反映了微软之外的厂商团体对于程序的分布式计算的一致意见。

图22.商业软件技术团体

　　有了CORBA，分布式计算环境就是大型企业利用的一种主流技术了（图23）。分布式计算环境的重要缺陷之一是单协议堆栈（single-protocol-stack）实现的规定。随着分布式计算技术的演化，它为了满足不同的服务质量需求提供多种网络实现逐渐变成必要的。这些要求可能包括消息传递的实时性、性能、吞吐量、可靠性、安全性和其它非功能性需求。在单协议堆栈实现中，应用程序的开发者没有能力提供适当层次的服务。此处描述的技术缺口完全可以用访问透明度（access transparency）来表述，它是国际标准化组织的参考模型定义的术语。适当的面向对象的分布式计算的下部构造的确提供了访问透明度并赋予开发者选择适当的协议堆栈以符合应用程序服务质量需求的自由。

图23.分布式计算环境

　　图24显示了微软的COM+和ActiveX产品线的下部构造技术。分布式计算使用的这些技术的基础来自原始的OSF环境，但是人们通过不同的方式利用专利接口扩展了这种技术，使它也支持使用C++编程（作为DCE支持的C编程的补充）。ActiveX技术在支持分布式计算的能力和局限于单个桌面系统的能力之间有一道分割线。特定的桌面能力包括复合文档工具。复合文档工具支持将来自多个应用程序的数据集成到一个office文档中。把文档从一个桌面迁移到另一个桌面的时候，可能会出现一些问题，因为它缺乏与分布式环境的完善的集成。

图24.ActiveX技术原理

　　图25显示了组件对象模型和COM+模型是如何与应用软件对接的一些低层细节信息。应用软件被暴露给微软生成的功能表，而这个功能表直接与微软Visual C++的运行时系统相关。应用软件中的这种连接Visual C++的紧密耦合的结果是，向其它编程语言的映射不是标准化的，并且在某些情形中这是很困难的（例如，把原始的C程序与COM+下部构造一起应用）。CORBA技术提供了克服这些缺点的一种方法。

图25.组件对象模型

　　图26显示了对象请求代理（ORB）背后的一些基础概念。ORB的目的是为了提供应用软件的不同元素之间的通讯。提供服务的应用软件表现为对象。这种对象可能封装了并非面向对象的软件。应用程序客户端可以通过ORB发送请求从对象中要求某些服务。我们定义CORBA的机制是为了帮助自己简化分布式系统中客户端的角色。这种方法的优点是它减少了必须编写建立应用程序客户端并使它在分布式环境中交互操作的软件的数量。

图26.对象请求代理概念

　　图27显示了CORBA模型的一些出色的细节信息。图27与图26相对应，在图26中客户端和对象软件通过ORB交互操作。CORBA所标准化的这部分下部构造局限为应用软件和ORB下部构造之间的屏蔽接口。CORBA并没有标准化下层机制或者协议堆栈。这种实现的自由度有优点，而且很重要。由于不同的实现可以在CORBA接口之下提供不同的机制和协议堆栈，大量的不同的产品支持这种标准，并且提供了不同的服务质量。实际上，有些实现提供了动态的服务质量，它可以在本地类型和远程类型的调用之间变更。这种实现的自由度的结果是被选择的机制在不同的厂商之间可能是不兼容的。一个附加的协议Internet Inter ORB协议（IIOP）定义了不同的ORB机制如何能够透明地交互操作。所有的CORBA产品都必须有IIOP的实现部分。

图27CORBA架构中的关键接口

　　CORBA下部构造同时为客户端和通讯服务的实现端提供了两种不同类型的机制。在客户端，客户端开发者可以选择使用预编译的存根（stub）程序，它类似于对应用软件的普通调用。静态存根的使用最小化了所需要的专用的编程，因为应用程序是潜在的分布式的。存根程序看起来类似应用程序环境中的本地对象，但是存根表现为远程对象的一个代理。

　　客户端开发者也可以使用动态调用（图27）。动态调用是一种接口，它允许客户端调用自己动态发现的对象上的任何消息请求。动态调用赋予CORBA机制可扩展性，这仅仅在某些类型的专业应用程序中是有用的。而这些应用程序可能包括程序调试器、移动代理程序和操作系统。CORBA环境中的对象服务的工具也拥有选择静态调用或动态调用的能力。这两种选择都是随着静态程序框架（skeleton）或动态程序框架产生的。

　　这些程序框架为软件提供了ORB通讯下部构造和应用程序之间的接口，而且它们是用软件开发者自然了解的方式实现这种操作的。通过在相同的程序中使用动态程序框架和动态调用，就可能实现一些有趣的能力。例如，软件防火墙，它提供了在不同的应用程序组之间的过虑，可以被这两种动态能力轻易地实现。

　　图28显示了对象管理架构中的CORBA技术和这些技术如何与前面讨论的Cargill模型相关联的。图9中显示的对象管理架构提供了所有CORBA技术的参考模型。CORBA和其相关的标准，例如CORBA服务和CORBA工具，都是广泛地应用于多个域的行业标准的例子。

图28对象管理架构的扩展

　　CORBA域包含了Cargill模型中的功能性概要。换句话说，CORBA接口规范描述了如何使用CORBA技术提供互通性的特定域互通性协定。最后，对象管理架构中的应用程序对象直接与Cargill模型中的应用程序实现相对应。

　　其它一些主动者（除CORBA之外）也试图规定全面的标准层次。首先是Taligent，其次是IBM的San Francisco项目试图定义对象的标准框架，但是都没有获得预期的流行。Java J2EE最接近于达到这种情形，并且表现出了向着完成标准全景的方向的显著的进步。

　　结论

　　本文介绍了面向对象、开放系统和面向对象架构的基本概念。它还讨论了面向对象在软件系统方面的独立改变，它把数据和过程组合到称为对象的模块中。对象技术是一种已经出现并进入软件开发主流的能力。对象技术已经通过软件出售被工商业和很多主流的终端用户组织在它们的应用程序开发中广泛地支持了。

　　本文还讨论到，唯一可以维持的商业进步都是以商业技术的开放系统形式存在的。在专利技术中，能力的废弃与建立支持应用程序功能扩展的稳定应用程序环境是相互使矛盾的。

　　此外，stovepipe系统是应用程序架构的普遍形式，但是它可以被革新成为效率更高的组件对象架构。在后面的部分中，描述了对象技术和形成这些可以理解的技术的多种参考模型。

　　本文考虑了面向对象架构的关键观念之一——软件开发中的应用程序的标准。对如何利用标准的适当的了解对于成功的采用商业技术和应用程序功能的互通性是很重要的。

　　在本文中也描述面向对象的客户端－服务器技术。这些技术聚焦于下层的分布式的计算能力，以及它们与面向过程的一些相关技术的对比。支持这些技术的公司都有高度重复的利益，这都通过商业标准组织和正式的标准团体表达的。实际上，分布式的计算环境不同于CORBA机制和微软技术，这两种技术与远程进程调用更相近。最后，讲述了CORBA下部构造的一些细节和它们如何与Cargill模型关联。

　　同时本文还谈到了不同的架构层，包括两层、三层、N层和对等的方式。本文讲到了使用不同方式的优点并为什么时候选择一种或多种复杂的架构的决定提供了一些本质性的指导。

　　总之，大量的开放系统客户端－服务器技术支持面向对象。这些技术允许我们构造基于对象和组件的大量的分布式的系统。