test

Sun Java Enterprise System 2005Q4 部署规划指南

第 4 章 逻辑设计

在解决方案生命周期的逻辑设计阶段，设计指定解决方案逻辑组件间相互关系的逻辑体系结构。逻辑体系结构和来自技术要求阶段的使用分析一起组成了部署方案，作为部署设计阶段的信息来源。

本章包括以下部分：

关于逻辑体系结构

逻辑体系结构确定实现解决方案所需的软件组件，显示组件间的相互关系。逻辑体系结构和在技术要求阶段确定的服务质量要求一起组成一个部署方案。部署方案是进行下一阶段，即部署设计阶段，部署体系结构设计的基础。

开发逻辑体系结构时，不仅需要确定向用户提供服务的组件，还要确定提供必要中间件和平台服务的其他组件。基础结构服务依赖性和逻辑层提供了两种执行此分析的补充方法。

基础结构服务依赖性和逻辑层是 Sun JavaTM Enterprise System 基于的解决方案体系结构三维中的两维。此三维在下面列出，同时显示在关于逻辑体系结构中。

注 –

有关 Java Enterprise System 体系结构概念的更多信息，参阅《Sun Java Enterprise System 2005Q4 技术概述》的“Java Enterprise System 体系结构”一章。

逻辑体系结构通过显示必要组件及其依赖性说明基础结构服务级别。逻辑体系结构还在逻辑层间分配组件。这些逻辑层表示可被客户层访问的表示、业务和数据服务。服务质量虽未在逻辑体系结构中建立模型，但与部署方案中的逻辑体系结构相对应。

设计逻辑体系结构

设计逻辑体系结构时，使用在技术要求阶段确定的使用案例来确定提供解决方案所需服务的 Java Enterprise System 组件。还必须确定向最初确定组件提供服务的所有组件。

根据 Java Enterprise System 组件所提供服务的类型，将其放在多层体系结构的上下文环境中。组件是多层体系结构的组成部分，这种理解有助于您确定对组件所提供的服务进行分布的方法，还有助于确定实现服务质量（如可伸缩性、可用性等）的策略。

另外，还可提供另一个将逻辑组件放在安全访问区内的逻辑组件视图。访问区一节中提供了一个安全访问区示例。

Java Enterprise System 组件

Java Enterprise System 由提供企业服务的交互软件组件组成，可用于构建企业解决方案。下图显示的是 Java Enterprise System 提供的关键软件组件。《Sun Java Enterprise System 2005Q4 技术概述》提供了关于 Java Enterprise System 组件及其所提供服务的更多信息。

图 4–1 Java Enterprise System 组件

Java Enterprise System 各组件间关系图。

组件依赖性

确定逻辑体系结构的 Java Enterprise System 组件时，还需确定支持组件。例如，如果将 Messaging Server 确定为某个逻辑体系结构的必要组件，则该逻辑体系结构还必须含有 Directory Server 及可能含有 Access Manager。Messaging Server 依赖 Directory Server 提供目录服务，依赖 Access Manager 提供要求单点登录的解决方案。

下表列出了 Java Enterprise System 组件的依赖性。有关关键组件依赖性的图示，参阅组件依赖性。设计逻辑体系结构时，使用此表及所附数字确定设计中的依赖性组件。

表 4–1 Java Enterprise System 组件依赖性

Java Enterprise System 组件 

所依赖的组件 

Application Server

Message Queue 

Directory Server（可选） 

Calendar Server

Messaging Server（用于电子邮件通知服务） 

Access Manager（用于单点登录） 

Web Server（用于 Web 接口） 

Directory Server 

Communications Express

Access Manager（用于单点登录） 

Calendar Server 

Messaging Server 

Instant Messaging 

Web Server（用于 Web 接口） 

Directory Server 

Directory Proxy Server

Directory Server 

Directory Server

无 

Access Manager

Application Server 或 Web Server 

Directory Server 

Instant Messaging

Access Manager（用于单点登录） 

Directory Server 

Message Queue

Directory Server（可选） 

Messaging Server

Access Manager（用于单点登录） 

Web Server（用于 Web 接口） 

Directory Server 

Portal Server

如果配置为使用 Portal Server 频道： 

Calendar Server 

Messaging Server 

Instant Messaging 

Access Manager（用于单点登录） 

Application Server 或 Web Server 

Directory Server 

Portal Server Secure Remote Access

Portal Server 

Web Server

Access Manager（可选，用于访问控制） 

注 –

组件依赖性中列出的 Java Enterprise System 组件间的依赖性并未列出全部的组件依赖性，其中未列出在规划安装时必须考虑的依赖性。有关 Java Enterprise System 依赖性的完整列表，参阅《Sun Java Enterprise System 2005Q4 安装指南》。

图 4–2 Java Enterprise System 组件依赖性

此图提供了表 4-1 中所述依赖性的图示。

Web 容器支持

上一节组件依赖性中未提及 Portal Server 和 Access Manager 在其中运行的 Web 容器。此 Web 容器可由 Application Server、Web Server 或第三方产品提供。设计包含有 Portal Server 或 Access Manager 的逻辑体系结构时，请确保对这些组件所需的 Web 容器加以说明。

Messaging Server 提供的逻辑互异服务

Java Enterprise System Messaging Server 通过配置，可提供单独的实例，以提供以下逻辑互异服务：

Messaging Server 的这些不同配置提供了可在单独的物理服务器上部署并可在逻辑体系结构的不同层中表示的功能。由于 Messaging Server 的这些配置代表不同层中逻辑互异的服务，因此在设计逻辑体系结构时请将其视为逻辑互异组件。逻辑体系结构示例提供了一个逻辑互异组件的示例。

下表介绍了 Messaging Server 的逻辑互异配置。

表 4–2 Messaging Server 配置

子组件 

说明 

Message Transfer Agent (MTA)

支持通过处理 SMTP 连接发送电子邮件、路由电子邮件以及将消息传送到适当的消息存储。MTA 组件通过配置，可支持从企业外部发送（入站）或从企业内部发送（出站）电子邮件。 

Message Store (STR)

提供电子邮件消息的检索和存储。 

Message Multiplexor (MMP)

通过使用 IMAP 或 POP 协议访问电子邮件客户机的消息存储，支持电子邮件检索。 

Messenger Express Multiplexor (MEM)

通过代表基于 Web (HTTP) 的客户机访问消息存储，支持电子邮件检索。 

访问组件

Java Enterprise System 还含有提供对系统服务访问（通常从企业防火墙外部）的组件。Messaging Server 的某些配置还可提供网络访问，如为消息多路复用器配置的 Messaging Server。下表介绍了提供对系统服务远程访问的 Java Enterprise System 组件。

表 4–3 提供远程访问的 Java Enterprise System 组件

组件 

说明 

Directory Proxy Server

可为 Directory Server 实例提供增强的目录访问控制、模式兼容性、路由选择以及负载平衡。 

Portal Server, Portal Server Secure Remote Access

提供从公司防火墙外部对 Portal Server 内容和服务（包括内部门户和 Internet 应用程序）的安全 Internet 访问。 

Portal Server, Portal Server Mobile Access

提供从移动设备到 Portal Server 的无线访问和对 Portal Server 的语音访问。 

Messaging Server Message Multiplexor (MMP)

通过代表基于 Web (HTTP) 的客户机访问消息存储，支持电子邮件检索。 

提供远程访问的组件通常在安全访问区部署，如访问区一节中的示例所示。

多层体系结构设计

Java Enterprise System 非常适合多层体系结构设计。在多层体系结构中，服务根据其提供的功能放在不同层中。每个服务都是逻辑独立的，并且可由同层或不同层的服务访问。下图显示了企业应用程序的一个多层体系结构模型，介绍了客户层、表示层、业务服务层和数据层。

图 4–3 多层体系结构模型

此图显示了多层体系结构中服务间的关系。

下表是对多层体系结构设计中显示的逻辑层的说明。

表 4–4 多层体系结构中的逻辑层

层 

说明 

客户机层

含有向最终用户提供信息的客户机应用程序。对于 Java Enterprise System，这些应用程序通常是邮件客户机、Web 浏览器或移动访问客户机。 

表示层

提供向最终用户显示数据的服务，允许用户处理和操作该表示。例如，Web 邮件客户机或 Portal Server 组件允许用户修改客户接收信息的表示。 

业务服务层

提供后端服务，这些服务通常从数据层检索数据，以提供给表示层或业务服务层内的其他服务，或直接提供给客户层的客户机。例如，Access Manager 向其他 Java Enterprise System 组件提供身份认证服务。 

数据层

提供由表示或业务服务层内的服务访问的数据库服务。例如，Directory Server 向其他服务提供 LDAP 目录访问。 

多层体系结构设计具有若干优点。在部署设计阶段，根据多层体系结构中的功能布置服务有助于确定在网络中分配服务的方式。还可看到体系结构中的组件如何访问其他组件的服务。这种直观性有助于规划服务解决方案的可用性、可伸缩性、安全性和其他性质。

逻辑体系结构示例

本节提供了一些 Java Enterprise System 解决方案的逻辑体系结构示例。这些示例首先说明如何在多层体系结构的适当层布置逻辑组件，然后通过研究使用案例，分析组件间的关系。将本节中的逻辑体系结构示例用作了解 Java Enterprise System 解决方案中逻辑体系结构设计的基础。

第一个示例是一个基本的 Messaging Server 解决方案，说明了 Messaging Server 的逻辑互异组件如何与其他组件交互操作。第二示例说明一个基于身份的部署解决方案的逻辑体系结构，该方案可适用于拥有 1,000 到 5,000 名员工的中型企业。

Messaging Server 示例

下图说明了一个 Messaging Server 部署的基本逻辑体系结构。该逻辑体系结构仅显示 Messaging Server 要求的逻辑互异组件。后面的图中介绍了这些组件的关系。

注 –

通常，Messaging Server 的部署是包括其他 Java Enterprise System 组件的企业解决方案的组成部分，如基于身份的通信示例中所示。

图 4–4 Messaging Server 部署的逻辑体系结构

示意图显示了在多层体系结构中部署的 Messaging Server 方案的逻辑组件。

下表介绍了Messaging Server 示例中显示的组件。

表 4–5 Messaging Server 逻辑体系结构中的组件

组件 

说明 

电子邮件客户机 

用于阅读和发送电子邮件的客户机应用程序。 

Messaging Server MTA

Messaging Server 配置为消息传送代理 (Message Transfer Agent, MTA)，以接收、路由、传输和发送电子邮件消息。 

Messaging Server MMP

Messaging Server 配置为消息多路复用器 (Message Multiplexor, MMP)，以路由至合适的消息存储的连接，进行检索和存储。MMP 访问 Directory Server，查找目录信息，以确定适合的消息存储。 

Messaging Server STR

Messaging Server 配置为消息存储，以进行电子邮件消息的检索和存储。 

Directory Server

提供对 LDAP 目录数据的访问。 

逻辑体系结构不为 Messaging Server 组件指定服务复制。例如，企业部署通常创建单独的入站和出站 MTA 实例，但Messaging Server 示例只显示一个 MTA 组件。将逻辑组件复制到多个实例是在部署设计阶段所作的设计决策。

Messaging Server 使用案例

使用案例帮助确定体系结构中的逻辑组件间的关系。根据使用案例映射组件间的交互，从而获得一个有助于部署设计的组件交互视图。

通常，在部署设计之前分析每个使用案例，以确定组件的交互。下述三个使用案例是 Messaging Server 的典型使用案例，显示了逻辑组件间的交互。

Procedure使用案例 1：用户成功登录到 Messaging Server

步骤

  1. 电子邮件客户机将登录信息发送到 Messaging Server Multiplexor (MMP)。

  2. MMP 向 Directory Server 请求用户 ID 和密码验证。

  3. Directory Server 将验证返回给 MMP。

  4. MMP 向 Messaging Server Message Store (STR) 请求消息列表。

  5. STR 向 Directory Server 请求用户的 LDAP 记录。

  6. Directory Server 将用户的 LDAP 记录返回给 STR。

  7. STR 将消息列表返回给 MMP。

  8. MMP 将消息列表转发给电子邮件客户机。

    显示使用案例 1 的 Messaging Server 组件间数据流的示意图。

Procedure使用案例 2：登录用户阅读和删除邮件

步骤

  1. 电子邮件客户机向 Messaging Server Multiplexor (MMP) 请求要阅读的消息。

  2. MMP 向 Messaging Server Message Store (STR) 请求消息。

  3. STR 将消息返回给 MMP。

  4. MMP 将消息转发给电子邮件客户机。

  5. 电子客户机将删除消息操作发送给 MMP。

  6. MMP 将删除消息操作转发给 STR。

  7. STR 将消息从数据库中删除，然后将确认发送给 MMP。

  8. MMP 将删除确认转发给电子邮件客户机。

    显示使用案例 2 的 Messaging Server 组件间数据流的示意图。

Procedure使用案例 3：登录用户发送电子邮件消息

步骤

  1. 电子邮件客户机将在客户机中编写的消息发送给 Messaging Server Message Transfer Agent (MTA)。

  2. MTA 向 Directory Server 请求用户 ID 和密码验证。

  3. Directory Server 将验证返回给 MTA。

  4. MTA 检查 Directory Server，获取每个收件人的目标域。

  5. Directory Server 将每个收件人的目标域返回给 MTA。

  6. MTA 将消息转发给每个收件人。

  7. MTA 将消息转发给 Messaging Server Message Store (STR)，在发件箱中存储消息。

  8. MTA 将确认发送给电子邮件客户机。

    显示使用案例 3 的 Messaging Server 组件间数据流的示意图。

基于身份的通信示例

此示例说明了面向拥有约 1,000 至 5,000 名员工的中型企业的基于身份的通信解决方案。通常，设计逻辑体系结构时需要彻底的业务分析及随后的详细的技术要求分析。但是，这是一个理论性示例，假定已确定以下业务需求：

此示例的使用案例将详细说明登录程序、阅读电子邮件、发送电子邮件、个性化门户、同步日历以及其他类似用户活动。

下图说明了此种基于身份的通信解决方案的逻辑体系结构。

此示意图显示了多层体系结构中部署的基于身份的通信方案的逻辑组件。

基于身份的通信示例的使用案例

对于此种性质的部署解决方案，通常存在大量概括说明用户与该解决方案所提供服务的交互作用的详细使用案例。此示例着重说明用户从浏览器客户机登录门户时组件间的交互。此示例将登录方案分为以下两个使用案例：

可将这两个使用案例视为一个扩展使用案例。但是在此示例中，为简单起见，单独对两个使用案例进行说明。

Procedure使用案例 1：用户成功登录后，门户检索用户的配置

步骤

  1. Web 浏览器客户机将用户 ID 和密码发送到 Portal Server。

  2. Portal Server 向 Access Manager 请求验证。

  3. Access Manager 向 Directory Server 请求用户 ID 和密码验证。

  4. Directory Server 验证用户 ID 和密码。

  5. Access Manager 向 Directory Server 请求用户配置文件。

  6. Directory Server 返回用户配置文件。

  7. Portal Server 向 Access Manager 请求用户显示配置文件。

  8. Access Manager 返回门户配置。

  9. 门户配置在浏览器客户机中显示。

    显示使用案例 1 的基于身份的通信方案组件间的数据流的示意图。

Procedure使用案例 2：门户服务器显示电子邮件和日历信息

步骤

  1. 在成功登录、验证、检索门户配置后，Portal Server 向 Messaging Server MMP 请求电子邮件消息。

  2. MMP 向 Messaging Server STR 请求消息列表。

  3. STR 将消息列表返回给 MMP。

  4. MMP 将消息标头转发给 Portal Server。

  5. Portal Server 向 Communications Express 请求日历信息。

  6. Communications Express 向 Calendar Server 后端请求日历信息。

  7. Calendar Server 后端将日历信息返回给 Communications Express。

  8. Communications Express 将日历信息转发给 Portal Server。

  9. Portal Server 将所有频道信息发送给 Web 浏览器客户机。

    显示使用案例 2 的基于身份的通信方案组件间的数据流的示意图。

访问区

另一种表示逻辑体系结构组件的方式是将其置于访问区中，这些访问区显示体系结构如何提供安全访问。下图说明了部署 Java Enterprise System 组件的访问区。每个访问区显示了组件如何提供与 Internet 和内联网间的安全远程访问。

图 4–5 置于访问区的逻辑组件

说明安全访问区内的 Java ES 组件布置的示意图。

下表介绍了访问区中显示的访问区。

表 4–6 安全访问区及置于其中的组件

访问区 

说明 

内部访问区 (Intranet)

通过由 Intranet 与 Internet 间的防火墙执行的策略访问 Internet。内部访问区通常用于最终用户进行 Web 浏览和发送电子邮件。 

有些情况下，允许直接访问 Internet 进行 Web 浏览。但是，通常与 Internet 间的安全访问由外部访问区提供。 

外部访问区 (DMZ)

提供与 Internet 间的安全访问，发挥关键后端服务的安全缓冲器的作用。 

安全访问区（后端）

提供对关键后端服务的受限访问，仅能从外部访问区访问这些服务。 

访问区未显示前面示例中所述的逻辑层，而是着重强调了提供远程和内部访问的组件、这些组件与安全措施（如防火墙）间的关系，以及必须执行的访问规则的直观显示。将多层体系结构设计与显示访问区的设计结合使用，提供规划部署的逻辑模型。

部署方案

完成的逻辑体系结构设计本身还不足以进入解决方案生命周期的部署设计阶段。还需将逻辑体系结构与技术要求阶段确定的服务质量 (quality of service, QoS) 要求配对组合。逻辑体系结构与 QoS 要求间的相互对应共同组成了部署方案。部署方案是部署体系结构设计的起点，如第 5 章，部署设计所述。