现在的位置: 首页 > 综合 > 正文

使用 UDDI 的 Web 服务描述和发现(第一部分)+(第二部分)

2013年08月08日 ⁄ 综合 ⁄ 共 16450字 ⁄ 字号 评论关闭
使用 UDDI 的 Web 服务描述和发现(第一部分) 
Karsten Januszewski
Microsoft Corporation 
2001年10月3日

查看和下载本文的源代码(英文)。

简介
到目前为止,At Your Service 专栏已经介绍了如何建立 Web 服务的实际案例:从最初的设计文档到业务关联,直至最终的部署。下一步就是要考虑如何发布 Web 服务,以便感兴趣的客户能够轻松地发现该服务并将其应用到自己的应用中。现在已经有了实现这种要求的发现机制:通用说明、发现和集成 (UDDI),这是业界支持跨技术、跨平台的 Web 服务发现的第一步。

At Your Service 的作者诚恳地邀请我为专栏撰文,介绍 UDDI 及其注册步骤,我非常乐于接受这项工作。首先我将从技术和业务两方面来介绍 UDDI 的含义。随后我将讨论一下 UDDI 和 Web 服务说明语言 (WSDL) 之间的关系。最后,我将带您体验 UDDI 的注册过程,并介绍一些充分发挥 UDDI 潜力所需考虑的问题。在下一期专栏,即本文的第二部分中,我将介绍 At Your Service 小组是如何充分利用 UDDI 的。

UDDI - Web 服务的全球注册表
UDDI 是一个公共的注册表,旨在以一种结构化的方式来保存有关各公司及其服务的信息。通过 UDDI,人们可以发布和发现有关某个公司及其 Web 服务的信息。这些数据使用标准的分类法进行分类,因此可以按分类来查询信息。最重要的是,UDDI 包含有关公司服务的技术接口的信息。通过一套基于 SOAP 的 XML API 调用,用户可以在设计时和运行时与 UDDI 进行交互以发现技术数据,从而调用和使用这些服务。通过这种方法,UDDI 可以用作基于 Web 服务的软件系统的基础结构。

为何使用 UDDI?为何需要这种注册表?当我们面对具有数千甚至数百万个 Web 服务的软件系统时,将面临以下的严峻挑战:

如何发现 Web 服务? 
如何按照某种合理的方式分类信息? 
对本地化有什么影响? 
对专用技术有什么影响?如何保障发现机制的互操作性? 
当应用依赖于某项 Web 服务时,如何在运行时与该发现机制进行交互? 
UDDI 的出现正是为了应对这些挑战。为了解决这些问题,许多公司,其中包括 Microsoft、IBM、Sun、Oracle、Compaq、HP、Intel、SAP 以及三百多家其他公司(请参阅 UDDI: Community(英文)以获得这些公司的完整列表),共同制定了一种基于开放式标准和非专用技术的规范。该规范的 Beta 版于 2000 年 12 月发布,正式产品于 2001 年 5 月推出。它是一个全球业务注册表,建立在多个运营商节点上,用户可以通过这些节点免费搜索和发布信息。

通过 Web 服务的这种基础结构,现在就能够以一种通用的、与供应商完全无关的方式找到有关 Web 服务的数据,而且数据一致并且可靠。使用可扩展的分类系统和标识,用户可以进行精确的分类查询。运行时 UDDI 集成可以被合并到应用程序中去。因而大大繁荣了 Web 服务软件环境。

工作原理
UDDI 数据存放在运营商(即承诺运营一个公共节点的公司)节点上。这种公共节点遵循 UDDI.org 组织管理的规范。目前已经建立了两个遵循 UDDI 规范版本 1 的公共节点:一个属于 Microsoft;另一个属于 IBM。HP 也承诺将建立一个遵循规范版本 2 的节点。数据寄存运营商之间必须能通过安全通道复制数据,从而为整个 UDDI 云团提供数据冗余。将数据发布到一个节点上后,通过复制,就可以在另一个节点上发现这些数据。目前,每隔 24 小时就进行一次复制;在将来,由于有更多的应用程序要依赖 UDDI 数据,复制的时间间隔还将缩短。

值得一提的是,对于数据寄存运营商实现其节点的方式,不存在一些专用的要求,只要节点遵循 UDDI 规范即可。例如,Microsoft 的节点 http://uddi.microsoft.com/default.aspx(英文)完全用 C# 写成,并运行于 .NET Beta 2 公共语言运行时环境下。其代码基础充分利用了 .NET 系统类提供的本地 SOAP 支持和序列化。在后端,Microsoft 运营商节点使用 Microsoft® SQL Server 2000 作为其数据仓库。而 IBM 使用其他技术来运行其节点!但是,这两个节点的行为是相同的,因为它们都遵循相同的一套基于 SOAP 的 XML API 调用。客户端工具可以和这些节点进行无缝的交互操作。因此,UDDI 公共云团是一个最佳方案,它展示了 XML Web 服务模型如何跨异类环境进行工作。

为了了解 UDDI,下一步我们来看看 UDDI 中存储的数据及其存储结构。UDDI 相对来说是轻量的,它被设计为“注册表”,而不是“储备库”。两者之间的差别很微妙,但却很重要。注册表将用户重定向至资源,而储备库则完全是一个信息库。我们以 Microsoft® Windows® 注册表为例:它包含基本设置和参数,但最终把应用程序引导至资源或二进制代码。基于 Prog ID 搜索 COM 组件时,将引导至一个 Class ID,然后通过 Class ID 再引导至二进制代码本身所在的位置。

UDDI 的行为与之类似:与 Windows 注册表一样,它依靠全局唯一标识符 (GUID) 来搜索并定位资源。UDDI 查询最终指向一个接口(.WSDL、.XSD 和 .DTD 文件等等),或指向其他服务器上的实现(例如 .ASMX 或 .ASP 文件)。UDDI 因此可以回答以下问题:

“已经发布了哪些基于 WSDL 并是为指定行业建立的 Web 服务接口?” 
“哪些公司已经为其中一个接口写好了实现?” 
“目前提供的 Web 服务(以某种方式分类)有哪些?” 
“某个公司提供了哪些 Web 服务?” 
“如果要使用某个公司的 Web 服务,需要与谁联系?” 
“某个 Web 服务的实现细节是什么?” 
WSDL 和 UDDI
WSDL 已成为 Web 服务协议堆栈的重要组成部分。因此,有必要掌握 UDDI 和 WSDL 如何协同工作,以及每个协议如何解决接口和实现这两个相对的概念。WSDL 和 UDDI 都是为清楚说明抽象的元数据和具体实现之间的关系而设计的,了解为什么要这么划分是理解 WSDL 和 UDDI 的基础。

例如,WSDL 明确区分消息和端口:消息(Web 服务所需的语法和语义)始终是抽象的,而端口(调用 Web 服务的网络地址)始终是具体的。在 WSDL 文件中不需要提供端口信息。WSDL 可以只包含抽象的接口信息,而不提供任何具体的实现数据。这样的 WSDL 文件被认为是有效的。这样,WSDL 文件便从实现中分离出来。

其重要意义之一在于:一个 WSDL 接口可以有多个实现。这种设计允许不同的系统为同一接口编写自己的实现,从而保证系统之间能进行对话。如果三个不同的公司实现了相同的 WSDL 文件,一个客户端软件根据这个 WSDL 接口创建了代理/存根代码,那么这个客户端软件就可以使用相同的代码基础与所有这三个实现进行通信,只要更改访问点即可。

UDDI 通过 tModel 的概念描绘了抽象和实现之间的这种区别。tModel 结构(“技术模型”的简称)代表了技术指纹、接口和元数据的抽象类型。使用 tModel 的必然结果是绑定模板,它是一个或多个 tModel 的具体实现。在绑定模板内,要为 tModel 的特定实现注册访问点。如同 WSDL 架构允许分离接口和实现一样,UDDI 也提供了相似的机制,因为 tModel 可以独立于引用它的绑定模板而单独发布。例如,某标准化组织或行业组织可能为特定行业发布规范接口,然后多个公司可以为该接口编写实现。因此,各个公司的实现都需要引用同一个 tModel。WSDL 文件是 UDDI tModel 的完美示例。

用 UDDI 进行注册
发布到 UDDI 是一个比较直接的过程。第一步是确定在 UDDI 上为公司及其服务建立模型所需的基本信息。之后便可以进行实际注册。这可通过基于 Web 的用户界面或编程两种方法完成。最后测试您的注册条目以确保注册正确,并且在不同类型的搜索和工具中都能按要求显示。

步骤 1:为 UDDI 条目建立模型
考虑上述数据模型,在建立 UDDI 条目之前应准备好几个关键数据。

确定 Web 服务实现所需使用的 tModel(WSDL 文件)。
与开发 COM 组件类似,开发 Web 服务时可以使用现有的接口,也可以使用自己设计的接口。如果 Web 服务基于现有 WSDL,则需要确定该 WSDL 文件是否已经在 UDDI 上注册。如果是,就需要记录其名称和 tModelKey,这是注册 WSDL 文件时 UDDI 所生成的 GUID。

另一方面,如果 Web 服务所基于的 WSDL 文件尚未在 UDDI 上注册,就需要准备创建一个新的 tModel 来代表这个接口。此 tModel 应具有统一资源标识符 (URI) 格式 (MyCompany-com:SampleWebService-interface:v1) 的名称,并指向 WSDL 文件所在的位置。

如果 Web 服务是 Microsoft&reg; Visual Studio&reg; .NET 服务,则可以使用 .ASMX 文件(也就是:<http://www.mycompany.com/SampleWebService.asmx?wsdl>)中的查询字符串来生成 WSDL 说明。但是,Visual Studio .NET 生成的 WSDL 文件与调用 Web 服务的访问点紧密耦合在一起,如果 Web 服务接口有多个实现,访问点可能就不适用了。如果不希望 WSDL 文件有多个实现,这就不是问题。 

如果需要,可以用多种语言确定公司的名称和简介,以及公司 Web 服务的主要联系方法。
UDDI 支持 xml:lang 名称空间,它允许公司用多种语言提供公司简介。另外,UDDI 还允许列出联系方式,包括电子邮件、电话和地址信息。联系列表用于列出公司内与 Web 服务相关的资源。例如,如果有人想要使用您的 Web 服务,并需要联系相应的业务关系经理,应该联系谁?使用公司的 Web 服务时,有关技术问题和谁联系?该联系人也应该列出。 

为公司确定适当的分类和标识。
通过 Microsoft UDDI 节点 http://uddi.microsoft.com/default.aspx(英文)浏览当前支持的 UDDI 分类法。当前支持的分类法有北美行业分类系统 (NAICS)、通用标准产品和服务代码 (UNSPSC)、ISO 3166、标准行业分类 (SIC) 和 GeoWeb 地理分类。请选择一种最适于您的公司的分类。 

确定公司通过 UDDI 提供的 Web 服务。
下一步,确定公司要在公共 UDDI 节点上注册的 Web 服务。这项服务有多个访问点吗?是否要给使用此 Web 服务的客户提供其他必需的参数和信息?

注意,在 UDDI 上注册 Web 服务并不意味着每个人都有访问权。可以为 UDDI 注册表条目依次设置安全、授权和身份验证。仅知道 Web 服务的存在并不意味着就可以实际调用该服务。在授权访问 Web 服务之前,公司之间通常需要进行一些额外的交流。 

为服务确定适当的分类。
如同可以将公司分类一样,也可以将 Web 服务分类。因此,公司可能按商业级别被分类为 NAICS: Software Publisher (51121),而其旅馆预约 Web 服务的服务级别可能被分类为 NAICS: Hotels and Motels (72111)。 

步骤 2:注册 UDDI 条目
在完成建模之后,下一步就是注册您的公司。您需要获取一个可访问 UDDI 注册表的帐号,这不能通过编程来完成,因为必须要同意“使用规定”声明。Microsoft 节点使用 Passport 进行验证,您需要获取一份 Passport (http://www.passport.com/Consumer/default.asp) (英文)来完成注册。

这里有两种选择:使用 Microsoft 节点提供的 Web 用户界面,或者通过使用 SOAP API 调用节点自身以编程进行注册。如果不希望更改注册表条目,或条目相对简单,则使用 Web 用户界面就足够了。但是,如果希望频繁更新,或条目很复杂,请使用 Microsoft UDDI SDK 制作注册过程的脚本。另外,由于没有针对其他语言对 Microsoft 用户界面进行本地化,所以如果想利用 UDDI API 的多语言功能,需要通过编程的方法进行注册。

注意:您可以在模拟环境中练习注册过程,地址是 http://test.uddi.microsoft.com/default.aspx(英文),这是实际投入使用节点的复本。这对于在正式使用之前熟悉注册过程很有帮助。
使用 Microsoft 的 Web 用户界面
使用 Microsoft 的 Web 用户界面来注册是一个相对直观的过程。首先导航至管理员页面 http://uddi.microsoft.com/administer.aspx(英文)。登录后,将显示注册 tModel 和公司的选项。下面是继续操作时需要了解的几个事项:

在注册服务之前,确保将 WSDL 文件注册为 tModel,因为在以后的过程中会需要 tModel。 
将 WSDL 文档注册为 tModel 时,应该使用“UDDI 类型分类法”对 tModel 分类。至少应将 WSDL 分类为“Specification for a Web Service”(wsdlSpec)。
使用这种分类方法,可以确保 tModel 的分类符合“Using WSDL in a UDDI Registry”最佳实践文档(英文)的原则。因为 tModel 能包含对 WSDL 文件以外的文档的引用,所以给 tModel 提供一些分类是很重要的。很多工具(例如 Visual Studio .NET)靠这些分类来缩小查询的结果集。 

将 WSDL 接口注册为 tModel 后,需要给公司业务添加相应的联系信息以及分类信息。只要您认为合适,可以添加任意多的分类。 
继续添加要通过 UDDI 公开的 Web 服务。因为服务可以有多种实现,所以需要给每个添加的服务添加一个绑定。对于每个绑定,需要提供 Web 服务的访问点,即 <http://www.mycompany.com/SampleWebService.asmx>。 
每个绑定都需要为所支持的接口创建一个引用。Microsoft UI 将这些作为“规范签名”来调用。规范签名就是包含 WSDL 接口的 tModel。Microsoft UI 会提供一个屏幕,允许您基于其 URN 来搜索 tModel。这个 tModel 可以是在步骤 1 中注册的,也可以是别人注册的 WSDL 文件的 tModel。 
最后,系统会显示选项,要求提供一个关于特定 Web 服务的概述文档的 HTTP 地址,以及任何相关的实例参数。 
使用 Microsoft UDDI .NET SDK 编程进行注册
注册过程的另一种选择是通过编程进行注册。使用 Microsoft UDDI SDK 可以轻而易举地完成该过程。您必须使用 Web UI 获取一个 UDDI 帐号。完成该任务后,其余过程就交给脚本来处理。首先,下载并安装 UDDI SDK,地址是 http://www.microsoft.com/downloads/release.asp?ReleaseID=30880(英文)。然后,使用 Visual Studio .NET 创建一个新的 C# 控制台应用程序。添加一个对 Microsoft UDDI SDK dll 的引用,其默认安装位置是 C:/Program Files/Microsoft UDDI SDK/VS7/Microsoft.Uddi.Sdk.dll。然后,在代码顶部添加一些名称空间引用:

using Microsoft.Uddi;
using Microsoft.Uddi.Binding;
using Microsoft.Uddi.Business;
using Microsoft.Uddi.Service;
using Microsoft.Uddi.ServiceType;

在 static void Main (string[] args) 函数中添加下列代码:

// 您最好先运行这个程序,在 https://test.uddi.microsoft.com/publish
// 上进行注册测试
Publish.Url = "https://uddi.microsoft.com/publish";
Publish.User = "您的帐户";
Publish.Password = "************";

这将为您的帐户建立身份验证。下一步,添加以下代码将 WSDL 文件发布为 tModel:

// 创建 tModel
SaveTModel stm = new SaveTModel();
stm.TModels.Add();
stm.TModels[0].Name = "此处插入 URN";
stm.TModels[0].Descriptions.Add("zh","此处插入说明");
stm.TModels[0].OverviewDoc.OverviewURL = "此处插入 WSDL 的 URL";
// 下一行是给 tModel 正确分类所必需的
stm.TModels[0].CategoryBag.Add 
( "uddi-org:types",
"wsdlSpec",
"uuid:c1acf26d-9672-4404-9d70-39b756e62ab4" );

string sTModelKey = "";

// 发送到 UDDI
try
{
   TModelDetail tmd = stm.Send();
   sTModelKey = tmd.TModels[0].TModelKey;         
}
catch (UddiException ue)
{
   Console.WriteLine ( ue.Message );
   return;
}
catch (Exception e)
{
   Console.WriteLine ( e.Message );
   return;
}

成功保存后,UDDI 将生成一个新的唯一的 tModelKey,以后在 Web 服务的绑定中需要用到它。下一步,创建公司条目:

// 创建公司
SaveBusiness sb = new SaveBusiness();
sb.BusinessEntities.Add();
sb.BusinessEntities[0].Name = "此处插入公司名称";
sb.BusinessEntities[0].Descriptions.Add("zh","此处插入说明");

// 创建公司服务
sb.BusinessEntities[0].BusinessServices.Add();
sb.BusinessEntities[0].BusinessServices[0].Name = "此处插入服务名称";
sb.BusinessEntities[0].BusinessServices[0].Descriptions.
Add("zh","此处插入服务说明");

// 创建绑定模板
sb.BusinessEntities[0].BusinessServices[0].BindingTemplates.Add();
sb.BusinessEntities[0].BusinessServices[0].BindingTemplates[0].
Description.Add("zh","此处插入绑定说明");
sb.BusinessEntities[0].BusinessServices[0].BindingTemplates[0].
AccessPoint.Text = "此处插入访问点";
sb.BusinessEntities[0].BusinessServices[0].BindingTemplates[0].
AccessPoint.URLType = Microsoft.Uddi.Api.URLTypeEnum.Http;

// 创建 tModel 实例信息
sb.BusinessEntities[0].BusinessServices[0].BindingTemplates[0].
TModelInstanceDetail.TModelInstanceInfos.Add();
sb.BusinessEntities[0].BusinessServices[0].BindingTemplates[0].
TModelInstanceDetail.TModelInstanceInfos[0].Descriptions.
Add("zh","此处插入说明");
// 使用上面的 tModelKey 字符串
sb.BusinessEntities[0].BusinessServices[0].BindingTemplates[0].
TModelInstanceDetail.TModelInstanceInfos[0].TModelKey = sTModelKey;

// 发送到 UDDI
try
{
   BusinessDetail bd = sb.Send();
   // 显示 xml
   Console.WriteLine ( bd );
}
catch (UddiException ue)
{
   Console.WriteLine ( ue.Message );
   return;
}
catch (Exception e)
{
   Console.WriteLine ( e.Message );
   return;
}

此时,WSDL 定义和公司信息都已经保存到了 UDDI 中。通过传递适当的键,以后您可以随时编辑这些条目。

步骤 3:在 UDDI 中搜索条目
在 UDDI 中注册条目后,进行以下三种检查是比较有意义的。第一,使用 Microsoft Web 用户界面,根据名称和分类来搜索您的公司,确认其存在于返回的结果集中。第二,打开 Visual Studio .NET 并确保它是通过“Add Web Reference”对话框显示的。如果没有显示,则可能没有正确使用上述的 uddi-org:types 分类法对您的 tModel 进行分类。您应该能将 Web 服务添加到工程中,并基于 WSDL 文件生成代理代码。第三,等待 24 小时,您的条目将复制到 IBM 节点上,这可以通过其 UI 来查询,地址是 https://www-3.ibm.com/services/uddi/protect/find(英文)。

总结
UDDI 和 WSDL 作为免费的规范,可以帮助建立基于 Web 服务的软件系统。WSDL 提供了与供应商无关的正式方法来定义 Web 服务,这样便可以实现下一代远程过程调用。而 UDDI 提供了一种广泛的、标准化的基础结构,允许人们去描述和发现 Web 服务。这两个标准的结合将带来一个繁荣的 Web 服务生态系统。

下周的专栏将向大家介绍 At Your Service 小组是如何在 UDDI 中为 收藏服务(英文)进行建模和注册的

使用 UDDI 的 Web 服务描述和发现(第二部分) 
Scott Seely
Microsoft Corporation 
2001年10月17日

简介
在上一个专栏中,Karsten Januszewski 已经带我们访问了 Microsoft&reg; UDDI 小组。Karsten 概要介绍了 UDDI 的概念、用途和使用方法。在本文中,我们将介绍如何使用 Microsoft UDDI 注册表注册“Cold Rooster 收藏服务”。鉴于我们以前从未使用 UDDI 进行过注册,现在就让我们从头讲起。

用 UDDI 进行注册
由于从未在 Microsoft UDDI 站点(英文)注册过 Cold Rooster,所以首要任务就是在该站点创建一个帐户。注册帐户要求使用 Passport 登录。登录后,您可以设置 UDDI 电子邮件联系地址,将它连接到您的 Passport 帐户或其他地址上。我选择的地址是 crooster@microsoft.com,因为在我的小组里不止我一个人在使用 UDDI。原来 Cold Rooster 咨询公司需要使用电子邮件时,我们已经创建了这个电子邮件帐户,这看来是个明智的选择。

注册屏幕还会提示输入其他联系信息,例如注册者的姓名、联系电话和通信地址。要完成注册,您需要接受“使用规定”协议。请参阅 Terms of Use(英文)。

在注册表中填好联系信息,并接受“使用规定”后,UDDI 站点将向您发送一封电子邮件,确认您的联系地址。单击邮件中的链接,就可以管理您的 UDDI 帐户了。管理工作涉及到向注册表中添加公司数据、发布 tModel 以及编辑注册详细信息。图 1 显示了管理页面。

此主题相关图片如下:
按此在新窗口浏览图片

图 1:UDDI 管理页面

在 UDDI 中添加公司
在 Microsoft UDDI 站点建立帐户后,下一步就是向 UDDI 注册表中添加 Cold Rooster 咨询公司。我们可以通过 Web 页面注册公司,也可以使用 .NET SDK 或 COM SDK 调用 UDDI API 来注册公司。我选择使用 UI,因为我想一次注册成功。如果将来要经常更改接口内容,就应使该过程自动化以减少错误发生率。将公司添加到注册表中,就可以使用户根据我们的公司和所提供的 Web 服务的类型来找到我们。要在 UDDI 注册表中添加 Cold Rooster 咨询公司,请单击管理页面(图 1)中的“Add a new business”链接。第一页将要求提供公司名称和说明。对于 Cold Rooster,我输入:

Name:Cold Rooster 咨询公司
Description:MSDN Architectural Samples 小组使用的虚拟公司
在 UDDI 注册表中添加公司后,现在可以添加其他信息了:

Contacts:可以帮助客户解决各种业务问题的人。我们将 MSDN Architectural Samples 小组的不同成员添加到联系人列表中。 
Services:该公司要提供的 tModel(WSDL 文件)。我们在 UDDI 条目中添加了“帐户”、“登录”和“报表”三种 tModel。 
Identifiers:代表本公司的唯一的数据。例如,公司的注册序号。因为 Cold Rooster 没有上述数据,所以没有填写。 
Business classifications:标识公司所在的位置以及公司的业务。Cold Rooster 咨询公司位于美国的华盛顿州。 
Discovery URL:提供了可以查找公司详细信息的位置。 
首先完成简单的项目,最后保存服务。

在 UDDI 中添加联系信息
这非常简单。就象填写其他地址表格一样,只要填写不同联系人的一般信息就可以了。潜在用户可以根据说明和使用注释来联系贵公司,以便申请使用 Web 服务的许可、获得支持或咨询与业务相关的其他事项。图 2 显示了我的联系信息表格的外观。

此主题相关图片如下:
按此在新窗口浏览图片

图 2:详细的联系信息页

对公司进行分类
大多数公司可根据其业务范围分类。对实体进行分类时,UDDI 分类有多种方法,包括:

North American Industry Classification System (NAICS-1997)(北美行业分类系统) 
Universal Standard Products and Services Codes (UNSPSC-7.03)(通用标准产品和服务代码) 
ISO 3166 Geographic Taxonomy(ISO 3166 地理分类) 
Standard Industrial Classification (SIC-1987)(标准行业分类) 
GeoWeb Geographic Classification(GeoWeb 地理分类) 
UDDI Types Taxonomy(UDDI 类型分类) 
除了 UDDI 类型外,Cold Rooster 在所有分类中都进行了注册。之所以未在 UDDI 类型分类中注册公司,是因为它是专用于对 tModel 和服务信息进行分类的。 
要了解需要注册的内容,就必须知道 Cold Rooster 的业务范围和地理位置。Cold Rooster 咨询公司位于美国华盛顿州的雷德蒙德。它提供基于工程的辅助性的计算机咨询服务。而且,它擅长基于 Windows 和 Internet 的开发。知道了这些,我们需要分别按照六种分类方案为该公司正确分类。表 1 显示了按照每种分类方案对该公司进行分类的情况。分类方案 分类 
NAICS 541511: Custom Computer Programming Services 
541512: Computer Systems Design Services 
 
UNSPSC 81.11.16.07.00: Programming for C or C++ 
81.11.16.03.00: Programming for HTML 
81.11.16.01.00: Programming for Microsoft&reg; Visual Basic&reg; 
81.11.16.12.00: Programming or Proprietary Languages(也包括 C#) 
81.11.21.06.00: Application Service Providers(提供 Web 服务) 
81.11.21.03.00: World Wide Web (WWW) site design services 
 
ISO 3166 US-WA (Washington, USA, World) 
 
SIC 7371: Computer programming services 
7372: Information retrieval services 
 
GeoWeb 地理分类 518816 (Redmond, Washington, USA, North America, World) 
 

表 1:UDDI 分类示例

公司分类完毕。下一步是添加三个 tModel。

添加 tModel
如果您没有读过上周的文章,那么请注意,tModel 就是一个类型模型。对于 Web 服务来说,tModel 通常就是 WSDL 文件的同义词。它们使用同样的方法定义 Web 服务所使用的类型以及消息和操作定义。给定一个 tModel,就可以知道何种 Web 服务操作是由实现该 tModel 的实体实现的,以及如何访问这些操作。将 WSDL 文件注册为 tModel,是因为这些 tModel 最终可能有多个实现。

服务器端的收藏 Web 服务包括三项 Web 服务:登录、帐户和报表。“登录”Web 服务允许被授权者登录并得到一个标记。使用该标记,被授权者可以访问“帐户”和“报表”Web 服务中的其他方法。要添加 WSDL 文件,需要将其部署在一个可以通过公共 Internet 访问的服务器上。这里也需要使用 UDDI 分类。

要添加 tModel,请在管理页面(图 1)上单击“Add a new tModel”。接着需要添加一些 tModel 的基本信息:名称、说明以及 WSDL 文档所在的位置。完成后,将 tModel 分类为 WSDL 文档,并将信息发布到 UDDI 注册表中。这真是轻而易举。图 3 显示了“登录”tModel 要填写的详细信息。

此主题相关图片如下:

图 3:“登录”tModel 的详细信息

在下一个屏幕上,可以添加服务分类和公司标识。这里的数据和在公司信息中输入的数据相同。作为服务分类,我们只使用了 UDDI 分类。可以通过单击一系列链接来指定这些信息:

用于 tModel 的类型 
Web 服务的规范 
WSDL 中说明的 Web 服务的规范 
我在注册 Cold Rooster 收藏服务时,对于 Logon.WSDL、Account.WSDL 和 Report.WSDL 就采用了这些步骤。完成 UDDI 注册后,注册表中的这些信息才可用。 
定义服务
tModel 注册完毕后,仍然需要添加服务以声明存在这些服务。要添加服务,请回到管理页面,这次您会看到您的公司已列在“Add a new business”(图 1)中。选择您的公司并滚动到“Services”。在此处单击“Add a Service”。在第一页填写服务的详细信息。对于“登录”Web 服务,我填写的内容如下:

Name:登录 
Description:验证被授权者并提供访问标记 
完成后,再次将服务分类为“WSDL 中说明的 Web 服务规范”。接着将该服务绑定到已注册的“登录”tModel。在以下所示的“Define a new binding”字段中,我填写的内容如下:

Access point:https://Coldrooster.com/SSF/Logon.asp 
URL type:http 
Description:Cold Rooster 咨询公司登录 Web 服务的端点 
要完成这一步,必须将服务与“收藏 Web 服务:登录 tModel”联系起来。在“Specification Signatures”下,选择“Add specification signature”。要按名称查看模型,请输入“收藏 Web 服务”。这将调用收藏服务所保存的全部三个 tModel。选择“收藏 Web 服务:登录”并按下“Continue”。一个 Web 页将显示出来,您需要在上面编辑关于端点的详细信息。我填写的内容如下:

Edit specification signature; Description:收藏 Web 服务的 Cold Rooster 实现:登录 tModel 
Instance details; Parameters:http://msdn.microsoft.com/library/?url=/library/en-us/dncold/html/ssfapiref.asp?frame=true 
Instance details; Description:API 引用文档 
Overview document; Document location:http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncold/html/ssf1sec.asp 
Overview document; Description:服务器端收藏安全信息 
填写完毕后,再次单击“Continue”。接着,在返回到主公司数据视图并向 UDDI 注册表发布全部信息前,可以查看输入的所有关于登录服务的信息。对“帐户”和“报表”Web 服务重复这一过程。

查找数据
根据 GeoWeb 分类,今天(2001 年 10 月 8 日)只有一家公司列在雷德蒙德中:Cold Rooster 咨询公司。使用 ISO 3166 分类再搜索一次。这次找到了九家公司。其他分类将产生其他的统计结果。对于其他的分类方案,其结果通常需要占用好几页。

现在数据是可以发现的,因此对存储收藏 URL 的 Web 服务感兴趣的人,在理论上可以找到并使用 Cold Rooster 解决方案。对于使用 Microsoft&reg; Visual Studio&reg; .NET 的用户,使用 UDDI 查找 Web 服务并将其添加到自己的工程中将更加简单。

第一次遇到“Add Web Reference”对话框(“Project”|“Add Web Reference”)时,会显示一个对话框,允许您通过 Microsoft UDDI 服务器来查找 Web 引用(也称为 WSDL 文件)。用于 Visual Studio 的端点是 http://uddi.microsoft.com/visualstudio/。当告诉该端点查找所有以“cold”开头的公司时,它只找到了我注册的三个 Web 服务:帐户、登录和报表。可以在此处(英文)查看此次查询的结果。要将 Web 引用添加到“登录”Web 服务中,只要单击“Logon”以扩展该节点,然后单击“Favorites Web Service: Logon”查看 WSDL。在这里,单击“Add Reference”,就可以登录到收藏 Web 服务了。

如果到现在您还没有获得收藏服务授权,请到 Favorites Service Admin Console(英文)申请一个。在 15-30 分钟内您将收到一个密码。要使用 Visual Basic 连接到“登录”Web 服务,则代码编写非常简单:

Sub Main()
    Dim svc As New com.coldrooster.www.Logon()
    System.Console.WriteLine(svc.Logon("许可证持有者", "密码"))
    System.Console.WriteLine("按 Enter 键退出")
    System.Console.ReadLine()
    svc.Dispose()
End Sub

代码将显示 GUID 标记,供用户访问收藏 Web 服务中可用的其他方法。编写其他方法的代码也同样简单。

总结
通过使用 UDDI 注册公司、自定义 tModel 和 Web 服务,您可以帮助世界各地的开发人员找到您的 Web 服务。UDDI 注册表允许您发布的不只是 Web 服务端点和公司数据。使用 UDDI 的用户也可以使用该界面查找 Web 服务文档和示例。Microsoft UDDI 注册表是免费使用的。我们鼓励用户使用此注册表注册您的 Web 服务和公司。请花一些时间来熟悉 http://uddi.microsoft.com(英文)。您可能试图查找 Cold Rooster 咨询公司的信息,并浏览它以查看所有可用的信息。最后一点,现在可是使用 Visual Studio .NET 来连接收藏服务并进行实际操作的绝佳时机。

下一次,将由客座专栏作家 Allen Wagner 主持。Allen 将讨论处理大型 SOAP 消息的技术。

 

--------------------------------------------------------------------------------

At Your Service

Scott Seely 是 MSDN Architectural Samples 小组的成员。除了那里的工作以外,他还通过 Prentice Hall 出版了两本书:《SOAP: Cross Platform Web Service development Using XML》(SOAP:使用 XML 进行跨平台 Web 服务的开发)和《Windows Shell Programming》(Windows Shell 编程)。他还编写和维护一个小型的基于 C++ 的 SOAP 库(位于 http://www.scottseely.com/soap.htm)。该库根据 LGPL 协议对外发布。

抱歉!评论已关闭.