如何架構Web Service-WSDL服務描述

來源:互聯網
上載者:User
web|架構

最後,我給出對應本節描述的save_category元素的Schema定義的Schema圖示來結束本小節。

Figure 1.   SOAP API Schema圖示



WSDL服務描述

對SOAP API訊息完成Schema建模之後,一方面這個資料模型可以由SOAP Interface來使用,當發生具體調用時可以使用這個資料模型來除了傳入的參數並產生傳出的參數。同時,利用這個資料模型,我們可以產生相應的WSDL描述,從而將這個Web服務的介面文檔發布給使用者,該介面文檔是具備被程式自動處理的能力的。

以下是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所定義的。

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。


<?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資料和本機快取的有沒有差別,如果有的話,就下載到本地,重建立立服務綁定,完成服務串連的遷移。
總結

到這篇文章為止,如何架構Web Service這個系列就將告一段落,在整個系列中,從為什麼要有Web服務開始,到什麼是Web服務,Web服務的開發工具,對Web服務作了一個概念上的全面介紹。然後以一個具體執行個體來介紹Web服務的構建模式和各種Web Service "stack"技術的具體應用。希望這個系列對大家理解和接受下一代的應用程式套件裝模式Web服務有一個全面的協助。

參考資料

Web Service 技術/評論網站
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
作者簡介

柴曉路: 上海得易電子商務技術有限公司(DealEasy)首席系統架構師、XML技術顧問。UDDI-China.org藍色火焰工作室(Blue Blaze Studio)成員。UDDI Advisor Group成員,WSUI Working Group成員。2000年獲複旦大學電腦科學碩士學位,曾在國際電腦科學學術會議(ICSC)、亞太地區區XML技術研討會(XML Asia/Pacific'99)、中國XML技術研討會(北京)、電腦科學期刊等各類國際、國內重要會議與期刊上發表論文多篇。專長於基於XML的系統整合和資料交換的技術研究,同時對資料庫、物件導向技術及CSCW等技術比較擅長。



相關文章

E-Commerce Solutions

Leverage the same tools powering the Alibaba Ecosystem

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。