在 UDDI 中使用分类法区分条目并创建社区

在 UDDI 中开发和使用所检查种类的验证服务

文档选项

将此页作为电子邮件发送

级别： 初级
Matt Rutkowski (mrutkows@us.ibm.com), UDDI Development, Emerging Technologies，IBM
Andrew Hately (hately@us.ibm.com), UDDI Development, Emerging Technologies，IBM
Robert Chumbley (chumbley@us.ibm.com), UDDI Development, Emerging Technologies，IBM
2003 年 4 月 01 日
本文描述了 UDDI 中的分类法在根据标准分类法对数据进行区分方面的强大功能，并描述了如何使用分类法来创建注册中心（已经向外部用户屏蔽）的子集。本文还描述了在 IBM UDDI 测试注册中心使用 UDDI 验证服务创建 Speed-start Web 服务社区。这个 Speed-start 社区是一组公共数据的示例，这些数据可以使用简单的基于种类的查询与同一 UDDI 注册中心中的所有其他公共数据区分开来。作为对那个查询的响应的一部分返回的 UDDI 条目在发布的时候已被 Speed-start 验证服务评估，以确保这些条目是在因特网上可以访问到的 Web 服务。
注册到统一描述、发现和集成（Universal Description, Discovery and Integration，UDDI）商业注册中心的 IBM 版本的企业常常包含大量的可读信息：如企业名称（这些名称会用每种可以想像得到的语言书写）、地址、联系人，包括所有他们的电子邮件地址、电话、手机和传真号码。描述了自己的企业后，这些服务提供者接着添加它们提供的每项服务。注册了所有的这些信息，公司员工便可以闲坐在公司中，等待顾客找上门来，并大量发送电子邮件，然后等待大量的在线订单，是不是这样呢？
不完全对，这些公司还需要利用 UDDI 提供的最重要的功能之一：分类法！
依靠各家公司通常输入的所有这些信息，顾客只有根据早已知道的企业或服务名称使用“按名称查找（Find by name）”搜索才能找到这些公司。因此，那些可能找到这些企业的人们仅仅是那些仍然使用电话薄中的书面的白页和黄页来进行查找的人。应当清楚的一点是，在全球企业目录中，拥有一个以“AAA”开头的企业名称并不足以让一家企业被列于首位或被查找到的次数最多。
UDDI 提供了一种机制，这种机制包括一些标准的分类法，它们可用于使用所需的尽可能多的行业标准搜索术语描述每一个条目。每个企业、服务或技术模型都可能包含一个“种类包（Category Bag）”，这个“种类包”保存有通过键值标识的引用（即分类法代码、定位器或关键字），这些引用可以具体描述其企业的类型、物理位置，甚至还可以描述该企业提供的确切的产品。这些通过键值标识的引用包含一个对分类系统或分类法的引用、一个包含那个分类法中的值的文本域和一个针对人类可读的描述内容的文本域。通过使用分类法方法，UDDI 查询 API（UDDI Inquiry API）可以迅速而有效地将企业和服务与需要它们的客户准确地连接起来。




回页首
UDDI 现在支持几个“内置的”分类法系统（请参阅参考资料以获取链接），它们可以用于发布或查询：
北美行业分类系统（North American Industrial Classification System，NAICS） 企业分类代码，例如制药（3254）、光学用品商店（44613）
通用标准产品和服务分类法（Universal Standard Products and Services Classification，UNSPSC） 产品和服务代码，例如，超轻飞机（25.13.20.05.00）、土壤污染咨询服务（77.12.16.04.00）
地理分类系统（Geographic Classification System，GCS）（根据 ISO 3166-1999 制定） 国家或地区、州、省和地区的代码，例如，美国得克萨斯州（US-TX）、丹麦（DK）。
UDDI 分类 UDDI 标准和 UDDI 使用／认可的标准的一个分类，例如，有线／传输协议（transport），用 WSDL 描述的 Web 服务（wsdlSpec）
通用关键字 任一个值与一个关键字的自由关联，例如“商店位置”（#102）、“汽车”（Toyota）
这些分类法的前三个是针对分类条目的标准。第四个分类法（即 UDDI 分类法）是作为 UDDI 规范的一部分开发的，用来为对 Web 服务的技术信息进行分类提供有用的值。最后一个分类法对于用条目关联关键字（尤其是那些不是条目名称一部分的关键字）来说很有用。这些分类系统的每一个都由一个 UDDI 条目（称为 tModel（技术模型，Technical Model））进行唯一标识，并且能够通过其 tModelKey 引用。XML 格式的在 UDDI 数据结构中对以上种类信息进行引用的情况如清单 1所示。

除了这些“内置的”值集以外，政府和企业的多数领域（例如，农业、汽车业、计算机业）开发了它们自己的标准和分类系统，这些标准和分类系统可以很容易地在 UDDI 中发布、描述和引用。欲了解更多关于发布一个新值集的信息和代码样本，请参阅 Web 服务发布与发现的 UDDI4J 一节（请参阅参考资料以获得链接）。
为了适应其他的值集，UDDI 还提供了用于分类系统的外部提供者的方法，以将它们的值集注册到 UDDI 本身，因此使得任何企业、服务或技术模型能够开始将它们的值与它们的种类包关联起来。
UDDI 还另外提供了一个机制，供值集用来与 UDDI 注册中心进行集成，以验证企业或服务正在正确关联和注册它们的值。提供者可以部署一个验证服务供 UDDI 在值集代码被发布之前使用。




回页首
当 UDDI 注册中心接收到一个对已选择的、带有外部验证服务的分类法的引用时，这个引用将向适当的外部服务发布一条 validate_values 消息。这使得外部用户能够对给定的种类系统的使用进行调整。通常的用法是验证那个特定的类别值在给定的分类法中存在（检查所提供的 keyValue 属性值）。对于某些分类法和标识符来说，提供验证服务的一方可能根据在消息中传送的标识符或任何可能使用被传送的数据的其他种类的上下文检查对某些方的值的使用进行进一步的约束（请参阅参考资料中的程序员的 API 的链接）。
调用 validate_values 的 UDDI 注册中心的实现将传送 businessEntity、businessService 或 tModel 元素作为这个调用的唯一自变量。这与正在 save_business 、 save_service 或 save_tModel API 调用中被传送的数据相同。同一类型的多个元素会被一起传送。
（请参阅参考资料以获得链接），以 UDDI V2 模式编写的 SOAP:Body 中的 validate_values API 语法如清单 2所示。





回页首
Speed-start 验证服务有助于确保发布到 IBM UDDI 测试注册中心的实体包含可以访问的 Web 服务。每当接收到要发布这样一个实体（该实体包含一个对 developerWorks 分类法 tModel 进行引用的种类包）的请求时，IBM UDDI 测试注册中心就会对 Speed-start 验证服务进行调用。验证服务然后会对在实体中提供的所有 SOAP 端点和 WSDL 文档进行检查，检查它们在万维网（World Wide Web）上能被访问。
Speed-start 验证服务是 UDDI V2 规范中描述的 UDDI V2 validate_values API 的实现。
请求中的实体必须首先将验证传送到 Speed-start 验证服务，包含对 developerWorks 种类系统进行引用的发布请求才会成功。developerWorks 种类系统的关键字在 IBM Web 服务工具中构建，或者也可以通过发出一个需要 IBM UDDI 测试注册中心上的种类系统的 find_tModel 请求找到。对 developerWorks 种类系统的引用在实体中的出现形式如下面的 XML 片段（请参阅清单 3）所示：
... ... /categoryBag>
测试注册中心通过递交一条包含 validate_values 请求的 SOAP 消息来调用 Speed-start 验证服务。那些请求包含一个关于 businessEntity 实体、businessService 实体或 tModel 实体的列表。验证服务将会对所有包含 Speed-start tModel 分类类别的实体进行验证。
如果实体中包含的所有 URL 在万维网上都可以访问的话，那么就可以认为这个实体是有效的。如果某个 URL 被确定为无效，那么验证服务将会把一个包含错误代码和消息的响应发送回测试注册中心。这样，UDDI 发布请求便没能成功，并将来自验证的错误代码和消息返回给发布者。否则，如果验证成功，那么将会有一个成功响应被发送到测试注册中心，UDDI 发布请求便成功了。




回页首
Speed-start 验证服务是作为一个 Web 服务来实现的。Web 服务是一个自我描述的、独立的、模块化的应用程序逻辑单元，它能够通过因特网连接为其他应用程序提供一些功能。应用程序会通过 Web 协议和数据格式（如 HTTP 和 XML）访问 Web 服务，而无需担心每个 Web 服务是如何实现的。
验证服务会对 UDDI V2 validate_values API 进行实现。这个实现使用 Java servlet 来处理 validate_values 请求。servlet 是在 Web 服务器（如 WebSphere Application Server）中运行的 Java 程序。servlet 对来自 Web 客户机的请求进行接收和响应，这通常通过 HTTP 进行。
实现提供 validate_values API 的服务有几种方法。通过使用从 AXIS 生成的 WSDL2Java 代码，会生成 UDDI 模式的数据类型和一个接口，它们是实现具体的 validate_values API 的基础（请参阅参考资料以获得链接，了解有关 WSDL2Java 的信息）。根据传送到代码生成器的命名参数，所生成的验证值代码会与下面的清单 4中的代码相似。
// An interface will be created, for which a concrete implementation can be written: public interface UDDI_ValueSetValidation_PortType extends java.rmi.Remote { public uddi.DispositionReport validate_Values(uddi.Validate_Values body); }
使用这个工具的好处是接口引用的数据类型都被创建为 Java 类，作为代码生成的一部分。在运行时，每当 validate_values API 被调用时，这些数据类便被 AXIS 实例化和填充。作为 Java 数据结构的一个示例，这里是一个 uddi.vs. Validate_Values 对象，它不带有所有的 get/set 方法，如清单 5所示。
public class Validate_Values implements java.io.Serializable { private uddi.AuthInfo authInfo; private uddi.BusinessEntity[] businessEntity; private uddi.BusinessService[] businessService; private uddi.BindingTemplate[] bindingTemplate; private uddi.TModel[] tModel; private uddi.PublisherAssertion[] publisherAssertion; ...
使用 WSDL2Java 工具使得无需显式地处理 SOAP、HTTP 或数据类型映射便可以对服务进行快速开发。 validate_values 服务的具体实现将遍历每个数据类型数组并对一些数据进行搜索，这些数据将在最高级别实体（即 businessEntity、businessService、bindingTemplate、tModel 或 publisherAssertion）的上下文中进行验证。
另外一个不使用完整的 SOAP 引擎便可实现验证服务的方法是创建一个 Java 类，这个 Java 类继承由 J2EE 提供的抽象类 HttpServlet。由于 UDDI API 只需要对 HTTP Post 请求作出响应，所以 Validation 服务只实现 doPost 方法。清单 6显示了对此进行演示的某个样本代码。
public class ValidatorService extends HttpServlet implements DefaultHandler { protected boolean insideOverviewURL; protected StringBuffer overviewURL; protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, java.io.IOException { // Get the input stream InputStream input = req.getInputStream(); // Read the XML request from the input stream // Parse the XML request using SAX and a registered listener // to examine specific elements, or use a DOM parser // to create a full document boolean validURLs = true; try { SAXParser parser = new SAXParser(); parser.setContentHandler(this); InputSource is = new InputSource( input ); parser.parse( is ); // Perform some contextual validation // Get the output stream } catch (SAXException e) { validURLs = false; } OutputStream output = resp.getOutputStream(); output.setContentType("text/xml;charset=UTF-8"); // Print the response to the output stream if (validURLs) // Print the SOAP message with E_success report output.write(UTF8_SUCCESS_RESPONSE_BYTES); else // Write the SOAP message with E_invalid value output.write(UTF8_INVALID_RESPONSE_BYTES); } ... // DefaultHandler methods for SAX parsing public void startElement(String uri, String localName, String qName, Attributes attributes) throws SAXException { if (localName.equals("overviewURL")) { insideOverviewURL = true; overviewURL = new StringBuffer(); } } public void characters(char[] ch, int start, int length) throws SAXException { if (insideOverviewURL) { overviewURL.append(ch, start, length); } } public void endElement(String uri, String localName, String qName) throws SAXException { if (insideOverviewURL { insideOverviewURL = false; // Throw an exception that will cause parsing to stop // on any inaccessible overviewURL if (!validateURL(overviewURL.toString())) throw new SAXException("Invalid overviewURL"); } } }
这个服务使用 Xerces 对 XML 请求进行解析，并对请求中与 Java 对象表示相关的部分实例化，以进行验证。在以上实例中，只检查了那些带有 XML 元素本地名称“overviewURL”的实体。在完整的验证服务中，检索整个消息，以查找包含 Speed-start tModel 分类类别的 UDDI 实体，并且所有的 URL 都会得到验证。以下清单 7中的代码片段演示了如何验证 URL 在因特网上是可访问的。
private boolean validateURL( String urlString ) { boolean valid = true; try { URL url = new URL( urlString ); URLConnection connection = url.openConnection(); connection.connect(); } catch ( MalformedURLException exception ) { valid=false; } catch ( IOException exception ) { valid=false; } return valid; }
由于这个实现在每次实体包含一个对 developerWorks 分类法进行引用时被调用，因此，对包含引用那个分类法的服务的查询应得到注册中心数据的一个子集，它是因特网可访问的 Speed-start 社区的一部分。




回页首
通过使用任何感知 UDDI 的工具（这些工具需允许将 developerWorks 种类系统添加为服务的一种属性）都可以将 Web 服务发布到 Speed-start 社区。WebSphere Studio 中的 Web 服务浏览器被预先配置为包含了 developerWorks 种类系统。从发布者和查询者的角度来看，使用外部检查或验证的种类系统与使用 UDDI 中的任何其他种类系统来区分数据没有什么不同。
通过示例，请考虑一下 developerWorks 上的文章“Ask the magic eight ball”中强调的 Magic 8 ball Web 服务（请参阅参考资料）。这个 Web 服务在因特网上作为一个演示被托管，并且使用 WSDL 在以下 URL 中得到描述：http://dwdemos.alphaworks.ibm.com/axis/services/urn:EightBall?wsdl。
要将这个 Web 服务注册为 Speed-start 社区的一部分，只需要知道这个 WSDL 文件的 URL 以及这个 WSDL 文件和服务端点都已在因特网上被托管。
使用 Web 服务浏览器进行发布可以从 WebSphere Studio 中的 File => Export... 菜单访问。在出现的对话框的第一个页面中选择 Web Service 作为导出目的地。在第二个页面中选择 IBM 测试注册中心，如图 1所示。

下一步是要创建有关提供该服务的企业（即提供者）的信息，请选择抓屏中 Actions 部分的 publish 按钮，如图 2所示。

在出现的页面上，填入用户帐户信息（帐户可以在 https://uddi.ibm.com/testregistry/registry.html 获得）以及企业（即服务提供者）的名称和描述。
下一步（也就是最后一步）是提供服务信息并添加种类条目，表明应该将它们作为 Speed-start 社区的一部分进行验证。这一步通过在 Actions 部分选择 publish service 按钮来完成，如图 3所示。

当表单出现时，请选择 Advanced 选项，输入一个名称以及 WSDL 文件的 URL，如图 4所示。

要指明这个服务将成为 Speed-start 社区的一部分，您可以添加恰当的分类法，这需要先添加一个种类，然后从 type 下拉框选择 dwCommunity 并单击 Browse...（请参阅图 5），然后从分类法浏览窗口选择 Speed-start。在输入这个信息之后，请单击 Go，在经 Speed-start 验证服务验证为因特网可访问的之后，这个服务将会被发布。

若要使用浏览器查找所有已被 Speed-start 验证服务验证的服务，请选择 find 操作，如图 6所示。

当查找页面出现时，请从 Search for 框选择 Services，再选择 Advanced 作为搜索类型，然后添加 Speed-start 的种类值（如发布步骤所示）并单击 Go...
左手边的结果将是一个作为 Speed-start 社区的一部分提交的 Web 服务的列表，如图 7所示。





回页首
本文对分类法进行了概述，并概述了如何将分类法和由 UDDI 注册中心调用的验证服务一起使用以提供一个社区或按照特定于种类系统的标准被屏蔽的结果集。Speed-start 社区是一个关于上下文的验证服务的强大功能的简单示例，这种功能大大增强了查询（针对引用特别种类或标识符系统的数据）的数据结果的质量。使用本文提供的信息可以开发能大大增强 UDDI 注册中心的结果（如服务质量或引用服务）的服务。
从 developerWorks 上的Speed-start Web services获取您需要创建和部署 Web 服务的每个工具。
查找更多关于“内置”分类法系统的信息。
请阅读Web 服务的发布与发现的 UDDI4J 一节（PDF 格式）。
获取更多有关程序员的 API的信息。
请下载UDDI V2 模式。
欲了解有关 WSDL2Java 的详细信息，请参阅Axis Reference Guide。
请阅读Ask the magic eight ball，Doug Tidwell 著（ developerWorks，2003 年 1 月）。
 

 

Matt Rutkowski 在 IBM 的 Emerging Technologies Group 工作，他现在致力于 IBM 的统一描述、发现和集成（UDDI）版本 3 的实现。他是计算机图形和着色方面的狂热爱好者，也是俄亥俄州引以为荣的前成员（即 2002 年国家大学橄榄球锦标赛主办方的七叶树州人）（注：七叶树州人是美国俄亥俄州人的别称）。您可以通过mrutkows@us.ibm.com随时给 Matt 发送电子邮件。

 

Andrew Hately 在 IBM 的 Emerging Technologies Group 工作，现在他致力于 UDDI 版本 3 的实现和 IBM UDDI 商业注册中心（http://uddi.ibm.com/）的工作。他还在 OASIS UDDI 规范技术委员会（OASIS UDDI Specification Technical Committee）中代表 IBM。您可以通过hately@us.ibm.com与 Andrew 联系。

 

Robert Chumbley 在 IBM 的 Emerging Technologies Group 工作，现在他致力于自动发音开发工具（Self-Voicing Development Kit，SVDK）的工作。他过去两三年中致力于 IBM UDDI 商业注册中心的开发工作。在此之前，他毕业于 THE university in Texas，该校也称为 Texas A&M。您可以通过chumbley@us.ibm.com与 Robert 联系。