理解UDDI

第四个链接是出于测试目的。微软的地址目录中提供很多服务，你可以使用这些服务来学习如何访问和合并程序中的Web services。

现在我们做一个试验：通过第三方链接，查找UDDI业务注册中心。(注意：为了能够使范例正常运行，系统中一定要安装VS.NET。) 点击并连接到微软开发的http://uddi.microsoft.com/visualstudio。这是一个节点，你可以在这一节点中搜索服务类型(比如天气)，提供者(比如XYZ天气服务)，或者在类别方案(categorization scheme)中选择，而类别方案其实就是一个小的UDDI“黄页”集。

在服务名称中输入W%(%类似于*，意味着以w为入口)，我这里获得29种结果──也许你的结果不一样，因为与网络上的站点一样，Web services都是不断变化的。

现在在类别方案列表中选择并点击VS Web服务搜索分类(VS Web Service Search Categorization)。在子类别表中点击日历，然后点击搜索(Search)按钮。你可以看到提供日期/时间或者其它与日历相关的Web服务的很多列表。如果你对其中某一方面感兴趣，点击+就可以展开所有的入口，你可以看到显示很多UDDI数据选项的一个清单，包括：服务描述(Service Description)，绑定(Bindings，查看与服务相关的站点)，访问站点(Access Point，你可以通过这一地址发送一个信息以激活一个特定的服务)，描述(description)，接口定义(Interface Definitions，传递到注册中心的任何参数)。

这里，最重要的数据选项是描述，比如提供美国任何一个地区的地方天气情况。

次要重要的数据选项是访问站点(Access Point)，访问站点等同于一个普通应用程序调用的函数名称。你将给出函数的名称(在本例中为LocalWeather)以及Web service响应。最后，点击接口定义，这里你可以看到，当访问Web service时，你必须提供必要的参数和数据类型，如下所示：

LocalWeather(ZipCode As Integer)

你也可以恢复响应及其数据类型：

Returns: Forecast As String

此时，一些描述被操作完成并清除，而另一些描述并没有被清除。节点上的绝大多数服务只是作为测试而发布，很多服务都是无法正常运行，或者无法访问到。然而，如果你对如何在程序中操作Web 服务感兴趣，你可以练习这些测试服务，而微软开发的这一站点也十分适合于服务的测试操作。

你也可以在Visual Studio IDE中通过一个不同的进程来访问Web服务。选择Help|Show启动页，然后点击Online Resources tab键。点击右面板中链接的XML Web服务。你可以看到查找和注册Web服务的各种选择。

在查找页中，在UDDI产品环境中点击Search选择，然后在种类(Category)下拉式列表中选择Miscellaneous，点击Go就可以查找你感兴趣的服务。而且，你还可以通过点击不同的tab键和链接检查绑定，描述，以及接口的信息。

WSDL的发展走向

有关自描述的概念，包括元数据，发现，以及映象等，都是很时髦的东西。你可以认为UDDI列表(服务描述，尤其是接口描述)的描述部分只是具有理论性，但是你应该完全相信，另一XML派生的语言已经由委员会构建，这也就是WSDL(Web服务描述语言)。WSDL的目的是建立各种规范，通过这些规范可以实现描述错误处理，对象成员，信息，以及Web 服务行为的标准化。

虽然历史以来这种元语言特别地难于实施，但是希望是永远存在的。如果在阅读本篇文章之前你已经阅览了其它的一些UDDI注册的描述，你应该没有任何疑问的注意到，除了被广为接受的WSDL外，还没有其它的Web服务描述的标准。而且，如果你使用.NET来建立Web 服务，.NET可以自动生成WSDL文档。如果你对进一步地探索WSDL有兴趣，可以从W3C(万维网联盟)找到完整的，行话丰富的信息。