【分布计算环境学习笔记】9 Web Service
作者：gnuhpc
出處：http://www.cnblogs.com/gnuhpc/
1.概述：
在現有的各種異構平臺的基礎上，構筑一個通用的，與應用無關、語言無關的技術層，各種不同平臺之上的應用依靠這個技術層來實施彼此的連接和集成，即：傳統的的Web技術解決的問題是如何讓人來使用Web應用所提供的服務，而Web Service則要解決如何讓計算機系統來使用Web應用所提供的服務。從表面上看，Web Service就是一個應用程序，它向外界暴露出一個能夠通過Web進行調用的API。這就是說，你能夠用編程的方法通過Web調用來實現某個功能的應用程序。例如，創建一個Web Service，它的作用是查詢某公司某員工的基本信息。它接受該員工的編號作為查詢字符串，返回該員工的具體信息。你可以在瀏覽器的地址欄中直接輸入HTTP GET請求來調用羅列該員工基本信息的ASP頁面，這就可以算作是體驗Web Service了。從深層次上看，Web Service是一種新的Web應用程序標準，它們是自包含、自描述、模塊化的應用，可以在網絡(通常為Web)中被描述、發布、查找以及通過Web來調用。Web Service便是基于網絡的、分布式的模塊化組件，它執行特定的任務，遵守具體的技術規范，這些規范使得Web Service能與其他兼容的組件進行互操作。它可以使用標準的互聯網協議，像超文本傳輸協議HTTP和XML，將功能體現在互聯網和企業內部網上。Web Service平臺是一套標準，它定義了應用程序如何在Web上實現互操作性。你可以用你喜歡的任何語言，在你喜歡的任何平臺上寫Web Service。
?
?
| RPC 架構 | 客戶機存根 | 服務器存根 |
| CORBA | 存根 | 框架 |
| DCOM | 代理 | 存根 |
| Web 服務 | 服務代理 | 服務實現模板 |
?
Web Service出超的地方：
盡管 CORBA 和 DCOM 已經在各種平臺上得到了實現，然而實際情況是建立在這些協議之上的任何解決方案都依賴于單一廠商的實現。因此，如果要開發一個 DCOM 應用程序，分布式應用程序中所有參與的節點都必須以 Windows 風格運行。如果要開發 CORBA 應用程序，應用程序環境中的每個節點都要運行相同的 ORB 產品。現在也有來自不同廠商的 CORBA ORB 能夠相互操作。但是那種互操作性并不能擴展到像安全與事務管理那樣的更高級別的服務中去。不僅如此，所有特定于廠商的優化在這種情況下將丟失殆盡。這兩種協議都依賴于嚴格管理的環境。要找到能成功地在外部調用 DCOM 或 IIOP 的任意兩臺計算機的幾率比較小此外，程序員們必須處理數據排列和數據類型所需的協議唯一的消息格式規則。DCOM 和 CORBA 都是服務器對服務器通信的合適的協議。然而，它們在客戶機對服務器通信方面都存在嚴重的缺陷，特別是當客戶機遍布因特網時。 我們需要一個建立在開放因特網標準基礎上的新的分布式計算模型。
Web 服務技術提供了一個全新的編程模型來利用開放因特網標準建立分布式應用程序。這一全新的分布式計算解決方案采用特定因特網技術的開放性解決了許多 CORBA 和 DCOM 的互操作性問題。Web 服務技術組件是一套開放的規范，它們要么是現有的因特網標準，要么是被廣泛接受并正在通過正常步驟成為標準的規范。組件的基本部分包含 HTTP、XML、SOAP、WSDL、UDDI 以及 WSFL。這部分的基礎是 HTTP，它是一個被廣泛運用的、類似 RPC 的簡單協議，并且是防火墻友好的。接下來，是 XML 中的通用數據表示法語言，它同樣被廣泛使用。SOAP 是一個基于 XML 的消息傳遞協議，它不確定平臺及語言。它同時支持消息傳遞和請求／響應通信模型。與 CORBA 和 DCOM 一樣，它需要一個 IDL。它所使用的 WSDL 是一個基于 XML 的服務 IDL，定義了服務接口和其實現特征。
特別是，Web 服務
- 使用 HTTP 來實現防火墻友好和不確定有效負載；
- 將 XML 作為一個編碼模式使用，它能比 DR 和 CDR 更為廣泛地被采用；
- 提供關于 HTTP/SOAP 服務器環境的免費的經濟價值建議，或提供關于 ORB 框架的收費的經濟價值建議；
- 使用廣泛深入的 URL 因特網概念來解決對象識別問題；
- 提供的不只是互操作性的承諾。廠商們正積極工作以證明它們的 SOAP 實現確有互操作性。
?
2.XML Web 服務
一個能夠使用XML消息通過網絡來訪問的Interface, 這個Interface描述了一組可訪問的操作，由SOAP+WSDL包裝的Object，服務的行為、輸入/輸出都可使用WSDL描述，適應松散耦合的網絡環境，可通過Web訪問，手段是SOAP Message。
?
3.Web Service 部署在Web上的對象
對象接口描述: WSDL
對象訪問: SOAP
對象界面發現: UDDI
對象實現: EJB, COM+, CORBA以及任何可用于對象實現的技術
?
4.架構
三個參與者：
- 服務提供者（Service Provider）：從企業的角度看，這是服務的所有者。從體系結構的角度看，這是托管訪問服務的平臺。
- 服務請求者（Service Requester）：從企業的角度看，這是要求滿足特定功能的企業。從體系結構的角度看，這是尋找并調用服務，或啟動與服務的交互的應用程序。
- 服務代理（Service Broker）：這是可搜索的服務描述注冊中心，服務提供者在此發布他們的服務描述。在靜態綁定開發或動態綁定執行期間，服務請求者查找服務并獲得服務的綁定信息（在服務描述中）。服務請求者也可以從服務注冊中心以外的其它來源得到服務描述。
三個基本操作
- 發布（Publish）：為了使服務可訪問，需要發布服務描述以使服務請求者可以查找它。
- 查找（Find）：在查找操作中，服務請求者直接檢索服務描述或在服務注冊中心中查詢所要求的服務類型。對于服務請求者，可能會在兩個不同的生命周期階段中牽涉到查找操作，在設計時為了程序開發而檢索服務的接口描述，在運行時為了調用而檢索服務的綁定和位置描述。
- 綁定/調用（Bind/Invoke）：最后需要調用服務。在綁定操作中，服務請求者使用服務描述中的綁定細節來定位、聯系和調用服務，從而在運行時調用或啟動與服務的交互。
?
5.工作過程
服務提供者將所提供的服務發布到服務代理的一個目錄上，服務請求者首先到服務代理提供的目錄上搜索服務，得到如何調用該服務的信息，根據得到的信息調用服務提供者提供的服務。
6.構建過程
?
7.使用過程
8.Web服務的請求過程實例
9.特點
- 完好的封裝性：使用者僅看到Web Service提供的功能列表
- 松散耦合：只要接口不變，其使用方法就不會改變
- 使用標準協議規范：使用開放的標準協議進行描述、傳輸和交換
- 高度可互操作性：可以跨越平臺、語言進行調用
- 高度可集成能力
- 動態性：可以自動發現服務并進行調用
10.分類
- Business-Oriented Web Service：面向企業應用的服務，將企業內部的大型系統，如ERP、CRM系統等，封裝成Web Service的形式在網絡中（Internet or Intranet）提供。企業內部的應用更容易集成；企業間的眾多合作伙伴的系統對接更加容易
- Customer-Oriented Web Service：面向電子商務用戶的服務，主要針對原有B2C網站的改造，Web Service技術為B2C網站增加了Web Service的應用界面，使得桌面工具可以提供跨越多個B2C服務的桌面服務，如將機票預定、炒股等服務集成到一個個人理財桌面系統中使得用戶使用Internet更加方便，能夠獲得更加便捷的服務。
- Device-Oriented Web Service：面向其它接入設備的服務，如手持設備、日用家電等將原有的網絡服務封裝成Web Service，支持除PC以外的各種終端，如天氣預報、E-mail服務、股票信息等。
- System-Oriented Web Service：如用戶權限認證、系統監控等服務，將這些系統級服務封裝成Web Service，發布到Internet或者企業內部的Intranet上，其作用范圍將從單個系統或局部網絡拓展到整個企業網絡或整個Internet上。如一個跨國企業的所有在線服務可以使用同一個用戶權限認證服務。
11.服務標準
- SOAP http://www.w3.org/TR/SOAP
- WSDL http://www.w3.org/TR/wsdl
- UDDI http://www.oasis-open.org/committees/uddi-spec/tcspecs.shtml
a）SOAP——Simple Object Access Protocol
定義：SOAP 是一個簡單的用于在Web上交換結構信息的XML協議。
設計目標: 只提供最必要的功能，簡單性和可擴展性，這意味著傳統的消息系統和分布對象系統的某些性質不是SOAP 規范的一部分。
模塊化和可擴展：沒有應用語義和傳輸語義。
包含：
- 信封 ：消息中包含誰處理消息，是可選還是強制的。
- 數據的編碼規則 ：定義了一套編碼機制用于交換應用程序定義的數據類型的實例。消息可以采用自身特定的XML詞匯，使用namespace來區分彼此。用戶只需要了解SOAP消息的格式，而對底層實現的細節可以無需關心，做到信息隱藏。
??????
- RPC調用規范 ：定義了一個用于表示遠程過程調用和響應的約定。
- SOAP綁定：定義了一個使用底層傳輸協議來完成節點之間交換SOAP信封的約定。
b）WSDL——Web Service Description Language
采用XML語言來描述Web Service的屬性的語言，WSDL文檔可以包含以下內容：What：Web Service做什么；Where：Web Service位于哪里；How：怎樣調用。
Web Service作為一個分布式對象來看，WSDL就是Web Service的接口描述語言（IDL）。WSDL定義了一套基于XML的語法，將Web Service描述為能夠進行消息交換的服務訪問點的集合。
?
c）UDDI
基于標準的服務描述和發現的規范(specification)，以資源共享的方式由多個運作者一起以Web Service的形式運作UDDI商業注冊中心。核心組件是UDDI商業注冊，它使用XML文檔來描述企業及其提供的Web Service。
角色和主要操作：
- Service Provider：提供e-Business Service，通過Service Registry發布(Publish)其提供的可用的Service。
- Service Registry：為Service的發布和定位提供支持，類似電話黃頁。
- Service Requestor：通過 Service Registry發現(Find)需要的Service，綁定(Bind) Service Provider提供的Service, 并實施調用。
與SOAP和WSDL的關系：
- WSDL：Publish的內容、Find的返回結果和Bind的信息都是WSDL描述的服務信息
- SOAP：Service Registry的訪問(Publish/Find)、Service的訪問都是通過SOAP Message實現
數據模型：
任何企業都可以到其中的一個注冊中心去免費注冊企業的信息和提供的服務。注冊中心之間可以同步數據，所以只要到任何一個中心注冊，就可以把自己的企業信息發布到全球所有的注冊中心上。
UDDI 和 SOAP
12.Web Service vs. CORBA/DCOM/EJB 對比
?
從體系結構上講，Web Service不會取代CORBA、COM/DCOM、EJB，四者的概念有所區別：CORBA、COM/DCOM、EJB為分布式應用程序建立服務，通過服務對象來執行客戶端調用的服務，Web Service是基于XML和HTTP通信的的分布式對象模型，SOAP可以作為前三者的對象的通信協議，使用Web Service可以實現使用前三者開發的應用的整合。
從通信協議上講，是競爭的關系：前三者的通信協議規范都定義了傳送信息的語義，對參數和返回值使用二進制編碼，可以對諸如參數名稱或類型的任何元信息都不編碼，這使得中介很難處理消息，又因為每個系統使用不同的二進制編碼，系統間互操作性很難實現。SOAP并沒有定義信息的語義，而是采用XML進行消息編碼，正確的處理需要服務器和客戶端本身來執行，理解和執行彼此使用的信息格式，應用程序本身在語義解析中扮演者十分重要的角色，可以很好的實現互操作性。SOAP和CORBA/DCOM/EJB所使用的底層通信協議（IIOP/DCOM-RPC）是競爭的。
13.應用
B2C的龍頭老大Amazon發布了一套可以通過兩種接口訪問(XML/HTTP以及XML/SOAP)的Web Services，通過這套Web Services，用戶可以使用程序獲取Amazon所提供的各種商品的結構化數據，包括產品名稱、制造商、價格等等。具體的獲取方式包括關鍵詞搜索以及內容樹瀏覽。
GE Global eXchange Services是GE公司的一個組成部分，同時也是基于Internet的B2B電子商務的領導者，在2002年5月1日，它宣布在其為中小企業提供的電子商務事務中提供了Web Services接口。GE Global eXchange Services(GXS)是全球最大的B2B電子商務網絡之一，擁有100,000個貿易伙伴，每年完成10億個商業事務，成交金額達到1萬億美元。
搜索引擎服務商Google發布了一個開發工具包，這個開發工具包使得開發人員可以在自己的應用程序中集成Google搜索，搜索的接口是通過SOAP/WSDL實現的，也就是說Google將他自己的搜索服務包裝成了Web Services，目前這個工具包支持Java和.NET兩種技術，使用范圍被限制在非商業領域，同時單個用戶的使用頻率被限制在每天1000次搜索以內。
?
附錄：
Web Service與組件的比較（From http://book.51cto.com/art/200911/164310.htm）
開發Web Service的主要目的是提供分布式應用的基本框架， 這些分布式應用之間能夠以某些形式進行相互通信，從而促進應用的相互了解、 復用、 開發和集成。乍一看，分布式組件間涉及一些共同的關注事項， 因此很可能將Web Service和組件簡單地視為同一類分布式計算， 僅是風格不同而已。然而， 若對Web Service和組件進行進一步的比較可以發現，分布式組件通常用于開發緊耦合的解決方案， 而Web Service的目的并不是定義一個新的組件模型， 而是定義一個功能分布的服務規范，該規范可以應用于任何已有的組件模型、 編程語言或執行環境。
?
Web Service和組件所支持的集成方案的主要需求是實現多層次的中立性， 通過建立抽象層隱藏端點實現的細節。抽象層既可以實現為Web Service， 也可以實現為組件。對于不同的平臺、 語言、 應用程序組件模型、 事務模型、 安全性模型、 傳輸協議、 調用機制、 數據格式、端點可用性模型等， 集成方案都必須是中立的。這一目標可以很自然地分為下列五個方面： 通信模式、 端點間的耦合類型、 接口類型、 調用類型、代理類型。我們將從這幾方面對Web Service和分布式組件進行一個簡要的對比。
?
通信類型： 分布式組件間的交互基于RPC范式， 通常在多個請求中傳遞少量的數據項， 并且同步地獲取少量的返回數據。在組件方式中， 網絡通信基于細粒度的對象， 這通常是不可靠的， 并且開銷很大。
?
組件使用同步通信， 然而Web Service卻既使用同步通信， 也使用異步通信。對于簡單的Web Service，可以采取RPC類型的請求/響應同步通信， 進行細粒度的對象交互。而對于復合的Web Service， 需要采用更松散的異步通信模式，通常采用基于消息的系統。
?
端點間的耦合類型： 分布式組件依靠緊耦合方式進行交互。在緊耦合的交互中，通常需要調用多個細粒度的API（應用編程接口）。這類緊耦合的交互主要依賴于一點，即設計應用的模型需要能夠得到普遍接受。這迫使客戶端和服務端都需要采用類似的基礎架構， 從而使得分布式組件平臺間不能很方便地進行互操作。例如， CORBA需要所有的應用都遵循接口描述語言（IDL）， 并需要使用對象請求代理，而遠程方法調用（RMI）則需要進行通信的所有實體都是使用Java語言編寫的。對于這類與特定的組件技術緊耦合的實現，在受控環境中是完全可以接受的。然而在Web環境中， 緊耦合的實現將變得不切實際， 并且無法做到可伸縮性。在集成的業務流程中，參與者可能會不斷發生變化， 所采用的技術也可能會不斷發生變化。這就使得保證所有的參與者都采用統一的基礎設施變得非常困難。
?
另一方面， Web Service并不使用特定的應用接口進行相互綁定， 而是使用抽象的消息定義來進行相互間的綁定，即使用消息定義來取代方法簽名。通用的消息定義使得應用程序能獨立處理具體的復雜消息， 從而可以復用接口。由于僅需要處理消息， Web Service完全無須關心具體的語言、 平臺和對象模型， 從而使那些請求該服務的應用可以在任何平臺上使用任何語言來實現。
接口類型： 組件將細粒度的對象層接口暴露給應用程序。在分布式組件方式中， 對于接受者如何激活應用程序，以及對于被調用的這類接口及它們的簽名， 發送者都進行了許多假設。與此相反， Web Service僅需要暴露應用層接口。另一方面， Web Service所使用的消息系統在有線格式（wire format）層形成約定。請求者唯一需要假定的就是接收者能夠理解所發送的消息。請求者既無須假定接受消息后會發生什么，也無須假定發送者和接收者之間可能發生的事情。
?
在Web Service方式中， 應用層接口是粗粒度的接口， 描述了在業務層有用的服務。例如， 在Web Service方式中，庫存服務將暴露庫存補給服務和相關的參數。與基于組件的方式不一樣， Web Service方式不會暴露庫存對象及它的所有接口，也不會暴露補給服務對象和它的接口， 它們與業務應用都沒有直接的關聯。
?
調用類型： 組件通過名稱查找服務， 例如CORBA使用命名上下文（Naming Context， 也稱命名環境）。與此相反， 在Web Service中引入了“服務能力”這一概念。服務能力描述了分類、 功能及發布、 發現和調用特定服務的條件。例如，我們可以發現許多業務可提供的服務的類別， 例如制造或物流服務， 并可基于價格和QoS（包括響應時間、 負載平衡等技術參數）選擇最合適的服務。
請求代理的類型： 分布式計算的傳統方式（例如組件框架）使用預定義的接口來調用遠程對象：使用服務的程序能夠了解目標服務的消息的格式。服務可使用完全不同的綁定方式： 靜態綁定和動態綁定。在靜態綁定中，應用程序在設計時就了解協作服務的各種詳細信息。而在動態綁定中， 應用程序通過服務代理來確定協作服務。
?
Web Service和組件的其他重要的不同方面還包括： 1）Web Service廣泛使用了開放標準， 而組件技術卻缺乏開放標準； 2）Web Service可以提供一些組件技術不具有的高級功能。這些高級功能包括運行時協商的QoS（按照QoS標準，在不同的服務提供者之間進行選擇）、 反應式服務和流程（服務能根據具體的環境進行調整， 并且不會影響運行效率）、 工作流、 協調，以及基于服務的應用程序的事務部件。
綜上所述， 對于體系結構定義明確、 主要面向內聯網和企業內部集成的應用， 最適合使用組件系統構建。例如， CORBA這類的分布式組件技術比較適合構建受控環境中的分布式應用。在這樣的環境中， 所有的分布式實體間可能共享通用的對象模型，并且對分布式實體間通信的粒度大小和通信量的多少沒有限制。此外， 這類環境中的系統部署相對穩定，因此可直接將網絡地址變換為對象引用。對于集成各不相同的端點， 分布式組件技術提供了很好的支持。然而， 對于構建業務流程管理的解決方案，分布式組件技術卻并不適用（至少不是非常適合）。若要構建跨企業的分布式系統， 需要創建技術協議和協調， 然而分布式組件技術很難做到這些。
?
因為Web Service提供了一個語義豐富的集成環境， 所以可以使用Web Service構建企業內部或跨企業的業務流程管理解決方案。Web Service最適合用于實現企業間的共享業務， 然而也可使用Web Service集成企業應用。
?
?
作者：gnuhpc
出處：http://www.cnblogs.com/gnuhpc/
總結
以上是生活随笔為你收集整理的【分布计算环境学习笔记】9 Web Service的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： hive怎样决定reducer个数
- 下一篇： 关于硅谷的文化