在构建基于兼容 J2EE 的应用程序服务器或 XML Web 服务平台的企业级应用程序时，我们倾向于将应用程序可管理性留作基础平台要解决的问题。因此，我们可能不会在业务逻辑中做任何工作，以增强产品中应用程序的可管理性。这不是一个好的策略，并且可能会导致应用程序在部署时比实际情况更难于管理。

J2EE 应用程序服务器是 XML/SOAP Web 服务应用程序的基础，它向我们提供了监视软件服务器和一定程度上监视应用程序的工具。但是，软件开发人员需要开发这些实用程序，以提供更多的应用程序级别的可管理性，而不是平台级别可管理性。可以比较这二者的区别，来了解自己购物车（应用程序级别或业务逻辑级别的一个对象）中的物品数，而不是了解在支持它的 BEA WebLogic Server (WLS) 消息队列中发生了什么。

可管理性的缺乏可能会导致严重的问题。由于操作人员不了解应用程序软件，所以一旦部署这个应用程序软件，它就可能会变成一个难以管理的实体。缺乏对可管理性的关注将大幅度增加支持和维护软件产品的成本。软件开发人员可能正在解决部署管理问题，而此问题却可以通过采用软件生命周期中的较早期步骤得到解决。本文将介绍这些步骤。

本文将描述开发人员的众多选择，包括：

·             将消息从应用程序代码写为可人工识别的文件，并能够使用管理工具适当地处理这些消息。

·             将其中一些日志封装进管理模板中。

·             使用预构建的基于 Java Management Extensions (JMX) 受管理 Bean 对象和操纵它们的工具。

·             生成并使用自己的 JMX 受管理 Bean 对象，以用于特定目的。

稍后将解释这些 JMX 受管理 Bean 对象后面的概念。

我们可以视这些步骤为应用程序可管理水平的逐步提高。对一个应用程序来说，我们可以使用其中的单个步骤或是全部步骤。本文列出了多种技术，帮助开发人员将它们集成并构建为一个更好的应用程序。好消息就是许多艰难的工作已经可以用应用程序服务器和管理工具来执行。但是，仍有一些工作需要在应用程序中完成。

背景

作为开发人员，有时我们会认为，如果我们已经在应用程序的文本日志文件中生成了消息，则对应用程序的可管理性就做得足够了，不需要做更多的工作了。这些对于非常简单的应用程序部署的管理来说是足够的。如果有应用程序的两个副本（或实例）需要并行运行，那么就需要对日志文件方法的设计投入更多的精力。

但是，应用程序可管理性并不仅限于知道应用程序是否还在运行、或者它是否已经在其日志文件中生成了一条错误消息。对于某些应用程序，我们可能需要知道应用程序在过去的一到两个小时内处理了多少用户事务，每一个事务平均花费多少时间，以及未完成事务的百分比。复杂的应用程序有请求的队列，其中一些请求未处理，另一些正在处理。在这种情况下，系统管理员需要了解每一个队列的情况，以便能够正确地对问题情况做出响应。举例说来，如果进入请求的队列可能会引发到最终用户处的延迟，那么管理员可能会想通过将其中一些队列分配给其它类似的进程的方法，来避免此类问题。

我们需要“可管理性”一词的框架性定义，以便于确定应在一个应用程序中构建多少的可管理性。“可管理性级别”决定了我们要使用哪些技术以及我们将在应用程序设计的这一方面付出多少努力。

可管理性的定义

我们将“可管理性”一词定义为：在某组件上，执行管理和监控操作以及接收与这些操作相关的信息的能力。

可管理性可以被进一步细分为三个主要方面：

1.         监视：从一特定组件中捕获用于报告和通知的运行时事件和历史事件的能力。

2.         跟踪：跨多个组件观察单独的工作单元的各方面以及线程的执行（例如，跟踪从发信人到收信人的消息）的能力。

3.         控制：改变受管理组件运行时行为的能力（例如，改变应用程序的日志级别）。

可管理性包括以下内容：确保应用程序正在使用并且工作正常；以及检查应用程序性能是否正常。当有问题发生时，通过可管理性工具，故障排除工程师可以找到该问题。可管理性的这些方面可以用来评估各种技术。

而且，可管理性还包括监视、跟踪和控制同一软件的多个实例。例如，在 J2EE 应用程序服务器上构建的应用程序会由于负载平衡和容错的原因，而频繁地在几台计算机上进行复制。操作员需要能够一直查看和控制其中的每一个实例的活动级别。这样他们可以重新路由请求或者采用其它操作来减少问题和维护服务级别协议。

可管理性中的关键设计决策

为了将可管理性功能应用于他/她的软件中，开发人员必须要做出下列决策：

·             什么级别的信息对于软件操作人员来讲最有用？

·             作为此信息的结果，将在软件上采用什么操作？

·             什么样的信息详尽程度（单个对象的细粒度访问，或者对子系统、模型或其他对象的粗粒度访问）对于应用程序可管理性来讲是最好的？

·             是否允许管理软件与应用程序代码进行同步交互，或者是否所有的操作都必须在“事后”才执行？

向应用程序构建可管理性的方法

本节描述了一组将为应用程序构建可管理性的技术方法。它们以开发人员方面“要做的工作”的升序来显示。这些技术不会相互排斥，并且在许多应用程序中正确的可管理性级别是通过组合这些技术中数种来实现的。大部分应用程序开发人员都将识别出第一个选项，将消息写入日志文件中，正如他们通常考虑到对任何应用程序要做的那样。这就是说原来的产生日志文件的应用程序将很容易实现这一可管理性级别，该级别适于上面的“监视”类别。

应用程序日志文件

许多应用程序被设计为使用标准的编程 I/O 机制在日志文件中或在屏幕上产生一组文字的、可供人识读的错误消息。这些日志文件可供操作人员查看来发现错误，还可以由一个单独的进程进行扫描，此进程获取重要消息并将它们显示在管理控制台上的某个窗体中。管理基础设施，如 HP 的 OpenView Operations (OVO)（带有消息取源和处理功能）支持这种类型的功能，同时还支持这些消息的复杂过滤。

从应用程序直接记录到管理控制台

每一个应用程序都有自己解决此问题的方法。例如，在 HP OpenView 管理套件中，“opcmsg”命令用于将消息直接记录到 OpenView 管理控制台，并有一个类似的 C 和 Java API 用于对控制台的程序性访问。编程人员可以选择是否根据需要的迫切程度而将对此记录 API 的调用构建到他们的程序中，以便于在某一时间点不使用进一步筛选就可以将此信息提供到控制台。使用严重级别或类别（例如，“信息”、“警告”、“严重警告”和其他可以用管理工具帮助解释这些消息的级别或类别）在日志文件中标记不同的文字消息。这些标签对于不了解软件内部的操作人员来说是必须的。管理工具将从尽可能大的一组消息中检出“严重警告”消息并在显示设备上突出显示。

从应用程序间接记录

然而，应用程序编程人员不必将对控制台记录 API 的调用（在前面提到的）嵌入到应用程序中。应用程序开发人员可以将记录消息集中到一个文件或其他永久性存储中，并且稍后可以使用管理工具来选择性地显示这些消息。

OVO 工具箱是一些将应用程序日志文件（和其他数据源，例如二进制文件和 SNMP 陷阱）作为消息源封装的实用工具。而且，这里有用以设置“模板”的屏幕或在位于中央的管理服务器上处理这些消息的模式，然后将这些模板分发到受管理以便以这种方式监视应用程序的所有实例。例如，此处理模式可以定义要排除某些消息类型，使之不在管理控制台上显示。处理模板可能会重新调整消息的格式，或者将一组消息组合成一个，避免由于消息过多而出现操作员重载。模板设置人员有很多选择，有关这些选择的完整信息，请参阅 OVO 管理员指南。开发人员或 IT 操作人员所需做的仅是：

1.     识别文件或其他消息来源（例如 Windows 中的 SNMP 或事件日志）。

2.     从提供的模板集中选择现有的消息模板，或新建一个模板。

3.     将消息处理模板附加到消息源。

4.     将此消息分发到需要的位置（计算机、应用程序站点）。

开发人员可以选择这些日志文件的监视选项并对下列因素做出决策：

·             读取日志文件的时间间隔。

·             是从文件开头开始读取还是从上一次扫描位置开始。

·             在完成对文件的访问（以及其他因素）后是否关闭该文件。

日志文件封装和消息模板处理中的问题

筛选消息：由于消息记录方法可能导致产生过多消息的问题，从而难以向操作人员提供关于软件运行情况的有意义的信息。注意将每一个消息都标记为“信息”、“警告”、“严重警告”以及其他可能的类别，这种做法会有助于解决这种问题。开发人员应与操作员共同决定是否要取消不重要的消息。

可以实现这种目标：筛选消息以突出显示那些在特定情况中有意义的消息。然后这些筛选器会将消息馈送到后续通知命令或逻辑片断中。这些工具存在于可以得到这些消息的管理平台中，并会请求操作人员以某种形式对消息做出响应。

相关性：消息相关性也是一项需要用户或软件设计者更关注日志文件的任务。最终用户/操作人员需要将适用于一种情况的消息手动地进行关联，或者必须编写出一个功能段来为他执行此关联。OpenView 操作模板可以很好地为开发人员解决此问题。

有关日志文件处理和消息处理的详细信息，请参阅 OpenView 操作概念指南 (OVO-Concepts) 以及 OpenView 操作管理员指南 (OVO-Admin)。

日志文件摘要

建议将这种消息文件封装方法作为为应用程序构建可管理性的最小开始级别。若要得到充足的应用程序可管理性，它只是必要条件，但不是充分条件。使用此方法，我们已经实现了前面定义部分所描述的可管理性“监视”方面的一些部分。这就是说，我们至少可以看到开发人员特意关照的应用程序的那些部分，但是我们至今尚不能对其实施控制。我们将在下一节探讨“控制”主题。

Java Management Extensions 标准

Java Management Extensions (JMX) 已经成为管理 Java 应用程序的公认的工业标准。Java community process (JCP) 内的 JMX 规范是名为JSR3 的 Java Specification Request (JSR)。单独的规范 (JSR77) 是 J2EE 1.4 规范的一部分。它是对象“模型”的一个描述，每一个规范服务器必须通过 JMX 暴露这些对象。写此文章时，J2EE 规范的 1.4 版本仍未完成。有关这些提交请求的详细信息，请分别参阅 JSR3 和 JSR77。JMX 规范以标准的方式规定了 Java 应用程序可管理性方面的构建。

JMX 环境包含软件的三个级别

·             规范

·             代理

·             分布式服务

图 1 中描述了这些级别（分布式服务层是最高级别）。

在 Instrumentation Level（规范级别）中，存在受管理 Bean 对象，或者 Mbeans。这里将列出符合二者要求之一的 Java 对象：

·             在 Java 世界里被称为JavaBeans 的对象结构的简单样式（适用于简单 Mbeans）。

·             被称为 “DynamicMBean” 的 JMX 标准，适用于更灵活的管理。

·             JMX "Model MBeans"，是 Dynamic MBeans 的扩展，它为管理规范提供了更通用的模板。

符合 JavaBeans 格式很简单。这就是说对象是可序列化的并且有一个空的构造函数。常见的做法，是在所有需要对外部管理工具可见的对象属性或数据成员（类变量）上实现“getter” 和 “setter” 方法。以这种样式创建 MBeans 意味着：一旦 Mbeans 在称为 Mbean 服务器的 JMX 服务器上注册，就可以在图表顶部的分布式服务层使用工具实现监视和控制目的。

JMX 需要使用图 1 的Agent Level（代理级别）中显示的 MBean 服务器。需要将 MBeans 在 MBean 服务器上注册表明其存在，以便于被管理框架注意到。MBean 服务器处理流入和流出以前作为 Mbeans 注册的对象的管理消息。可以使用管理工具查看符合 Mbean 界面的对象的特定属性，并且在某些情况下，还可以使用管理控制台的功能更改对象的行为。这是通过允许管理控制台从 JMX 服务器提取数据的连接器和其他适配器来完成的，而不是通过 Mbeans 自己的直接操作完成的。

对于 JMX 开发人员来讲 MBeans 的关键问题

由于MBean 机制提供了一种将一个业务对象与另一个专门实现可管理性的 Mbean 包装在一起的工业标准方法，因而MBean 机制是功能强大的。

使用 MBean 界面目录中的权衡

JMX 的规范并不能确定业务对象是否本身可能就是Mbean。这是有可能的，因为Mbean 层次结构是由界面组成的。此方法的缺点是业务对象现在既包含业务逻辑还包含可管理性逻辑，这会导致此方法更加复杂。如果同时包含业务对象和其同等 Mbean 对象，则引用或指针可能会从二者之间被删除，这是此方法提供的一个优点。稍后我们将对其进行讨论。

开发人员可以选择使业务对象符合相应的 JMX 样式界面，也可以选择构建专用于业务对象管理的单独的 JMX Bean 对象。为什么这种区分这么有意义？是因为每种技术都有自己的优点。

使用继承方法，业务对象可以继承它们的 JMX 管理界面，每一种业务对象实例都将需要在MBean 服务器上进行注册 —— 可能会有成千上万的业务对象实例。利用一个符合 JMX 界面的单独的对象专门用于可管理性，由于它单独在 MBean 服务器上进行了注册，从而使得条目数量较少。那么这个单独管理对象将负责管理一组业务对象。这里可能仅需要业务类所有实例的一个管理对象。这是一种权衡，并且对于所有应用程序没有正确答案。此时开发人员必须做出一个设计决策。稍后我们将对其进行讨论。

通信和链接

JMX 规范没有指定如何实现业务对象和 Mbean 之间的通信。它完全由应用程序开发人员进行控制。

因此开发人员必须针对下列问题作出关键决策：

·             是否所有的或仅其中一些业务对象的属性（成员变量）对管理工具可见？

·             这些属性是只读或只写的？

·             以什么频率执行从 Mbean 到业务对象的更新，或者反过来，从业务对象到Mbean的更新？

·             是否将有一个MBean用于一组业务对象或每一个业务对象？

应用程序开发人员完全控制了在这些业务对象和 Mbean 对之间进行的通信数量。应用程序开发人员可以选择从一个对象到其他对象的引用，或者选择它们之间的双向引用。

结束语

在本两部分文章的第1部分中，我从应用程序的可管理性决定了产品的接受性来开始讨论。我学到了应用程序可管理性的定义和将其添加到 Java/J2EE 应用程序的一些选项，从最简单的消息记录一直到较为复杂的 JMX 方法。这些方法应看成是互补的而不是互相排斥的。在本文的第二部分中，我将讲述管理工具以及它们是如何帮助我们将更多的可管理性内建到应用程序中的，包括通过应用现有模板以及通过编写代码来实现这一点。

参考资料

·             BEA JMX: http://edocs.bea.com/wls/docs70/javadocs/index.html

·             JSR3: www.jcp.org/en/jsr/detail?id=3

·             JSR77: www.jcp.org/en/jsr/detail?id=77

·             OVO-Metrics: HP OpenView Operations - Metrics Guide

·             OVO-Admin: HP OpenView Operations - Administrators Guide

·             OVO-Concepts: HP OpenView Operations - Concepts Guide

·             OVTA: HP OpenView Transaction Analyzer: www.openview.hp.com/products/transaction_analyzer/index.html

·             Poole: HP OpenView Architectures for Managing Network Based Services