使用 AIDE 实现高效率,第 7 部分: 更好的 IT 管理

使用通用接触点

IBM® Autonomic Integrated Development Environment (AIDE) 有助于采用模型驱动的方法进行接触点开发,是一种有用的工厂样式且带有向导辅助的用于生成通用接触点的模式。不过,在 AIDE 驱动的工作流的某些位置,必须使得接触点特定于给定应用程序。可以在模型设计阶段进行此工作,也可以通过硬编码手动进行。本教程是本系列的第 7 部分,将介绍用于创建通用接触点和专用接触点的各项技术,并且还能从中了解如何生成与给定管理应用程序正确混合的接触点。

Stephen B Morris, CTO, Omey Communications

Stephen 是爱尔兰的 Omey Communications 的 CTO。在过去 20 年中,Stephen 曾在一些世界级大型网络公司参与过各种软件项目,包括基于 J2EE/J2SE 的网络管理系统,帐单编制应用程序、移植和开发 SNMP 实体、网络设备技术和 GSM 移动网络应用程序。他是 Network Management, MIBs and MPLS: Principles, Design and Implementation(Prentice Hall PTR,2003 年)一书的作者,同时也在 InformIT 和 OnJava.com 发表过多篇有关网络管理和其他主题的文章。您可以通过 stephenbjm@yahoo.com 与 Stephen 联系。



2007 年 6 月 25 日

开始之前

了解本教程中包含的内容以及如何最好地利用本教程。

关于本系列

本系列教程描述 IBM AIDE 工具包及其在越来越重要的信息技术(Information Technology,IT)管理领域中的使用,本教程是其中的第 7 部分(最后一部分)。本系列之前的教程已经对从托管元素一直到管理应用程序的 IT 管理价值链进行了讨论。本教程将探讨通用接触点和专用接触点这一重要领域的内容。

本系列教程的目标读者是具有一定 Java™ 编程知识且希望能够通过 AIDE 技术及其组件使用 Web 服务来创建有效的 IT 管理系统的任何人。AIDE 合并了多项强大的开放源代码技术,包括 Eclipse、Apache Tomcat(或 IBM WebSphere® Application Server)和 Apache Axis。

关于本教程

在第七篇教程中,仍然采用通用平台:任何支持 Eclipse、AIDE 工具包和 Java 2 Platform Standard Edition (Java SE) V5.0 的平台。如 Microsoft® Windows® XP 就已经足够了。所有示例代码都是在运行 Microsoft Windows XP Professional with Service Pack 2 (SP2) 的计算机上编写和测试的。

先决条件

本教程的目标读者是具备一定 Java 编程和 Java Platform Enterprise Edition (Java EE) 元素知识的程序员。能够使用 Java EE 元素(如应用服务器)对阅读本教程有所帮助,但并非必须的。本教程全程提供了详细的说明,因此无论是否阅读过本系列的其他教程,都能够顺利完成本教程中的操作。

系统要求

要运行本教程中的示例,必须满足平台的最低要求:一台运行 Windows XP 且安装了 AIDE 软件和 Axis、Tomcat V5 和 Java SE V5.0的计算机。


通用接触点入门

本系列教程内容回顾。

本系列回顾

本系列旨在帮助软件开发人员和设计人员快速使用 AIDE 和其他 IBM 自主计算技术实现高效率。本系列中一个重要的内容是 Web 服务分布式管理(Web Services Distributed Management,WSDM)标准,而 AIDE 正是该标准的一个实现。WSDM 的主要目标是通过提供独立于供应商、平台、网络和协议的框架,以尝试对各种遗留管理基础设施和信息模型进行统一;前者包括简单网络管理协议(Simple Network Management Protocol,SNMP)和桌面管理接口(Desktop Management Interface,DMI)等,而后者包括公共信息模型(Common Information Model,CIM)等。此外,WSDM 还规定管理软件能够访问托管对象的方法和属性。所有此类功能都在 Web 服务的上下文中提供。

不过,WSDM 并非完美无缺。对 WSDM 的一些指责包括其过于复杂,并且依赖于各种其他标准。在某些情况下,其所依赖的标准还处于草案(非最终版)阶段。此类依赖标准包括:

  • WS-Resource 规范
  • WS-ResourceProperties 规范
  • WS-ResourceLifetime 规范
  • WS-ServiceGroup 规范
  • WS-BaseFaults 规范

尽管如此,WSDM 中的两个主要依赖关系涉及到 Web 服务技术:简单对象访问协议(Simple Object Access Protocol,SOAP)和 Web 服务描述语言(Web Services Description Language,WSDL)。在此上下文中,定向到管理端点的 SOAP 消息必须符合 WS-Addressing 标准。WSDL 用于描述管理端点提供的接口。

WSDM 的复杂性

WSDM 很复杂,但其复杂性是有限的。例如,在 WSDM 尝试进行标准化的领域——IT 管理——中也是如此。如果已经学习了本系列前面的教程,并研究过其中的示例,则会发现真正的复杂之处在于理解 IT 管理的理论和实践!本系列教程描述 IT 管理的主要组成部分,包括获取、设置、通知、遗留管理基础设施(例如,Java Management Extension 或 JMX)、Web 服务操作与编排以及通用自主计算领域等。如果 WSDM 要保持自己的优势,则应该由供应商提供的工具包(如 AIDE)对 WSDM 所带来的复杂性进行处理。也就是说,符合 WSDM 标准的管理系统的最终用户不必了解 WSDM 的所有细枝末叶。

动手实践

本系列教程所强调的一个重点是通过与 AIDE 和各种 IT 管理组件进行交互来获得实践知识。其中详细讨论的一些技术包括自主构建的 Weather Station 控件、Derby、Axis、Eclipse 和 JMX。由于本系列以实践为目的,因此并未对托管对象设计(如,设计 JMX Mbean)这一重要领域进行详细地讨论。所讨论的设计注意事项的主要领域都是相对于自主计算管理价值链进行讨论的。对此主题的讨论非常全面,可帮助您很好地了解接触点的开发、托管实体消息传递以及与自主管理器层相关的问题。

本教程是本系列的最后一部分,将对通用接触点的问题进行概括性讨论。对此主题的讨论应该能够帮助弥合相对于设计内容的差距。另外,还应该能够帮助您进行可重用自主管理元素的设计。首先,让我们简单讨论一下通用代码 的组成内容。


使用通用代码

了解什么是通用代码

什么是通用代码?

通用代码是设计过程的主要理想质量属性之一。代码通用性越好,其潜在的可重用性越好。面向对象的编程语言的主要预期交付内容之一就是通用代码。例如,Java 语言中的抽象类就是这样的交付内容。这样的类包含没有完整定义的一些方法。其规则规定不能使用抽象类构造函数创建对象。不过,可以使用抽象类作为基类来定义派生类。让我们通过一个具体的例子来掌握通用代码的概念。清单 1 给出了通用基类的一个简单示例。

清单 1. 使用简单 Java 类建模托管元素
public class ManagedElement
{
private String elementName;

public ManagedElement()
{
elementName = "No name yet";
}

public ManagedElement(String newName)
{
elementName = newName;
}

public String getName()
{
return elementName;
}
}

清单 1 给出了一个名为 ManagedElement 的 Java 类。可以使用此类作为所有托管实体的基类,此类实体如路由器、应用服务器、数据库服务器和 Web 服务等。也就是说,ManagedElement 类形成了继承树的顶部。这与位于 Java 语言继承树顶部的对象(Java Object 类)在概念上有些类似。Java Object 类是所有其他类的祖先。而您在稍后将看到,清单 1 中的类是所有派生 IT 管理类的祖先。

清单 1 中的代码是通用代码。为什么会这样呢?这是因为它不与任何具体托管技术绑定——即,ManagedElement 类仅提供名为 elementName 的单个 name 属性。

派生类

清单 2 给出了一个子类或派生类,对基类 ManagedElement 进行了扩展。清单 2 中的代码的通用性次于清单 1 中的代码,因此其用途更为专一。

清单 2. ManagedElement 的简单子类
public class ApplicationServerObject extends ManagedElement
{
private String vendorName;

public ApplicationServerObject()
{
super();
vendorName = "No name yet";
}

public ApplicationServerObject(String theVendorName, String theProductName)
{
super(theProductName);
vendorName = theVendorName;
}

public String getVendorName()
{
return vendorName;
}
}

清单 3 给出了名为 Demonstration 的类,该类实例化了 ApplicationServerObject 类的一个对象。

清单 3. 实例化 ApplicationServerObject 类
public class Demonstration
{
public static void main(String[] argv) {
	ApplicationServerObject appServerObject = 
        new ApplicationServerObject("IBM", "WebSphere");

	System.out.println("Managed element base class entity name: " + 
        appServerObject.getName());
	System.out.println("Managed element derived class vendor name: " + 
        appServerObject.getVendorName());
}
}

第一个通用代码原则

清单 1清单 2清单 3 进行分析之后,就可以得到第一个通用代码原则:

代码的通用程度与其专用程度呈反比。

也就是说,继承树越往下,代码的应用范围越窄。

因此,面向对象的指导原则是让基类尽可能通用,不要尝试使用域特定的细节过于限制派生类。这相对于清单 1清单 2 的情况如何呢?一种方法是在清单 2 的类的名称选择上做文章。继续阅读前,您是否能想到一个更好、更为通用的方法来对清单 2 中的类进行命名呢?

名称的意义

通过选择名称 ApplicationServerObject,此子类将永远用于建模此类托管对象(即应用服务器)。这是一个常见错误,会导致生成脆弱的代码库。之所以说它脆弱,是因为当您稍后返回进行修改时(例如,维护变更或错误修复),将很难进行。清单 1清单 2 所示的代码很简单,但随着添加越来越多的托管实体,所面临的困难会翻倍,最终会得到一个无用的层次过浅的继承树。

既然这样,可能使用 ServerObjectApplicationServerObject 类名称更好。还可使用名为 ServerObject 的类来建模其他类型的服务器实体,如文件服务器、打印服务器、Web 服务器和数据库服务器。因此,对托管实体进行命名的简单操作本身就是一项关键设计步骤。

名称 ApplicationServerObject 的另一个问题是其中包含了单词 Object。通过在类名称中使用这个单词,就得到了一个笨拙且有些不和谐的结构,其中的 Java 类和对象混杂在一起。这个错误很糟糕,在 IT 管理领域要予以避免。问题在于,托管对象 这一说法恰在面向对象的语言成为所使用的主流语言之前就出现了。随着开始使用这些语言来编写 IT 和网络管理解决方案,托管对象 这一说法就变得越来越常见了。包含托管对象 这样的单词的糟糕类名称也变得很常见了。因此,一定要仔细谨慎地避免在您的类名称中使用这一单词。是否有人说良好的编程很容易做到?我经常说,如果您认为它简单,可能您就错了。

正如您将在接下来的部分中看到的,这个原则直接适用于在本系列中所给出的各个接触点。如果您希望对清单 1、2 和 3 中定义的代码进行试验,可以随意下载、编译和执行上面三个 Java 类(请参见下载部分中给出的链接)。要运行此代码,请将三个 Java 类文件复制到任何文件夹中。将目录更改为指向此文件夹,并运行清单 4 中的命令,以得到所给出的程序输出。

清单 4. 调用 Demonstration
javac *.java
set CLASSPATH=.;%CLASSPATH%
java Demonstration

PROGRAM OUTPUT NOW FOLLOWS:

Managed element base class entity name: WebSphere
Managed element derived class vendor name: IBM

正如在上面清单 3 中看到的,我实例化了有缺陷的类 ApplicationServerObject 的一个对象。请注意,我调用了 ApplicationServerObject 中的第二个构造函数,而这会调用基类构造函数(通过调用 super(theProductName))。通过这样,会创建一个具有名称和一个供应商名称的 ApplicationServerObject 实例。

我随后调用基类方法 getName(),以获得托管对象的名称——在本例中即 WebSphere® Application Server 的实例。此调用之后是对 ApplicationServerObjectgetVendorName() 方法的调用。正如清单 4 的底部所示,此调用会生成运行 WebSphere Application Server 的计算机的名称(即 IBM)。


继承与关注分离

请注意清单 4 中的代码示例划分基类和派生类间工作的方式。每个类都完成尽可能多的工作,而让子类进行更为具体的工作。这就是关注分离 原则的例子——这个原则是代码中非常理想的另一个质量属性,能够起到在整个继承树中平衡各自责任的效果。

使用关注分离

正确使用关注分离时,类结构就不会失衡了,不会有一个或两个提供大量代码的类。正如您将在接下来的部分中看到的,通用代码的生成通常很大程度都源自编程时所持的理念。这个方法并不复杂;通用代码创建实际讨论的仅是设计常识和编程实践。

通用代码是否真的值得花一番功夫呢?

我始终保持着这样一个观点,即正是编写尽可能通用的代码的能力将大师级设计人员/程序员与其他人区分开来。可以在不同的产品系列甚至不同行业中将通用代码重用于各种不同(通常都是非预期)的用途。Apache Software Foundation 是寻找通用软件的好地方,Axis、Apache(Web 服务器)和常见实用工具包就是这样的软件。看看回报,就会觉得绝对值得花精力编写通用代码!以电话 PBX 产品为例。其中一些较老的产品供应商已经使用和重用相同的代码库 30 多年了。考虑到此类产品的资本贬值大约为 10 年或者更短,这无疑是非常不错的回报了。这样的供应商会在维护基础 PBX 系列和添加新功能时跨产品系列重用代码。虽然 PBX 技术在不断推出,由 Voice over IP (VoIP) 技术取代其地位,但正是通用代码的使用帮助 PBX 供应商坚持了很长一段时间。此类代码的灵活性帮助延长了 PBX 产品的生命。


通用接触点

了解需要知道的所有通用接触点信息。

那么,什么是通用接触点呢?

接触点与 Java 继承树不同。首先,接触点是可执行的 Web 服务实体。由于接触点是运行时实体,因此每个接触点在创建时都有具体的目标。为了说明这一点,让我们以本系列中看到的接触点为例:Weather Station 接触点旨在用于监视和控制国家气象监测设备。类似的,Derby 接触点旨在专门用于控制 Derby 数据库实例。在这些情况下,接触点与所交互的托管实体紧密绑定。

清单 5 显示了取自 Derby 接触点 Java 文件 DerbyTouchpointImpl.java 的两个方法。

清单 5. Derby 接触点方法
public int getConnectionPoolSize()
{
  return connectionPoolSize;
}

public void setConnectionPoolSize(int newConnectionPoolSize)
{
  int oldConnectionPoolSize = connectionPoolSize;
  connectionPoolSize = newConnectionPoolSize;
  if (eNotificationRequired())
    eNotify(new ENotificationImpl(this, Notification.SET, 
        AutonomicPackage.DERBY_TOUCHPOINT__CONNECTION_POOL_SIZE, 
        oldConnectionPoolSize, connectionPoolSize));
}

WSDM 可管理资源

我们说过,WSDM 的重点是可管理资源(例如,Derby 实例或气象站)。设计流程的端点是建模为 Web 服务的可管理资源。关于此资源的管理信息必须通过 Web 服务(准确的说,是 Web 服务端点)提供。必须能够通过端点引用(Endpoint Reference,EPR)访问托管资源。正是由于这个原因,才将此类端点称为可管理性端点图 1 显示了将消息定向到一个或多个 EPR 的接触点管理器。EPR 的 AIDE 实现也称为代理。您已经在本系列的第 4 部分首次见到(并使用)了代理。

另外在本系列之前文章中还介绍了这种 get/set 和通知代码。清单 5 中的方法与获取和设置 Derby 实例连接池相关。从概念上说,清单 5 中所示的这类方法代表了接触点的精髓。此类方法将深入托管资源内部,并允许管理系统提取数据,并能对这些数据进行修改。另外,如果管理系统注册为从托管资源接收通知,将在调用 setConnectionPoolSize() 方法时发出一条相应的通知消息。

让接触点保持松散绑定

可能会出现这些接触点与关联的可管理资源之间的绑定过于紧密的情况。将接触点的用途具体地定义为管理给定技术元素的做法会降低其重用性。因此,务必尽可能保持接触点的通用性和松散绑定。这与 IT 管理的松散耦合 Web 服务的 WSDM 理念一致。

图 1 显示了对第 5 部分中讨论的 Derby 数据库管理系统所使用的方法。

图 1. 自主 Derby 数据库管理
自主 Derby 数据库管理

图 1 中的接触点是为了明确的目的而构建的,即管理 Derby 数据库实例。图 1 中的接触点管理器能够创建、使用和删除接触点,以便对关联的 Derby 实例进行监视和控制。可以在各个接触点的粒度级别使图 1 中的接触点管理器尽可能通用。也就是说,此管理器几乎可以与任何接触点进行交互:创建代理、与基础接触点交互以及最终(如果需要)删除代理。因此,此管理器相当通用。那么 Derby 接触点呢——它们的通用性如何呢?

使 Derby 接触点具有通用性

为了回答这个问题,让我们仔细看一下 Derby 接触点,以了解如何使其更为通用。完成以下步骤:

  1. 启动 Eclipse。
  2. 打开 DerbyTouchpointModels 项目。
  3. 双击 DerbyTouchpoint.actpty 项目项。

图 2 显示了与此模型关联的 Derby 接触点类型。请特别注意 DerbyControls 功能的内容——traceDirectory、pageSize 等。

图 2. Derby 接触点类型
Derby 接触点类型

正如 Derby 接触点模型中所示,模型和托管对象之间存在一个设计时绑定。也就是说,如果使用现有结构,可能很难重用此接触点来建模其他数据库类型,如 IBM DB2? 或 Informix?。因此,此处的重用范围并不大。这意味着有提高此接触点模型的通用性的潜在空间。

何时应创建通用代码?

让代码保持通用性的工作最好在设计期间进行,但也可以在完成了代码编写后进行有限的调整。在后一种情况下,提高代码通用性的工作就是进行移植。以下是提高接触点通用性的一些规则:

  • 尽可能多地删除对技术的硬编码引用。
  • 与使用术语 Derby 相比,使用 DB 之类的术语更好。
  • 尽可能选择中性的非特定术语。
  • 尽可能少地添加对 Derby 的引用。

请记住,接触点越通用,其可重用性越强。根据上面的第一个原则,我希望尽可能多地删除 Derby 依赖关系。为此,请完成以下步骤:

  1. 创建名为 DBTouchpointModels 的新模型文件夹。
  2. 将 DerbyTouchpointModels 文件夹的内容复制到 DBTouchpointModels 文件夹中。
  3. 编辑 DBTouchpointModels 文件夹中的 .project 文件。
  4. 将所有 Derby 实例更改为 DB
  5. 编辑 DBTouchpointModels 文件夹中的 DerbyTouchpoint.actpim 文件。
  6. 将所有 Derby 实例更改为 DB

上面的更改应该足以允许您将新模型导入到 Eclipse 中了。现在完成以下步骤:

  1. 重新启动 Eclipse Workbench。
  2. 单击 File > Import > Existing Projects into Workspace
  3. 单击 Next
  4. 选择 DBTouchpointModels 目录。
  5. 接受缺省设置,然后生成接触点。

完成了上面步骤后,应该会创建一个新模型接触点 DBTouchpointModels,如图 3 中所示。

图 3. 更为通用的数据库接触点模型
更为通用的数据库接触点模型

前面的步骤说明了生成通用接触点的原则。实际上,这些步骤说明了如何对现有接触点进行反向工程,以创建更为通用的接触点。显然,创建通用接触点的时机是在设计阶段,即从头创建模型时。此讨论中重要的一点是,创建通用接触点可行,也非常有价值。使用 DB 术语替代 Derby 这个简单的做法为创建通用的以数据库为中心的接触点铺平了道路。

向接触点添加细节

请注意,Derby 接触点模型中有一个名为 DerbyTouchpointImpl.java 的文件。可以使用此文件来重写向导生成的文件。DerbyTouchpointImpl.java 提供了必要的挂钩,以允许生成的接触点控制 Derby 的实例。应该将大部分技术(即 Derby)依赖关系置于接触点的这个位置。

向接触点添加细节的另一个例子是在添加外部 Java 代码时。这样做可进一步将接触点与其托管资源绑定。例如,假定您希望获取并显示有关给定接触点的宿主平台的细节。正如在本系列前面的文章中了解到的一样,JMX 提供了强大的机制来以编程方式管理 Java 平台。越来越多的供应商开始将 JMX 工具包含到产品中,如 IBM(WebSphere Application Server 中)、Jboss(开源产品)和 Oracle。

JMX 的基础是 Mbean,即管理 Bean。从概念上讲,MBean 有些像接触点。主要区别在于,MBean 的管理接口是通过对 Java 接口反射确定的。MBean 类非常灵活,提供了 MBean 的实现类(如操作系统)与其管理接口间的固定关系。平台 MBean(或 MXBean)是一种能够以编程方式监视和控制 Java Virtual Machine (JVM) 的 MBean。每个 MXBean 都不可避免地与 JVM 功能交织在一起——例如 JVM 类加载系统、Just-in-Time (JIT) 编译系统或垃圾回收器。

Platform MBean Server

Platform MBean Server 是一个真正的服务器,因为它可供在相同 JVM 中运行的一个或多个托管组件使用。可以使用 ManagementFactory.getPlatformMBeanServer() 方法来访问和使用 Platform MBean Server(例如,注册 MXBean)。

清单 6 显示了调用 java.lang.management 包中的两个基于 JMX 的方法的简单类。

清单 6. 一些特定于平台的 JMX 代码
package ibm.com.impl;	
	
import java.lang.management.*;

public class PlatformService
{
public String platformDetailsOS()
{
	return ManagementFactory.getOperatingSystemMXBean().getName();
}

public String platformDetailsOSArch()
{
	return ManagementFactory.getOperatingSystemMXBean().getArch();
}
}

平台 MXBean 是符合 JMX Instrumentation Specification 的托管 Bean。MXBeans 仅使用一组基本数据类型(如基元类型 intlong、包装类等等)。JMX 管理应用程序和 Platform MBean Server 可以进行互操作,而不需任何特定于 MXBean 的数据类型的类。如清单 6 中所示,Platform MBean Server 提供了一个非常方便的工厂模式(称为 ManagementFactory)。假定您希望确定宿主操作系统及其体系结构(即底层 CPU 类型)。前面已经介绍了如何以简单 Java 调用的形式将代码合并到接触点中——调用 JMX 代码的过程与此完全相同。要将此类添加到 WeatherStation 接触点,请完成以下步骤:

  1. 打开 WeatherStation 接触点项目。
  2. 打开 WeatherStation\JavaSource\ibm\com\impl。
  3. 将 PlatformService.java 文件复制到此文件夹中。
  4. 清单 7 中的代码行添加到 WeatherStationImpl.java。

在上面的步骤 4 中,我们将代码添加到了 Kickme() 方法中,如清单 7 所示。

清单 7. Kickme() 方法
public void Kickme() throws BaseFault
{
	this.erratic = true;
	System.out.println("I've been kicked!");
	
	PlatformService pservice = new PlatformService();

	System.out.println("Managed element base class entity name: " + 
        pservice.platformDetailsOS());
	System.out.println("Managed element derived class vendor name: " + 
        pservice.platformDetailsOSArch());
}

执行此代码时,应该看到与图 4 中所示类似的日志输出。

图 4. 获取平台特定信息
获取平台特定信息

如果将此类 JMX 功能添加到接触点中,可能会将其添加到新方法中,而不是直接将其插入现有方法中。但您应该能够通过这个例子了解如何进行此工作。


接触点体系结构

了解接触点和 Java 继承树间的区别。

接触点的层次结构

前面的讨论中曾说过,接触点与 Java 继承树不同。接触点本质上与托管资源密切互连。不过,如果遵循了生成通用接触点的指导原则,则应该可以得到接触点组件层次结构,如图 5 中所示。

图 5. 形成接触点层次结构
形成接触点层次结构

注意:图 5 中所代表的理念当前并未在 AIDE 中实现。这些理念仅反映本教程中所讨论的通用接触点概念。

图 5 所代表的主要理念是,在创建接触点(通过 AIDE 创建向导)时,可以根据需要包含所显示的通用组件。因此,如果要将平台特定的 JMX 软件包含进来,可以直接选择 Platform Beans 块,相关的代码将随即添加到接触点中。类似地,如果希望创建特定于 Oracle 数据库的接触点,则可以选择 Software Beans 元素。然后在 Software Beans 元素中选择 Database Beans 块。最后,在 Database Beans 块中选择 Oracle 选项。随后会将所需的 Oracle 特定代码作为接触点的一部分生成。类似地,可以采用相似的方法来创建应用服务器接触点。

在图 5 的上下文中,各个块可能非常简单,它们是图形用户界面(Graphical User Interface,GUI)下拉菜单,供用户选择所需的选项。正如前面提到的,这类功能当前在 AIDE 中不可用,但能通过其说明通用元素非常有用。

接触点库

到本系列教程目前为止,已经介绍了可以称为硬编码接触点 的接触点。此类接触点是在运行创建向导、在所选应用服务器上部署接触点并对其进行测试时预先定义的。那么,如果将接触点组合为供自主管理系统进行选择和合并的调色板,会怎么样呢?从某种意义上讲,通过将预先打包的模型导入并生成关联的接触点,就是在手动进行此工作。

提供这样的接触点库,就是在利用模型驱动的开发来添加通用功能。从概念上讲,这种做法与图 5 所示的方法并不一样。目前在 AIDE 中不支持此方法。

使用特定接触点元素添加值

目前越来越强调业务逻辑——即在编写代码时,关注的是应用程序的需求,而不是基础设施相关的问题。如果需要提供相关功能的应用程序,则可以使用 Apache Tomcat 或 WebSphere Application Server 之类的产品。类似地,如果需要 SOAP 客户机/服务器机制,则可以使用 Apache Axis。现在越来越没有必要像以前一样投入大量的精力来自己创建这些实体。

以在图 4 中添加的 JMX 代码为例,这就是添加管理值的一个例子。您添加的特定(非通用)代码提高了接触点以及整个自主管理系统的价值。这是通用代码的主要好处:使用得越多,实现特定于业务或领域的增值就更快。


总结

WSDM 是一项处理复杂技术问题(IT 管理)的复杂标准。时间将证明 WSDM 的用途将有多么广泛。本教程对一些重要设计问题(如通用接触点的创建)进行了讨论。

生成通用解决方案出奇地简单,而且会以可重用性和可维护性的形式得到回报。可以非常方便地创建通用接触点。通用解决方案代表了对关注分离的需求。在本系列教程中介绍的接触点并不是特别通用,但可以在设计时非常方便地解决这个问题。通过采用这种方法,可以稍后进行非通用添加,向基础接触点添加更多的值。JMX 代码添加就是这样的类值添加例子。JMX 代码可提供大量平台管理数据的访问。


下载

描述名字大小
Sample classes and java filesac-aidetut7source.zip8KB

参考资料

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=SOA and web services, XML, Java technology
ArticleID=232959
ArticleTitle=使用 AIDE 实现高效率,第 7 部分: 更好的 IT 管理
publish-date=06252007