Windows Server 2003 的UDDI服务

Windows Server 2003中所包含的UDDI服务为那些需要在防火墙后端针对XML Web 服务加以运用的应用程序配备一个功能强劲的描述与发现基础架构。这场讲座旨在介绍这对UDDI服务进行规划设计并将其全面集成于Web服务体系结构的具体实现方式。讲座所涉及的主要论题包括：UDDI技术规范概要，Windows Server 2003中的UDDI服务特性祥解，UDDI 应用设计与运行时研讨以及UDDI 内部分类方案重要性。

中文对白：

大家好，我叫Karsten Januszewski，是负责UDDI服务的项目经理，今天将为大家讲述Windows Server 2003的一项新特性-UDDI服务。

我们将深入探究UDDI是什么，它能为我们做些什么，无论在座的各位是站在系统架构、设备或是站在IT的认识角度来看待它。

UDDI作为服务器的一项新特性，我想先从它的缩写讲起：UDDI指统一描述、发现和集成，它是旨在实现Web服务发现的标准化的一项全行业项目。

我们首先从UDDI作为一项标准的角度开始讲述，这样可能会对大家有所帮助，然后再来看Microsoft和Windows Server是如何在操作系统中应用这项标准的。

那么我就先从规范开始，然后以规范结束。 UDDI的全部计划是为了综合解决Web服务搜索问题。Web 服务本身是一种分布式的软件体系结构，它需要某种探索形式来寻找这些服务。

开始采用一种规范来解决这一问题。规范基本上涉及两个方面：一个是描述那些服务、服务供给者以及服务技术信息的一种数据模型。

然后规范阐明了一种API，并用它来实际得到那些服务。它既把服务发布至UDDI目录中，又进行查询以找到这些服务。整个规范是构筑在标准自身之上。因而，UDDI就构筑在Web服务标准、XML、 XSD、 SOAP、 WSDL的基础之上，并使用HTTP作为它的传输协议。

规范最初是由名为UDDI.org 的团体制定，近来被转至OASIS标准化组织，现在由OASIS（技术协会）所有和管理。 3年中，UDDI规范发展了三种版本，分别是版本1、版本2和版本3，这并不令人惊讶。

与UDDI相关的最重要事情或许是：它已被供应商全面采用。规范本身由来自Microsoft, IBM, SUN, Oracle, HP, Compaq, Fujitsu公司的代表所编写，而且其他的公司也为此做出了一些贡献。

这些供应商再根据规范来创建自己的产品。也就是供应商将在标准上进行合作和产品上进行竞争。对所有标准来说，情况都是如此；UDDI当然也不例外。 现在，一旦规范完成，您便可拥有最杰出的UDDI示例，或者是被称作UBR（UDDI业务注册）形式的规范应用。

UDDI这一实例是公共实例，任何人均可使用它来进行发布和查询，同时由许多不同的供应商所支持。

Microsft控制一个节点、IBM控制一个节点，SAP控制一个节点，NTT和日本 Telc目前也控制一个节点。它们每个节点共享位于单一主拷贝拓扑结构下的数据拷贝，允许数据可被完全拷贝。我可以在 Microsoft 的节点上查询数据，并从发布在IBM节点上或其它节点上重新获得数据。

此外，它是完全互通的，所以我可以用 Microsoft的工具来查询 IBM 的节点，因为，基本上它都是以实现Web 服务的一组规范为基础。

Windows Server更引人注目的方面是：用于互联网Web服务探索的这种相同的规范和概念同样适用于企业内部网或外部网上的服务发现。 因而我们把 UDDI视为Windows Server 2003的一个组成部分，并将对UDDI可提供的特性做一番深入探讨。

但在此之前，我先要阐明UDDI在整个 Web 服务体系结构中的位置。了解它在整个结构中的位置是多么重要。

在Web服务体系结构的核心位置，实现 Web 服务的是XML 和XML架构。XML 是一种基于文本的格式，用于创建消息。XML架构是传送和可靠输入XML的一种已知标准化方法。 从这个核心中，我们可获得组成 Web 服务规范的基本集的三种规范。包括SOAP，该规范允许您用标准化的信封在网络中传送消息。

WSDL规范, 它表示服务描述语言，可让您确切地描述一项消息进入和重新返回时的消息参数是什么。

UDDI位于这一堆栈的顶端，如果您要获得 Web 服务，您需要能够找到它们；UDDI便是这样一个场所，您在那里可以对Web服务进行注册也对与之相关的元数据进行注册，这样您就可以查询Web服务，最后进行搜索和使用。

我们值得花点时间来考虑一下 UDDI 数据模型，看看UDDI实际上是如何存贮这些有关 Web 服务的数据。这个模型虽然简单但功能却很强大。许多简单的软件往往具有强大的功能。越复杂的软件， 其成本常常也比较高昂。

UDDI数据模型的简单性在于组成 UDDI 信息存贮的只有四种核心实体。UDDI数据模型能够描述任何一种提供某种类型服务的实体。服务位于它的下层，从逻辑上说，是它的一个'孩子'。

它们是一系列的拥有从零到极限服务的技术提供者。服务是包含绑定的合理实体，绑定是所提供服务的实际技术信息。在此尚待决定的第四种结构叫做 tModels 或是技术模式。

这是把多个绑定和某些公用规范或接口进行联合的一种方法。 您可以把tModel 视为一种外键，例如对于 ooModel 来说，tModel 描述一个接口，在那里，一种绑定会描述此接口的应用。

这里有个例子可以很好地证明。 在一个企业内部，请设想一下服务的供给者是财务部门。且它可提供两种服务，两种软件服务。

一种是新建客户服务，来创建新的客户，一种是客户更新服务。这没什么可惊奇的， 可以设想客户更新服务有多个绑定。这正是 UDDI 吸引人的地方，因为它可容纳不同技术类型的绑定。

它或许包含一项 Web 服务。假如您看到的第一个蓝盒子是由.NET 所有的be .asmx Web服务，它能让您更新客户资料，它指的是一种 WSDL 文件 --- 一种称为WSDL文件的 XML 文件，用来描述如何请求这种网络服务的约定。

但是UDDI也会包含其它的服务信息和绑定类型，比如可能是一个 COBOL 访问点，它是指一个被叫做 COBOL副本的 tModel。 甚至是一个称为类型库的 COM 访问点或DCOM访问点。 这样您将看到这个核心模式是如此简单而强大。

它确实会对数据进行约束。它不仅提供了一种开放的目标层次让您进行数据建模。但同时在如何描述供给者、服务以及如何在特定的单位内描述绑定方面，它又是灵活的。

这一点我在前面已经提到过，但在应用 UDDI 时，值得再次重申。在UDDI相对简短的历史里，了解对UDDI的叙述是非常有趣的。正如我所说，UDDI 的第一次应用，第一次广为人知的应用是在互联网上。约两年前，人们真的那样认为：Web 服务将在互联网上获得大量应用。

快速抓取 Web 上的所有数据并表现为 Web服务， 或者把所有从B2B模式到B2C模式的功能表现为Web 服务应该是Web服务的最佳体现。

这样，就需要把 UDDI 当作目录来对可从互联网上可得到的、数以千计、数以百万的可能的 Web 服务进行管理。

正因为如此，公司在考虑这种Web服务的版本时，认为'它确实很强大也很有意义，但目前看来它却意义不大。'

我们无法确定能为公众提供怎样的 Web 服务； 无法确定网络服务是什么；该怎样保护这些 Web 服务；以及如何利用这些 Web 服务来赚钱。

所以互联网上的Web服务并没有快速盛行，而且UDDI 注册可以在互联上完成。但这些公司会认为：'我们知道这种概念在防火墙后非常有意义，我们也已经在内部网上开发了许多 Web 服务，我们可以使用注册来跟踪它们。'

UDDI 公共注册，我们最终会用到，我们也会在互联网上提供 Web 服务。但现在我们需要在企业内部网上使用 UDDI。 以及在外部网上，在这里我们的商务伙伴可以在此搜寻到专为某个贸易社区或系统提供的网络服务。

现在让大家了解一下 UDDI 可解决的些许问题。如果关注一个企业设法用 Web 服务解决的问题，您会发现事实上他们要解决的是 EAI 问题（企业应用集成），而Web服务对此发挥的力量却非常微弱。

这样，运行某位顾问写于1996年的一些 VB 应用程序的分公司，现在便可以利用那个应用程序，并与运行在完全不同平台上的不同应用程序的数据中心进行对话，以及与海外分公司进行对话等等。

所以公司沿用以前的应用程序，并把它们包装成 Web服务，以实现企业内的集成。从而充分利用现有的体系结构和资产。

现在，请看看我的幻灯片，您会说，'天哪，怎么这么乱'。这并非因为我不善于power point制作，而正是要证明我的观点。如果您坚持继续进行解决方案和体系结构，可能会弄得一团糟。您如何得知 Web 服务的存在？一个分公司如何能利用其他分公司的 Web 服务？开发人员如何了解网络服务的存在？

而且，即便他们知道有 Web 服务，但如何确定该Web 服务真正被IT部门认可，而不单是一种 Web 服务，诸如开发人员手头毫无用处的工作计划之类的。

因而，为一个单位提供大量Web服务并进行管理是UDDI亟待解决的问题。

用UDDI注册您的Web服务并作为中心储存库，在那里我们可以找到这些服务并且可以使用任何工具找到它们，并且我们可以应用已有的体系结构，如同UDDI使用HTTP和XMLWeb服务堆栈一样。 这就是UDDI为企业解决问题的具体方式。

这也是Windows Server 2003支持UDDI的原因所在。当编写Windows 2003说明和计划增加新功能时，我们决定把应用服务器作为Windows Server 2003的核心功能。 XMl Web服务应用服务器的体系结构的核心件就是UDDI。

因而我们把UDDI视为Windows Server操作系统的一项特性。您可以象添加NAT、 DHCP 或终端服务一样，添加这种服务。它是操作系统的核心组件，支持Web服务体系结构。

通过'添加/删除组件'特性来添加该应用，正如我所说的，您可以把三种不同的组件添加到一台设备中。

我不知道您是否能看清幻灯片，但当您在服务器中进行添加/删除组件操作时，会看到自己是怎样把数据库组件添加到UDDI，您可以把Web服务组件添加到UDDI, 或是添加到UDDI的MMC管理控制台。

您可以把所有的组件添加到一个计算机中，或是把其中的一项添加到一个计算机中，这完全取决于您想如何进行安装。如果想在多个计算机内分配UDDI安装，您便可以把它留在一个计算机内。

现在Windows Server 2003 中的UDDI 服务与UDDI 版本1和版本2完全兼容。 这意味着任何兼容V1 和V2的客户端可以与Windows Server 中的UDDI服务对话。这样JAVA 工具包或是PEARL 工具包可与Windows UDDI服务器对话。

我们构筑在.NET framework上，我觉得在此值得一提的是UDDI服务是用C# 构建的，前端是ASP.NET，我们使用了ADO.NET 和全部串行化类。我们应用这种构架，在CLR下运行。 UDDI是真正意义上的Windows Server .NET 特性。

我们还应用IIS 6.0 和 SQL Server 2K 或MSTE ，下面我会讲到。 在此要提到的另一件事情是您在Windows Server 2003上运行的代码库是uddi.microsoft.com 中提供的通用代码库。

前面我提到UDDI的公共节点已经在互联网上运行多年了，现已完成互操作性测试，也进行了大量的性能实验。您可以获得相同的代码库。目前代码库已修整、更新完毕，以备企业使用。但基本上是相同的代码库，因而是可靠的。 正如我提到的，对于服务器中的某些UDDI服务特性，您可以进行具有伸缩性的部署应用，以便仅在一台计算机中使用UDDI。 您还可以把它作为一个Web 场应用，让多个UDDI Web组件指向一个单独的UDDI数据库实例。

对于UDDI服务的最高级版本，您甚至可以建立一个虚拟的SQL 服务器群集来获得最大的冗余。我们在Windows服务器中进行了安全集成，意味着您无需再对UDDI进行任何附加的安全构架。

我们利用AD.。我们使用AD登录来验证使用UDDI服务的用户。 我们有四种角色对现有团体进行划分：1. 读者角色-只允许您读UDDI目录；2. 发布者角色-只允许您读和写；3. 协调人角色-可允许您进行读、写和修改其他人的数据; 4. 管理员角色-允许您做任何事情。

的确，您会看到UDDI服务的初始化很简单、运行快速且相当直观。管理完全通过MMC完成，经常使用Windows的IT管理人员对它都很熟悉。

我们的系统构架基本上是一个3层应用程序，就象您所创建的许多Web服务一样。 UDDI本身就是一种Web服务。我愿意把它视为Meta Web 服务。如果您需要一个轻量级的版本，我们为您提供了数据仓库、SQL Server 2000或者MSDE。

然后我们通过一套组件来体现业务逻辑部分，如我所说，它在CLR下运行，创建在数据仓库里。运行在IIS 6.0下。

我们利用了IIS 6.0 应用池隔离，这是一项重要特性：如果您在包含其他网站的一台计算机中运行UDDI，即使Web 服务器上的某个网站发生故障，您也不必担心UDDI,因为UDDI运行在自己的应用池中。

此外，这是我们所信赖的IIS 6.0 的一个杰出特性。我们还可以使用网络服务账户，它是IIS 6.0中让我们每个人都可使用的一个新账户。

然后我们再通过用ASP .NET所写的一个用户接口--我们待会儿再解释它--或通过XML SOAP API把信息存储起来。这样通过专用API或UI与UDDI相接。我们使用Active Directory 或是NT Security 来完成所有验证和授权。

我们的用户界面令人心动。规范不会教您如何写用户界面，而只规定API。这样对每个供应商来说，如何在UDDI信息模型之上提供用户界面，完全取决于他们自己。

我们正在抓紧时间编写一个全面、细致的用户界面，这样您通过API 层发出的任何查询，也可通过UI 层发出。您可以把任何类型的数据发布到通过API 发布的UDDI 之中。

用户界面还有一些其它特性，即用于协调并允许拥有协调者角色的用户去改变其它用户的数据、查看服务器上统计信息以及在计算机中真正运行UDDI的实例。

我们不光只对用户接口进行口头上的讨论，现在就让我们来看看演示，了解一下UI真正是什么。

一旦您启动UDDI并开始运行，就会从用户界面角度了解您是如何根据 UI与 UDDI进行互动。对开发人员来说，还有许多其他与 UDDI互动的方式。

正如我所说，UDDI的确是适用于开发人员的一种特性或服务，同时开发人员们从各自的开发环境与 UDDI直接互动的能力对UDDI也很重要。

那么在了解之后，如果您考虑用Microsoft提供的某些开发环境，如：Office XP Web 服务工具包，您可以直接从工具包中安装并查询 UDDI。

同样地，如果在Visual Studio .NET 环境下，一位开发人员在编写一种 Web 服务， 他们可以使用 添加 Web引用 特性并再次直接从他们的开发环境中查询到UDDI。

SDK也是我们的特色之一，希望通过API连接UDDI的开发人员可以使用它。 该SDK 是一组类和对象，让您从对象角度来处理UDDI，并获得与XML的完全交互。 因而，基本上它是非串行化版本的API，来处理所有串行化XML。您可以从MSDN中下载它。

我们还提供所谓的工具资源包，它包含某些工具，让您与 UDDI 进行互动来创建分类架构、从UDDI中输入/输出数据，利用命令行配置调用一个 UDDI BOX然后用 XML 文件把它的配置信息存储起来。

因而，如果谈到驱使人们使用UDDI的应用情境，实际上主要有两种。第一种，我们称之为设计时发现，如下所示。 第二种，接着看幻灯片，会看到1号.NET开发人员，他用Visual Studio .NET来创建pricing Web 服务。

准备完毕后，他把它部署到成品数据中心，得到IT部门的支持后，他说："好吧，我把它发布到 UDDI 中，这样其它开发人员也可以得到它。"

然后，这一过程就开始了，他也许会请求某人把它发布到 UDDI 服务器中，也许能自己发布。采用怎样的策略和步骤从UDDI获得数据依公司的具体情况而定。 但是即便手续没问题，UDDI中一个实体指示："这儿有可用的分类为x 的Web服务；这儿说明了使用方法、它的位置以及关于如何使用它的更多文章链接。"

让我们继续进行，现在2号开发者正在编写一个程序，他需要使用pricing Web 服务。然后他前往公司 UDDI 服务器，依据目录或名称进行查询找pricing服务。

他找到了一组，挑出最适合的一项。然后他就可以把它用到自己的程序中，开始把它直接称为Web服务。

这里值得一提的是，UDDI对此却毫不知情。UDDI仅扮演了匹配者的角色，这样，1号开发者和2号开发者可以搜寻彼此的服务，UDDI让该信息增值，却毫不知情。 这便是最普通的、层次1和阶段1的UDDI用法。

另一种与UDDI互动的复合方法我们称之为运行时发现或动态配置。使用这种方法进行发现时，UDDI便不再是毫不知情。

我们来回想一下早期的情况：我们的一个客户端要调用Web服务，设想一下客户端访问Web服务失败。如果那个Web服务的访问点在客户端的采用的是硬编码的形式，那么客户端就得不到响应。

Web服务将会失败并提示发现过程结束。但是，如果客户端知道UDDI，逻辑上，客户端在运行失败时，它会查询UDDI，以寻找是否有一个新的访问点，以及这个备份访问点的位置，并把UDDI作为抽象层或中间层。

他们可以挑取服务的新信息然后在运行时调用备份。这种使用UDDI的方法是一种比阶段2更好的方法，用这种办法您可以让客户端意识到UDDI，并在客户端放置一些编码在运行时与UDDI对话。

这种情况下，从备份到智能客户端有许多种不同的可能性，根据分类信息或其他与Web服务进行对话的元数据来做出决定。

接下来，让我们看看发现过程到底是如何与使用Visual Studio .NET 的UDDI进行工作。这样我们便可了解使用UDDI服务的设计时发现和Windows Server 2003。

接下来我想讲讲UDDI的一个关键特性---分类。我说指的分类是修饰元数据以及把它与 UDDI中不同核心实体进行关联的能力。

请回忆一下，数据模型有供给者服务、tModels 和绑定类型。您可以仅根据不同实体的名称进行UDDI搜索。但这种类型的搜索不够精确，也没用到您想与实体相联的所有类型的元数据

因而，UDDI把重点放在分类概念上：一种创建分类架构并把它们的值与UDDI中的实体进行关联的能力。这样，搜索会更加精确。

它比纯文本搜索更精确，也更集中。我提到分类架构时，所指的是不同值的分类和分级关系。待会儿我们会看到一些例子。

但UDDI的强大之处在于您可以把多个分类架构放置到某一个单独实体上，这样您便能用不同元数据值修饰一个实体，以便能够通过一个不同值的矩阵或公用etrex(?) 进行查询。

分类是UDDI在规范层次的一个特性。 在Windows Server中的UDDI服务，我们已强调了这点。我们已经应用并把重点放在根据目录进行浏览的用户接口上。

我们把重点放在创建自己的定制分类架构以及在计算机中发布分类架构上，类似于Map Point的地理位置分类架构。最后，我们提供了一些管理工具让您去创建、输入、管理和更新它们。

再深入探讨一下，我所讲的分类架构是许多不同的事情。它可能是地理位置分类架构，这样您将根据服务所在位置对其进行分类。

即便它们在东海岸数据中心或欧洲数据中心，您都能通过以企业、部门，以及这些部门相互联系的不同方式为基础的组织层次进行分类。

您可以根据服务水平协议或者说按照SLA进行分类，它可以告诉您哪些Web服务是金牌Web服务，哪些是铜牌Web服务，您就可以基于这些进行不同的操作。

您也可以根据使用情况进行分类，例如，哪些服务是成品Web服务，而哪些仅仅是测试Web服务，这样您就不应该把它用在产品中。

因为有这种分类, 寻求服务的人们可以进行更细小的查询，例如 "请查出所有基于US的Web服务， 或通过合并多个分类架构，查找到具有7X24 SLA并且位于US的服务。"

或者，请找出所有位于US、在成品环境中部署，并且具有7X24 SLA 的服务，而且这些服务部署在财务部门。那么您就能了解到如何使用分类把数据具体化，并在UDDI中兑现。

UDDI如何让数据在网络可用是非常关键的一部分。 当您进行查询服务时，无论在设计时间，或在运行时间，一个运行时的查询可能会抵制基于这些分类信息的UDDI。因而这种Web服务会停止，查询就开始寻找与刚停止的分类类似的其他Web服务。

了解问题最好的办法就是仔细考虑问题本身。那么让我们来看看演示--关于如果创建您自己的分类架构，如何把它们输入到UDDI以及如何使用它们。这个演示实际上使用了资源工具包，该工具包是UDDI服务的附加工具。

所以，这些内容是针对许多不同听众的，我想总结一下UDDI服务对不同的听众有什么样的意义。

对于一位对UDDI服务感兴趣的行政管理官员、CEO，CIO而言等等，他们会说，"我愿意在我们的体系结构中应用Web服务，我认为我们将要使用这些服务，而且UDDI是该体系结构中的核心部件。"

SOAP, WSDL和 UDDI是三位一体的Web服务规范的一部分。CEO或CIO们知道UDDI是在单位中工作的Web服务基础构架的重要一部分。

他们或许会通过UI来查看Web服务是怎么配置的。正如您从演示中看到的，一位CIO会快速通过用户界面浏览UDDI, 看看哪儿发生了什么，以及Web服务是如何应用在部门位中的。

对于组合构架的设计师来说，UDDI是一个真正的集中位置，设计师在其中贯彻企业标准，这样设计师便可提出每个Web服务应该以何种特性信息进行分类。

每个编写Web服务的部门都需要把它们发布到UDDI中。企业内的每个部门需要通过在运行时使用UDDI而让他们的应用程序更加稳定。

关于UDDI如何工作的这些决策和程序正是设计师们在他们的计划中进行规划、制订和所要利用的。因而对于设计师，UDDI将成为总体Web服务结构的一部分。 同时，它是一个可互操作的、不会让开发团体觉得恐慌的部分。我认为对开发单位来说，UDDI就如同"瑞士"这个国家一样，无论对于Java开发人员，VB开发人员， C#开发人员或共享服务的任何人，它都是安全的。

对于开发人员，UDDI是一个可让他们搜寻和发布Web服务的场所。 最后，这将让他们更容易地在网络上找到想要的东西。他们可以利用现有的服务，无需重写已经写过的东西。

他们不用浪费时间来记录这些服务。正如我所说的那样，这已经集成到IDE中了，他们可以与UDDI直观地进行互动。

如果他们在运行时确实利用了UDDI, 最终写出的程序将更加灵活和可靠，这样如果出现问题，应用程序也会很好地重新恢复。 对于IT人员来说，UDDI可安装到所维护的服务器中。而且也是他们查看服务运行情况的一种办法。因而，如果一位IT人员在网络上对Web服务进行分类，就可以使用UDDI作为一种分类方法。

最后，其实最终用户不会知道UDDI的存在。想一下Windows中的注册表，如果最终用户随意修改注册表，系统可能就会出错。UDDI 基本上就是这样一种体系结构，它是最终用户不知道的注册表。但他们每天所用的应用程序却要依赖UDDI，让程序更加可靠。

所以，现在就是开始我们开始行动安装UDDI的时候了。它的安装相对简单。您可以使用MSDE把它安装到单台计算机上，用较低的花费来开始探索UDDI的种种特性。试着在设计时对它进行发现，并鼓励开发人员将Web服务发布到这个实验性的UDDI。

让他们发现这些服务，并开始为您的企业定制分类架构，并最终实现运行时的UDDI先导应用， 让UDDI在Web服务构架中真正扮演核心角色。

您可以浏览microsoft.com/windowsserver2003，以获得更多信息。那里提供了大量有关UDDI配置和规划的文章，重点在构架和IT方面，此外还有MSDN方面的开发资源。 您还可以浏览uddi.microsoft.com，您可以在可以在那里找到公开的UDDI实例。

今天我的讲解到此结束，祝大家使用愉快。谢谢。