信息技術應用之Web服務最佳實踐之路

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

一、Web 服務是什么？

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

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

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

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

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

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

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

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

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

在上述每個類別中，都有專有（特定于供應商或平臺的）技術和開放（與供應商或平臺無關的）技術可供使用。

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

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

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

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

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

二、使用web服務
 
1、確認 Web 服務的使用

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

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

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

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

·對象到 XML 以及 XML 到對象的編組和解組。消息的結構越復雜，程序設計的對象和 XML 元素之間的映射需要的時間就越長。

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

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

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

只要可能，就應該將文檔/文字消息傳遞方式用于您的 Web 服務，原因有二。首先，它促進了符合 Web 服務互操作性（WS-I）基本概要 1.0 的互操作性。第二個原因與本文所討論的性能有關。文檔/文字會產生更小、更簡單的消息：在 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 編碼相關聯(lián)的序列化器和反序列化器相對。
 
3、 SOAP 消息的解析
 
3.1 最小化 XML 數(shù)據(jù)的解析

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

文檔對象模型（Document Object Model，DOM）是由萬維網聯(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í)行任務的方式卻相差很多。DOM 在內存中創(chuàng)建一個對象樹，不考慮 XML 元素的數(shù)據(jù)類型。整個 XML 文檔都在內存中表示。因此，這種方法需要更大的內存，對于非常大的 XML 文檔來說，它并不認為是最好的方法。相反，SAX 是事件驅動的，并且不要求整個文檔都在內存中。然而，程序員必須創(chuàng)建他們自己的對象模型并管理 SAX 事件。因此，雖然最后得到的對象模型很簡單，但是 SAX 比 DOM 的解析速度快。如果您使用的是 Xerces parser，推薦您確保使用的是最新的版本（V2.6.0 與 1.4.0），因為在過去的一年里加進了重要的性能增強。
 
需要說明的是，在 WebSphere Application Server 的 SOAP 解析方面的改進（如圖 2 所示）部分地源于向 SAX parsing 轉變的結果。
如果您的解決方案利用處理時間的 35% 以上來解析 SOAP 消息，不要感到驚訝。記住，您正使用 Web 服務來支持互操作性并改進運行成本和資產重用。
 
4、 編組和解組對象和 XML

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

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

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

來源：AMT