|
| |
| Sun Java Enterprise System 2004Q2 技术概述 | |
第 2 章
Java Enterprise System 体系结构本章概述了 Java Enterprise System 部署所基于的体系结构概念。
章中描述了一个框架，在此框架内从三维角度对 Java Enterprise System 部署体系结构进行了分析，它们分别是：逻辑层、基础结构服务级别和服务质量。这三维在下图中以图解形式显示为正交坐标轴，它们有助于在体系结构上阐明 Java Enterprise System 组件的功能。此三维框架是为商业软件解决方案成功设计部署体系结构的关键。
图 2-1 Java Enterprise System 体系结构框架的三维
本章先分别单独探索了图 2-1 所示三维中的每一维，随后将这三维放到单个框架中进行了综合。本章包括下列各节：
第 1 维：逻辑层分布式应用程序的标准体系结构将应用程序逻辑分成了若干层。这些层表示各组件在由服务提供者和使用者组成的有序链条中的逻辑和物理组织结构。层中的组件通常会使用相邻提供者层中组件所提供的服务，并向相邻使用者层中的一个或多个组件提供服务。
下图说明了部署体系结构的逻辑层维。
图 2-2 第 1 维：分布式企业应用程序的逻辑层
逻辑层描述
本节简要描述了图 2-2 所示的四个逻辑层。为便于举例，在描述中引用了采用 Java 2 Platform, Enterprise Edition（J2EE™ 平台）组件模型实现的组件。但是，其他分布式组件模型（如 CORBA）也可支持此体系结构。
客户层
客户层由最终用户通过用户界面直接访问的应用程序逻辑组成。客户层中的逻辑可以包括基于浏览器的客户机、在台式计算机上运行的 Java 组件，或是在手持设备上运行的 Java 2 Platform, Micro Edition（J2ME™ 平台）移动客户机。
表示层
表示层由应用程序逻辑组成，应用程序逻辑负责准备要传送给客户层的数据以及处理来自客户层的请求以便传送给后端业务逻辑。表示层中的逻辑通常由 J2EE 组件组成，如 Java Servlet 组件或 JSP 组件，它们会为 HTML 或 XML 传送准备数据或接收请求以便进行处理。此层还可能包括门户服务，该服务可对业务服务层中的业务服务提供个性化、安全和定制的访问。
表示层组件通常是能够定制并插入到应用程序中的可重用组件。还可以复制表示服务以实现故障转移和可伸缩性，并且可以将这些服务映射到计算节点，从而优化网络带宽和计算资源。
业务服务层
业务服务层由执行应用程序主要功能的逻辑组成，这些功能有：处理数据、实现业务规则、协调多个用户以及管理诸如数据库或传统系统之类的外部资源。通常，此层由符合 J2EE 分布式组件模型的紧耦合组件组成，如 EJB 组件或消息驱动 Bean (MDB)。可将单个 J2EE 组件组合起来提供复杂的业务服务，如库存服务或计税服务。单个组件及服务组合体可以封装起来作为符合“简单对象访问协议”(SOAP) 接口标准的松耦合 Web 服务。也可将业务服务组建为独立的服务器，如企业日历服务器。
业务服务的各种实现封装了可在特别计算节点驻留并运行的特定应用程序功能。这种方法虑及了可以定制并插入到应用程序中的可重用组件。如同表示层逻辑一样，您可以复制这些业务服务提供者以实现故障转移和可伸缩性，并且可以将这些服务提供者映射到计算节点，从而优化网络带宽和计算资源。
数据层
数据层由业务逻辑使用的数据组成。这些数据可以是数据库管理系统中存储的持久性应用程序数据，也可以是“轻型目录访问协议”(LDAP) 数据仓中存储的资源和目录信息。这些数据还可以包括自外部源馈送而来的数据或可从传统计算系统中访问的数据。
逻辑和物理独立性
图 2-2 的表示及业务服务层中所示的服务是此模型的中心部分。这些服务是能够支持大量客户机的多线程软件进程。这些客户机既可以是最终用户客户机也可以是其他服务。
图 2-2 中说明的体系结构维强调了这四层的逻辑和物理独立性，便于在联网环境中的各种计算节点上划分应用程序逻辑：
分层体系结构示例
Messaging Server 所提供的电子邮件通信服务是逻辑层在体系结构设计中的使用方面的一个具体示例。电子邮件服务的实现使用了诸多 Messaging Server 组件，如下图所示。
图 2-3 Messaging Server：分层体系结构示例
在逻辑上将 Messaging Server 各功能分成独立的组件，这样可使这些组件得以分布在物理环境中的不同计算节点上。物理分离使得这些组件易于复制，使得不同组件可以具有不同的可用性解决方案，并且使得可以对不同组件采取不同的安全途径。
第 2 维：基础结构服务级别分布式企业应用程序的交互软件组件需要一组底层的基础结构服务，这些服务允许分布式组件相互通信、协调各自的工作、实现安全访问，等等。这组分布式服务构成了可在其上建立分布式组件的基础结构。
分布式基础结构服务
可将分布式基础结构服务概念化为处于许多不同级别的一组分布式服务。这些服务构成了部署体系结构的基础结构服务级别维，如下图所示。
图 2-4 第 2 维：分布式基础结构服务级别
图 2-4 中的各级别反映了各种分布式服务相互间的依赖性，从最低级别的操作系统服务一直到最高级别的应用程序和集成服务。每项服务一般都依赖于其下方的服务而支持其上方的服务。
但是，较高级别的服务可以不依靠中间级别直接与较低级别的服务进行交互。例如，某些运行时服务可能直接依赖于平台服务而无需两者间的任何服务级别。另外，没有对图 2-4 中表示的级别作出严格规定。还可在此概念图中加入其他服务级别，如监视或管理服务。
图 2-4 所示的服务一般可分为三大组：低级平台服务、高级应用程序服务以及一组中间件服务（因其位于其他两个分组之间而得名）。
下列各段落在有关地方引用 Java 编程语言人工产物简要介绍了这些不同的服务。各服务按从最低到最高的顺序逐个进行介绍，如图 2-4 所示：
- 操作系统平台。 为在计算节点上运行的任何进程提供基本支持。操作系统（如 Solaris™ 操作系统、Linux 或 Windows）管理着物理设备以及内存、线程和支持 Java 虚拟机（JVM™ 机）所需的其他资源。
- 网络传输。 为不同计算节点上运行的分布式应用程序组件间的通信提供基本联网支持。这些服务包括对诸如 TCP 和 HTTP 等协议的支持。其他较高级别的通信协议（参见“消息”层）依赖于这些基本传输服务。
- 持久性。 为访问和存储静态数据（如用户、目录或配置信息）及动态应用程序数据（经常更新的信息）提供支持。
- 消息传送。 为应用程序组件间的同步及异步通信提供支持。同步消息传送是实时消息收发；它包括 J2EE 组件间的远程方法调用 (RMI) 以及 SOAP 与 Web 服务的交互。异步消息传送是指这样的一种通信：消息的发送不依赖于使用者是否已准备好立即接收该消息。异步消息传送规范（例如，“Java 消息服务”(JMS) 和 ebXML）支持可靠性保障及其他消息传送语义。
- 运行时环境。 提供任何分布式组件模型（如 J2EE 或 CORBA 模型）所需的支持。除了紧耦合分布式组件所需的远程方法调用之外，运行时服务还包括组件状态（生命周期）管理、线程池管理、同步（互斥锁定）、持久性服务、分布式事务监视以及分布式异常处理。在 J2EE 环境中，这些运行时服务由应用程序服务器或 Web 服务器中的 EJB、Web 和消息驱动 Bean (MDB) 容器提供。
- 安全和策略。 为安全访问应用程序资源提供支持。这些服务包括对策略的支持，策略不仅支配着分布式资源的组或基于角色的访问而且还支配着单点登录能力。单点登录允许将通过了分布式系统中一项服务的用户验证自动应用于系统中的其他服务（J2EE 组件、业务服务和 Web 服务）。
- 用户协作。 提供在支持企业和 Internet 环境中的用户间直接通信和多用户相互协作方面起关键作用的服务。因而，这些服务是应用程序级业务服务，通常由独立的服务器（如电子邮件服务器或日历服务器）提供。
- 集成。 提供聚集现有业务服务的服务，聚集方式或者是为访问这些服务提供一个公共接口（如在门户中那样），或者是通过在生产工作流程内协调这些服务的处理引擎将它们集成在一起。集成也可在不同企业间的企业到企业交互时发生。
Java Enterprise System 实现
Java Enterprise System 实现了图 2-4 所示的分布式基础结构服务维。下图显示了 Java Enterprise System 组件在不同级别内的定位：
图 2-5 Java Enterprise System：分布式基础结构服务
图 2-5 所示分布式基础结构服务的 Java Enterprise System 实现由分立的软件服务器（系统服务器）组成，这些服务器分别在分布式基础结构服务栈中的各个不同级别上提供服务。这些服务提供者是能够支持大量客户机的多线程服务器进程。
注
有许多 Java Enterprise System 组件未出现在图 2-5 中，这是因为它们不直接提供分布式基础结构服务。然而，这些组件可提供下列支持功能：
- Portal Server Mobile Access 提供从无线客户机到 Portal Server 的访问。
- Portal Server Secure Remote Access 提供从企业防火墙外部基于浏览器的客户机到 Portal Server 的访问。
- Directory Proxy Server 提供从企业防火墙外部基于浏览器的客户机到 Directory Server 的访问。
- Sun Cluster 向基础结构服务提供高可用性，将在体系结构的服务质量维中对其进行讨论（参见示例：Sun Cluster）。
Java Enterprise System 服务器
Java Enterprise System 服务器共同实现了图 2-5 所示的全部级别。每种系统服务器都提供一项具体服务或一组服务以支持分布式企业应用程序。这些系统服务是每种服务器的独有特征（有关每种系统服务器所提供服务的简介，参见表 1-1）。
系统服务器间的依赖性
一般而言，每种系统服务器都依赖于基础结构中其下方的服务器并支持其上方的服务器。表 2-1 按图 2-5 所示顺序，从上至下显示了不同 Java Enterprise System 服务器间的特定依赖性。
系统服务器剖析
尽管每种 Java Enterprise System 服务器所提供的服务有所不同，但所有系统服务器享有一些共同特征。一般而言，每种系统服务器都会使用下列种类的软件组件或子组件：
下图以图解形式显示了这些子组件，并会在随后各节对其进行简要介绍。
图 2-6 Java Enterprise System 服务器剖析
系统服务子组件
表 1-1 总结了每种 Java Enterprise System 服务器所提供的主要系统服务。
每种服务器都用各自的方法实现了所提供的服务。一些服务器是用 Java 语言编写的，而另一些是用 C 或 C++ 编写的。一些服务器使用单个子组件实现其独特的系统服务，而另一些使用了若干子组件。例如，Portal Server 使用“重写器”、“桌面”和 NetMail 子组件来提供 Portal Server 的主要系统服务。
支持服务子组件
每种系统服务器都包含若干子组件，这些子组件提供了系统服务所依赖的各种支持服务。图 2-6 所示的支持服务是 Java Enterprise System 所提供的分布式基础结构服务的典型写照。例如：
在某些情况下，支持服务由其他 Java Enterprise System 服务器外部提供。但是，大多数情况下，支持服务都是在服务器内部实现的。Java Enterprise System 的目标是提取公共内部服务并将其作为系统级服务来实现，如日志记录器服务或通信服务等等。
共享组件
除了支持服务以外，大多数 Java Enterprise System 服务器还依赖于诸多本地服务，这些服务通常用来提供跨越不同操作系统的可移植性。这些服务是作为共享组件本地安装的库，在特定计算节点上运行的所有系统服务器都可以使用这些共享组件。Java Enterprise System 共享组件的例子有：Java 2 Platform, Standard Edition（J2SE™ 平台）、Netscape Portable Runtime (NSPR)、Network Security Services (NSS)、Network Security Services for Java (JSS)，等等。有关完整列表，参见共享组件。
第 3 维：服务质量前面的两个体系结构维（逻辑层和基础结构服务级别）主要定义了体系结构的逻辑层面，即需要哪些组件以何种交互方式将服务交付给最终用户。但是，对于任何已部署的解决方案，还有一维也同等重要，即解决方案满足服务质量要求的能力。
随着 Internet 和电子商务服务对企业运营变得愈发重要，这些服务的性能、可用性、安全性、可伸缩性和可维护性已成为大规模、高性能部署体系结构的关键要求。
换言之，满足与诸多重要服务质量有关的业务要求已成为部署体系结构的重要一维。下表总结了指定服务质量要求时最常用到的性质。
影响部署体系结构的各系统性质密切相关。对一项系统性质的要求可能会影响到其他系统性质的要求和设计。例如，提高安全性级别可能会影响到性能，而性能又会影响到可用性。靠另外增加服务器来应对可用性问题可能会影响到维护成本（可维护性）。
理解各系统性质的相互联系方式以及所要采取的折衷方案是设计满足业务要求和业务约束的体系结构的关键。
应用服务质量要求
对表 2-2 所示系统性质的服务质量要求通常是在系统范围层次上规定的，即它们会整体应用于系统。但是，软件系统的总体机能是系统中各种应用程序和基础结构组件之间复杂交互的结果。
因此，服务质量要求通常会应用于体系结构内所有基础结构服务级别上的所有层。这些要求经常以组件为基础应用到某个组件上。
例如，如果系统应具有高度可用性，则您需要考虑系统中最有可能发生故障的点，并首先关注那些最具影响力的故障。与使用率较低或不会引起全面系统故障的组件的高可用性解决方案相比，对此类高风险组件的高可用性解决方案的要求可能会更加苛刻。
在考虑性能、安全性和可伸缩性时也会产生类似的问题。要了解系统中潜在的弱点或瓶颈并将对系统中的每个组件均有意义的多种体系结构解决方案合为一体，必须进行大量的分析。
示例：Sun Cluster
有一个 Java Enterprise System 组件特别注重服务质量体系结构维，它就是：Sun Cluster。
Sun Cluster 软件可为 Java Enterprise System 以及基于 Java Enterprise System 基础结构的应用程序提供高可用性和可伸缩性服务。
群集是一组松耦合计算节点，该组节点共同提供了服务、系统资源和数据的单客户机视图。群集在内部使用了冗余计算节点、相互连接、数据存储和网络接口，以此来向基于群集的服务和数据提供高可用性。群集软件不停地监视成员节点及其他群集资源的运行状况，即使出现故障，它也会使用内部冗余对这些资源提供近乎连续的访问。
此外，群集代理还会不停地监视由群集主管的软件服务。万一出现故障，这些软件代理会采取行动执行故障转移或是重新启动所监视的服务。群集代理可供所有 Java Enterprise System 服务器使用，并且您可以为在 Java Enterprise System 基础结构之上运行的任何分布式组件或服务实现编写定制群集代理。这样，群集软件就为高度可用的服务作好准备了。（此可用性处于服务级别，不是为实现会话级别的故障转移而准备的。）
由于群集软件担负着控制职责，所以群集还可准备用于可伸缩服务。充分利用群集的全局文件系统以及群集中多个节点运行基础结构服务或应用程序服务的能力，可在多个并存的服务实例之间平衡对这些服务增加的要求。因此，经过适当配置后，群集软件便可准备用于在分布式企业应用程序中同时实现高可用性和可伸缩性。
由于冗余性是支持群集服务所必需的，因此在解决方案中包含这些服务对您的计算环境会产生很大影响。包含群集服务会大大增加物理拓扑中所需的计算节点和网络链路的数量。
与 Java Enterprise System 服务器所提供的服务不同，群集服务是分布式对等服务。因此，需要将群集软件安装在群集中的每个计算节点上。
三维综合上述各节分别对三个体系结构维进行了讨论，将它们聚在一起，便提供了一个框架，在此框架内可以了解任何应用程序或基础结构组件在体系结构设计中的作用。
从根本上讲，部署体系结构的每个逻辑层中的分布式组件都需要由适当的基础结构服务（第二维）提供支持。必须部署该二维方阵中的每个组件，才能满足服务质量要求（第三维）。
下图从概念上表示了这三维间的综合。
图 2-7 Java Enterprise System 体系结构的三维综合
例如，在此框架中，Directory Server 将被归类为后端、低级 Java Enterprise System 组件。从而其他许多组件都要依赖于 Directory Server，因此它出现故障会对业务系统产生巨大影响。这表明 Directory Server 必须高度可用。
由于 Directory Server 是用来存储敏感的用户和配置信息的，因此安全性遭到破坏也会产生巨大影响。这表明 Directory Server 以及与其交互的所有通信通道都应当高度安全可靠。
从设计方法学高度概括描述如何使用图 2-7 中的体系结构框架，这超出了本书的范围。但是，该三维体系结构突出体现了 Java Enterprise System 的多个方面，这些方面对于理解使用 Java Enterprise System 付诸实施分布式企业部署有着重要的意义。
