oracle weblogic serverimages.china-pub.com/ebook60001-65000/61112/ch02.pdf · oracle weblogic...

40
2 Oracle WebLogic Server 在讨论 Oracle Fusion Middleware 架构之前,先详细介绍一下 Oracle WebLogic Server由于 WebLogic Server 是构建所有基于 Java EE Oracle Fusion Middleware 组件的基础, 因此深入理解它对于所有 Fusion Middleware 系统架构师来说至关重要。 WebLogic Server 是第一个完全满足规范的 Java EE(当时称为 J2EE)应用程序服务器。该产品非常成熟,具 有许多功能,并且通过测试和大量关键业务企业应用程序对这些性能进行了强化。本章 的目的不是分析所有这些功能,而是概要介绍 WebLogic Server 及其主要子系统,重点介 绍主要架构概念和它们提供的管理功能。 本章先介绍一些关键的管理概念,然后介绍 WebLogic Server 的应用程序容器。这些 容器主要抽象对企业应用程序的部署和管理。在详细描述 WebLogic Server 的管理功能和 工具之后,再介绍 WebLogic Server 的容器服务,它们让应用程序能够实现高级数据库连

Upload: others

Post on 12-Oct-2020

24 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Oracle WebLogic Serverimages.china-pub.com/ebook60001-65000/61112/ch02.pdf · Oracle WebLogic Server 在讨论Oracle Fusion Middleware架构之前,先详细介绍一下Oracle WebLogic

第 2 章

Oracle WebLogic Server

在讨论Oracle Fusion Middleware架构之前,先详细介绍一下Oracle WebLogic Server。

由于 WebLogic Server 是构建所有基于 Java EE 的 Oracle Fusion Middleware 组件的基础,

因此深入理解它对于所有 Fusion Middleware 系统架构师来说至关重要。WebLogic Server

是第一个完全满足规范的 Java EE(当时称为 J2EE)应用程序服务器。该产品非常成熟,具

有许多功能,并且通过测试和大量关键业务企业应用程序对这些性能进行了强化。本章

的目的不是分析所有这些功能,而是概要介绍 WebLogic Server 及其主要子系统,重点介

绍主要架构概念和它们提供的管理功能。

本章先介绍一些关键的管理概念,然后介绍 WebLogic Server 的应用程序容器。这些

容器主要抽象对企业应用程序的部署和管理。在详细描述 WebLogic Server 的管理功能和

工具之后,再介绍 WebLogic Server 的容器服务,它们让应用程序能够实现高级数据库连

Page 2: Oracle WebLogic Serverimages.china-pub.com/ebook60001-65000/61112/ch02.pdf · Oracle WebLogic Server 在讨论Oracle Fusion Middleware架构之前,先详细介绍一下Oracle WebLogic

第Ⅰ部分 Oracle Fusion Middleware 11g 架构与管理

14

接管理、消息发送和安全性能。最后讨论 WebLogic Server 的线程模型和本书所有章节使

用的用例,该用例在实践示例的上下文中将本章介绍的一些主要概念串在一起。

2.1 Oracle WebLogic Server 简介

服务器实例、域和群集的概念是理解 WebLogic Server 的基础,下面简要介绍这些概

念,然后讨论 WebLogic Server 安装和域组件,最后简要介绍域启动选项。

2.1.1 服务器、群集和域

WebLogic Server 实例是一个执行代码的 Java 虚拟机(Java Virtual Machine,JVM)进

程,它提供所有 API 和 Java EE 规范授权的服务,以及 WebLogic 的特定扩展。使用 Java

EE 规范的开发团队创建了 Java 应用程序,WebLogic 特有的 API 被部署到服务器实例并

由它执行。服务器实例的主要组件如图 2-1 所示。

本章将介绍与图 2-1 中所示各组件相关联的核心概念。

请求管理服务

Web 容器 Web 服务容器 EJB 容器 JCA 容器

部署容器

JMS 服务 JDBC 服务

安全服务

Java 运行时环境

WebLogic Server 实例

图 2-1 WebLogic Server 组件

每个 WebLogic Server 实例都是 WebLogic Server 域的一部分,它是一组服务器的管

理分组和配置范围划分机制。通过名为域管理(admin)服务器的专门服务器实例来管理、

配置和监控域。管理服务器和域内其他服务器实例一样,但它配置了一组特定目的的应

用程序,以实现如下功能。

● 管理域内所有服务器的配置信息,并作为该信息同步的中心点。也就是说,所有

受管理服务器都从管理服务器获得最新配置。

Page 3: Oracle WebLogic Serverimages.china-pub.com/ebook60001-65000/61112/ch02.pdf · Oracle WebLogic Server 在讨论Oracle Fusion Middleware架构之前,先详细介绍一下Oracle WebLogic

第 2 章 Oracle WebLogic Server

15

● 提供基于浏览器的管理控制台应用程序,用来管理域及其服务器的配置。

除了管理服务器之外,域内其他所有WebLogic Server实例都称为受管理服务器。Java

EE 应用程序通常部署在满足需要的受管理服务器上,而管理服务器只用于管理。然而,

域也可能由单个管理服务器(没有受管理服务器)组成,并被用做部署 Java EE 应用程序的

目标。然而,这种设置通常只在开发环境中使用,其目的是为了方便和优化硬件资源。

可以将域内的服务器组成 WebLogic Server 群集。一个域可以包含一个或多个群集,

而服务器只能是某个群集中的一员。在部署时,如果将应用程序定位到群集,那么就会

将它部署到群集内的所有服务器。同样,某些域配置资源—— 如本章稍后介绍的 JMS 模

块—— 也可以定位到群集。在更高层次上,群集为驻留其上的应用程序带来的主要好处

是,通过将应用程序部署到多个服务器,能够提高可扩展性和可用性。不能到达请求的

原始服务器目标时,WebLogic Server 群集也能够将自动将客户请求转移给群集里的另一

个服务器,而不会丢失客户状态。

上面简要介绍了服务器、域和群集,图 2-2 阐明它们之间的关系。正如所见,图 2-2

还包含一个名为“节点管理器”的实体,该进程用于监控和管理服务器实例。本章稍后

将详细介绍节点管理器,但现在先讨论 WebLogic Server 安装过程、安装内容和域目录。

主机 2

管理服务器

受管理服务器 1 受管理服务器 2

节点管理器 节点管理器

群集

主机 1

图 2-2 服务器、域和群集之间的关系

2.1.2 安装和域组件

通过 WebLogic 安装工具安装 WebLogic Server 组件,并指定下面两个目录路径。

● 顶级安装目录:常用 WebLogic Server 组件(JDK、实用程序等)安装在该目录下。

该目录被称为中间件总部(middleware home)。以下将该目录称为 MW_HOME,

它是一个环境变量,在 WebLogic Server 运行时环境中将目录的路径指定给该变

量。通过运行域的 setDomainEnv.cmd 或.sh 命令,可以初始化该环境变量。

Page 4: Oracle WebLogic Serverimages.china-pub.com/ebook60001-65000/61112/ch02.pdf · Oracle WebLogic Server 在讨论Oracle Fusion Middleware架构之前,先详细介绍一下Oracle WebLogic

第Ⅰ部分 Oracle Fusion Middleware 11g 架构与管理

16

● 安装 WebLogic Server 专有二进制文件(如 JAR 文件、数据文件、第三方库和构

成产品的其他所有软件)的顶级安装目录。该目录称为 WebLogic home,以下将

该目录称为 WL_HOME,它是一个环境变量,在 WebLogic Server 运行时环境中

为该变量指定目录的路径。

MW_HOME 内的 WebLogic Server 安装作为其他所有基于 Java EE Fusion Middleware

产品的基本应用程序服务器,因此这些产品有时也称为分层 Oracle Fusion Middleware 产

品。虽然安装程序并不强制要求,但基于 WebLogic Server 构建的分层 Oracle Fusion

Middleware 产品(如 Oracle SOA Suite)希望创建 WLHOME 目录作为其 MW_HOME 目录

的子目录。

说明

为了确保 WebLogic Server 安装可用作其他分层 Oracle Fusion Middleware 产品的基

础,要确保让 WLHOME 目录的位置使用 WebLogic 安装程序提供的默认选项(即作为

MWHOME 目录的子目录)。

表 2-1 给出了 MWHOME 和 WLHOME 目录下最重要的路径。

表 2-1 WebLogic Server 安装目录结构

目录/文件名 描 述

MW_HOME/jdkNNN 与

MW_HOME/ jrockitNNN

Oracle Java HotSpot JDK 和 Oracle JRockit JDK,它们都可通过

WebLogic 安装用作 Java 运行时

MW_HOME/logs WebLogic Server 安装程序和配置向导的日志目录。安装程序日志

文件位于文件 log.txt 里,并包含安装组件的详细目录。每个配置向

导会话都会产生单独的日志文件,其格式如下:wlsconfig_

<time_stamp>

MWHOME/modules 包含 WebLogic Server 运行时使用的 OSGi 模块。OSGi 是一个组件

模型,它能够模块化 Java 应用程序。WebLogic Server 使用 OSGi

组件模型来构建其内部模块。讨论 OSGi 和 WebLogic Server 相关

模块化超出了本书的范围,其对于理解 Oracle Fusion Middleware

架构也不是必需的

MW_HOME/utils 包含安装和域配置实用程序工具。该目录里包含的主要实用程序工

具有 WebLogic Smart Update 和 Oracle Configuration Manager。

WebLogic Smart Update 用于修补 WebLogic Server 安装,Oracle

Configuration Manager 是一种 Oracle 服务,如果在安装时配置,它

将定期从安装和配置域收集配置信息,并将这些信息发送回 Oracle

支持,以便通过 My Oracle Support 入口扩展支持管理功能。

Configuration Framework 由域配置向导和其他域管理工具使用,本

章稍后将详细讨论

Page 5: Oracle WebLogic Serverimages.china-pub.com/ebook60001-65000/61112/ch02.pdf · Oracle WebLogic Server 在讨论Oracle Fusion Middleware架构之前,先详细介绍一下Oracle WebLogic

第 2 章 Oracle WebLogic Server

17

(续表)

目录/文件名 描 述

MW_HOME/domain-registry.xml 域配置工具维护的文件,其目的是跟踪安装中创建的域。该文件用

于简化可能需要域调整的修补程序,如果配置向导无法写入,也不

会丢失操作

MW_HOME/registry.xml 安装工具维护的文件,其目的是记录给定 MW_HOME 目录内安装

的所有产品

WLHOME/common 包含常见 WebLogic Server 组件,其中最重要的是 WebLogic Server

节点管理器、WebLogic Server Scripting Tool 以及安装的域创建和

扩展模板。本章后面将详细讨论这 3 个组件

WL_HOME/server 包含 Java 库和二进制文件,它们构成从 WebLogic Server 域执行的

WebLogic Server 组件的功能

从表 2-1 中 WebLogic Server 目录的内容可以看出,安装 WebLogic Server 不会产生

可执行程序(它再要求“运行安装程序”)。因为 WebLogic Server 架构最重要的一点就是

分离服务器环境的配置,通过域的概念,从 WebLogic Server 可执行的二进制文件中抽象

配置。因此 WebLogic Server 实例总是从域的上下文运行,必须通过安装工具在安装完

WebLogic Server 二进制文件之后创建它们。安装二进制文件和域配置明显分离有两个重

要含义。首先,WebLogic Server 域目录可以在文件系统的任何位置创建,并且不必放置

在与安装目录相关的特定路径里。域目录与其安装二进制文件之间的唯一联系是环境变

量,它们在服务器启动时设置,并指向安装目录的 Java 库。其次,从单个安装目录里可

以创建任意数量的域。换句话说,WebLogic Server 安装和使用它的域的数量之间是一对

多的关系。域功能的唯一标准是通过运行服务器可以访问它引用的安装目录。

创建域之后(本章后面将详细分析完成创建的各种方法),其顶级目录称为域 home(下

面称为 DOMAIN_ HOME,这是一个环境变量,在 WebLogic Server 环境中将目录的路径

赋值给它)。DOMAIN_HOME 是域中所有服务器实例的工作区,这些实例从该工作区执

行;因此,理解它包含的各个子目录及用法至关重要。表 2-2 给出了 DOMAIN_HOME

目录下的一些最重要路径。

表 2-2 WebLogic Server 域目录结构

目 录 名 称 描 述

bin 包含用来启动和停止域服务器和节点管理器的脚本

config 包含域的部署和配置信息。配置信息保存在 config.xml 文件和组件专用的 XML 文件

里,该文件从 config.xml 文件引用,并位于子目录里。config.xml 文件包含全局域配

置值,在 JDBC、JMS 和 Diagnostics 子目录里引用配置元素,这些子目录包含相关

的域范围内模块的配置。服务器实例使用 Deployment 子目录来管理以分期模式部署

的应用程序。本章后面将详细介绍服务器的部署模式

Page 6: Oracle WebLogic Serverimages.china-pub.com/ebook60001-65000/61112/ch02.pdf · Oracle WebLogic Server 在讨论Oracle Fusion Middleware架构之前,先详细介绍一下Oracle WebLogic

第Ⅰ部分 Oracle Fusion Middleware 11g 架构与管理

18

(续表)

目 录 名 称 描 述

lib 该目录用来扩展服务器类路径。目录里的所有 JAR 文件都被加载为系统类路径直接

子类加载器(class-loader)的一部分,因此,实现的效果与将 JAR 文件添加到整个域的

运行服务器的系统类路径完全相同。只有确实需要将有问题的 JAR 文件扩展到服务

器的系统类加载器时才使用该目录(例如,用于 JDBC 驱动程序 JAR 文件)

servers 包含每个服务器的子目录,该服务器是域的一部分,并且在使用该域目录的主机上

执行。各服务器使用该目录输出日志,保存其复制的嵌入式 LDAP 服务器数据,本

章后面将详细讨论

2.1.3 服务器启动和节点管理器

如前所述,可从域的上下文启动 WebLogic Server,启动域就意味着启动一个或多个

域所配置的服务器实例。WebLogic Server 实例通过域 bin 目录里的 startWebLogic.cmd 和

startManagedWebLogic.cmd 启动脚本(在 UNIX 系统中则是.sh 脚本)启动。第一个脚本用

于启动域的管理服务器,第二个脚本则用于通过提供管理服务器 URL 和要启动的受管理

服务器的名称作为参数,来启动域的任意受管理服务器。生成这些脚本是域创建过程的

一部分。每个脚本首先都要初始化许多环境变量,在 Java 命令行中这些变量用作执行

WebLogic Server 代码的实参,如类路径、Java 选项(如内在实参)和 Java 运行时主目录(home

directory)。还需要注意,启动脚本本身不初始化任何环境变量。相反,这两个启动脚本

都调用 DOMAIN_HOME/bin/setDomainEnv.sh|.cmd 脚本,它再调用 WL_HOME/common/

bin/commEnv.sh|.cmd 脚本。setDomainEnv.sh 脚本初始化域的专用环境变量,如 DOMAIN_

HOME,并且确定服务器是以开发模式运行还是以生产模式运行。commEnv.sh 脚本初始

化用于所有域的变量,例如默认的 JAVA_ HOME 和 WebLogic Server 所需的 Java 命令行

属性。每个脚本的最后一步都是执行 Java 命令,以便使用初始化后的环境变量启动

WebLogic Server。

说明

通过直接修改域的/bin 目录内启动脚本位置,可以修改类路径、Java 运行时和WebLogic

Server 使用的 Java 选项。不建议以这种方式修改服务器类路径,因为 WebLogic 提供了

许多更加精细的方法确保正确扩展服务器的类路径。

要成功启动,服务器实例还需要用户的用户名和口令,并且该用户在域的安全领域

有 Admin 角色权限。2.4 节将详细讨论安全领域的概念及如何管理用户和角色。但在服

务器启动上下文中,知道有两种方法可以将所需的证书提供给服务器就足够了。

● 通过-Dweblogic.management.username=<username>and-Dweblogic.management.password

=<password> Java 命令行选项。

Page 7: Oracle WebLogic Serverimages.china-pub.com/ebook60001-65000/61112/ch02.pdf · Oracle WebLogic Server 在讨论Oracle Fusion Middleware架构之前,先详细介绍一下Oracle WebLogic

第 2 章 Oracle WebLogic Server

19

● 通过 DOMAIN_HOME/server/ <server-name>/security 目录里的 boot.properties 文

件,它包含两个属性——username 和 password。各服务器实例在启动时读取该文

件,如果用纯文本指定属性的值,则服务器自动加密该值,并将它重写到文件。

上面讨论了 WebLogic Server 域的服务器如何通过启动脚本实现手动启动。但完整讨

论服务器启动还需要介绍 WebLogic Server 节点管理器,它能够自动且远程启动域服务

器。节点管理器是个进程,它在每个驻留一个或多个 WebLogic Server 域的物理机器上运

行。通过驻留在各主机上的节点管理器,可以将域配置为自动启动它们的受管理服务器。

为此,必须将 Java 启动命令发送到域的管理服务器,admin 服务器再将该命令发送到节

点管理器,并在该节点管理器上配置目标受管理服务器来执行。对于受管理服务器而言,

为了使远程主机节点管理器的管理服务器远程能够启动它们,需要给管理服务器配置受

管理服务器的启动类路径、Java 运行时、Java 选项和证书。管理服务器再将这些信息传

递给节点管理器,执行受管理服务器的 Java 命令行。需要注意的是,当以这种方式用节

点管理器启动受管理服务器时,在默认情况下没有使用它们的启动脚本,以及它们自定

义的所有启动参数。

说明

用节点管理器来启动受管理服务器时,对域的启动脚本所做的所有自定义默认都没

使用。如果已经自定义启动脚本,并且要使用节点管理器,则可以考虑使用节点管理器

的 StartScriptEnabled 形参。

受管理服务器独立

要详细讨论服务器启动功能,必须讨论一个重要元素,这个元素与域和受管理服务

器以及管理服务器之间的依赖性有关。受管理服务器启动时,它首先尝试连接到域的管

理服务器,以便检索最新的域配置。如果不能访问管理服务器,受管理服务器则以受管

理服务器独立模式的状态启动操作,默认情况下所有服务器都会激活这种模式。在这种

模式中,受管理服务器使用已经访问的本地 config.xml 文件作为域配置的临时来源。当

管理服务器能够再次连接受管理服务器时,再刷新受管理服务器的配置信息。

到现在为止已经讨论完构成 WebLogic Server 域的主要组件。但要使用它们,还必须

为能够部署它们的应用程序自定义域。在运行时,部署的应用程序在不同的域服务和功

能上下文中执行,它们一起称为应用程序容器。2.2 节将详细分析 WebLogic Server 应用

程序部署和应用程序容器。

2.2 应用程序容器和部署

Java EE 应用程序的行为和生命周期操作不仅是其自定义部署逻辑的功能,也是其相

关运行时容器的配置功能。本节将简要介绍 WebLogic Server 应用程序容器及其部署。

WebLogic Server、Oracle Coherence 和 ActiveCache

Oracle Coherence 提供内存数据群集。Coherence 能够分割群集内存缓存里的应用程

Page 8: Oracle WebLogic Serverimages.china-pub.com/ebook60001-65000/61112/ch02.pdf · Oracle WebLogic Server 在讨论Oracle Fusion Middleware架构之前,先详细介绍一下Oracle WebLogic

第Ⅰ部分 Oracle Fusion Middleware 11g 架构与管理

20

序数据。使用 Oracle Coherence 主要有以下两个好处。

● 提高性能 通过缓存应用程序堆内存空间里共享数据源(通常是 RDBMS)里的数

据实现性能的提高。

● 线性可扩展性 通过扩展群集的数据栅格内的数据实现。Coherence 的分布式缓

存考虑到群集内各单个应用程序 JVM 的数据数量随着群集大小的增加而减小,

同时确保群集里各应用程序数据访问不超过一个远程调用延时。

WebLogic Server 通过名为 ActiveCache 的特性与 Coherence 紧密集成。ActiveCache

允许通过域的管理工具创建和管理 Coherence 群集。部署到 WebLogic Server 域的应用程序

使用 ActiveCache可以直接访问 coherence群集。ActiveCache还能够与名为 Coherence*Web

的 Coherence 特性集成,该特性允许部署到 Java EE 应用程序服务器的 Web 应用程序使

用 Coherence 群集,而不是 WebLogic Server 默认会话复制机制来复制它们的 HTTP 会话

数据。使用 Coherence*Web 能够更有效地管理包含大量会话数据的应用程序的会话复制。

Coherence*Web 还可用来实现增强的会话状态可靠性,并允许在不同 Web 应用程序之间

共享 HTTP 会话。对 Coherence 和 ActiveCache 的详细讨论超出了本书的范围。关于

ActiveCache 的更多信息请参考 Fusion Middleware 文档库里的 Using ActiveCache 文档。

2.2.1 应用程序容器

如图 2-1 所示,在最高层次,WebLogic Server 的应用程序容器可分为如下类别:

● Web 容器

● Enterprise Java Beans(EJB)容器

● Web Services 容器

● Java Connector Architecture(JCA)容器

应用程序开发人员依据与这些容器相关的规范来构建自己的应用程序,当将这些应

用程序部署到 WebLogic Server 时,将在其关联的运行时服务里执行它们。本节将介绍前

3 个应用程序容器,讨论它们支持的接口、部署组件生命周期和事务管理功能。本节还

将讨论各容器的关键部署时配置形参,在构建和管理其依赖应用程序时需要考虑它们。关

于 WebLogic Server 的 JCA 容器的讨论超出了本书的范围,虽然允许将它部署到 WebLogic

Server 的 Java EE 应用程序与外部系统通信(通常基于非标准)。而 Oracle Fusion Middleware

Service-Oriented Architecture(SOA)Suite 与 JCA 适配器打包在一起,并可以开箱即用,第

5 章将详细讨论它们。

1. Web 容器

HTTP servlet 和 Java Server Pages(JSP)是主要的 Java EE 规范,用于开发在 Web 应用

程序容器里调整运行的应用程序。对于 Web 应用程序开发人员来说,JSP 可以使他们更

方便地关注 Model-View-Controller(MVC)基于 Web 的应用程序的视图元素,再将它们编

译到 servlet(伺服小程序)用于运行时执行。框架和规范还有一个变体可以简化 MVC 基于

Web 应用程序的开发(例如 Oracle 应用程序开发框架,第 6 章将详细讨论),但最终从运

行时执行的角度来看,这些框架的最终构造都是一组 HTTP servlet,它们处理基于 HTTP

Page 9: Oracle WebLogic Serverimages.china-pub.com/ebook60001-65000/61112/ch02.pdf · Oracle WebLogic Server 在讨论Oracle Fusion Middleware架构之前,先详细介绍一下Oracle WebLogic

第 2 章 Oracle WebLogic Server

21

的请求和响应。

Servlet 本身是无状态的,Web 应用程序管理客户端状态的方法是通过 HTTP 会话对

象,给它分配一个初始 ID,并通过 HTTP 缓存保存在客户端,其默认名称是 JSESSIONID。

对于所有余下的请求,客户端—— 在大多数情况下是 Web 浏览器—— 传递请求里的 ID,

servlet 代码再用它来查找关联的会话状态。HTTP 会话状态由 Web 容器管理,其行为由

许多参数在域和部署描述符层控制。WebLogic Server 也具有群集会话复制性能,以提高

部署到它的 Web 应用程序的可用性和可靠性。但讨论 WebLogic Server 会话复制功能超

出了本书的范围。通过 weblogic.xml 部署描述符来控制 Web 容器的 HTTP 会话管理配置

的主要类别。最常修改的部署描述符属性是那些设置客户会话合法时长的属性和控制会

话持续功能的属性。

Servlet 的默认生命周期由创建 servlet 的单个实例的 WebLogic Server 组成,该 servlet

用于并行处理所有传入的请求。虽然这种情况不常见,但是也可能开发一个 Web 应用程

序,这样每个传入的请求都将实例化新的 servlet 对象。在这种情况下,WebLogic Server

在启动时将启动一批 servlet 实例,用来传入为请求服务,如果池内的实例全部用完,则

开始启动新的 servlet。weblogic.xml <single-threaded-servlet-pool-size>元素的值用来控制

servlet 池的初始大小。最后还需要注意的是,servlet 不知道事务,因为没有为它们提供

容器事务处理功能。

2. Enterprise Java Bean 容器

Enterprise Java Bean(EJB)是主要的 Java EE 规范,用于在 Java EE 应用程序服务器上

下文中创建安全可扩展的事务业务逻辑。WebLogic Server 同时提供 EJB 2.1 和 EJB 3 容

器功能。提供 EJB 2.1 容器功能主要出于兼容性考虑,本书不再进一步讨论。作为 EJB 2.1

的替代品,WebLogic Server 的 EJB 3 容器功能主要包括以下方面。

● 作为 Pitchfork 项目的一部分,与 SpringSource 联合开发的 EJB 3 Stateless/Stateful

Session Beans 和 Message Driven Beans 容器。

● 通过两种不同的 Java Persistence API(JPA)实现方式,支持 Java 对象关系映射:

Kodo 和 TopLink。在 WebLogic Server 中 Kodo 是默认的 JPA 提供者;而 TopLink

是 Oracle 的战略 JPA 实现方式,是 WebLogic Server 默认 JPA 提供者的替代方

式。本节只讨论标准的 JPA 配置方面(实现方式不讨论)。

下面将详细讨论 WebLogic Server EJB 容器的各种功能。

Stateless、Stateful 和 Message Driven Beans Stateless Session Beans(SLSB)和

Stateful Session Beans (SFSB)提供一个接口,能够用来配置本地调用和远程调用。本地调

用只能由模块在 EJB 的相同部署存档(本章稍后将详细讨论部署存档文件和结构)中实

现,因此不需要考虑任何系统级或部署时配置。但如果这种 EJB 提供客户在存档文件之

外使用的接口—— 不管该客户本身是部署到相同服务器/群集还是完全在域之外—— 就要

考虑远程调用以及下面两个部署时。

Page 10: Oracle WebLogic Serverimages.china-pub.com/ebook60001-65000/61112/ch02.pdf · Oracle WebLogic Server 在讨论Oracle Fusion Middleware架构之前,先详细介绍一下Oracle WebLogic

第Ⅰ部分 Oracle Fusion Middleware 11g 架构与管理

22

● 使用 WebLogic 的私有 T3 协议或者通过标准的 IIOP 协议,可以实现 EJB 接口的

远程调用。WebLogic Server 的默认协议是 T3,WebLogic Server 默认配置为处

理 T3 请求。然而,如果是 IIOP 客户,就需要将部署 EJB 的服务器配置为管理

传入的 IIOP 请求,如表 2-3 中“IIOP 访问”这一行所示。一般情况下 T3 协议

效率更高,但如果需要与在其他环境(不同于 WebLogic Server)中运行的客户进

行互操作,IIOP 协议则可能是更好的选择。

● 远程客户通过查找服务器的 JNDI 树来访问 EJB。EJB 的服务与其客户的集成要

求 EJB 客户使用的 JNDI 查找名称和 EJB 提供的 JNDI 名称同步。因此重要的是

知道如何配置这些参数,如表 2-3 中“JNDI 映射”和“JNDI 引用”这两行所示。

SLSB 的实例化由 WebLogic Server 汇集(pooling),以便节省为每个实例实例化新对

象的性能开销。WebLogic 部署描述符提供一组参数,用于配置 SLSB 汇集行为。而 SFSB

则无法汇集,因为每个客户都与保存客户状态的 SLSB 的特定实例相关联,因此每个对

SFSB 的新请求都将创建新的 SFSB 实例和相关客户会话。WebLogic Server 提供 SFSB 缓

存功能,允许 SFSB 实例在内存中保存一段时间,之后将 bean 的状态钝化到内存之外的

桌面上。这些WebLogic服务器会话bean汇集和缓存参数如表2-3中“SLSB汇集”和“SFSB

缓存”这两行所示。

Message Driven Beans(MDB)是一种 Java EE 机制,它通过在 JMS 目标上实现异步消

息来实例化容器托管的业务逻辑。因此 MDB 无法提供任何远程接口。MDB 与其依赖的

JMS 目标的映射通过 JNDI 实现,表 2-3 中“JNDI 引用”这一行所列的配置考虑因素同

样适用。MDB 的汇集方式与 SLSB 相同。

最后,本节介绍的 EJB 的这 3 种类型都可以参与 WebLogic Server 容器托管的事务。

事务划分点是,对于 SLSB 和 SFSB,它们是 bean 的接口方法;对于 MDB,则是接收来

自其目标的消息。因为 MDB 在现有事务上下文中不提供客户能够调用的操作,因此它

们的事务模型仅限于为每个接收到的消息(或者通过 WebLogic Server MDB 事务批处理

机制配置的一组消息)实例化新事务。RJB 的事务配置功能如表 2-3“事务管理”这一行

所示。

表 2-3 EJB 容器主要配置参数

配 置 类 别 描 述

IIOP 访问 要允许远程客户 IIOP 访问,服务器的 Listen Address 属性必须设置为有效 IP

地址或者 DNS 属性,不能设置为默认的空值,它表示服务器监听“所有配置

的网络接口”。该限制不适用于使用 T3 协议访问服务器的远程客户

JNDI 映射 EJB 可以通过注释(在 EJB类代码内)或 weblogic-ejb-jar.xml <business-interface-

jndi-name>元素映射服务器 JNDI 树。 注释方法不能为不同环境修改 JNDI 名

称,而部署描述符方法通过使用部署计划能够提供这种灵活性,该功能本章稍

后将详细讨论

Page 11: Oracle WebLogic Serverimages.china-pub.com/ebook60001-65000/61112/ch02.pdf · Oracle WebLogic Server 在讨论Oracle Fusion Middleware架构之前,先详细介绍一下Oracle WebLogic

第 2 章 Oracle WebLogic Server

23

(续表)

配 置 类 别 描 述

JNDI 引用 远程 EJB 客户应该使用 ejb-jar.xml 部署描述符里的<ejb-ref>元素和 weblogic-

ejb-jar.xml 部署描述符里对应的<ejb-reference-description>元素在服务器的

JNDI树里查找引用。对于客户和EJB不在相同域的情况,则需要配置外部 JNDI

提供者。外部 JNDI 提供者允许 WebLogic Server 实例的 JNDI 树包含对位于本

地域之外的 JNDI 服务器的引用。对外部 JNDI 提供者的详细讨论超出了本书

的范围。请参考 Fusion Middleware 文档库内的“Programming JNDI for Oracle

WebLogic Server”文档,详细了解对该主题的讨论

SFSB 缓存 weblogic-ejb-jar.xml <cache-type>、<idle-timeout-seconds>和<max-beans-in-cache>

控制容器的 SFSB 缓存管理设置

SLSB 汇集 weblogic-ejb-jar.xml <initial-beans-in-free-pool>控制容器的 SLSB 池管理设置

事务管理 weblogic-ejb-jar.xml<trans-attribute>控制容器的 EJB 事务管理设置

Java Persistence API 容器 Java Persistence API(JPA)规范可用作 Java 对象关系

(OR)映射框架基于标准模型的基础。在 JPA 之前,EJB 2.1 通过 EJB 2.1 实体 beans 包含

自己的 OR 映射功能。虽然由 EJB 3 工作组设计的 JPA 在某种程度上被作为 EJB 2.1 实体

beans 的替代品,但该规范是独立的,其实现方式也可由独立的 Java SE 应用程序使用。

JPA 其实由两类 API 组成。第一类是一组 Java 注释,由开发人员将某个 Plain Old Java

Objects(POJOs)—— 称为 JPA 实体—— 的字段映射到对应的数据库表。第二类是一组控制

API,它们通过应用程序代码控制 JPA 实体的管理,例如实例的创建和修改。

WebLogic Server 使用的默认 JPA 实现方式称为 Kodo,该产品与另一种称为 TopLink

的实现方式打包在一起。Oracle 已经将 TopLink 确定为 WebLogic Server 的战略 JPA 实现

方式。如果应用程序只使用标准的 JPA API,那么 JPA 提供者从 Kodo 到 TopLink 的转换

只是将元素

<provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>

添加到应用程序的 persistence.xml 标准部署描述符文件。否则就需要在将提供者转换到

TopLink 之前移植应用程序的 Kodo 独有 API 用法。这两种实现方式提供一些实现方式特有

的配置参数,如 Fusion Middleware 文档库中“Programming Enterprise JavaBean”文档所述。

从部署时配置的角度来看,唯一标准的 JPA 参数是数据源配置,通过 JPA 应用程序

的 persistence.xml 部署描述符来提供。在 JPA 应用程序使用容器托管事务的情况下—— 对

于 Java EE JPA 应用程序来说就是这种情况—— 则需要由该文件为应用程序使用的每个

持续单元引用两个 JDBC数据源。这些数据源通过<jta-data source>和<non-jta-data source>

元素来标识,并且必须包含合法 WebLogic Server 数据源的 JNDI 名称。

<jta-data source>元素必须指向配置的数据源,以便能够参与全局事务(本章后面将详

细讨论 WebLogic JDBC 数据源的架构和事务配置),并被用作传递所有应用程序查询的

数据源。<non-jta-data source>元素必须指向数据源,该数据源不允许其他资源参与事务

(通过非 XA 数据源实现,该数据源禁用 Supports Global-Transactions 设置,或者如果启

用该设置,则将值设置为 One-Phase Commit),并被 JPA 实现方式用来通过应用程序的实

Page 12: Oracle WebLogic Serverimages.china-pub.com/ebook60001-65000/61112/ch02.pdf · Oracle WebLogic Server 在讨论Oracle Fusion Middleware架构之前,先详细介绍一下Oracle WebLogic

第Ⅰ部分 Oracle Fusion Middleware 11g 架构与管理

24

体管理查询独立访问数据库。

除了本节讨论的少数几个参数之外,JPA 应用程序复杂性主要在于其开发或者提供

者特有的设置。

3. Web 服务容器

由于通过 Web Services Definition Language(WSDL)接口定义的标准化,以及大批

WS-*规范提供通用机制来实现分布式集成功能,Web 服务已经成为研究远程调用业务逻

辑的优先选择。Web 服务最常用的传输协议是 HTTP,但 WebLogic Server 容器也允许通

过 JMS/IIOP 传输协议提供 Web 服务。Web 服务的消息格式通常由 Simple Object Access

Protocol(简单对象访问协议,SOAP)定义,但通过提供 REST 样式的 Web 服务也可以使

用纯 XML 格式的消息。

Web 服务以实现为 POJO(通过名为 Java Web Services [JWS]文件的 Java 类)或 SLSB

EJB。Web 服务对象(基于接收新的 HTTP 请求)的生命同期取决于其实现类型。如果 Web

服务实现为 SLSB EJB,则 EJB 容器的 SLSB 生命周期管理和实例汇集功能则适用,如

本小节“2.Enterprise Java Bean 容器”所述。如果 Web 服务实现为 POJO,则 Web 服务容

器将创建 Web Services JWS 类的新实例,并调用请求的操作。将 Web 服务实现为 EJB 的好

处是,在这种情况下所有容器的 SLSB 管理功能(事务管理、汇集、容器托管安全)都有效。

WebLogic Server Web 服务容器能够执行 JAX-RPC 和基于 JAX-WS 的 Web 服务,推

荐后者作为开发新 Web 服务的首选,因为它是 JAX-RPC 的替代品。WebLogic 的 Web

服务容器提供的功能随着 Web 服务类型的变化而变化。表 2-4 简要描述了 WebLogic

Server Web 服务容器支持的各种 Web 服务类型的功能。

表 2-4 JAX-RPC 与 JAX-WS Web 服务的功能

功 能 JAX-RPC Web 服务 JAX-WS Web 服务

安全性 支持基于 WS-Security 的消息级安全,用于加密 SOAP 消息内容以及传播用

户名令牌和基于 SAML 的身份识别。在 WebLogic Server Web 服务端点上启

用 WS-Security需要应用程序级编码,但使用 Fusion Middleware Oracle Web

Services Manager(OWSM)的 WS-Security 可以保护基于 JAX-WS 的 Web 服

务。第 3 章将详细讨论 OWSM

异步 Web 服务调用 通过一组 WLS 特性实现,以支持

SOAP/JTTP 的 Web 服务会话缓冲

和可靠消息发送。通过将 Web 服务

作为 SOAP/JMS 服务实现,也可以

提供异步调用。需要编码

不支持

事务管理 基于 EJB 的 Web 服务支持启动新

JTA 事务;但不支持事务传播—— 即

能够确保将客户事务上下文传递到

服务器

通过 WS-Atomic Transaction 规范,与

容器托管事务和传入请求的事务传播

完全集成。交互行为不需要开发时编

码,通过 weblogic-webservices.xml 的

<wsat-config>元素可以控制交互行为

Page 13: Oracle WebLogic Serverimages.china-pub.com/ebook60001-65000/61112/ch02.pdf · Oracle WebLogic Server 在讨论Oracle Fusion Middleware架构之前,先详细介绍一下Oracle WebLogic

第 2 章 Oracle WebLogic Server

25

(续表)

功 能 JAX-RPC Web 服务 JAX-WS Web 服务

Stateful Web Services 通过专门的 WebLogic Server Web

服务会话协议实现。需要编码

通过 JAX-WS 标准会话传播功能实现,它

允许使用 HTTP 会话管理会话。需要编码

RESTFul Web Services 不支持 通过 JAX-WS HTTPBinding.HTTP_电路

BINDING 绑定类型实现。需要编码

如表 2-4 所示,WebLogic Server Web 容器的许多行为都通过 Web 服务代码里的逻辑

进行控制,并且在部署时不可配置;但可配置的元素在表中进行了专门介绍。

关于支持这些功能以及与它们相关的WebLogic Server Web服务容器配置的更多信息,

可参考 Fusion Middleware 文档库里的 JAX-WS and JAX-RPC Advanced Features Guides。

2.2.2 应用程序部署

应用程序功能通过文件以 Java JAR 存档文件格式部署到 WebLogic Server,这些文件

用特殊扩展名来表示相关的应用程序类型和内容结构。部署到 WebLogic Server 的不同类

型部署存档文件是标准 Java EE 部署存档文件,其扩展名为 JAR、WAR、EAR 或 RAR。

与这些部署类型相关的标准 Java EE 部署描述符一起,WebLogic Server 提供一组自己的

描述符,以便利用私有特性扩展名。表 2-5 描述了这些部署类型及其关的 WebLogic 部署

描述符。

表 2-5 WebLogic 服务器部署单元

部 署 类 型 描 述

JAR 有两种不同方法可以将 Java Archive File(JAR)部署到 WebLogic Server。第一种方法

是作为存档文件,包含一组 Enterprise Java Beans 和/或基于 Java Persistence API 的实

体。这种存档文件必须包含以下内容。

● 根级别的 META-INF 目录及以下可选内容:

● 一组 persistence.xml 和/或 application-persistence.xml 部署描述符文件,它们为

JAR 文件内的 JPA 实体提供元数据,并将实体映射到一组 JDBC 数据源。

● ejb-jar.xml 和/或 weblogic-ejb-jar.xml 部署描述符文件,这些文件为存档文件内

的 EJB 标识和提供元数据。

● 如果存档文件内的任何EJB被提供为Web服务,则该目录也包含webservices.xml

和/或 weblogic-webservices.xml 部署描述符文件,这些文件为这些 EJB 的 Web

服务接口标识和提供元数据。

● ejb-jar.xml 部署描述符里标识的每个 EJB 相关 Java 程序包路径里的一个或多个

Java 类文件。

使用 ejb-jar.xml 文件是可选的,因为通过 EJB 3 Java 注释完全可以描述 EJB,

WebLogic Server 在部署时将这些注释编译到 ejb-jar.xml 文件中。

.JAR 文件(作为部署是不合法的)的第二种类型包含其他.JAR 文件和/或.class 文件,

并作为共享库部署。本节稍后将详细讨论共享库部署

Page 14: Oracle WebLogic Serverimages.china-pub.com/ebook60001-65000/61112/ch02.pdf · Oracle WebLogic Server 在讨论Oracle Fusion Middleware架构之前,先详细介绍一下Oracle WebLogic

第Ⅰ部分 Oracle Fusion Middleware 11g 架构与管理

26

(续表)

部 署 类 型 描 述

WAR Web Archive(WAR)文件必须包含根级别的 META-INF 和 WEB-INF 目录。

WEB-INF 用来维护如下内容。

● 可选的 web.xml 和/或 weblogic.xml 部署描述符文件,这些文件为存档文件内的

Web 应用程序标识和提供元数据。

● 可选的 webservices.xml 和/或 weblogic-webservices.xml 部署描述符文件,这些文

件为存档文件内的 Web 服务标识和提供元数据。

● 一个\classes 目录,它包含.class 文件—— 在它们的 Java程序包路径内—— 这些.class

文件包含存档文件所包含的 Web 和/或 Web 服务应用程序的实现方式。

● 一个\lib 目录,它能够包含任何依赖 JAR 文件,应用程序的实现方式可能依赖这

些文件。通过应用程序的专用类加载器来加载这些 JAR 文件的内容。

另外,WAR 文件通常还包含一定数量实现 Web 应用程序视图逻辑的 HTML、JSP 和

资源文件(例如定位属性文件或级联样式表)。部署描述符的使用也是可选的,因为通

过 Java 注释能够完整描述 Web 应用程序,WebLogic Server 在部署时会将这些注释

编译到它们关联的描述符文件中

EAR Enterprise Archive(EAR)文件必须包含根级别的 META-INF 和 APP-INF 目录。

APP-INF 目录的结构与 WAR 文件中的 WEB-INF 目录相近,但是用于 EAR 的部署

描述符是 application.xml 和/或 weblogic-application.xml 文件。EAR 文件的目的是聚

集相关 EJB/基于 JPA 的 JAR 或 WAR 部署存档文件,并将它们部署为一个存档文件

RAR Resource Adapter Archive(RAR)文件包含基于 JCA 的资源适配器的逻辑和描述。如本

节所述,关于 WebLogic Server JCA 容器及其组件的详细讨论超出了本书的范围

WebLogic Server Web 服务可通过 JAR 或 WAR 存档文件部署。在通过 EJB 上的注释

部署 Web 服务时—— 高效地提供 EJB 的业务方法作为 Web 服务—— 则通过 JAR 文件完

成部署。在通过启动 WSDL(自顶向下开发模型)或者通过启动 Plain Old Java Objects

(POJOs)部署 Web 服务时,则通过 WAR 文件完成部署。

可以使用管理控制台或 WLST 命令将存档文件部署到 WebLogic Server,2.3 节将进

一步讨论这个问题。许多重要变量会影响将存档文件部署到域。

● 部署目标 指定域的服务器实例,需要将存档文件部署到这些服务器实例。目

标可以是一组特定服务器实例或群集,如果是群集等,存档文件将被部署到群

集内的所有服务器。WebLogic Server 没有假定默认部署目标,通常必须在部署

时指定部署目标。

● 分期模式 指定从服务器(在部署之后将这些服务器作为目标)引用部署存档文

件的方式。默认的部署模式是“staged”,表示管理服务器将部署存档文件的副

本传递给每个目标服务器,同时它还管理所有后续变更。存档文件的部署模式

Page 15: Oracle WebLogic Serverimages.china-pub.com/ebook60001-65000/61112/ch02.pdf · Oracle WebLogic Server 在讨论Oracle Fusion Middleware架构之前,先详细介绍一下Oracle WebLogic

第 2 章 Oracle WebLogic Server

27

对其生命周期管理有重要意义。2.2.4 小节将详细讨论所有可用的 WebLogic Server

部署模式。

● 安全模型 指定目标服务器处理存档文件如何部署描述符内包含的角色和策

略。默认的安全模型是“Deployment Descriptor Only”,它表示只有存档文件部

署描述符内的角色和策略是有效的,不能为应用程序定义任何外部授权策略和

角色映射。2.4 节将详细讨论所有可用的安全模型。

● 部署计划 该文件允许对存档文件标准和WebLogic Server 特有部署描述符进行

部署时变更。部署计划对于在不同类型环境之间,应用程序的部署描述符配置

管理具有重要作用。2.2.5 小节将详细讨论部署计划及其用法。

WebLogic Server 使用两阶段模型来部署存档文件。第一阶段,让每个目标服务器都

可使用存档二进制文件,并且管理服务器要求每个服务器验证存档文件部署的配置。作

为该阶段的一部分,服务请求不能使用存档文件内包含的应用程序。

如果所有目标服务器都成功通过该阶段,接着管理服务器就开始执行第二阶段,即

在各服务器上启用存档文件里的应用程序。如果有服务器无法执行第一阶段,则所有目

标服务器上的部署都会中断。这种方法降低了只将存档文件部分部署到其目标服务器设

备的风险。

如果部署目标是群集,并不需要激活所有群集成员并成功运行部署。管理服务器会

将存档文件部署到所有可访问的群集服务器,恢复每个不可用的群集服务器,使其与所

有错过的部署重新同步。但通过将-DClusterConstraintsEnabled=true Java 选项添加到管理

服务器的命令行,可以重写这种行为。

除了 JAR 存档文件格式之外,还能够以分解的存档(exploded archive)文件目录格式

部署应用程序。在这种情况下,分解的存档文件目录的结构必须与未分解格式中的结构

相同。将选中的 WebLogic Server 部署工具指向其根目录,就可以部署应用程序。通常,

分解的存档文件目录部署最适用于只有一个服务器的部署环境,从而方便经常更新存档

文件目录内容(如 JSP 或应用程序特有的配置文件)。

图 2-3 说明 WebLogic Server 应用程序容器与本节介绍的部署存档文件之间的关系。

EAR

WAR JAR

Servlet 与 JSP

JAX-RPC

与 JAX-WS

Web 服务

JPA 实体 SLSB, SFSB

与 MDB

Web 容器 Web 服务容器 JPA 容器 EJB 容器

应用程序容器

图 2-3 WebLogic Server 应用程序容器与部署存档文件之间的关系

到目前为止,讨论的所有部署存档文件都依赖特定类型的部署,称为共享库,下面

Page 16: Oracle WebLogic Serverimages.china-pub.com/ebook60001-65000/61112/ch02.pdf · Oracle WebLogic Server 在讨论Oracle Fusion Middleware架构之前,先详细介绍一下Oracle WebLogic

第Ⅰ部分 Oracle Fusion Middleware 11g 架构与管理

28

就来介绍它。

2.2.3 共享库

WebLogic Server 能够部署表 2-5 中所示的 JAR、WAR 和 EAR 存档文件格式作为共

享库。其他已部署的应用程序通过 WebLogic 私有部署描述符的<library-ref>元素,可以

声明对共享库的依赖。如果声明这种依赖,引用的共享库的整个内容都将被导出到依赖

应用程序的类路径中,因此,引用的共享库里包含的所有 Java 类对应用程序都可用。当

共享库本身包含 Web、Web 服务或 EJB 应用程序时,库的部署描述符也与导入应用程序

本身的部署描述符合并在一起。

通过 META-INF/MANIFEST.MF 文件的内容可以将共享库版本化,引用的应用程序

再反过来专门引用共享库的具体版本。应用程序引用的共享库必须在部署应用程序本身

之前部署,在所有引用的应用程序未部署之前,不能先部署共享库。

2.2.4 部署模式

如 2.2.2 小节所述,在部署存档文件时,WebLogic Server 有 3 种不同的分期模式。

该模式确定管理存档文件内容以及将它发布到目标服务器的方式。WebLogic Server 提供

的 3 种分期模式分别是:stage、nostage 和 external_stage 模式。stage 模式与后两种模式

之间的主要不同点是:在 stage 模式中,以使用管理服务器可以使用存档文件的副本,并

可再将其内容分配给每个目标服务器的 DOMAIN_HOME/servers/<server-name>/stage 目

录作为第一阶段部署的一部分;在 nostage 和 external_stage 模式中,管理服务器不将存

档文件发布到受管理服务器;在 nostage 模式中,部署时指定存档文件的路径,所有目标

服务器必须访问指定的路径,不管它们在哪个主机上运行。将共享目录用于存档文件分

期,或者确保包含相同路径的存档文件副本在每个主机的文件系统中存在,就可以做到

这一点。最后,关于 external_stage,在初始化部署操作之前,存档文件需要对各主机上

各服务器的 DOMAIN_HOME/servers/<server-name>/stage 目录可用—— 通过完成部署的

实体而不是管理服务器,这种情况和 stage 模式一样。

根据所涉及应用程序的特殊管理需要,每种分期模式都有预定用法。目前最常用的

部署模式是 stage 和 nostage 模式。当使用 stage 模式时,要记住随着部署的存档文件不

断增大,由于需要将网络文件从管理服务器迁移到发布的目标受管理服务器,因此部署

失败的概率也会增加。使用 stage 模式的另一层含义是,当多个域使用存档文件的某个版

本,而该版本需要在所有域上更新时,就要对每个域都执行显式重新部署。而如果使用

nostage 模式,并且所有域都指向相同路径,那么更新所有域上的存档文件就只需要关闭

所有域内的所有服务器,更新存档文件,然后重启所有域里的服务器。当终端用户使用

的应用程序需要创建多个域,并且应用程序二进制文件需要经常打补丁时,后面这种模

式就非常有用。

2.2.5 部署计划

部署计划是一个 XML 文件,它指定重写部署存档文件的标准和 WebLogic 特有部署

Page 17: Oracle WebLogic Serverimages.china-pub.com/ebook60001-65000/61112/ch02.pdf · Oracle WebLogic Server 在讨论Oracle Fusion Middleware架构之前,先详细介绍一下Oracle WebLogic

第 2 章 Oracle WebLogic Server

29

描述符。部署计划非常有用,因为有时需要依据部署存档文件的不同环境需求来调整部

署文件的内容。例如,weblogic.xml 的<jsp-descriptor>元素中定义的 Web 应用程序的

<page-check-seconds>值设置时间间隔,服务器按照该时间间隔检查存档文件里的 JSP 是

否改变,如果改变,则需要对它进行编译。对于开发环境来说最佳默认值是 1s,因为开

发人员可能现场改变部署的 JSP,但对于生产环境来说这个值不太好,因为 JSP 不可能

改变,这样做反而会产生不必要的性能开销。

可以通过维护用于不同环境的单个部署描述符,可以修改存档文件的部署描述符元

素,但这也会导致需要慎重对待的构建管理和内容同步问题。WebLogic Server 利用其部

署计划功能,能够从外部管理对存档文件部署描述符所做的变更。

以<page-check-seconds>为例,管理员可以为生产环境创建一种部署计划,指定该元

素的值为–1,表示容器绝不会检查 JSP 变更。这种部署计划如下所示。

<deployment-plan xmlns=" ... "

<application-name>PricingApp</application-name>

<variable-definition>

<variable>

<name>PageCheckSecondsVar</name>

<value>-1</value>

</variable>

</variable-definition>

<module-override>

<module-name>PricingServiceWeb.war</module-name>

<module-type>war</module-type>

<module-descriptor external="false">

<root-element>weblogic-web-app</root-element>

<uri>WEB-INF/weblogic.xml</uri>

<variable-assignment>

<name>PageCheckSecondsVar</name>

<xpath>/weblogic/jsp-descriptor/page-check-seconds</

xpath>

<operation>add</operation>

</variable-assignment>

</module-descriptor>

</module-override>

<config-root>C:\PricingApp\plan</config-root>

</deployment-plan>

正如所见,部署计划包含具有特定重写指令的元数据。在前面的示例中,已经定义

了一个变量,在<variable-definition>元素内,其名称为 PageCheckSecondsVar,值为–1。

后面会经常在<module-override>元素里使用该变量,以表示应该修改应用程序的

weblogic.xml 部署描述符,重新设置其<page-check-seconds>元素。<variable-assignment>

片段的<operation>子元素指明应该将 page-check-seconds 参数添加到有问题的部署描述

符。这是默认的 WebLogic Server 行为,因此严格来说,不需要在计划里指定它。但是

<operation>元素的值可能是“replace”或者“delete”。replace 操作指明如果元素已经存

Page 18: Oracle WebLogic Serverimages.china-pub.com/ebook60001-65000/61112/ch02.pdf · Oracle WebLogic Server 在讨论Oracle Fusion Middleware架构之前,先详细介绍一下Oracle WebLogic

第Ⅰ部分 Oracle Fusion Middleware 11g 架构与管理

30

在,就应该在部署描述符里重新设置元素值。delete 操作则表示应该从部署描述符中完

全删除有问题的元素。

所有 WebLogic Server 部署工具都能够在部署时指定部署计划。而且,如果部署存档

文件位于/app 目录和/plan 目录同属内(如下面的示例所示),并且通过指向根目录来部署

应用程序,则通过 admin 控制台所做的所有变更将导致在 plan 目录里生成部署计划(其名

为“Plan.xml”)。

\PricingApp\app\PricingAppWeb.war

\PricingApp\plan

如果/plan 目录已经包含 Plan.xml 文件,服务器将保留其内容,对管理控制台所做的

变更将合并到现有文件中。可以从头开始创建部署计划,也可以通过weblogic.PlanGenerator

实用程序从存档文件生成,该工具包含大量选项,例如为存档文件里的现有全部部署描

述符元素生成自动变量。该工具对于创建初始部署计划通常非常有用,初始部署计划经

过进一步提炼后可用于不同的部署环境。最后还要注意的是,Oracle Enterprise Pack for

Eclipse 集成开发环境也能够直接创建和修改 WebLogic Server 部署计划。

2.3 管理功能

本节将详细讨论 WebLogic Server 提供的配置管理功能。

2.3.1 域创建和模板

WebLogic Server 域创建工具建立在通用配置框架基础之上,而该框架又基于域配置

模板。域配置模板是一个 JAR 存档文件,它包含有关域结构和内容的信息。WebLogic

Server 与默认模板(WL_HOME/common/templates/domains/wls.jar)打包在一起,该模板是

创建通用域的基础。如后面所述,其他 Fusion Middleware 产品也使用 WebLogic Server

域内的模板提供所需的资源。常用的配置框架支持 3 种不同类型的域配置模板。

● 域模板 包含从头开始创建功能域的完整信息。域模板用于创建新域。

● 扩展模板 包含部分域信息,用于使用新资源或部署扩展现有域。

● 受管理服务器模板 只包含用于受管理服务器的部分域信息。用于在不同主机

上分布域的服务器。

使用 WebLogic Server Domain Template Builder Tool,可以从现有域创建新的域模板。

下面是使用模板提供域管理功能的工具列表。

● WebLogic Server Configuration(Wizard)(配置向导) 能够以图形模式或控制台

模式运行的用户界面(UI)。向导通常用于在开发和/或测试环境中创建新域。向

Page 19: Oracle WebLogic Serverimages.china-pub.com/ebook60001-65000/61112/ch02.pdf · Oracle WebLogic Server 在讨论Oracle Fusion Middleware架构之前,先详细介绍一下Oracle WebLogic

第 2 章 Oracle WebLogic Server

31

导指向域或者扩展模板,该域或扩展模板被用做创建其他域的基础。该工具然

后导航一组选项,这些选项能够自定义模板域(如服务器的数量/名称及其群集成

员),最后创建域目录和内容。

● WebLogic Server Scripting Tool(WLST) 一种使用 Jython 语言的脚本工具,包

含大量预先打包好的用于域管理的操作。通过使用域或扩展模板,WLST 也能

提供域创建和域扩展功能。WLST 域创建和扩展性能通常与其他域管理功能(如

部署和在线配置管理)配合使用,以通过脚本自动提供域。2.3.3 小节将详细讨论

WLST。

● Pack/Unpack 命令 一对命令行工具,用于将域打包到域模板(pack),在不同位

置从模板重新创建域目录(unpack)。pack 命令可用于创建受管理服务器模板。这

些命令通常用于将域从一种环境移动到另一种环境,以及在域服务器横跨的不

同主机的文件系统之间分布域组件。

2.3.2 WebLogic Java Management Extension MBean Server

Java Management Extension(JMX)技术是构建 WebLogic Server 配置基础的支柱。通

过一组 JMX MBean 服务器可在运行时管理域的配置。每个 WebLogic Server 实例通过名

为管理端口的特殊端口都可以使用 MBean 服务器。默认状态下,每个服务器的管理端口

都被设置为监听端口。JMX 客户可以连接到服务器的管理端口,以获取或编辑其配置。

每个受管理服务器都有两个 MBean 服务器:Runtime 服务器和 Platform 服务器。

Runtime 服务器驻留两类 MBean。第一类是配置 MBean,如果管理服务器可用,则由受

管理服务器从管理服务器初始化;否则从域 config.xml 的本地副本初始化。配置 MBean

的组织形式是树层次结构,DomainMBean 是树的根。以只读模式可以使用受管理服务器

的配置 MBean。Runtime 服务器驻留的第二种 MBean 是 Runtime MBean,它由服务器初

始化,以提供与服务器资源的运行时状态有关的度量标准或状态(如服务器子系统的运行

状态)。服务器的 Platform服务器驻留 JVM 的平台 MBean(称为 MXBeans),它提供与 JVM

的资源运行时状态有关的度量标准或状态(如当前堆大小)。

域的管理服务器与受管理服务器有相同的 MBean 服务器,但其配置 MBean 可用于

管理服务器里的所有调整。管理服务器还有另外两个 MBean 服务器:Domain Runtime

服务器和 Edit 服务器。Domain Runtime 服务器驻留 MBean,它保存域范围内的配置、度

量标准和服务。Edit 服务器可用作单个入口点,通过对域进行锁定、保存和激活操作,

控制配置变更。要执行域配置变更,JMX 客户需要连接到 Edit MBean 服务器,以实现

锁定操作,然后连接到管理服务器的 Runtime MBean 服务器,以修改目标 Mbean;最后

通过 Edit MBean 服务器保存和激活操作。

如前所述,管理服务器是域内唯一拥有配置 MBean 可编辑版本的服务器。在保存配

置变更时,管理服务器将变更发送到域的受管理服务器,受管理服务器将变更保存在

DOMAIN_HOME/pending 目录。激活变更时,管理服务器要求各受管理服务器应用 pending

目录里的变更。各服务器对变更进行评估,以确定是否接受它们,如果所有服务器都接

Page 20: Oracle WebLogic Serverimages.china-pub.com/ebook60001-65000/61112/ch02.pdf · Oracle WebLogic Server 在讨论Oracle Fusion Middleware架构之前,先详细介绍一下Oracle WebLogic

第Ⅰ部分 Oracle Fusion Middleware 11g 架构与管理

32

受,管理服务器则要求它们将变更提交到配置 MBean 和域的 config.xml 文件。

JMX 客户

到目前为止所讨论的WebLogic Server JMX 基础可能让自定义 JMX 客户连接到域的

服务器来检索信息,也可以连接到管理服务器编辑配置。下面的代码是示例 JMX 客户,

它连接到管理服务器,查询域内的服务器列表。

public MBeanerverConnection connectToServer(String host, int adminport,

String JmxServerURI) {

try {

JMXServiceURL serviceURL = new JMXServiceURL("t3", host, adminport,

"/jndi/" + JmxServerURI);

Hashtable<String, String> context = new Hashtable<String, String>();

context.put(Context.SECURITY_PRINCIPAL, "weblogic");

context.put(Context.SECURITY_CREDENTIALS, "welcome1");

context.put(JMXConnectorFactory.PROTOCOL_PROVIDER_PACKAGES,

"weblogic.management.remote");

JMXConnector connector = JMXConnectorFactory.connect(serviceURL,

context);

MBeanerverConnection connection = connector

.getMBeanerverConnection();

return connection;

} catch (Exception e) {

throw new RuntimeException(e);

}

}

public void displayServers() {

try {

MBeanerverConnection runTimeServer = connectToServer(

"localhost",7001, "weblogic.management.MBeanervers.runtime");

ObjectName runtimeObjectName = new ObjectName(

"com.bea:Name=RuntimeService,Type=weblogic.management.

MBeanervers.runtime.RuntimeServiceMBean");

ObjectName domain = (ObjectName) runTimeServer.getAttribute(

runtimeObjectName, "DomainConfiguration");

ObjectName servers[] = (ObjectName[])runTimeServer.

getAttribute(domain,"Servers");

for (ObjectName server : servers) {

System.out.println(runTimeServer.getAttribute(server, "Name")

.toString());

}

catch (Throwable e) {

throw new RuntimeException(e);

}

}

Page 21: Oracle WebLogic Serverimages.china-pub.com/ebook60001-65000/61112/ch02.pdf · Oracle WebLogic Server 在讨论Oracle Fusion Middleware架构之前,先详细介绍一下Oracle WebLogic

第 2 章 Oracle WebLogic Server

33

在上面的代码中,connectToServer()方法建立到服务器(给定主机)的连接,调整管理

端口以获得对特定 MBean 服务器的引用,如 URI 参数所示。displayServers()方法使用

connectToServer()方法建立到管理服务器的 Runtime MBean 服务器的连接。正如所见,要

建立这种连接,客户需要知道指定 URI 和目标 MBean 服务器的对象名称。各 WebLogic

MBean 服务器的对象名称—— 包括 URI 作为其 Type 属性的前缀—— 如表 2-6 所示。

表 2-6 WebLogic Server Mbean 服务器 URI

服 务 器 对 象 名 称

Runtime MBean 服务器 com.bea:Name=RuntimeService, Type=weblogic

.management.MBeanervers.runtime.RuntimeServiceMBean

Domain Runtime MBean 服务器 com.bea:Name=DomainRuntimeService, Type=

weblogic.management.MBeanervers.domainruntime

.DomainRuntimeServiceMBean.

Edit MBean 服务器 com.bea:Name=EditService, Type=weblogic

.management.MBeanervers.edit.EditServiceMBean

尽管任何人都可能写 JMX 客户来管理域的配置,但 WebLogic Server 打包了以下两

种客户,从而让这项任务变得更加简单。第一种客户是域管理控制台—— 一个部署到所

有WebLogic Server域的管理服务器上的Web应用程序,可以通过http://<admin server host

IP>:<admin port>/console URL 访问。管理控制台不仅提供用户友好的 GUI 用于浏览和管

理域的 MBean,还提供了其他功能,如查看每个域服务器的 JNDI 树。第二个预先打包

的 JMX 客户应用程序是 WebLogic Server Scripting Tool (WLST),接下来将详细介绍它。

2.3.3 WebLogic Server Scripting Tool

WebLogic Server Scripting Tool(WebLogic 服务器脚本工具,WLST)是一种基于 Jython

的脚本接口,它提供的命令可自动执行域管理任务。所有 Fusion Middleware 产品都提供

特定 WLST 命令,它们能够满足特定的管理需求,后面相关章节将详细介绍这些产品的

具体功能。对于 WebLogic Server 来说,WLST 提供的命令可以创建、配置、监控域,还

可以部署应用程序。WLST 可以以离线模式或在线模式执行。

在离线模式中,WLST 可用来创建和修改域的配置,而无需连接到任何服务器。

WLST 离线在域的 config.xml 文件上运行,如果域的服务器正在运行,那么将会重写通

过它对域配置所做的修改。因此,为了实现域配置变更,当域服务器关闭时,必须运行

WLST 离线。

说明

不要使用 WLST 离线来修改管理服务器主机上的域配置,当管理服务器正在运行时

也不要这样做,因为变更可能被重写。

Page 22: Oracle WebLogic Serverimages.china-pub.com/ebook60001-65000/61112/ch02.pdf · Oracle WebLogic Server 在讨论Oracle Fusion Middleware架构之前,先详细介绍一下Oracle WebLogic

第Ⅰ部分 Oracle Fusion Middleware 11g 架构与管理

34

在线模式中,WLST 维护到域管理服务器的活动连接,通过直接修改域的 MBean 来

实现变更。WLST 在线还允许浏览运行时状态 MBean,部署和解除部署应用程序。因为

WebLogic Server 配置 MBean 是树形层次结构,因此浏览它们就像浏览文件系统目录结

构一样,WLST 也希望这样。例如,用来实现与 2.3.2 小节 JMX 客户代码相同任务的

WLST 在线脚本如下所示:

connect('weblogic','welcome1','t3://localhost:7001');

ls('Servers');

在默认情况下,将 WLST 在线 MBean 的浏览层次结构设置为所连接的服务器实例

的运行时 MBean 服务器。但当连接到管理服务器时,通过 domainConfig()命令可以将

MBean 浏览层次结构转换为域运行时服务器。通过 serverConfig()命令,也可以将该层次

结构转换回运行时服务器。但这两种层次结构都不允许通过 WLST 修改 MBean 属性。

如果要进行编辑,则要使用 edit()命令转换到可写 MBean 层次结构,它包含域的所有配

置 MBean。WLST 还能够通过 jndi()命令浏览服务器的 JNDI 树,其方法与 MBean 层次

结构相同。

由于导航 WebLogic Server MBean 层次结构可能很麻烦,因此查找需要管理的 MBean

指定设置路径的好方法是通过管理控制台的“record WLST scripts feature”。该性能可通

过管理控制台进行一系列调整,确保创建 WLST 脚本片段,这些脚本片段代表在记录会

话过程中通过控制台实现的步骤。

通过本节对 WLST 的描述可知,这些功能提供了一种强大的机制,能够自动化域创

建和调整,方便多环境中的管理。但 WLST 最好能与 WebLogic Server 配置框架的域配

置模板和部署计划功能结合使用。这通常对于为特定环境创建域模板具有重要意义,该

域模板然后被用作 WLST 脚本的基础,以便为指定上下文创建实际域并修改它—— 例如,

依据提供的目标数据库实例设置相应的 JDBC 连接字符串。通过使用环境特有的部署计

划,可以在部署时进一步修改已部署存档文件的配置。

虽然对 WLST 及其命令的更详细描述超出了本节的范围,但仍然可以在本书整个用

例部分使用 WLST,并会详细描述其他一些功能。通常,熟悉 WLST 及其命令的最简单

方法就是使用 help 命令。parameterless help()命令提供所有可用 WLST 命令列表,help

也可以与特定命令名称一起用作获得详细信息的参数。

2.4 身份验证和授权服务

本节将从应用程序身份验证和授权的角度讨论 WebLogic Server 的安全服务及其架

构。虽然很重要,但关于网络安全(即 SSL 和连接过滤)、证明和证书管理的讨论将放在

第 9 章。图 2-4 所示为 WebLogic Server 身份验证和授权安全服务的主要组件,下面几小

节将详细讨论这些组件。

Page 23: Oracle WebLogic Serverimages.china-pub.com/ebook60001-65000/61112/ch02.pdf · Oracle WebLogic Server 在讨论Oracle Fusion Middleware架构之前,先详细介绍一下Oracle WebLogic

第 2 章 Oracle WebLogic Server

35

WebLogic Server

应用程序容器

身份存储库

身份验证和断言提供者 授权和角色映射提供者

WebLogic Server 安全框架

WebLogic 角色和

授权策略存储库

部署的应用程序

图 2-4 WebLogic Serve 身份验证和授权安全服务的主要组件

2.4.1 嵌入式 LDAP

WebLogic Server 包含一个嵌入式 LDAP 服务器,其默认身份验证、授权和角色映射

提供者将它用作身份标识以及角色映射和授权策略存储库。通常对于包含大量用户的环

境来说,不建议在生产中将嵌入式 LDAP 服务器作为身份存储库,这是因为管理服务器

将在受管理服务器之间复制嵌入式 LDAP 的内容,而且当 LDAP 的内容变更很庞大时,

也不能对这种模型进行很好的扩展。推荐的生产实践是使用专用LDAP服务器,例如Oracle

Internet Directory 或 Oracle Directory Server Standard Edition。但在所有环境中(包括生产

环境)将嵌入式 LDAP 用作角色映射和授权策略存储库是无害的,并且很常见,因此理解

其架构非常重要。通过管理控制台的 domain/Security/Embedded LDAP 标签可以修改嵌入

式 LDAP 服务器的配置,本节稍后将讨论这个问题。

嵌入式服务器的实例在每个服务器实例上都存在,它将其数据保存在磁盘上,其目录

为 DOMAIN_HOME/servers/<server-name>/data/ldap。管理服务器是唯一能够编辑 LDAP

内容的服务器,它确保将数据定期复制到受管理服务器。每个服务器实例都被默认配置为

每天一次将其数据备份到名为/backup 的子目录。WebLogic Server 使用名为 Admin 的默认

管理用户,并使用随机生成的密码作为 LDAP 服务器的管理员证书。因此,如果要直接通

过通用 LDAP 客户访问 LDAP 服务器,就需要修改 Admin 用户的随机密码,之后指向任

何服务器的监听地址/端口,Base DN(dc)值与域名称相同,username(cn)值为“Admin”。

2.4.2 安全提供者

WebLogic Server 应用程序安全服务通过安全提供者实现。安全提供者是一种

WebLogic Server 结构,它通过 JMX MBean 提供配置,并提供特定类型的安全服务。安

全提供者的范围属于 WebLogic Server 安全领域。虽然在域内可以定义多个领域,但只有

配置为默认领域的领域才能被激活。WebLogic Server 预先打包了许多现有安全提供者,

有些被默认配置为所有新域的安全提供者。虽然可能,但从头开始创建自定义提供者没

Page 24: Oracle WebLogic Serverimages.china-pub.com/ebook60001-65000/61112/ch02.pdf · Oracle WebLogic Server 在讨论Oracle Fusion Middleware架构之前,先详细介绍一下Oracle WebLogic

第Ⅰ部分 Oracle Fusion Middleware 11g 架构与管理

36

有必要,因为预先打包的提供者已经包含许多功能,通过它们提供的配置也可以进行自

定义配置。下面将介绍一些重要类型的 WebLogic Server 安全提供者以及它们在域安全领

域里的默认配置。

1. 身份验证和身份断言提供者

身份验证提供者将域与包含用户和组相关信息的身份存储库集成在一起,并作为所

部署应用程序登录的一部分,验证提供的证书。WebLogic Server 打包一组身份验证提供

者,它与最常用的 LDAP 服务器集成,作为身份存储库。另外,它还提供基于 RDBMS

身份存储库的身份验证提供者。WebLogic Server 配置的默认身份验证提供者使用域的嵌

入式 LDAP服务器作为身份存储库。WebLogic Server 身份验证提供者以 Java Authentication

and Authorization Services(JAAS)规范为基础,因此可以定义多个身份验证提供者(每个都

使用自己的 JAAS LoginModule),每个都有不同的控制标记,这些标记描述提供者身份

验证成功的相关需求。

身份断言提供者是特殊类型的身份验证提供者,用于实现周界身份验证模式。在这

种类型的身份验证中,WebLogic Server 域前面的另一个实体(通常是 Single Sign-On 服务

器)已经执行用户所需的身份验证。在这种情况下,身份断言提供者用于将经过验证的用

户的信息—— 通常从传入请求的标题获取—— 映射到经过验证的合法 JAAS 目标,再将它

作为应用程序角色映射和授权策略的一部分。它们自己的安全提供者负责管理应用程序

的角色-映射和授权策略。下面将详细介绍这些提供者。

2. 角色-映射和授权提供者

角色-映射提供者负责管理应用程序和容器范围内的角色,还负责依据应用程序的角

色-映射策略管理经过验证的原则到对应角色的映射。

授权提供者负责管理应用程序和容器范围内的授权策略。用户经过身份验证之后,

WebLogic Server 使用配置好的授权提供者来确定经过验证的用户是否能够根据上下文

中的授权策略访问受保护的功能。

默认情况下,基于角色-映射和授权提供者支持,可以用 eXtensible Access Control Markup

Language(XACML)配置 WebLogic Server 域。这些提供者默认将域的角色-映射和授权策

略以 XACML 形式保存在其嵌入式 LDAP 服务器中,当然也可以使用基于 RDBMS 的外

部存储库。

2.4.3 用户、组、角色和授权策略

当为域配置指向身份存储库的身份验证提供者时,出于安全考虑,部署的应用程序

可以通过定义使用资源的授权策略,进而使用该存储库内定义的用户和组。为此,Java EE

应用程序提出了角色的概念,它映射到一组用户和组。在 WebLogic Server 中,有两种方

式定义应用程序的角色以及它们到用户和组的映射。第一种方式是在应用程序内,通过

注释或在部署描述符内定义。第二种方式是在容器层,在部署应用程序之后,通过管理

控制台的安全领域页面或 WLST 在线定义。

从管理的角度来看,重要的是准确列出应用程序所需的角色组,以确保在各种环境

Page 25: Oracle WebLogic Serverimages.china-pub.com/ebook60001-65000/61112/ch02.pdf · Oracle WebLogic Server 在讨论Oracle Fusion Middleware架构之前,先详细介绍一下Oracle WebLogic

第 2 章 Oracle WebLogic Server

37

中能够正确映射。因此重要的是要知道,开发团队是在应用程序内包含内置角色(通过其

部署描述符),还是希望提供的应用程序角色全部在容器层实现。如果是前者,若使用部

署描述符,就可以从它们推断出所需的角色。如果使用注释,或者应用程序内没有定义

角色,而是希望使用容器定义的角色,那么就要让开发团队准确列明应用程序所需的角

色,以确定在应用程序的不同环境中到用户和组的相应映射。本章后面的用例中有许多

这方面的示例。可在全局范围(全部可见)、域范围、特定服务器组、应用程序本身、JDBC

数据源或 JMS 模块中定义容器定义的角色。

相对于应用程序直接引用用户和组来定义授权策略,角色带来的好处主要有两点。

首先,可以将角色扩展到特定部署存档文件,并在配置时映射到目标域特定身份存储库

内的用户和组。这种灵活性使应用程序安全开发从域的配置身份存储库的特定内容中分

离出来,并且这种灵活性随着环境的不同而有所变化。其次,WebLogic Server 能够基于

日期/时间间隔和请求上下文(HTTP 请求和会话参数以及 EJB 方法参数值),将用户和组

映射到容器角色。这种功能让应用程序授权能够基于业务规则执行—— 例如,确保在营

业时间禁用容易引起混乱的某种管理任务。

角色映射还要补充一组授权策略,这些策略依据用户的 Subject 来保护应用程序的功

能或资源。Subject 是一个包含用户、组和角色(经过验证的用户的身份属于该角色)的对

象。和角色一样,也可以在应用程序内或容器层定义授权策略。在应用程序内指定时,

可以通过编程指定授权策略,也可以公开通过注释或部署描述符指定。从管理的角度来

看,重要的一点是要理解部署的应用程序是已经包含所需的授权策略还是希望在容器层

定义它们。和容器层角色映射一样,也可以通过管理控制台安全领域页或 WLST 在线来

定义容器层的授权策略。

通过所选的部署时安全模型来控制应用程序角色定义、角色映射和授权策略的方式,

就像由应用程序本身和在容器层定义它们一样。WebLogic Server 提供 4 种不同的安全模

型:Deployment Descriptor Only、Custom Roles Only、Custom Roles and Policies 和

Advanced。前 3 种模型就足以满足大多数应用程序的安全需要。不同类型角色定义、角

色映射和授权策略对容器处理的影响如表 2-7 所示。

在部署时使用 Advanced(高级)安全模型定制一种方式,应用程序定义的角色定义、

角色映射和授权策略以这种方式与它们容器定义的角色定义、角色映射和授权策略结合。

如上所述,很少需要这样,因此要慎用。

表 2-7 安全模型角色定义、角色映射和授权策略处理

角 色 定 义 角 色 映 射 授 权 策 略

Deployment

Descriptor Only

应用程序层范围内的

DD 角色,在些层上定

义所有应用程序的

URL 模式。

无法定义应用程序范

围内的容器角色

映射到角色的原则像在 DD 中

定义的一样。DD 通过使用

<externally-linked>元素,可以

委托到容器的映射,在这种情

况下,匹配 DD 定义角色名称

的全局或基于域的角色必须指

定映射

所有EJB和URL范围内的

授权策略必须在 DD 层定

义,不能从外部在容器层

定义

Page 26: Oracle WebLogic Serverimages.china-pub.com/ebook60001-65000/61112/ch02.pdf · Oracle WebLogic Server 在讨论Oracle Fusion Middleware架构之前,先详细介绍一下Oracle WebLogic

第Ⅰ部分 Oracle Fusion Middleware 11g 架构与管理

38

(续表)

角 色 定 义 角 色 映 射 授 权 策 略

Custom Roles

Only

DD 角色定义被容器

忽略

DD 原则到角色映射被容器忽

略。通过容器层角色策略将原

则映射到角色

所有EJB和URL范围内的

授权策略必须在 DD 层定

义,不能从外部在容器层

定义。DD 授权策略必须使

用匹配容器层角色的名称

Custom Roles

and Policies

DD 角色定义被容器

忽略

DD 原则到角色映射被容器忽

略。通过容器层角色策略将原

则映射到角色

DD 授权策略被容器忽略,

只使用容器层的授权策略

2.5 JDBC 服务

Java EE 应用程序通过 JDBC 数据源访问数据库,这些数据源抽象数据库集成和连接

管理。WebLogic Server JDBC 数据源封装 JDBC 驱动程序、连接信息—— 指向 RDBMS

内的特定模式,其类型匹配数据源驱动程序—— 和到连接信息引用的模式的活动连接。

图 2-5 显示的是 WebLogic JDBC 数据源的主要元素。

WebLogic Server 实例

部署存档文件

数据源客户

连接池

JDBC 驱动程序

连接

数据源

数据库

图 2-5 WebLogic Server JDBC 数据源架构

Page 27: Oracle WebLogic Serverimages.china-pub.com/ebook60001-65000/61112/ch02.pdf · Oracle WebLogic Server 在讨论Oracle Fusion Middleware架构之前,先详细介绍一下Oracle WebLogic

第 2 章 Oracle WebLogic Server

39

在启动时,各 WebLogic Server 实例用一定数量的活动连接初始化配置的数据源。客

户通过 JNDI 查找来访问数据源,数据源对客户范围的可用性由其服务器目标确定。换

句话说,数据源的 JNDI 名称只对 WebLogic 服务器实例可用—— 在创建时将数据源分配

给该实例。客户访问数据库源时,会给它们提供池中的活动连接。如果池内的连接耗尽,

数据源将扩展连接池,直到达到最大数量为止。数据源初始、最大和递增大小增加值

(incremental size increases)都是连接池的可配置参数。通常最好将数据源连接池的初始值

和最大值设置为相同值。这样就可以确保在出现峰值时,后端数据库不会因昂贵的新连

接请求而过载,又能够确保在服务器初始化时能够预先获得所需的全部连接。每个数据

源也可以定期测试所有连接,以保证它们仍然可用,当然这种测试也可以关闭。通过 Test

Connections on Reserve 属性可以配置连接池,以便在将连接传递给请求的客户之前先测

试它们。

数据源的事务处理行为是另一个需要考虑的重要配置。简单地说,如果数据源由参

与 JTA事务的资源所使用,并且使用的 JDBC驱动程序是非XA(即按照X/Open XA标准,

它不能像资源管理器一样参与分布式事务),那么就必须设置数据源的 Supports Global

Transactions,这样WebLogic Server就能在特定JTA事务上下文内总是使用相同的连接(来

自数据源的连接池)。Supports Global Transactions 配置下可用的不同选项可指定数据源用

来确保连接参与基于 XA 的双相提交事务的算法,而 one-phase commit 选项则表示数据

源的连接不会参与到 XA 事务内。

需要强调的是,WebLogic Server 提供应用程序范围内以及系统范围内的 JDBC 模块。

应用程序范围内模块的配置被嵌入特定应用程序部署存档文件中,而系统范围内的

JDBC 模块在域层定义,其配置包含在 DOMAIN_HOME/config/jdbc 目录里,并从域的

config.xml 目录引用。相对于应用程序范围内的模块而言,系统范围内的模块可通过 JMX

访问,并且在最初创建之后可以用新资源扩展它。在部署时修改各种类型模块配置的方

法也不同,因为对于系统范围内的模块而言,这种修改需要在 JMX 和/或 WLST 层解决;

而对于应用程序范围内的模块而言,则需要使用部署计划。由于在管理系统范围内的

JDBC 模块中有更灵活的选项,因此通常不用应用程序范围内的 JDBC 数据源。

Real Application Clusters 集成

Real Application Clusters (RAC,实际应用程序群集)是 Oracle RDBMS 的一种特性,

它使多个数据库服务器实例能够访问相同的数据库。这种服务器实例被称为 RAC 群集的

节点。特定模式的用户可使用任何 RAC 节点来提交数据访问请求,RAC 基础设施管理

群集内提交的并行请求。因此 RAC 为增加的容错(如果 RAC 节点瘫痪,其他节点继续服

务请求)、负载均衡(整个 RAC 节点的主机)和可扩展性(可添加新节点以容纳增加的请求)

留有余地。WebLogic Server JDBC 提供了两种不同特性,用于 Java EE 应用程序与 RAC:

多数据源和 GridLink 数据源。图 2-6 阐明了实现 WebLogic Server 部署的 Java EE 应用程

序与 RAC 数据库集成的方式。

Page 28: Oracle WebLogic Serverimages.china-pub.com/ebook60001-65000/61112/ch02.pdf · Oracle WebLogic Server 在讨论Oracle Fusion Middleware架构之前,先详细介绍一下Oracle WebLogic

第Ⅰ部分 Oracle Fusion Middleware 11g 架构与管理

40

多数据源 RAC 集成 GridLink 数据源集成

WebLogic Server WebLogic Server

部署存档文件 部署存档文件

数据源客户 数据源客户

多数据源 GridLink

数据源

数据源 1 数据源 2 数据源 3

数据库服务器

实例 1 数据库服务器

实例 2 数据库服务器

实例 3 数据库服务器

实例 3

数据库服务器

实例 2 数据库服务器

实例 1

RAC 群集 RAC 群集

Oracle 数据库 Oracle 数据库

变更事件

ONS

图 2-6 Java EE 应用程序与 RAC 数据库集成的方式

多数据源抽象对一组 JDBC 数据源的访问,并且允许通过它们进行负载均衡和故障

处理。多数据源有自己的 JNDI 名称,并在域内给它们配置对一个或多个实际 JDBC 数

据源的引用。多数据源下的每个数据源都是通用的 JDBC 数据源,因此多数据源可用于

与除 Oracle 之外的其他数据库集成。当多数据源用作与 RAC 集成时,必须用Oracle JDBC

thin 驱动程序配置单个 JDBC 数据源,而且必须将每个数据源配置为指向 RAC 群集内不

同的 RAC 节点。否则,多数据源就是一种通用机制,可用于任何与 Oracle RAC 类似的

群集数据库技术。客户应用程序引用多数据源而不是它聚集的单个 JDBC 数据源。因为

客户使用多数据源执行 SQL 语句,因此它确保请求在不同数据源之间保持负载均衡。因

此,当多数据源与 RAC 群集节点结合使用时,可确保请求在 RAC 群集的不同节点之间保

持负载均衡。

GridLink 数据源是一种特殊类型的数据源,它专门用于与 RAC 集成。GridLink 数据

源与普通的 JDBC 数据源一样,由一个标准的 JDBC 连接池组成,但可以给它配置 RAC

群集所有节点的连接,并代表客户为这些节点提供负载均衡和故障切换功能。GridLink

数据源可与 RAC 群集的 Oracle Notification Service (ONS)集成。这种集成使数据源能够

接收来自 RAC 基础设施的通知,从而能够在 RAC 层依据 RAC 群集状态及其配置的功

能目标保持其负载均衡和故障切换算法。与多数据源相比,GridLink 数据源与 RAC 的集

成更加紧密,这种技术被称为通用群集数据库集成技术。而 GridLink 被认为是 WebLogic

Server 应用程序与 Oracle RAC 集成的首选方法。

Page 29: Oracle WebLogic Serverimages.china-pub.com/ebook60001-65000/61112/ch02.pdf · Oracle WebLogic Server 在讨论Oracle Fusion Middleware架构之前,先详细介绍一下Oracle WebLogic

第 2 章 Oracle WebLogic Server

41

2.6 JMS 服务

WebLogic Server 提供一种基础设施,允许其作为 Java Messaging Services (JMS)提供

者,以方便使用 JMS API 实现客户之间的异步消息发送。本节将探讨 WebLogic Server

JMS Services 的架构,讨论它最重要的管理因素。图 2-7 所示为 WebLogic Server JMS 架

构的主要元素及它们之间的关系。

WebLogic Server 实例

JMS 服务器

子部署

连接工厂 队列和主题

资源

JMS 模块

永久存储库

群集

群集

子部署

服务器

子部署

JMS 服务器

子部署

图 2-7 WebLogic Server JMS 架构

2.6.1 JMS 服务器

WebLogic Server JMS 架构的核心是 JMS 服务器。JMS 服务器负责通过接收 JMS 客

户发送方给它们发送的消息来管理目的地,记录消息的属性(如它们的持久性和重试要求)

及其目的地,最后确保将消息发送给目的地的消费者和/或订购者。必须将 JMS 服务器

定位到单个受管理服务器,不能将它定位到群集。因此 JMS 被认为是单独服务,并且依

赖 WebLogic Server 服务器的移植功能(其细节超出了本书的讨论范围),用于在失败情况

下,将目的地和相关消息从一个受管理服务器自动移植到另外一个受管理服务器。

下面将讨论 JMS 服务器一些最重要的配置。

1. 永久存储库

JMS 提供者必须保证 JMS 消息使用永久传递(persistentdelivery)模式,以确保消息在

Page 30: Oracle WebLogic Serverimages.china-pub.com/ebook60001-65000/61112/ch02.pdf · Oracle WebLogic Server 在讨论Oracle Fusion Middleware架构之前,先详细介绍一下Oracle WebLogic

第Ⅰ部分 Oracle Fusion Middleware 11g 架构与管理

42

传递给接收方之前不会丢失。WebLogic Server 实现这一目标的方式是将 JMS 服务器与

永久存储库联系起来,该永久存储库用来以永久传递模式永久存储 JMS 消息的内容。在

默认情况下,每个 JMS 服务器都与其受管理服务器 DOMAIN_NAME\servers\<server-

name>\data\store\default 目录里基于文件的永久存储库相关联。可以将该存储库改变为显

式定义且基于文件或者基于 JDBC 的永久存储库。一般来说,经过调整的基于文件的存

储库通常比基于 JDBC 的存储库更有效,但基于 JDBC 的存储库配置高可用性永久存储

库的方法更简单,因为它利用了 RDBMS 的高可用性功能。

2. 分页、限额和阀值

基于消息发送的集成可能出现以下风险:消息生产者发送消息的速度高于接收者接

收消息的速度。WebLogic Server JMS 提供者提供了许多特性来降低这种情况造成的影响,

以确保能够尽量从容地控制这种情况。这些特性就是分页和阀值。为了提高效率,需要

在 JMS 服务器上配置这些特性,使其适应客户应用程序的预期行为。下面将详细介绍这

些特性。

每个 JMS 服务器都有一个内存缓冲区,用于处理其目标目的地的消息。当该缓冲区

达到某个大小时,服务器自动将缓冲区溢出到文件系统,以确保消息缓冲区不会占用所

有 WebLogic Server 实例的可用内存,此过程称为“分页”。在默认情况下,当缓冲区小

于 JVM 堆的 1/3 或 512 MB 时,JMS 服务器就会将缓冲区的内容“分页”到受管理服务

器的 DOMAIN_NAME\servers\<server-name>\tmp 目录。分页目录的位置和最大缓冲区大

小都是 JMS 服务器的可配置属性。

分页保护可以应对内存溢出,但无法确保当目的地上产生消息的速度长时间高于处

理消息的速度时,分页和/或永久存储库本身不会被填满。为了防止出现这种情况,JMS

服务器对消息的最大数量、使用的最大内存和所有定位到其目的地的单个消息的最大大

小实施限额管理。当服务器达到消息的最大数量或内存限额时,则要求新消息的生产者

等待一段时间,该时间由连接工厂的超时设置指定。如果这段时间内新消息所需的空间

够用,生产者就可以完成其发送操作,否则生产者就会接收到一个必须处理的异常。限

额可以在 JMS 模块层定义,并且与模块内的特定目的地相关联。当在 JMS 服务器上定

义时,限额适用于所有服务器的目的地,这些目的地没有与它们相关联的模块级限额。

限额是处理退化目的地的最终方法,但阈值机制允许 WebLogic Server JMS 尝试和

防止到达限额,当服务器里的所有消息达到某个值或者当所有服务器目的地上的消息总

量达到某个总数时,它会压制生产者生产消息的速度。JMS 服务器给整个消息大小和总

数都定义一个高阀值和一个低阀值。当达到高阀值时,服务器就会启动所有消息生产者

上的流程控制算法,开始实行最大生产速度,经过一段时间再将该速度降低到最小生产

速度,直到再次达到低阀值为止。使用的流程控制算法的特定元素由消息生产者使用的

JMS 连接工厂的配置指定。还可以定义特定 JMS 目的地的阀值,在这种情况下,目的地

上的设置优先于 JMS 服务器设置。

Page 31: Oracle WebLogic Serverimages.china-pub.com/ebook60001-65000/61112/ch02.pdf · Oracle WebLogic Server 在讨论Oracle Fusion Middleware架构之前,先详细介绍一下Oracle WebLogic

第 2 章 Oracle WebLogic Server

43

2.6.2 JMS 模块

JMS 模块包含 JMS 消息生产者和消费者的客户需要集成的 JMS 资源。JMS 模块的

资源不仅定义这些客户使用的目的地,还包含一些配置,用于驱动客户之间消息发送集

成的行为。本小节将分析可作为模块的一部分部署的主要资源类型以及它们背后的概念。

1. 连接工厂

连接工厂是 JMS 模块资源的一种类型,JMS 客户用它连接到 JMS 服务器,以便生

产和消费消息。JMS 客户通过 JNDI 查找连接工厂。连接工厂的属性确定它生产的连接

的行为,再定义客户从这些连接创建的消息的行为。在连接工厂层可以修改的一些主要

属性包括 JMS 消息服务设置(如永久传递模式)的默认传递质量,默认客户通知策略,通

过连接工厂实现的操作是否参与分布式事务,以及使用连接工厂的消息生产者的流程控

制算法设置。在默认情况下,每个受管理服务器都配置有两个默认连接工厂,分别使用

weblogic.jms.ConnectionFactory 和 weblogic.jms.XAConnectionFactory JNDI 名称进行访

问。这两个连接工厂之间的唯一不同是 XAConnectionFactory 被配置为创建参与分布式

JTA 事务(与其他 XA-aware 资源)的连接。还需要注意的是,默认连接工厂的设置不能修

改,它们的服务器目标也是固定的。

2. 队列、主题和模板

JMS 队列和主题通常也称为“目的地”,是保存生产者发送的消息和等待传递给消

费者的消息集合。在 JMS 模块内可将这两种目的地类型定义为资源。队列遵循点对点传

递模型,而传入的消息则总是传递给单个消费者。主题遵循出版/订阅模型,传入的消息

被传递给订阅它的所有客户。和连接工厂一样,客户通过 JNDI 查找 JMS 目的地。目的

地的主要配置参数是阀值、限额和传递失败设置。2.6.1 小节已经介绍了前两个参数。目

的地的传递失败设置确定服务器重新传递消息的次数,在重新传递过程中进行尝试的次

数,以及最后保存消息的备用目的地(也称为错误目的地)的名称,因为重新传递尝试的

次数用完之后就不能再进行重新传递。

JMS 模板是另一种 JMS 模块资源类型,它能够定义配置,可以基于它新创建目的地。

JMS 客户通常使用模板动态创建临时目的地,以便将这类客户需要指定的配置层减到

最小。

3. JMS 模块类型和定位

和 JDBC 模块一样,WebLogic Server 也提供应用程序范围内和系统范围内的 JMS

模块。应用程序范围内模块的配置被嵌入特定应用程序部署存档文件内。而系统范围内

的 JMS 模块在域层定义,其配置包含在 DOMAIN_ HOME/config/jms 目录里,并从域的

config.xml 目录引用。相对于应用程序范围内的模块而言,系统范围内的模块可通过 JMX

访问,并且在最初创建之后可以用新资源扩展它。在部署时修改各种类型模块配置的方

法也不同,因为对于系统范围内的模块而言,这种修改需要在 JMX 和/或 WLST 层完成,

Page 32: Oracle WebLogic Serverimages.china-pub.com/ebook60001-65000/61112/ch02.pdf · Oracle WebLogic Server 在讨论Oracle Fusion Middleware架构之前,先详细介绍一下Oracle WebLogic

第Ⅰ部分 Oracle Fusion Middleware 11g 架构与管理

44

而对于应用程序范围内的模块则需要使用部署计划。

必须将 JMS 模块的资源定位到 WebLogic Server 实例或特定 JMS 服务器,JMS 目的

地资源只能定位到 JMS 服务器。可以以不同方式定位模块内的每个资源。实现方式就是

通过子部署。子部署在 JMS 模块层定义,它标识 JMS 模块资源的潜在目标。因此,模

块资源可与定位它们的特定子部署相关联。这种定位机制如图 2-7 中虚线箭头所示。

4. 外部 JMS 服务器

外部 JMS 服务器资源可指向外部第三方 JMS 提供者,允许在服务器本地 JNDI 树内

访问 JMS 资源(连接工厂和目的地),因此也能够与第三方 JMS 提供者集成。外部服务器

有自己的相关连接工厂和目的地,每个都有一个本地 JNDI 名称(在本地服务器上运行的

客户使用该 JNDI 名称)和一个远程 JNDI 名称(在外部服务器的 JNDI 树中,本地 JNDI 名

称映射该 JNDI 名称)。

2.7 WebLogic Server 请求管理

能够有效地并行处理传入的应用程序请求是 WebLogic Server 架构的重要特性。

WebLogic Server 的请求管理基础设施确保传入的请求与服务器线程相关联,并被正确地

分配给目的地—— 可能是 servlet、EJB 或者其他容器。本节将详细分析这种基础结构。

2.7.1 连接和端口管理

必须将传入的请求发送到服务器的监听端口。在默认情况下服务器只有一个监听端

口,但有 3 种方法可以改变这种设置。

● 启用服务器的 SSL 端口 顾名思义,这个端口用于所有基于 SSL 的连接。本书

第 9 章将详细讨论 SSL 连接。

● 启用域范围内的管理端口 这是一个 SSL 端口,域内的所有服务器都启用它,它

专门用于管理通信量。管理端口能够将传入的应用程序通信量与管理通信量—— 例

如所有 JMX MBean 请求以及受管理服务器和管理服务器之间的配置同步—— 分

离开。必须使用管理员证书才能访问服务器的管理端口。

● 创建网络通道 网络通道这种 WebLogic Server 机制能够在给定服务器上创建新

的监听端口和/或监听地址。

每个监听端口都与一个监听线程相关联,它唯一的任务是为所有连接请求创建套接

字连接,并将它们保存在活动的连接集合里。WebLogic Server 维护特定的线程池—— 也

称为 muxer 线程池—— 这些线程负责监控传入请求事件的每个活动的套接字连接,从连

接读取这些请求,再将它们与合法协议(HTTP、IIOP 等)和目标应用程序关联起来。请求

经过 muxer 线程处理之后被传递到 Work Manager,它负责区分优先次序,并将请求分配

给执行线程,执行线程则在应用程序上下文中执行请求。2.7.2 小节将详细讨论 Work

Manager。图 2-8 说明从监听端口到执行线程的逻辑 WebLogic Server 请求流程。

Page 33: Oracle WebLogic Serverimages.china-pub.com/ebook60001-65000/61112/ch02.pdf · Oracle WebLogic Server 在讨论Oracle Fusion Middleware架构之前,先详细介绍一下Oracle WebLogic

第 2 章 Oracle WebLogic Server

45

监听端口

请求 Muxer 线程 Work Manager

Muxer 线程池

全局和应用程序

Work Manager

执行队列 执行线程

执行线程池

图 2-8 从监听端口到执行线程的逻辑 WebLogic Server 请求流程

2.7.2 Work Manager

如 2.7.1 小节所述,对 WebLogic Server 实例的每个传入请求最终都在执行线程上下

文中执行。每个服务器都有一个执行线程池,从该池给所有请求分配线程。由于限制了

线程的最大数量(按此数量活动进程可以以最佳方式运行),因此传入的请求将竞争可用

的执行线程份额,当没有可用线程时,则将它们保存在执行队列中。WebLogic 每隔两秒

就会自动调整执行线程池的大小,该数量不能手动更改。用来控制将请求分配给线程方

式的实体称为 Work Manager。

可以将 Work Manager 看作一个负责在服务器实例进程上下文内表示应用程序执行

线程份额的代理。换句话说,Work Managers 负责确保给应用程序的传入请求分配相应

的服务器可用执行线程份额。在默认情况下,每个部署的应用程序都与自己的 Work

Manager 相关联,它负责所有目标为应用程序的请求。所有应用程序的默认 Work Manager

确保每个应用程序都有相同机会获得请求的执行线程。应用程序可以使用其默认 Work

Manager 并按需要配置它,也可以让它们为特定类型的请求使用新的 Work Manager。本

小节下面将介绍如何配置这种特定 Work Manager,还将讨论它们提供的线程分配配置参

数的类型。

可以使用部署存档文件的部署描述符配置自定义 Work Manager,其中只有存档文件

的应用程序可以使用它们;也可以在域层配置它们,在这种情况下域内部署的所有应用

程序都能使用它们。即使在域层定义 Work Manager,仍然需要从应用程序的部署描述符

中显式引用它。下面是示例 weblogic-application.xml 文件,它引用域层的 Work Manager。

<work-manager>

<name>pricing-service</name>

</work-manager>

自定义 Work Manager 的策略适用于所有部署描述符(在该描述符中定义它们)层的应

用程序,并适用于存档文件内描述符层次结构下的所有应用程序。Work Manager 主要有

3 类策略:请求类、线程约束和容量约束。可以在给定 Work Manager 上配置这 3 种实体

的实例,以指定它们的策略详情。下面依次介绍这 3 种策略类型。

自定义 Work Manager 可以引用 3 种不同类型的请求类:response-time、fair-share 和

context。response-time(响应时间)请求类为其管理的请求定义响应时间目标。定义这种请

求类时,服务器连续检查给定请求类型存档的响应次数,如果因为缺少可用请求线程导

致响应类的目标没有达到,它将提升该请求类型线程分配的优先级。fair-share(公平共享)

Page 34: Oracle WebLogic Serverimages.china-pub.com/ebook60001-65000/61112/ch02.pdf · Oracle WebLogic Server 在讨论Oracle Fusion Middleware架构之前,先详细介绍一下Oracle WebLogic

第Ⅰ部分 Oracle Fusion Middleware 11g 架构与管理

46

请求类定义一个数值(介于 1~1000),它定义 Work Manager 相关请求的相对优先级—— 相

对于其他具有 fair-share 请求类的 Work Managers 而言。例如,如果应用程序,FOO 和

BAR 分别与 fair share 值 60 和 40 相关联,当服务器以全线程容量运行时,随着时间的推

移,FOO(上下文)限制请求最终将占用服务器请求线程的 60%,而 BAR 限制请求最终约

占 40%。Context(上下文)请求类能够依据经过验证的原则(用户名或组)将 response-time

或者 fair-share 请求类与请求的类型关联起来。

顾名思义,最小和最大线程约束指定执行线程的最小数量和最大数量,服务器将

Work Manager 的相关请求类型分配给这些线程。通常不需要使用这些约束,因为请求类

提供了更灵活的方法来指定应用程序的线程调度需求。

可以定义的最后一类 Work Manager 策略是容量约束。该策略确定在服务器的执行队

列里排列的最大请求数量,之后服务器将向发送特定类型请求的客户发送错误响应。

在完成 Work Managers 的讨论之前还需要说明的是,Work Manager 及其策略配置可

以在多个应用程序之间共享。例如,下面的程序清单是两个不同应用程序的 weblogic-

application.xml 片段,这两个应用程序引用相同的请求类。下面是第一个应用程序的程序

清单。

<work-manager>

<name>pricing-service</name>

<fair-share-request-class>

<name>priority-application-share</name>

</fair-share-request-class>

</work-manager>

下面是第二个应用程序的程序清单。

<work-manager>

<name>pricing-web</name>

<fair-share-request-class>

<name>priority-application-share</name>

</fair-share-request-class>

</work-manager>

priority-application-share 请求类是一个全局请求类,它在域的 config.xml 文件里定义

如下所示。

<self-tuning>

<fair-share-request-class>

<name>priority-application-share</name>

<target>cluster1</target>

<fair-share>80</fair-share>

</fair-share-request-class>

</self-tuning>

在多个 Work Manager 引用相同请求类的情况下,min/max 线程或容量约束和这些实

体定义的策略由引用 Work Managers 的请求类型共享。对于前面程序清单所列的示例来

Page 35: Oracle WebLogic Serverimages.china-pub.com/ebook60001-65000/61112/ch02.pdf · Oracle WebLogic Server 在讨论Oracle Fusion Middleware架构之前,先详细介绍一下Oracle WebLogic

第 2 章 Oracle WebLogic Server

47

说,它表示如果在域内定义 fair-share 请求类值为 20 的其他 Work Manager,那么与

priority-application-share 请求类相关联的请求类型在高峰时将共同占用服务器执行线程

的 80%。

讨论完 WebLogic Server 请求管理基础结构之后,对 WebLogic Server 主要子系统及

其架构的介绍也就结束了。下面将注意力转移到用例,阐述本章前面讨论的某些概念在

实际情况下的适用性。

2.8 本章用例

下面介绍本章用例,其目的就是在实际情况上下文中应用本章前面介绍的一些概念。

本章用例通过一些必不可少的步骤,介绍一个简单的为 WebLogic Server 构建并已经开发

完成的自定义 Java EE 应用程序,该应用程序最后由预期用户评估。

2.8.1 用例描述

假设你被雇用为某个中型日用品制造公司 IT 部门的 Oracle Fusion Middleware 专家。

你的第一项任务是,与专业产品业务开发团队经理 Jane 见面,理解她对新应用程序的宿

主需要。在此过程中你知道她已经将这项工作承包给了一位自由开发人员,并且该开发

人员已经完成应用程序开发。Jane 希望 IT 部门能够确保对该应用程序进行相应的测试,

确保它能够供 Jane 团队的一些成员(约 3 人)用于体验。Jane 还说她知道 IT 部门已经标准

化 Oracle WebLogic Server,所以她已经指示承包人构建在 WebLogic 上运行的 Java EE

应用程序。

与经理讨论情况之后,你们达成一致:考虑到新应用程序的使用部门和体验用途,

管理它的最好方法是将其作为一个特定用例,该用例不需要完全展示给 IT 部门的宿主基

础。而你决定将该应用程序作为一项单独服务,仅供 Jane 的团队访问和使用。按照这种

策略,你开始约见应用程序的唯一开发人员,以便更好地理解应用程序的本质。

2.8.2 理解应用程序及其环境

与应用程序开发人员见面之后,了解了与应用程序及其架构本质有关的许多情况。

有问题的应用程序是定价引擎,专业业务开发团队使用该引擎来依据市场条件变化获得

特定产品的推荐价格。该应用程序被部署为单个 EAR 文件,并提供下面两个外部接口。

Pricing Model Web Service(定价模型Web服务) 一个提供单独操作(称为modifyModel)

的 Web 服务接口,外部系统可通过该操作将新产品添加到定价引擎模型,或者更新现有

产品的模型参数。要更新模型,Web 服务将其操作的输入转换为 JMS 消息,然后将它保

存到 JMS 队列中。JMS 队列的消费者是 MDB,它将消息从队列中取出,并相应更新数

据库(通过 JPA 实体)。

Pricing Engine Web Application(定价引擎 Web 应用程序) 一个简单的 Web 应用

程序,业务开发团队通过输入其 SKU 来查询产品的推荐价格。图 2-9 显示的是应用程序

的查询页面(实际上应用程序仅有的另一个页面是登录页面)。应用程序通过 JSP 和 servlet

Page 36: Oracle WebLogic Serverimages.china-pub.com/ebook60001-65000/61112/ch02.pdf · Oracle WebLogic Server 在讨论Oracle Fusion Middleware架构之前,先详细介绍一下Oracle WebLogic

第Ⅰ部分 Oracle Fusion Middleware 11g 架构与管理

48

实现,它们调用 EJB(SLSB)接口,该接口再查询数据库,检索查询产品的属性,计算推

荐价格。

图 2-9 定价引擎 Web 应用程序查询页面

因为应用程序的展现接口只通过 Web 服务和 Web 应用程序,因此不必担心任何为

外部客户访问引用配置的外部 JNDI。为简单起见,此时不建议使用应用程序的 Web 服

务接口,只将它部署为将来会使用的特性(第 3 章的用例会利用该特性)。Web 应用程序

的安全性通过基于窗体的登录页面启用,唯一受保护的页面是查询页面,这样只有“sales”

角色内的用户才能通过下面的策略在 web.xml 层访问它。

<security-constraint>

<web-resource-collection>

<web-resource-name>query page</web-resource-name>

<url-pattern>*.jsp</url-pattern>

<http-method>GET</http-method>

<http-method>POST</http-method>

</web-resource-collection>

<auth-constraint>

<role-name>sales</role-name>

</auth-constraint>

</security-constraint>

因为到目前为止开发人员是应用程序的唯一用户,因此他只是在应用程序的

weblogic.xml 部署描述符中简单地将 sales 角色映射到管理用户 weblogic,如下所示。

<wls:security-role-assignment>

<wls:role-name>sales</wls:role-name>

<wls:principal-name>weblogic</wls:principal-name>

</wls:security-role-assignment>

开发人员当前使用自己计算机里的域来开发应用程序。该域只有一个服务器:管理

服务器,它也被用为应用程序的部署目标。详细检查开发人员的域目录之后,会发现:

● 使用 staged 分期模式和 DD only 安全模型部署应用程序。

● 域包含两个数据源,它们都指向相同的 MySQL RDBMS 模式。其中一个数据源

使用 XA JDBC 驱动程序,另一个使用非 XA 驱动程序,支持全局(JTA)事务标

记被设置为 false。开发人员解释说需要这两个数据源作为应用程序使用 JPA 实

体的结果。

Page 37: Oracle WebLogic Serverimages.china-pub.com/ebook60001-65000/61112/ch02.pdf · Oracle WebLogic Server 在讨论Oracle Fusion Middleware架构之前,先详细介绍一下Oracle WebLogic

第 2 章 Oracle WebLogic Server

49

● 开发人员通过修改 startWebLogic.cmd 脚本,并将其路径保存在管理服务器的系

统类路径上,使服务器可以使用 MySQL JDBC 数据源 JAR 文件。

● 目标为管理服务器的 JMS 服务器没有使用任何自定义配置。

● 已经配置包含两个资源—— ConnectionFactory 和 Queue—— 的单个全局 JMS 模块。

这两者都通过 subdeployment 配置定位到 JMS 服务器,都没有任何非默认配置。

理解应用程序并且掌握应用程序 EAR 文件和开发域目录之后,就可以开始设计评估

环境,在该环境中驻留该应用程序,以便 Jane 的团队使用。

2.8.3 设计评估环境

对于创建评估环境而言,很明显必须对应用程序及其环境配置进行某些改变。下面

将介绍配置和创建评估环境需要考虑的一些变更。

1. 应用程序拓扑

我们知道,要将应用程序部署在受管理服务器里而不是管理服务器里,但假设有一

些用户偶尔使用应用程序,因为应用程序不是重要业务,所以你决定使用单个受管理服

务器,并且让整个域在同一台主机上运行。但为了将来简化拓扑向外扩展,还应该在群

集里创建受管理服务器,该群集目前只有一个成员,但将来根据需要可以很方便地用新

复制的受管理服务器来扩展群集。

说明

创建只有一个受管理服务器的拓扑时,应考虑将它分配给群集,这样如果将来需要

添加新服务器,就更容易向外扩展。

而且,你决定启用评估主机上的节点管理器,并让它启动服务器,以及在失败时自动

重启服务器。最后,假设 Web 应用程序的用户数量非常少,你决定暂时不需要前向 Web

服务器,并将浏览器请求直接定位到某个受管理服务器。图 2-10 是你设计的评估拓扑。

主机(h1)

受管理服务器 (ms1)

管理服务器

节点服务器

群集

(c1

)

图 2-10 定价应用程序的评估拓扑

Page 38: Oracle WebLogic Serverimages.china-pub.com/ebook60001-65000/61112/ch02.pdf · Oracle WebLogic Server 在讨论Oracle Fusion Middleware架构之前,先详细介绍一下Oracle WebLogic

第Ⅰ部分 Oracle Fusion Middleware 11g 架构与管理

50

2. 应用程序安全

弄清应用程序的域拓扑之后,就可以计划其安全配置了。考虑到应用程序的用户基

数非常小,并且该应用程序只用于体验,因此决定继续使用WebLogic Server嵌入式LDAP

来保存用户和组,以及应用程序的角色和授权策略。这就意味着不必担心在域内配置任

何新身份验证或授权提供者,可以使用域的管理控制台来提供所需的角色、组和用户。

由于没有计划引入新的授权策略,而是希望修改应用程序开发描述符内由开发人员

选择的默认 weblogic 用户到角色 sales 的映射,因此决定给应用程序部署 Custom Roles

安全模型。这将创建一个容器层的角色,其名称为 sales,它的成员策略将控制应用程序

的授权用户。还可以创建一个名为“SpecialtySales”的组,并将它添加到容器层 sales 角

色的成员策略,继续创建分配给该组的应用程序用户。图 2-11 说明在容器层 web.xml 授

权策略如何映射到角色、用户和组。

组:

默认授权提供者(嵌入式 LDAP)

用户: 用户:

嵌入式

应用程序

图 2-11 在容器层 web.xml 授权策略如何映射到角色、用户和组

3. JMS 和 JDBC 配置

确保部署质量的下一步是理解定价应用程序所需的 JMS 和 JDBC 配置。从开发人员

的设置来看,首先要改变的是访问 MySQL JDBC 驱动程序的应用程序系统类路径的配置

(在开发环境中通过直接修改 startWebLogic.cmd 启动脚本进行设置)。开发人员使用的方

法有两个问题。首先,由于计划使用节点管理器,因此通过 startManagedWebLogic.cmd

脚本不能启动受管理服务器,也就无法简单地将驱动程序添加到脚本的系统类路径。其

Page 39: Oracle WebLogic Serverimages.china-pub.com/ebook60001-65000/61112/ch02.pdf · Oracle WebLogic Server 在讨论Oracle Fusion Middleware架构之前,先详细介绍一下Oracle WebLogic

第 2 章 Oracle WebLogic Server

51

次,凭经验可以知道,直接修改系统类路径可能导致很难检修的问题。因此可以将 JAR

文件添加到域的/lib 目录,以确保作为服务器系统类加载器的直接子程序可用,不管将

它们定位到哪个服务器,对域的数据源都可用,通过这种方法让评估环境可以使用 JDBC

驱动程序。除了这些变更之外,你确定不需要对 JDBC 配置进行其他修改,这些 JDBC

配置来自部署环境而不是 JDBC 模块定位,需要将它定位到群集而不是管理服务器。为

了最终确定容器的 RDBMS 配置,可以使用 DBA 部门,给它们提供应用程序的预期数

据库空间和使用需求(希望这两者都最小),以及应用程序的 DDL,它是开发人员提供的,

包含创建和生成所需定价引擎表的脚本。DBA 部门再使用合适的证书创建一种模式,可

以将这些证书用于配置域的数据源。

从 JMS 配置的角度来看,不必担心自定义和调整,因为此时并未计划使用产生应用

程序 JMS 消息的 Web 服务。但要相应调整 JMS 资源的定位。为此首先要将 JMS 定位到

单个受管理服务器,然后在 JMS 模块里创建两个子部署。第一个用于将连接工厂定位到

群集,第二个用于将队列定位到 JMS 服务器。

4. 提供评估环境

通过使用 WebLogic Server 配置向导创建域,然后使用域的管理控制台自定义它,此

时已经在分期环境内设置好应用程序的最终评估配置。如果对这种环境满意,并已经测

试里面的应用程序,就要为评估制定一个计划。为此,你决定使用 WebLogic Server 域配

置模板功能从用来创建评估域的分期域创建域模板。然后在域的 DOMAIN_HOME 目录

里以离线模式运行 WLST,执行下面的命令来创建模板。

wls:/offline>readDomain('.');

wls:/offline/pricing>writeTemplate('pricingdomaintemplate.jar');

这些命令读取域的配置,并在 pricingdomaintemplate.jar 文件里捕获它。该模板不仅

捕获域的拓扑、所有资源及其配置,而且还包括域目录的内容,包括/lib 目录的 MySQL

JDBC JAR 文件和以 staged 模式部署到域的所有应用程序的存档文件。但模板不包括在

域的嵌入式 LDAP 里创建的角色、组和用户。现在可以将模板文件保存到定位定价应用

程序的评估主机,并使用 WLST 创建评估域。但先要在评估主机上安装 WebLogic Server,

并相应配置节点管理器。

要使用刚刚从分期环境创建的应用程序域模板创建目的地域,必须知道两个重要细

节。首先,创建的域模板包含定价引擎应用程序部署存档文件,通过将它保存在主目录

将它们部署到分期环境,然后使用 staged 模式将它们部署到域的群集。现在需要确保创

建评估域在适当位置保存部署存档文件,以便管理服务器查找和部署。为此,可使用

WLST setOption()命令将保存存档文件的位置设置为域创建的一部分。其次,还要使用

setOption()命令让评估域的服务器以 production 模式运行。这种模式设置许多域参数值,

它们更适合生产环境。受这种模式影响的值主要有以下几个。

Page 40: Oracle WebLogic Serverimages.china-pub.com/ebook60001-65000/61112/ch02.pdf · Oracle WebLogic Server 在讨论Oracle Fusion Middleware架构之前,先详细介绍一下Oracle WebLogic

第Ⅰ部分 Oracle Fusion Middleware 11g 架构与管理

52

● 禁用管理服务器的自动部署设置。该设置在开发环境中很有用,在开发环境中通

过在域的 DOMAIN_HOME/autodeploy 目录里保存应用程序,就可以实现频繁的

重新部署,但在生产环境中就没有必要。

● 用于该环境的 Java Runtime 被设置为到 Oracle JRockit 而不是 Oracle Sun HotSpot

虚拟机。

● 启用管理控制台的变更控制设置,这样如果没有显式锁定配置和后续激活变更,

变更就无法完成。

在/domains 目录里创建评估域的 WLST 命令如下所示。

wls:/offline/prcingEval>readTemplate('pricingdomaintemplate.jar');

wls:/offline/prcingEval>setOption('AppDir',

'/domains/prcingEval/pricingapp');

wls:/offline/prcingEval>setOption('ServerStartMode','prod');

wls:/offline/prcingEval>writeDomain('/domains/prcingEval');

因为域的模板不包含嵌入式 LDAP 的自定义内容,因此必须重新创建域的用户和组,

并将他们映射到新 sales 角色,如本小节“2.应用程序安全”所述。最后,为了让用户更

方便地访问应用程序,可以联系 IP 部门的网络小组,将应用程序的访问

URL(http://<host-name>:7002/PricingServiceWeb)映射到用户友好的适当地址(如 http://

myenterprise/sales/pricing)。最后一步完成之后,Jane 的团队就可以在评估环境中使用定

价应用程序来进行评估。

2.9 小结

至此已介绍完 WebLogic Server 架构。本书后面几章将以与本章相同的风格介绍

Fusion Middleware 堆栈的其他组件,以及它们对 WebLogic Server 基础设施的依赖性。本

章讨论的 WebLogic Server 架构的元素在探讨其他 Fusion Middleware 组件时具有重要作

用。第 3 章将介绍所有 Fusion Middleware 组件都用到的基础设施组件。