生成 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 ，在那里，您可以找到有关这个主题的大量技术资源、文章和指南(参见 参考资料 )。

　　点击查看：2011年计算机二级考试JAVA知识点整理汇总