官术网_书友最值得收藏!

2.2 Web服務技術

Web原本是蜘蛛網和網的意思。在互聯網中,Web指的是一種基于網站(Website)的使用環境,是網站的前臺布局、后臺程序、數據庫和用戶訪問等一系列技術的總稱。網站是一種信息工具,就像布告欄一樣,人們可以通過網站來發布自己想要公開的信息,或者利用網站來提供相關的網絡服務。人們可以通過網頁瀏覽器來訪問網站,獲取自己需要的信息或者享受網絡服務。

Web服務(Web Service)是基于Web技術,在互聯網上提供的一套分布式可互操作的應用程序(服務)及其標準,定義了多種應用程序如何在互聯網上實現互操作,具有平臺獨立、松耦合、自包含等特點。在依據Web Service規范實施的應用程序之間,無論它們所使用的語言、平臺或內部協議是什么,都可以相互交換數據,從而使得互聯網中運行在不同機器上的不同應用程序無須借助附加、專門的第三方軟件或硬件,就可以相互交換數據或進行集成。Web Service使用開放的XML來描述、發布、發現、協調和配置這些應用程序。

進行Web服務開發的核心技術是WSDL,它使用端口類型或者通用服務接口來描述Web服務。服務接口描述了服務支持的各種操作,以及每個操作輸出的和輸入的消息結構。服務描述能夠告訴客戶端互聯網中的服務提供哪些功能,以及如何調用它們。相比面向對象的軟件設計架構CORBA(Common Object Request Broker Architecture,公共對象請求代理體系結構)中的接口定義語言(IDL),WSDL能夠用于自動生成面向編程語言的架構,這些架構通過隱藏發布的細節來簡化服務開發過程。然而,服務接口的描述并不充分,因為它缺少服務支持的交互過程順序消息集合的描述,以及其他在操作調用上的約束。

我們使用的Web服務協議是對客戶端和服務端之間正確交互作用集合的定義。服務模型非常重要,因為它們允許應用開發者能夠正確開發與服務交互的客戶端。因此,包含服務協議規范的服務描述是十分重要的。另外,也有必要擴展服務描述語言,從而支持消息調用的正確順序及其屬性(包括WSCL、WSCI、BPEL4WS、WS-Coordination等)的約束。

Web服務策略(WS-Policy)是Web服務抽象中的另一個重要部分。明確描述服務策略的需求比傳統應用集成更為重要,因為Web服務將會基于各種策略在動態和自治環境中潛在運行。這方面的工作包括制定WS-Security、WS-Policy、WS-Security Policy等規范。這些規范僅規定了將策略需求具體化的XML語法,但是不能解決如何對這些需求進行建模或管理的問題。因此,還需要一個高級架構,以利于開發者使用服務策略規范工具和自動化服務策略進行服務生命周期的管理。

Web服務的另一個重要的特性是,一旦各種應用功能以Web服務的形式提供給用戶,就會大大降低其異構性。當服務被描述并以一種標準化的方式交互時,通過組合其他服務來開發復雜服務的任務就相對簡單了。事實上,隨著服務相關技術的成熟,人們期望服務組合能夠在服務開發工作中發揮越來越大的作用。由于服務會在其組成部分的組裝和事務到事務之間的交互過程中被查找,其功能和策略需要以這樣的方式來描述:客戶端可以發現它們并且評估其組裝和交互的適應性。

針對Web服務協議和策略,目前已有的服務組裝語言和工具已經成熟。其中,最重要的規范是服務流程執行語言(Business Process Execution Language,BPEL),它是一種用于自動化服務流程的形式規約語言,能夠自動生成代碼和外部規范。用XML文檔寫入BPEL中的流程能在Web 服務之間以標準化的交互方式形成服務流程。而且,這些流程能夠在任何一個符合BPEL規范的平臺或產品上執行。因此,通過允許顧客在各種各樣的創作工具和執行平臺之間移動和使用這些流程,BPEL保護了他們在流程自動化上的已有投資。

2.2.1 Web服務架構(WSA)

WSA(Web Service Architecture,Web服務架構)將Web服務技術放在上下文(Context)體系中考慮并簡化其關系。WSA協議棧包含大量Web服務協議的子集,這些協議設計用來支持Web服務應用的服務質量(QoS)。

簡單對象訪問協議(Simple Object Access Protocol,SOAP)是Web服務默認的消息傳輸協議,是WSA協議棧中底層的協議。SOAP頭部使得高層Web服務協議能夠簡單地集成到其基礎消息交換協議中。

每個協議的頭部都是被單獨處理的,允許軟件代理在Web服務中接收到消息時執行協議規定的活動。相似地,當服務發送消息時,協議特定的代理可能會加入任何必要的頭部,并重寫到消息中任何合適的地方。SOAP頭部的內容是不固定的,這就允許Web服務能夠有效地確定其協議棧。統一包含在Web服務協議棧中的協議如圖2-7所示。

img

圖2-7 統一包含在Web服務協議棧中的協議

WSA具有以下特性。

1.可組合性

盡管多種協議規范可能被組合到一起來實現某些復合行為,但每個協議規范都是獨立設計的。也就是說,盡管一個給定的協議規范為了提供額外可選的功能而用到了另一個協議規范,但是這些協議規范之間并沒有必需的依賴關系。

2.面向消息

WSA中的各種協議規范均體現為消息和消息交換形式的規定,沒有任何結構性或者服務實現技術方面的額外規定。

任何具有這類特性的Web服務協議都可以與其他Web服務協議交互工作,從而支持特定QoS的消息交換。然而,Web服務組合方法的松耦合特性意味著Web服務系統是非集中式管理的,雖然有中心可能有助于在跨越整個應用的QoS協議時保持一致性,但這樣會導致每個Web服務都不能正確解釋和處理其中的QoS協議消息。

3.傳輸獨立性

在SOA的架構中,雖然在Web服務傳送消息可以使用HTTP作為傳輸協議,但在Web服務激增的早期階段及現在都不是必須使用HTTP協議的。目前,大多數的Web服務規范都是基于SOAP消息交換形式來定義的,而與任何特定傳輸層協議無關。正如人們所理解的那樣,Web服務與Web是解耦的。

不依賴特定傳輸層協議的SOAP消息實現了消息級別的尋址。像WSAddressing和WS-Message Delivery這樣的協議允許在消息中加入尋址信息,在SOAP消息中封裝為頭部子塊,在消息傳輸的過程中綁定到下面的傳輸層尋址機制中。結果是SOAP消息可以利用任何傳輸層協議在網絡中傳送,如圖2-8所示。

img

圖2-8 加入地址的獨立SOAP傳輸

4.消息路由

基于傳輸層協議獨立和可擴展的消息傳輸機制,可以定義其他高層消息協議,如組播和可靠消息交付協議。這樣的協議允許Web服務交換信息的方式超越傳統的點到點消息交換方式。

5.元數據

Web服務的類型結構如圖2-9所示。從圖2-7中可以看出元數據和策略元素棧管理描述服務的方式。特別是,WSDL描述消息格式和服務期望參與的消息交換形式,而且可選策略規定了許可消息或者其他QoS特性的內容約束條件。

img

圖2-9 Web服務的類型結構

訪問一個Web服務的元數據,傳統上是一個特設事務,都在Web服務的URL上發起一個HTTP GET來獲取Web服務的WSDL約定。雖然該機制現在已經標準化,但仍然是基于具體傳輸協議的,因此不是Web服務的最好方式。WS-Metadata Exchange規范被認為是從相關的Web服務獲取WSDL約定和策略的SOAP友好方法。

6.QoS協議

如果沒有任何協議來提供適當級別的服務質量(QoS)保證,Web服務將不會是一個部署可靠計算系統的有效方法。WSA中的QoS協議解決了可靠性系統的重要問題,而且是通過增加底層面向消息結構的消息安全性、可靠消息及事務的方式實現的。雖然這些討論僅限于安全、可靠消息交付和事務,但支持的原則同樣適用于其他QoS協議。

7.安全性

雖然“安全”是一個廣義術語,但是,在Web服務領域,安全性的討論僅限于消息傳輸方面。WS-Security支持Web服務之間的私有、防篡改、驗證和不可否認的消息交互??紤]到消息交互在通過包括互聯網在內的任意網絡時,這些屬性是極為重要的。如果機密信息被泄露,或者如果郵件內容在中途被改變,結果可能是災難性的。確定郵件的發件人是同樣重要的,因為它可能會影響是否接收Web服務及如何處理該消息。

在Web服務領域,允許Web服務中間件屏蔽底層網絡中的故障,以便提供盡力將消息交付給Web服務(例如,WS-ReliableMessaging)的能力。

2.2.2 Web服務分析

典型的Web服務系統結構是多層次的,它包括信息傳輸、處理、服務邏輯及在運行時環境承載的資源層。Web服務的實現將其中許多Web服務協議與某些服務特定的邏輯相結合,并將預期的功能交付給網絡。

宿主(Hosting)環境可以是任何的計算機系統,例如,從一個單一的操作系統過程到Web服務器(如IIS或Apache),到整個應用的服務器群的部署(基于Web Sphere)。宿主環境只需要提供信息處理能力的執行上下文,就能夠啟動處理過程以響應消息的接收。

傳輸層完成輸入、輸出消息的處理和路由事件。它通常是實現一個或多個通信協議(例如,內存中的交換、TCP、UDP、SMTP、HTTP等)的特定基礎設施中間件。

信息處理層的功能是使用底層傳輸協議傳遞SOAP消息,以及根據該消息的內容執行任何必要轉換或特定協議行動。此外,還提供抽象揭示底層消息傳遞活動的可編程抽象。服務邏輯通過這些抽象綁定到底層應用和基礎設施協議上。SOAP消息處理器結構如圖2-10所示。

此外,信息處理層還為Web服務邏輯提供必要的執行上下文,以便提取和處理包含具體協議的SOAP消息頭部。根據部署或服務對所有傳出的SOAP消息的具體要求,引入了協議特定的頭文件。典型的消息處理器(見圖2-10)將允許以“handler”或“plug-in”兩種方式沿兩個邏輯消息處理管道(一個用于接收消息,另一個用于發送消息)來處理SOAP消息。任何需要handler傳播到服務實現的消息都是在對郵件正文處理過程中完成的,一般來講是通過在handler(處理程序)和服務邏輯之間共享執行上下文來實現的,通常每個handler實現一個SOAP中間代理(如每個SOAP處理模型)。

img

圖2-10 SOAP消息處理器結構

主站蜘蛛池模板: 德阳市| 沽源县| 黄浦区| 四会市| 镇雄县| 加查县| 瑞丽市| 咸丰县| 海安县| 嵊州市| 巴里| 汝城县| 泾源县| 监利县| 黄石市| 平安县| 德江县| 临邑县| 张掖市| 罗源县| 葵青区| 阳新县| 北海市| 宁城县| 湘阴县| 化德县| 宁安市| 浙江省| 南岸区| 清水县| 佳木斯市| 卢氏县| 鹤山市| 宣恩县| 林口县| 固安县| 佛学| 万荣县| 孝义市| 子洲县| 台山市|