【翻译JMX1.4】Introduction-to-the-JMX-Specification(持续修改)

1.介绍JMX规范

Java管理扩展（也称为JMX规范）在Java编程语言中定义了一个体系结构，设计模式，API，应用程序的服务，网络管理和监控。本章介绍了所有这些元素，展示了这些扩展的作用范围。 JMX规范为所有行业的Java开发人员提供了测试Java代码的方式，创建智能Java代理，实现分布式管理中间件和管理人员，并将这些解决方案顺利整合到其中现有的管理和监测系统。 另外，JMX规范是现有标准管理和许多Java API引用监测技术。
应该指出的是，在本文其余部分，管理概念是指管理和监测服务。

JMX体系结构分为三个级别：

• Instrumentation level
• Agent level
• Distributed services level

本章介绍每个级别，并介绍其基本内容组件。

1.1 JMX体系结构的优点

通过实现JMX规范，JMX体系结构提供了有以下好处：

• 无需大量投入即可管理Java应用程序
  JMX体系结构依赖于一个核心的管理对象服务器充当management agent，并且可以在大多数支持Java的设备上运行。 这允许Java应用程序可以管理，而对其设计几乎没有影响。 一个Java应用程序只需要嵌入一个托管对象服务器并实现一些功能可用作在对象服务器中注册的一个或多个受管Bean（MBean）;只需从管理基础结构中获益即可。JMX为任何基于Java的Java提供了一种标准方式来实现可管理性应用程序，服务或设备。 例如，Enterprise JavaBeans™（EJB）应用程序可以符合JMX体系结构以变得易于管理。
• 提供可扩展的管理架构
  每个JMX代理服务都是一个可以插入到management agent的独立模块，视需求而定。 这种基于组件的这意味着JMX解决方案可以从小型设备扩展到大型设备电信交换机等。JMX规范提供了一组核心代理服务。 额外的服务将会通过一致的实现来开发，以及由集成商开发管理方案。 所有这些服务都可以动态加载，卸载或在管理基础结构中更新。
• 整合现有的管理解决方案
  JMX智能代理能够通过HTML浏览器或通过HTML进行管理各种管理协议，如SNMP和WBEM。 JMX API已打开任何管理系统供应商都可以利用的接口。
• 利用现有的标准Java技术
  无论何时需要，JMX规范都会引用现有的Java规范如Java命名和目录接口（JNDI），Java数据库连接API（JDBC™），Java Transaction Services（JTS）或其他。
• 可以利用未来的管理概念
  JMX规范的API可以实现灵活和动态的管理解决方案，通过Java编程语言，可以利用新兴的技术。 例如，JMX解决方案可以使用查找和发现服务协议，如Jini™网络技术，通用即插即用（Upnp）和服务位置协议（SLP）。
  在Sun Microsystems提供的演示中，Jini网络技术提供然后在网络上自发地发现资源和服务通过JMX应用程序进行管理。 这两种功能的组合是称为Sun自发管理软件。
• 仅定义管理所需的接口
  JMX API的设计不是一个通用的分布式对象系统。虽然它提供了许多旨在适合分布式应用的服务环境，这些都侧重于提供管理网络的功能，系统和应用程序。

1.2 本规范的范围

JMX规范定义了用于管理的体系结构和一组API描述这个架构的组件。 这些API涵盖了管理和代理方的两种功能，这些兼容的实现将提供给管理应用程序的开发人员。

这个JMX规范文档解决了所有三个级别架构管理。 这些部分是：

• The instrumentation specification
• The agent specification
• The distributed services specification

1.2.1 参考实现

reference implementation（RI）是JMX的第一个工作应用程序规范，正如Java社区过程规定的扩展名Java编程语言。包含instrumentation和agent规范的RI由Sun Microsystems，Inc.开发，作为JMX规格领先。
从JMX API的1.3版本开始，没有可单独使用的RI规范。RI是Java平台Standard版本6的RI的一部分版（Java SE），代号为“Mustang”。

1.2.2 兼容性测试套件(Compatibility Test Suite)

JMX规范的compatibility test suite（CTS）将检查JMX实现的一致性。它也由Java社区进程授权。该CTS验证声称符合JMX特定部分的应用程序如下规范的每一点。instrumentation和agent规范的CTS规格由Sun Microsystems，Inc.开发，作为JMX规格领先。
因为JMX规范定义的类是可选包Java平台中，CTS被实现为技术兼容性套件（TCK）由JavaTest™软件运行。
JMX规范的每个部分都可以标识强制和可选组件。符合JMX的实现必须提供所有必需的服务，并且可以提供可选服务的任何子集，但它提供的服务必须符合到规范。
在声明JMX合规性时，实现列出了它们的可选服务支持，并由CTS对其一致性声明进行测试。 这个需要一些模块化的CTS可以对付各种运行的方式实现规范的许多子集的实现。

1.2.3 JMX API作为Java平台的一部分

从Java 2 Platform Standard Edition（J2SETM平台）5.0版开始，代为“Tiger”，JMX API和JMX Remote API是核心平台的一部分。“Tiger”包含版本1.2的JMX API和版本1.0的JMX Remote API。本文档涵盖的这些API的版本（每个API的版本1.4）都是包括在Java平台标准版（也称为Java SE）的第6版中，代号为“Mustang”，继承“Tiger”.
可以替换JMX和JMX中的任何一个或两个的实现“Tiger”中的远程API以及本文档涵盖的API的实现。这样的替换必须通过CTS替换每个API。
MXBean的规范定义了注释时的某些行为出现java.beans.ConstructorProperties。 由于这个注释没有存在于“Tiger”平台中，有问题的行为不会发生在那里。

1.3体系结构概述

本节描述JMX规范的每个部分和在整体管理架构中的关系：

• Instrumentation level
• Agent level
• Distributed services level
• Additional management protocol APIs

图1-1显示了JMX体系结构的关键组件如何与其相关另一个在建筑模型的三个层次内。 这些组件是在以下小节中介绍并在“组件”中进一步讨论概述“（第28页）。

1.3.1仪表等级(Instrumentation Level)

The instrumentation level提供了一个实现JMX可管理的规范资源。 一个JMX可管理资源可以是一个应用程序，一个实现服务，设备，用户等等。 它是用Java开发的，或者至少提供Java wrapper，并已安装，以便可以通过遵从JMX进行管理应用。
给定资源的检测由一个或多个受管Beans提供，或标准或动态的MBeans。 Standard MBean是Java对象符合从JavaBeans™组件派生的特定设计模式模型。 Dynamic MBeans符合特定的接口，可以提供更多的灵活性运行。 有关更多信息，请参阅第28页上的“Managed Beans (MBeans)”。
资源的检测使其可以通过代理级别进行管理在下一节中介绍。 MBean不需要JMX代理的知识与他们运作。
MBean的设计灵活，简单，易于实现。 开发人员应用程序，服务或设备可以使其产品在标准中可管理无需理解或投资于复杂的管理系统。现有对象可以轻松演变为生成标准MBean或打包为动态MBean，从而以最小的努力使现有资源易于管理。
另外，the instrumentation level还指定了通知机制。 这个允许MBeans生成并传播通知事件给组件其他水平。
由于the instrumentation level包含设计模式和Java接口，因此参考实现只能提供不同MBean和的示例的通知机制。
但是，the instrumentation level的the compatibility test suite将检查该问题正在测试的MBean符合设计模式并实现接口正确。
JMX可管理资源可以被完成JMX规范的agents自动管理。 它们也可以由任何不合规的系统管理使用支持MBean设计模式和接口的JMX规范。

1.3.2代理级别(Agent Level)

The agent level提供执行代理的规范。管理代理直接控制资源并使其可用于远程管理应用。代理通常位于与机器相同的机器上他们控制的资源，尽管这不是要求。
这个级别建立在并利用仪器级别来定义一个标准化代理来管理JMX可管理资源。 JMX代理由一个MBean server和一组处理MBean的服务。 另外还有一个JMX代理将需要至少一个通信adaptor或connector。MBean server实施和代理服务是强制执行的规范。
当一台Java虚拟机（JVM）在该机器上可用时，JMX代理可以嵌入到托管JMX的机器中管理资源。同样，JMX代理可以实例化为调解/集中器元素托管资源仅提供专有（非Java）环境。 否则，aMX代理不需要知道它将提供哪些资源：任何JMX可管理资源可以使用任何提供其所需服务的JMX代理。
Managers访问代理的MBeans，并使用提供的服务协议适配器或连接器，如下一节所述。 但是，JMX代理不需要知道使用它们的远程管理应用程序。
JMX代理由可以构建的管理系统的开发人员实施他们的产品以标准的方式无需理解其语义JMX可管理资源或管理应用程序的功能。
代理兼容性测试套件将检查正在测试的代理是否符合接口和代理规范中阐述的功能。 有代理商已成功通过代理CTS测试，可以作为JMX代理商。
JMX代理运行在Java 2 Platform Standard Edition（J2SETM平台）上，1.3版或更高版本，以及Java 2 Platform Micro Edition的某些配置文件（J2METM平台）。 JMX代理实现了JMX的1.3版本规范必须在J2SE平台的5.0或更高版本上运行。
JMX代理将自动与JMX分布式服务兼容，并且可以也可用于任何不支持JMX的系统或支持JMX的应用程序代理商。

1.3.3分布式服务级别(Distributed Services Level)

分布式服务级别提供了实现JMX管理的接口。 这个级别定义了管理界面和组件在代理的代理或层次结构上运行。 这些组件可以：

• 为管理应用程序提供一个接口，以透明地与之交互代理及其通过连接器的JMX可管理资源
• 通过映射JMX代理及其MBean来公开JMX代理及其MBean的管理视图语义意义转化为数据丰富协议的结构（例如超文本标记语言（HTML）或简单的网络管理协议（SNMP））
• 将管理信息从高级管理平台分发到众多的JMX代理
• 将来自众多JMX代理的管理信息合并到与最终用户的业务操作相关的逻辑视图
• 提供安全性

Management components通过网络彼此合作提供分布式，可扩展的管理功能。 定制的基于Java的管理可以在这些组件之上开发功能来部署管理应用。
manager level与其他agent和instrumentation的组合级别提供了完整的设计和开发的完整架构管理方案。 Java管理扩展技术带来了独特性这些解决方案的设施，如便携性，按需部署管理功能，动态和移动服务以及安全性。

1.4组件概述

下面列出了每个架构级别的关键组件，并在其中进行了讨论后续部分。

• Instrumentation level
  
  • MBeans (standard, dynamic, open, and model MBeans)
  • Notification model
  • MBean metadata classes
• Agent level
  
  • MBean server
  • Agent services

1.4.1仪器级别的组成部分(Components of the Instrumentation Level)

instrumentation级别的关键组件是Managed Bean（MBean）设计模式，通知模型和MBean元数据类。

1.4.1.1管理 Beans（MBeans）

MBean是实现特定接口并符合某些设计模式的Java对象。 这些要求正式规定了MBean中资源的management interface的形式。 资源的management interface是管理层所需的一切必要信息和控制的集合应用程序需要对资源进行操作。
MBean的管理接口表示为：

• 可以访问的有价值的属性
• 可以调用操作
• 可发出的通知（请参阅第29页的“通知模式”）
• MBean的Java类的构造函数

MBean通过其公共方法和封装属性和操作遵循设计模式，将它们暴露给管理应用程序。 对于例如，标准MBean中的只读属性只有一个getter方法，而getter和setter方法实现读写访问。

任何实现为MBean并向代理注册的对象都可以从代理的Java虚拟机外部进行管理。 这些对象包括：

• 您的应用程序管理的资源
• 提供的增值服务可帮助管理资源
• 可以管理的JMX基础架构的组件

其他JMX组件（如代理服务）被指定为完全检测MBeans，它们可以从JMX基础结构中受益并提供一个管理界面。
JMX体系结构不对编译的MBean的位置施加任何限制类存储。 它们可以存储在类路径中指定的任何位置代理的JVM，或者在远程站点使用类加载（请参见第8章“高级”动态加载“（第143页））。
JMX规范定义了四种类型的MBean：standard, dynamic, open and model MBeans。 这些中的每一个对应于不同的仪器需求：

• Standard MBeans是最简单的设计和实现，它们的管理 接口由其方法名称描述MXBeans是一种标准 使用Open MBeans中的概念来实现通用可管理性的MBean 同时简化编码。
• Dynamic MBean 必须实现特定的接口，但是它们会暴露他们的管理界面在运行时具有最大的灵活性
• Open MBeans 是依赖基本数据类型实现通用的动态MBean 可管理性和自我描述为用户友好。
• Model MBean 也是动态MBean，它们可以完全自行配置 在运行时描述; 它们提供具有默认行为的通用MBean类 用于资源的动态检测。

1.4.1.2通知模式(Notification Model)

JMX规范定义了一个基于Java事件的通用notification模型。 notification可以由MBean实例以及MBean服务器。 本规范描述了notification对象以及broadcaster和listener接口，notification发送者和接收者必须实现。
此规范包括允许分发此通知模型的服务，从而允许管理应用程序侦听MBean事件和MBean服务器事件远程。

1.4.1.3 MBean元数据类(MBean Metadata Classes)

instrumentation规范定义了用于描述的类MBean的管理界面。 这些类用于构建标准用于发布MBean管理接口的信息结构。 代理级MBean服务器的其中一个功能是提供其元数据的MBean。
元数据类包含描述MBean管理界面的所有组件的结构：它的属性，操作，通知和构造函数。 对于其中的每个元数据，元数据都包含名称，说明及其内容特定的特征。 例如，属性的一个特征就是它是否可读，可写或两者; 操作的特点是其签名参数和返回类型。
不同类型的MBean扩展元数据类以提供额外的功能信息。 通过这种继承，标准信息将永远是知道如何访问子类的可用和管理应用程序可以获取额外的信息。

1.4.2代理级别的组件(Components of the Agent Level)

agent级别的关键组件是MBean server，它是对象的注册表工具级别以及启用JMX代理的代理服务将管理智能纳入更多的自主权和表现。

1.4.2.1 MBean服务器(MBean Server)

受管理的bean服务器（简称MBean服务器）是一个对象的注册表暴露于代理人的管理操作中。 任何注册的对象管理应用程序可以看到MBean服务器。 但是，MBean服务器只公开MBean的管理界面，而不是它的直接对象参考。
您希望从代理的Java虚拟机外部管理的任何资源（JVM）必须在服务器中注册为MBean。 MBean服务器也提供一个用于访问同一个JVM中的MBean的标准化接口，提供本地的反对操纵可管理资源的所有好处。 MBeans可以实例化和注册：

• Another MBean
• The agent itself
• A remote management application(through the distributed services)

注册MBean时，必须为其分配一个唯一的对象名称。 一个管理应用程序使用对象名称来标识它所在的对象执行管理操作。 MBean上可用的操作包括：

• Discovering the management interface of MBeans
• Reading and writing their attribute values
• Performing operations defined by the MBeans
• Getting notifications emitted by MBeans
• Querying MBeans based on their object name or their attribute values

MBean服务器依赖于protocol adaptors和connectors来创建代理可以从代理的JVM之外的管理应用程序访问。 每个适配器通过在MBean中注册的所有MBean的特定协议提供一个视图服务器。 例如，一个HTML适配器可以在Web浏览器上显示一个MBean。协议适配器提供的视图对于每个协议必然不同并且在JMX规范的这个阶段没有提到。
连接器提供处理通信的管理器端接口 在manager和agent之间。 每个连接器将提供相同的远程接口尽管是不同的协议。 当远程管理应用程序使用它时接口，它可以通过网络透明地连接到代理，无论如何协议。
适配器和连接器使所有MBean服务器操作都可用于远程管理应用。 对于要管理的代理，它必须至少包含一个代理协议适配器或连接器。 但是，代理人可以包括任何数量的这些代理人，允许它由多个管理人员通过不同的协议进行管理。

1.4.2.2代理服务(Agent Services)

代理服务是可以对MBean执行管理操作的对象在MBean服务器中注册。 通过将管理智能纳入代理，JMX可帮助您构建更强大的管理解决方案。 代理服务通常也是MBean，允许他们和他们的功能被控制通过MBean服务器。 JMX规范定义了以下代理服务：

• Dynamic class loading 通过管理applet（m-let）服务检索并从任意网络实例化新的类和本地库位置。
• Monitors 观察几个MBean的属性的数字或字符串值 并且可以通知目标中的多种类型变化的其他对象。
• Timers 提供基于一次性闹钟的调度机制通知或重复的定期通知。
• The relation service 定义MBeans之间的关联并强制执行 基于预定义关系类型的关系的基数。

所有代理服务在符合JMX的实现中都是强制性的。

1.5 JMX远程API

JMX Remote API是由JSR 160定义的。为了便于表示，这个文件将JSR 160的维护评审2规范与JSR 3的维护评审4的规范。正式的，这是第I部分和第II部分文档由JSR 3定义，而第III部分和附录由JSR定义160.为了简单起见，两个规格使用相同的版本号1.3。正在进行的JSR 255正在定义JMX规范的2.0版本，将JMX Remote API集成到JMX API中。 因此，它将合并规范最初由JSR 3和160定义。
JMX Remote API的主要目标是互操作性，透明性，安全性，和灵活性。
API是可互操作的，因为它完全定义了标准协议在客户端和服务器之间使用，以便两种不同的实现标准可以沟通。
该API是透明的，因为它将API暴露给距离最近的远程客户端尽可能使JMX规范定义的API访问仪器在代理内。
该API是安全的，因为它基于Java技术标准进行安全性建设，即Java安全套接字扩展（JSSE），简单身份验证和安全层（SASL）和Java认证和授权服务（JAAS）。这些标准使客户端和服务器之间的连接成为可能私有和验证，并允许服务器控制不同的操作客户可以执行。
API是灵活的，因为除了所需的协议外，它还提供了一些方法新的传输协议被添加和现有的新实现协议被替代。

1.6什么改变了

本文档合并并更新了两个先前的规范，即JMX Instrumentation and Agent Specification，v1.2，2002年12月，以及JMX Remote API规范，v1.0，2003年10月。本节列出了这两个主要更改规格。
对任一规格的所有更改都使用更改条标记在文本中。

1.6.1对JMX规范（JSR 3）的更改

• JMX API已被基因化。 例如，MBeanServer.queryNames 先前返回了一个Set，而现在它返回一个Set。
• J2SE 5.0中为java.lang.management引入的MXBeans功能包已经被推广，以便用户可以创建自己的MXBeans。
• 以前仅支持Model MBean的描述符现在支持 所有类型的MBean。
  
  • 有关以前仅在“打开”时可用的合法类型的信息 现在可以使用任何类型的MBean通过描述符来表示MBean。
  • 名为DescriptorRead的DescriptorAccess的父级已添加并 由各种MBean * Info类实现。
  • 调用Descriptor接口的第二个不可变实现 ImmutableDescriptor已被添加。
  • 许多新的常规描述符项目（“字段”）记录在其中 Descriptor接口的API规范。
  • 预定义的描述符字段名称中有相应的字符串常量称为JMX的新类。
  • 可以使用新的注释DescriptorKey向信息添加信息通过Java中的注释为标准MBean（或MXBean）描述符 接口。
  • 方法Descriptor.getFieldValues（String …）和构造函数DescriptorSupport（String …）以前采用了String [] 参数。
  • 描述符接口定义一个equals方法并指定数组的方式 值进行比较。
  • 返回数组的排序顺序已澄清 Descriptor.getFieldValues（空）。
  • 用于Descriptor.setField和的异常封装指定了Descriptor.setFields。
• 新的类javax.management.JMX已添加到常量和常量中 静态方法。
• 通知处理已更新，如下所示：
  
  • 新的构造函数已添加到NotificationBroadcasterSupport 指定将返回的MBeanNotificationInfo [] getNotificationInfo（）。
  • NotificationBroadcasterSupport的线程模型已被使用显式指定并添加一个Executor参数的构造函数 允许改变它。
  • 中的过滤器或侦听器的行为NotificationBroadcasterSupport指定了一个异常。
  • 一个新的类，javax.management.StandardEmitterMBean，是的一个子类javax.management.StandardMBean是一个NotificationEmitter。
• ObjectName已被修改，如下所示：
  
  • 通配符*和？ 可以出现在用于匹配的关键属性的值中。 新方法isPropertyValuePattern（）和isPropertyValuePattern（String属性）告诉给定的是否ObjectName有这样一个通配符。
  • 为MBean服务器的名称添加新的ObjectName常量委托和匹配所有ObjectName的通配符。
  • ObjectName实现了Comparable 。
• 禁止将getter和setter调用为操作的文本 在本规范的前一版本中令人困惑。
• 标准MBean支持MBean接口中的协变返回类型。
• 动态MBean的MBeanServer.isInstanceOf语义已被使用 澄清。
• 对模型MBean规范应用了各种小的更改，如 如下：
  
  • Model MBean描述符中的值和displayName字段是可选的但此规范的以前版本并未以斜体显示它们。
  • RequiredModelMBean.setAttribute应该会引发异常没有setMethod并且没有currencyTimeLimit，因为setAttribute调用在这种情况下不起作用。
  • ModelMBeanOperationInfo描述符中的角色字段是可选的。
  • targetType描述符字段的值不区分大小写，但是从大小写不敏感的字段的显式列表中省略。
  • targetType描述符字段不包含在a的序列形式中描述符支持实例。
  • ModelMBeanInfoSupport.clone明确浅显（不克隆包含ModelMBeanAttributeInfoSupport等）。
  • 描述符的persistPolicy字段的新的OnUnregister值。
  • DescriptorSupport（String []，Object []）禁止空参数 - this以前是不明确的。
• Open MBean已更新如下：
  
  • Open MBeans可以引用基本类型的数组。 一个ArrayType对象可以构建代表这样的数组。
  • 在构造函数ArrayType（int dimension，OpenType <？>elementType），elementType参数现在可以是一个ArrayType实例。
  • CompositeDataSupport.equals逐个比较数组。
  • TabularDataSupport.entrySet（）指定返回的Set is中的键包装成一个列表。
  • MBeanOperationInfo的影响可能是UNKNOWN。
• 当监视的属性看起来时，监视服务支持复杂的类型 如“a.b.c”。
• 监视任务被指定为在调用者的访问控制上下文中运行Monitor.start（）。
• 定时服务过去日期的规格不一致 解决。 MLetContent类已公开.
• RelationNotification构造函数现在允许源为a RelationService实例或ObjectName
• RelationService.addRelationType拒绝空关系名称。
• RelationSupport规范已澄清从setRole和…中抛出RoleNotFoundException从setRoles抛出IllegalArgumentException。 ■添加了新查询Query.isInstanceOf。
• 使用MBeanServerInvocationHandler构建的代理不再转发方法hashCode（），toString（）和equals（Object）到代理 MBean，除非它们在代理接口中显式声明。
• API文档现在明确指定了所有的serialVersionUID 可序列化的类以及使用标准非公开序列化查询的调用 类。

1.6.2对JMX远程规范（JSR 160）的更改

• JMXConnector接口扩展了java.io.Closeable。
• 澄清了JMX连接提供程序异常处理。
• RMIConnector类的序列化形式包括虚假clientNotifID字段。
• 添加JMXAddressable接口以获取连接器客户端的地址 已连接。