简介： 这是介绍 IBM WebSphere Service Registry and Repository 主要概念和功能的系列中的第 7 篇文章。前几篇文章介绍了业务模型、访问控制及 API 使用等相关内容。本文详细介绍了 WSRR 插件的功能以及使用方法，包括 ：Validation（验证）插件，Modification（修改）插件，Notification（通知）插件和 WSDL parser extension WSDL 解析扩展）插件。
在 WebSphere Service Registry and Repository（以下称为 WSRR）中，通过使用插件可以实现用户自定义的功能，以便满足实际的需求。此自定义的功能可以根据用户的要求执行数据或流程的验证、修改、通知等操作。WSRR 提供了四种类型的插件：验证、修改、通知和 WSDL 解析扩展。这四种类型的插件分别在不同的阶段起作用，如：验证插件是在创建、更新或删除 WSRR 对象之前调用的；修改插件是在创建、更新或删除 WSRR 对象过程中调用的；通知插件是在创建、更新或删除 WSRR 对象之后调用的；WSDL 扩展元素解析插件是在处理 WSDL 时调用的。将插件本身的功能和调用阶段结合使用，可以完成更多的功能，使 WSRR 的使用更加灵活和方便。
在本文中，您将学习如何在 WSRR 中实现并使用这 4 种插件。
JK 是一家向境内外投资机构提供服务的证券公司，随着业务的增长以及公司规模的不断扩大，公司采用 WSRR 作为其服务管理平台，统一管理公司所有的服务。在服务的管理过程中，公司希望执行一些特定的 IT 规则，确保服务遵守适当的业务规则，以提高服务的质量及管理的水平。
JK 公司为了对服务进行有效的管理，明确划分服务的责任人，希望服务的描述文件 (WSDL) 必须有所属部门的信息。
为了实现此功能，我们将实现一个 Validation ( 验证 ) 插件以保证每个 WSDL 文件都有一个部门属性。我们将服务描述文件 (WSDL) 存储在 WSRR 中。当服务发生状态转换时，插件将验证文件是否有该属性。如果该文档添加了该属性，则验证通过，可以发生该转换。否则，验证不通过，该服务不能发生状态转换。
在 WSRR V6.2 中，验证插件有两种，分别是普通验证插件和控制验证插件。普通验证插件必须实现 ServiceRegsitryValidator 接口，控制验证插件必须实现 ServiceRegistryGovernanceValidator 或 ServiceRegistryGovernanceValidator2 接口。控制验证插件是将 WSRR 对象从一种生命周期状态转换为另一种生命周期状态之前或显式地请求验证控制对象时调用的。本文中的场景使用的是 ServiceRegistryGovernanceValidator 接口，在 transition 方法中判断当前 WSDL 文件是否具有部门信息的属性。
为了实现插件，我们需要完成以下步骤：
步骤 1：创建插件应用程序。对于 WSRR 里的插件，默认情况下，对所有的 WSRR 对象都起作用，由于本例验证 WSDL 文件是否有部门信息属性，所以我们只要处理 WSDLDocument 对象，看它在由状态 Plan 变迁（转换）到下一个状态的时候是否具有部门信息属性就可以了。示例代码如清单 1 所示：
public class MyValidation implements ServiceRegistryGovernanceValidator{
|
// 实现控制插件的接口，transition 方法有两个参数，arg0 为状态的 uri,arg1 为 WSRR 内的对象类型
public ServiceRegistryStatus transition(String arg0, OriginalObject arg1) {
|
初始化状态信息，设置返回码为成功
ServiceRegistryStatus status = new ServiceRegistryStatus(); status.setReturnCode(ServiceRegistryStatus.SUCCESS); |
// 由于插件是在 Plan 状态下发生的转换，所以，我们只要处理当前状态为 Plan 的对象，对于不处于该状态的对象，我们直接返回
if(!arg0.equals
("http://www.ibm.com/xmlns/prod/serviceregistry/6/0/governance/DefaultLifecycle#Plan"))
return status;
|
// 由于我们是对 WSDL 文件进行判断，所以我们只处理类型为 WSDLDocument 的对象
if (arg1 instanceof WSDLDocument) {
|
// 状态为 Plan, 类型为 WSDLDocument 的对象，就是我们需要验证的对象
String departmentName;
try {
|
// 得到部门信息属性
departmentName = BSRSDOHelper.INSTANCE.getPropertyValue(arg1, "department"); |
// 判断部门是否为开发部，如果是则通过验证，否则验证失败
if (departmentName.equals("development")) {
return status;
}
} catch (ServiceRegistryInvalidPropertyException e) {
e.printStackTrace();
}
}
status.setReturnCode(ServiceRegistryStatus.ERROR);
return status;
}
|
步骤 2：安装验证插件。
在 WSRR V62 中，插件的安装十分方便。只需要将步骤 1 中的 java 文件打包成 jar 文件，并部署到 WSRR 中即可。
步骤 3：启动验证插件。
启动插件的步骤也比较简单，只需在配置文件里添加插件的类名即可。如图 3 所示，在 governanceValidators 后，添加了插件的类名 sample.MyValidation。
步骤 4：导入 WSDL 文件。
在 WSRR 中，创建 WSDL 文件。
图 4. 导入 StockQuoteServiceSample.wsdl
步骤 5：执行状态转换。
开发人员将该服务的状态改为 Plan, 表示该服务正在被开发中。
步骤 6：转换结果。
从图 6 可以看出，上面的转换并未成功，因为该 WSDL 并没有部门信息属性。
步骤 7： 添加部门属性。
为该 WSDL 添加部门信息属性，如图 7，部门名称是开发部 (development)。
步骤 8：执行转换。
开发人员将该服务的状态改为 Plan, 表示该服务正在被开发中。
步骤 9：转换结果。
由于该 WSDL 已经具有了部门信息属性，转换成功。
由于服务数量的庞大，JK 公司为了规范服务，提高服务的查找效率，希望将服务的描述文件 (WSDL) 分类，同时希望在服务创建的过程中可以自动的添加分类信息，方便将来使用。
为了实现此功能，我们将实现一个 Modification ( 修改 ) 插件。在 WSDL 创建的时候为它添加一个分类。分类信息保存在配置文件中，以便可以在不修改插件的情况下，改变分类的名称。我们将配置文件存储在 WSRR 中，当 WSDL 文件创建的时候，插件读取配置文件中的分类名称，然后将分类信息添加到该 WSDL 文件上。在 WSRR V6.2 中，修改插件有两种，分别是普通修改插件和控制修改插件。普通修改插件必须实现 ServiceRegsitryModifier 接口，控制验证插件必须实现 ServiceRegistryGovernanceModifier 接口，用于修改 WSRR 中被治理的对象。本文中的场景使用的是 ServiceRegsitryModifier 接口，在 create 方法中给该文件添加分类信息。
为了实现插件，我们需要完成以下步骤：
步骤 1：创建插件应用程序。修改插件的 create 方法在对象被创建到 WSRR 前被调用，本例中我们需要在插件中得到 WSDLDocument 对象，然后将分类信息添加到该对象，最后该对象被创建后就自然的被分类。如果想改变对象的分类，则实现 update 方法即可。 示例代码如清单 2 所示：
public class MyModification implements ServiceRegistryModifier{
|
// 实现修改插件的接口，create 方法有 1 个参数，arg0 为 WSRR 内的对象类型
public ServiceRegistryStatus create(OriginalObject arg0) {
|
// 初始化状态信息，设置返回码为成功
ServiceRegistryStatus status = new ServiceRegistryStatus(); status.setReturnCode(ServiceRegistryStatus.SUCCESS); |
// 由于我们是对 WSDL 文件进行判断，所以我们只处理类型为 WSDLDocument 的对象
if(arg0 instanceof WSDLDocument){
WSDLDocument document = (WSDLDocument)arg0;
Util util = new Util();
|
// 从配置文件中得到分类名称
String uri = util.getClassificationName(); |
// 给 document 添加分类信息
document.getClassificationURIs().add(uri);
try {
ServiceRegistrySession serviceRegistry = util.getServiceRegistrySession();
serviceRegistry.update(document);
} catch (Exception e) {
e.printStackTrace();
}
return status;
}
return status;
}
|
步骤 2：安装修改插件。具体步骤参考图 1。
步骤 3：启动修改插件，如图 10，图 11 所示。
步骤 4：导入配置文件。
WSRR 提供了存储用户配置文件的功能。利用该功能，我们可以将插件的配置文件存储在 WSRR 中。
步骤 5：修改配置文件。
本文中的配置文件只有一个配置项，指定了分类的名称。如图 13 所示。
步骤 6：导入 WSDL 文件。
该步骤如图 4 所示。
步骤 7：实验结果。
从图 14 可以看出，WSDL 已经处于我们指定的分类中。
JK 公司为了更加严格地管理服务，希望服务的任何修改都被纪录到一个文本文件中，以便于日后的错误跟踪。
为了实现此功能，我们将实现一个 Notification ( 通知 ) 插件。当 WSDL 文件变更完成以后，插件将变更发生的时间以及文件的名称纪录在一个叫做 nodificationRecord.txt 的文件中，该文件位于 WAS 的临时目录中。在 WSRR V6.2 中，通知插件有两种，分别是普通通知插件和控制通知插件。普通通知插件必须实现 ServiceRegistryNotifier 接口，控制通知插件必须实现 ServiceRegistryGovernanceNotifier或ServiceRegistryGovernanceNotifier2 接口。控制通知插件作用于 WSRR 中被治理的对象。本文中的场景使用的是 ServiceRegistryNotifier 接口，在 update 方法中实现将 WSDL 的名称及更新时间信息保存在文本文件中。
为了实现插件，我们需要完成以下步骤：
步骤 1：创建插件应用程序。通知插件是在对象发生更新之后调用，当 WSRR 中的 WSDL 文件发生变更后，通知插件被调用，将变更的时间以及文件的名字纪录在我们自定义的日志文件中。 示例代码如清单 3 所示：
public class MyNotification implements ServiceRegistryGovernanceNotifier{
|
// 实现通知插件的接口，update 方法有四个参数，arg0，arg1 为 WSRR 内的对象类型 ,arg0 为修改前的对象，arg1 为修改后的对象，arg2 为此次操作的结果，默认为 success,arg3 为抛出的异常
public void update(BaseObject arg0,
BaseObject arg1, boolean arg2, ServiceRegistryException arg3){
|
// 由于我们是对 WSDL 文件进行判断，所以我们只处理类型为 WSDLDocument 的对象
if(arg0 instanceof WSDLDocument){
String name = arg0.getName();
|
// 得到 WAS 的临时路径
String wasTemp = System.getProperty("was.repository.temp");
|
// 生成日志文件
File file = new File(wasTemp + "/updateRecord.txt");
try {
if (!file.exists()) {
file.createNewFile();
}
|
// 将文件的更新时间及文件名写进日志
BufferedReader input = new BufferedReader(new FileReader(file));
String s = new String();
String s1 = new String();
while ((s = input.readLine()) != null) {
s1 += s+"\r\n";
}
input.close();
Date date = new Date(System.currentTimeMillis());
s1 += "The document "+name+" is updated at: " + date + "\r\n";
BufferedWriter utput = new BufferedWriter(new FileWriter(file));
output.write(s1);
output.close();
} catch (IOException e) {
e.printStackTrace();
}
}
}
|
步骤 2：安装通知插件。具体步骤参考图 1。
步骤 3：启动通知插件，具体步骤参考图 15，图 16。
步骤 4：导入 WSDL 文件。
该步骤可参考图 4。
步骤 5：修改 WSDL 文件的属性值。
修改 WSDL 的属性 dd 的值。其中，dd 为作者添加的属性。
步骤 6：实验结果。
如图 18 所示，在 WAS 的临时目录里生成了 updateRecord.txt 的文本文件。该文件的内容为文件的名称以及修改时间。
说明，本文为了说明通知插件的作用，将文件保存在 WAS 的临时目录中。在实际中，不推荐将文件保存在该目录。
对于带有扩展元素的 WSDL 文件 , JK 公司希望在服务创建的过程中可以添加详细的关于服务扩展元素的信息，以便将来使用方便。
为了实现此功能，我们将实现一个 WSDL parser extension plug-in (WSDL 解析扩展 ) 插件。在 WSDL 创建的时候为扩展元素添加一个 extensionDescription 属性，记录该扩展元素的详细信息。在 WSRR V6.2 中，WSDL 解析扩展插件必须实现 ServiceRegistryParserExtension 接口。
为了实现插件，我们需要完成以下步骤：
步骤 1：创建插件应用程序。 WSDL 扩展元素解析插件是在处理 WSDL 时调用的，当扩展元素的 WSDL 的命名空间与注册的命名空间匹配时，该插件被调用。示例代码如清单 4 所示：
public class WSDLExtension implements ServiceRegistryParserExtension{
|
// 实现 WSDL 解析扩展插件的接口，parseElement 方法有两个参数，arg0 为 WSRR 内的可扩展的对象 ,arg1 为 DOM 中的扩展元素
public boolean parseElement(ExtensionLogicalObject arg0, Element arg1) {
|
// 得到命名空间
String ns = arg0.getNamespace();
System.out.println("ns:"+ns);
|
// 我们只处理和注册的命名空间匹配的命名空间 if(ns.equals("http://tonawanda.sr.ibm.com/StockQuoteServiceSample")){
String description = "The extension is used for MQ!"; |
// 添加扩展信息
try {
BSRSDOHelper.INSTANCE.addProperty(arg0, "extensionDescription", description);
} catch (ServiceRegistryInvalidPropertyException e) {
e.printStackTrace();
}
try {
Util util = new Util();
ServiceRegistrySession serviceRegistry = util.getServiceRegistrySession();
serviceRegistry.update(arg0);
} catch (Exception e) {
e.printStackTrace();
}
}
return true;
}
|
步骤 2：安装 WSDL 扩展解析插件。具体步骤参考图 1。
步骤 3：启动 WSDL 扩展解析插件。
图 19. WSDL 扩展解析插件配置项
图 20. 启动 WSDL 扩展解析插件
步骤 4：导入 WSDL 文件。
该步骤参考图 4。
步骤 5：试验结果。
如图 21 所示，扩展元素 RMStockQuotePort 添加了 extensionDescription 属性，该属性说明该扩展用于 MQ。
本文详细介绍了 WSRR 4 种插件的功能以及如何实现和部署这些插件，包括 Validation （验证）插件，Modification（修改）插件，Notification（通知）插件和 WSDL parser extension （WSDL 解析扩展）插件。完成本文中的练习之后，您现在可以开发一个插件，将其部署到 WSRR 中，熟练的使用这些插件可以达到很好的自定义的效果。
原文链接:http://www.ibm.com/developerworks/cn/websphere/library/techarticles/1007_dubb_wsrrplugin/1007_dubb_wsrrplugin.html
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14789789/viewspace-669852/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/14789789/viewspace-669852/
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
