WAS 7系统管理的惊鸿一瞥

我从2000年开始使用WAS，第一个项目是农行网上银行，WAS 3.0，那个时候WAS的管理界面是Java客户端。WAS给人的感觉是系统管理方面显得比较笨重，不过在WAS 5开始，这方面的改进非常显著。这不，让人期待的WAS 7发布了。系统管理方面又有不少新特性。让我们看看到底有哪些改进（我选了几个我认为在系统管理方面能带来显著便利的新特性）。

1、  管理代理（Administrative Agent）

还是讲一个故事，前一段时间银联数据使用WAS，采用的是应用服务器节点的类型。当WAS接受大量的应用请求时，系统出现CPU使用过高的情况，这时想查看WAS的性能信息，但是用WAS管理控制台无法登陆，因为作为应用服务器节点类型，管理和应用都使用同一个应用服务器，共同使用一个Web容器，应用将线程池占满了，WAS管理控制台也就无法登陆了。现在好了，有了新的特性，管理代理。

WAS 7 引入了新的可选管理服务器，称为管理代理，以通过以下方式处理此类挑战：

l 多个独立应用程序服务器可以向单个管理代理注册；一经注册，即可通过单个管理代理监视和控制应用程序服务器。

l 管理代理成为了用于管理同一计算机上的多个独立应用程序服务器的中心入口点。如果用户管理的拓扑包含单台计算机上的大量独立应用程序服务器，则这种方法是极为重要的。

l 所注册的服务器的管理服务被合并到管理代理中，从而减少了以前的重复服务的内存占用空间。

l 管理代理执行的管理功能在所注册的应用程序服务器之间保持隔离，从而使得用户能够针对所管理的服务器集合中的特定服务器执行操作。

管理代理旨在作为补充 WAS 基本拓扑的选项，其中的独立应用程序服务器继续为应用程序请求提供服务。只有服务器中的管理服务才合并到管理代理中。对于每个向管理代理注册的 WAS 基本概要，将在管理代理中创建一个管理子系统，以表示该概要的新管理入口点。

2、  作业管理器（Job Manager）

前一段时间去过华夏银行，他们的生产及测试环境共使用十多套WAS，他们自己有时正不明白到底有多少，所以管理的时候需要登录每个机器上或者各自的WAS管理控制台，管理起来是相当的不容易。每个WAS做了哪个操作，结果如何，都没有记录，很是不方便。现在有了新的特性，作业管理器。

单个作业管理器可以管理大量作为托管节点向其注册的 WAS 基本版本和 Network Deployment 拓扑。在此模型中，与直接针对独立服务器和部署管理器调用管理操作不同，而是将这些操作作为管理作业提交给作业管理器。然后托管节点按预定义的间隔获取这些管理作业。在 WAS 7 中，作业管理器支持将服务器、集群和应用程序的配置和控制（启动/停止）操作以及执行 wsadmin 脚本作为管理任务。

通过指定作业激活或过期时间、重复执行模式、作业完成时的电子邮件通知等等，可以对作业提交过程进行自定义。

这种新的灵活管理模型提供了许多优点：

l 作业管理器旨在对 Network Deployment 和基本版本拓扑形成补充。不需要对现有的节点进行重新配置。单个作业管理器可以管理数百个节点，并且与 Network Deployment 拓扑中由部署管理器拥有托管节点不同，给定的节点可以由多个作业管理器管理。

l 作业管理器管理的拓扑保持它们的自主性，包括它们的安全配置，从而可以使用现有的管理流程直接对其进行管理，例如脚本或管理控制台。

l 这种模型支持跨多个定义为一个组的托管节点执行协同管理操作。

l 异步作业提交模型可以促进地理上分散并且只能通过低带宽、高延迟网络进行访问的节点的管理。

3、  业务级应用程序（Business-Level Application，BLA）

以前将应用组装在EAR文件中，但是有很多共享库没有地方统一定义，我们需要在每个节点上部署这些共享库，并在通过CLASSPATH让应用去识别。现在有了业务级应用程序，管理整个应用变得更加轻松了。

在 WAS 7 中，BLA 组合可以包括一个或多个 Java EE EAR 文件和Java EE 应用程序所依赖的共享库。BLA 定义为其构成部分提供了操作语义。例如，对某个 BLA调用启动操作将导致启动该 BLA 中定义的所有企业应用程序和共享库。此外，BLA 体系结构支持按引用的递归组合，从而促进 BLA 和各个所部署构件的层次结构组装。此机制支持为特定的业务用途而定义某个 BLA，同时允许将其完整地包括在许多其他组合中，以便服务于更广泛的用途。

BLA 定义将应用程序二进制与它们在特定部署实例中的配置分离，从而促进应用程序二进制跨多个应用程序定义的重用。可以多次配置单个 EAR 文件或库 JAR，使其成为一个或多个 BLA 的一部分。

通过其可扩展的部署模型，BLA 体系结构提供了对 WebSphere 应用程序部署的重要增强：共享库管理。

4、  基于属性的配置

我们都知道从WAS 5开始，WebSphere配置参数存储在一组配置文件中，其中大部分是XML格式。虽然可以使用wsadmin脚本或者控制台进行配置参数的修改，但是这些相对来说有些复杂。我们常常需要从开发环境复制某些参数配置到生产环境中，或者从某一生产环境复制某些参数到另外一个生产环境中去。这种方式不是很方便。现在有了基于属性的配置，这类工作变得容易了。

WAS 7 提供了称为基于属性的配置的重要管理功能，可以简化将管理自动化的体验。使用此功能，管理员可以将 WebSphere 配置提取到属性文件中，属性文件以简单的 <property=value> 格式列出配置参数。所提取的配置的简单格式使得读取和操作它变得非常容易。还可以将属性文件反馈到 WebSphere 管理中，以便将其内容应用于现有的配置。

l 能够创建或删除配置构件，以及读取或操作现有的配置。

l 预览模式，藉此生成报告，指示如何将属性文件中的数据应用于 WebSphere 配置而不实际更改配置。

l 变量支持，允许将属性文件中的值定义为可在应用属性文件时进行解析的变量，从而促进给定属性文件跨多个配置的重用。