2.2 应用 JMX 最佳实践

　　构建 Java 应用程序需要许多复杂的分布式组件。现今，几乎所有的应用程序都要连接到遗留系统或其他 IT 资源。这些应用程序的分布式本质，为 IT 提出了一个难以置信的挑战，即一旦开发出一个应用程序，就要担负起维护该应用程序及其所有相关程序的重担。

　　由于企业开始采用面向服务的体系结构( Service-Oriented Architectures ， SOA )，问题变得进一步复杂化了。 SOA 引入了一种设计风格，即把应用程序公开为，以松散耦合方式连接的服务。在 SOA 方法中，通常使用不同的编程语言和平台，来开发应用程序组件。在某些情况下，客户端和服务提供者之间的连接，直到运行时都无法确定。

　　寄希望于利用 SOA 的企业，现在需要一种更好的方式，来管理它们的分布式应用程序和服务。对处理现今应用程序异构和动态的本质来说，使用既定的底层管理技术(如 SNMP )已经不能满足需求。管理需要面向服务的风格—— META Group 将此称为面向服务的管理体系结构( Service-Oriented Management Architecture )或 (SOMA) 。( 参见 参考资料 )

　　SOMA 允许异构的托管系统和管理应用程序和平共处。面向服务的管理风格，可以消除现存的人工屏障，这些屏障，是由于依赖特定平台上的特定管理 API 而造成的。让我们进一步考察，如何通过 Java 管理扩展( Java Management Extension ， JMX ) API ，而在 Java 中实现 SOMA 。

　　除了支持在管理产品之间进行更好的集成之外， SOMA 还使得开发自定义管理应用程序变得更加轻松。尽管企业通常依赖于开箱即用的管理解决方案，但也需要构建用于监控管理数据的，特定子集的自定义工具板。 SOA 风格的管理将使一个团队，能够使用反馈自 Web 服务的数据，来快速构建管理应用程序。 Web 服务是 SOA 实现中使用的常见技术。

　　SOMA 表述

　　区分管理接口和管理实现是相当重要的。 SOMA 中提出的设计原则，主要与托管系统和被托管应用程序之间的接口有关。关于在公开一项托管资源的过程中，所使用的底层实现， SOMA 没有任何表述。一个应用程序可能需要使用特定的 API ，并借助不同的管理接口进行公开。例如， Java 开发人员可以使用 JMX ，在他们的应用程序中增加易管理性。 JMX 使开发人员可以在他们的应用程序中使用 JMX MBean ，这样 JMX Mbean 服务器就可以发现并访问这些托管资源。

　　JMX 不仅仅是一个编程 API ，它还定义了一个包括监控和管理服务的体系结构，以及一个包括连接器和适配器的分布层。开发人员可以使用标准的 RMI 连接器，来外部公开管理接口。然而，如果您希望公开更多面向服务的管理接口，那么使用 RMI 连接器并非最佳方法。

　　现在已经提出了几个用于解决 SOMA 问题的标准。 Hewlett-Packard (HP) 所进行的早期工作，导致了第一批基于 SOA 的管理标准的出现，其中之一是： Web 服务管理框架( Web Services Management Framework ， WSMF )。 HP 把 WSMF 提供给了 Web Services Distributed Management (WSDM) ， WSDM 是一个 OASIS 技术委员会，创建它的目的是，为用于可管理资源的 Web 服务接口定义规范。 [NextPage]

　　我们相信，业界会为 JMX 和其他基于 SOA 的管理标准开发 WSDM 协议适配器的。一般性的概念是， WSDM 协议适配器将支持 WSDM 客户端或管理应用程序，来使用 Web 服务协议与 JMX Mbean 连接(参见 图 1 )。

　　图 1. 从 JMX 到 WSDM 的连通性

　　通常， JMX-WSDM 协议适配器会使用 Web 服务协议，来支持 WSDM 客户端或管理应用程序，与 JMX Mbean 连接。

　　如果开发人员希望通过 JMX 来实现易管理性，那么他们是如何实现 SOMA 的呢?幸运的是，有许多良好的证据点，演示了从 JMX 到 SOA 管理风格的映射。例如， HP 发布了 HP OpenView Smart Plug-In (SPI) ，它可以管理和监控 WebLogic Integration 中的业务流程(参见参考资料) SPI 不得不包括由 BEA Weblogic Integration 公开的 JMX Mbean 和基于 WSMF 的接口之间的一座桥梁。

　　从我们自己的经验出发，我们已经找出了，在把 JMX 映射为 Web 服务过程中的几处障碍。要想克服这些难题，我们需要考虑服务和松散耦合体系结构方面的问题。我们必须应用一些设计原则，比如简单性、模块性和互操作性。

　　例如，假定一个典型的 JMX Mbean 与客户端有着十分紧密的耦合，公开了有关可管理资源的许多底层细节。 JMX Mbean 可能映射为 Java 类或 Enterprise JavaBean (EJB) 。我们不想把这个 Mbean 映射为单个的 Web 服务端点。相反， SOA 需要一个用于公开易管理性的、更加粗粒度的方法。

　　Java 和 Web 服务使用的数据类型之间的互操作性，也是必须解决的一个主要难题。我们发现， JMX 接口使用的数据类型，不能自动转换为 Web 服务的数据类型。另外， JMX Mbean 可以向 Java 对象返回一个远程引用，这在 Web 服务世界中没有相对应的部分。

　　管理挑战

　　我们研究 JMX 定义的编程模型和体系结构时，发现了编程接口和 管理模型 之间的明显区别。 JMX 提供了一个非常灵活且功能强大的 API ，用于实现应用程序的易管理性，但是单独使用 JMX 无法定义或利用任何特定的管理模型。

　　建立良好的管理模型，对于功能丰富的管理应用程序来说是必不可少的。如果没有这种管理模型，跨应用程序一致地提取和处理管理数据，就将成为一大挑战。

　　最后，在 JMX 中尚未完全支持的新兴 Web 服务管理规范中，定义了几种重要的管理抽象。例如， WSDM Management Using Web Services (MUWS) 包括一个线级规范，用于基于 Web 服务技术的交换管理信息。这个规范对 Metrics, ResourceState 和 Relationships 的管理功能进行了建模(参见 图 2 )。

　　图 2. 管理功能

　　这个规范对 Metrics, ResourceState 和 Relationships 的管理功能进行了建模。

　　JMX 无法充分地对许多此类功能建模。例如，尽管 JMX 为 Mbean 之中的关系定义了一个 Relation 服务，但它使用起来还是相当的复杂，而且很少在实践中实现。 JMX 也不直接支持像 Metrics 和 State 这样的功能。例如， JMX 中并没有预定义的类，来代表不同类别的量度。

　　WSDM 的这些缺点，使从 JMX 到 SOA 的易管理性接口的自动转换，成为了一个大大的难题。为了帮助您克服一部分此类难题，我们给出了一系列的 5 个最佳实践，用于为 WSDM 作准备的 JMX 开发。我们相信，结合这些实践，将会开发出更加易于管理的应用程序，而与您是否计划使用 WSDM 无关。

  [NextPage] 

　　最佳实践 1 ：从管理模型开始。 管理模型 定义了要交换的管理信息，以及这些信息的底层语义。使用管理模型，对于确保易于发现、标识和监控托管资源的健康和可用性是必不可少的。管理模型对于确保，可以在运行时统一地配置和控制应用程序来说，同样很重要。

　　应用程序是不会孤立存在的，它们和其他应用程序、系统以及网络组件都有着相关性。即使主要考虑一个应用程序时，应用程序的易管理性也必须把这些相关性考虑在内。管理模型应该捕捉这些相关性和关系。

　　创建一个管理模型，要求您在软件生命周期的早期，考虑到易管理性的需求。通常，开发人员总是在事后才想起易管理性的问题。为了在构建 SOMA 方面获得真正的成功，您必须从一开始就考虑易管理性和管理模型。事实上，无论您使用何种技术来公开易管理性，一个优秀的管理模型总是会为您带来好处的。在开发管理模型的过程中，您应该询问一些问题。什么是托管 资源 ?什么是托管资源的 状态 ，如何去控制它?托管资源之间存在 关系 吗?您需要跟踪什么特定的业务或性能 量度 ?应该公开什么样的额外管理 属性 和 操作 ?托管资源关心的是什么事件和消息 通知 ?

　　定义模型

　　理解这些问题的答案，能够帮助您定义一个可以跨 IT 基础架构利用的管理模型。您还应该从操作人员的角度考虑这个管理模型，因为操作人员必须在部署应用程序之后对其进行管理。

　　记住，应用程序公开的管理模型和它的内部结构不是一回事。前者的目标是允许外部管理系统有效地监控、配置和控制应用程序，而后者的目标则是实现业务功能。

　　例如，我们设想一台 Web 应用服务器，它允许部署多个 Web 应用程序或 Web 模块，每个 Web 模块由一个或多个 servlet 组成(参见 图 3 中高度简化的系统管理模型)。
　　在高度简化的系统管理模型中，一台 Web 应用服务器允许部署多个 Web 应用程序或 Web 模块，而每个 Web 模块由一个或多个 servlet 组成。

　　这个模型为每项可管理资源，都定义了状态、通知、量度、属性和操作。我们将利用这个过分简化的模型，围绕在 SOMA 中使用 JMX 实现易管理性，来应用另外的最佳实践。另外，我们还开发了 实现这个模型的完整源代码 。

 [NextPage]  

　　最佳实践 2 ：设计互操作性。 拥有一个定义良好的管理模型，是走向 SOMA 的第一步。 Java 社区已经意识到了这种需要，并且已经通过 JSR 77 和 174 为 J2SE 和 J2EE 平台定义了管理模型。

　　JSR 174 现在是 J2SE 5.0 规范的一部分，它提供了一种为 Java 虚拟机( Java Virtual Machine ， JVM )公开管理模型的方式。它引入了平台 MXBean 的概念，这个概念是用于建模，代表特定的 JVM 监控指示器的，专门 JMX MBean 。这些 MXBean 可以用于监控内存使用、线程争用问题、类装载行为和垃圾收集频率。

　　所有 MXBean 都被实现为 OpenMBean ，这是一个提供增强级别互操作性的 JMX Mbean 类型。 OpenMBean 限制了 Mbean 接口中某些数据类型的使用。这种限制最小化了客户端对于访问 Mbean 的需求，进一步确保了可以使用 XML 轻松访问和操作这些 MBean ，同时不用求助于特定的封送和解除封送逻辑。

　　所有 MXBean 操作和属性必须遵循特定的数据类型集合，叫做开放类型( open type ) ，它包括原始类型 ( int, long 和 boolean )、枚举、 CompositeData 类型和 Map and List 类型。 清单 1 显示了一个遵从这些数据类型要求的 ServletMXBean 接口的例子。

　　注意， J2SE 5 天生就不支持从用户定义的 MXBean 到 Open Mbean 的映射，这意味着您无法引入您自己的 MXBean ，并指望它的行为像平台 MXBean 一样。可以开发一个一般类集合，来支持把用户定义的 MXBean 作为 Open Mbean 注册到 MBeanServer ，而且我们希望这些类将通过 JCP 过程变为可用。

　　即使您没有直接使用平台 MXBean ，您仍然可以把您的 JMX MXBean 设计为符合 Open Mbean 的模型。最终结果是一个互操作性更强，并满足 SOMA 需要的 JMX 接口。

　　补充 JMX

　　最佳实践 3 ：利用 J2EE 管理机制。 JSR 77 提出了一个为 J2EE 平台公开管理信息的管理模型。模型支持管理大量 J2EE 资源的能力，包括 EJB 、 Web 容器、 JMS 和 JDBC 连接。该模型可以用于收集、监控和控制有关应用服务器的运行时信息。这个通用模型支持使用管理工具，轻松地管理多个 J2EE 的厂商实现。

　　JSR 77 定义了许多抽象，在处理性能统计信息、应用程序状态和关系方面，对 JMX 进行了补充。它定义了 Statistic 接口，用于对 J2EE 组件的性能数据建模。例如，模型定义了一个 EJBStats 接口，为所有的 EJB 组件指定了统计信息。这个接口公开了基本的 CountStatistics ，用于跟踪，创建和删除的对象的数目：

　　public interface EJBStats extends

　　Stats {

　　CountStatistic getCreateCount();

　　CountStatistic getRemoveCount();

　　可以通过 StateManageable 接口来管理一个对象的状态。您可以查询资源的状态，并启动和停止特定的组件。另外， JSR 77 为模型中的代表关系定义了一个基本的惯例。可以定义包容关系，在这种关系中，特定的容器可以维护一个托管对象的数组。

　　我们可以将多个此类设计原则，应用到我们的管理模型例子(参见 图 4)。我们说明了如何增强 MXBean ，来支持状态管理、事件、规格和包容的能力。参考前面 清单 1 中的源代码，您会发现 Servlet MXBean 接口是按照前面描述的模型，来定义 Servlet Managed 对象的易管理性接口的。

[NextPage] 

　　在我们的管理模型例子中，我们可以看到如何增强 MXBean ，来支持状态管理、事件、量度和包容功能。

　　ServletMXBean 及相关接口

　　清单 1. 这个 ServletMXBean 接口符合开放类型，开放类型包括原始类型( int, long 和 boolean )以及它们的包装类、枚举、 CompositeData 类型和 Map and List 类型。

　　public interface ServletMXBean {

　　public boolean isStateManageable();

　　public boolean isStatisticsProvider();

　　public boolean isEventProvider();

　　public boolean isContainerMXBean();

　　public List getEventTypes();

　　public Stats getStats();

　　public String getImplClass();

　　}

　　public interface Stats {

　　public Statistic getStatistic(String name);

　　public Map getStatistics();

　　}

　　public interface Statistic {

　　public String getName();

　　public String getUnit();

　　public String getDescription();

　　public long getStartTime();

　　public long getLastSampleTime();

　　}

　　使用量度、统计信息、状态管理和关系，是 SOMA 的重要方面。没有这些功能，提供一个用于监控和管理 Java 应用程序的一致管理接口，就成为了一件困难的事情。在您自己的开发项目中，要注意使用一些这样的 J2EE 管理机制。

　　最佳实践 4 ：使用 JMX 通知进行通信。 JMX 为托管对象定义了一个事件模型，您可以使用这个模型来接收或生成事件。事件机制对于处理，由托管资源生成的关键事件，以及监控状态变化，是必不可少的。事件还可以用于为托管资源去监控服务级别的违规。 JMX 通知机制允许 Mbean 发送通知给其他 Mbean 或其他管理应用程序。以通知为中心的设计原则，可以应用于我们的示例管理模型。例如，我们可能需要，在某个属性出现变化或者加入新的模块时，生成通知。

　　清单 2 显示了 WebAppServerMXBean 类的实现，其中包括给应用服务添加新的 WebModule 时，要调用的 addWebModule() 方法。注意 Notification 对象的创建和对 sendNotification() 方法的调用。这个方法是从基类继承而来的，使用一个实用程序类( javax.management.NotificationBroadcasterSupport )来发送通知。

 [NextPage]

　　生成 JMX 通知

　　清单 2. WebAppServerMXBean 类的这个实现，包括 给应用服务添加新的 WebModule 时，要调用的 addWebModule() 方法。

　　public class WebAppServerMXBeanImpl

　　extends NEStandardMBean

　　implements WebAppServerMXBean {

　　// Implementation details removed -- see

　　// full source code

　　private ArrayList webModules =

　　new ArrayList();

　　private String adminEMail;

　　public void setAdminEMail(String adminEMail){

　　String oldEMail = this.adminEMail;

　　this.adminEMail = adminEMail;

　　// create and send a notification.

　　Notification notif = new Notification(

　　"jmxbp.attribute_changed", "hello", 1,

　　System.currentTimeMillis(),

　　"attribute: AdminEMail, old value: " +

　　oldEMail + ", new value: " + adminEMail);

　　sendNotification(notif);

　　}

　　// non-MBean methods.

　　public void addWebModule(String objectName){

　　webModules.add(objectName);

　　// create and send a notification.

　　Notification notif = new Notification(

　　"jmxbp.child_added", "hello", 1,

　　System.currentTimeMillis(), "test message");

　　sendNotification(notif);

　　}

　　}

　　使用 JMX 通知是 SOMA 的关键设计原则之一。在面向服务的设计中，您需要获得托管资源的能力，以便与管理系统进行简易的通信。 JMX 通知允许您，更容易地生成要处理的应用程序事件。另外，正确使用通知机制，可以减轻潜在的性能问题，具体方法是，让管理系统频繁地轮询应用程序，看看有无变化。

　　聚会时间

　　最佳实践 5 ：分离管理和业务关系。有一个良好的设计实践是， 把需要托管的业务对象，从管理它们的管理接口中分离出去。许多当前的 JMX 最佳实践，并没有使这种分离表现为显式的，这就导致了把业务层和 JMX 接口相结合的应用程序的开发。

　　把这两个方面相混合，可能会带来一些严重的后果，比如需要为一个类的每个实例注册一个 JMX MBean 。另一方面，分离管理和业务，允许管理接口独立于所定义的业务对象而变化。

　　您可以应用一系列非常确实的设计模式，来辅助对您管理层的建模工作 ( 参见参考资料 ) 。例如， SeparateMBean 模式 ( 参见 图 5 ) 描述了，与必须托管的，从业务对象分离的单独对象的， MBean 的创建。创建业务对象时，它们要维持一个引用，引用了充当它们管理方的，单独的 MBean 对象。

　　图 5. SeparateMBean 设计模式

　　SeparateMBean 模式描述的是，与必须托管的业务对象分离的，单独对象的 Mbean 的创建。每个业务对象维护一个充当它们管理方的，单独 MBean 对象的引用。

　　尽管我们的例子没有包括 ServletMXBean 的真正实现，但实际上是可以使用 SeparateMBean 模式的，在该模式中， MXBean 是由 Servlet 对象更新的。

　　在 Web 服务管理接口中获得正确的粒度级别时，其他设计模式可能会对您有所帮助。因为每个 Mbean 都有与注册和查找相关的开销，设计过多的 Mbean 会影响性能。通过使用级联模式，您可以使这种性能影响变为最小，并向管理应用程序提供更加粗粒度的接口。

　　还有一件事情也很重要，即，要把 JMX 管理接口看作是管理数据的库，而不是管理逻辑的库。当您需要监控应用程序的阙值违规时，应把这种逻辑放入管理系统，而不是放入托管应用程序中。这样做可以提供更多的灵活性，以便在部署应用程序之后，更新服务级别的监控。

　　随着所部署体系结构的复杂程度和分布式程度的增加， IT 将需要一个更加灵活而开放的体系结构，来管理 SOA 组件。诸如 JMX 这样的管理技术，为实现 J2EE 应用程序的易管理性提供了具体的解决方案，但是它们并不能满足需要。

　　为了实现 SOMA ，您必须将 SOA 原则应用于管理，这需要考虑每个应用程序，对易管理性的要求。然后，管理功能就组成了资源的管理模型。拥有一组通用管理模型，是构建跨厂商实现的，标准管理接口的关键。

　　在 Web 服务技术领域的经验中，强调设计中互操作性的重要性，而且在您使用 JMX 技术时，应该注意选择正确的数据类型，来缓解这些问题。另外，您可以期待 JSR 77 中提供的功能，能够帮助您，在您的应用程序中构建管理功能。然而，使用 JMX 开发您的应用程序，需要花费更多的工夫。它要求围绕您的易管理性需求，进行仔细地规划，还要求仔细地分离管理和业务问题，从而使您的设计具有最大的灵活性。

　　最近引入的 JSR 255 把目标定为更新 JMX 和 JMX Remote API ，从而从可用性的角度改善现有的接口 ( 参见资源 ) 。我们希望，经过修订的规范可以结合这里给出的最佳实践，或者能够让使用这些最佳实践变得更加容易。我们还要清楚如何努力，去引入单独的 JSR ，以探讨，用于搭建从 JMX 到 Web 服务标准(比如 SOAP )的桥梁的可用方法。

　　通过结合一些方法，以及这里讨论的 JMX 技术，您可以更加高效地公开使用 JMX 的、带有 WSDM 的应用程序或者其他管理接口。最后，您将能够设计更多管理感知的、能够满足业务需求的应用程序。

　　想要了解关于 JMX 技术的更多信息，您可以访问 HP 的 Dev Resource Central ，在那里，您可以找到有关这个主题的大量技术资源、文章和指南(参见 参考资料 )。