java的基础结构



Java ES 体系结构框架

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

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

• 基础结构服务依赖性。此维强调系统服务组件在支持分布式解决方案方面扮演的角色（参见系统服务组件）。
• 逻辑层。此维强调解决方案组件在网络或 Internet 环境中部署时的逻辑和物理独立性。
• 服务质量。此维强调如何达到服务质量要求（如可用性、安全性、可伸缩性及可维护性），包括服务质量组件所扮演的角色（参见服务质量组件）。

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

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

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

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

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

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

基础结构服务级别

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

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

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

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

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

• 操作系统平台。为在计算机上运行的任何进程提供基本支持。操作系统管理着物理设备、内存、线程以及其他用以支持 Java 虚拟机（JVM^TM 机）的资源。
• 网络传输。为不同计算机上运行的分布式应用程序组件间的通信提供基本联网支持。这些服务包括对诸如 TCP 和 HTTP 等协议的支持。其他较高级别的通信协议（请参见消息层）依赖于这些基本传输服务。
• 持久性。为访问和存储静态数据（如用户、目录或配置的信息）及动态应用程序数据（经常更新的信息）提供支持。
• 消息传送。为应用程序组件间的同步及异步通信提供支持。同步消息传送是实时消息收发；它包括 J2EE 组件间的远程方法调用 (Remote Method Invocation, RMI) 以及 SOAP 与 Web 服务的交互。异步消息传送是指这样的一种通信：消息的发送不依赖于使用者是否已准备好立即接收该消息。异步消息传送规范（例如，“Java 消息服务”(Java Message Service, JMS) 和 ebXML）支持可靠性保障及其他消息传送语义。
• 运行时环境。提供任何分布式组件模型（如 J2EE 或 CORBA 模型）所需的支持。除了紧耦合分布式组件所需的远程方法调用之外，运行时服务还包括组件状态（生命周期）管理、线程池管理、同步（互斥锁定）、持久***、分布式事务监视以及分布式异常处理。在 J2EE 环境中，这些运行时服务由应用服务器或 Web 服务器中的 EJB、Web 和消息驱动 Bean 容器提供。
• 安全和策略。为安全访问应用程序资源提供支持。这些服务包括对策略的支持，策略不仅掌管着分布式资源的组或基于角色的访问，还掌管着 single sign-on（单点登录）能力。单点登录允许将通过了分布式系统中一项服务的用户验证自动应用于系统中的其他服务（J2EE 组件、业务服务和 Web 服务）。
• 用户协作。提供在支持企业和 Internet 环境中的用户间直接通信和多用户相互协作方面起关键作用的服务。这些服务是应用程序级业务服务，通常由独立的服务器（如电子邮件服务器或日历服务器）提供。
• 集成。提供用于聚集现有业务服务的服务。为访问这些服务提供一个公共接口（如在 Portal 中那样），或通过用于在生产工作流程内协调这些服务的过程引擎将服务集成在一起。集成也可在不同企业间的企业到企业交互时发生。

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

Java ES 基础结构服务组件

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

图 2–3 Java ES 系统服务组件

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

Java ES 基础结构服务依赖性

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

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

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

第 2 维：逻辑层

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

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

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

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

逻辑层描述

本节简要描述了图 2–4 中所示的四个逻辑层。在描述中引用了采用 J2EE 平台组件模型所实现的应用程序组件。但是，其他分布式组件模型（如 CORBA）也可支持此体系结构。

• 客户层。客户层由最终用户通过用户界面所直接访问的应用程序逻辑组成。客户层中的逻辑可以包括基于浏览器的客户机、在台式计算机上运行的 Java 组件，或是在手持设备上运行的 Java^TM 2 Platform, Micro Edition（J2ME^TM 平台）移动客户机。
• 表示层。表示层由负责准备要传送给客户层的数据并负责处理来自客户层的请求以便传送给后端业务逻辑的应用程序逻辑组成。表示层中的逻辑通常包括诸如 Java servlet 或 JSP 组件之类的 J2EE 组件，它们负责准备以 HTML 或 XML 格式传送的数据或是负责接收请求以便进行处理。此层还可能包括 portal 服务，该服务可对业务服务层中的 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 基础结构服务组件为分布式软件解决方案提供底层基础结构支持。其中，有些解决方案包括由 Sun Java Communications Suite 组件及某些 Java ES 组件提供的应用程序级服务。这些解决方案使用逻辑层设计方法。

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

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

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

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

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

第 3 维：服务质量

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

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

服务质量

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

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

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

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

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

理解各服务质量的相互联系方式以及所要采取的折衷方案是设计满足业务需求和业务约束的部署体系结构的关键。

Java ES 服务质量组件

有几个 Java ES 组件主要用来增强系统服务组件或分布式应用程序组件所提供的服务质量。这些软件组件通常结合一些硬件组件共同使用，如负载平衡器和防火墙。

以下简要说明了在服务质量组件中介绍的 Java ES 服务质量组件：

• 可用性组件。为已部署解决方案提供近乎连续的运行时间。
• 访问组件。提供到系统服务的安全 java的基础结构 Internet 访问，还常常提供路由选择功能。
• 监视组件。提供 Java ES 组件的相关实时信息。

下表从体系结构的角度列出了最重要的几个 Java ES 服务质量组件以及受它们影响最大的系统质量。

表 2–3 服务质量组件以及受影响的系统质量

Sun Cluster 软件

Sun Cluster 软件为 Java ES 组件以及 Java ES 基础结构支持的应用程序提供高可用性和可伸缩***。群集是一组松耦合的计算机，它们共同提供了服务、系统资源和数据的单一客户机视图。群集在内部使用了冗余计算机、相互连接、数据存储和网络接口，以此来向基于群集的服务和数据提供高可用性。

Sun Cluster 软件持续监视成员节点及其他群集资源的运行状况。如果出现故障，Sun Cluster 软件就会介入，启动所监视资源的故障转移功能，从而使用内部冗余为这些资源提供近乎连续的访问。

Sun Cluster 数据服务包（有时称为 Sun Cluster 代理）适用于所有 Java ES 系统服务组件。您也可以为自定义开发的应用程序组件编写代理。

由于 Sun Cluster 软件担负着控制职责，所以它还可提供可伸缩服务。充分利用群集的全局文件系统以及群集中多个节点运行基础结构服务或应用程序服务的能力，可在多个并存的服务实例之间平衡对这些服务增加的要求。因此，经过适当配置后，Sun Cluster 软件便可准备用于在分布式企业应用程序中同时实现高可用性和可伸缩性。

由于冗余对于支持 Sun Cluster 环境的必要性，因此，在解决方案中包含 Sun Cluster 会大大增加物理环境中所需的计算机和网络链接的数目。

与其他 Java ES 组件提供的服务不同的是，Sun Cluster 可用***是分布式对等服务。因此，需要将 Sun Cluster 软件安装在群集中的每台计算机上。

Sun Cluster Geographic Edition 是 Sun Cluster 软件的扩展，它可通过使用位于不同地理位置的多个群集以及在这些群集之间复制数据的基础结构来保护应用程序，使其免于意外中断。

Sun Cluster 和 Sun Cluster Geographic Edition 仅在 Solaris^TM 操作系统 (Solaris Operating System, Solaris OS) 上受支持。

三个体系结构维的综合

综合在一起看，我们在前几节中论述并在图 2–1 中进行了显示的三个体系结构维为如何设计分布式软件解决方案提供了一个框架。这三维（基础结构服务依赖性、逻辑层和服务质量）着重于 Java ES 组件在解决方案体系结构中所扮演的角色。

每个维都代表一个独特的体系结构视角。每个解决方案体系结构必须将这三个维全部考虑进去。例如，解决方案体系结构每个逻辑层中的分布式组件（第 2 维）必须得到适当的基础结构组件（第 1 维）和适当的服务质量组件（第 3 维）的支持。

同样，解决方案体系结构中的任意组件都扮演着与不同体系结构维相关的不同角色。例如，Directory Server 既可看作是数据层中的后端组件（第 2 维），同时又可看作是持久***的提供者（第 1 维）。鉴于 Directory Server 在以上两维中的中心地位，所以服务质量问题（第 3 维）对于此 Java ES 组件也极为重要。Directory Server 故障对业务系统有非常大的影响，因此，对于此组件而言，其高可用性设计极为重要。由于 Directory Server 用来存储敏感的用户或配置信息，因此，对于此组件而言，安全性设计也是极为重要的。

就 Java ES 组件而言，三个维之间的相互影响对解决方案逻辑体系结构和解决方案部署体系结构的设计也会产生影响。

版权声明：

本文来源网络，所有图片文章版权属于原作者，如有侵权，联系删除。

本文网址：https://www.bianchenghao6.com/h6javajc/20646.html