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.直接告訴給客戶端調用者。