Sun Java Enterprise System 2005Q4 技术概述

第 2 章 Java Enterprise System 解决方案体系结构

本章概述了 Java Enterprise System (Java ES) 解决方案所基于的体系结构概念，说明 Java ES 组件（系统服务组件和服务质量组件）如何用于支持分布式企业解决方案。

Java ES 解决方案 architecture（体系结构）有两个层面：logical architecture（逻辑体系结构）和 deployment architecture（部署体系结构）。逻辑体系结构描绘解决方案逻辑构件（软件组件）之间的交互方式。部署体系结构描绘逻辑体系结构到物理计算环境的映射。Java ES 组件在逻辑体系结构和部署体系结构中都扮演着重要角色。

本章说明用于设计 Java ES 解决方案体系结构的体系结构框架，后面是基于该体系结构框架的示例解决方案体系结构。

本章介绍以下主题：

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 所示：

操作系统平台。为在计算机上运行的任何进程提供基本支持。操作系统（如 Solaris^TM 操作系统、Linux 或 Microsoft Windows）管理着物理设备以及内存、线程和支持 Java 虚拟机（Java Virtual Machine，JVM^TM 机）所需的其他资源。
网络传输。为不同计算机上运行的分布式应用程序组件间的通信提供基本联网支持。这些服务包括对诸如 TCP 和 HTTP 等协议的支持。其他较高级别的通信协议（请参阅消息层）依赖于这些基本传输服务。
持久性。为访问和存储静态数据（如用户、目录或配置的信息）及动态应用程序数据（经常更新的信息）提供支持。
消息传送。为应用程序组件间的同步及异步通信提供支持。同步消息传送是实时消息收发；它包括 J2EE 组件间的远程方法调用 (RMI) 以及 SOAP 与 Web 服务的交互。异步消息传送是指这样的一种通信：消息的发送不依赖于使用者是否已准备好立即接收该消息。异步消息传送规范（例如，“Java 消息服务”(Java Message Service, JMS) 和 ebXML）支持可靠性保障及其他消息传送语义。
运行时环境。提供任何分布式组件模型（如 J2EE 或 CORBA 模型）所需的支持。除了紧耦合分布式组件所需的远程方法调用之外，运行时服务还包括组件状态（生命周期）管理、线程池管理、同步（互斥锁定）、持久性服务、分布式事务监视以及分布式异常处理。在 J2EE 环境中，这些运行时服务由应用程序服务器或 Web 服务器中的 EJB^TM、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（J2EE^TM 平台）组件模型实现的应用程序组件。但是，其他分布式组件模型（如 CORBA）也可支持此体系结构。

客户层。客户层由最终用户通过用户界面直接访问的应用程序逻辑组成。客户层中的逻辑可以包括基于浏览器的客户机、在台式计算机上运行的 Java 组件，或是在手持设备上运行的 Java 2 Platform, Micro Edition（J2ME^TM 平台）移动客户机。
表示层。表示层由应用程序逻辑组成，应用程序逻辑负责准备要传送给客户层的数据并处理来自客户层的请求，以便传送给后端业务逻辑。表示层中的逻辑通常由 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 服务质量组件以及受影响的系统质量


组件	受影响的系统质量
Communications Express	安全性可伸缩性
Directory Proxy Server	安全性可伸缩性
High Availability Session Store	可用性
Portal Server Secure Remote Access	安全性可伸缩性
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 数据服务包（有时称为 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 的软件解决方案时，理解三维体系结构框架强调的各设计层面很重要。

Java Enterprise System 解决方案体系结构示例

Java Enterprise System 支持范围广泛的软件解决方案。

使用 Java Enterprise System 中的组件，许多解决方案出厂时已完成设计和部署，不需要再执行开发工作。另一些解决方案可能需要大量的部署工作，需要部署提供新业务或表示服务的定制 J2EE 组件。您可以将这些定制的组件封装成符合简单对象访问协议 (Simple Object Access Protocol, SOAP) 接口标准的服务。许多解决方案需要综合这两种方法。

本节为您举例说明 Java Enterprise System 如何支持开盒即用解决方案，以上一节介绍的体系结构概念为基础。

企业通信方案

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

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

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


业务需求	说明	需要的 Java ES 服务
单点登录	基于单一身份和访问的单点登录访问安全企业资源和服务。	身份认证服务
消息传送日历	员工内部以及与外部的电子邮件通信。电子式员工日程和会议安排。	通信和协作服务
门户访问	基于 Web 的个性化单点登录至通信服务，如电子邮件、日历以及内部网页。	门户服务

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

示例方案的逻辑体系结构

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

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

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

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

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

有关 Java ES 解决方案逻辑设计的更多信息，参见《Sun Java Enterprise System 2005Q4 部署规划指南》。

示例方案的部署体系结构

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

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

有关 Java ES 解决方案部署设计的更多信息，参见《Sun Java Enterprise System 2005Q4 部署规划指南》。

本章的主要术语

本节说明本章使用的主要技术术语，主要是阐述这些术语之间的关系以及它们在 Java Enterprise System 上下文中是如何使用的。

application component（应用程序组件）: 定制开发的软件 component（组件），执行某些特定的计算功能，为 end user（最终用户）或其他应用程序组件提供 business service（业务服务）。应用程序组件通常符合分布式组件模型（如 CORBA 和 J2EE^TM 平台）。这些组件可以单独或联合封装成 web service（Web 服务）。
architecture（体系结构）: 一种设计，展示了分布式应用程序（或其他某个软件系统）的逻辑和物理构件及其相互关系。对于 distributed enterprise application（分布式企业应用程序）而言，体系结构设计通常同时包括应用程序的 logical architecture（逻辑体系结构）和 deployment architecture（部署体系结构）
business service（业务服务）: application component（应用程序组件）或组件的集合体，代表多个客户机执行业务逻辑（因而是一个多线程进程）。业务服务也可以是作为 web service（Web 服务）封装起来的分布式组件的集合体，还可以是独立的 server（服务器）。
client（客户机）: 请求软件 service（服务）的软件。（注：此术语并非指人 — 参见 end user（最终用户）。）客户机可以是请求另一服务的某项服务，或者是最终用户所访问的某个 GUI 组件。
deployment architecture（部署体系结构）: 一种高层次设计，描绘了 logical architecture（逻辑体系结构）到物理计算环境的映射。物理环境包括内联网或 Internet 环境中的计算机、它们之间的网络链路以及支持软件所需的其他物理设备。
logical architecture（逻辑体系结构）: 一种设计，描绘了分布式应用程序的逻辑构件以及这些构件之间的关系（或接口）。逻辑体系结构包括分布式 application component（应用程序组件）以及支持这些组件所需的基础结构服务组件。
server（服务器）: 一种多线程软件进程（有别于硬件服务器），为通过外部接口访问服务的 client（客户机）提供分布式 service（服务）或一组紧密结合的服务。
web service（Web 服务）: 一种服务，它符合为实现可访问性、服务封装和发现功能而制订的标准化 Internet 协议。这些标准包括 SOAP（Simple Object Access Protocol，简单对象访问协议）消息传送协议、WSDL（Web Service definition Language，Web 服务定义语言）接口定义以及 UDDI（Universal Discovery, Description, and Integration，通用发现、描述和集成）注册标准。