内容：
SOAP消息示例
XML Schema建模
WSDL服务描述
UDDI服务发布
总结
参考资料
作者简介
相关内容：
交互界面，Web服务定义的核心
实战Web服务
基于Web服务的应用、解决方案和开发平台
什么是Web服务?
为什么需要Web服务?
WSDL: 描述你的Web服务
UDDI 注册信息的数据模型
柴晓路 (fennivel@uddi-china.org)
Chief System Architect
2001年9月20日
（本文最初由 IBM developerWorks 中国网站发表，其网址是
http://www.ibm.com/developerWorks/cn/）
本文是架构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等。本文的最后给出了这些资源的链接，有兴趣的读者可以通过这些资源链接找到所需的内容。
在这个消息中，将在一个现有的category中添加一个新的category和一个新的product。
POST /catalog HTTP/1.1Content-Type: text/xml; charset="utf-8"Content-Length: nnnnSOAPAction: "http://www.sagitta.com/catalog/"Host: www.sagitta.com<?xml version="1.0" encoding="UTF-8" ?><env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope"> <env:Body> <save_category xmlns="http://www.sagitta.com/schema/"> <authInfo>5Az784kJceHCE982eB</authInfo> <category categoryKey="cb4e17d1-6100-47f6-a532-cd9cbd30c073" parentCategoryKey="ab4e3de1-7865-f2c1-b49a-beccbd21c072"> <name>Consumer Electronics</name> <description>Product Category for Consumer Electronics </description> <category categoryKey="" parentCategoryKey="cb4e17d1-6100-47f6-a532-cd9cbd30c073"> <name>SONY Consumer Electronics</name> <description>Sony's Product Category for Consumer Electronics</description> </category> <product productKey="" parentCategoryKey=" cb4e17d1-6100-47f6-a532-cd9cbd30c073"> <name>DSC-S75 Digital Camera</name> <description>Sony's Brand-New Professional Digital Camera</description> <compliantSpecBag> <specification specificationKey="Key[USB1.1]" /> </compliantSpecBag> <featureBag> <feature>……</feature> <feature>……</feature> </featureBag> <parameterBag> …… </parameterBag> </product> </category> </save_category> </env:Body></env:Envelope>
该调用消息的返回消息可能是： HTTP/1.1 200 OKContent-Type: text/xml; charset="utf-8"Content-Length: nnnn<?xml version="1.0" encoding="UTF-8" ?><env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope"> <env:Body> <categoryList xmlns="http://www.sagitta.com/schema/"> <category categoryKey="cb4e17d1-6100-47f6-a532-cd9cbd30c073" parentCategoryKey="ab4e3de1-7865-f2c1-b49a-beccbd21c072"> <category categoryKey="8933aa50-3aaf-11d5-80dc-002035229c64" parentCategoryKey="cb4e17d1-6100-47f6-a532-cd9cbd30c073" /> <product productKey="89307600-3aaf-11d5-80dc-002035229c64" parentCategoryKey="cb4e17d1-6100-47f6-a532-cd9cbd30c073" /> </category> </categoryList> </env:Body></env:Envelope>
从中我们可以看到在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的文件后缀是.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 version="1.0" encoding="UTF-8"?><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
以上是XML Schema的文件头。
<xs:complexType name="compliantSpecBag"> <xs:sequence> <xs:element name="specification" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="specificationKey" type="xs:string" use="required"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType>
在这段Schema描述中，描述了compliantSpecBag这个元素类型，任何使用compliantSpecBag类型的元素可以包含的元素是specification，这个元素可以出现0次到无穷次(无限制，事实上不可能出现无穷次)，而specification这个元素中包含一个属性specificationKey，该属性是必须的，同时类型为字符串(xs:string)。xs这个命名空间是W3C XML Schema 2001的命名空间(namespace)。
<xs:complexType name="featureBag"> <xs:sequence> <xs:element name="feature" type="xs:string" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>
在这里，描述了featureBag这个元素类型，任何使用featureBag类型的文档元素可以包含的子元素是feature，而feature元素能够出现0次到无穷次(无限制，事实上不可能出现无穷次)。该元素的内容的类型是字符串(xs:string)。
<xs:complexType name="parameter"> <xs:sequence> <xs:element name="keyName" type="xs:string"/> <xs:element name="keyValue" type="xs:string"/> </xs:sequence> </xs:complexType> <xs:complexType name="parameterBag"> <xs:sequence> <xs:element name="parameter" type="parameter" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>
这里首先描述了parameter这个元素类型，任何使用parameter类型的文档元素可以包含的子元素有两个keyName和keyValue，它们都是必须出现的子元素，同时仅可出现一次。他们的类型也都是字符串(xs:string)。然后描述的是parameterBag元素类型，任何使用parameterBag类型的文档元素可以包含的子元素是parameter，而这个子元素的类型是先前定义的parameter(在XML Schema中，类型名和元素名的域空间是正交的，不需要考虑任何的名字重复问题)，parameter元素出现的次数可以是从0次到无穷次。
<xs:complexType name="product"> <xs:sequence> <xs:element name="name" type="xs:string"/> <xs:element name="description" type="xs:string"/> <xs:element name="compliantSpecBag" type="compliantSpecBag"/> <xs:element name="featureBag" type="featureBag"/> <xs:element name="parameterBag" type="parameterBag"/> </xs:sequence> <xs:attribute name="productKey" type="xs:string" use="required"/> <xs:attribute name="parentCategoryKey" type="xs:string" use="required"/> </xs:complexType>
这里描述了product这个元素类型，任何使用product类型的文档元素可以包含的子元素是name、description、compliantSpecBag、featureBag、parameterBag。name和description元素的类型都是xs:string。而compliantSpecBag、featureBag、parameterBag的类型大家通过查看这断XML Schema定义也可以很清楚地发现是引用了前面定义的这些类型定义。任何使用product类型的文档元素还有两个必须出现的属性productKey和parentCategoryKey，这是两个字符串(xs:string)类型的属性值，分别表示了自身元素的键值和父辈category的键值。
<xs:complexType name="category"> <xs:sequence> <xs:element name="name" type="xs:string"/> <xs:element name="description" type="xs:string"/> <xs:element name="category" type="category" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="product" type="product" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="categoryKey" type="xs:string" use="required"/> <xs:attribute name="parentCategoryKey" type="xs:string" use="required"/> </xs:complexType>
这是category元素类型的描述，任何使用product类型的文档元素可以包含的子元素是name、description、category和product。name和description元素的类型都是简单类型xs:string。而category是一个递归元素，引用了自身这个元素类型。而product的元素类型则是前面描述好的product类型。任何使用product类型的文档元素还有两个必须出现的属性categoryKey和parentCategoryKey，这是两个字符串(xs:string)类型的属性值，分别表示了自身元素的键值和父辈category的键值。
<xs:element name="save_category"> <xs:complexType> <xs:sequence> <xs:element name="authInfo" type="xs:base64Binary"/> <xs:element name="category" type="category" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element>
这是在这个Schema文档中唯一的一个元素定义，元素save_category是一个复合类型，它的元素可以有authInfo和category。其中authInfo是一个base64编码的字符串，而category则是一个可以出现0次到无限次的类型为category的子元素。我们不难发现元素定义和类型定义的基本机制是一样的，事实上，我们完全可以将这段定义拆分成两段，一段为类型定义，一段为元素定义，下面给出这个等价实例，希望有助于对Schema的理解。
<xs:complexType name="save_category"> <xs:sequence> <xs:element name="authInfo" type="xs:base64Binary"/> <xs:element name="category" type="category" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:element name="save_category" type="save_category" />
那为什么要采用第一种方法，而不使用第二种方法呢，原因也很简单，由于整个Web服务相关的消息Schema中，诸如category、product、featureBag、compliantSpecBag、parameterBag这些元素都可能被复用，因此定义成类型比较合适，而save_category是一个单一的消息，不可能被其他元素复用，因此就直接定义成了元素。
</xs:schema>
最后，我给出对应本节描述的save_category元素的Schema定义的Schema图示来结束本小节。
Figure 1. SOAP API Schema图示
以下是WSDL文档详细的定义：(完整的WSDL文档是: sagitta.wsdl)
<?xml version="1.0"?><definitions name="catalogService" 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/"> <import namespace="http://www.sagitta.com/schema/" location=" http://www.sagitta.com/schema/save_category.xsd" />
这是WSDL文件的文件头，其中的import元素指明在这个WSDL文件中，types系统是由http://www.sagitta.com/schema/save_category.xsd文件具体描述，在这里仅仅是将其导入。
<message name="save_category"> <part name="body" element="myxs:save_category"/> </message> <message name="categoryList"> <part name="body" element="myxs:categoryList"/> </message>
这里定义了两条消息：save_category消息，在前面的Schema建模中已经完整地创建了根元素的结构定义。其中myxs是这里使用的命名空间(namespace)，命名空间的具体定义在文件头上出现。而categoryList将会对应save_category消息的返回消息，在Schema建模中没有表现，在这里我也仅列出一个元素名，相信大家在看了本文的前半部分以及本系列的前一篇文章之后，会很清楚如何来定义。
<portType name="save_category_portType"> <operation name="save_category_operation"> <input message="tns:save_category"/> <output message="tns:categoryList"/> </operation> </portType>
这部分定义了服务访问点的调用模式的类型，表明这个入口类型是请求/响应模式，请求消息是save_category，而响应消息是categoryList。
<binding name="save_category_soapBinding" type=" save_category_portType "> <soap:binding style="document" transport=" http://www.w3.org/2001/06/soap-envelope/http"> <operation name="save_category_operation"> <soap:operation soapAction=" http://www.sagitta.com/catalog/"> <input> <soap:body use="literal" namespace=" http://www.sagitta.com/schema/" encodingStyle=" http://www.w3.org/2001/06/soap-encoding"/> </input> <output> <soap:body use="literal" namespace=" http://www.sagitta.com/schema/" encodingStyle=" http://www.w3.org/2001/06/soap-encoding"/> </output> </soap:operation> </operation> </soap:binding> </binding>
这部分将服务访问点的抽象定义与SOAP HTTP绑定，描述如何通过SOAP/HTTP来访问按照前面描述的访问入口点类型部署的访问入口。其中规定了在具体SOAP调用时，应当使用的soapAction是"http://www.sagitta.com/catalog/"，而请求/响应消息的编码风格都应当采用SOAP规范默认定义的编码风格" http://www.w3.org/2001/06/soap-encoding "。
<service name="catalogService"> <documentation>Online Web Service for Catalog</documentation> <port name="save_category_port" binding="tns:save_category_soapBinding"> <soap:address location="http://www.sagitta.com/catalog/"/> </port> </service> </definitions>
这部分是具体的Web服务的定义，在这个名为catalogService的Web服务中，提供了一个服务访问入口(其实还有很多，不过在这里因为演示的原因，仅仅介绍了一个)，访问地址是"http://www.sagitta.com/catalog/"，使用的消息模式是由前面的binding所定义的。
假设我们之前已经注册了一个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。
<?xml version="1.0" encoding="UTF-8"?><Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/"> <Body> <save_service generic="1.0" xmlns="urn:uddi-org:api"> <authInfo>udditest</authInfo> <businessService businessKey="434554F4-6E17-1342-EA41-36E642531DA1" serviceKey=""> <name>categoryService</name> <description xml:lang="en">Online Web Service for Catalog</description> <bindingTemplates> <bindingTemplate bindingKey="" serviceKey=""> <description xml:lang="en">categoryService's BindingTemplate3</description> <accessPoint URLType="http">http://www.sagitta.com/catalog/</accessPoint> <tModelInstanceDetails> <tModelInstanceInfo tModelKey="uuid:E31A569A-AEFF-4468-BA4D-2BF22FE4ACEF"> <description xml:lang="en">Sagitta Web Service Type Description</description> <instanceDetails> <description xml:lang="en">Sagitta Web Service Type Description</description> <overviewDoc> <description xml:lang="en">Sagitta Web Service Overview</description> <overviewURL>http://www.sagitta.com/wsdl/savecategory.wsdl</overviewURL> </overviewDoc> </instanceDetails> </tModelInstanceInfo> </tModelInstanceDetails> </bindingTemplate> </bindingTemplates> </businessService> </save_service> </Body></Envelope>
通过上述的API调用，我们就已经把这个服务注册进了UDDI注册中心，其中bindingTemplate的accessPoint是服务的入口，而overviewDoc中的overviewURL是WSDL文档的访问位置。
潜在的使用者可以通过查询UDDI注册中心找到这个Web服务，通过overviewURL中保存的URL找到服务的描述，然后通过accessPoint所指定的访问地址来访问这个服务。
当发生紧急服务崩溃的时候，Web服务可能被迁移到另一台主机上，IP地址，甚至是访问的URL都可能有很大变化，此时原先的集成的连接将不再工作。但是由于UDDI注册的存在，我们可以通过自动化的程序手段来解决这个问题，使得类似的服务灾难恢复的过程非常迅速。
具体的流程一般是：
当恢复的服务启动后，自动去更新UDDI注册中心上的数据，将访问入口修改到新的URL位置; 连入的客户端系统当发现无法访问最终服务的时候，将会定期去查询UDDI注册中心，看看新的BindingTemplate数据和本地缓存的有没有差别，如果有的话，就下载到本地，重新建立服务绑定，完成服务连接的迁移。
UDDI-China.ORG, 以UDDI为主的Web服务技术网站。 WebServices.ORG, Web服务的综合类技术网站。 IBM developerWorks/Web Service Zone, IBM的Web服务技术资源中心 MSDN Online Web Services Developer Resources, Microsoft的Web服务的开发者资源网站 ITPapers/Web Service, ITPapers的Web服务评论文章 解决B2B电子商务应用交互和集成的InterOP Stack系列技术标准规范 UDDI执行白皮书, UDDI-China.org, UDDI.org UDDI技术白皮书, UDDI-China.org, UDDI.org UDDI程序员API规范, UDDI-China.org, UDDI.org UDDI数据结构参考, UDDI-China.org, UDDI.org Web Service Description Language (WSDL) 1.0, IBM, 25 Sep 2000 SOAP: Simple Object Access Protocol Specification 1.1, IBM, Microsoft, DevelopMentor, 2000 XML Schema Part 0: Primer , W3C, 2 May 2001 Extensible Markup Language (XML) 1.0 (Second Edition), W3C, 6 Oct 2000 架构Web services系列 架构Web Service(一): 为什么需要Web服务 架构Web Service(二): 什么是Web服务 架构Web Service(三):基于Web服务的应用、解决方案和开发平台 架构Web Service(四): 实战Web服务 架构Web Service(五): 交互界面，Web服务定义的核心 柴晓路: 上海得易电子商务技术有限公司(DealEasy)首席系统架构师、XML技术顾问。UDDI-China.org蓝色火焰工作室(Blue Blaze Studio)成员。UDDI Advisor Group成员，WSUI Working Group成员。2000年获复旦大学计算机科学硕士学位，曾在国际计算机科学学术会议(ICSC)、亚太区XML技术研讨会(XML Asia/Pacific'99)、中国XML技术研讨会(北京)、计算机科学期刊等各类国际、国内重要会议与期刊上发表论文多篇。专长于基于XML的系统集成和数据交换的技术研究，同时对数据库、面向对象技术及CSCW等技术比较擅长。