// edit by googleyufei
part1. Web Service概述
-----------------------------------------------------
一、 Web Service概述
1.動(dòng)機
1) 今天，萬(wàn)維網(wǎng)的主要用途是交互式的訪(fǎng)問(wèn)文檔和應用程序;
2) 大多數時(shí)候，這些訪(fǎng)問(wèn)是通過(guò)瀏覽器、音頻播放器或其它交互式的前-后端系統;
3) W3C: “假如萬(wàn)維網(wǎng)支持應用程序間的交互，Web在能力及應用范圍上能得到引人注目的增長(cháng)”
2.理念：構建應用程序的時(shí)候通過(guò)發(fā)現以及調用網(wǎng)絡(luò )上現在的應用去實(shí)現某些功能;
二、 技術(shù)基礎
Web services = XML + HTTP
XML：通用數據描述語(yǔ)言;
HTTP：被瀏覽器和Web servers廣泛支持的一種傳輸協(xié)議;
三、 What is web service
1) 在互聯(lián)網(wǎng)上，通過(guò)基于標準的互聯(lián)網(wǎng)協(xié)議(例如HTTP、SMTP)訪(fǎng)問(wèn)的一段業(yè)務(wù)邏輯?；蛘呓蠾eb服務(wù)組件。
2) 承諾在一個(gè)分布式環(huán)境中，不同的平臺的，不同語(yǔ)言的應用和應用組件之間能夠互操作。
3) Web service是自我包含、自我描述、模塊化的程序，它能發(fā)布、定位以及通過(guò)Web調用;
4) 一旦一個(gè)web service被布署，其它應用程序即可發(fā)現和調用這個(gè)服務(wù)。
5) 技術(shù)上來(lái)說(shuō)，Web Service也是一種遠程方法調用
1. 自我包含
1) 在客戶(hù)端，無(wú)須附加的軟件;
2) 只須XML和HTTP協(xié)議客戶(hù)端支持即可開(kāi)始;
3) 在服務(wù)器端，僅需要一個(gè)Web服務(wù)器和servlet引擎;
4) 對于Web service使一個(gè)既存的系統重新可用而無(wú)須寫(xiě)一行代碼是可行的;
2. 自我描述
1) 無(wú)論是客戶(hù)端還是服務(wù)器端除了格式和請求內容以及響應信息外無(wú)須關(guān)注任何事情;
2) 信息格式定義通過(guò)消息傳輸;
3) 無(wú)額外的無(wú)素貯藏庫或代碼產(chǎn)生工具需要;
3. 模塊化的程序
1) Web services標準框架提供了一個(gè)組件模型;
2) Web services是一種技術(shù)，用于部署和提供Web上的商業(yè)功能訪(fǎng)問(wèn);
3) J2EE、CORBA和其它標準是實(shí)現這些Web services的技術(shù);
4. 發(fā)布、定位以及通過(guò)Web調用所需的一些額外的標準：
SOAP：Simple Object Access Protocol
也可理解為 service-oriented architecture protocol，基于RPC和通訊協(xié)議的XML。
WSDL：Web Service Description Language, 一個(gè)描述性的接口和協(xié)議綁定語(yǔ)言。
UDDI：Universal Description, Discovery and Integration，一種注冊機制，用于查找Web service描述。
5. 語(yǔ)言無(wú)關(guān)和互操作性
1) 客戶(hù)端和服務(wù)器端能在不同環(huán)境下被實(shí)現;
2) 既存的環(huán)境為了實(shí)現 Web service 無(wú)須進(jìn)行改動(dòng);
3) 但是在現在，我們假設Java是Web service客戶(hù)端和服務(wù)器端的實(shí)現語(yǔ)言;
6. 基于開(kāi)放的標準
1) XML和HTTP是Web services的技術(shù)基礎;
2) 很大部分Web service技術(shù)使用開(kāi)源項目構建;
3) 因此，供應商無(wú)關(guān)以及互操作性是這時(shí)的現實(shí)目標。
7. Web services是動(dòng)態(tài)的
通過(guò)使用Web Services，動(dòng)態(tài)電子商務(wù)變得很現實(shí)。
因為，使用UDDI和WSDL，Web service描述和發(fā)現可以自動(dòng)進(jìn)行。
8. Web services是組合的、簡(jiǎn)單的
Web services能組合成更復雜的Web services，無(wú)論是使用工作流技術(shù)或是調用更底層的Web services。
9. 基于成熟技術(shù)構建
1) XML + HTML
2) 和其它分布式計算框架相比，有很多相同點(diǎn)也有很多基礎性的不同。
例如，傳輸協(xié)議基于文本而非二進(jìn)制。
四、 Web Service可以解決的問(wèn)題
1) 異構應用系統之間的集成
異構程序定位：使用URI標志軟件程序
傳輸協(xié)議：HTTP、FTP、SMTP等公共協(xié)議
數據格式：XML
接口描述：XML
2) 不同公司之間的系統集成
公共的互聯(lián)網(wǎng)協(xié)議HTTP、FTP、SMTP
3) 需要集成的系統之間有防火墻
使用公共的網(wǎng)絡(luò )協(xié)議HTTP、FTP、SMTP
傳統的做法是，選擇用瀏覽器作為客戶(hù)端(大量跳轉頁(yè)面和控制程序)
新的做法(Ajax，Web Service)
區別于web應用
web application： 人(瀏覽器)與應用的交互
web service： 應用與應用的交互
4) 代碼重用的問(wèn)題
使用HTTP等服務(wù)，無(wú)需下載或安裝服務(wù)程序的代碼
Web service的好處.
專(zhuān)注于核心商業(yè)邏輯，使用Web service應用于非核心商業(yè)邏輯從而以一個(gè)很低的成本快速發(fā)布新的IT解決方案;
通過(guò)使用Web service封裝以前軟件系統到當前系統中可保護既有投資;
以最少的費用將用戶(hù)和伙伴的商業(yè)系統結合到一塊;
1.好處——促進(jìn)協(xié)同工作能力
1) service provider和service requester之間的溝通設計為平臺和語(yǔ)言無(wú)關(guān);
2) 這個(gè)交互需要一份WSDL文檔，這份文檔定義了接口以及描述了相應的服務(wù)，連同網(wǎng)絡(luò )協(xié)議在一起(通常是HTTP);
2.好處——
1) 當service requester 使用service broker尋找service provider，這種發(fā)現是自動(dòng)發(fā)生的。
2) 一旦requester和provider相互找到，provider的WSDL文檔用于將requester和服務(wù)綁定到一塊。
3) 這意味著(zhù)requester、provider和broker一塊創(chuàng )建的系統是自我設置、自我適應以及強健的。
3.好處——通過(guò)封裝降低了復雜性
1) service requester和provider只關(guān)心必要的接口;
2) service requester并不關(guān)心service provider如何實(shí)現服務(wù);
3) 這些細節都在requester和provider方封裝好，這種封裝對于降低復雜性非常重要;
4.好處——給遺留系統以新的生機
1) 對于一個(gè)遺留系統、產(chǎn)生一個(gè)SOAP包裝，然后產(chǎn)生一個(gè)WSDL文檔將應用程序作為一個(gè)web service;
2) 這意味著(zhù)遺留系統能用于新的方面;
3) 此外，與遺留系統相聯(lián)系的基礎設施能封裝成一系列的服務(wù);
五、 Web Service的特點(diǎn)
1) 基于XML，異構應用集成容易
2) 基于消息的(HTTP和SOAP消息)
松散耦合的(調用服務(wù)代碼時(shí)無(wú)需下載和安裝)
編程語(yǔ)言獨立的(使用HTTP等協(xié)議，通信更加簡(jiǎn)單，使用XML的數據格式，程序更易識別)
提供異步和同步的能力(異步功能提高訪(fǎng)問(wèn)性能)
能動(dòng)態(tài)裝配和集成(可以使用更多服務(wù))
通過(guò)互聯(lián)網(wǎng)進(jìn)行訪(fǎng)問(wèn)
3) 基于工業(yè)標準的(W3C的 WSDL, SOAP, UDDI)
六、 Web Service角色
1) service provider 創(chuàng )建web service并發(fā)布它的接口和訪(fǎng)問(wèn)信息到服務(wù)登記處;
2) service broker (也稱(chēng)為service registry)
有責任使Web service接口和實(shí)現訪(fǎng)問(wèn)信息對任何潛在的service requestor可用;
3) service requestor
為了使用Web service，使用各種查找操作在broker登記處定義入口以及綁定到service provider。
Service provider子角色
1) WSDL規范由二部分組成：服務(wù)接口和服務(wù)實(shí)現;
2) 服務(wù)接口提供者和服務(wù)實(shí)現者是service provider的子角色;
3) 二個(gè)角色可以，但非必須被同一個(gè)事務(wù)承擔;
七、 Web services架構體系
1) 通過(guò) service provider 部署到Web上;
2) 提供的功能使用WSDL描述;
3) service broker 幫助 service provider 和 service requestor 能互相找到對方;
4) service requestor 使用 UDDI API從service broker 處尋找它所需要的服務(wù);
5) 當service broker 返回查找的結果，service requestor 可使用這些結果綁定到一個(gè)特定服務(wù);
6) Web service 描述由service provider創(chuàng )建和發(fā)布;
7) 由service broker 組織和查找;
8) 由service requester 定位和調用;
八、 Web services組件
前面顯示了Web service中用到的三種主要的組件：
1) Service provider: 提供服務(wù)并使這些服務(wù)可用;
2) Service broker: 為service provider和service requestor配對;
3) Service requester: 使用service broker查找Web service，然后調用這些服務(wù)去創(chuàng )建應用程序;
九、 Web service操作
1) 發(fā)布/取消發(fā)布
發(fā)布服務(wù)至登記處;
移除這些登記的條款
service provider聯(lián)系
service broker發(fā)布/取消服務(wù)
2) 查找操作由service requestor和service broker共同完成:
service requestor描述他們查找的服務(wù)種類(lèi);
service broker遞交最匹配的請求結果。
3) 綁定發(fā)生在service requestor和service provider間
他們會(huì )協(xié)議好以便requestor能訪(fǎng)問(wèn)和調用service provider提供的服務(wù)。
六、 SOA架構(Service-Oriented Architecture)
面向服務(wù)的體系結構(Service-Oriented Architecture，SOA)是一個(gè)分布式組件模型，用來(lái)將現有的應用集成
1) 把組件都看做網(wǎng)絡(luò )服務(wù)
將現有的應用、組件、業(yè)務(wù)邏輯發(fā)布為服務(wù)
對服務(wù)的要求：與平臺無(wú)關(guān)(硬件，操作系統，語(yǔ)言)；基于 internet 的服務(wù),采用公共的網(wǎng)絡(luò )協(xié)議
2) SOA系統原型的一個(gè)典型例子是通用對象請求代理體系結構
(Common Object Request Broker Architecture，CORBA)
3) 現在的SOA以XML為基礎的，也就是Web Service
Web服務(wù)是技術(shù)規范，而SOA是設計原則，Web服務(wù)是實(shí)現SOA的方式之一
part2. Web Service關(guān)鍵技術(shù) ---- SOAP協(xié)議
-----------------------------------------------------
一、 What is SOAP(Simple Object Access Protocol) ——簡(jiǎn)單對象訪(fǎng)問(wèn)協(xié)議
1) SOAP是一個(gè)網(wǎng)絡(luò )中立的、輕量級的協(xié)議，用于交換兩個(gè)遠端應用程序的信息;
2) SOAP是一個(gè)基于XML的協(xié)議，由三部分組成：
envelope: 定義了一個(gè)框架，該框架用于描述信息內容以及處理說(shuō)明;
一系列的編碼規則:用于表現系統定義的數據類(lèi)型實(shí)例;
一個(gè)協(xié)定:用于表現遠端處理調用和響應
3) SOAP使用XML技術(shù)定義了一個(gè)可擴展的消息框架，底層可以通過(guò)各種協(xié)議進(jìn)行數據交換(主要HTTP、FTP、SMTP)
4) SOAP定義為與特定的編程模型和實(shí)現語(yǔ)句無(wú)關(guān)(只要它能處理XML信息)
是一個(gè)與協(xié)議無(wú)關(guān)的傳輸器, 用和許多協(xié)議共同使用(這里我們描述如何和HTTP一起使用SOAP);
5) SOAP是分布式環(huán)境下交換結構化信息的規范;
6) SOAP代表了SOA中三種主要行動(dòng)者
(service provider、service requestor、service broker)間主要的溝通方式;
7) 它的設計目標是應該簡(jiǎn)單以及可擴展;
1.SOAP VS JRMP、IIOP
SOAP：傳遞基于XML的文本數據(基于文本的協(xié)議易識別和理解，例如HTTP)
JRMP、IIOP：傳遞字節數據
2.SOAP1.2 是 W3C 推薦標準
W3C(萬(wàn)維網(wǎng)聯(lián)盟)組織是一個(gè)制定網(wǎng)絡(luò )標準的非贏(yíng)利組織,像 HTML、XHTML、CSS、XML 的標準都是由W3C來(lái)定制
3.defines1：
SOPA信封 定義消息結構：一個(gè)信封內包含一個(gè)消息頭和一個(gè)消息體
協(xié)議綁定框架 定義了一組規則把SOAP消息綁定到其他的底層協(xié)議
參看：http://www.w3.org/TR/soap12-part1/
4.defines2：
Data modle for SOAP
定義SOAP消息中的XML數據，和具體編程實(shí)現的數據類(lèi)型的對應關(guān)系(如：XML轉換成Java數據類(lèi)型)
Binding to Http
定義了如何將SOPA消息綁定到HTTP協(xié)議
參看：http://www.w3.org/TR/soap12-part2/
5.需要知道SOAP的細節嗎？
需要：了解細節有助于你構建更好的應用(如提高效率和性能：這要求對XML和底層通信協(xié)議的了解)
無(wú)需：一般情況你應該使用一些高層的API(如JAX-WS)構建應用，SOAP的實(shí)現細節對開(kāi)發(fā)者透明
二、 SOAP信封
1) 一條 SOAP 消息就是一個(gè)普通的 XML 文檔，包含下列元素：
必需的 Envelope 元素，可把此 XML 文檔標識為一條 SOAP 消息
可選的 Header 元素，包含頭部信息
必需的 Body 元素，包含所有的調用和響應信息
包含可選的 Fault 元素，提供有關(guān)在處理此消息所發(fā)生錯誤的信息
2) 所有以上的元素均被聲明于針對 SOAP 封裝的默認命名空間中：
http://www.w3.org/2001/12/soap-envelope
以及針對 SOAP 編碼和數據類(lèi)型的encodingStyle屬性：
http://www.w3.org/2001/12/soap-encoding
1. SOAP消息 語(yǔ)法規則:
必須用 XML 來(lái)編碼
必須使用 SOAP Envelope 命名空間
必須使用 SOAP Encoding 命名空間
不能包含 DTD 引用
不能包含 XML 處理指令
2. SOAP 消息的基本結構
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap=" soap:encodingStyle=" <soap:Header> ... </soap:Header>
<soap:Body> ...
<soap:Fault> ... </soap:Fault>
</soap:Body>
</soap:Envelope>
三、 信息格式
1) 一個(gè)SOAP信息是一個(gè)envelope，該envelope包含零至多個(gè)header以及一個(gè)body元素;
2) 這個(gè)envelope是XML文檔的根元素;
3) envelope為以下內容提供了了一個(gè)容器：
控制信息; 消息的收件人; 消息本身;
4) header包含控制信息，例如服務(wù)屬性;
5) body包含消息標簽以及它的參數;
四、 編碼規則
1) 編碼規則定義了一系列機制用于交換程序自定義數據類(lèi)型的實(shí)例;
2) SOAP基于XML schema描述符(XSD)定義了一個(gè)與編程語(yǔ)言無(wú)關(guān)的數據類(lèi)型schema,
根據這個(gè)模型為所有定義的數據類(lèi)型加上這個(gè)編碼規則;
五、 RPC代表
1) RPC代表是適用于表現遠端過(guò)程調用以及相關(guān)響應消息的一個(gè)協(xié)定;
2) 作為遠端方法中的參數，我們通常使用相關(guān)的簡(jiǎn)單數據結構。當然，也可以傳輸更復雜的數據。
3) 這個(gè)協(xié)定僅被SOAP執行，并非SOAP標準的一部分。
4) 這個(gè)轉換的使用是可選的，假如沒(méi)有使用RPC轉換，會(huì )話(huà)是純粹面向消息的;
六、 URN
1) URN代表統一資源名稱(chēng)(unified resource name);
2) URN唯一地識別給客戶(hù)端的服務(wù);
3) 在單個(gè)SOAP服務(wù)器的所有部署的服務(wù)中，它必須是唯一的，通過(guò)一個(gè)合適的網(wǎng)絡(luò )地址確定;
4) 一個(gè)URN被編碼為一個(gè)通用資源標識符(URI);
5) 我們通過(guò)使用格式：urn:UniqueServiceID
七、 SOAP envelope
1) envelope是表示為下列結構的XML文檔的根元素: [message payload]
2) 一個(gè)SOAP消息有零至多個(gè)header和一個(gè)body;
3) SOAP envelope同樣定義了結構化信息的名域空間;
4) 整個(gè)SOAP消息(header和body)都封裝在envelope內;
5) 注意消息body使用一個(gè)服務(wù)特定的名域空間，類(lèi)似于urn:NextMessage;
6) 這個(gè)名域空間不同于SOAP-ENV, 這個(gè)名域空間被envelope所使用，由SOAP規范所定義;
7) 因此在創(chuàng )建消息體的時(shí)候，這個(gè)應用程序能使用它自己的域特定詞匯;
八、 SOAP Header
1) header是envelope中可選的元素，假如出現的話(huà)，這個(gè)元素必須是SOAP envelope中第一個(gè)出現的子元素;
2) 所有header元素的子元素稱(chēng)為header條款;
3) header也能裝載認證數據，數字簽名，編碼信息以及傳輸設置;
4) header也能裝載客戶(hù)端或項目-指定控制以及協(xié)議的擴展;header的定義并不取決于body。
1.可選的，用于擴展SOAP消息，例如：
調用的上下文 目前的應用模式基本上停留在遠程過(guò)程/對象的調用上，
基于多次協(xié)調調用或者遵循上下文的調用模式尚很少使用，這其實(shí)是受簡(jiǎn)單的SOAP消息的制約
安全認證 保存用戶(hù)標識及密碼信息或者其他鑒定證書(shū)
事務(wù)控制 利用SOAP Header條目進(jìn)行事務(wù)控制
其他高級語(yǔ)義功能
2.SOAP Header由一些Header條目組成
<env:Header xmlns:env=" <auth:authentication xmlns:auth=" env:role="authentication:signin_service" env:mustUnderstand="1" relay="" >
<auth:userID>testuserid</auth:userID>
<auth:password>[encodedPassword]</auth:password>
<auth:redirection>http://example.com/service/</auth:redirection>
</auth:authentication>
</env:Header>
3.role屬性：(next|none|ultimateReceiver)
指定這個(gè)條目必須被哪種角色處理
4.mustUnderstand：(true|false)
處理節點(diǎn)必須被處理，如果處理節點(diǎn)理解不了，必須返回一個(gè)SOAP Fault. (此時(shí)relay無(wú)意義)
5.relay：(true|false)
處理節點(diǎn)理解的條目，將會(huì )保留，并轉發(fā)給下一個(gè)SOAP節點(diǎn)處理
九、 SOAP Body
必須的，包含傳遞給最終的節點(diǎn)的實(shí)際信息
1) SOAP body元素提供了一種機制用以交換信息;
2) body元素是SOAP envelope元素的下一級元素;
3) 假如存在header元素，body元素應該緊跟header元素之后。否則它應該緊跟envelope元素之后。
4) 所有body元素的下一級子元素稱(chēng)為body的條目，這些條目各自獨立;
5) 在大多數簡(jiǎn)單的情況下，基本SOAP消息的body組成：
一個(gè)消息名稱(chēng);
一個(gè)服務(wù)實(shí)例的引用;
6) 在A(yíng)pache SOAP中，一個(gè)服務(wù)實(shí)例為它的URN所標識。這個(gè)引用編碼為名域空間的屬性。
7) 一至多個(gè)參數里裝載著(zhù)值和可選的類(lèi)型引用;
8) 典型的body元素使用包括用相應的參數調用RPC、返回結果及錯誤報告;
9) 消息可以包括幾乎任何XML結構，除了DTD及處理說(shuō)明。
<soap:Body xmlns:m=" <m:GetStockPrice>
<m:StockName>IBM</m:StockName>
</m:GetStockPrice>
</soap:Body>
十、 SOAP Fault
可選的，元素用于存留 SOAP 消息的錯誤和狀態(tài)信息。必須出現在SOAP Body中
<soap:Body xmlns:m=" <soap:Fault>
<faultcode>MustUnderstand</faultcode>
<faultstring>
一個(gè)或多個(gè)必須的soap頭未被理解
</faultstring>
</soap:Fault
</soap:Body>
<faultcode> 供識別故障的代碼
<faultstring> 可供人閱讀的有關(guān)故障的說(shuō)明
<faultactor> 有關(guān)是誰(shuí)引發(fā)故障的信息
<detail> 存留涉及 Body 元素的應用程序專(zhuān)用錯誤信息
faultcode的值:
VersionMismatch: SOAP Envelope 元素的無(wú)效命名空間被發(fā)現
MustUnderstand: Header 元素的一個(gè)直接子元素(帶有設置為 "1" 的 mustUnderstand 屬性)無(wú)法被理解。
Client: 消息被不正確地構成，或包含了不正確的信息。
Server: 服務(wù)器有問(wèn)題，因此無(wú)法處理進(jìn)行下去。
十一、SOAP HTTP Binding
HTTP + XML = SOAP
SOAP 請求可能是 HTTP POST 或 HTTP GET 請求。
HTTP POST 請求規定至少兩個(gè) HTTP 頭：Content-Type 和 Content-Length。
1. SOAP請求
POST /soapsamples/servlet/rpcrouter HTTP/1.0
Host: localhost
Content-Type:
text/xml:charset=utf-8
Content-Length: 460
SOAPAction: "" IBM
1) SOAP請求表明getQuote方法從以下地址調用：http://localhost/soapsamples/servlet/rpcrouter
2) SOAP協(xié)議并沒(méi)有指定如何處理請求，服務(wù)提供者可運行一個(gè)CGI腳本，調用servlet或執行其它產(chǎn)生對應響應的處理;
3) 響應包含于一個(gè)XML文檔格式的表單內，該表單包含了處理的結果，在我們這個(gè)范例中是IBM的股價(jià);
2. SOAP響應
HTTP/1.1 200 OK
Server: IBM HTTP SERVER/1.3.19 Apache/1.3.20 (Win32)
Content-Length: 479
Connection: close
Content-Type: text/xml; charset = utf-8
Content-Language: en 108.53
1) 結果所位于的元素名稱(chēng)在請求方法名后加后綴“Response”,
例請求方法名為：getQuote, 響應方法名為：getQuoteResponse。
3. Http響應狀態(tài)
1) 1XX——information
2) 2XX——success
3) 3XX——redirection
4) 4XX——client error
5) 5XX——sever error
part3. Web Service關(guān)鍵技術(shù) --- WSDL
-----------------------------------------------------
1. What is WSDL(Web Service Description Language) ——Web服務(wù)描述語(yǔ)言
WSDL既是機器可閱讀的，又是人可閱讀的，這將是一個(gè)很大的好處。
一些最新的開(kāi)發(fā)工具既能根據你的Web service生成WSDL文檔，又能導入WSDL文檔，生成調用相應Web service的代碼
1) WSDL是以XML為基礎的接口定義語(yǔ)言，它提供了一種分類(lèi)和描述Web service的方式;
描述Web服務(wù) 和說(shuō)明如何與Web服務(wù)通信的XML語(yǔ)言
2) WSDL定義了 Web service的接口，包括：
a. 操作方式(單向、通知、請求-響應);
b. 定義了Web service的消息;
c. 數據類(lèi)型(XML schema);
Web service訪(fǎng)問(wèn)協(xié)議(SOAP over HTTP);
Web service聯(lián)系的終點(diǎn)(Web service URL);
符合要求的服務(wù)端應用程序必須支持這些接口，客戶(hù)端用戶(hù)能從這份文檔中得知如何訪(fǎng)問(wèn)一個(gè)服務(wù)。
2. WSDL文檔結構
<definitions>
<types> definition of types........ </types>
<message> definition of a message.... </message>
<portType> definition of a port....... </portType> //代表interface:接口
<binding> definition of a binding.... </binding>
<service> service of a binding.... </service>
</definitions>
總體上可以分為兩大部分：
1)抽象定義
定義要交換的數據格式(數據類(lèi)型/參數/返回值/方法聲明)
types 定義數據類(lèi)型，使用XML Schema作為類(lèi)型系統
messages 定義要交換的數據，數據類(lèi)型是types中定義的數據類(lèi)型。對應方法的參數
包括若干個(gè)part，每個(gè)part 都對應types中定義一個(gè)元素。對應方法的一個(gè)參數
porttype(接口) 包含若干 operation；定義一個(gè)服務(wù)，對應Java的接口
包含一些operation，operation對應Java的方法
operation 都包含一個(gè)input 和 output 消息(messages中定義)
2)具體描述
定義要采用的互操作協(xié)議(soap)、傳輸協(xié)議(http,ftp,smtp 等)、聲明服務(wù)的訪(fǎng)問(wèn)地址
binding 針對 porttype 定義協(xié)議綁定和數據格式的細節：
首先是定義消息風(fēng)格(style) 和 傳輸協(xié)議(transport)
然后是對操作的輸入輸出的 消息編碼方式(use)
service 包含若干 port
port 定義了一個(gè)通信端點(diǎn)，代表 binding(不同協(xié)議)到 address 的映射
使用XFire開(kāi)發(fā)Web Service
XFire是一個(gè)開(kāi)源的Web Service框架
operation的四種類(lèi)型：
單向: 端點(diǎn)接收請求消息
請求/應答: 端點(diǎn)接收請求消息，然后返回一個(gè)響應消息
通知: 斷點(diǎn)發(fā)送一個(gè)消息
要求/響應: 端點(diǎn)發(fā)送請求消息，然后接收一個(gè)響應消息
SOAP的兩種消息風(fēng)格
style=[document|rpc]
document: 客戶(hù)端使用 XML 模式調用約定。優(yōu)點(diǎn)：更松散的客戶(hù)端和服務(wù)器端耦合性，跨平臺互操作性更好
分兩種: bared(裸露)； wrapped，模擬rpc(包裝的)
rpc: 客戶(hù)端使用遠程過(guò)程調用約定。 優(yōu)點(diǎn)：對開(kāi)發(fā)人員更加簡(jiǎn)單.
binding的傳輸協(xié)議
transport=" transport=" binding中消息的編碼方式
user=[literal|encoded]
literal: 使用types定義的數據類(lèi)型
encoded: 使用soap定義好的數據類(lèi)型，不能使用自定義數據類(lèi)型
可能的style/user組合
1. style="rpc" and use="encoded"
2. style="rpc" and use="literal"
3. style="document" and use="encoded"
4. style="document" and use="literal"
其中WS-I組織只支持(user=literal)格式；(user=encoded不被支持)
WS-I(Web Services Interoperability Organization) Web服務(wù)協(xié)同組織
盡量使用第4種: style="document" and use="literal"
part4. Web Service關(guān)鍵技術(shù) --- UDDI
-----------------------------------------------------
一、 What is UDDI (Universal Description Discovery and Integration)
1) 即統一描述、發(fā)現和集成協(xié)議。
2) UDDI提供了一種發(fā)布和查找Web服務(wù)的方式，使貿易伙伴彼此發(fā)現對方和查詢(xún)對方。
3) UDDI提供了一個(gè)全球的、平臺無(wú)關(guān)的、開(kāi)放式框架，使得商業(yè)應用能：
相互查找;
定義它們通過(guò)Web交互的方式;
在一個(gè)全球注冊場(chǎng)所共享信息;
4) 在Web上存在三種開(kāi)放的UDDI注冊場(chǎng)所, 由IBM、Microsoft 和HP發(fā)起;
5) 注冊是免費的，在任一注冊處注冊的內容被其它注冊處所復制;
6) 在UDDI商業(yè)注冊處提供的信息由三部分組成：
“白皮書(shū)”：(白頁(yè) White pages)包括地址、聯(lián)系以及標識符、產(chǎn)品信息;
“黃皮書(shū)”：(黃頁(yè) Yellow pages)包括基于標準分類(lèi)學(xué)的各產(chǎn)業(yè)分類(lèi);
“綠皮書(shū)”：(綠頁(yè) Green pages)所提供的service的詳細信息;
7) Web service provider 和 requester 使用SOAP API和UDDI注冊處交流;
預想的結構：發(fā)布者--注冊服務(wù)--使用者
不是必須的，公共的注冊服務(wù)目前還沒(méi)有被廣泛接受
UDDI的數據結構
1. businessEntity. 白頁(yè)信息，公司的信息
2. businessService.黃頁(yè)信息，Web服務(wù)的分類(lèi)信息
3. bindingTemplate. 綠頁(yè)信息，Web服務(wù)的技術(shù)信息，包括如何調用Web服務(wù)的信息
4. tModels. 調用細節信息，包含WSDL文檔的引用。
XFire動(dòng)態(tài)客戶(hù)端
-----------------------------------------------------
第一步：引入 XFire相關(guān)的類(lèi)庫
Core Libraries
JAXB Libraries
HTTP Client Libraries
第二步：
Client client = new Client(new URL("WSDL文檔URL")); //創(chuàng )建一個(gè)動(dòng)態(tài)客戶(hù)端
Object[] results = client.invoke("test", new Object[] { "Juliet" }); //調用方法
System.out.println( results[0]);
XFire動(dòng)態(tài)客戶(hù)端2
Service srvcModel = new ObjectServiceFactory().create(MathService.class);
XFireProxyFactory factory = new XFireProxyFactory(XFireFactory.newInstance().getXFire());
// HelloWorld 服務(wù)名稱(chēng)
String helloWorldURL = "http://localhost:8081/Hello/services/HelloWorld";
IHelloWorld srvc = (IHelloWorld) factory.create(srvcModel, helloWorldURL);
System.out.println("結果 ：" + srvc.example("tarena"));
聯(lián)系客服
