信息技術(shù)應(yīng)用之Web服務(wù)最佳實踐之路

申請免費試用、咨詢電話：400-8352-114

一、Web 服務(wù)是什么？

在挑選一組最佳實踐時，最重要的首要步驟之一是要確保用于描述各種核心概念的語言是清楚、簡煉且準確的。例如，SOAP 協(xié)議本身就是 Web 服務(wù)領(lǐng)域中命名不恰當?shù)募夹g(shù)的“典范”：盡管該首字母縮寫代表簡單對象訪問協(xié)議（Simple Object Access Protocol），但是它描述的卻是一個與對象沒有多大關(guān)系并且實現(xiàn)起來也遠非那么簡單的消息傳遞協(xié)議規(guī)范。

W3C Web Services Architecture 小組達成一致意見的 Web 服務(wù)的暫行定義如下所示：

Web 服務(wù)是由 URI 標識的軟件應(yīng)用程序，其接口和綁定可以通過 XML 構(gòu)件進行定義、描述和發(fā)現(xiàn)，Web 服務(wù)支持通過基于因特網(wǎng)的協(xié)議使用基于 XML 的消息與其他軟件應(yīng)用程序直接交互。

還要注意到，W3C 的定義盡管提到了服務(wù)發(fā)現(xiàn)，但并未提到 UDDI 或其他任何特定的發(fā)現(xiàn)機制。具體來說，盡管關(guān)于Web服務(wù)體系結(jié)構(gòu)的早期文獻斷言 UDDI 要扮演一個核心的、至關(guān)重要的角色，但使用 Web 服務(wù)的業(yè)務(wù)解決方案的實際實現(xiàn)卻證明，UDDI 實際上僅在目前這個時候能起到最重要的作用；事實上，人們構(gòu)建了許多并未以任何方式使用 UDDI 的 Web 服務(wù)解決方案。在當前的絕大多數(shù)業(yè)務(wù)案例中，可以有把握地說，這些發(fā)現(xiàn)機制還不是用于集成業(yè)務(wù)伙伴之間的流程的核心組件。

W3C 的 Web 服務(wù)定義具有深遠的影響，這表現(xiàn)在字面上可以被稱作 Web 服務(wù)的東西的范圍包括可以使用 XML 語法唯一地標識和描述的任何軟件組件。這個范圍可能是無限的，對我們概述一組最佳實踐根本沒有任何幫助。術(shù)語 Web 服務(wù)本身難以表示符合寬泛的 W3C 定義的應(yīng)用程序的整個范圍，因為許多這樣的應(yīng)用程序可能永遠不會涉及 Web 或構(gòu)建 Web 時所依托的技術(shù)。盡管如此，我還是必須以某種方式將術(shù)語 Web 服務(wù)包括在我們的術(shù)語集中，因為它已經(jīng)與我們的討論所涉及的技術(shù)領(lǐng)域聯(lián)系在一起了。

Web 服務(wù)（Web services）是使用以下三個主要技術(shù)類別中的一些特定技術(shù)開發(fā)的軟件組件：

基于 XML 的描述格式（例如，WSDL）

應(yīng)用程序消息傳遞協(xié)議（例如，SOAP）

一組傳輸協(xié)議（例如，HTTP）

在上述每個類別中，都有專有（特定于供應(yīng)商或平臺的）技術(shù)和開放（與供應(yīng)商或平臺無關(guān)的）技術(shù)可供使用。

面向服務(wù)的應(yīng)用程序（Service-oriented application）包括可能利用 Web 服務(wù)技術(shù)（如 SOAP）但可能不包括 WSDL 或其他基于 XML 的描述的應(yīng)用程序。這樣的應(yīng)用程序被看作是類似于 Web 服務(wù)的，但從技術(shù)上講它們不是 Web 服務(wù)。

根據(jù)對web服務(wù)的定義，我們可以得出web服務(wù)的大致分類：

企業(yè) Web 服務(wù)（Enterprise Web services）是肯定提供了 WSDL 描述但可能使用專有應(yīng)用程序消息傳遞協(xié)議或傳輸協(xié)議的 Web 服務(wù)。使用 JMS 通過 IBM MQSeries 發(fā)送 SOAP 消息的 Web 服務(wù)就是這種服務(wù)的一個示例。

因特網(wǎng) Web 服務(wù)（Internet Web services）是必須僅使用開放的應(yīng)用程序消息傳遞協(xié)議或傳輸協(xié)議的企業(yè) Web 服務(wù)。通過 HTTP 發(fā)送 OTA XML 消息的企業(yè) Web 服務(wù)就是這種服務(wù)的一個示例。

XML Web 服務(wù)（XML Web services）表示因特網(wǎng) Web 服務(wù)的一個很小的子集，這類服務(wù)必須使用已經(jīng)被 W3C 采用的、通過為數(shù)不多的幾種傳輸協(xié)議進行傳遞的、基于 XML 的消息傳遞協(xié)議。具體來說，XML Web 服務(wù)將只發(fā)送 SOAP 消息，并且只能通過 HTTP、SMTP 或原始 TCP/IP 連接來發(fā)送這些 SOAP 消息。

二、使用web服務(wù)
 
1、確認 Web 服務(wù)的使用

在解決方案組件之間的邊界上使用 Web 服務(wù)是不合適的。實際上，需要有意識地作出在什么地方利用 Web 服務(wù)的決定，而且應(yīng)該基于處理業(yè)務(wù)需要的技術(shù)需求來作出這些決定。在某些情況下，這些決定將包括折衷方案，但是通過收集適當?shù)男枨蟛ζ浯_定優(yōu)先級，這些選擇中的許多都將是明顯的、容易證明其合理性。 例如，與 Internet 之上的業(yè)務(wù)合作伙伴的應(yīng)用程序之間的互操作性可能具有比達到最佳性能更高的優(yōu)先級；因而，XML Web 服務(wù)是合理的。同樣地，從安全性的角度考慮，使用 SSL 來確保在 Internet 上交換消息的真實性和機密性可能就足夠了。與之相對的是，當您考慮對后者的性能影響時，就需要在應(yīng)用程序終端本身之間通過使用 XML 加密（XML Encryption）和 XML 數(shù)字簽名（XML Digital Signatures）來提供這個級別的保護。
 
Web 服務(wù)應(yīng)該只使用在具有明確的需求來證明它們是合理的地方。這種合理性本質(zhì)上可以是定量的（互操作性可能存在于具有不同程序設(shè)計模型的異構(gòu)系統(tǒng)之間），也可以是定性的，比如，根據(jù)公司的策略來配置您的企業(yè)資產(chǎn)將為以后帶來可度量的好處（例如，重用遺留代碼以使 J2EE、.Net 和 Web 應(yīng)用程序能夠提供集成服務(wù)）。很容易證明在內(nèi)聯(lián)網(wǎng) Java 應(yīng)用程序之間使用企業(yè) Web 服務(wù)是合理的，因為通過使用現(xiàn)在的 J2EE 運行時和解析器，RMI/IIOP 提供了比 SOAP/HTTP 更好的性能。
 
2、服務(wù)的粒度

一旦需求表明 Web 服務(wù)是一項可行的集成技術(shù)，下一步就是確定如何最好地利用它們來獲取最多的好處。這包括決定作為 Web 服務(wù)公開的函數(shù)的粒度來避免跨 Internet 的不必要的消息交換。作為一條性能規(guī)則，應(yīng)該努力發(fā)布本身接受所有必需的參數(shù)和信息的粗粒度服務(wù)，從而使得服務(wù)提供者能夠代表消費應(yīng)用程序（consuming application）提供盡可能多的服務(wù)。目的是將顧客為了完成一組業(yè)務(wù)任務(wù)所發(fā)出的請求數(shù)目減到最少。這將確保網(wǎng)絡(luò)延時、系統(tǒng) I/O 以及線程/進程等待狀態(tài)所帶來的影響（當多個請求同時發(fā)出時，它們共同產(chǎn)生的延時可能是很大的）最小。例如，可能會通過允許消費者在單個請求中指定產(chǎn)品 SKU 編號、數(shù)量、信貸卡信息、配送地址信息以及折扣卷等所有信息來考慮支持購買訂單服務(wù)。請求本身可能在服務(wù)提供者處開始多個原子事務(wù)（信用卡授權(quán)、費用提交、庫存查詢和更新、以及訂購?fù)瓿桑?。在支持整個業(yè)務(wù)流程的同時，如果需要，每個事務(wù)都可以被取消或撤銷。
 
三、Web 服務(wù)的性能瓶頸

無疑地，目前基于 Web 服務(wù)的解決方案中的三個最普遍的瓶頸涉及：

·SOAP 消息的解析。消息越大，解析它所需要的時間就越長。

·對象到 XML 以及 XML 到對象的編組和解組。消息的結(jié)構(gòu)越復(fù)雜，程序設(shè)計的對象和 XML 元素之間的映射需要的時間就越長。

·包括 XML 數(shù)字簽名（XML Digital Signatures）和 XML 加密（XML Encryption）的 Web 服務(wù)安全性（WS-Security）功能的處理。應(yīng)用程序終端之間的安全性并不是不受任何事情影響的，并且可能會驚人地延長處理服務(wù)請求的時間。

表示這些功能的 Web 服務(wù)組件如圖 1 所示，它們用于處理 Web 服務(wù)請求。

 
2、文檔/文字與 RPC/SOAP 編碼

只要可能，就應(yīng)該將文檔/文字消息傳遞方式用于您的 Web 服務(wù)，原因有二。首先，它促進了符合 Web 服務(wù)互操作性（WS-I）基本概要 1.0 的互操作性。第二個原因與本文所討論的性能有關(guān)。文檔/文字會產(chǎn)生更小、更簡單的消息：在 SOAP 消息體中 的 XML 數(shù)據(jù)不必用方法名稱元素來封裝，并且沒有數(shù)據(jù)類型屬性被嵌入到 XML 元素中去。文檔/文字消息傳遞方式的另一個好處是目前的集成開發(fā)環(huán)境（WebSphere Application Studio Development）和運行時（WebSphere Application Server）支持用于對象和 XML 元素編組的 JAX-RPC 序列化器和反序列化器例程，這些例程是專門根據(jù)基于 WSDL 所包含 的 XML Schema 進行最優(yōu)化的，同與 SOAP 編碼相關(guān)聯(lián)的序列化器和反序列化器相對。
 
3、 SOAP 消息的解析
 
3.1 最小化 XML 數(shù)據(jù)的解析

如果業(yè)務(wù)功能以 XML Web 服務(wù)的形式公開，并且 Web 服務(wù)對于內(nèi)部消費（EAI）和業(yè)務(wù)合作伙伴的外部消費（B2B）都利用 SOAP，那么像網(wǎng)關(guān)或服務(wù)代理這樣的中介就應(yīng)該避免或最小化 SOAP Body 的解析。如果使用網(wǎng)關(guān)組件來將對 Web 服務(wù)的訪問集中到 Internet，而又不需要網(wǎng)絡(luò)傳輸或消息處理（比如 SOAP/HTTP 到 RMI/IIOP），那么網(wǎng)關(guān)就不應(yīng)該執(zhí)行 SOAP 體的解析。目前，許多系統(tǒng)管理供應(yīng)商提供實際的 Web 服務(wù)的前端服務(wù)代理。這些組件在提供它們的系統(tǒng)管理功能時依賴于 SOAP 體內(nèi)部的業(yè)務(wù)上下文信息，比如業(yè)務(wù)伙伴 ID、事務(wù)相關(guān)器、消息 ID、以及授權(quán)代碼。通過使用業(yè)務(wù)上下文，服務(wù)代理可以提供關(guān)于業(yè)務(wù)事件的統(tǒng)計，執(zhí)行加強業(yè)務(wù)政策以及路由請求來兌現(xiàn)服務(wù)質(zhì)量承諾。最近，WebSphere Application Server V5.1 中的 Web Services Gateway 開始支持 SOAP 消息的部分解析。同樣地，系統(tǒng)管理供應(yīng)商經(jīng)銷商近來也開始提供可以部分地解析 SOAP 消息的功能，以將它們對性能的影響降到最小，因此利用這些功能是至關(guān)重要的。
 
3.2 DOM 與 SAX 解析

文檔對象模型（Document Object Model，DOM）是由萬維網(wǎng)聯(lián)盟（World Wide Web Consortium，W3C）開發(fā)的基于對象的編程接口。它使程序員能夠訪問以節(jié)點樹的形式存儲在 XML 文檔中的數(shù)據(jù)。另一方面，SAX（Simple API for XML）是基于事件的編程接口，它是由 XML-DEV 郵件發(fā)送列表的成員提供的。SAX 使程序員能夠訪問在 XML 文檔中作為事件序列的數(shù)據(jù)。因為 Apache Xerces2 Java parser 支持這兩個編程模型，所以您可以輕松地為您的程序員從中選擇最適合您的需求的模型。兩個接口都可以使程序員能夠處理 XML；然而，它們執(zhí)行任務(wù)的方式卻相差很多。DOM 在內(nèi)存中創(chuàng)建一個對象樹，不考慮 XML 元素的數(shù)據(jù)類型。整個 XML 文檔都在內(nèi)存中表示。因此，這種方法需要更大的內(nèi)存，對于非常大的 XML 文檔來說，它并不認為是最好的方法。相反，SAX 是事件驅(qū)動的，并且不要求整個文檔都在內(nèi)存中。然而，程序員必須創(chuàng)建他們自己的對象模型并管理 SAX 事件。因此，雖然最后得到的對象模型很簡單，但是 SAX 比 DOM 的解析速度快。如果您使用的是 Xerces parser，推薦您確保使用的是最新的版本（V2.6.0 與 1.4.0），因為在過去的一年里加進了重要的性能增強。
 
需要說明的是，在 WebSphere Application Server 的 SOAP 解析方面的改進（如圖 2 所示）部分地源于向 SAX parsing 轉(zhuǎn)變的結(jié)果。
如果您的解決方案利用處理時間的 35% 以上來解析 SOAP 消息，不要感到驚訝。記住，您正使用 Web 服務(wù)來支持互操作性并改進運行成本和資產(chǎn)重用。
 
4、 編組和解組對象和 XML

用于消息的對象和 XML Schema 越復(fù)雜，客戶端和服務(wù)提供者所需的處理就越多?？蛻舳嗽诎l(fā)布請求之前將不得不把它們的編程對象編組成 XML 元素，而服務(wù)提供者不得不在處理請求的過程中將 XML 元素映射到編程對象。如果在為請求和響應(yīng)消息設(shè)計您的數(shù)據(jù)時不作出有意識的決定，那些用數(shù)組的數(shù)組構(gòu)造的對象或者由嵌套元素的嵌套元素組成的 XML 元素將必定成為瓶頸。目前，很多公司都在使開放式應(yīng)用程序組信息系統(tǒng)（Open Application Group Information System，OAGIS）的業(yè)務(wù)對象文檔（Business Object Document，BOD） 的使用標準化。用于這些 XML 文檔的 XML Schema 包含幾個層次的嵌套 XML 元素，因此當使用這些 BOD 時，您需要估計它們對整體性能可能造成的影響，這一點很重要。推薦選擇在您的解決方案中使用什么 BOD。
 
設(shè)計消息以便最大化正在交換的實際信息的數(shù)量同樣重要。具有很多元素和屬性以及很少數(shù)據(jù)的消息常常導(dǎo)致復(fù)雜的 XML Schema。最常見的是，SOAP 消息的解析被看作是造成 Web 服務(wù)中的性能問題的主要方面。然而，一個復(fù)雜的消息結(jié)構(gòu)同樣也可能導(dǎo)致多于 50% 的處理時間與 Object 和 XML 元素的編組和解組相關(guān)聯(lián)。
 
5、 選擇安全性方法

在實際解決方案中，所有機密的或者具有市場價值的信息在開放的 Internet 上傳輸時都必須被小心地保護。這常常通常意味著，信息的發(fā)送者和接收者都必須經(jīng)過驗證（雙方的檢驗），確保消息的真實性和完整性（檢驗消息是否已經(jīng)更改），并且保持消息的機密性（進行加密以防其內(nèi)容為預(yù)定的接收者以外的人所獲悉）。提供消息的安全性可能涉及非常復(fù)雜的過程，但是目前在業(yè)界有一些可用的方案。對于 IT 架構(gòu)師和 IT 專業(yè)人員來說，問題就是決定哪種方法可以最好地滿足他們的需求，然后配置中間件和基礎(chǔ)架構(gòu)組件來啟用這些安全特征。
 
傳統(tǒng)上，網(wǎng)絡(luò)節(jié)點之間的安全性是通過在 Web 服務(wù)器和應(yīng)用程序服務(wù)器中使用 HTTP（HTTPS）之上的 SSL 來提供的。通過使用 HTTPS，您可以執(zhí)行消息的發(fā)送者和接收者的相互認證，從而確保消息的機密性。這個過程涉及及 X.509 證書，它是在連接的兩端配置的，并且一般與網(wǎng)絡(luò)節(jié)點相關(guān)聯(lián)（部署消費者和服務(wù)提供者的系統(tǒng)或者托管 SOAP 中介的網(wǎng)關(guān)系統(tǒng)）。

當從一端到另一端直到整個應(yīng)用程序棧都需要安全性的時，或者當安全性必須獨立于網(wǎng)絡(luò)傳輸協(xié)議時，就必須考慮其他的方法。Web 服務(wù)安全性（WS-Security）通過 XML 數(shù)字簽名（XML Digital Signature）提供驗證和消息的完整性，通過 XML 加密（XML encryption）提供消息的機密性，在這兩個實例中都使用 X.509 認證。然而，必須根據(jù)全部的需求來理解和評估性能的權(quán)衡?；蛟S這樣說比較保險，通過Web 服務(wù)安全性（WS-Security）技術(shù)來支持安全性的成本至少是使用傳統(tǒng)的用 HTTP 的 SSL 提供相似功能的兩倍。然而，如果在處理您的請求中使用的業(yè)務(wù)邏輯和數(shù)據(jù)庫也占您的執(zhí)行時間的大部分（解析和序列化除外），那么這兩個安全性方法的差別就不足以擔保任何的利害關(guān)系了。
 
常見的實踐是結(jié)合這兩種方法，使用 SSL 來加密，然后使用 XML 數(shù)字簽名（XML Digital Signature）來驗證應(yīng)用程序端點并確保消息的完整性。請謹記，SSL 將至少包括對消息要發(fā)送到的服務(wù)器的一項驗證，因而就會產(chǎn)生一些冗余。您的業(yè)務(wù)和技術(shù)的需求以及利弊權(quán)衡的評估都將指導(dǎo)您從這三個可選方案中找到一個可行的方案。
 
成功地最優(yōu)化 Web 服務(wù)的性能，部分是經(jīng)驗，部分是藝術(shù)，部分是您用于度量標準、分析信息以及合理調(diào)整的方法的系統(tǒng)訓(xùn)練。首先，正如前面所描述的，您必須在您的體系結(jié)構(gòu)和設(shè)計階段作出合適的決定。然后，一旦您擁有了可操作的解決方案，您就需要從模擬負載中獲取度量標準、作出調(diào)整、再次度量以理解它們的影響，從而精細地地調(diào)整您的解決方案，這是一個反反復(fù)復(fù)的過程。

來源：AMT