解讀 WebService

如下部份內容引自：《Web Service學習》（該文還講述瞭如何利用.NET實現WebService）

腦圖連接

WebService是要作什麼？

Web Service的主要目標是跨平臺的可互操做性。爲了實現這一目標，Web Service 徹底基於XML（可擴展標記語言）、XSD（XML Schema）等獨立於平臺、獨立於軟件供應商的標準，是建立可互操做的、分佈式應用程序的新平臺。

WebService從表面看，是一個可以經過Web調用的API，能夠理解爲統一使用80端口提供的RPC服務集；從深層看，WebService是構建分佈式系統、實現可互操做的新的技術架構，是一個平臺，是一套標準。

WebService 的架構設計到如下幾個層面：通信層、數據層、應用層。

WebService 組件

SOAP

簡單對象訪問協議（Simple Object Access Protocol）是交換數據的一種協議規範，是一種輕量的、簡單的、基於XML的協議，它被設計成在WEB上交換結構化的和固化的信息。

如下內容部分引自：《菜鳥教程》

爲何使用 SOAP？

對於應用程序開發來講，使程序之間進行因特網通訊是很重要的。通訊方式能夠歸結爲兩類：

• 基於socket（TCP or UDP）的數據結構實現通訊，例如 RPC、ZeroMQ、ORB 以及其餘各種網絡中間件，均可以當作是對socket的封裝，提供了更易於使用的接口；
• 基於現有通訊框架實現數據的傳遞，例如HTTP是一套完善的網絡數據傳輸方式，故而能夠將數據內容以HTTP協議發送到網絡中。

目前的應用程序經過使用遠程過程調用（RPC）在諸如 DCOM 與 CORBA 等對象之間進行通訊。但 RPC 會產生兼容性以及安全問題；防火牆和代理服務器一般會阻止此類流量……經過 HTTP 在應用程序間通訊是更好的方法，由於 HTTP 獲得了全部的因特網瀏覽器及服務器的支持。

那麼 WebService 經過HTTP協議發送請求和接收結果時，必需要有必定的格式，並非說經過HTTP隨便發送一個請求就能夠的。SOAP 定義了這個標準格式。

SOAP 定義了 WebService 消息 的格式，SOAP協議是基於HTTP協議的，SOAP也是基於XML和XSD的，XML是SOAP的數據編碼方式。因而乎，運行在不一樣的操做系統並使用不一樣的技術和編程語言的應用程序能夠互相通訊。

SOAP 構建模塊

一條 SOAP 消息就是一個普通的 XML 文檔，包含下列元素：

1. 必需的 Envelope 元素，可把此 XML 文檔標識爲一條 SOAP 消息
2. 可選的 Header 元素，包含頭部信息
3. 必需的 Body 元素，包含全部的調用和響應信息
4. 可選的 Fault 元素，提供有關在處理此消息所發生錯誤的信息

全部以上的元素均被聲明於針對 SOAP 封裝的默認命名空間中：http://www.w3.org/2001/12/soap-envelope
以及針對 SOAP 編碼和數據類型的默認命名空間：http://www.w3.org/2001/12/soap-encoding

語法規則

這裏是一些重要的語法規則：

• SOAP 消息必須用 XML 來編碼
• SOAP 消息必須使用 SOAP Envelope 命名空間
• SOAP 消息必須使用 SOAP Encoding 命名空間
• SOAP 消息不能包含 DTD 引用
• SOAP 消息不能包含 XML 處理指令

組成部分

• SOAP封裝（envelop）：它定義了一個框架，描述消息中的內容是什麼，是誰發送的，誰應當接受並處理它以及如何處理它們；
• SOAP編碼規則（encoding rules）：它定義了一種序列化機制，用於表示應用程序須要使用的數據類型的實例；
• SOAP RPC表示（RPC representation）：它定了一個協定，用於表示遠程過程調用和應答；
• SOAP綁定（binding）：它定義了SOAP使用哪一種協議交換信息。使用HTTP/TCP/UDP協議均可以。

把 SOAP 綁定到 HTTP 提供了同時利用SOAP的樣式和分散的靈活性的特色以及HTTP的豐富的特徵庫的優勢。在HTTP上傳送SOAP並非說SOAP會覆蓋現有的HTTP語義，而是HTTP上的SOAP語義會天然的映射到HTTP語義。在使用HTTP做爲協議綁定的場合中，RPC請求映射到HTTP請求上，而RPC應答映射到HTTP應答。然而，在 RPC 上使用SOAP並不只限於HTTP協議綁定，SOAP也能夠綁定到TCP和UDP協議上。

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>

SOAP 不等於 HTTP + XML

SOAP消息可以與不一樣的底層傳輸協議進行綁定——包括超文本傳輸協議（HTTP），簡單郵件傳輸協議（SMTP），多用途網際郵件擴充協議（MIME）。它還支持從消息系統到遠程過程調用協議（RPC）等大量的應用程序。

固然，最多的狀況仍是綁定在HTTP協議上面傳輸。這就致使大多數人認爲SOAP就是HTTP + XML，或者認爲SOAP是HTTP post請求的一個專用版本，遵循一種特殊的XML消息格式——雖然，咱們看到的大多狀況確實如此，但這並非SOAP本質與所有。

WSDL

WSDL 文檔僅僅是一個簡單的 XML 文檔（人爲定義的格式化文本）。它包含一系列描述某個 web service 的定義，包括兩個層面的信息：

• 網絡服務的定位（地址）
• 網絡服務的接口描述

WebService服務提供商能夠經過兩種方式來暴露它的WSDL文件地址：

• 註冊到UDDI服務器，以便被人查找；
• 直接告訴給客戶端調用者。

如下內容引自：《菜鳥教程》

文檔結構

WSDL 文檔是利用這些主要的元素來描述某個 web service 的：

元素	定義
<portType>	web service 執行的操做
<message>	web service 使用的消息
<types>	web service 使用的數據類型
<binding>	web service 使用的通訊協議

示例

<message name="getTermRequest">
  <part name="term" type="xs:string"/>
</message>

<message name="getTermResponse">
  <part name="value" type="xs:string"/>
</message>

<portType name="glossaryTerms">
  <operation name="getTerm">
    <input message="getTermRequest"/>
    <output message="getTermResponse"/>
  </operation>
</portType>

在這個例子中，<portType> 元素把 "glossaryTerms" 定義爲某個端口的名稱，把 "getTerm" 定義爲某個操做的名稱。
操做 "getTerm" 擁有一個名爲 "getTermRequest" 的輸入消息，以及一個名爲 "getTermResponse" 的輸出消息。
<message> 元素可定義每一個消息的部件，以及相關聯的數據類型。
對比傳統的編程，glossaryTerms 是一個函數庫，而 "getTerm" 是帶有輸入參數 "getTermRequest" 和返回參數 getTermResponse 的一個函數。

UDDI

UDDI 是一個獨立於平臺的框架（在線企業和服務註冊的一個規範），用於經過使用 Internet 來描述服務，發現企業，並對企業服務進行集成。

• UDDI 是一種用於存儲有關 web services 的信息的目錄。
• UDDI 是一種由 WSDL 描述的 web services 界面的目錄。

注意：UDDI 經由 SOAP 進行通訊。

技術規範 

UDDI數據模型：一個用於描述商業組織和Web Service的XML Schema；

UDDI API：一組用於查找或發佈UDDI數據的方法，基於SOAP；

UDDI註冊服務（應用）：Web Service中的一種基礎設施。

XSD

WebService採用HTTP協議傳輸數據，採用XML格式封裝數據——XML解決了數據表示的問題，但它沒有定義一套標準的數據類型，更沒有說怎麼去擴展這套數據類型。例如，整形數到底表明什麼？16位，32位，64位？這些細節對實現互操做性很重要。XML Schema(XSD)就是專門解決這個問題的一套標準。它定義了一套標準的數據類型，並給出了一種語言來擴展這套數據類型。

WebService平臺用XSD來做爲其數據類型系統的。當你用某種語言（如.NET或Java,C語言）來構造一個Web service時，爲了符合WebService標準，全部你使用的數據類型都必須被轉換爲XSD類型。不用太擔憂，你用的工具可能已經自動幫你完成了這個轉換。

WebService架構層級

通信層

HTTP無疑是WebService通信的主要形式和載體。

除了標準的HTTP以外，WebService也支持FTP協議和SMTP協議。而對於Intranet上，WebService也支持採用中間件來做爲傳輸交互的基礎架構，例如IBM的 MQ Series 和 CORBA。

實際上，通信層的可替換性很強——你能夠經過任何一種socket傳輸協議，實現消息的網絡傳遞。而這個過程對服務提供者來講，基本是透明的。

數據層

數據表現層的XML爲WebService上層協議提供了信息、數據描述手段。XML是目前全球範圍內描述數據和交換數據的一種標準方式。

在WebService的時代，所有的規範、技術都是以XML爲底層核心和構架基礎的。對WebService而言，無論是WebService消息的傳遞（SOAP）、WebService服務接口的描述（WSDL)，或是WebService的查詢發現（UDDI）都是將XML做爲信息描述和交換的標準方式。

描述數據結構的數據模型（也就是元數據），它自己也是一種數據。所以，描述數據結構的方式也基於XML實現——XML Schema。

消息層

消息是數據的封裝形式，

WebService使用的是基於XML的消息交換協議SOAP。SOAP是構建於更低的傳輸層之上，這意味這SOAP能夠單獨使用，也能夠與任何傳輸層協議進聯合使用。全部的SOAP消息都提供前面說過的WebService架構中的發佈（Publish)、綁定(Bind)、和查找(Find)功能。

接口描述層

WSDL文檔只是服務的基本描述手段，它能夠經過其餘服務描述文檔來補充，以描述WebServices例如業務環境，服務質量等更高級的信息。 

應用層

應用層包含三個角色——服務終端、請求者（客戶端）和服務註冊中心。

服務提供者可以直接向服務客戶端發送WSDL文檔，例如經過Email的形式。
固然，更常見的形式是服務提供者將WSDL發佈到本地的UDDI庫中，或者是公共/私有的UDDI服務註冊中心，服務客戶端能夠經過註冊庫發現WSDL文檔。

服務客戶端能夠選擇在設計階段或運行時階段經過本地WSDL服務註冊中心或者公有/私有的UDDI註冊中心發現WSDL文檔。

服務項

引自：《解道：SOA面向服務架構》

服務兩個重要特色：自治和管制。

自治表明服務不能被外部勢力牽制，好比在一個服務內部處理中須要調用外部資源或等待外部流程結束，這種等待不能影響服務自己的調用。若是一個服務分爲顯式對外和隱式內部兩個部分，那麼自治是針對隱式內部，意味着咱們不能在具體一個服務中直接使用同步代碼實現複雜功能。如：

public class AServiceImpl :AService{
　　public void productSale(...){
　　　　Product product = productService.getProduct();
　　　　int inventory = InventoryService.getInventory(product);
　　　　int price = priceService.getPrice(product);
　　}
}

在AServiceImpl的productSale方法中，咱們得到商品的庫存和訂價，都是經過同步的RPC實現調用的，這樣形成productSale方法依賴於InventoryService和priceService，沒法實現自身自治。

服務工做流層

WebService工做流語言（WSFL）是協議棧頂層的服務工做流層的標準語言。與協議棧中其餘的標準不一樣，WSFL針對的是商務流程建模和工做流。WSFL用於描述WebService在工做流中如何交互，以及服務跟服務之間的通訊和協同，這意味這WebService能夠是工做流的一部分，也能夠動態地被編入工做流。特別的，這個工做流有可能發生在買方，賣方和承運方之間。

例如WSFL容許工做流管理器從一個複合WebService中，按工做流來定義依據商業流程賦予的不一樣功能的，做爲其成分的每一個個體WebService。這樣的商業流程包括財務報表、預測和5年IT計劃等。

SOA 與 Web Service 的聯繫

由於如今幾乎全部的SOA應用場合都是和Web Service綁定的，因此難免有時候這兩個概念混用。不能否認Web Service是如今最適合實現SOA的技術，SOA的走紅在很大程度上歸功於Web Service標準的成熟和應用普及。由於如今你們基本上認同Web Service技術在幾方面體現了SOA的須要：

• 首先，是基於標準訪問的獨立功能實體知足了鬆耦合要求：在Web Service中全部的訪問都經過SOAP訪問進行，用WSDL定義的接口封裝，經過UDDI進行目錄查找，能夠動態改變一個服務的提供方而無需影響客戶端的配置，外界客戶端是根本不關心訪問服務器端的實現。
• 其次，適合大數據量低頻率訪問符合服務大顆粒度功能：基於性能和效率平衡的要求，SOA的服務提供的是大顆粒度的應用功能，並且跨系統邊界的訪問頻率也不會象程序間函數調用那麼頻繁。經過使用WSDL和基於文本(Literal)的SOAP請求，能夠實現能一次性接收處理大量數據。
• 最後，基於標準的文本消息傳遞爲異構系統提供通信機制：Web Service全部的通信是經過SOAP進行的，而SOAP是基於XML的，XML是結構化的文本消息。從最先的EDI開始，文本消息也許是異構系統間通信最好的消息格式，適用於SOA強調的服務對異構後天宿主系統的透明性。

綜合上述觀點，Web Service不愧爲當前SOA的最好選擇。然而，就SOA思想自己而言，並不必定要侷限於Web Service方式的實現。更應該看到的是SOA自己強調的是實現業務邏輯的敏捷性要求，是從業務應用角度對信息系統實現和應用的抽象。隨着人們認識的提升，還會有新技術不斷的發明出來，更好的來知足這個要求。

非適用場景

單機應用程序

目前，企業和我的還使用着不少桌面應用程序。其中一些只須要與本機上的其它程序通訊。在這種狀況下，最好就不要用Web Service，只要用本地的API就能夠了。COM很是適合於在這種狀況下工做，由於它既小又快。運行在同一臺服務器上的服務器軟件也是這樣。固然Web Service 也能用在這些場合，但那樣不只消耗太大，並且不會帶來任何好處。

局域網的一些應用程序

在許多應用中，全部的程序都是在Windows平臺下使用COM，都運行在同一個局域網上。在這些程序裏，使用DCOM會比SOAP/HTTP有效得多。與此相相似，若是一個.net程序要鏈接到局域網上的另外一個.net程序，應該使用.net Remoting。其實在.net Remoting中，也能夠指定使用SOAP/HTTP來進行Web Service 調用。不過最好仍是直接經過TCP進行RPC調用，那樣會有效得多。

思考

1. 關於SOAP，做爲協議爲什麼須要與XML的具體的描述語言耦合（所謂基於XML）？
   答：任何協議，設計到數據時，老是須要描述數據結構和數據定義——而XML與XSD做爲語言無關的數據描述方案，成爲了SOAP/WSDL等協議的描述形式——故而稱，SOAP是基於XML的協議。這不是耦合，而是不得不用，而選擇語言無關的數據定義，已是最小化的依賴方案了。
2. 跨平臺是HTTP實現的，而不是SOAP！答：或者說，SOAP之因此基於HTTP，就是爲了繼承HTTP這一套平臺無關的通信實現。固然，SOAP也能夠採用其餘傳輸模式，如SMTP/MIME，甚至於局域網內的RPC/ORB的消息——因此更底層的說，跨平臺是socket（TCP or UDP）實現的，而不是SOAP！