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