【IT168 技术文章】在本文中研究了网络管理软件的历史，以及它是如何从开始阶段粗陋的软件发展成现今这样复杂而成熟的企业管理系统的。他还研究了困扰这些系统的许多常见问题的根源。以及如何利用 JMX 来解决它们。
Java 管理扩展(JMX)是 Java 平台上热门的新增部分，它承诺为与企业网络管理相关的老问题提供可伸缩的、低实现成本和与旧系统兼容的解决方案。新型的软件服务器(包括象 Jakarta Tomcat 和 JBoss 这样的流行开放源码服务器)能迅速地将 JMX 用作其管理标准。我们将通过研究网络管理软件的历史以及它是如何发展的，来开始我们对 JMX 的研究。
网络管理的发展
早期的网桥、协议转换器和路由器都
是简单的专用硬件设备，通常是通过直接连接到该设备本身串口的终端来配置的。配置命令通常用来启用或禁用端口，或者更改设备支持的协议的特征。这些“黑箱
”上可配置参数的数量是有限的，串行终端界面通常比较“神秘”并且只有受过大量培训的网络操作员才能够理解，如图 1 所示：
图 1. 专门的串行连接
专用网络时期
由于网络规模的增长，以及这些“黑箱”的数目激增，很明显需要一些方法来寻址和控制这些大量的网络设备。一些供应商选择了提供用于管理这些设备的单独的“带外(out-of-band)”互连或集中器网络，如图 2 所示：
图 2. 带外多路复用控制
其他供应商使用了“带内(in band)”技术，这种技术中，在运行这些“黑箱”的同一网络上发送寻址和控制信息，如图 3 所示：
图 3. 带内设备控制和管理
客户机软件(称为管理控制台，该名称是从终端控制台等类似的名称继承而来)从“神秘的”终端样式的界面缓慢地发展成增强的 GUI
配置工具，后者能够对网络上每个可寻址的设备单独地进行配置。由此产生了早期的网络管理系统(NMS)。很大程度上，专用网络协议在这一时期处于支配地
位，早期 NMS 通常使用专用协议来寻址、控制和监控供应商的设备。
TCP/IP 成为了实际的联网标准
接着进入了 TCP/IP 网络的时代。通过早期的因特网雏形，TCP/IP 协议族成为全球性互连网络的标准。大型企业发现：他们需要连接其分别发展的、专用的异构内部网络孤岛(其中许多来自于全球范围内不同的供应商)，但同时又不失去对整个企业内所有设备的控制。
此外，基础设施构建人员在其运作中将维护越来越多的联网黑箱。这经常要跨越位于不同地理区域的多个网络运营中心。因此需要从集中的位置来管理、控制和监控所有这些设备。来自这两大用户群体的迫切需求催生了早期企业 NMS 的概念。
在此期间，管理控制台(客户机)使用最新的图形工作站和
处理技术，并通常包括受管设备位置的交互式地图，以及网络网状拓扑的示意图。通过在地图上或 GUI
网络图的节点上点击，网络操作中心工作人员可以监控任何特定设备的状态并更改其设置和配置。作为异构网络管理的实际标准，SNMP(简单网络管理协议
― 一个完全为 TCP/IP 网络上的网络管理而设计的协议)变得更流行了。尽管由于实践和经济上的原因，最初 SNMP
受到了抵制，但专用联网硬件供应商最终还是采纳 SNMP 作为管理其联网设备的备选方法。
PC 和 LAN 革命：扩展企业管理
几乎与 TCP/IP 革命同时，装备了 PC 和 LAN 的办公室的数量呈爆炸性地增长。这需要一些企业的 NMS 承担新的范围：管理和控制 PC 工作站、打印机、外设以及其它 LAN 设备，如图 4 所示：
图 4. 向管理混合体中添加 PC 和 LAN 设备
许多供应商将其新取得的能力作为营销优势来推动其企业管理系统或简称 EMS(注意并未强调“网络”这个字眼)。在此期间，领先的供应商提供的商业
EMS 的规模和复杂性都提高了，但许多供应商的产品仍然维持着大量的专用代码库，并支持所有特定于供应商的旧系统。现有的基于 GUI
的管理控制台(客户机)软件，被反复地“移植”到新兴的桌面操作系统的许多不同版本上，这放宽了限制，但增加了底层代码库的复杂性。SNMP 协议被扩展到了其极限，以支持它设计时从未考虑的新的和不同的设备。由于受管的网络端点数量激增并超出了可管理级别，因而，几乎在每种商业 EMS 中，增值智能管理辅助都成为了标准。
因特网和电子交易革命：将可管理的软件服务添加到 EMS
随着受 EMS 管理的端点骤增，因特网革命给大多数 EMS 系统和架构设计师带来了冲击。突然之间，曾经完全迥异的大型网络都通过因特网连接了起来，而客户要求这个“网络的网络”可以使用他们了解和喜欢的同一种对用户友好的管理控制台进行管理(请参阅图 5)。
随着各种智能网络设备、PC 和外围设备的不断出现，在对这些端点的日常管理和监控中需要越来越多的智能。此外，对通过因特网进行业务的需求的不断增长，致使 EMS 需要支持一种新的端点：智能软件服务器/服务。
对于新型的 EMS 系统而言，能够访问企业在全球各地的每一台数据库服务器、Web 服务器、应用程序服务器和特大容量磁盘(disk farm)(新的、高智能、宽带宽、自适应特大容量磁盘现在称为 存储区域网络或 SAN)都有管理访问权，这并不希奇。
图 5. 新型 EMS
对受管网络中分布式智能的需求
在当今 EMS
时代，智能管理辅助不再是一个选项，而是必需的。对于处理组成和拓扑都经常变化的动态网络，该需求也是必须的。此外，适应和支持任何新的和未来设备的能力
是一项明确的要求。但是，这些新 EMS
还必须继续支持旧设备、协议和软件的混合物并能与之协调一致地工作，因为客户在艰难的发展过程中，曾经对它们作过巨大投资。实际上，客户对于支持现有的基
于 GUI 的 EMS 客户机有着强烈的需求，因为对这些复杂的工具进行过培训方面的投资。同时，EMS 的新用户还要求最新型的基于 Web
的管理界面以支持可能的远程管理和监控。
使用这些新 EMS 系统，您仍然可以启用和禁用旧的“哑”联网黑箱上的端口，但只要轻松地发出类似这样的命令：
必要时自动地切换到备份应用程序服务器群集和数据库服务器，以便在接下来的 24 小时中保持 95% 的正常运行时间;当发生灾难性故障时通过寻呼机 808-555-1212 向网络操作员报警。
换句话说，当在典型的 应用程序服务供应商(ASP)环境中出现网络故障时，您还可以依靠智能管理辅助来管理它们。
在因特网时代，软件体系结构和联网协议有哪些更改，以便这种复杂的网络管理能继续发挥功能呢?实际上，我们已经描述过的 EMS
案例很大程度上仍是“发展中的工作”。JMX 是朝向实现动态网络的通用管理的一个关键步骤，它具有完全的向后兼容性以及对现有的和旧 EMS
基础结构的支持。
将 Java 平台用于网络管理
Java 平台所具有的许多特性使之成为复杂网络管理解决方案实现的自然的候选者，这些特性包括平台和 OS 无关性、联网和动态适应性。
平台和 OS 无关性
因为 Java 语言的平台和 OS 无关性，NMS 开发人员不再需要为每种 OS 和硬件平台组合维护一个代码库版本。相反，现在可以将用来提高产品功能的精力和工作集中到单个代码库上。
联网
与大多数其它编程语言不同，联网是 Java 平台的核心部分。它不是事后添加的或第三方库，因此，可以确信和保证它与
OS/硬件平台的其它部分能良好协作。这很重要，因为较早的网络管理产品常常依靠第三方联网库来满足平台/OS
组合不能提供的需求，或实现作为目标的稳定性。
动态适应性
网络管理软件可以方便地利用跨网络动态且安全地装入类的能力。例如，基于 Java 的 EMS 可以仅仅跨网络“装入”它的支持模块来支持它们，并可按照需要动态地升级实现网络管理智能的软件模块。
JMX：网络管理规范
JMX 是业界广泛合作创建一套规范的成果，它将描述可扩展的体系结构、API 和一组使用 Java
编程语言用于网络管理的分布式服务。正如先前详细描述的，它利用了 Java 平台的网络管理能力。在撰写本文时，最新的规范是 Java
管理扩展工具和代理规范 v1.1(Java Management Extension Instrumentation and Agent
Specification，v1.1)。
可交付使用的 JMX 包括一组规范、API 文档、符合 JMX 规范的参考实现和兼容性测试套件。请参阅 参考资料以获取 JMX 1.1 规范和更多信息。
JMX 的目标只是定义构成 JMX
体系结构内系统的接口，而不在不必要时指定实现和策略。对于赢得在现有网络和服务管理技术方面有既得专利权益的供应商的支持，这一思想是必需的。它将使新
的基于 JMX 的应用程序在设计上享有最大的自由度和灵活性 ―
避免了规定的实现和策略可能不适合于未来需求的情形。这样，参考实现仅提供了一个关于如何满足指定的一组接口的示例，而没有建议或推荐实现这一点的方法。
JMX 的体系结构和操作模型
JMX 的体系结构和操作模型旨在满足下列目标：
可伸缩性：适应从管理少数设备或服务到管理因特网时代的企业可能拥有的数万个可管理端点的能力
旧系统集成和兼容性：与现有 NMS 或 EMS 解决方案以及与可能不支持 JMX 的旧的可管理端点协作的能力
低成本实现：无需大量设计和编码工作，即可轻松地将 JMX 兼容性设计到现有软件产品和设备中
在 JMX 体系结构中，采用三级分而治之的体系结构化方法来降低可伸缩网络管理的复杂性。 图 6 说明了这三个松散耦合的层。它们是：
工具层：在本层，可管理端点(设备、软件服务等)可通过 JMX 指定的接口访问。这是通过创建公开可配置属性、可访问操作和事件的 Java
对象实现的。这些对象称为 ManagedBean(简称 MBean)。在规范中将可通过这些对象管理的端点称为 JMX 可管理的资源。通过提供
Java MBean 封装器，可以轻松地将旧的非 JMX 设备和服务器(如 SNMP 兼容的设备或子网)“调整”成 JMX 可管理的资源。这一层上的 JMX 可管理资源可以完全独立于任何其它 JMX 体系结构层上的对象进行设计。
代理层：在本层中，公开了 JMX 代理的内部体系结构。 JMX 代理是软件组件，它向远程管理组件公开一组标准化代理服务并通过 JMX
可管理资源的 MBean 接口直接控制这些资源。实际上，在 JMX 代理内可通过能够动态地装入和卸装 MBean 的 MBean 服务器来管理 MBean。访问 MBean 服务器的接口由 JMX 指定。大型 EMS 系统中的增值服务(如本地化智能监控和自动化响应)，可在该层的 JMX 体系结构中实现。可以独立于其它层的对象设计这一层的代理。代理通过连接器或协议适配器与管理应用程序通信。但是，用于这些组件的规范仍处于开发过程中。
分布式服务层：在本层中，目标是指定为 JMX Manager 组件提供的接口。JMX Manager 可以访问代理或代理组来管理由代理公开的
JMX 可管理的资源。实质上，这些是 EMS 应用程序开发人员进行编程所依赖的接口。Manager 组件可以是 EMS
应用程序或管理多个代理和相关资源的中间智能层。
图 6. JMX 体系结构的三层
图 6 说明了三个层上的 JMX 对象，以及由 JMX 1.1 指定的接口。利用面向对象设计和 Java 编程语言，JMX
体系结构中的每层都是高度组件化的并由良好定义的接口进行划分的。按照这些良好规定的接口编写符合规定的代码，确保了我们的工具和代理逻辑可以与任何兼容
JMX 1.1 的实现一起使用。虽然 JMX 1.1 规范中规定了工具和代理层，但分布式服务层仍属于未来规范的范畴(在图 6
中显示为水平灰点线以及其上的点框)。现有网络管理标准(包括 SNMP 和 CIM/WBEM)的标准 JMX 接口正在由其它组同步进行制定。
标准 MBean vs. 动态 MBean
工具层的核心是 MBean 接口。MBean 接口指定了如何访问属性、如何调用操作(类似于 Java 编程语言中的方法)以及如何从 MBean 发送事件。MBean 有两种主要类型，表 1 中作了详细说明。
表 1. 标准与动态 MBean
| MBean 类型 | 描述 |
| 标准 MBean | 与标准 MBean 相关联的所有属性、操作和事件都在其接口中静态地指定。它们是固定的，不随时间变化而变化。标准 MBean 必须实现按固定编码约定（在 JMX 1.1 规范中称为 词法设计模式）编码的管理接口，MBean 规范中对此有详细描述。例如，要用标准 MBean 使用名为 WebServer 的类，则其管理接口必须称为 WebServerMBean 。JMX 代理通常使用“自省（introspection）”来发现标准 MBean 的管理接口。 |
| 动态 MBean | 所有动态 MBean 都实现 javax.management.DynamicMBean 接口。通过使用 DynamicMBean接口，与 MBean 相关联的一组属性、操作和事件直到运行时才是确定的。这满足了拥有可能随时间改变而改变的属性、操作和事件的可管理 JMX 资源的需要（例如，工具应用程序服务器可能以不同的发行版级别 ― Tomcat 4.1.4 和 Tomcat 4.1.5 ― 支持不同属性）。它也自然地适合于由联合的网络技术工具，如 Jini/Jiro。 |
动态 MBean 专门化：模型和开放 MBean
有两种用于特殊用途的动态 MBeans 子类型，如表 2 所示：
表 2. 模型和开放 MBean
| MBean 类型 | 描述 |
| 模型 MBean（Model MBean） | 所有 JMX 实现都必须提供一个模型 MBean 的实例 ― 实现 javax.management.modelmbean.ModelMBean 接口。它必须命名为 javax.management.modelmbean.RequiredModelMBean。模型 MBean 提供了“现成的”MBean 实现，您可以立即使用它来快速地利用任何 JMX 可管理资源。它是预制的、通用的和动态的 MBean 类，作为参考实现的一部分提供，已经包含了所有必要缺省行为的实现 ― 允许您在运行时添加或覆盖需要定制的那些实现。这使得基于 Java 的、非工具化的资源能够在运行时提供保证兼容的 MBean 虚包，使它们能够通过 JMX 体系结构进行管理。 |
| 开放 MBean（Open MBean） | 开放 MBean 是一种动态 MBean，其中所有的 MBean 属性都属于一组指定的 Java 数据类型（ String 、 Integer 、 Float 等），并且 bean 通过一组 javax.management.openmbean.* 接口提供自我描述的数据。任何代理和任何管理器／EMS 都可以轻松地管理由这些 bean 提供的 JMX 可管理资源。JMX 1.1 中没有完整地详细说明开放 MBean 的细节，并且参考实现也没有包括它们。 |
图 7 说明了如何使用 MBean 来将工具添加到设备和软件服务。请注意，相应的 MBean 是设备或服务的 JMX 内部表示。任何已向
JMX 代理中的 MBean 服务器(稍后讨论)注册的 MBean 都可以将其管理接口(属性、操作和事件)向远程 NMS 或其它 JMX
应用程序公开。但是，当我们添加 MBean 以利用设备或软件服务时，我们不必考虑将哪种 JMX 代理或 NMS 用于管理工作。
图 7. JMX 的操作模型
持久 MBean
一些 MBean 可能需要持久性支持以确保正确的操作。这些 MBean 应该总是实现
javax.management.PersistentMBean 接口。这个接口仅有 save() 和 load() 方法。持久 MBean
实现负责在 bean 构造期间调用 load() 方法，以根据被持久化的值初始化 MBean 的状态。JMX 代理内幕
图 7 揭示了典型 JMX 代理的内部构造。请注意，代理内部的四种主要组件是 MBean 服务器、一组代理服务、连接器和协议适配器以及定制代理逻辑。
MBean 服务器
MBean 服务器是代理内部的核心组件。所有 MBean 在可以通过远程应用程序访问之前都必须向 MBean 服务器注册。当使用 MBean
服务器时，通过唯一的对象名对已注册的 MBean 进行寻址。远程管理器应用程序(或分布式服务)只能通过 MBean
的管理接口(已公开的属性、操作和事件)发现和访问 MBean。
代理服务
代理还提供了一组代理服
务，定制代理逻辑可以使用它们在 MBean 服务器中对已注册的 MBean 进行操作。为了符合 JMX 1.1，这些服务是必需的
―所有代理都必须提供它们。有趣的是，可以用 MBean 本身的形式实现这些服务。以 MBean 的形式实现服务有几个优点：
可以通过 Manager 组件或 EMS 远程访问该服务的操作。
通过从远程管理器应用程序进行访问，EMS 可以远程地管理服务本身。
可以通过下载 MBean 在运行时动态地执行服务逻辑的更新。
表 3 显示了 JMX 1.1 规范中定义的一组代理服务。
表 3. JMX 1.1 所需的代理服务
| m-let 或管理 Applet 服务 | 支持跨网络从 URL 位置装入动态类（请参阅 javax.management.loading.MLetMBean 和相关联的类／接口）。 |
| 监视器服务 | 将代价高昂的远程轮询操作转换成本地操作；监控 MBean 属性的特定更改并在观察到更改时发送事件。 |
| 计时器服务 | 经历了指定的时间量后发送事件，或以指定时间间隔定期发送事件（请参阅 javax.management.monitor.MonitorMBean 和相关的类／接口）。 |
| 关系服务 | 支持 MBean 之间的关系定义，并强制关系的完整性（请参阅 javax.management.relation.RelationServiceMBean 和相关的类／接口）。 |
增值代理逻辑
增值代理逻辑通常是编写的代码。它是能够提供本地化智能的定制代理逻辑，用来管理向该代理注册的 JMX
可管理资源。例如，如果我们有两个冗余的应用程序服务器群集，就可以创建定制代理，监控负载级别并且动态地将入站请求重定向到不同的群集 ―
通过对已注册的服务器的 MBean 进行操作。通常，NMS
的供应商也会提供定制逻辑。一旦分布式服务的规范得以充实，可以预言，某种特定的定制代理逻辑将可以与定制远程 JMX
管理器组件良好地协作，以提供更高级别的网络管理功能。
连接器和协议适配器
代理不与分布式服务、NMS 或其它管理应用程序直接通信。而是使用连接器和协议适配器。这种体系结构与 J2EE 连接器体系结构(J2EE Connector Architecture)是一致的(请参阅 参考资料)。协议适配器是一种软件组件，它通过标准化协议(如 HTTP 和 SNMP)提供对代理管理的资源的访问。
连接器是一种专用软件组件，它提供了到代理和/或该代理上的受管资源的远程接口(通常使用诸如 CORBA 或 RMI 这样的远程过程调用技术来完成 ― 为了安全性
通常通过 SSL)。当代理有多个活动的连接器和协议时，可以通过多个异构的应用程序或 NMS
同步地访问受管资源。可以用协议适配器来提供对现有的和已建立的 NMS 的向后兼容性。例如，我们可以为支持这个标准的 NMS 创建
通用信息模型/基于 Web 的企业管理(CIM/WEBM)适配器，或者可以创建 电信管理网络(TMN)协议适配器来启用由 JMX
代理管理的电信资源上的 操作、管理和维护(OAM)。JMX 连接器和协议适配器的精确规范属于正在同时开发的规范的范畴。
JMX 1.1 不断增加的应用程序支持
构仅完整定义了工具和代理层，但它已经在基于 Java 的企业技术开发人员中赢得了广泛的支持。
J2EE 1.4 和 JMX
2002 年 8 月 18 日提议的 J2EE v1.4 最终草案版本详细描述了基于 JMX 的工具将如何成为 J2EE Web
容器(JSP/Servlet 引擎)、EJB 容器和应用程序客户机容器的标准部分。这是很自然的发展，因为基于 J2EE
服务器的广泛部署正使得可管理性成为明确的需求。(正如您可以想象的，在部署了数百台服务器的大型站点中，手工或专门配置、管理和监控几乎是不可能的。)
迄今为止，商业服务器产品已经通过专用方式或特殊添加物(使产品与现有 NMS 产品兼容)来支持可管理性。J2EE v1.4 规范中作为管理基础的 JMX 标准化，对于确保来自不同供应商的服务器产品普遍地与 NMS 兼容(并可由 NMS 管理)大有帮助。
实现的案例研究：Apache Jakarta Tomcat 4.1.x
Tomcat 4.1.x 服务器的最新 beta 测试版与 J2EE v1.4 规范保持一致，它已经集成了 JMX 工具。。大多数
Tomcat 工具集中于配置组件，这些组件对应于 Tomcat 的 Catalina 引擎中的运行时对象。原本只能通过 conf 目录中的
server.xml 和 web.xml 文件更改的配置组件(如 <Engine>、<Host>、<Server>、<Service>、<Connector>、<Context>
和 <Realm>），现在都可以通过 JMX MBean 实现使用。
如果您研究一下 org.apache.catalina.mbeans 包(在源代码分发版或 API Javadoc 中)，就会发现所有公开 Tomcat 配置组件的 JMX 工具 MBean 类。一些示例包括利用<Context> 配
置组件的 org.apache.catalina.mbeans.StandardContextMBean ，而
org.apache.catalina.mbeans.MemoryUserDatabaseMBean
利用<MemoryUserdatabase>组件。如果您研究实际的源代码，您将发现 Tomcat 4 工具广泛利用了 JMX 实现提供的模型 MBean 模板。
目前，Tomcat 4.1.x 使用 MX4J JMX 实现(一个开放源码许可的 JMX 实现)，而不是 Sun 的参考 JMX 实现。但是，两个实现都是完全兼容 JMX 1.1 的。
广泛的 Tomcat 工具的一个立杆见影的好处就是可以很容易地创建一个基于 Web 的 GUI 管理应用程序。Tomcat 4.1.x
提供了一个称为 admin 的应用程序。应用程序本身是用 Struts 应用程序框架和 JSP 技术创建的。它通过本地 JMX 代理的
MBean 服务器访问所有的配置组件(与 server.xml 文件中定义的那些相同)。在 Tomcat 环境中，JMX 代理是由
org.apache.catalina.mbeans.ServerLifeCycleListener 类创建的。该类是一个在 Tomcat
启动和关闭时会调用的 LifeCycleListener 。
要尝试这个基于 JMX 的 admin 实用程序，首先您必须编辑 Tomcat 分发版的 conf 目录下的 tomcat-users.xml 文件。确保您为 tomcat 用户添加了 admin 角色：
2
组件将使用该文件在运行时验证访问，要运行这个实用程序，用户必须具有 admin 角色。接下来，启动 Tomcat 4.1.x。
打开浏览器并输入 URL：
2
在登录页面，输入：
2 Password: tomcat
3
现在，请研究 admin 实用程序并观察 JMX MBean 是如何支持实时显示和修改 Catalina 配置组件值的。例如，图 8 显示了 配置组件的属性的配置页面：
图 8. 基于 JMX 1.1 的 Tomcat 4 GUI admin 实用程序
当然，除了基于 Web 的 admin 应用程序之外，Tomcat 的工具支持由其它代理和 EMS 来管理它。
结束语
通过利用 Java 平台和谨慎的设计，JMX 达到了其设计目标：可伸缩性、低实现成本和与现有技术的兼容性。在下一篇文章中，我们将使用参考
JMX 1.1 代码，实现我们自己的标准 MBean 和动态 MBean，利用所需的模型 MBean 作为快速工具，并用 JMX 代理进行实验。