软件架构之基于中间件开发

第 15 章：基于中间件的开发

20 世纪 90 年代初，C/S 计算模式成为主流，将数据统一存储在数据服务器上，而有
关的业务逻辑都在客户端实现。但是，这种两层结构的模式由于服务器依赖于特定的供应商，数据存取受到限制，再加上难以扩展到广域网或互联网等原因，极大地阻碍着计算机软件系统的发展。有人提出将客户端的业务逻辑独立出来，形成第三层。在这种三层结构中，客户端仅仅是处理图形用户界面，在设计和实现时需要开发的，仅是在应用服务器上的业务逻辑部分的软件。

随着 Internet 及 WWW 的出现，计算机的应用范围更为广阔，许多应用程序需在网络环境的异构平台上运行。在这种分布异构环境中，通常存在多种硬件系统平台（例如 PC、工作站、小型机等），在这些硬件平台上又存在各种各样的系统软件（例如不同的操作系统、数据库、语言编译器等），以及多种风格的用户界面，这些硬件系统平台还可能采用不同的网络协议和网络架构连接。如何把这些系统集成起来并开发新的应用是一个非常现实而困难的问题。为了解决这个问题，出现了处于系统软件和应用软件之间的中间件。它使设计者集中设计与应用有关的部分，大大简化了设计和维护 工作。

15.1 中间件技术

中间件（middleware）是基础软件的一大类，属于可复用软件的范畴。顾名思义，中间件处在操作系统、网络和数据库之上，应用软件的下层（如图 15-1 所示），也有人认为它应该属于操作系统中的一部分。

15.1.1 中间件的概念

中间件从诞生到现在，虽然仅有 10 多年时间，但发展极其迅速，是有史以来发展最快的软件产品，但在技术上还处于成长阶段，还没有统一的标准和模型，通常都是用 C++ 语言以面向对象的技术来实现的，但是它的特性已超出面向对象的表达能力，由于它属于可重用构件，目前趋向于用构件技术来实现。然而，中间件要涉及软件的所有标准、规范和技术，它有更多的内涵，因为它包括平台功能，自身具有自治性、自主性、隔离性、社会化、激发性、主动性、并发性、认识能力等特性，是近似于 Agent（代理）的结构。

目前很难给中间件一个严格的定义，国际上各家机构都有不同的定义，如 IDC 对中间件给出的定义是：中间件是一种独立的系统软件或服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源，中间件位于客户机服务器的操作系统之上，管理计算资源和网络通信。这些服务程序或软件具有标准的程序接口和协议。针对不同的操作系统和硬件平台，它们可以有符合接口和协议规范的多种实现。中间件为处于其上层的应用软件提供运行与开发的环境，帮助用户灵活、高效地开发和集成复杂的应用软件。中间件应具有如下的一些特点：

• 满足大量应用的需要；
• 运行于多种硬件和 OS 平台；
• 支持分布计算，提供跨网络、硬件和 OS 平台的透明性的应用或服务的交互；
• 支持标准的协议；
• 支持标准的接口。

世界著名的咨询机构 Standish Group 在一份研究报告中归纳了中间件的十大优越性：

• 缩短应用的开发周期；
• 节约应用的开发成本；
• 减少系统初期的建设成本；
• 降低应用开发的失败率；
• 保护已有的投资；
• 简化应用集成；
• 减少维护费用；
• 提高应用的开发质量；
• 保证技术进步的连续性；
• 增强应用的生命力。

具体来说，首先，中间件屏蔽了底层操作系统的复杂性，使程序开发人员面对一个简单而统一的开发环境，减少了程序设计的复杂性，将注意力集中在自己的业务上，不必再为程序在不同系统软件上的移植而重复工作，从而大大减少了技术上的负担。中间件带给应用系统的，不只是开发的简便、开发周期的缩短，也有系统的维护、运行和管理的工作量的减少，还减少了计算机总体费用的投入。Standish 的调查报告显示，由于采用了中间件技术，应用系统的总建设费用可以减少 50%左右。在网络经济、电子商务大发展的今天，从中间件获得利益的不只是 IT 厂商，IT 用户也同样是赢家，并且是更有把握的赢家。

其次，中间件作为新层次的基础软件，其重要作用是将不同时期、在不同操作系统上开发的应用软件集成起来，彼此无缝地整体协调工作，这是操作系统、数据库管理系统本身做不了的。中间件的这一作用，使得在技术不断发展之后，人们以往在应用软件上的劳动成果仍然物有所用，节约了大量的人力、财力投入。

最后，由于标准接口对于可移植性和标准协议对于互操作性的重要性，中间件已成为许多标准化工作的主要部分。对于应用软件开发，中间件远比操作系统和网络服务更为重要，中间件提供的程序接口定义了一个相对稳定的高层应用环境，不管底层的计算机硬件和系统软件怎样更新换代，只要将中间件升级更新，并保持中间件对外的接口定义不变，应用软件几乎不需任何修改，从而节省了企业在应用软件开发和维护中的重大投资。

15.1.2 中间件的分类

好比一个大型城市的交通系统，将网络看做市区马路，通过交通工具（如：汽车）实现通信，每分钟将有数万辆车在马路上行驶，如果没有相应的交通设施和管理规划，城市将会乱成一团，发生各种交通事故，中间件系统就相当于这些配套的交通设施。按照中间件在分布式系统中承担的职责不同，可以划分以下积累中间件产品。
（1）通信处理（消息）中间件。正如，安装红绿灯，设立交通管理机构，制定出交通规则，才能保证道路交通畅通一样，在分布式系统中，人们要建网和制定出通信协议，以保证系统能在不同平台之间通信，实现分布式系统中可靠的，高效的，实时的跨平台数据传输，这类中间件称之为消息中间件，也是市面上销售额最大的中间件产品，目前主要产品有 BEA 的 eLink、IBM 的 MQSeries、TongLINK 等。实际上，一般的网络操作系统如 Windows 已包含了其部分功能。

（2）事务处理（交易）中间件。正如城市交通中要运行各种运载汽车，以此来完成日常的运载，同时随时监视汽车运行，在出现故障时及时排堵保畅。在分布式事务处理系统中，经常要处理大量事务，特别是 OLTP 中，每项事务常常要多台服务器上的程序按顺序协调完成，一旦中间发生某种故障，不但要完成恢复工作，而且要自动切换系统，达到系统永不停机，实现高可靠性运行。要使大量事务在多台应用服务器上能实时并发运行，并进行负载平衡的调度，实现与昂贵的可靠性机和大型计算机系统同等的功能，为了实现这个目标，要求
中间件系统具有监视和调度整个系统的功能。BEA 的 Tuxedo 由此而著名，它成为增长率最高的厂商。

（3）数据存取管理中间件。在分布式系统中，重要的数据都集中存放在数据服务器中，它们可以是关系型的、复合文档型、具有各种存放格式的多媒体型，或者是经过加密或压缩存放的，该中间件将为在网络上虚拟缓冲存取、格式转换、解压等带来方便。

（4）Web 服务器中间件。浏览器图形用户界面已成为公认规范，然而它的会话能力差、不擅长做数据写入、受 HTTP 协议的限制等，就必须进行修改和扩充，形成了 Web 服务器中间件，如 SilverStream 公司的产品。

（5）安全中间件。一些军事、政府和商务部门上网的最大障碍是安全保密问题，而且不能使用国外提供的安全措施（如防火墙、加密、认证等），必须用国产产品。产生不安全因素是由操作系统引起的，但必须要用中间件去解决，以适应灵活多变的要求。

（6）跨平台和架构的中间件。当前开发大型应用软件通常采用基于架构和构件技术，在分布式系统中，还需要集成各节点上的不同系统平台上的构件或新老版本的构件，由此产生了架构中间件。功能最强的是 CORBA，可以跨任意平台，但是过于庞大；JavaBeans 较灵活简单，很适合于做浏览器，但运行效率有待改善；COM+模型主要适合 Windows 平台，在桌面系统已广泛使用。由于国内新建系统多基于 UNIX（包括 Linux）和 Windows，因此，针对这两个平台建立相应的中间件市场相对要大得多。

（7）专用平台中间件。为特定应用领域设计领域参考模式，建立相应架构，配置相应的构件库和中间件，为应用服务器开发和运行特定领域的关键任务（如电子商务、网站等）。

（8）网络中间件。它包括网管、接入、网络测试、虚拟社区、虚拟缓冲等，也是当前最热门的研发项目。

15.1.3 中间件产品介绍

本节介绍主流的中间件产品 IBM MQSeries 和 BEA Tuxedo。
1．IBM MQSeries

IBM 公司的 MQSeries 是 IBM 的消息处理中间件。MQSeries 提供一个具有工业标准、安全、可靠的消息传输系统，它用于控制和管理一个集成的系统，使得组成这个系统的多个分支应用（模块）之间通过传递消息完成整个工作流程。MQSeries 基本由一个信息传输系统和一个应用程序接口组成，其资源是消息和队列。

MQSeries 的关键功能之一是确保信息可靠传输，即使在网络通信不可靠或出现异常时也能保证信息的传输。MQSeries 的异步消息处理技术能够保证当网络或者通信应用程序本身处于“忙”状态或发生故障时，系统之间的信息不会丢失，也不会阻塞。这样的可靠性是非常关键的，否则大量的金钱和客户信誉就会面临极大的损害。

同时，MQSeries 是灵活的应用程序通信方案。MQSeries 支持所有的主要计算平台和通信模式，也能够支持先进的技术如（Internet 和 Java），拥有连接至主要产品（如 LotusNotes 和 SAP/R3 等）的接口。

2．BEA Tuxedo
BEA 公司的 Tuxedo 作为电子商务交易平台，属于交易中间件。它允许客户机和服务器参与一个涉及多个数据库协调更新的交易，并能够确保数据的完整性。BEA Tuxedo 一个特色功能是能够保证对电子商务应用系统的不间断访问。它可以对系统构件进行持续的监视，查看是否有应用系统、交易、网络及硬件的故障。一旦出现故障，BEA Tuxedo 会从逻辑上把故障构件排除，然后进行必要的恢复性步骤。

BEA Tuxedo 根据系统的负载指示，自动开启和关闭应用服务，可以均衡所有可用系统的负载，以满足对应用系统的高强度使用需求。借助 DDR（数据依赖路由），BEA Tuxedo 可按照消息的上下文来选择消息路由。其交易队列功能，可使分布式应用系统以异步“少连接”方式协同工作。

BEA Tuxedo 的 LLE 安全机制可确保用户数据的保密性，应用/交易管理接口（ATMI）为50 多种硬件平台和操作系统提供了一致的应用编程接口。BEA Tuxedo 基于网络的图形界面管理可以简化对电子商务的管理，为建立和部署电子商务应用系统提供了端到端的电子商务交易平台。

15.2 应用服务器技术

Web 应用开发大致经历了三个阶段。在第一阶段，大家都使用 Web 服务器提供的服务器扩展接口，使用 C 或者 Perl 等语言进行开发，例如 CGI、API 等。这种方式可以让开发者自由地处理各种不同的 Web 请求，动态地产生响应页面，实现各种复杂的 Web 系统要求。但是，这种开发方式的主要问题是对开发者的素质要求很高，往往需要懂得底层的编程方法，了解 HTTP 协议，此外，这种系统的调试也相当困难。

在第二阶段，大家开始使用一些服务器端的脚本语言进行开发，主要包括 ASP、PHP、Livewire 等。其实现方法实质上是在 Web 服务器端放入一个通用的脚本语言解释器，负责解释各种不同的脚本语言文件。这种方法的首要优点是简化了开发流程，使 Web 系统的开发不再是计算机专业人员的工作。此外，由于这些语言普遍采用在 HTML 中嵌入脚本的方式，方便实际开发中的美工和编程人员的分段配合。对于某些语言，由于提供了多种平台下的解释器，所以应用系统具有了一定意义上的跨平台性。但是，这种开发方式的主要问题是系统的可扩展性不够好，系统一旦比较繁忙，就缺乏有效的手段进行扩充。此外，从一个挑剔者的眼光来看，这种方式不利于各种提高性能的算法的实施，不能提供高可用性的效果，集成效果也会比较差。

为了解决这些问题，出现了一个新的 Web 应用开发方法，也就是应用服务器的方式。目前，应用服务器已经成为电子商务应用中一种非常关键的中间件技术。如今，各大主要软件厂商纷纷将应用服务器作为其电子商务平台的基础，如 IBM 的 Websphere，Oracle 的Internet 应用服务器，Sybase 的 Enterprise 应用服务器等。本节将阐述应用服务器的概念、相关技术及发展方向，并就目前主流的应用服务器产品进行简单的介绍。

15.2.1 应用服务器的概念

应用服务器是在当今 Internet 上企业级应用迅速发展、电子商务应用出现并快速膨胀的需求下产生的一种新技术，通过它能将一个企业的商务活动安全有效地实施到 Internet 上，实现电子商务。它并非一种传统意义上的软件，而是一个可以提供通过 Internet 来实施电子商务的平台。在分布式、多层结构及基于构件和服务器端程序设计的企业级应用开发中，它提供的是一个开发、部署、运行和管理、维护的平台。它可以提供软件“集群” 的功能，因而可以让多个不同的、异构服务器协同工作、相互备份，以满足企业级应用所需要的可用性、高性能、可靠性和可伸缩性等。

故而，从某种意义上说，应用服务器提供了一个“企业级应用的操作系统”。实现 J2EE规范的应用服务器称为 J2EE 应用服务器。现代社会商机稍纵即逝，电子商务应用要求能很快地开发出功能强大的系统。应用服务
器可以帮助企业快速架构一个基 Internet 的电子商务系统，而且拥有极高的稳定性、可扩展性和安全性。它能够：

（1）更合理地分工企业级应用开发，加快应用的开发速度，减少应用的开发量。应用服务器将系统功能与业务功能分开，使得编程人员能够集中精力在业务功能上，在系统内建立/部署的构件越来越多，并且为分布式架构的时候，系统功能必将变得越来越复杂；而与此同时，对可靠性（负载均衡、容错和故障恢复）的需求也会越来越高。开发人员只关注编码业务方面的功能，对系统一级的功能并没有多少兴趣。因为系统级底层功能的实现，一般需要非常复杂的专业技能，因此对功能实现的合理分离可以允许技能的优化。

在应用服务器上开发采用的模块化方法，提供了大量的可重用模块。一个新的系统可以通过组合一些现成的框架和模块，再加上一定的开发来快速完成。而新开发出的代码又可作为今后重复利用的模块，这一点对于降低开发成本，提高开发速度是非常重要的。

另外，为了便于开发，有些应用服务器还提供开发版的服务器，以便进行各种调试工作。应用服务器一般还提供集成开发环境，将本地编辑、上传、项目管理和调试工具等集中在一起，使开发工作在一个界面内全部完成。还有一些开发环境同时提供后台系统的开发环境，以便同时进行开发管理。此外，还有一些产品内置一些代码的自动生成器，数据库设计辅助工具等，例如 ORM（ObjectRelation Mapping，对象关系映射）等，这些都有效地提高了开发速度，减少了应用开发量。

（2）应用设计、开发、部署、运行、管理、维护的平台。应用服务器既是应用开发的平台，包括表示层、应用层和数据层的设计模式和编程环境；同时又是多层结构应用的部署、运行平台，对多层结构应用进行配置、启动、监控、调整，并在开发的不同阶段承担不同的职责。

• 设计：应用服务器完成底层通信、服务，并屏蔽掉复杂的底层技术细节，向用户提供结构简单、功能完善的编程接口，让用户可以专心于商务逻辑的设计。
• 开发：应用服务器提供了完全开放的编程语言和应用接口，用户可以用任何自己习惯的开发工具来工作。另外应用服务器自己也提供快速开发的工具和手段，帮助用户提高开发效率。
• 部署：应用服务器可以部署在任何硬件平台、任何操作系统上，而且可以分布在异构网络中，应用服务器帮助用户在复杂的网络环境中配置系统参数，使系统发挥最大的性能，拥有最好的稳定可靠性。
• 运行：应用服务器采用的是开放技术标准，它提供了一个完整的标准实现，即提供了系统的运行环境，任何基于同样标准的系统都能很好地运行于这个环境中。在运行中提供应用系统的名字解析、路由选择、负载平衡、事务控制等服务，并提供系统容错、修复、迁移、升级扩展等功能。
• 管理：应用服务器让用户通过图形化的界面方便地管理自己的资源，而且在系统运行时也能动态监控和管理。

（3）使得应用与底层平台无关，便于商业逻辑的实现与扩展。一个好的应用服务器通过提供对操作系统/数据库平台的广泛支持，或采用平台无关技术，如 J2EE，从而能够做到让应用独立于操作系统/数据库平台。显然，它可以确保企业应用具备很好的移植性并保护了企业在应用和开发技能上的投资。 另外一个方面，在激烈的市场竞争条件下，企业的商业逻辑不可能一成不变，而随着生产经营的拓展，首先需要解决的一个问题就是将按需地对现有的业务系统，方便地进行扩充和升级。应用服务器技术可以很好地解决这个问题，因为它采用了三层结构体系，应用服务器将业务流程单独作为一层，客户可以根据自己的商业逻辑来专心设计这一层。应用服务器能提供这种设计能力，当客户业务扩展时，只需专注于改进中间层的设计，原系统就能平滑方便地升级。

（4）为企业应用提供现成的、稳定而强健的、灵活的、成熟的基础架构。在构建电子商务应用的竞争中，许多企业已经没有时间去从容地“千锤百炼”一个电子商务架构体系。通过应用服务器，立刻就可以拥有一个成熟的架构，包括基础平台、标准、应用开发工具和预制构件。

另外一方面，随着经济全球化的步伐加快，许多企业的业务服务于全球，计算机业务系统需要提供 24 小时不间断的服务，系统在大负荷量和长时间运转情况下的稳定性至关重要。应用服务器通过分布式体系来保障这一点，表现为：当系统处理能力不够时，可以通过简单地增加硬件来解决；动态调整不同主机间的负载可以最大地利用系统资源，同时提高单机的稳定性；当系统中的某台机器出现故障时，它的工作可由其他机器来承担，不会影响系统整体的运行，即无单点故障。

目前市面上的应用服务器的解决方案基本都具备了这些作用，因而企业在选购应用服务器产品的时候，不能简单地判断优劣，而需要先充分了解自己的需求到底是什么，然后在各个主要技术问题上，确定适合自己的解决方案，最后寻找使用这些解决方案的产品来完成自己的系统。

15.2.2 主要的应用服务器

本节介绍五种主要的应用服务器产品。
1．BEA WebLogic
BEA WebLogic 作为新一代基于 Java 的 Web 应用服务器，是一款满足 Web 站点对性能和可靠性要求很高的产品。在提供传统的应用服务器功能的同时，还针对当今的 Internet 技术和 Java 技术提供了众多功能，它符合最新 Java 标准。安装 WebLogic 非常容易。WebLogic EJB Deployer Tool 提供了对管理多个 EJB.jar 文件和配置 WebLogic Server 部署特性和资源的控制。Deployer Tool 支持两级 EJB 部署的合法性检测，它自动地检查特性和引用，以确保它们包含正确的值，并检验关键 EJB 所需的类是否符合 EJB1.1 规范。 名为 WebLogic Zero Administration Client（ZAC）发布向导的图形实用程序使用户可以创建、发布和管理包括应用程序、小程序或 Java 代码库的软件包。ZAC 使用户可以开发客户端 Java 应用并将这些应用打包分发。

2．IBM WebSphere
IBM 的 WebSphere 强调其在应用开发（WebSphere Studio 和 VisualAge for Java）、数据库（DB2）和消息服务（MQseries）的集成性。这些产品构成了该公司总体电子商务产品战略的基础。WebSphere 以对多种平台的支持和符合最新的 Java 标准，提供了开发电子商务应用的可靠平台。

WebSphere 安装简单易行。对 WebSphere 服务器及它运行的应用的控制是在WebSphere 高级管理控制台中执行的。由于 WebSphere 可以运行多个服务器，因此，用户必须从控制台分别启动每一个服务器进程。如果必须重新引导系统的话，WebSphere 可以记住目前每个不同服务器的状态并自动地重新启动运行的服务器。IBM 提供了像 WebSphereStudio 和 VisualAgeforJava 这类专为开发基于 Java 应用而设计的其他产品。WebSphere 的高级版和企业版在发送时附带了 IBM 的 DB2 数据库产品和 SecureWay 轻型目录访问协议服务器。企业版包括用于连接到外部数据库、CICS、IMS 或MQSeries 应用的一个构件代理应用适配器。

3．SUN iPlanet
作为 SUN 与 Netscape 联盟产物的 iPlanet 公司生产的 iPlanet 应用服务器满足最新J2EE 规范的要求，并通过了全套 J2EE 证书测试套件的测试。iPlanet 应用服务器的基本核心服务包括事务监控器、多负载平衡选项、对集群和故障转移全面的支持、集成的 XML 解析器和可扩展格式底稿语言转换（XLST）引擎，以及对国际化的全面支持。包括 Directory Server、Web Server 和用于 EAI（Enterprise Application Integration，企业应用集成）的另一些附件在内的其他 iPlanet 产品之间实现了紧密的集成。IPlanet Application Deployment 工具是基于 Java 的程序，它可以指导用户完成一个应用的部署过程。iAS 提供了一款与 WebGainStudio、InspireJBuilder、IBMVisualAge 及 Java企业版的 SUNForte 这类第三方工具集成在一起的独立产品 iPlanet Application Builder。

4．Oracle Internet ApplicationServer
毫无疑问，Oracle 公司的数据库产品是多种平台上的市场领先产品，凭借这种得天独厚的优势，Oracle 的 Internet Application Server（iAS）与其余 Oracle 产品实现了相互集成，例如，可以利用 Oracle iAS 向 Web 部署任何基于 OracleForms 应用的 Oracle Forms Service。

Oracle 利用一些扩展的 ApacheWeb Server 作为进入 Oracle iAS 的入口点。iAS 管理器是配置和管理应用的工具，提供了综合操作各种系统管理功能的统一界面。Oracle 为Apache 开发了插件盒模块来处理 Java 应用程序、Perl 程序、PL/SQL 程序及 SSL 上的安全网页。插件盒模块是一个共享库，可以实现程序逻辑访问。插件盒模块中可运行一个或多个插件盒实例，包括 PL/SQL 插件盒、Jweb 插件盒、LiveHTML 插件盒、Perl 插件盒、C 插件盒、ODBC 插件盒等。

iAS 允许开发基于 CORBA 对象的应用，通信协议采用 IIOP。iAS 支持以下两种应用模式：CORBA 应用和 EJB 应用。这两种模式都允许不同的 CORBA 客户访问。iAS 企业版配置了 Oracle Portal。Oracle Portal 提供了部署企业信息用户所需的工具。 Oracle iAS 是该公司将应用推向 Web 战略的关键组成部分。Oracle 的客户可以比较容易地将他们的 Oracle Forms 和 Oracle Reports 放到 Web 上运行。但是，Oracle iAS 价格也
比较昂贵。

5．Sybase Enterprise ApplicationServer
Sybase Enterprise Application Serve （ rEAServer ） 将 Sybase 的 JaguarCTS 和PowerDynamo 紧密集成并加以发展，是同时实现 Web 联机事务处理（WebOLTP）和动态信息发布的企业级应用服务器平台。它对各种工业标准提供广泛的支持，符合基于构件的多层架构，是支持所有主要构件模型的应用服务器产品，并且在它的最新版本中加强了对PowerBuilder 构件和 EJB 的深层支持。这样，用户可以运用它提供的灵活的开发能力，充分利用多样化的计算环境，建立更加高效的企业 Web 应用系统。

EAServer 支持多种构件模型，同一应用中可以结合使用各种构件，支持标准脚本语言和任意客户类型，集成了 PowerSite 开发环境，使 Web 应用开发和提交方便快捷。除了优良的性能之外，EAServer 还支持多种数据库访问方式，给用户提供了可靠的安全性。

15.3 J2EE
J2EE 是针对 Web Service、业务对象、数据访问和消息报传送的一组规范。这组应用编程接口确定了 Web 应用与驻留它们的服务器之间的通信方式。J2EE 注重两件事，一是建立标准，使 Web 应用的部署与服务器无关；二是使服务器能控制构件的生命周期和其他资源，以便能够处理扩展、并发、事务处理管理和安全性问题。

J2EE 规范定义了以下几种构件：应用客户端构件、EJB 构件、Servlets 和 JSP、Applet 构件。J2EE 采用的是多层分布式应用模型，意味着应用逻辑将根据功能分成几个部分， 用户可以在相同或不同的服务器上安装不同应用构件组成的 J2EE 应用。这些层次可以参 见图15-2。

15.3.1 表示层

J2EE 客户端可以基于 Web，也可以基于 Java。在 HTML、Javascript、XML 等技术的帮助下，Web 浏览器可以支持强大、快速的用户界面。实际上，如果 HTML 足以捕获和显示应用所需的信息，则 HTML 为首选；如果 HTML 不足以达到此目的，则应该由客户端执行必要的捕获和操作。无论是 Applet 还是独立的 Java 程序，都可提供更丰富的图形用户界面。Applet 还可以与中层通信，从而进一步加强程序控制和系统灵活性。分布式企业应用可以同时包括多种客户端，并且这些客户端都可以访问相同的业务逻辑。

如图 15-3 所示：当客户端是 HTML 时，JSP/Servlet 组合将成为能实现业务目标的真正客户端。当客户端是 Java 程序或基于 COM 程序时，它可以直接访问业务逻辑

15.3.2 应用服务层

一般情况下，应用服务层包含表示层请求的表示逻辑和业务逻辑。表示层由显示 HTML 页面的 JSP 页面和 Servlets 实现。业务逻辑通过 RMI 对象和 EJB 实现。EJB 依靠容器来实现事务处理、生命周期和状态管理、资源池、安全等问题，容器是 EJB 运行的环境。

1．Servlet
Java Servlets 是指可以扩展 Web 服务器功能的程序。Servlet 从客户端接受请求，动态生成响应，然后将包含 HTML 或 XML 文档的请求发送给客户端。Servlet 类似于 CGI（公共网关接口），但 Servlet 使用 Java 类和流，更易于编写；由于 Servlet 可编译为 Java 字节码，在运行时，Servlet 例程驻留在内存中，每一个用户请求都生成一条新线程，故而它们的执行速度也更快。

2．JSP
JSP 页面是基于文本的 Servlet 开发方式。JSP 页面具有 Servlet 的所有优点，如果与JavaBeans 类结合在一起，可以容易地将内容和显示逻辑分开。这使得无须了解 Java 代码就能更新页面的外观，更新 Java Beans 类的人也无须深入了解 Web 页面的设计。相对 CGI 而言，由于 CGI 依赖于平台，消耗资源更多，而且程序不能容易地访问参数数据等缺点，故而 JSP 页面和 Servlet 都比 CGI 应用广泛。 用户可以使用带 Java Beans 类的 JSP 页面定义 Web 模板，以便建立由外观相似的页面组成的 Web 站点，而 Java Beans 类负责组织数据。用户还可以借助标记和脚本将内容与应用逻辑捆绑在一起，或是嵌入一些 Java 小应用程序来实现一些简单的 Web 应用。

3．EJB
EJB 构件用于封装业务逻辑，使开发人员无须再担心数据访问、事务处理支持、安全性、高速缓存和迸发等琐碎任务的编程。在 EJB 规范中，它们由 EJB 容器负责。EJB 包含接口和类。客户端通过 EJB 的本地接口和远程接口访问 EJB 方法。本地接口提供的方法可用于生成、删除和查找 EJB，远程接口则提供业务方法。部署时，容器从这些接口生成类，这些类使客户端可以访问、生成、删除、查找和调用 EJB 上的业务方法。EJB 类为业务方法、生成方法和查找方法提供实施，如果 Bean 管理自己的存储，还得提供生成生命周期方法的实施。

EJB 共有三种类型：EntityBean（实体 Bean）、Session Bean（会话 Bean）和 Message Driven Bean（消息驱动 Bean），下面分别说明。

（1）实体 Bean。实体 Bean 表示数据库中的数据及作用于数据的方法。在关系型数据库中，表中的每一行就是一个 Bean 的实例。实体 Bean 是具有持久性的事务处理型 EJB，只要数据存在于数据库中，实体 Bean 就存在。

用容器管理的持久性访问关系数据库的 EJB，不需要为数据库访问使用任何 JDBC API，因为容器可以负责完成这项任务。但是，如果使用 Bean 管理的持久性或想访问关系数据库以外的企业信息系统，就需要提供相应的程序代码才能完成。但是如果 EJB 使用 Bean 管理的持久性访问数据库，用户必须借助于 JDBC API 实施 Bean 生命周期方法，这样才能加载和保存数据，并保持运行和持久数据库存储之间的一致性。

（2）会话 Bean。会话 Bean 代表与客户间的短暂对话。在执行数据库读写时，会话Bean 可以请求 JDBC 调用，也可以使用实体 Bean 执行调用，这时会话 Bean 是实体 Bean 的客户端。会话 Bean 的字段中包含对话的状态，如果服务器或客户端出现故障，会话 Bean 将消失。

会话 Bean 可以有状态，也可以无状态。有状态会话 Bean 包含客户端方的对话状态，对话状态是会话 Bean 实例的字段值加上可以从会话 Bean 字段阅读的所有对象。有状态的会话 Bean 不表示持久数据库中的数据，但能够以客户端的名义访问和更新数据。 无状态会话 Bean 没有客户端的任何状态信息。它们一般不提供保留任何状态的服务器行为。无状态会话 Bean 需要的系统资源较少。提供通用服务或表示共享数据视图的业务对
象适合作为无状态的会话 Bean。

（3）消息驱动 Bean。EJB2.0 规范中的消息驱动 Bean 能处理从 JMS 消息队列接收到的异步消息。JMS 将消息路由到消息驱动 Bean，由消息驱动 Bean 从池中选择某个实例处理消息。

消息驱动 Bean 在 EJB 容器中管理。由于它们不是由用户的应用直接调用的，因此不能借助 EJB 本地接口从应用进行访问。但是，用户的应用可以将消息发送到 Bean 所监听的 JMS 队列中，以此来实例化消息驱动 Bean。

4．JMS
JMS 是支持 Java 程序之间信息交换的 J2EE 机制。这也是 Java 支持异步通信的方法—— 发送者和接收者无须相互了解，因此可以独立操作。JMS 支持两种消息传播模式：点到点（point to point）。基于消息队列，消息产生者将消息发送到队列中。消息消费者可以将自身与队列连接，以倾听消息。当消息到达队列时，客户可以从队列中取走，并给出响应。消息只能发送到一个队列，只能由一个消费者使用。消费者可以过滤消息，以便获得希望获得的消息。

出版和订阅（publish/subscribe）。消息生产者将消息发送到一个话题（topic），注册到此话题的消费者都能接收到这些消息。这种情况下，许多消费者都能接收到同样的消息。

5．JNDI
由于 J2EE 应用的构件可以独立运行，而且是在不同的设备上运行，因此客户端和应用服务器层代码必须以某种方式查找和参考其他代码和资源。客户端和应用代码使用 JNDI（Java Naming and Directory Interface，Java 命名和目录接口）查找用户定义对象（如 EJB）和环境实体（Environment Entities）。在 JDBC2.0 中，数据源可以绑定到 JNDI 上，并允许应用程序访问。

6．事务处理
J2EE 事务处理模型可以在部署过程中定义组成一个事务处理的方法之间的联系，以便事务处理中的所有方法可以作为一个整体存在。如果用户希望完成这一任务，因为事务处理是一系列步骤，要么全部执行成功，要么全部回滚。例如，EJB 中可能有一系列方法，其作用是将资金从一个账户转到另一个账户，方法是借记第一个账户和贷记第二个账户。用户可能希望将全部操作作为一个整体，这样，如果借记之后，贷记之前出现故障，借记将滚回。

事务处理的属性在应用构件的集成过程中确定。它可以将各种方法组合成应用构件间的事务处理，即用户可以在 J2EE 应用中方便地重新分配应用构件的事务处理属性，无须修改代码和重新编译。J2EE 事务处理 API（JTA）和 Java 事务处理服务（JTS）形成 J2EE 中事务处理支持的基础，而且更适合 EJB 和 JDBC2.0。JTS 是低级事务处理管理 API，主要作用是将 Java 映射到对象管理组（OMG）的对象事务处理服务。JTA 是高级 API，包括两个部分：

事务处理接口。该接口允许事务处理定界，通过分布式构件由进行全局事务处理登记来完成工作。这种方法可以令多组操作组成一个事务处理。

XA 资源接口。基于能处理分布式事务处理的 X/Open/XA 接口，有时也称为两步提交事务处理，需要多种资源之间的协调，如数据库或序列。分布式事务处理由两步提交协议协调，可跨越用 XA 兼容的 JDBC 驱动程序访问的多个数据库，如针对 Oracle/XA 的 BEA WebLogicDriver 等。

EJB 规范定义了 Bean 管理的事务处理和 Container 管理的事务处理。当 EJB 用Container 管理的事务处理部署时，应用服务器将自动协调事务处理。如果 EJB 由 Bean 管理事务处理部署，EJB 参数必须提供事务处理代码。

基于 JMS 或 JDBC API 的应用代码可以启动事务处理，或参与先前启动的事务处理。一个事务处理联系与执行应用的应用服务器线程相关，所有事务处理操作都在参与当前事务处理的线程上执行。

多数情况下，用户无须担心用 JTA 编写明确事务处理的问题，因为此项工作由 JDBC 完成，EJB API 由 Container 处理，并由应用部署说明符配置。这样，用户就可以将精力集中在事务处理设计而非实施上。

15.4 .NET

Microsoft.NET 战略基于一组开放的互联网协议，推出了一系列的产品、技术和服务，吹响了互联网技术变革的号角。关于.NET，微软公司 CEO 鲍尔默这样描述：“Microsoft.NET 代表了一个集合、一个环境、一个可以作为平台支持下一代 Internet 的可编程结构。”这句话简单扼要地概括了.NET 的外部特性。

15.4.1 .NET 平台

.NET 首先是一个环境。这是一个理想化的未来互联网环境，微软的构想是一个“不再关注单个网站、单个设备与 Internet 相连的网络环境，而是要让所有的计算机群、相关设备和服务商协同工作”的网络计算环境。简而言之，互联网提供的服务，要能够完成更高程度的自动化处理。未来的互联网，应该以一个整体服务的形式展现在最终用户面前，用户只需要知道自己想要什么，而不需要一步步地在网上搜索、操作来达到自己的目的。

而要搭建这样一种互联网环境，首先需要解决的问题是针对现有 Internet 的缺陷来设计和创造一种新一代 Internet 结构。这种结构不是物理网络层次上的拓扑结构，而是面向软件和应用层次的一种有别于浏览器只能静态浏览的可编程 Internet 软件结构。因此.NET把自己定位为可以作为平台支持下一代 Internet 的可编程结构。

.NET 的最终目的就是让用户在任何地方、任何时间，以及利用任何设备都能访问他们所需要的信息、文件和程序。而用户不需要知道这些东西存在于什么地方，甚至连如何获得等具体细节都不需要知道。他们只需发出请求，然后只负责接收即可，而所有后台的复杂性是完全屏蔽起来的。故而，对于企业的 IT 人员来说，工作量将大大减少，他们也不需要管理复杂的平台及了解各种分布应用之间的工作是如何协调的。

.NET 包括 4 个重要特点：一是软件变服务，二是基于 XML 的共同语言，三是融合多种设备和平台，四是新一代的人机界面。这 4 个特点基本上覆盖了.NET 的技术特征。

（1）软件变服务。鲍尔默在谈到软件服务时说道：“今天的软件产品仅仅是一张光盘，用户购买软件，亲自安装、管理和维护。但是软件服务是来自 Internet 的服务，它替用户 安装、更新和跟踪这些软件，并让它们和用户一同在不同的机器间漫游。它为用户存储自 己的信息和参考资料。这些就是软件和软件服务各自不同的风格。”这段话概括了软件变服务的核心。

伴随着 ASP（应用服务提供）产业的兴起，软件正逐渐从产品形式向服务形式转化，这是 IT 行业的整体趋势。在.NET 中，最终的软件应用是以 Web 服务的形式出现并在Internet 发布的。Web 服务是一种包装后的、可以在 Web 上发布的构件，.NET 通过 WSDL 协议来描述和发布这种 Web 服务信息，通过 DISCO 协议来查找相关的服务，通过 SOAP 协议进行相关的简单对象的传递和调用。

如图 15-4 所示，.NET 平台中 Orchestration 可视化编程工具用于产生基于 XML 的XLANG 代码，它和 BizTalk 服务器、.NET 框架，以及 VisualStudio.NET 都曾是 Windows DNA 2000 战略的重要部分。

微软的.NET 战略意味着：微软公司及在微软平台上的开发者将会制造服务，而不是制造软件。在未来几年之内，微软将陆续发布有关.NET 的平台和工具，在 Internet 上开发 Web 服务。那时，工作在.NET 上的用户、开发人员和 IT 工作人员都不再购买软件、安装软件和维护软件。取而代之的是，他们将定制服务，软件会自动安装，所有的维护和升级也会通过互联网进行。

（2）基于 XML 的共同语言。XML 是从 SGML 语言演化而来的一种标记语言。作为元语言，它可以定义不同种类应用的数据交换语言。在.NET 架构中，XML 作为一种应用间无缝接合的手段，用于多种应用之间的数据采集与合并，用于不同应用之间的互操作和协同工作。具体而言，.NET 通过 XML 语言定义了简单对象访问协议（Simple Object Access Protocol，SOAP）、Web 服务描述语言（Web Services Description Language，WSDL）、Web 服务发现协议。SOAP 协议提供了在无中心分布环境中使用 XML 交换结构化有类型数据的简单轻量的机制。WSDL 协议定义了服务描述文档的结构，如类型、消息、端口类型、端口和服务本身。Web 服务发现协议定义了如何从资源或者资源集合中提取服务描述文档、相关服务发现算法等。

（3）融合多种设备和平台。随着 Internet 逐渐成为一个信息和数据的中心，各种设备和服务已经或正在接入和融入 Internet，并试图成为其中的一部分。.NET 谋求与各种Internet 接入设备和平台的一体化，主要关注在无线设备和家庭网络设备及相关软件、平台方面。

（4）新一代的人机界面。新一代人机界面主要体现在“智能与互动”两个方面。.NET 包括通过自然语音、视觉、手写等多种模式的输入和表现方法；基于 XML 的可编辑复合信息架构——通用画布；个性化的信息代理服务；使机器能够更好地进行自动处理的智能标记等技术。

.NET 的平台及框架是基于微软软件工业基础的又一次升级和演化。然而，.NET 还是要尽力保证 Windows 系统及系列产品和.NET 能够融为一体，尽量在微软公司原有的软件资产基础上，使.NET 继续成为 Internet 的中心。

15.4.2 .NET 框架

Microsoft.NET 开发框架如图 15-5 所示。通用语言运行时及它所提供的一组基础类库是整个开发框架的基础；在开发技术方面，.NET 提供了全新的数据库访问技术 ADO.NET，以及网络应用开发技术 ASP.NET 和 Windows 编程技术 WinForms；在开发语言方面，.NET 提供了 VB、VC++、C#等多种语言支持；而 VisualStudio.NET 则是全面支持.NET 的开发工具。

1．通用语言运行时
Microsoft.NET 给开发人员带来了一种全新的开发框架，而通用语言运行时（Common Language Runtime，CLR）则处于这个框架的最底层，是这个框架的基础。读者也许对于所谓的 C 运行时、VB 运行时、Jave 虚拟机这些概念已经有所了解，而通用语言运行时则为多种语言提供了一种统一的运行环境。另外，它还提供了更多的功能和特性，例如，统一和简化的编程模型，用户不必迷惑于 Win32API 和 COM；避免了 DLL 的版本和更新问题，从而大大简化了应用程序的发布和升级；多种语言之间的交互，例如，甚至可以在 VB 中使用C++编写的类；自动的内存和资源管理等。Microsoft.NET 正是基于通用语言运行时，实现了这些开发人员梦寐以求的功能。

基于通用语言运行时开发的代码称为受控代码，它的运行步骤大体如下：首先使用一种通用语言运行时支持的编程语言编写源代码，然后使用针对通用语言运行时的编译器生成独立于机器的微软中间语言（Microsoft Intermediate Language，MIL），同时产生运行所需的元数据，在代码运行时再使用即时编译器（Just In Time Compiler，JITC）生成相应的机器代码来执行。

2．基础类库
当然对于开发者而言，他们除了关心通用语言运行时提供的那些新特性外，还关心它究竟给开发者提供了什么样的编程接口，这就是基础类库（Base Class Library）。这组基础类库包括了从输入输出到数据访问等各方面，提供了一个统一的面向对象的、层次化的、可扩展的编程接口。它使用一种点号分隔的方法，使得查找和使用类库非常容易。例如基础类库中的根，它的命名空间是 System，提供数据访问的类库的命名空间是 System.Data。在使用时，开发者只需在自己的应用中添加所需的基础类库的引用，然后就可以使用这个类库中的所有方法、属性等。跟传统的 Windows 编程相比，使用和扩展基础类库都非常容易，这使得开发者能够高效、快速地构建基于下一代互联网的网络应用。

3．ADO.NET
几乎所有的应用程序都需要访问从简单的文本文件到大型的关系型数据库等各种不同
类型的数据。在 Microsoft.NET 中访问数据库的技术是 ADO.NET。ADO.NET 提供了一组用
来连接到数据库、运行命令、返回记录集的类库，与从前的 ADO（ActiveX Data Object）相
比，Connection 和 Command 对象很类似，而 ADO.NET 的革新主要体现在如下几个方面：
首先,ADO.NET 提供了对 XML 的强大支持，这也是 ADO.NET 的一个主要设计目标。在
ADO.NET 中通过 XMLReader，XMLWriter，XMLNavigator，XMLDocument 等可以方便地创建
和使用 XML 数据，并且支持 W3C 的 XSLT、DTD、XDR 等标准。ADO.NET 对 XML 的支持也
为 XML 成为 Microsoft.NET 中数据交换的统一格式提供了基础。
其次，ADO.NET 引入了 DataSet 的概念，这是一个驻于内存的数据缓冲区，它提供了
数据的关系型视图。不管数据来源于一个关系型的数据库，还是来源于一个 XML 文档，人
们都可以用一个统一的编程模型来创建和使用它。它替代了原有的 Recordset 的对象，提高
了程序的交互性和可扩展性，尤其适合于分布式的应用场合。
另外，ADO.NET 中还引入了一些新的对象，例如 DataReader 可以用来高效率地读取数
据，产生一个只读的记录集等。简而言之，ADO.NET 通过一系列新的对象和编程模型，并
与 XML 紧密结合，使得在 Microsoft.NET 中的数据操作十分方便和高效。
4．ASP.NET
ASP.NET 是 Microsoft.NET 中的网络编程结构，它使得建造、运行和发布网络应用非常
方便和高效。可以从以下几个方面来了解 ASP.NET：
（1）Web 表单。ASP.NET WEB 表单的设计目的就是使开发者能够非常容易地创建 Web
表单，它把 VB 中的快速开发模型引入网络开发中，从而大大简化了网络应用的开发。具
体来说：在 ASP.NET 中可以支持多种语言，不仅仅支持脚本语言，通用语言运行时支持的
所有语言在 ASP.NET 中都可以使用；代码和内容分开，在现在的 ASP（Active Server Pages）
开发中，内容和脚本交错，维护和升级很困难，将它们分开可以使得开发人员和设计人员能
够更好地分工合作，提高开发效率；另外在 ASP.NET 中通过引入服务器端控件，将类似 VB
的快速开发应用到了网络开发中来，这样大大提高了构建网络表单效率，并且服务器端控件
是可扩展的，开发者可以建造自己需要的服务器端控件。
（2）ASP.NET Web 服务。Web 服务是下一代可编程网络的核心，它实际上就是一个可
命名的网络资源，可用来在 Internet 范围内方便表现和使用对象，就像使用今天的 COM 对
象一样，不同的是使用和表现网络服务是通过 SOAP 甚至 HTTP 来实现的。在 ASP.NET 中，
建造和使用网络服务都非常方便。
在 ASP.NET 中建造网络服务就是编写一个后缀为.ASMX 的文件，在这个文件中加入想
要表现出来的方法即可，网络服务的建造者不需要了解 SOAP，XML 的细节，只需要把精力
集中在自己的服务本身，这也为独立软件服务开发商提供了很好的机会；使用网络服务最简
单的方式就是使用 HTTP 协议（HTTPGET 或 HTTPPOST），用户只需要直接访问网络服务
（.ASMX 文件）的 URL 即可；当然用户还可以通过 SOAP 在自己的应用中更灵活地使用网
络服务。
（3）ASP.NET 应用框架。ASP.NET 应用不再是解释脚本，而是编译运行，再加上灵活
的缓冲技术，使其性能从根本上得到了提高；由于 ASP.NET 的应用框架基于通用语言运行
时，故而发布一个网络应用，仅仅是一个复制文件的过程，即使是构件的发布也是如此，更
新和删除网络应用，可以直接替换/删除文件；开发者可以将应用的配置信息存放到 XML 格
式的文件中，管理员和开发者对应用程序的管理可以分开进行；提供了更多样的认证和安全
管理方式；在可靠性等多方面都有很大提高。
5．WinForms
传统的基于 Windows 的应用（WinForms），它仍然是 Microsoft.NET 战略中不可或缺
的一部分。在 Microsoft.NET 中开发传统的基于 Windows 的应用程序时，除了可以利用现
有的技术例如 ActiveX 控件及丰富的 Windows 接口外，还可以基于通用语言运行时开发，
可以使用 ADO.NET、网络服务等，这样也可以实现诸如避免 DLL 地狱、多语言支持等.NET 的
新特性。
6．开发语言
从上面的介绍中，已经知道 Microsoft.NET 开发框架支持多种语言，在目前的测试版中已经支持 VB，C++，C#和 Jscript 四种语言及它们之间的深层次交互。而且微软支持第三方生产针对 Microsoft.NET 的编译器和开发工具，这也就是说几乎所有市场上的编程语言都有可能应用于 Microsoft.NET 开发框架。这样开发者可以任意选择自己喜爱的语言，这种开放和交互的特性正是开发者所热爱的。

需要特别指出的是，微软在 Microsoft.NET 中推出了全新的 C#语言，这种全新的面向对象的语言使得开发者可以快速地构建从底层系统级到高层商业构件的不同应用。C#在保证了强大的功能和灵活性的同时，给 C 和 C++带来了类似于 VB 的快速开发，并且它还针对.NET 做了特别设计，例如，C#允许 XML 数据直接映射为它的数据类型等，这些特性结合起来使得 C#成为优秀的下一代网络编程语言。

与此同时，Microsoft.NET 对原有的 VB 和 C++也做了很大的改进，使得它们更加适应Microsoft.NET 开发框架的需求。例如在 VisualBasic.NET 中增加了继承等面向对象的特性，结构化的出错处理等；可管理的 C++扩展，大大提高了利用 C++来开发 Microsoft.NET 应用的效率等。

Visual Studio.NET 和.NET 开发框架紧密结合，是构建互联网应用的优秀工具。VisualStudio.NET 通过提供一个统一的集成开发环境及工具，大大提高了开发者的效率；集成了多种语言支持；简化了服务器端的开发；提供了高效地创建和使用网络服务的方法等。.NET 框架的一个主要目的是使 COM 开发变得更加容易。COM 开发过程中最难的是COM 基本结构的处理。因此，为了简化 COM 开发，.NET 框架实际上已自动处理了所有在
开发人员看来是与 COM 紧密相关的任务，包括引用计算、接口描述及注册。必须认识到，这并不意味着.NET 框架构件不是 COM 构件。事实上，使用 VisualStudio 6.0 的 COM 开发人员可以调用.NET 框架构件，并且在他们看来，后者更像是拥有 iUnknown 数据的 COM 构件。相反，使用 VisualStudio.NET 的.NET 框架开发人员则将 COM 构件视作.NET 框架构件。

为了避免引起误解，这里需对这种关系加以特别说明：COM 开发人员必须手动去做大多数.NET 框架开发人员可以在运行时自动执行的事情。例如，必须手写 COM 构件的安全性模块，且无法自动管理模块占用的内存，而在安装 COM 构件时，注册条目必须放进Windows 注册表中。对.NET 框架而言，运行时实现了这些功能的自动化。例如，构件本身是自我描述型的，因而无须注册到 Windows 注册表中便能安装。

当把 COM 与 Microsoft 事务服务器（MTS）和分布式 COM（DCOM）结合在一起时，就变成了 COM+。COM+提供了一组面向中间层的服务。特别是 COM+提供了进程管理功能和数据库与对象连接池处理功能。在将来的版本中，它还将提供一种称为分区的功能——专门为应用程序服务提供商设计的更强大的进程隔离功能。COM+服务主要面向中间层应用程序开发，并主要为大型分布式应用程序提供可靠性和可扩展性。这些服务是对.NET 框架所提供服务的补充；通过.NET 框架类，可以直接访问这些服务。

7．其他特征
.NET 框架有几个要素值得一提。首先是它的安全系统和配置系统。这两个系统协同工作，有力地遏止了运行不安全代码的可能性，并大幅度减少了“DLL 地狱”对应用程序进行配置时所面临的挑战。

安全系统是一个高度细化、基于事实的系统，它赋予开发人员和管理员多种代码处理权限（而不仅仅是“on”或“off”）。将来，还会根据代码本身的核心要素来决定如何实施上述权限。

例如，当.NET 框架应用程序被下载到某一系统中时，它会申请一组权限（诸如对临时目录的写入权限）。运行时将收集有关应用程序的事实信息（诸如：它是从何处下载的、是否用了有效签名、甚至它访问系统的准确程度），并按管理策略决定是否允许应用程序运行。运行时甚至还可告之应用程序它无法授权申请的所有权限，并允许应用程序自行决定是否继续运行。

有这种安全系统做保障，许多应用程序配置问题便会迎刃而解。开发人员和管理员（最终是用户）所面临的最大挑战之一是版本的管理问题。如果在新装了某个应用程序之后，一切都陷于瘫痪状态，而在这之前系统一直运行得非常良好，那么最大的可能就是新安装的应用程序重写了一些共享库，并极有可能修正了现有应用程序正使用的程序错误。这种情况出现的频率很高，以致人们将它称为“DLL 地狱”。

.NET 框架拥有的几项高级功能可以彻底消除“DLL 地狱”现象。首先，它有一个非常强大的内部命名系统，能够有效地防止两个库因互相重名而被错当为对方的情况发生。除此之外，它还提供一项被称作“并行”配置的新功能。如果前例中新安装的应用程序确实重写了共享库，现有应用程序可对该库进行修复。等现有应用程序再次启动时，它会检查所有的共享文件。如果发现文件被更改，同时这些更改又是不兼容的，则它可以请求运行时提取一个它可以使用的版本。得益于强大的安全系统，运行时可以安全地执行该操作， 这样应用程序就完成了本身的修复工作。

总之，Microsoft.NET 开发框架在通用语言运行时的基础上，给开发者提供了完善的 基础类库、下一代的数据库访问技术 ADO.NET、网络开发技术 ASP.NET，开发者可以使 用多种语言及 VisualStudio.NET 来快速构建下一代的网络应用。随着相关的互联网标准及 技术的普及，可以预言将会有越来越多的开发者采用这种开发结构，并开发出丰富多样的下一代互联网应用。

15.5 企业应用集成

许多企业的信息系统在最初设计时没有考虑多个系统“协同工作”的需要。这主要是由于企业信息化建设者对信息系统由不熟悉到熟悉，从了解信息化的好处，到真正体会到好处需要一个长期的过程，这就客观上造成企业信息化建设缺乏一个整体规划，实际需要的时候才会想到。因而，企业的信息化往往是从单项业务系统开始的，不同系统的开发方式及对于开发规范的遵从程度都有所不同，这使得系统间存在很强的孤立性，再加上对企业外部的信息未予以足够的重视，致使各部门开发出的信息系统最终成为一个个信息孤岛，一个系统很难与其他系统交换信息。同时，大多数企业都有过去遗留下来的异构的系统、应用、商务流程及数据源构成的应用环境。应用环境的通信状况是混乱的，只有很少的接口文档，并且维护代价也非常昂贵。

据有关数据统计，一家典型的大型企业平均拥有 49 个应用系统，33%的 IT 预算是花在传统的集成上，而且普遍是通过“点对点”连接，如图 15-6 所示，众多的信息孤岛联系起来，以便让不同的系统之间交换信息。

EAI（Enterprise ApplicationIntegration，企业应用集成），可以在一定程度上帮助人们解决这一问题。EAI 是指通过将业务流程，应用软件、硬件和各种标准联合起来，对企业中完成不同业务功能的应用系统进行无缝集成，使它们像一个整体一样进行业务处理和信息共享，从而提高企业效率，为客户提供灵活的业务服务。

EAI 使人们可以从更高层次来看待企业内的信息资源，使新的信息和应用可以通过可插拔的方式和原有的资源在一个全新的信息集成共享平台上协同工作，共同发挥“1+1>2” 的集成效应。企业在借助 EAI 系统整合企业内部已有的各种信息系统的同时，也加速了数据的即时共享和提高了企业的信息反应能力。特别是，目前处在电子商务时代的企业不仅仅需要在企业内部系统之间进行集成，同时也需要对供应链中的不同环节进行集成。而 EAI 不仅是连接企业内应用的高效手段，它也是在企业之间建立信息沟通共享的一种科学而有效的方式，从而有效地降低供应链网络的整体拥有成本。

EAI 可以通过中间件技术来连接企业级各种应用，使异构应用系统之间能够相互“交流”与“协作”，如图 15-7 所示。通过 15.1 节的介绍，读者对中间件技术的特点有了一定的了解，这里就不再赘述。正因为这些特点，中间件技术能给企业带来的好处也就显而易见了。

首先，中间件产品对各种硬件平台、操作系统、网络数据库产品及客户端实现了兼容和开放。
其次，中间件保持了平台的透明性，使开发者不必考虑操作系统的问题。
第三，中间件实现了对交易的一致性和完整性的保护，提高了系统的可靠性。
第四，中间件产品可以缩短开发周期 50%～75%，从而大大地降低了开发成本，提高了工作效率。
EAI 包括的内容很复杂，涉及结构、硬件、软件及流程等企业系统的各个层面，根据 EAI 集成的深度来划分可以分为应用集成、业务过程集成、数据集成。

1．应用集成
应用层次的集成主要为两个以上的应用中的数据和函数提供接近实时的集成。在网络环境中的跨平台应用程序之间的应用到应用（Application to Application，A2A）的集成。它涵盖了普通的代码（COBOL，C++，Java）撰写、应用程序接口、远端过程调用、分布式中间件如 TP 监控、分布式对象、CORBA、RMI、面向消息的中间件及 Web 服务等各种技术。应用层次的集成一般来说是通过处理多个应用系统之间的消息交换，实现系统间的集成。各个应用能够处于同步模式，即基于客户（请求程序）和服务器（响应程序）之间的请求响应交互机制。应用系统能够自己处理消息的转换，并且它将影响被集成系统的数据转换和有效性。但是，这需要对系统进行修改以建立发送和接收消息的接口。

2．业务过程集成
业务过程集成需要处理企业范围内的业务过程和把企业存在的应用系统整合到这些业务过程中。它是一个完全的企业应用集成实现策略，因为它使企业内的一个个分离系统变成了一个支持业务过程的连续系统，从而满足企业的整个业务过程需求。

当对业务过程进行集成的时候，企业必须在各种业务系统中定义、授权和管理各种业务信息的交换，以便改进操作、减少成本、提高响应速度。业务过程集成包括业务管理、进程模拟，以及综合任务、流程、组织和进出信息的工作流，还包括业务处理中每一步都需要的工具。业务过程集成至少包括以下两种形式的流程。

（1）交互式流程。交互式流程包含了跨两个系统之间的事务处理。这种流程是完整的且不间断的，它不包含任何需要人为参与的工作和间断的流程。由于交互式流程通常是在两个系统之间流转的，它不需要特别复杂的 EAI 处理。

（2）多步流程。作为业务流程的一部分，许多单独的事务处理根据事先定义的顺序在两个或者多个系统之间流转，这就涉及工作流和业务流程重组。多步流程有一系列的步骤并同多个系统相关，能在一定的时间内完成。这种流程可以是一对多、多对一或者多对多的关系。

3．数据集成
要完成应用集成和业务过程集成，必须首先解决数据和数据库的集成问题。为了处理多个数据库之间的数据移动，很多企业把数据级 EAI 作为他们实施 EAI 的切入点。当应用系统必须分享信息时，这种集成可以支持不同数据库之间的数据交换。目前有很多支持数据级EAI 的工具，这使得数据级 EAI 实现起来相对容易，甚至不用修改应用系统的源程序。通行的做法就是将历史数据批量导入新系统中和现行系统中的批量、实时数据处理，也称数据同步。

随着数据仓库的建立，越来越多的数据同步工作能够采用批量的方式来处理。这样可以掌握更多的信息，例如客户类型、客户交易历史和客户习惯的购买、交货方式都能够每日或者每周更新一次。关键数据、新客户的数据和可用库存增加的需求都能够进行批量实时的更新。很多企业也在寻找方法来进行批量数据的集成，缓解日益增长的数据给数据同步带来的压力。

当然，更深层次的数据集成，需要首先对数据进行标识并编成目录，另外还要确定元数据模型。这三步完成后，数据才能在数据库系统中分布和共享。但是，目前数据集成解决方案中最普遍的方法发生在企业内的数据库和数据源级别，即通过从一个数据源将数据移植到另外一个数据源来完成数据集成。下面举出数据集成的一些例子：

将订单从 ERP 系统更新到 CRM（Customer Relationship Management，客户关系管理）系统中，以便销售人员能够实时了解订单的情况。从多个系统中同步和规范客户信息，使企业能够 360°全面审视客户。将运作数据实时地保存在系统中，客户和分销商能通过商业智能网络访问企业的库存和订单信息。

每天一次或者多次地将 ERP 中的数据导入 SCM（Supply Chain Management，供应链管理）系统中，将有助于企业制订物料需求计划。每天多次将运输的价格信息传输给各个下游分销商。

数据集成的一个最大的问题是商业逻辑常常只存在于主系统中，无法在数据库层次去响
应商业流程的处理，因此限制了实时处理的能力。 在企业内部，EAI 通过建立底层结构来联系横贯整个企业的异构系统、应用、数据源等，完成在企业内部的 ERP、CRM、SCM、数据库、数据仓库，以及其他重要的内部系统之间无缝地共享和交换数据的需要。而在电子商务时代，企业不仅需要在内部的应用系统之间进行集成，还需要对供应链中的不同企业系统进行集成，以帮助企业创建一条畅通于企业的各个部门以及它的供应商、承运商、分销商、零售商和顾客之间的信息流，从而进行有效的数据和业务集成。

特别是随着信息技的普及和企业各种应用的迅速增加，越来越多的企业开始采用 EAI 解决方案将企业内部的应用软件与外部客户和供应商的应用软件进行链接，实现数据流和业务运作的自动化，从而达到业务的实时与快速。好的企业应用集成解决方案可以实现对于未来业务的集成，维护和修改实现时间和成本的节约，从而提升企业的核心竞争力。

15.6 轻量级架构和重量级架构

MVC 模式是一种目前广泛流行的软件设计模式，随着 J2EE 的成熟，它正成为 J2EE 平台上推荐的一种设计模型，将业务处理与显示分离，将应用分为模型、视图及控制层，增加了应用的可扩展性。MVC 模式为搭建具有可伸缩性、灵活性、易维护性的 Web 系统提供了良好的机制。

J2EE 多层结构的出现促进了软件业的巨大改变，但是，J2EE 只是提出了一般意义上的框架设计，且其庞大的体系显得有些臃肿。轻量 级 Web 架构不仅保持了 J2EE 的优势，还简化了 Web 的开发。目前主流的轻量级架构是把 Struts、Spring 和 Hibernate 这三种在业内比较推崇的开源技术基于 MVC 模式相结合，这样在项目开发中不管是从效率上，费用上，还是易维护上都能达到很好的效果。下面将分别介绍这三种框架。

15.6.1 Struts 框架

Struts 是一个基于 SUN J2EE 平台的 MVC 框架，主要是采用 Servlet 和 JSP 技术来实现的。在 Struts 框架中，模型由实现业务逻辑的 JavaBean 或 EJB 构件构成，控制器由ActionServlet 和 Action 来实现，视图由一组 JSP 文件构成，如图 15-8 所示。

Struts 把 Servlet、JSP、自定义标签和信息资源整合到一个统一的框架中，开发人员利用其进行开发时不用自己再编码实现全套 MVC 模式，极大地节省了时间。

Struts 将业务数据、页面显示、动作处理进行分离，这有利于对各部分的维护。Struts 采用 Front Controller 模式来实现动作处理，使所有的动作请求都经过一个统一入口，然后进行分发。这方便了人们在入口中加入一些全局控制代码，如安全控制、日志管理、国际化编码等。通常情况下借助 Struts Validator 框架帮助完成 Web 层的验证工作，不用再去为每个 Web 页面写验证代码，只需通过配置即可实现。这也减少了开发量，由于验证代码的集中管理，也为维护带来便利。

Struts 的工作流程为：首先，JSPview 发起一个以.do 表示的请求；ActionForm 封装用户请求数据，同时提供验证数据的功能；ActionServlet 根据 struts-config.xml 文件来得到处理这个请求的 Action 对象，并将请求发送给这个 Action 对象；Action 对象调用 model 去处理这个请求，将结果返回给 ActionServlet；ActionServlet 决定将结果返回给对应的 view；view 得到结果，并将它显示给用户。这里需要提到的是，可以通过 Struts 提供的 ActionForm 封装 web form 中的元素，使重用 web 表单成为可能。

15.6.2 Spring 框架

Spring Framework 是由 Rod Johnson 创立的一个开放源码的应用框架。它是轻量级的J2EE 应用程序框架，旨在简化 J2EE 的开发，降低 J2EE 项目实施的难度。这个框架包括声明性事务管理，通过 RMI 或 web services 远程访问业务逻辑，mail 支持工具，以及对于数据和数据库之间持久层的各种配置的支持。Spring 允许自由选择和组装各部分功能，还提供和其他软件集成的接口，如与 Hibernate、Struts 的集成。

Spring 核心本身是个容器,管理物件的生命周期、物件的组态、相依注入等，并可以控制物件在创建时是以原型（Pro-totype）或单例子（Singleton）的方式来创立。Spring 的核心概念是控制反转（Inversionof Control，IoC），更具体而易懂的名词是依赖注入（Depen-dency Injection），使用 Spring，不必自己在程序码中维护物件的依赖关系，只需在构件中加以设定，Spring 核心容器会自动根据构件将依赖注入指定的物件。Spring 的目标是实现一个全方位的整合框架，在 Spring 框架下实现多个子框架的组合，这些子框架之间可以彼此独立，也可以使用其他的框架方案加以替代，Spring 成为企业级应用程序一站式的解决方案。其架构如图 15-9 所示。

Spring 模块构建在核心容器之上。核心容器定义了创建、配置和管理 bean 的方式。

Core 封装包的主要构件是 BeanFactory，它提供对 Factory 模式的经典实现来消除对程序性单例模式的需要，并真正地允许从程序逻辑中分离出依赖关系和配置。DAO 提供了 JDBC 的抽象层，它可消除冗长的 JDBC 编码和解析数据库厂商特有的错误
代码。并且，JDBC 封装包还提供了一种比编程性更好的声明性事务管理方法，不仅仅实现了特定接口，而且对所有的 POJOs（Plain Old Java Objects，普通的 Java 对象）都适用。 ORM 框架提供了对象关系映射工具，其中包括 JDO（Java Data Object，Java 持久对象）、Hibernate、Ibstis、JPA（Java Persistence API，Java 持久 API）。所有这些都遵从 Spring 的通
用事务和 DAO 异常层次结构。

Context（上下文）是一个配置文件。Spring 的上下文包括企业服务，例如，EJB、JNDI、Remodeling Mail、Validation。
Web 包提供了基础的针对 Web 开发的集成特性，例如多方文件上传，利用 Servlet listeners 进行 IoC 容器初始化和应用上下文。当与 Web 或 Struts 一起使用 Spring 时，这个包使 Spring 可与其他框架结合。

通过策略接口，MVC 框架变为高度可配置的，容纳了大量视图技术。Spring 的核心要点是支持不绑定到特定 J2EE 服务的可重用业务和数据访问对象。Spring 的 IoC 控件主要服务于利用类、对象和服务去组成一个企业级应用，通过规范的方式，将各种不同的控件整合成一个完整的应用。

15.6.3 Hibernate 框架

Hibernate 是一种对象和关系之间映射的框架，是 Java 应用和关系数据库之间的桥梁。它可以将数据库资源映射为一个或者多个 POJO。将面向数据库资源的各种业务操作以POLO 的属性和方法的形式实现，使人们摆脱烦琐的 JDBC 代码，将精力更多地集中在编写数据表示和业务逻辑上。Hibernate 的基本实现框架如图 15-10 所示。

Hibernate 是一个工具，而不是一个 J2EE 的服务器。可以在各种流行的服务器中使用Hibernate，利用 Hibernate 来作为持久化的处理技术，或者在桌面程序中直接利用Hibernate 来完成数据库操作，还可以基于 Hibernate 成熟的持久化技术框架来扩展平台软件的功能，例如基于 Hibernate 来完成对 EJB3.0 标准的实现。Hibernate 在支持集成方面提供了对 JMX 标准的支持，实现了封装 Hibernate 全部功能的 MBean 接口。Hibernate 的作用如图 15-11 所示。

在 Hibernate 中对象/关系映射机制的核心是一个 XML 文件，通常命名为*.hbm.xml。这个映射文件描述了数据库模式是怎么与一组 Java 类绑定在一起的。Hibernate 提供工具从已有的数据库模式和 Java 代码生成*.hbm.xml 文件。一旦有了*.hbm.xml 文件，就可以生成 Java 代码，或数据库模式，或者两者兼得。Hibernate 只是一个将持久化类与数据库表映射的工具，Hibernate 只需要将每个持久化实例对应于数据库表中的一个数据行即可。

15.6.4 基于 Struts、Spring 和 Hibernate 的轻量级架构

基于 Struts、Spring 和 Hibernate 框架，可以构造出 Web 轻量级架构。如图 15-12 所示，该系统逻辑上分成三层。

（1）表示层。由 Struts 实现，主要完成如下任务：管理用户请求和响应；提供一个控制器代理以调用业务逻辑和各层的处理；处理从其他层抛给 StrutsAction 的异常；为显示提供数据模型；借助 Struts Validator 框架帮助完成 Web 层的验证工作，通常情况下，不用再去为每个 Web 页面写验证代码，只需通过配置即可实现。Struts 里的控制器也就是ActionServlet 会解析核心配置文件 struts- config.xml。其中用户登录验证的配置文件如下：

<s truts -config>

<form-bean name="loginForm"type=“com.authorise.LoginForm”>
<form-property name=“name"type=“java.lang.String” />

<actionpath=”/login"name=“loginForm”
type=“com.authorise.LoginAction"scope=“reques t” input=”/Login.jsp"validate=“false”/>

</s truts -config>

（2）持久层。由 Hibernate 实现。它通过一个面向对象的查询语言（Hibernate Query Language，HQL）或正则表达式的 API 来检索对象的相关信息。HQL 类似于 SQL，只是把 SQL 里的表和列用对象和它的字段代替。Hibernate 还负责存储、更新、删除数据库记录。同时Hibernate 支持大部分主流数据库，且支持父表/子表关系、事务处理、继承和多态。

（3）业务层。由 Spring 来实现。使用 Spring 的优点是：利用延时注入思想组装代码，提高了系统扩展性和灵活性，实现插件式编程。利用 AOP 思想，集中处理业务逻辑，减少重复代码，构建了较理想的解决方案。利用其对 Hibernate 的会话工厂（Session Factory）、事务管理的封装，可以更简洁地应用 Hibernate。

15.6.5 轻量级架构和重量级架构的探讨

重量级的开发倒并不是指 EJB 或者是 JNDI，很大意义上，重量级的开发都是需要依赖一个非常庞大的容器系统进行开发，在 EJB 的开发中，所有开发的内容基本都需要放置在一个容器系统中进行运行这些容器因为基本针对大型企业应用，所以体积庞大，占用资源过多，在开发的过程中效率很低。因为使用大型容器作为开发环境的话，很大一部分时间都用在了配置、运行这样的过程上，有时候改动一个小小的部分，需要等很长的时间才能看到结果。如果做单元测试也比较麻烦，虽然现在有很多针对容器的单元测试框架，但是还是没有很好地解决配置的等待问题，所以在开发者这里，EJB 逐渐失去了吸引力，因为感觉实在是太笨重了。

轻量级框架的优势很大程度上是因为加速了开发的速度，不用部署一个很庞大的容器系统就可以实现以前需要容器才能实现的功能，可以使用 Spring 代替 EJB 中的无状态的会话Bean，可以使用 Hibernate 代替 EJB 中的实体 Bean，而且可以直接写一个应用程序运行已经完成的系统，马上可以看到结果，做单元测试非常简单，不需要做太多的工作就可以构建系统，这些特性对于开发人员来说非常有吸引力。

关于轻量级和重量级之间的论战已经由来已久了，最终也没有出现一个很好的结果，重量级框架在大规模运行的时候会表现出非常优异的性能，劣势主要是开发效率较低，轻量级框架正好相反，开发的时候非常迅速，但是在大规模运行的时候，性能与重量级框架相比还是有差异的。

但是随着最近一些框架标准的成熟，可以有新的选择，因为不管是轻量级还是重量级框架，基本解决的是两个问题，一个是事务控制，另一个是持久化控制，在 JPA 标准发布以后，看到一个很好的解决方式，持久化的开发可以和任何框架没有关系，直接使用 JPA 的标准注解即可，所以开发持久化部分的时候可以使用 JPA 进行注解，开发时期用 Hibernate 作为 JPA 的实现进行开发测试，需要上线运行的时候就可以直接部署到 EJB 的实体 Bean 上，在 EJB 3.0 之后，已经很好进行移植部署了。关于事务控制，现在所有的实现方式都比较简单，针对方法进行注解事务类型即可，开发的时候可以用一个转换器将这些注解转化为Spring 的映射，快速地进行开发，在上线运行的时候，直接使用 EJB 的会话 Bean 进行部署就可以解决，这些方式实现起来并不困难，可以很好地解决“重量级”和“轻量级”之间的矛盾。