架構Web Service:描述與注冊，發(fā)布Web服務

申請免費試用、咨詢電話：400-8352-114

架構Web Service:描述與注冊，發(fā)布Web服務  

  
 柴曉路 (fennivel@uddi-china.org)

Chief System Architect

2001年9月20日

本文是架構Web服務的系列文章的第六篇，也是最后一篇，文本以前文為基礎，在前文的應用實例的基礎上，考察了發(fā)布Web服務界面的整個過程：XML Schema建模、WSDL發(fā)布和UDDI注冊。通過本文，大家可以詳細具體地了解各個XML和Web Service的系列規(guī)范在Web Service的發(fā)布時所起的左右，對Web Service技術也將有一個深入的理解。

在前文中，我已經介紹過，Web服務是通過SOAP消息調用的，通過WSDL進行界面描述的，以及通過UDDI進行公共注冊發(fā)布的。在前一篇文章中，我已經介紹了如何進行SOAP API的消息定義，那么在本文中，我將單把save_category提出來，看看在具體的實現(xiàn)上，應當如何對這個消息使用W3C XML Schema進行建模，如果使用WSDL將基于該消息調用的Web服務進行規(guī)范描述并交付調用者，以及如何將這個Web服務連同它的WSDL規(guī)范化描述文件一起發(fā)布到UDDI注冊中心中去。希望大家能通過本文的實例講解，在本系列的最后完整地了解Web服務的工作原理和相關技術規(guī)范的作用。

本文所引用的資源主要包括兩類，一類是Web服務的技術資源網(wǎng)站，包含了大量Web服務的技術信息，另一類是Web服務“stack"系列技術規(guī)范，他們是一個整體的技術體系，包括UDDI、SOAP、WSDL、XML Schema, XML等。本文的最后給出了這些資源的鏈接，有興趣的讀者可以通過這些資源鏈接找到所需的內容。

SOAP消息示例

以下是一個save_category的調用例子，在例子中使用了SOAP HTTP Binding(使用的SOAP規(guī)范的版本是1.2)，假設目標Web服務被部署在www.sagitta.com，而調用的Web服務的入口位置將是http://www.sagitta.com/catalog/。

在這個消息中，將在一個現(xiàn)有的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

<?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 OK
Content-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這個服務入口進行界面描述，然后將這個入口發(fā)布到UDDI注冊中心中去。

XML Schema建模

XML Schema的文件后綴是.xsd文件，一個XML Schema中的定義通常分為兩部分，型(Type)定義和元素(Element)定義。下面我們結合save_category具體的XML Schema定義來說明如何使用XML Schema來實現(xiàn)模式定義。

在下面的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，這個元素可以出現(xiàn)0次到無窮次(無限制，事實上不可能出現(xiàn)無窮次)，而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元素能夠出現(xiàn)0次到無窮次(無限制，事實上不可能出現(xiàn)無窮次)。該元素的內容的類型是字符串(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，它們都是必須出現(xiàn)的子元素，同時僅可出現(xiàn)一次。他們的類型也都是字符串(xs:string)。然后描述的是parameterBag元素類型，任何使用parameterBag類型的文檔元素可以包含的子元素是parameter，而這個子元素的類型是先前定義的parameter(在XML Schema中，類型名和元素名的域空間是正交的，不需要考慮任何的名字重復問題)，parameter元素出現(xiàn)的次數(shù)可以是從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定義也可以很清楚地發(fā)現(xiàn)是引用了前面定義的這些類型定義。任何使用product類型的文檔元素還有兩個必須出現(xiàn)的屬性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類型的文檔元素還有兩個必須出現(xiàn)的屬性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則是一個可以出現(xiàn)0次到無限次的類型為category的子元素。我們不難發(fā)現(xiàn)元素定義和類型定義的基本機制是一樣的，事實上，我們完全可以將這段定義拆分成兩段，一段為類型定義，一段為元素定義，下面給出這個等價實例，希望有助于對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>

最后，我給出對應本節(jié)描述的save_category元素的Schema定義的Schema圖示來結束本小節(jié)。

Figure 1. SOAP API Schema圖示

WSDL服務描述

對SOAP API消息完成Schema建模之后，一方面這個數(shù)據(jù)模型可以由SOAP Interface來使用，當發(fā)生具體調用時可以使用這個數(shù)據(jù)模型來除了傳入的參數(shù)并生成傳出的參數(shù)。同時，利用這個數(shù)據(jù)模型，我們可以生成相應的WSDL描述，從而將這個Web服務的接口文檔發(fā)布給使用者，該接口文檔是具備被程序自動處理的能力的。

以下是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系統(tǒng)是由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建模中已經完整地創(chuàng)建了根元素的結構定義。其中myxs是這里使用的命名空間(namespace)，命名空間的具體定義在文件頭上出現(xiàn)。而categoryList將會對應save_category消息的返回消息，在Schema建模中沒有表現(xiàn)，在這里我也僅列出一個元素名，相信大家在看了本文的前半部分以及本系列的前一篇文章之后，會很清楚如何來定義。

 <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來訪問按照前面描述的訪問入口點類型部署的訪問入口。其中規(guī)定了在具體SOAP調用時，應當使用的soapAction是"http://www.sagitta.com/catalog/"，而請求/響應消息的編碼風格都應當采用SOAP規(guī)范默認定義的編碼風格" 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所定義的。

UDDI服務發(fā)布

在前一節(jié)中，我們已經通過使用WSDL這個工具將Catalog Service這個Web服務進行了結構化地描述。為了使更多的潛在用戶能夠發(fā)現(xiàn)這個Web服務，同時也為了加強這個Web服務的互操作能力和災難恢復時的連接保持能力，我們需要使用UDDI SDK將這個Web服務注冊到UDDI注冊中心中去。

假設我們之前已經注冊了一個businessEntity，叫做www.sagitta.com，一個在線服務提供商，這個businessEntity的鍵值是"434554F4-6E17-1342-EA41-36E642531DA1"，那么我們要在這個businessEntity下注冊一個businessService，以用于描述前面的Catalog Service。同時需要成立的假設是我們也預先注冊了一個Service Type(tModel)，這個tModel描述了我們這個需要發(fā)布的Web服務的調用規(guī)范，具體內容是前面我定義的這個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所指定的訪問地址來訪問這個服務。

當發(fā)生緊急服務崩潰的時候，Web服務可能被遷移到另一臺主機上，IP地址，甚至是訪問的URL都可能有很大變化，此時原先的集成的連接將不再工作。但是由于UDDI注冊的存在，我們可以通過自動化的程序手段來解決這個問題，使得類似的服務災難恢復的過程非常迅速。

具體的流程一般是：

當恢復的服務啟動后，自動去更新UDDI注冊中心上的數(shù)據(jù)，將訪問入口修改到新的URL位置;

連入的客戶端系統(tǒng)當發(fā)現(xiàn)無法訪問最終服務的時候，將會定期去查詢UDDI注冊中心，看看新的BindingTemplate數(shù)據(jù)和本地緩存的有沒有差別，如果有的話，就下載到本地，重新建立服務綁定，完成服務連接的遷移。

總結

到這篇文章為止，如何架構Web Service這個系列就將告一段落，在整個系列中，從為什么要有Web服務開始，到什么是Web服務，Web服務的開發(fā)工具，對Web服務作了一個概念上的全面介紹。然后以一個具體實例來介紹Web服務的構建模式和各種Web Service "stack"技術的具體應用。希望這個系列對大家理解和接受下一代的應用包裝模式Web服務有一個全面的幫助。

參考資料

 柴曉路: 上海得易電子商務技術有限公司(DealEasy)首席系統(tǒng)架構師、XML技術顧問。UDDI-China.org藍色火焰工作室(Blue Blaze Studio)成員。UDDI Advisor Group成員，WSUI Working Group成員。2000年獲復旦大學計算機科學碩士學位，曾在國際計算機科學學術會議(ICSC)、亞太區(qū)XML技術研討會(XML Asia/Pacific'99)、中國XML技術研討會(北京)、計算機科學期刊等各類國際、國內重要會議與期刊上發(fā)表論文多篇。專長于基于XML的系統(tǒng)集成和數(shù)據(jù)交換的技術研究，同時對數(shù)據(jù)庫、面向對象技術及CSCW等技術比較擅長。