WebServices簡介html
先給出一個概念 SOA ,即Service Oriented Architecture ,中文通常理解爲面向服務的架構,java
既然說是一種架構的話,因此通常認爲 SOA 是包含了運行環境,編程模型,linux
架構風格和相關方法論等在內的一整套新的分佈式軟件系統構造方法和環境,web
涵蓋服務的整個生命週期。而在 SOA 的架構風格中,服務是最核心的抽象手段。編程
SOA 中的服務是構建在一些列基於開放標準的基礎之上的,服務器
Web 服務定義瞭如何在異構系統之間實現通訊的標準化方法,網絡
從而就使得 Web 服務能夠跨越運行平臺和實現語言,架構
同時也使得 Web 服務成爲了實現 SOA 中服務的主要技術。編程語言
至於SOA 的話,過高深的技術,這裏不予討論(嘿嘿),本篇博文只介紹 WebServices 這項技術。分佈式
引子
有沒有一種辦法能夠實現跨應用程序進行通訊和跨平臺進行通訊呢?
換句話說,就是有什麼辦法能夠實現個人應用程序 A 能夠和應用程序 B 進行通訊呢?
或者說是,我用 Java 寫的應用程序和用 . Net 開發的應用程序之間進行通訊呢?
不少時候,上面提到的這些,咱們是必需要使用的,好比,一個跨應用程序吧,
拿騰訊 QQ 來講吧,我估計每個人都用過騰訊 QQ 上面的天氣預報工具吧 ! ! !
上面的這個天氣預報功能是如何實現的呢?
有一種辦法,那就是騰訊公司放個衛星上天,而且在公司中成立一個氣象部門,每天關注於天氣,
而後每時每刻更新騰訊 QQ 上的這個天氣預報信息,
確實,這種辦法確實行得通,不過,要真這樣作的話,估計馬化騰也該被踢出去了(哪有這麼蠢啊?),
那麼上面這個是如何實現的呢?別急,且聽我慢慢道來~~~
而後,咱們再來看看跨平臺這個東東又是什麼呢?
這裏主要是拿 . Net 平臺和Java 平臺來講明例子,
倘若,有兩個公司,每一個公司呢都有本身的一個項目,一個公司呢使用 . Net 開發,一個呢,使用 Java 開發,
恩,原本呢,這兩個是相互獨立的,進水不犯河水,可是有一天,忽然,這兩個公司給合併了,
合併後的老總髮現,若是把兩個項目結合起來將會大大的賺一筆,爲此,如何作?
由於要把兩個項目結合在一塊兒,那麼這兩個項目之間總應該統統信吧 !!!
可這兩個項目又是基於不一樣的平臺,怎麼通訊呢?麻煩了吧 !!!
然後再看一種狀況,就是好比一個公司使用的服務器是 Windows Server 2008,
那麼它如何和 IT 供應商的UNIX 或者是 Linux 服務器進行鏈接呢?也很複雜吧 !!!
WebServices特色介紹
WebServices 提供一個創建分佈式應用的平臺,使得運行在不一樣操做系統和不一樣設備上的軟件,或者是用不一樣的程序語言和不一樣廠商的軟件開發工具開發的軟件,全部可能的已開發和部署的軟件,可以利用這一平臺實現分佈式計算的目的。WebServices的思想是:使得應用程序也具備 Web 分佈式編程模型的鬆散耦合性。
WebServices的特色:
(1),WebServices 是自包含的。即在客戶端不須要附加任何軟件,只要客戶機支持 HTTP 和XML 就 OK 了。
(2),WebServices 是自我描述的。在客戶端和服務端都不須要知道除了請求和響應消息的格式和內容外的任何事。
(3),WebServices 是跨平臺和跨語言的。客戶端和服務端都可以在不一樣的平臺和語言環境中實現,同時,沒必要爲了支持 WebServices 而更改現有的代碼。
(4),WebServices 是基於開放和標準的。XML 和 HTTP 是WebServices 的主要技術基礎,而 XML 和HTTP 早就成了業內標準了。
(5),WebServices 是動態的。
(6),WebServices 是能夠組合的。也就是經過一個 WebService 訪問另一個 WebService 來達到組合的目的。經過組合 WebServices 即可以將簡單的 WebServices 聚合成爲實現更多複雜功能的複雜的服務。
(7),WebServices 是鬆散耦合的。它徹底解耦了客戶端和服務端。
(8),WebServices 提供編程訪問的能力。換句話說,就是能夠經過編寫程序來訪問Web 服務。
(9),WebServices 是基於通過考驗的成熟技術上構建的。好比 XML 和 HTTP。
(10),WebServices 提供打包現有應用程序的能力。
(11),WebServices 經過網絡進行發佈,查找和使用。
上面這些特色呢,如今不清楚的話,也不用緊,等下還會有詳細的說明的 !!!
WebServices究竟是什麼?
若是簡單的說的話,WebServices就是一組函數庫,不過這和咱們平時概念中的函數庫卻又有所不一樣,咱們平時所使用的函數庫要麼是本身寫的(在本身的應用程序當中寫一組函數庫),
要麼是調用底層的 API(操做系統 API 如Win32 API),上面的這兩種狀況有一個共同點,
那就是函數庫是位於客戶端本地的,好比,您調用 Win32 API的話,就是調用本地操做系統上的函數庫,而這裏提到 Web 服務也是一組函數庫這個概念和上面提到的函數庫這個概念的區別就在此處,由於 Web服務看作一組函數庫的話,那麼這組函數庫不是位於本地的,而是位於遠程機器上(固然也能夠是本地機器中)。
何爲 Web 服務?
也就是網絡服務,那就是把網絡上不知道那個地方的一些函數看作是一組服務,而後我再經過網絡就可使用這些服務。
關於什麼是 Web 服務,上面的說法那是山寨版的,稍微正經一點的說法是:
Web 服務是一種部署在 Web 上的對象或者是應用程序組件。
Why WebServices?
爲何須要使用 WebServices呢?這必須根據 WebServices 的特色以及其優點進行分析了。
首先,上面呢,也說了,Web服務的話,就是一組網絡上的應用程序組件,
這樣的話,您即可以經過在您的應用程序中使用 Web 服務來將您的應用程序提高到服務層面上來。
既然能夠看作是一組服務了的話,那麼固然就是能夠提供給別個(別的應用程序)使用咯。
好比,我能夠經過 Web 服務來公開一些接口給別個使用,至於這些要不要收費呢?那就看我心情了,前面舉了騰訊 QQ 上查詢天氣的例子,這個例子呢,就能夠在這裏來作一個解釋了,
在中國,應該只有一個衛星來進行天氣預報的吧?騰訊也不可能爲了天氣預報而專門放個衛星上天吧?
但是騰訊 QQ 又確實是能夠查詢天氣的,這裏,即可以經過 Web 服務來解決。
首先,中國氣象局應該是有一個衛星的,氣象局根據衛星所返回的結果實時發佈全國各地的天氣情況,而且將這些天氣信息以 Web 服務的形式公開,而後呢,騰訊 QQ 即可以經過這個 Web 服務來訪問到天氣情況了,再將這些天氣情況反饋到 QQ 上就 OK 了。
而後,上面提到了 Web服務是應用程序組件,既然是組件,那麼就能夠對這個組件重複的進行使用了,
同時能夠經過 Web 服務來實現將這個應用程序組件做爲一個服務來進行使用,
更爲強大的是,能夠將多個 WebServices組合成爲更爲強大的 WebServices ,
而且是經過互聯網哦!!!
這也是一大優勢啊,
而後呢,最基本的 WebServices是基於 XML 和 HTTP 的
(固然這是最基本的 WebServices ,好比 WebServices 還能夠經過 HTTPS 或者是 SMTP 來實現通訊),
這又有什麼好處呢?很明顯,XML 和HTTP 這些都已是標準了,
不論你是 Java 平臺呢,仍是 . Net 平臺開發出來的(或者是是使用 Web 服務),既然我是使用 XML 和 HTTP 的話,我才懶得鳥你什麼 Java 仍是 . Net 呢,我也無論你是 linux 仍是 Windows ,這一切都和我 Web 服務無關,
我關注的只是經過 HTTP 協議來傳輸 XML 就 OK 了,
至於這些 XML 是如何被服務提供者開發出來的或者這些 XML 是如何被服務請求者使用的,這些都和我無關,這裏即可以看出 Web 服務的另外一個優點了,那就是跨語言跨平臺(實現協同工做),因此能夠經過 Web 服務來實現不一樣應用程序和不一樣平臺之間的通訊。
Web 服務容許獨立於實現服務基於的硬件或者是軟件平臺和編寫服務所用的編程語言使用服務,
根據上面這兩點呢,
即可以解決掉最開始提出的使用 Java 開發的應用程序如何和使用 . Net 開發的應用程序之間進行通訊這一問題,
同時,也能夠解決 Linux 或者是UNIX 和 Windows Server 2008 之間進行鏈接這一問題了。
最後就是經過使用不一樣的 Web 服務,也無論 Web 服務是那種編程語言實現的,
咱們均可以從不一樣的平臺和操做系統進行訪問,從而大大提升了不一樣應用程序共享數據和應用的能力。
而且 Web服務提供了構建 SOA 所必須得技術基礎。
從上面能夠看出經過 WebServices解決了咱們曾經想都不敢想的問題,這麼強大的東西爲何不加以好好利用呢?
WebServices體系結構
在Web 服務的體系結構中,涉及到三個角色,
一個是 Web 服務提供者,一個是 Web 服務中介者,還有一個就是 Web 服務請求者,
同時還涉及到三類動做,即發佈,查找,綁定,
Web 服務提供者:
能夠發佈 Web 服務,而且對使用自身服務的請求進行響應,
Web 服務的擁有者,它會等待其餘的服務或者是應用程序訪問本身。
Web 服務請求者:
也就是 Web 服務功能的使用者,它經過服務註冊中心也就是 Web 服務中介者查找到所須要的服務,
再利用 SOAP 消息向 Web 服務提供者發送請求以得到服務。
Web 服務中介者:
也稱爲服務代理,用來註冊已經發布的 Web服務提供者,並對其進行分類,同時提供搜索服務,
簡單來講的話,Web 服務中介者的做用就是把一個 Web 服務請求者和合適的 Web 服務提供者聯繫在一塊兒,
充當一個管理者的角色,通常是經過 UDDI來實現。
發佈:
經過發佈操做,可使 Web服務提供者向 Web 服務中介者註冊本身的功能以及訪問的接口。
發現(查找):
使得 Web 服務請求者能夠經過 Web 服務中介者來查找到特色的種類的 Web 服務。
綁定:
這裏就是實現讓服務請求者可以使用服務提供者提供的服務了。
WebServices三種基本元素之 SOAP
SOAP 即 Simple Object AccessProtocol 也就是簡單對象訪問協議。
SOAP 呢,其指導理念是「惟一一個沒有發明任何新技術的技術」,
是一種用於訪問 Web 服務的協議。
由於 SOAP 基於XML 和 HTTP ,其經過XML 來實現消息描述,而後再經過 HTTP 實現消息傳輸。
SOAP 是用於在應用程序之間進行通訊的一種通訊協議。
由於是基於 XML 和HTTP 的,因此其獨立於語言,獨立於平臺,而且由於 XML 的擴展性很好,
因此基於 XML 的 SOAP 天然擴展性也不差。
經過 SOAP 能夠很是方便的解決互聯網中消息互聯互通的需求,
其和其餘的 Web 服務協議構建起 SOA 應用的技術基礎。
SOAP 協議的一個重要特色是它獨立於底層傳輸機制,Web 服務應用程序能夠根據須要選擇本身的數據傳輸協議,
能夠在發送消息時來肯定相應傳輸機制。
因爲 HTTP 協議自己的一些特色和侷限性,
使得當 SOAP 使用HTTP 綁定的 Web 服務並不能知足某些企業應用的需求。
好比,HTTP 不是一個可靠傳輸協議,因此有可能在傳輸過程當中出現問題,
而後 HTTP 協議基於Request/Response 模型,也就是說客戶端須要在等待響應消息接收完成後才能繼續執行,
而此時若是響應時間過長呢?
基於上面的這些需求,便須要選擇合適的傳輸協議了。
關於這方面的內容的話,有點深奧了,有興趣的能夠去看看 IBM 的一些關於這方面內容的介紹。
還有一點須要說起一下,那就是 SOAP 是能夠繞過防火牆的,未來將會做爲 W3C 的標準進行發展。
WebServices三種基本元素之 WSDL
WSDL 即Web Services Description Language也就是 Web 服務描述語言。
是基於 XML的用於描述 Web 服務以及如何訪問 Web 服務的語言。
服務提供者經過服務描述將全部用於訪問 Web服務的規範傳送給服務請求者,
要實現 Web服務體系結構的鬆散耦合,服務描述是一個關鍵,
無論是請求者仍是服務提供者,經過服務描述即可以沒必要了解對方的底層平臺,編程語言等,
服務描述與底層的 SOAP 基礎結構相結合,
足以封裝服務請求者的應用程序和服務提供者的 Web服務之間的這個細節。
WSDL 描述了 Web服務的三個基本屬性:
(1)服務所提供的操做
(2)如何訪問服務
(3)服務位於何處(經過 URL 來肯定就 OK 了)
WebServices三種基本元素之 UDDI
UDDI 即 Universal Description,Discovery and Integration,也就是通用的描述,發現以及整合。
WSDL 呢,用來描述了訪問特定的 Web 服務的一些相關的信息,能夠在互聯網上,
或者是在企業的不一樣部門之間,如何來發現咱們所須要的 Web 服務呢?
而 Web 服務提供商又如何將本身開發的 Web 服務公佈到因特網上,
這就須要使用到 UDDI 了,UDDI的話,是一個跨產業,跨平臺的開放性架構,
能夠幫助 Web 服務提供商在互聯網上發佈 Web 服務的信息。
UDDI 呢是一種目錄服務,企業能夠經過 UDDI 來註冊和搜索 Web 服務。
簡單來時候話,UDDI 就是一個目錄,只不過在這個目錄中存放的是一些關於 Web 服務的信息而已。
而且 UDDI 經過SOAP 進行通信,構建於 . Net 之上。
開發 Web服務的方式
(1)開發階段:
實現一個 Web 服務,使這個 Web 服務能響應和接收 SOAP 消息,
(這個呢,其實能夠經過 Visual Studio 來幫助實現),
定義好邏輯模塊(這個 Web 服務總要乾點事情吧),
而後再撰寫 WSDL 文件(這個呢,開發工具會自動生成的,不須要人工撰寫了)
(2)部署階段:
指定 Web 服務的傳輸協議,將 Web 服務註冊到相應服務描述部署文件(這些也是能夠由工具來自動完成的)
(3)發佈階段:
將 Web 服務的接口和調用的地址公開給客戶端調用,
經常使用的發佈方式爲基於 Web 提供的WSDL 的連接,固然 UDDI 也是一個選擇。
總結一下 WebServices的優勢
其實呢,前面介紹的都是關於 WebServices 的優勢,在這裏就只是淺要的總結一下了。
首先,WebServices 是基於 Internet 和異構平臺的應用,
這樣即可以方便的實現經過網絡來通訊,同時能夠實如今不一樣的平臺之間共享數據。
而後就是,WebServices 是基於 XML 和HTTP 的,
也就是基於標準和開放的,基於 XML 的話,擴展性天然好,天然跨語言。
基於 HTTP 的話,天然跨平臺了。
最後,再回憶一下 WebServices 是一種應用程序組件吧,這樣即可以將 WebServices 重複使用了。
談談 WebServices 的缺點
首先就是因爲 XML 文件的難以解析,因此在使用 Web 服務的時候,會消耗較多的 CPU 和內存資源,
然後,SOAP 是基於XML 的,因此在網絡傳輸中傳輸的是 XML 文件,
可是由 XML 文件相比於二進制文件來講,要大不少,天然就會消耗更多的網絡資源了。
然後,因爲經過 WSDL 解耦了Web 服務提供者和請求者,且 SOAP 消息時從發送者向接收者單向傳送的,
這在必定程度上形成了 WebServices 是一種無狀態服務,
儘管如今在 . Net 中能夠經過 Session 來實如今客戶端和服務端共享一些數據,
可是單單依靠 Session 來實現客戶端和服務端的狀態交互也太牽強了吧
WebServices 在數據綁定上也存在一些缺陷,
由於全部的數據在傳輸中都是使用的 XML 來實現的,
所以,須要在二進制數據和 XML 之間進行一個轉換(經過序列化和反序列化來實現),
而在轉換過程當中有可能出現語義丟失的狀況。
最後就是 WebServices 的技術要求相對比較高,
由於涉及到底層的 HTTP 協議以及SOAP ,WSDL 和UDDL 這三大平臺元素,
因此學習的曲線也是比較長的,
固然,在 . Net 中能夠經過 Visual Studio 很是快速和簡單的開發和訪問一個 Web 服務,
但這隻限於在簡單的使用上,而對於本質的東西,是比較難的。
演示文檔:
1 <?xml version='1.0' encoding='UTF-8'?><wsdl:definitions name="HelloWorldService" targetNamespace="http://test.demo1/" xmlns:ns1="http://schemas.xmlsoap.org/soap/http" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://test.demo1/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> 2 <wsdl:types> 3 <xs:schema elementFormDefault="unqualified" targetNamespace="http://test.demo1/" version="1.0" xmlns:tns="http://test.demo1/" xmlns:xs="http://www.w3.org/2001/XMLSchema"> 4 <xs:element name="sayHello" type="tns:sayHello"/> 5 <xs:element name="sayHelloResponse" type="tns:sayHelloResponse"/> 6 <xs:complexType name="sayHello"> 7 <xs:sequence> 8 <xs:element minOccurs="0" name="arg0" type="xs:string"/> 9 </xs:sequence> 10 </xs:complexType> 11 <xs:complexType name="sayHelloResponse"> 12 <xs:sequence> 13 <xs:element minOccurs="0" name="return" type="xs:string"/> 14 </xs:sequence> 15 </xs:complexType> 16 </xs:schema> 17 </wsdl:types> 18 <wsdl:message name="sayHelloResponse"> 19 <wsdl:part element="tns:sayHelloResponse" name="parameters"> 20 </wsdl:part> 21 </wsdl:message> 22 <wsdl:message name="sayHello"> 23 <wsdl:part element="tns:sayHello" name="parameters"> 24 </wsdl:part> 25 </wsdl:message> 26 <wsdl:portType name="HelloWorld"> 27 <wsdl:operation name="sayHello"> 28 <wsdl:input message="tns:sayHello" name="sayHello"> 29 </wsdl:input> 30 <wsdl:output message="tns:sayHelloResponse" name="sayHelloResponse"> 31 </wsdl:output> 32 </wsdl:operation> 33 </wsdl:portType> 34 <wsdl:binding name="HelloWorldServiceSoapBinding" type="tns:HelloWorld"> 35 <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> 36 <wsdl:operation name="sayHello"> 37 <soap:operation soapAction="" style="document"/> 38 <wsdl:input name="sayHello"> 39 <soap:body use="literal"/> 40 </wsdl:input> 41 <wsdl:output name="sayHelloResponse"> 42 <soap:body use="literal"/> 43 </wsdl:output> 44 </wsdl:operation> 45 </wsdl:binding> 46 <wsdl:service name="HelloWorldService"> 47 <wsdl:port binding="tns:HelloWorldServiceSoapBinding" name="HelloWorldPort"> 48 <soap:address location="http://localhost:8080/helloWorld"/> 49 </wsdl:port> 50 </wsdl:service> 51 </wsdl:definitions>
Web service中一個wsdl對應一個web service地址,能夠想象成一個商店,商店裏面出售不少手機(portTypes),每一個手機上有不少功能(opeations),每一個功能對應不少輸入和輸出參數(message)
這裏沒有類,只有端口。。。沒有方法,只有端口裏面的操做,沒有參數,只有傳遞給端口中某個操做的消息
xml文檔第一句:
definitions--WSDL文檔的根元素,該元素的屬性指明瞭wsdl文檔的名稱,文檔的目標名字空間,以及WSDL文檔應用的名字空間的速記定義。它指明瞭此WebService的名稱爲:HelloWorldImplService
而後找到名爲「HelloWorldImplService」的service具體定義以下所示:
<wsdl:service name="HelloWorldImplService"> <wsdl:port binding="tns:HelloWorldImplServiceSoapBinding" name="HelloWorldImplPort"> <soap:address location="http://localhost:8080/helloWorld" /> </wsdl:port> </wsdl:service>
service---相關port元素的集合,用戶組織endpoint定義。
port--經過binding和物理地址定義的endpoint,這個元素將全部抽象定義彙集在一塊兒
這部分是具體的Web服務的定義,在這個名爲 HelloWorldImplService的Web服務中,提供了一個服務訪問入口,訪問地址是"http://localhost:8080/helloWorld",使用的消息模式是由前面的binding
「HelloWorldImplServiceSoapBinding」所定義的。
1 <wsdl:binding name="HelloWorldImplServiceSoapBinding" type="tns:HelloWorld"> 2 <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" /> 3 <wsdl:operation name="sayHello"> 4 <soap:operation soapAction="" style="document" /> 5 <wsdl:input name="sayHello"> 6 <soap:body use="literal" /> 7 </wsdl:input> 8 <wsdl:output name="sayHelloResponse"> 9 <soap:body use="literal" /> 10 </wsdl:output> 11 </wsdl:operation> 12 </wsdl:binding>
binding---一個endpoint的實際數據格式說明,一個binding元素定義如何將一個抽象消息映射到一個具體數據格式。該元素指明諸如參數順序,返回值等信息。
每一個被支持的信息格式和信息傳送方式組合,就叫作 binding (就是若是你要和商店裏的服務員溝通,那麼大家必須規定好用什麼語言溝通,binging就是把某個服務員(好比銷售nokia的服務員)和某種語言綁定wsdlsoap:binding 就是用 soap語言通話 )
這段xml定義的操做「sayHello」使用的是SoapDocumentProtocol消息格式(style="document")。輸入和輸出參數格式都是「Literal」(use="literal")
關於:SQAP的消息格式能夠參考文章:http://www.cnblogs.com/linyawen/archive/2011/07/20/2111177.html
1 <wsdl:portType name="HelloWorld"> 2 <wsdl:operation name="sayHello"> 3 <wsdl:input message="tns:sayHello" name="sayHello" /> 4 <wsdl:output message="tns:sayHelloResponse" name="sayHelloResponse" /> 5 </wsdl:operation> 6 </wsdl:portType>
portType---描述服務邏輯接口的operation元素的集合。HelloWorld只有一個操做sayHello.
這部分定義了服務訪問點的調用模式的類型,代表 HelloWorld Service的sayHello入口類型是請求/響應模式,請求消息是sayHello,而響應消息是sayHelloResponse。
1 <wsdl:message name="sayHelloResponse"> 2 <wsdl:part element="tns:sayHelloResponse" name="parameters" /> 3 </wsdl:message> 4 <wsdl:message name="sayHello"> 5 <wsdl:part element="tns:sayHello" name="parameters" /> 6 </wsdl:message>
這部分是消息格式的抽象定義,其中定義了兩個消息格式:
1 <xs:element name="sayHello" type="tns:sayHello" /> 2 <xs:element name="sayHelloResponse" type="tns:sayHelloResponse" /> 3 <xs:complexType name="sayHello"> 4 <xs:sequence> 5 <xs:element minOccurs="0" name="arg0" type="xs:string" /> 6 </xs:sequence> 7 </xs:complexType> 8 <xs:complexType name="sayHelloResponse"> 9 <xs:sequence> 10 <xs:element minOccurs="0" name="return" type="xs:string" /> 11 </xs:sequence> 12 </xs:complexType>
上面這部分是數據類型的定義,其中爲定義了兩個元素的結構:
1 <xs:element minOccurs="0" name="arg0" type="xs:string" />
<xs:element minOccurs="0" name="return" type="xs:string" />
其中的name="arg0", name="return"中的「arg0」,「return」是能夠指定的,由於我前面一章的HelloWorld輸入輸出參數都是使用的默認的參數名,因此生成的xml是這樣子。
若是HelloWorld接口中的方法修改爲
1 public @WebResult(name="responseResult")String sayHello(@WebParam(name="name")String name) ;
也就是給輸入參數與返回結果指定一個選定的名字,則生成的xml以下所示:
1 <xs:complexType name="sayHello"> 2 <xs:sequence> 3 <xs:element minOccurs="0" name="name" type="xs:string"/> 4 </xs:sequence> 5 </xs:complexType> 6 <xs:complexType name="sayHelloResponse"> 7 <xs:sequence> 8 <xs:element minOccurs="0" name="responseResult" type="xs:string"/> 9 </xs:sequence> 10 </xs:complexType>
4.請求及響應的具體消息格式以下所示:
請求消息:
1 - <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:q0="http://test.demo1/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 2 - <soapenv:Body> 3 - <q0:sayHello> 4 <arg0>xxl</arg0> 5 </q0:sayHello> 6 </soapenv:Body> 7 </soapenv:Envelope>
響應消息:
1 - <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> 2 - <soap:Body> 3 - <sayHelloResponse xmlns:ns2="http://test.demo1/"> 4 <return>hello xxl</return> 5 </sayHelloResponse> 6 </soap:Body> 7 </soap:Envelope>