webserver技術總結之一：webserver概念

WebService的簡介, 原理, 使用，流程圖

第一部分: 直觀概述

 

WebService的幾種概念:

 

以HTTP協議為基礎，通過XML進行客戶端和服務器端通信的框架/組件

 

兩個關鍵點:

1.       服務端提供的功能, 通過xml描述

2.       第一步中的描述的功能, 嵌入到HTTP協議中, 使得能通過HTTP協議進行通信【所謂的SOAP】.

 

用圖可以如下表示:

 

圖一: WebService的簡要表示

 

采用這兩個技術的目的主要是:

1.       跨平台, 支持HTTP協議的主機和服務器, 都能夠建立通信聯系, 並且大部分的主機和服務器(99.999%以上)將支持HTTP協議。一般而言，不同目標主機之間的通信，需要通過防火牆，打開某個端口, HTTP協議的優勢在於，防火牆一般不會封掉80端口, 這樣就可以方便，安全的通信。

 

2.       跨語言, 任何語言, 都支持XML文本解析, 這個的目的是為了實現不同語言之間的通信, 通信的內容，是被xml限制的，因此這樣進行通信，能跨越語言障礙，即, Java開發的服務端，客戶端可以用C訪問, 可以用java，VB等訪問, 反之亦然。

 

第二部分: 基本原理和架構

 

當然，架構比我們上面說到的圖要更為復雜，上面只是說明了一來一回的通信, 實際情況還需要考慮以下問題, 參照圖例說明:

1. 服務器端(Provider) 提供統一的標准化服務。就像開辦一個公司(即Server Provider), 工商行政管理局，注冊一下公司地址和性質。目的是, 別人要用公司的服務，從工商管理局就知道你的地址。這樣統一的做法，是方便所有的公司以及所有需要公司提供服務的客戶。並且這些信息是最大限度的公開。

 

2. 客戶端(Requester) 到注冊中心(Registry)拿到公司的基本信息之后, 去找到這個公司, 然后使用該公司提供的服務。

 

 

圖二: 基本的WebService架構流程圖

 

 

注意上面圖中的基本步驟的標號, 解釋如下

1. Provider節點提供好服務后, 首先注冊到節點Registry

2和3. Requester節點到Regitry節點查信息, 找到需要的Provider及其提供的Service

4. Requester使用Provider提供的服務

 

更具體的介紹, 參照參考文獻[2], 下面這些基本由這個參考文獻翻譯而來:

 

 

圖三: 細節步驟流程圖

上圖這些東西, 完完整整的呈現了WebService的整個原理流程:

1.       Client有需要，想調用一個服務，但不知道哪里去調用. 但知道UDDI Registry上可以查到。

2.       果然UDDI記錄了某個一個叫做Web Server A的服務器能提供這樣的服務。

3.       於是Client去Web Server A, 詢問確切的調用方法。

4.       Web Server A看到Client提出的“確切方法查詢”之后，立即返回給它一個WSDL描述的xml文檔這里記錄他能提供的各類方法接口.

5.       Client了解到這些之后，將這些xml的接口方法，封裝成為HTTP請求, 發給Web Server A. 這些封裝方式采用的是標准的SOAP方式, 實質是滿足HTTP協議的一些SOAP的報文消息。

6.       Web Server A回應的也是HTTP協議的SOAP包. 這樣雙方的請求-響應完全暢通。

 

 

上面我們看到的是應用原理圖, 進一步深入, 可以發現如下的協議架構圖:

 

圖四: 協議結構

 

 

上面我們已經花了很大的精力, 介紹了發現Service(UDDI), Service提供的接口描述(WSDL), 調用Service(SOAP), 以及傳輸(HTTP)的的整個過程。因此不再做介紹。這個技術的核心是SOAP.

 

第三部分: 實踐WebService

 

看到上面的圖那么復雜, 實質上SOAP+HTTP協議已經足夠成熟，犯不着讓我們通過xml生成帶有SOAP變遷的HTML腳本, 有很多工具可以幫住我們實現。事實上，開發起來還是相當簡便的。

情況A: 已知存在Web Service, 客戶端的開發可以通過以下步驟:

 

1. 通過UDDI，查找到Client程序需要的Web Service的位置
2. 通過WebService找到 WSDL接口描述文件
3. 通過工具，將步驟2得到的WSDL文件，生成一個Client Stub, 這個實質上是代碼, 也就是打了一個樁。把這個stub的代碼歸並到Client程序中.
4. 每次Client需要調用WebService的時候，直接調用步驟4生成的Stub 接口，就實現了對Server端的調用。

 

情況B: Server端的開發，同樣無需做解析SOAP這樣的破事，框架會幫我們做好。大致步驟如下:

1. 實現WebServer需要提供的所有功能

2.       利用WSDL文件(或者IDL)生成Server Stub, 這些代碼將負責接收從外界獲得的請求，並將其轉發給Web Server的Service Implementation（實現代碼）。當Service Implementation的代碼處理完，產生結果之后，又會把結果交給Server Stub, 然后 Server Stub可以產生一個SOAP的響應. Server Stub + Server Implementation 合在一起, 稱為Web Service Container, 這玩意兒就是讓發送到WebService的HTTP請求，直接送到Server Stub上面的。

 

 

 

圖五:實際應用中的調用

參考資料:

三：WebService的實現原理

XML+XSD,SOAP和WSDL就是構成WebService平台的三大技術。

1：XML+XSD

WebService采用HTTP協議傳輸數據，采用XML格式封裝數據（即XML中說明調用遠程服務對象的哪個方法，傳遞的參數是什么，

以及服務對象的 返回結果是什么）。
XML是WebService平台中表示數據的格式。除了易於建立和易於分析外，XML主要的優點在於它既是平台無關的，

又是廠商無關 的。無關性是比技術優越性更重要的：軟件廠商是不會選擇一個由競爭對手所發明的技術的。 

XML解決了數據表示的問題，但它沒有定義一套標准的數據類型，更沒有說怎么去擴展這套數據類型。

例如，整形數到底代表什么？16位，32位，64位？

這 些細節對實現互操作性很重要。XML Schema(XSD)就是專門解決這個問題的一套標准。它定義了一套標准的數據類型，

並給出了一種語言來擴展這套數據類型。WebService平台就 是用XSD來作為其數據類型系統的。

當你用某種語言(如VB.NET或C#)來構造一個Web service時，為了符合WebService標准，所 有你使用的數據類型都

必須被轉換為XSD類型。你用的工具可能已經自動幫你完成了這個轉換，但你很可能會根據你的需要修改一下轉換過程。

2：SOAP

WebService通過HTTP發送請求和接收結果。發送的請求內容和結果內容都采用xml格式封裝，並增加了一些特定的HTTP消息頭，

這些特定的HTTP消息頭和xml內容格式就是SOAP協議。

SOAP協議=HTTP 協議+XML數據格式

SOAP協議定義了SOAP消息的格式，SOAP協議是基於HTTP協議的，SOAP也是基於XML和XSD的，XML是SOAP的數據編碼方式。

打個比喻：HTTP就是普通公路，XML就是中間的綠色隔離帶和兩邊的防護欄，SOAP就是普通公路經過加隔離帶和防護欄改造過的高速公路。

3：wsdl

好比我們去商店買東西，首先要知道商店里有什么東西可買，然后再來購買，商家的做法就是張貼廣告海報。 WebService也一樣，

WebService客戶端要調用一個WebService服務，首先要有知道這個服務的地址在哪，以及這個服務里有什么方 法可以調用，

所以，WebService務器端首先要通過一個WSDL文件來說明自己家里有啥服務可以對外調用，

服務是什么（服務中有哪些方法，方法接受 的參數是什么，返回值是什么），服務的網絡地址用哪個url地址表示，服務通過什么方式來調用。

WSDL(Web Services Description Language)就是這樣一個基於XML的語言，用於描述Web Service及其函數、參數和返回值。

它是WebService客戶端和服務器端都能理解的標准格式。因為是基於XML的，所以WSDL既是機器可閱讀的，又是人可閱讀的，

這將是一個很大的好處。一些最新的開發工具既能根據你的 Web service生成WSDL文檔，又能導入WSDL文檔，生成調用相應WebService的

代理類代碼。

WSDL 文件保存在Web服務器上，通過一個url地址就可以訪問到它。客戶端要調用一個WebService服務之前，

要知道該服務的WSDL文件的地址。

WebService服務提供商可以通過兩種方式來暴露它的WSDL文件地址：

1.注冊到UDDI服務器，以便被人查找；

2.直接告訴給客戶端調用者。