Java ES 体系结构框架

Java ES 体系结构框架

Java ES 组件为部署分布式软件解决方案提供支持。要获得业务需求规定的性能、可用性、安全性、可伸缩性及可维护性级别的必需功能，就必须正确设计这些软件解决方案。

在设计企业级解决方案时涉及许多体系结构维。这些维代表不同的角度，从这些角度可以查看创建这些系统所用的多个软件组件之间的交互作用。特别是，分布式系统的设计涉及以下三个体系结构维：

解决方案体系结构的三维如下图所示。

图 2–1 Java ES 解决方案体系结构的维

这三维一起表示一个框架，其中还包括软件组件（和基础结构组件二者）之间的关系，这些关系是获取软件解决方案服务功能和服务质量要求所必需的。

以下章节将逐个描述三维，接着将三维综合为一个整体框架。

第 1 维：基础结构服务依赖性

分布式企业应用程序的交互软件组件需要底层的基础结构服务，这些服务允许分布式组件相互通信、协调各自的工作、实现安全访问，等等。本节说明多个 JavaES 组件在提供这些基础结构服务时所扮演的重要角色。

基础结构服务级别

在设计分布式软件系统时，无论系统是主要由自定义开发的组件构成，还是由现成可用的 JavaES 组件构成，都需要整合多项基础结构服务。这些服务在多个级别运行。

解决方案体系结构的基础结构服务依赖性如 中所示。此图显示的级别是 中基础结构服务层的扩展视图。 中服务的分层结构以及它们之间的依赖性构成解决方案逻辑体系结构的一个重要维。这些基础结构服务为 JavaES 系统服务组件提供了主要的理论根据（参见）。

下图所示的服务一般可分为三大组：底层平台服务、高层应用程序服务以及一组中间件服务（因其位于其他两个分组之间而得名）。

图 2–2 第 1 维：基础结构服务级别

下面介绍了不同的基础结构服务级别，并在有关地方引用了 Java 编程语言工件。服务级别按从最低到最高的顺序列出，如 中所示：

显示的服务级别反映了基础结构服务相互间的依赖性，从最低级别的操作系统服务一直到最高级别的应用程序和集成服务。每项服务一般都依赖于其下方的服务而支持其上方的服务，但是， 并不表示严格的基础结构服务分层。较高级别的服务可以不依靠中间级别直接与较低级别的服务进行交互。例如，某些运行时服务可能直接依赖于平台服务而无需两者间的任何服务级别。此外，还可在此概念图中加入其他服务级别，如监视或管理服务。

Java ES 基础结构服务组件

JavaES 组件可实现 中所示的分布式基础结构服务级别。下图显示了各系统服务组件在不同级别中的定位。

图 2–3 JavaES 系统服务组件

注 –

图中阴影框内的组件不是 Java ES 的组成部分。用户协作组件不属于 Java ES 组件，但常与 Java ES 组件一起部署，并在 Java ES 体系结构中使用。它们是 Sun Java Communications Suite 的一部分，本文档引用它们仅作说明之用。操作系统平台也不是 Java ES 的正式组成部分，但将它们放入图中是为了显示那些支持 JavaES 组件的操作系统平台。

Java ES 基础结构服务依赖性

一般而言， 中所示的每个 JavaES 系统服务组件都依赖于基础结构中其下方的组件，并支持其上方的组件。这些依赖性和支持关系是设计逻辑体系结构的关键因素。

下表显示了 JavaES 系统服务组件之间的特定关系，这些组件从上到下依次列出，如 中所示。

表 2–1 JavaES 系统服务组件之间的关系

组件

所依赖的组件

所支持的组件

Portal Server

Application Server 或 Web Server

Access Manager

Directory Server

如果配置成使用相应频道：Calendar Server、Messaging Server 和 Instant Messaging [Calendar Server、Messaging Server 和 Instant Messaging 组件是 Sun Java Communications Suite 的一部分。]

无

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

Access Manager

Calendar Server

Messaging Server

Instant Messaging

Service Registry

Java DB

基于 Application Server 的组件

Java DB

无

Service Registry

第 2 维：逻辑层

分布式企业应用程序的交互软件组件可以看作是分别驻留在多个逻辑层中。根据所提供服务的性质，这些层分别表示软件组件的逻辑和物理独立性。

下图说明了解决方案体系结构的逻辑层维。

图 2–4 第 2 维：分布式企业应用程序的逻辑层

多数情况下，逻辑层体系结构表示 中所示的分布式企业应用程序层。介绍的 JavaES 系统服务组件为 所示的所有逻辑层中的应用程序组件提供支持。逻辑层概念主要适用于自定义企业应用程序，同时还适用于由 Sun Java Communications Suite 组件提供的协作服务以及一些 portal 服务。

逻辑层描述

本节简要描述了 中所示的四个逻辑层。在描述中引用了采用 J2EE 平台组件模型所实现的应用程序组件。但是计算机网络什么是可伸缩性，其他分布式组件模型（如 CORBA）也可支持此体系结构。

逻辑和物理独立性

中的体系结构维强调了组件的逻辑和物理独立性，由四个独立的层表示。这些层表明了应用程序逻辑在联网环境下的不同计算机上的划分：

应用于系统组件的分层体系结构

如 中所示，JavaES 基础结构服务组件为分布式软件解决方案提供底层基础结构支持。其中，有些解决方案包括由 Sun Java Communications Suite 组件及某些 JavaES 组件提供的应用程序级服务。这些解决方案使用逻辑层设计方法。

例如，Messaging Server 提供的电子邮件通信服务使用多个逻辑上完全不同的 Messaging Server 配置来实现。这些独特的配置各自提供一组独特的服务。在设计消息传送解决方案时，这些独特的配置被表示为位于不同逻辑层的独立组件，如下图所示，图中连接各组件的线条表示各组件之间的交互。

注 –

下图并不是一个完整的逻辑体系结构。为简化起见，图中省略了许多 JavaES 组件。

图 2–5 Messaging Server：分层体系结构示例

注 –

通信组件不属于 Java ES 组件，但常与 Java ES 组件一起部署，并在 Java ES 体系结构中使用。这些通信组件是 Sun Java Communications Suite 的一部分，本文档引用它们仅作说明之用。

在逻辑上将 Messaging Server 各功能分成不同的层，可使 Messaging Server 的逻辑互异配置分别部署在物理环境中的不同计算机上。物理分离可以更加灵活地满足不同的服务质量要求（参见）。例如计算机网络什么是可伸缩性，它为不同实例提供不同的可用性解决方案，为不同 Messaging Server 功能提供不同的安全性实现。

第 3 维：服务质量

前面的两个体系结构维（基础结构服务依赖性和逻辑层）主要定义了体系结构的逻辑层面，即需要哪些组件以何种交互方式将服务交付给最终用户。对于任何已部署的解决方案，还有一维也同等重要，即解决方案满足服务质量要求的能力。

解决方案体系结构的服务质量维着重于 JavaES 服务质量组件所扮演的角色。

服务质量

随着 Internet 和电子商务服务对企业运营的作用愈来愈重要，这些服务的性能、可用性、安全性、可伸缩性以及可维护性已成为大规模、高性能部署体系结构的主要服务质量要求。

要设计成功的软件解决方案，必须建立相关的服务质量要求并设计符合这些要求的体系结构。许多重要的服务质量用于指定服务质量要求。下表中简要列出了这些服务质量。

表 2–2 影响解决方案体系结构的服务质量

系统服务质量

说明

性能

按用户负载条件对响应时间和等待时间所作的度量。

可用性

最终用户访问系统资源和服务长期性保证程度（系统正常运行时）。

安全性

对系统及其用户的完整性进行说明的复杂因素组合。安全性包括系统的物理安全、网络安全、应用程序和数据安全（用户的验证与授权）以及安全的信息传输。

可伸缩性

随时间推移为已部署系统增加容量的能力。可伸缩性通常涉及向系统添加资源，但不应要求对部署体系结构进行更改。

潜在容量

在不增加资源的情况下，系统处理异常峰值负载用量的能力。

可维护性

对已部署系统进行维护的容易度，其中包括监视系统、修复出现的故障以及升级硬件和软件组件。

服务质量维对解决方案的部署体系结构有很大影响：如何在物理环境中部署应用程序组件和基础结构组件。

影响部署体系结构的各服务质量密切相关：对一项系统质量的要求可能会影响到其他服务质量的设计。例如，提高安全性级别可能会影响到性能，而性能又会影响到可用性。添加额外的计算机以通过冗余来解决可用性问题可能会影响到维护成本（可维护性）。