“Web服务探查语言”（Web Services Inspection Language（WS-Inspection））和“通用描述、发现和集成”（Universal、Description、Discovery、Integration（UDDI））规范处理的都是与Web服务发现有关的问题。即使如此，由于设计它们时所期望的目标并不相同，因而表现出的特征也不同，必须先对其进行评估才能应用技术。本文通过同个人信息发现进行类比描述了Web服务发现空间，并说明可以如何联合使用这两种规范以满足多种请求。

　　介绍

　　解决与服务发现和服务描述检索有关的问题是Web服务成功的关键。尽管对于小型的或紧密集成的环境并不绝对需要，但如果更复杂的集成模型，如“面向服务的体系结构”（Service-Oriented Architecture）［1］要成功部署，这些解决方案就变得至关重要。

　　发现的概念可以有多种解释。发现模式可以分为两大类：有重点的和无重点的。“有重点的”发现是积极搜索一个特定目标，一条特定信息，或同时搜索两者的结果。它可能是指，例如，要对已知的一方就其必须提供的数据进行查询，或者是如果已知数据特征，要搜索能够制造这样的数据的供应商。“无重点的”发现是接收到未请求的信息，或者为了检索任何可能出现的可用数据，而遍历有可能无限的空间的结果。

　　除发现机制支持的模式以外，还可以根据其它两种属性来描绘其特性：信息传播点的选择和与发现过程有关的成本。在发现过程中，可以直接从信息源／始发者或第三方提取信息。直接从源检索信息提高了信息准确的可能性，但间接提取信息能提供利用第三方提供的额外服务的机会，而且并不要求原始来源总是可用或易于定位。与发现技术有关的成本也是变化的。在某些环境中存储及显示信息的成本比在其它一些环境中要高得多。

　　根据上面所列的属性，可以构造一种分类法从而对发现技术及其支持机制进行比较和对比。总之，可以根据如下标准对发现机制进行分类：

　　·支持哪些发现模式呢？该机制是只支持有重点的发现模式，只支持无重点的发现模式，还是二者的组合呢？如果是二者的组合，对每类模式的支持分别达到何种程度？
　　·传播点在哪里？一般情况下，发现的信息是直接来自信息源／始发者还是通过第三方呢？
　　·哪些是与发现机制有关的开销呢？有没有与存储和显示要发现的信息有关的基本成本，如果有的话，其重要程度如何呢？注：这是信息／基础设施供应商支持发现机制的成本；可以假定消费这些信息的成本差异可?S略不计。

　　在本文的第2节中，我们描述了几种用于个人信息发现的机制，并根据上面的分类法将其分类。在第3节中我们把同样的分类法应用于Web服务空间，并描述了在哪些地方适合使用UDDI和WS-Inspection机制。

　　发现示例

　　电话号码和地址形式的个人信息定位提供的是关于一系列相关的发现过程的一个有趣示例。最简单的系统是口头交流；我们遇到的人可能简单而直接的把他们的电话号码和地址告诉我们。所发现的数据通常直接来自信息的所有者／始发者，这一机制几乎没有任何开销。在这种发现类型中，使用的是部分有重点、部分无重点的使用模式。例如，在有重点的情况下，我们可以问别人的电话号码，但是，我们并不常要求别人指明电话号码属于谁。类似的，在无重点的情况下，也许我们不必要求某人提供信息他就会把电话号码告诉我们，但是通常情况下我们不会动脑子向随机人群要电话号码。

　　个人信息发现的下一更高级别涉及一条结构化信息的交流，如名片或信息手册。和口头交流的情况一样，这使部分有重点、部分无重点的用法模式更为方便，而且信息通常直接从所有者／始发者传给请求者。名片或手册提供相关信息的聚合，但是并不指定信息本身应该如何格式化；格式取决于要传递的那条特定信息。这种形式的发现同前面一种的主要区别就在于这个聚合；由于在单次交流中所允许传递的信息比用别的方法可能传递的更多，它提供的功能更为强大。由分组提供的额外语义信息也许还无法在每条独立的数据内被捕获。聚合所带来的收益其实付出了很高的代价；创建和维护聚合的文档带来了额外的开销。

　　个人信息发现的最高级别是目录辅助系统或可搜索的在线“黄页”。目录辅助提供高级查询及信息检索功能，而且它所支持的有重点的发现模式的范围比其它系统广阔的多。为了支持更强大的有重点发现，这些系统不是只聚合单一来源的信息，而是从多种来源聚合信息。这使得操作员和目录辅助系统的成本比前两种机制更高，通常由第三方提供信息的目录服务这一事实也是如此。虽然增加了开销，但目录辅助系统提供了一些在口头或简单的聚合环境中不易完成的高价值功能。

　　总之，所描述的个人信息发现机制具有如下特征：

　　·直接通信（语音）

　　支持一些有重点的和无重点的发现模式。
　　直接从信息源／始发者开始传播。
　　无开销。

　　·简单的聚合标记（名片）

　　支持一些有重点的和无重点的发现模式。
　　直接从信息源／始发者开始传播。
　　中等开销。

　　·目录辅助（操作员）

　　支持大量有重点发现模式及一些无重点的发现模式。
　　通过第三方传播。
　　高额开销。

　　上面所示的分类并不详尽，但是它的确提供了一个有用的示例，据此，才能把Web服务发现涉及到的机制联系起来。

　　Web服务发现

　　Web服务信息发现同个人信息发现非常类似，用一个或多个WSDL或其它描述文档提供“联系”（即端点）信息来代替电话号码或物理地址。以下两节依据UDDI和WS-Inspection机制所表现出的特征简要描述它们是如何适合介绍中所描述的分类法的。最后一节描述如何依据需要的功能和操作上的限制来应用这两者。

　　3.1 UDDI特征

　　“通用描述、发现和集成”（Universal Description Discovery and Integration（UDDI））规范［2］使用集中式模型处理与Web服务发现有关的问题；创建一个或多个资源库存放与企业及其提供的服务有关的信息。根据资源库直接发布与服务和企业的相关信息有关的请求和更新。此外，UDDI为存储的描述信息部分规定了特定的格式，而且为了方便进行高级搜索，还假定其它的描述信息也将在这个系统中存储／注册。

　　就上面所述的个人信息发现背景而言，UDDI环境非常类似于目录辅助供应商或可搜索的在线“黄页”系统的环境。同目录辅助和其它第三方供应商一样，UDDI系统所基于的系统化资源库提供了包括高级搜索功能在内的许多高级功能。这使其非常适合于为有重点的发现模式提供便利，包括帮助请求者迅速定位潜在的通信伙伴。在较低的程度上，UDDI还能够通过浏览资源库方便一些无重点的发现模式。但是，为了提供高级功能，UDDI需要部署并维护一定数量的基础设施，因而提高了操作成本。此外，除非服务描述只在UDDI内存储，否则，保持不同版本同步就要花费一定的成本。这些额外的成本并不一定会对信息所有者造成直接影响，这取决于目录供应商所采用的商业模型。例如，“通用商业注册中心”（Universal Business Registry）采用的模型就使信息所有者不必承担这些成本。

　　3.2 WS-Inspection特征

　　“Web服务探查语言”［3］依赖全分布式模型提供与服务相关的信息；可以把服务描述存在任何位置，通常情况下直接向提供该项服务的实体提出检索信息的请求。WS-Inspection规范并没有给服务信息规定任何特定格式；它依赖包括UDDI在内的其它标准来定义描述格式。WS-Inspection规范还依赖现有的Web技术和基础设施提供发布和检索其文档的机制。

　　就介绍中所描述的个人信息发现背景而言，WS-Inspection机制同名片及其它的简单信息聚合文档非常类似。如同其它机制一样，WS-Inspection文档是非常轻量级的，易于构造，易于维护。WS-Inspection机制通过提供利用现有的协议，直接从服务提供点传播服务的相关信息的能力，从而实现对单个目标执行有重点发现。但是，由于其分散性本质，如果通信伙伴未知的话，WS-Inspection规范无法提供良好的机制执行有重点的发现。不同于名片和手册，WS-Inspection规范通过提供一系列的约定使其文档易于定位，并允许服务供应商以前摄的方式显示这些文档，从而为大量无重点发现模式提供支持。同其它支持发现机制的简单聚合一样，创建及维护该聚合会带来少量成本开销。

　　3.3完善画面

　　在本文结束之前，必须提及同个人信息发现空间中的口头交流类似的第三种机制。该机制直接从其来源对描述文档、WSDL及其它相关文件进行检索。同口头交流的情形一样，该机制的确不会引起任何开销，但它却只支持部分有重点和无重点发现模式。

　　总之，本文所描述的Web服务发现机制具有下列特征：

　　·直接检索描述（语音、FTP和HTTP GET）

　　支持一些有重点和无重点的发现模式。
　　直接从信息源／始发者开始传播。
　　无开销。

　　·简单的聚合发布（WS-Inspection）

　　支持一些有重点的发现模式和大量无重点的模式。
　　直接从信息源／始发者开始传播。
　　中等开销。

　　·高级目录（UDDI）

　　支持大量有重点的发现模式和一些无重点的模式。
　　通过第三方传播。
　　信息所有者有中等开销；目录供应商开销较大。

　　同名片和目录辅助系统一样，UDDI和WS-Inspection规范处理发现问题空间内不同范围的问题，而且以不同的折中集合为特征。UDDI提供较高级的功能，但它也付出了提高复杂程度的代价。WS-Inspection规范为了维持较低开销而采用了较低级别的功能。据此，应当把这两种规范看作是互补的技术，根据具体情况，或一同使用，或单独使用。例如，可以基于WS-Inspection文档执行“Web爬虫程序”所得出的结果向UDDI资源库传递数据。同样，当请求者检索引用资源库条目的 WS-Inspection 文档时，可以发现UDDI资源库本身。在不要求UDDI提供的高级功能以及约束不允许部署高级功能的情况下，WS-Inspection机制可以提供所需的全部功能。在需要集中管理数据的情况下，UDDI解决方案自己就可以提供最佳方案。不应当把UDDI和WS-Inspection规范看作是提供竞争机制，就象名片和目录辅助服务也不能被看作是竞争传播个人信息一样。