構建面向服務的架構 （ SOA ， Service-Oriented Architecture ） 包含創建支持業務實踐的多個服務。其優點是使用多個服務可以讓企業更加靈活，并且能更好地對快速變化的競爭條件作出響應。構建服務可以提高現有應用程序的效率，并使得構建新的應用程序更容易。
許多企業（大約 70% ，據 Gartner 統計）都是既使用 Java 平臺又使用 Microsoft 平臺。理想情況下，這種平臺的混合不應該影響 SOA �？稍谝粋�平臺編寫服務，而客戶應用程序可以使用同一平臺或另一種平臺。這是用 SOA 方法構建應用程序的最重要優點之一，即可將許多不同技巧應用于創建服務，而且甚至還可修改遺留應用程序組件，將它作為服務運行。
理論上這無疑是正確的。在客戶應用程序和服務之間惟一需要的公共元素是發送、接收和解碼 SOAP 消息的能力。當然，還有比這更多一點的要求，即客戶和服務都必須在這些消息的模式上達成協議，或者提供像 Web service 描述語言（ WSDL ， Web Services Description Language ）這樣的機制，讓客戶來確定合適的模式。
但通常，松耦合的應用程序組件概念很少要求協作。假設已經協商好了模式，那么客戶應用程序與服務之間的通信就可以進行。
除非它不行時。這聽起來可能有點矛盾，但是實際上它是指對事物完全了解的一種狀態。應用程序里的許多東西可能會出錯，通常源于拙劣的需求分析、糟糕的設計、編碼中的錯誤和導致性能或可擴展問題的無效的東西。所有這些問題以及更多的問題都可能在將服務與一個或多個客戶結合時發生。
這里僅僅是客戶應用程序開發人員在使用 Web service 時可能會遇到的一些問題的幾個例子：徹底失效——這可能意味著它有 Bug 或對象泄漏；返回錯誤回答——這可能是邏輯錯誤或意外行為；返回結果時太慢——它是 Web service 還是數據庫；進一步縮小范圍對應用程序開發人員而言太困難了；它不能擴展——在許多情況下，這是由于直到加載應用程序之前才發現的低效代碼或瓶頸造成的。
當 Web service 采用與客戶應用程序不同的平臺時，這些問題更加復雜。如前所述， Web service 的一個關鍵優點是其概念是平臺是不可知的�？梢杂萌魏握Z言在任何平臺上編寫 Web service ，這使得 Web service 存在以下問題：構建客戶應用程序的任何開發人員小組都要能理解和評估其應用程序所調用服務的強度和限制。
即使客戶平臺和服務平臺是不同的，除了 Web service 通常由構建應用程序之外的一組人員開發和維護以外，這些聽起來仍像是圍繞應用程序開發的普通問題。使用 Web service 的一些應用程序開發人員缺少對應用程序細節的洞察，甚至不了解構建服務的平臺。
當然，可以就這樣假定它，但實際上，那些構建客戶應用程序的人對于 Web service 的工作細節也的確有很好的技術鑒賞力。這可能有助于解決如何調用服務以及調用服務的頻率等有關問題，比如，或者它能夠幫助開發人員解決服務本身所固有的問題。
后一個原因代表真正的問題——在除了知道所需的輸入和期望的輸出以外不了解 Web service 其他任何東西的情況下使用 Web service 。應用程序開發人員經常對分析和診斷他們所遇到的 Web service 問題感到迷茫。如果很少看見或根本看不見 Web service ，并且應用程序不能像預期的那樣工作或者執行的話，那么開發人員可能只能分析他們自己編寫的代碼，而不是分析整個應用程序。對應用程序開發人員而言， Web service 就是暗面。
窺探 Web service
讓我們近距離看一下企業中的典型場景可能是怎樣的。一種情況是當 Web service 在 Java 平臺上運行，同時客戶機應用程序使用 Microsoft .Net 技術的時候。在這個例子中，客戶應用程序無法擴展到需要的用戶數。實際上，在實際使用中，它只同時支持 10 個用戶，而要求是同時支持 100 個用戶。特別是，在只有 10 個用戶時，它最終還是癱瘓了。
解決這樣的問題應該遵循標準過程。這個過程看起來可能是這樣的：遇到一個問題，描述問題的特點，分析問題參數，對問題進行一些診斷，然后將分析和診斷移交給 Web service 的擁有者。
一旦遇到這種可伸縮性問題，初始任務是將它定位到客戶應用程序或 Web service 。合理的做法是將這二者分開來單獨測試。比如，比較合理的做法是編寫一個作為客戶應用程序后端的測試裝置模塊，并產生類似的期望從 Web service 那里獲得的批量應答。同樣，可直截了當地編寫一個演習 Web service 的測試裝置模塊。
雖然這些測試裝置模塊可生成適當的應答，但是它們不會去模仿應用程序上多個用戶的特性。除測試裝置模塊以外，還需要一個用于負載測試的載體。雖然在許多企業中，負載測試仍是手工過程，還是有一些方法可自動化這個過程�？梢允褂蒙虡I測試裝載工具，該工具實際上可以減少所涉及的人工干預，并獲得 Web service 響應時間和系統特性的真實數據。
圖 1 顯示了用商業測試負載產品執行負載測試所產生的結果。數據顯示 Java 虛擬機（ JVM ， Java Virtual Machine ）上下文中的內存使用在隨著時間推移而增加，而且在模擬用戶退出系統后并沒有減少。
圖 1. 用像 Compuware QACenter Performance Edition 這樣的商業化自動負載測試工具使負載測試自動化，從而允許應用程序開發人員無需大量工作就能夠收集數據
合理的可能出事故的地方是應用程序使用內存的方式。雖然許多開發人員相信，像 Java 這樣的可管理平臺不可能有重大的內存問題，開發人員必須全神貫注于構建使用內存管理來提高應用程序性能和可靠性的可靠戰略，而不是專注于分配、初始化、使用和釋放特定大小和位置內存區的戰術性技巧。
這怎么可能在 Java 平臺上發生呢？請考慮以下簡單的 Java 方法：
java.lang.String:
String r = new String ();
For (int I-0< limit; I+=1) {
r = r + compute(i);
}
return r;
在該方法中，分配一個新的字符串 r 作為迭代中使用的臨時對象。在這個迭代中，當前的 r 被復制到新的實例中。此外， compute(i) 方法的結果被增加到新的 r 字符串中。每一次循環都這么做一次。結果是每次通過該循環進行迭代時都會創建一個新的臨時對象。
這有幾層含義。首先，臨時對象的激增意味著內存持續分配。雖然內存分配耗費不是特別大，但是它確實會導致性能惡化。而且較大量的內存占用意味著要訪問更多的內存單元。這也不用花大量的時間，但是它會帶來相關的性能惡化。
主要的性能惡化來自過量內存的垃圾收集。垃圾收集代價很高，因此值得花一些精力去避免分配任何不必要的內存，而這么做的方法就是編寫減少臨時對象使用的代碼。一個替代方法可能是：
java.lang.StringBuffer:
StringBuffer r =
new StringBuffer();
For (int i=0; I< limit; i+=1) {
r.append(compute(i));
}
return r.toString();
這段代碼使用 append() 方法來執行添加操作，消除了為 JVM 生成臨時對象的需要。這些類型的內存問題是新出現的，大多數開發人員（甚至 Web service 開發人員）對它還不熟悉。很多情況下，開發人員只是缺少經驗和了解，不知道何時服務存在內存問題，以及是否能對此做些什么。他們假定自己無法控制內存的使用、分配和再分配方式，并且對設計和實現決定如何影響內存使用不加注意。
Web service 中的諸如此類的性能問題可使得它們不根據要求執行，或者不能擴展。這類問題可在任何 SOA 平臺上發生，這個例子恰巧發生在了 Java 上，但在 .Net 的 C# 中，這類問題也同樣很容易發生。
遠程診斷 Web service
應用程序開發人員可能不熟悉服務平臺或是語言。但是通過收集和分析應用程序中上下文中的數據，開發人員能夠幫助服務擁有者，使之可防止問題。通過提供在其應用程序上下文中進行負載測試而確定的一些 Web service 問題診斷，開發人員做到了這一點。
在這種情況下，既然負載測試已經識別了潛在的內存問題，那么通過使用商業內存分析產品對服務進行內存分析使得診斷更進了一級。通�？赡懿恍枰⻊盏脑创a就可以做到這一點。至少可以安裝和遠程控制一個產品，這使得不出現在服務器旁邊就能分析 Web service 成為可能。
比如， 圖 2 顯示了源自 JVM 的一個對象泄漏。進一步深入研究表明，對象泄漏源自一個打開數據庫連接的方法。結果，每次訪問數據庫，連接都被打開，但是最后從不關閉。最終結果是：每次調用數據庫都泄漏 48 字節。隨著時間過去，有許多用戶調用數據庫，這會產生一個穩步增長的、可降低性能并終至崩潰的應用程序圖像。
圖 2. 使用 Compuware DevPartner Java Edition 深入研究 Web service 的內存使用，提供對服務內對象泄漏的深入了解。
這些結果是可控訴的，雖然不是由服務消費者。作為替代，可以將它們移交給服務的擁有者做額外的診斷和修復。
Web service 開發人員對于 Web service 應該做什么，以及如何實現這些要求，有很好的理解。然而，他們缺乏設計直接支持終端用戶應用程序的實際經驗。通過提供對客戶應用程序的性能和可靠性的反饋，客戶應用程序開發人員可幫助 Web service 。
這使得應用程序開發人員可以更好地理解 Web service 的強度和限制，同時為服務開發人員提供關于服務使用的寶貴信息。在構造和構建企業 SOA 時，這類信息對這兩個團隊都很必要。服務消費者可實地測試服務提供者的工作，這可提供 Web service 最好的真實測試，而且這么做時可以幫助使用 SOA 的應用程序防止出現問題。
SOA 戰略有提高和加速企業應用程序開發的潛力，同時讓應用程序更加健壯，有更好的可擴展性。但是，這只在應用程序可依賴其服務的性能和可伸縮性時才有效。
服務消費者可通過兩種方式提供幫助，首先通過使用他們的應用程序來測試服務，其次，通過分析和診斷其應用程序上下文中的問題。如果企業希望構建一個真正能防止問題的 SOA ，那么服務消費者在這一層面上的參與就比較關鍵。
原文出處：
http://www.fawcette.com/weblogicpro/2005_01/magazine/features/rclark/
文章來源于領測軟件測試網 http://www.kjueaiud.com/
