将 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 的状态。
