Java Enterprise System 体系结构框架
Java ES 组件支持部署分布式企业级软件解决方案。
要获得业务需求规定的性能、可用性、安全性、可伸缩性及可维护性级别的必需功能，就必须正确设计这些软件解决方案。
在设计分布式企业级软件解决方案时涉及许多体系结构维。这些维代表不同的角度，从这些角度可以查看创建这些系统所用的多个软件组件之间的交互作用。特别是，分布式系统的设计涉及以下三个体系结构维：
-
基础结构服务依赖性。此维强调系统服务组件在支持分布式解决方案中的角色（参见系统服务组件）。
-
逻辑层。此维强调解决方案组件在网络或 Internet 环境中部署时的逻辑和物理独立性。
-
服务质量。此维强调如何达到服务质量要求（如可用性、安全性、可伸缩性及可维护性），包括服务质量组件的角色（参见服务质量组件）。
解决方案体系结构的三维如下图所示。
图 2–1 Java ES 解决方案体系结构的维
这三维一起表示一个框架，其中还包括软件组件（application component（应用程序组件）和基础结构组件二者）之间的关系，这些关系是获取软件解决方案服务功能和服务质量要求所必需的。
以下章节将逐个描述三维，接着将三维综合为一个整体框架。
第 1 维：基础结构服务依赖性
分布式企业应用程序的交互软件组件需要一组底层的基础结构服务，这些服务允许分布式组件相互通信、协调各自的工作、实现安全访问等等。本节说明多个 Java ES 组件在提供这些基础结构服务时所扮演的重要角色。
基础结构服务级别
在设计分布式软件系统时，无论主要由定制开发的组件构成，还是由开盒即用的 Java ES 组件构成，都需要整合多项基础结构服务。这些服务在多个级别运行。
解决方案体系结构的基础结构服务依赖性维如图 2–2 中所示。此图显示的级别是图 1–1 中基础结构服务层的扩展视图。
图 2–2 中服务的分层结构以及它们之间的依赖性构成解决方案逻辑体系结构的一个重要维。这些基础结构服务提供基本概念，帮助您了解 Java ES 系统服务组件的角色（参见系统服务组件）。
图 2–2 所示的服务一般可分为三大组：低级平台服务、高级应用程序服务以及一组中间件服务（因其位于其他两个分组之间而得名）。
图 2–2 第 1 维：基础结构服务级别
以下段落介绍不同的基础结构服务级别，并在有关地方引用 Java 编程语言人工产物。服务级别按从最低到最高的顺序逐个进行介绍，如图 2–2 所示：
-
操作系统平台。为在计算机上运行的任何进程提供基本支持。操作系统（如 SolarisTM 操作系统、Linux 或 Microsoft Windows）管理着物理设备以及内存、线程和支持 Java 虚拟机（Java Virtual Machine，JVMTM 机）所需的其他资源。
-
网络传输。为不同计算机上运行的分布式应用程序组件间的通信提供基本联网支持。这些服务包括对诸如 TCP 和 HTTP 等协议的支持。其他较高级别的通信协议（请参阅消息层）依赖于这些基本传输服务。
-
消息传送。为应用程序组件间的同步及异步通信提供支持。同步消息传送是实时消息收发；它包括 J2EE 组件间的远程方法调用 (RMI) 以及 SOAP 与 Web 服务的交互。异步消息传送是指这样的一种通信：消息的发送不依赖于使用者是否已准备好立即接收该消息。异步消息传送规范（例如，“Java 消息服务”(Java Message Service, JMS) 和 ebXML）支持可靠性保障及其他消息传送语义。
-
运行时环境。提供任何分布式组件模型（如 J2EE 或 CORBA 模型）所需的支持。除了紧耦合分布式组件所需的远程方法调用之外，运行时服务还包括组件状态（生命周期）管理、线程池管理、同步（互斥锁定）、持久性服务、分布式事务监视以及分布式异常处理。在 J2EE 环境中，这些运行时服务由应用程序服务器或 Web 服务器中的 EJBTM、Web 和消息驱动 Bean 容器提供。
-
安全和策略。为安全访问应用程序资源提供支持。这些服务包括对策略的支持，策略不仅支配着分布式资源的组或基于角色的访问而且还支配着 single sign-on（单点登录）能力。单点登录允许将通过了分布式系统中一项服务的用户验证自动应用于系统中的其他服务（J2EE 组件、业务服务和 Web 服务）。
-
用户协作。提供在支持企业和 Internet 环境中的用户间直接通信和多用户相互协作方面起关键作用的服务。因而，这些服务是应用程序级业务服务，通常由独立的服务器（如电子邮件服务器或日历服务器）提供。
-
集成。提供聚集现有业务服务的服务。为访问这些服务提供一个公共接口（如在门户中那样），或通过在生产工作流程内协调这些服务的处理引擎将服务集成在一起。集成也可在不同企业间的企业到企业交互时发生。
图 2–2 中的服务级别反映了各种基础结构服务相互间的一般依赖性，从最低级别的操作系统服务一直到最高级别的应用程序和集成服务。每项服务一般都依赖于其下方的服务而支持其上方的服务。
但是，图 2–2 不表示严格的基础结构服务分层。较高级别的服务可以不依靠中间级别直接与较低级别的服务进行交互。例如，某些运行时服务可能直接依赖于平台服务而无需两者间的任何服务级别。此外，还可在此概念图中加入其他服务级别，如监视或管理服务。
Java Enterprise System 基础结构服务组件
Java ES 组件可实现图 2–2 中所示的分布式基础结构服务级别。不同级别中 Java ES 系统服务组件的定位如图 2–3 所示。
图 2–3 Java ES 系统服务组件
注 –
图 2–3 中所示的操作系统平台不是 Java Enterprise System 的正式部分；将它们放入图中是为了显示支持 Java ES 组件的操作系统平台。
Java Enterprise System 基础结构服务依赖性
一般而言，图 2–3 所示的每个 Java ES 系统服务组件都依赖基础结构中其下方的组件，并支持其上方的组件。这些依赖性和支持关系是设计逻辑体系结构的关键因素。
表 2–1 显示 Java ES 系统服务组件之间的特定关系，从上到下依次列出，如图 2–3 中所示。
表 2–1 Java ES 系统服务组件之间的关系|
组件 |
所依赖的组件 |
所支持的组件 |
|---|---|---|
|
Portal Server |
Application Server 或 Web Server Access Manager Directory Server 如果配置成使用相应频道：Calendar Server Messaging Server Instant Messaging | |
|
Messaging Server |
Directory Server Access Manager（对于单点登录） |
Calendar Server（对于电子邮件通知） Portal Server（对于消息传送频道） |
|
Instant Messaging |
Directory Server Access Manager（对于单点登录） |
Portal Server（对于即时消息传送频道） |
|
Calendar Server |
Directory Server Messaging Server（对于电子邮件通知服务） Access Manager（对于单点登录） |
Portal Server（对于日历频道） |
|
Access Manager |
Application Server 或 Web Server Directory Server |
Portal Server 如果配置了单点登录：Calendar Server Messaging Server Instant Messaging |
|
Application Server |
Message Queue Directory Server（对于管理对象） |
Portal Server Access Manager |
|
Message Queue |
Directory Server（对于管理对象） |
Application Server |
|
Web Server |
Access Manager（对于访问控制） |
Portal Server Access Manager |
|
Directory Server |
无 |
Portal Server Calendar Server Messaging Server Instant Messaging Access Manager |
|
Service Registry |
无 |
基于 Applcation Server 的组件 |
第 2 维：逻辑层
分布式企业应用程序的交互软件组件可以看作是分别驻留在多个逻辑层中。根据所提供服务的性质，这些层分别表示软件组件的逻辑和物理独立性。
图 2–4 第 2 维：分布式企业应用程序的逻辑层
多数情况下，逻辑层体系结构表示图 1–1 中所示的分布式企业应用程序层。基础结构服务级别介绍的 Java ES 系统服务组件为图 2–4 所示的所有逻辑层中的应用程序组件提供支持。不过，逻辑层概念也适用于提供应用程序级服务的系统服务组件，如 Messaging Server 和 Calendar Server。
逻辑层描述
本节简要描述图 2–4 所示的四个逻辑层。在描述中引用了采用 Java 2 Platform, Enterprise Edition（J2EETM 平台）组件模型实现的应用程序组件。但是，其他分布式组件模型（如 CORBA）也可支持此体系结构。
-
客户层。客户层由最终用户通过用户界面直接访问的应用程序逻辑组成。客户层中的逻辑可以包括基于浏览器的客户机、在台式计算机上运行的 Java 组件，或是在手持设备上运行的 Java 2 Platform, Micro Edition（J2METM 平台）移动客户机。
-
表示层。表示层由应用程序逻辑组成，应用程序逻辑负责准备要传送给客户层的数据并处理来自客户层的请求，以便传送给后端业务逻辑。表示层中的逻辑通常由 J2EE 组件组成，如 Java Servlet 组件或 JSP 组件，它们为 HTML 或 XML 格式的传送准备数据或接收请求以便进行处理。此层还可能包括门户服务，该服务可对业务服务层中的 business service（业务服务）提供个性化、安全和定制的访问。
-
业务服务层。业务服务层由执行应用程序主要功能的逻辑组成，这些功能有：处理数据、实现业务规则、协调多个用户以及管理诸如数据库或传统系统之类的外部资源。通常，此层由符合 J2EE 分布式组件模型的紧耦合组件组成，如 Java 对象、EJB 组件或消息驱动 Bean。可将单个 J2EE 组件组合起来提供复杂的业务服务，如库存服务或计税服务。单个组件及服务组合体可在面向服务的体系结构模型内封装起来作为符合简单对象访问协议 (Simple Object Access Protocol, SOAP) 接口标准的松耦合 web service（Web 服务）。业务服务还可以组建为独立的 server（服务器），如企业日历服务器或消息传送服务器。
-
数据层。数据层由提供业务逻辑所用永久性数据的服务组成。这些数据可以是数据库管理系统中存储的应用程序数据，也可以是轻型目录访问协议 (Lightweight Directory Access Protocol, LDAP) 数据存储器中存储的资源和目录信息。这些数据服务还可以包括自外部源馈送而来的数据或可从传统计算系统中访问的数据。
逻辑和物理独立性
图 2–4 中所示的体系结构维强调了组件的逻辑和物理独立性，由四个独立的层表示。这些层表示联网环境中各台计算机上划分的应用程序逻辑：
-
逻辑独立性。该体系结构模型中的四层表现逻辑独立性：对某一层中（例如在业务服务层中）的应用程序逻辑的修改可以独立于其他层。无需更改或升级表示层或客户层中的逻辑即可更改您的业务逻辑实现。举例而言，这种独立性意味着：无需修改业务服务组件即可引入新型客户组件。
-
物理独立性。这四层还表现物理独立性：您可以在不同的硬件平台（即，不同的处理器配置、芯片组和操作系统）上部署不同层中的逻辑。利用此独立性，您可以在最适合各自计算要求和最适合最大化网络带宽的计算机上运行分布式应用程序组件。
您将应用程序组件或基础结构组件映射到硬件环境（即您的部署体系结构）的方式取决于多种因素，具体要根据软件解决方案的规模和复杂性来决定。对于规模很小的部署，部署体系结构可能只涉及几台计算机。而对于较大规模的部署，组件到硬件环境的映射可能需要考虑多个因素，如不同计算机的速度和功效、网络链路的速度和带宽、安全和防火墙考虑事项，以及获得高可用性和可伸缩性的组件复制策略。
应用于系统组件的分层体系结构
如图 2–3 中所示，Java ES 基础结构服务组件为分布式软件解决方案提供底层基础结构支持。但其中有些解决方案包括 Java ES 组件直接提供的应用程序级服务。这些解决方案使用逻辑层设计方法。
例如，Messaging Server 提供的电子邮件通信服务使用多个逻辑上完全不同的 Messaging Server 配置来实现。这些独特的配置各自提供一组独特的服务。在设计消息传送解决方案时，这些独特的配置被表示为位于不同逻辑层的独立组件，如下图所示。
图 2–5 Messaging Server：分层体系结构示例
注 –
图 2–5 并不是一个完整的逻辑体系结构，为了简化，示意图省略了许多 Java ES 组件。连接组件的线条表示各组件间的交互。
在逻辑上将 Messaging Server 各功能分成独立的层，可使这些逻辑上不同的 Messaging Server 配置部署在物理环境中的不同计算机上。物理分离可以更加灵活地满足不同的服务质量要求（参见第 3 维：服务质量）。例如，它为不同实例提供不同的可用性解决方案，为不同 Messaging Server 功能提供不同的安全性实现。
第 3 维：服务质量
前面的两个体系结构维（基础结构服务依赖性和逻辑层）主要定义了体系结构的逻辑层面，即需要哪些组件以何种交互方式将服务交付给最终用户。但是，对于任何已部署的解决方案，还有一维也同等重要，即解决方案满足服务质量要求的能力。
解决方案体系结构的服务质量维着重于 Java ES 服务质量组件所扮演的角色。
服务质量
随着和电子商务服务对企业运营的作用愈来愈重要，这些服务的性能、可用性、安全性、可伸缩性以及可维护性已成为大规模、高性能部署体系结构的主要服务质量要求。
要设计成功的软件解决方案，必须建立相关的服务质量要求，设计符合这些要求的体系结构。许多重要的服务质量用于指定服务质量要求。下表中简要列出了这些服务质量。
表 2–2 影响解决方案体系结构的服务质量|
系统服务质量 |
说明 |
|---|---|
|
按用户负载条件对响应时间和等待时间所作的度量。 |
|
|
最终用户访问系统资源和服务长期性保证程度（系统正常运行时）。 |
|
|
对系统及其用户的完整性进行说明的复杂因素组合。安全性包括系统的物理安全、网络安全、应用程序和数据安全（用户的验证与授权）以及安全的信息传输。 |
|
|
随时间推移为已部署系统增加容量的能力。可伸缩性通常涉及向系统添加资源，但不应要求对部署体系结构进行更改。 |
|
|
在不增加资源的情况下，系统处理异常峰值负载用量的能力。 |
|
|
对已部署系统进行维护的容易度，其中包括监视系统、修复出现的故障以及升级硬件和软件组件。 |
服务质量维对解决方案的部署体系结构有很大影响：如何在物理环境中部署应用程序组件和基础结构组件。
影响部署体系结构的各服务质量密切相关：对一项系统质量的要求可能会影响到其他服务质量的设计。例如，提高安全性级别可能会影响到性能，而性能又会影响到可用性。添加额外的计算机以通过冗余来解决可用性问题可能会影响到维护成本（可维护性）。
理解各服务质量的相互联系方式以及所要采取的折衷方案是设计满足业务需求和业务约束的部署体系结构的关键。
Java Enterprise System 服务质量组件
有几个 Java ES 组件主要用来增强系统服务组件或分布式应用程序组件提供的服务质量。这些软件组件通常结合一些硬件组件共同使用，如负载平衡器和防火墙。
以下简要说明了在服务质量组件中介绍的 Java ES 服务质量组件：
-
可用性组件。这些组件为部署的解决方案提供近乎连续的正常运行时间。
-
访问组件。这些组件提供到系统服务的安全 Internet 访问，还常常提供路由功能。
-
管理组件。这些组件为系统组件提供增强的可维护性。
下表从体系结构的角度列出了最重要的几个 Java ES 服务质量组件以及受它们影响最大的系统质量。
表 2–3 服务质量组件以及受影响的系统质量|
组件 |
受影响的系统质量 |
|---|---|
|
可伸缩性 |
|
|
High Availability Session Store | |
|
Sun Cluster | |
|
Web Proxy Server |
安全性 性能 |
Sun Cluster 软件
Sun Cluster 软件为 Java ES 组件以及 Java ES 基础结构支持的应用程序提供高可用性和可伸缩性服务。
群集是一组松耦合计算机，该组计算机共同提供了服务、系统资源和数据的单客户机视图。群集在内部使用了冗余计算机、相互连接、数据存储和网络接口，以此来向基于群集的服务和数据提供高可用性。
Sun Cluster 软件持续监视成员节点及其他群集资源的运行状况。如果出现故障，Sun Cluster 软件就会介入，启动所监视资源的故障转移功能，从而使用内部冗余为这些资源提供近乎连续的访问。
下图显示的是支持 Messaging Server 和 Calendar Server 的数据存储服务的双节点群集。
图 2–6 使用 Sun Cluster 节点的可用性设计
Sun Cluster 数据服务包（有时称为 Sun Cluster 代理）适用于所有 Java ES 系统服务组件。您也可以为定制开发的应用程序组件编写代理。
由于 Sun Cluster 软件担负着控制职责，所以它还提供可伸缩服务。充分利用群集的全局文件系统以及群集中的多个节点都能运行基础结构服务或应用程序服务的能力，可在多个并存的服务实例之间平衡对这些服务增加的需求量。因此，经过适当配置后，Sun Cluster 软件便可在分布式企业应用程序中同时提供高可用性和可伸缩性。
由于冗余对于支持 Sun Cluster 环境的必要性，因此，在解决方案中包含 Sun Cluster 会大大增加物理环境中所需的计算机和网络链路的数目。
与其他 Java ES 组件提供的服务不同的是，Sun Cluster 可用性服务是分布式对等服务。因此，需要将 Sun Cluster 软件安装在群集中的每台计算机上。
三个体系结构维的组合
综合在一起看，前几节所述的以及图 2–1 所示的三个体系结构维提供了一个用于设计分布式软件解决方案的框架。三维（基础结构服务依赖性、逻辑层和服务质量）着重于 Java ES 组件在解决方案体系结构中扮演的角色。
每个维都代表一个独特的体系结构视角。任何解决方案体系结构都需要考虑它们三个。例如，解决方案体系结构每个逻辑层中的分布式组件（第 2 维）必须得到适当的基础结构组件（第 1 维）和适当的服务质量组件（第 3 维）的支持。
同样，解决方案体系结构中的任意组件都扮演着与不同体系结构维相关的不同角色。例如，Directory Server 既可看作是数据层中的后端组件（第 2 维），同时又可看作是持久性服务的提供者（第 1 维）。
鉴于 Directory Server 在以上两维中的中心地位，所以服务质量问题（第 3 维）对于此 Java ES 组件也极为重要。Directory Server 故障可能会对业务系统造成非常大的影响，因此，此组件的高可用性设计非常重要；并且因为 Directory Server 是用来存储敏感的用户信息或配置信息的，此组件的安全性设计也非常重要。
Java ES 组件的三个维之间的相互影响也将对解决方案逻辑体系结构和解决方案部署体系结构的设计产生影响。
基于Java Enterprise System 体系结构框架中的体系结构框架详细介绍各种设计方法论已经超出了本书的范围。但是，在部署基于 Java Enterprise System 的软件解决方案时，理解三维体系结构框架强调的各设计层面很重要。
- © 2010, Oracle Corporation and/or its affiliates