Java ES 解决方案体系结构示例

Java ES 支持的软件解决方案的范围很广泛。使用 Java ES 中的组件，许多解决方案现成即可进行设计和部署，不需要再执行开发工作。其他一些解决方案可能需要大量的开发工作，需要您开发用于提供新业务或表示服务的自定义 J2EE 组件。您可以将这些自定义组件封装成符合 SOAP 接口标准的 Web 服务。许多解决方案需要综合这两种方法。

本节从上一节介绍的体系结构概念出发，为您举例说明 Java ES 如何支持现成可用解决方案。

企业通信方案

企业通常需要支持员工之间的通信，特别是电子邮件和日历服务。这些企业发现，基于企业级验证和授权服务授予员工个性化的内部网站访问方式是一种很有用的方法。此外，这些企业需要在所有企业服务中跟踪员工身份，这样单点登录便可访问所有这些服务。

下表简要列出了这些特定的业务需求（仅是举例示范的一组业务需求）。

表 2–4 业务需求摘要：通信方案

业务需求	说明	需要的服务
单点登录	使用单点登录功能访问基于单一身份的安全企业资源和服务，以实现 Web 访问	身份认证服务
消息传送  日历	员工内部以及与外部的电子邮件消息传送  电子式员工日程和会议安排	通信和协作服务
Portal 访问	针对电子邮件、日历以及内部 Web 页等通信服务的单一、基于 Web 的个性化访问	Portal 服务

此外，企业对于提供这些服务的软件系统还有性能、可用性、网络安全以及伸缩性等方面的要求。

示例方案的逻辑体系结构

下图显示了使用 Java ES 组件和 Sun Java Communications Suite 组件（Messaging Server、Calendar Server、Instant Messaging 等等）提供表 2–4 中确定的 portal 服务、通信服务以及身份认证服务的逻辑体系结构。该体系结构在逻辑上将不同的 Messaging Server 配置视为独立的组件，因为它们各自提供不同的服务。

图 2–6 企业通信方案的逻辑体系结构

各组件分别放置在表示标准逻辑层的水平维中以及表示基础结构服务级别的垂直维中。组件之间的交互取决于它们作为分布式基础结构服务的功能（基础结构服务级别之间的交互）或它们在分层应用程序体系结构中的角色（逻辑层内部及逻辑层之间的交互）。

在此体系结构中，Access Manager 可访问 Directory Server 中存储的用户信息，是 Portal Server 和表示层中其他基于 Web 的组件的单点登录验证和授权的仲裁程序。Messaging Server 组件包括数据层中的消息存储区 (Messaging Server-STR)、业务服务层中的发送和检索组件以及表示层中的 HTTP 访问组件和 Communications Express。

此逻辑体系结构还显示了不同组件之间的基础结构服务依赖性。例如，Portal Server 的消息传送和日历频道依赖于 Communications Express，验证和授权服务依赖于 Access Manager。这些组件反过来又依赖于 Directory Server 获得用户信息和配置数据。许多组件都需要由 Web Server 提供的 Web 容器服务。

有关 Java ES 解决方案逻辑设计的更多信息，参见《Sun Java Enterprise System Deployment Planning Guide》。

示例方案的部署体系结构

在从逻辑体系结构转移到部署体系结构的过程中，服务质量的要求变得极为重要。例如，受保护的子网和防火墙可用来创建后端数据的安全屏障。对于许多组件而言，通过在多台计算机上部署它们并使用负载平衡器在已复制的组件之间分配请求，可以满足可用性和可伸缩性要求。

但是，如果有较为苛刻的可用性要求或需要大量的磁盘存储空间，其他可用性解决方案会更合适。例如，Sun Cluster 可用于 Messaging Server 存储，多主复制可用于 Directory Server。

有关 Java ES 解决方案部署设计的更多信息，参见《Sun Java Enterprise System Deployment Planning Guide》。