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

申請(qǐng)免費(fèi)試用、咨詢電話：400-8352-114

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

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

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

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

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

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

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

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

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

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

在上述每個(gè)類別中，都有專有（特定于供應(yīng)商或平臺(tái)的）技術(shù)和開放（與供應(yīng)商或平臺(tái)無關(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ù)對(duì)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ù)的一個(gè)示例。

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

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

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

在解決方案組件之間的邊界上使用 Web 服務(wù)是不合適的。實(shí)際上，需要有意識(shí)地作出在什么地方利用 Web 服務(wù)的決定，而且應(yīng)該基于處理業(yè)務(wù)需要的技術(shù)需求來作出這些決定。在某些情況下，這些決定將包括折衷方案，但是通過收集適當(dāng)?shù)男枨蟛?duì)其確定優(yōu)先級(jí)，這些選擇中的許多都將是明顯的、容易證明其合理性。 例如，與 Internet 之上的業(yè)務(wù)合作伙伴的應(yīng)用程序之間的互操作性可能具有比達(dá)到最佳性能更高的優(yōu)先級(jí)；因而，XML Web 服務(wù)是合理的。同樣地，從安全性的角度考慮，使用 SSL 來確保在 Internet 上交換消息的真實(shí)性和機(jī)密性可能就足夠了。與之相對(duì)的是，當(dāng)您考慮對(duì)后者的性能影響時(shí)，就需要在應(yīng)用程序終端本身之間通過使用 XML 加密（XML Encryption）和 XML 數(shù)字簽名（XML Digital Signatures）來提供這個(gè)級(jí)別的保護(hù)。
 
Web 服務(wù)應(yīng)該只使用在具有明確的需求來證明它們是合理的地方。這種合理性本質(zhì)上可以是定量的（互操作性可能存在于具有不同程序設(shè)計(jì)模型的異構(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ù)是合理的，因?yàn)橥ㄟ^使用現(xiàn)在的 J2EE 運(yùn)行時(shí)和解析器，RMI/IIOP 提供了比 SOAP/HTTP 更好的性能。
 
2、服務(wù)的粒度

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

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

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

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

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

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

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

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

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

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

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

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

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

來源：AMT