内容：
SOAP消息示例
XML Schema建模
WSDL服务描述
UDDI服务发布
总结
参考资料
作者简介
相关内容：
交互界面，Web服务定义的核心
实战Web服务
基于Web服务的应用、解决方案和开发平台
什么是Web服务?
为什么需要Web服务?
WSDL: 描述你的Web服务
UDDI 注册信息的数据模型
柴晓路 (fennivel@uddi-china.org)
Chief System Architect
2001年9月20日
本文是架构Web服务的系列文章的第六篇，也是最后一篇，文本以前文为基础，在前文的应用实例的基础上，考察了发布Web服务界面的整个过程：XML Schema建模、WSDL发布和UDDI注册。通过本文，大家可以详细具体地了解各个XML和Web Service的系列规范在Web Service的发布时所起的左右，对Web Service技术也将有一个深入的理解。
在前文中，我已经介绍过，Web服务是通过SOAP消息调用的，通过WSDL进行界面描述的，以及通过UDDI进行公共注册发布的。在前一篇文章中，我已经介绍了如何进行SOAP API的消息定义，那么在本文中，我将单把save_category提出来，看看在具体的实现上，应当如何对这个消息使用W3C XML Schema进行建模，如果使用WSDL将基于该消息调用的Web服务进行规范描述并交付调用者，以及如何将这个Web服务连同它的WSDL规范化描述文件一起发布到UDDI注册中心中去。希望大家能通过本文的实例讲解，在本系列的最后完整地了解Web服务的工作原理和相关技术规范的作用。
本文所引用的资源主要包括两类，一类是Web服务的技术资源网站，包含了大量Web服务的技术信息，另一类是Web服务“stack"系列技术规范，他们是一个整体的技术体系，包括UDDI、SOAP、WSDL、XML Schema, XML等。本文的最后给出了这些资源的链接，有兴趣的读者可以通过这些资源链接找到所需的内容。
SOAP消息示例
以下是一个save_category的调用例子，在例子中使用了SOAP HTTP Binding(使用的SOAP规范的版本是1.2)，假设目标Web服务被部署在www.sagitta.com，而调用的Web服务的入口位置将是http://www.sagitta.com/catalog/。
在这个消息中，将在一个现有的category中添加一个新的category和一个新的product。
POST /catalog HTTP/1.1
Content-Type: text/XML; charset="utf-8"
Content-Length: nnnn
SOAPAction: "http://www.sagitta.com/catalog/"
Host: www.sagitta.com
……
该调用消息的返回消息可能是：
HTTP/1.1 200 OK
Content-Type: text/XML; charset="utf-8"
Content-Length: nnnn
从中我们可以看到在save_category和categoryList两个元素后面都带了一个XMLns的修饰"http://www.sagitta.com/schema/"。这URI唯一表示了该元素及其所有子元素的的命名空间。同时通过这个URL可以获得这些元素的Schema定义。
使用W3C XML Schema描述的XML文档的模式定义在整个Web服务的技术系列中处于一个支持工具的地位。W3C XML Schema是任何类型的XML文档的建模工具。在Web服务体系中，无论在SOAP消息的表示上，还是在WSDL的界面描述上，XML Schema都是不可缺少的重要工具和底层支持。
下面我将从XML Schema开始，针对save_category这个消息(同时也对应一个服务入口)逐一介绍如何为我们的XML消息进行XML Schema建模，如何使用WSDL将save_category这个服务入口进行界面描述，然后将这个入口发布到UDDI注册中心中去。
XML Schema建模
XML Schema的文件后缀是.xsd文件，一个XML Schema中的定义通常分为两部分，型(Type)定义和元素(Element)定义。下面我们结合save_category具体的XML Schema定义来说明如何使用XML Schema来实现模式定义。
在下面的XML Schema文档中，型定义包括：compliantSpecBag，featureBag，parameter，parameterBag，product和category六个类型，而元素定义为save_category这一个元素。
save_category的XML Schema描述定义：(完整的XML Schema文档是：sagitta.xsd)
以上是XML Schema的文件头。
在这段Schema描述中，描述了compliantSpecBag这个元素类型，任何使用compliantSpecBag类型的元素可以包含的元素是specification，这个元素可以出现0次到无穷次(无限制，事实上不可能出现无穷次)，而specification这个元素中包含一个属性specificationKey，该属性是必须的，同时类型为字符串(xs:string)。xs这个命名空间是W3C XML Schema 2001的命名空间(namespace)。
在这里，描述了featureBag这个元素类型，任何使用featureBag类型的文档元素可以包含的子元素是feature，而feature元素能够出现0次到无穷次(无限制，事实上不可能出现无穷次)。该元素的内容的类型是字符串(xs:string)。
这里首先描述了parameter这个元素类型，任何使用parameter类型的文档元素可以包含的子元素有两个keyName和keyValue，它们都是必须出现的子元素，同时仅可出现一次。他们的类型也都是字符串(xs:string)。然后描述的是parameterBag元素类型，任何使用parameterBag类型的文档元素可以包含的子元素是parameter，而这个子元素的类型是先前定义的parameter(在XML Schema中，类型名和元素名的域空间是正交的，不需要考虑任何的名字重复问题)，parameter元素出现的次数可以是从0次到无穷次。
这里描述了product这个元素类型，任何使用product类型的文档元素可以包含的子元素是name、description、compliantSpecBag、featureBag、parameterBag。name和description元素的类型都是xs:string。而compliantSpecBag、featureBag、parameterBag的类型大家通过查看这断XML Schema定义也可以很清楚地发现是引用了前面定义的这些类型定义。任何使用product类型的文档元素还有两个必须出现的属性productKey和parentCategoryKey，这是两个字符串(xs:string)类型的属性值，分别表示了自身元素的键值和父辈category的键值。
这是category元素类型的描述，任何使用product类型的文档元素可以包含的子元素是name、description、category和product。name和description元素的类型都是简单类型xs:string。而category是一个递归元素，引用了自身这个元素类型。而product的元素类型则是前面描述好的product类型。任何使用product类型的文档元素还有两个必须出现的属性categoryKey和parentCategoryKey，这是两个字符串(xs:string)类型的属性值，分别表示了自身元素的键值和父辈category的键值。
这是在这个Schema文档中唯一的一个元素定义，元素save_category是一个复合类型，它的元素可以有authInfo和category。其中authInfo是一个base64编码的字符串，而category则是一个可以出现0次到无限次的类型为category的子元素。我们不难发现元素定义和类型定义的基本机制是一样的，事实上，我们完全可以将这段定义拆分成两段，一段为类型定义，一段为元素定义，下面给出这个等价实例，希望有助于对Schema的理解。
那为什么要采用第一种方法，而不使用第二种方法呢，原因也很简单，由于整个Web服务相关的消息Schema中，诸如category、product、featureBag、compliantSpecBag、parameterBag这些元素都可能被复用，因此定义成类型比较合适，而save_category是一个单一的消息，不可能被其他元素复用，因此就直接定义成了元素。
最后，我给出对应本节描述的save_category元素的Schema定义的Schema图示来结束本小节。
Figure 1. SOAP API Schema图示
WSDL服务描述
对SOAP API消息完成Schema建模之后，一方面这个数据模型可以由SOAP Interface来使用，当发生具体调用时可以使用这个数据模型来除了传入的参数并生成传出的参数。同时，利用这个数据模型，我们可以生成相应的WSDL描述，从而将这个Web服务的接口文档发布给使用者，该接口文档是具备被程序自动处理的能力的。
以下是WSDL文档详细的定义：(完整的WSDL文档是: sagitta.wsdl)
targetNamespace="http://www.sagitta.com/wsdl/savecategory.wsdl" XMLns:tns="http://www.sagitta.com/wsdl/savecategory.wsdl" XMLns:myxs="http://www.sagitta.com/schema/" XMLns:soap="http://www.w3.org/2001/06/soap-envelope" XMLns="http://schemas.XMLsoap.org/wsdl/"> 这是WSDL文件的文件头，其中的import元素指明在这个WSDL文件中，types系统是由http://www.sagitta.com/schema/save_category.xsd文件具体描述，在这里仅仅是将其导入。 这里定义了两条消息：save_category消息，在前面的Schema建模中已经完整地创建了根元素的结构定义。其中myxs是这里使用的命名空间(namespace)，命名空间的具体定义在文件头上出现。而categoryList将会对应save_category消息的返回消息，在Schema建模中没有表现，在这里我也仅列出一个元素名，相信大家在看了本文的前半部分以及本系列的前一篇文章之后，会很清楚如何来定义。 这部分定义了服务访问点的调用模式的类型，表明这个入口类型是请求/响应模式，请求消息是save_category，而响应消息是categoryList。 encodingStyle=" http://www.w3.org/2001/06/soap-encoding"/> encodingStyle=" http://www.w3.org/2001/06/soap-encoding"/> 这部分将服务访问点的抽象定义与SOAP HTTP绑定，描述如何通过SOAP/HTTP来访问按照前面描述的访问入口点类型部署的访问入口。其中规定了在具体SOAP调用时，应当使用的soapAction是"http://www.sagitta.com/catalog/"，而请求/响应消息的编码风格都应当采用SOAP规范默认定义的编码风格" http://www.w3.org/2001/06/soap-encoding "。
这部分是具体的Web服务的定义，在这个名为catalogService的Web服务中，提供了一个服务访问入口(其实还有很多，不过在这里因为演示的原因，仅仅介绍了一个)，访问地址是"http://www.sagitta.com/catalog/"，使用的消息模式是由前面的binding所定义的。
UDDI服务发布
在前一节中，我们已经通过使用WSDL这个工具将Catalog Service这个Web服务进行了结构化地描述。为了使更多的潜在用户能够发现这个Web服务，同时也为了加强这个Web服务的互操作能力和灾难恢复时的连接保持能力，我们需要使用UDDI SDK将这个Web服务注册到UDDI注册中心中去。
假设我们之前已经注册了一个businessEntity，叫做www.sagitta.com，一个在线服务提供商，这个businessEntity的键值是"434554F4-6E17-1342-EA41-36E642531DA1"，那么我们要在这个businessEntity下注册一个businessService，以用于描述前面的Catalog Service。同时需要成立的假设是我们也预先注册了一个Service Type(tModel)，这个tModel描述了我们这个需要发布的Web服务的调用规范，具体内容是前面我定义的这个WSDL文档，在UDDI中，注册的是描述的链接。
businessService注册的SOAP消息如下，其中使用了Microsoft的test.uddi.microsoft.com站点，因此authInfo中可以填入测试用的udditest。
通过上述的API调用，我们就已经把这个服务注册进了UDDI注册中心，其中bindingTemplate的accessPoint是服务的入口，而overviewDoc中的overviewURL是WSDL文档的访问位置。
潜在的使用者可以通过查询UDDI注册中心找到这个Web服务，通过overviewURL中保存的URL找到服务的描述，然后通过accessPoint所指定的访问地址来访问这个服务。
当发生紧急服务崩溃的时候，Web服务可能被迁移到另一台主机上，IP地址，甚至是访问的URL都可能有很大变化，此时原先的集成的连接将不再工作。但是由于UDDI注册的存在，我们可以通过自动化的程序手段来解决这个问题，使得类似的服务灾难恢复的过程非常迅速。
具体的流程一般是：
当恢复的服务启动后，自动去更新UDDI注册中心上的数据，将访问入口修改到新的URL位置;
连入的客户端系统当发现无法访问最终服务的时候，将会定期去查询UDDI注册中心，看看新的BindingTemplate数据和本地缓存的有没有差别，如果有的话，就下载到本地，重新建立服务绑定，完成服务连接的迁移。
总结
到这篇文章为止，如何架构Web Service这个系列就将告一段落，在整个系列中，从为什么要有Web服务开始，到什么是Web服务，Web服务的开发工具，对Web服务作了一个概念上的全面介绍。然后以一个具体实例来介绍Web服务的构建模式和各种Web Service "stack"技术的具体应用。希望这个系列对大家理解和接受下一代的应用包装模式Web服务有一个全面的帮助。