Question

jmx的入门准备工作？？

开发任何的java相关的东东之前 都要配置诸如路径，在eclipse里设置这啊那啊 之类的
谁能给我一个详细一点的如何完成开发jmx的准备工作的指南啊 就是告诉我要下载些什么？解压到哪？配置些什么？ 完成你所说的准备工作后就可以看书学习开发了 我就给分
jmx in action是不是已经过时了啊 里面关于RmiConnectorServer的内容为什么在eclipse里是报错的？这个问题应该怎么解决？
有别的书么？

Answer 1

JMX学习总结 1.产生背景
要了解 JMX，我们就必须对当前的 IT 管理系统有一个初步的了解。随着企业 IT 规模的不断增长，IT 资源（IT resource）数量不断增加，IT 资源的分布也越来越分散。可以想象，甚至对于一家只有几百台 PC 公司的 IT 管理人员来说，分发一个安全补丁并且保证其在每台 PC 上的安装，如果只依赖人工来完成那简直就是一场噩梦。这样，IT 管理系统就应运而生。
然而，CPU、网卡、存储阵列是 IT 资源；OS、MS Office、Oracle database、IBM Websphere 也是 IT 资源。IT 管理系统若要对这些 IT 资源进行管理，就必须对这些管理对象有所了解：形形色色的 IT 资源就像是说着不同语言的人：Oralce 数据库表达内存紧张的方式和 Window XP 是绝然不同的， 而 IT 管理系统就像建造通天塔的经理，必须精通所有的语言， 这几乎是一个不可能完成的任务。

2.JMX（Java Management Extensions，即Java管理扩展）是一个为应用程序、设备、系统等植入管理功能的框架。JMX可以跨越一系列异构操作系统平台、系统体系结构和网络传输协议，灵活的开发无缝集成的系统、网络和服务管理应用。

3.

4.框架结构

图 1. 管理系统构架

上图分析了管理系统的基本构架模式。其中 Agent / SubAgent 起到的就是翻译的作用：把 IT 资源报告的消息以管理系统能理解的方式传送出去。

为什么需要 Agent 和 SubAgent 两层体系呢？这里有两个现实的原因：

管理系统一般是一个中央控制的控制软件，而 SubAgent 直接监控一些资源，往往和这些资源分布在同一物理位置。当这些 SubAgent 把状态信息传输到管理系统或者传达管理系统的控制指令的时候，需要提供一些网络传输的功能。
管理系统的消息是有一定规范的，消息的翻译本身是件复杂而枯燥的事情。
一般来说，管理系统会将同一物理分布或者功能类似的 SubAgent 分组成一组，由一个共用的 Agent 加以管理。在这个 Agent 里封装了 1 和 2 的功能。
JMX 和管理系统
JMX 既是 Java 管理系统的一个标准，一个规范，也是一个接口，一个框架。图 2 展示了 JMX 的基本架构。
图 2. JMX 构架

JMX 是管理系统和资源之间的一个接口，它定义了管理系统和资源之间交互的标准。
javax.management.MBeanServer 实现了 Agent 的功能，以标准的方式给出了管理系统访问 JMX 框架的接口。
javax.management.MBeans 实现了 SubAgent 的功能，以标准的方式给出了 JMX 框架访问资源的接口。
从类库的层次上看，JMX 包括了核心类库 java.lang.management 和 javax.management 包。
java.lang.management 包提供了基本的 VM 监控功能，
javax.management 包则向用户提供了扩展功能。

图 3 JMX 的操作模型

5.概念

>>>> MBeanManaged Bean的简称，是一个被管理的java对象，在JMX中MBean代表一个被管理的资源（设备,应用程序等）实例。通过操作MBean暴露一系列方法和属性来操作资源。MBean包含4种类型的MBean1.Standard MBeans标准MBeans的设计和实现是最简单的,MBean接口中定义需要暴露的属性和操作，约定MBean接口名字后添加后缀MBean，例如NameMBean.java,实现类名称 name.java2.Dynamic MBeans动态MBeans 在运行期暴露自己的管理接口,MBean实现类需要实现一个特定的接口DynamicMBean。接口中的方法用来动态获取MBean的属性和方法方法如图:3.Open MBean Open MBean也是一种dynamic MBeans,实现DynamicMBean接口。与dynamicMBean 不同的是 Open MBean使用了几种预定义的数据类型提供了更复杂的metadata数据。 Open MBean和dynamic MBean的区别在于是否返回OpenMBeanInfo，它是MBeanInfo的子类4.Model MBean Model MBean也是一种dynamic MBeans,它是预制的、通用的和动态的 MBean 类，已经包含了所有必要缺省行为的实现，并允许在运行时添加或覆盖需要定制的那些实现，JMX规范规定该类必须实现为javax.management.modelmbean.RequiredModelMBean，模型管理构件具有以下新的特点：
1)持久性
定义了持久机制，可以利用Java的序列化或JDBC来存储模型MBean的状态。
2)通知和日志功能
能记录每一个发出的通知，并能自动发出属性变化通知。
3)属性值缓存
具有缓存属性值的能力MBeanServer MBeanServer是MBean 的容器。MBeanServer管理这些MBean，并且通过代理外界对它们的访问。MBeanServer提供了一种注册机制，通过注册Adaptor和Connector，以及MBean到MBeanServer，并且通过代理外界对它们的访问。外界可以通过名字来得到相应的MBean实例。JMX agentAgent只是一个Java进程，它包括这个MBeanServer和一系列附加的MbeanService。当然这些Service也是通过MBean的形式来发布。JMX Agent通过各种各样的Adapter和Connector来与外界(JVM之外)进行通信。JMX Agent可以包含各种不同的协议适配器和连接器连接器 Connector连接器是可以连接MBeanServer，并使远程的java client可以访问该服务。连接器包含 客户端连接器(connector client)和服务器连接器(connector server).服务器连接器链接MBean Server 和 监听客户端的连接请求。客户端连接器任务是查找connector server服务并建立连接。client 和server通常在不同机器的不同JVM中。MX Remote API 定义了标准的连接器 RMI Connector，它通过 RMI 提供了对 MBeanServer 的远程访问。 使用 RMI 将客户端请求传输到远程 MBean 服务器。MX Remote API 还定义了一个可选协议，名为 JMXMP（JMX 消息协议）。JMXMP 基于 TCP 连接上的序列化 Java 对象（在可选包 javax.management.remote.message 中定义）。实现此协议的连接器称为 JMXMP Connector。也可以使用 JMXConnectorFactory 提供的用户定义的连接器协议和可选的通用连接器RMI Connector 使用 RMI 将客户端请求传输到远程 MBean 服务器，RMI Connector支持 RMI 的 JRMP(默认)和 IIOP 传输方式。连接器地址
服务器生成的连接器地址
service:jmx:rmi://host:port 返回如下所示的 JMXServiceURL：service:jmx:rmi://host:port/stub/XXXX
service:jmx:iiop://host:port 返回如下所示的 JMXServiceURL：service:jmx:iiop://host:port/ior/IOR:XXXX
基于目录条目的连接器地址
service:jmx:rmi://host:port/jndi/jndi-name
service:jmx:iiop://host:port/jndi/jndi-name
host 和 :port 均可忽略。
service:jmx:rmi://ignoredhost/jndi/rmi://myhost/myname
第一个 rmi: 指定 RMI 连接器，第二个 rmi: 指定 RMI 注册表service:jmx:iiop://ignoredhost/jndi/ldap://dirhost:9999/cn=this,ou=that其中ldap://dirhost:9999/cn=this,ou=that 表示 LDAP 目录中的 cn=this,ou=that 条目，该目录在运行主机 dirhost 的端口 9999 上。协议适配器 Adapter协议适配器通过特定的协议提供了一张注册在MBean服务器的管理构件的视图。例如，一个HTML适配器可以将所有注册过的管理构件显示在Web 页面上。不同的协议，提供不同的视图。Adapter和Connector的区别在于：Adapter 是使用某种协议(HTTP或者SNMP)来与JMX Agent获得联系，Agent端会有一个对象(Adapter)来处理有关协议的细节。比如SNMP Adapter和HTTP Adapter。Connector 在Agent端和client端都必须有这样一个对象来处理相应的请求与应答。比如RMI Connector。RMI Remote Method Invocation 的简称,RMI是面向对象的远程调用， RMI采用JRMP(Java Remote Method Protocol)通讯协议，是构建在TCP/IP协议上的一种远程调用方法。RMI 允许一个对象使其方法调用对驻留在其它虚拟机，甚至其它主机上的对象可用。RMI调用机制 -----RMI 采用stubs 和 skeletons 来进行远程对象(remote object)的通讯。stub 充当远程对象的客户端代理，有着和远程对象相同的远程接口，远程对象的调用实际是通过调用该对象的客户端代理对象stub来完成的。 对于JNDI技术，所有的可用服务信息都将注册在JNDI服务器，让客户端通过RMI机制调用应用程序服务器远程接口时，应用程序服务器就会根据JNDI 服务器的服务注册信息定位到相应的服务提供连接，等待应用程序服务器与后台服务器连接形成之后，JNDI将不再参与到连接当中（JNDI可以理解为注册服 务提供）LDAP OSL X.500目录是基于OSI网络协议的目录服务协议 ,500的缺点是不支持TCP/IP，而是支持OSI协议 , 在此前提下，也就产生了访问X500目录的网关--LDAP . LDAP（Lightweight Directory Access Protocal, 轻型目录访问协议），是针对以X500目录为主的目录服务的前端访问协议，是OSL X.500目录访问网关. LDAP就被设计成使用TCP/IP访问OSI 目录服务的服务协议，而随着互联网成为网络的主流，LDAP也成为一个具备目录的大部分服务的协议。 LDAP主要解决目录服务的前端访问形式，而不是对 目录服务本身制定的的协议，理论上，LDAP支持后台的任何存储形式，包括X500，关系数据库，文本数据库或文件目录等。LDAP继承了X500目录的 大部分定义，无论是访问样式还是语法都与X500相似。JINIJini( Java Intelligent Network Infrastructure)是一个主动的、响应式的分布式基础结构，它提供了在分布式环境中进行服务的建立、查找、通讯和调用的一整套机制。
Jini系统架构HTTPHTTP协议（HyperText Transfer Protocol，超文本传输协议）是用于从WWW服务器传输超文本到本地浏览器的传送协议。Internet的基本协议是TCP/IP协议，然而在TCP/IP模型最上层的是应用层（Application layer），它包含所有高层的协议。高层协议有：文件传输协议FTP、电子邮件传输协议SMTP、域名系统服务DNS、网络新闻传输协议NNTP和 HTTP协议等SNMPSNMP(Simple Network Management Protocol,简单网络管理协议)
>>>> 实现的协议适配器和连接器

当前已经实现的协议适配器和连接器包括：
1)RMI连接器
2)SNMP协议适配器
3)IIOP协议适配器
4)HTML协议适配器
5)HTTP连接器

JMX 标准提供了四种不同的 MBean：

Standard MBean 直接实现用于管理对象的方法，既可以通过实现一个由程序员定义的、类名以 “MBean” 结束的接口，也可以使用一个以一个类作为构造函数参数的 Standard MBean 实例，加上一个可选的接口类规范。这个接口可以开放用于管理的部分对象方法。
Dynamic MBean 用属性访问器动态地访问属性，并用一个一般化的 invoke() 方法调用方法。可用的方法是在 MBeanInfo 接口中指定的。这种方式更灵活，但是不具有像 Standard MBean 那样的类型安全性。它极大地降低了耦合性，可管理的 POJO（纯粹的老式 Java 对象）不需要实现特定的接口。
Model MBean 提供了一个改进的抽象层，并扩展了 Dynamic MBean 模型以进一步减少对给定实现的依赖性。这对于可能使用多个版本的 JVM 或者需要用松散耦合管理第三方类的情况会有帮助。Dynamic MBean 与 Model MBean 之间的主要区别是，在 Model MBean 中有额外的元数据。
Open MBean 是受限的 Model MBean，它限制类型为固定的一组类型，以得到最大的可移植性。通过限制数据类型，可以使用更多的适配器，并且像 SMTP 这样的技术可以更容易适应 Java 应用程序的管理。这种变体还指定了数组和表等标准结构以改进复合对象的管理。
如 果要同时控制客户机和服务器，那么 Standard MBean 是最容易实现的一种变体。它们的优点是有类型，但是如果在更一般化的管理控制台环境中使用时会缺少一些灵活性。如果计划使用 Dynamic MBean，那么您也可以更一步使用 Model MBean，在大多数情况下它会改善抽象层而几乎不会增加复杂性。Open MBean 是是可移植性最高的一种变体，如果需要开放复合对象，那么它是惟一的方法。不幸的是，在 Open MBean 中开放复合结构所需要的代码数量过多，只有在需要高级的商业管理解决方案时才合算。

JMX 还支持使用带过滤器和广播器的事件模型的通知。为此目的，Standard MBean 需要声明一个 MBeanInfo 元数据描述。 Standard MBean 实现通常在内部构造这些内容，开发人员不能直接看到它们。在本文后面，您会看到如何用 Model MBean 元数据的 XML 描述符格式和 Spring 的 JMX 支持进行实际上透明的配置。

>>>>使用 MBean 的过程1.创建一个 MBServer：MBeanServe2.获得管理资源用的 MBean：serverBean3.给这个 MBean 一个 ObjectName：serverMBeanName4.将 serverBean 以 serverMBeanName 注册到 mBeanServer 上去>>>>通知机制要让MBean能发出通知，MBean必须实现接口NotificationBroadcaster或它的子接口NotificationEmitter.发送通知时要做的是构建javax.management.Notification类的实例或Notification 的子类，然后以参数形式传递这个实例到NotificationBroadcasterSupport.sendNotification.方法中
>>>>JMX 代理内幕

揭示了典型 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 代理向管理客户机传递虚拟机数据的方式。这些属性分成两类：口令认证 和安全套接字层（SSL）。

使用命令行选项

为了让 5.0 兼容的虚拟机可以被监视和管理，需要用以下命令行选项设置平台 JMX 代理的端口号：

-Dcom.sun.management.jmxremote.port=<number>

如果不介意谁通过这个端口访问虚拟机，也可以添加以下两个选项，关闭口令认证和 SSL 加密（这两项默认都是开启的）：

-Dcom.sun.management.jmxremote.authenticate=false-Dcom.sun.management.jmxremote.ssl=false

在开发 java.lang.management 客户机代码，而且想方便地监视另一台虚拟机时，一起使用这三个选项会很方便。在生产环境中，则需要设置口令控制或 SSL（或者两者都要设置）。

口令认证

在JDK 的 jre/lib/management 目录中，可以找到一个叫做 jmxremote.password.template 的文件。这个文件定义了两个角色的用户名和口令。第一个是监视 角色，允许访问只读的管理函数；第二个是控制 角色，允许访问读写函数。取决于需要的访问级别，客户可以用 monitorRole 或 controlRole 用户名进行认证。为了确保只有认证的用户才能访问，需要做以下工作：

把 jmxremote.password.template 的内容拷贝到叫做 jmxremote.password 的文件中，并取消掉文件末尾定义用户名和口令部分的注释，根据需要修改口令。
修改 jmxremote.password 的许可，只让所有者能够读取和修改它。（在 UNIX 和 UNIX 类的系统上，把许可设置成 600。在 Microsoft Windows 上，请按照 “How to secure a password file on Microsoft Windows systems” 一文中的说明操作，可以在 参考资料 中找到这篇文章的链接。）
在启动虚拟机时，用以下命令行选项指定要使用的口令文件的位置：
-Dcom.sun.management.jmxremote.password.file=<file-path>

从管理客户的角度来说，需要提供正确的用户名/口令组合来访问开启了认证的虚拟机。如果客户是 JConsole，这很简单：在初始的 Connection 选项卡中提供了用户名和口令字段