建立在面向服務架構(SOA)上的Web應用程序將極大的提高IT效率和業務靈敏度。SOA 建立起了數據和協議方面的統一標準，以使得現有的內部和第三方應用程序模塊或服務能夠有效的重復利用，并可以進一步重新組合進業務應用程序。但不幸的是，在SOA迅速促進業務應用程序實施的同時，這些應用于生產的程序也大大增加了其性能管理的復雜性――這在很大程度上降低SOA應用所能實現的優勢。如果沒有有效的方法來監控應用程序的性能、迅速找出癥結所在并加以解決，那么SOA應用就很有可能成為死亡之路(dead on arrival ，DOA)。

　　在實施SOA有幾個方面的原因導致IT很難管理應用程序的性能：

　　造成低效的共同要素：一個SOA應用程序所提供的服務，其水平受到網絡中該SOA應用程序所需性能的服務水平限制。為了達到最大限度的靈活性，服務甚至可以由第三方供應商提供，并有可能在不同的計算平臺上運行。這使得IT從實際操作上不可能界定出服務構件的性能特點，更不可能完全控制那些影響程序交付和執行的眾多機動部分。服務的重新利用還意味著通用服務中所存在的性能缺陷也在程序應用中被復制過來，產生了無法預計的故障。這樣以來，就很難從數量上確定服務水平是否超過終端客戶的期望或至少達到服務水平協議(SLA)中規定的性能目標。

　　聯動實驗效果：對于一個通過Web發布的SOA應用程序來說，要確認其服務的發起和交付時存在哪些問題同樣是非常困難的。問題根源可能存在于交付機制中任何一個“機動部分”，比如客戶的個人電腦、網絡、數據中心、服務組件和/或第三方服務提供商的服務或基礎架構。在這樣一個復雜的環境中，沒有一張“嫌疑列表”足夠巨細無遺列出所有的可能性。

　　繁雜的網絡環境：在處理這些通過Web發布的應用程序或基礎架構時缺少一種可預見性或事先確定的步驟去實現操作，也進一步使得診斷SOA應用性能問題的任務變得更加復雜。在客戶端或服務器端的計算環境中，一個目錄查詢是經由定義的網絡分段，并由安裝在固定服務器上的ERP應用程序加以支持; 而在SOA環境中的目錄查詢可能經由網絡動態的進行，并且由多個虛擬或實際服務器所在基礎架構的多層邏輯中加以支持。第三方Web服務需求也能傳輸給提供商的基礎架構從而從提供商自身開始說明詳細目錄。這種復雜的組合需要涉及非確定性的操作路徑，這使得改造或診斷整體應用性能的問題變得十分困難。

　　為了應對如上的這些挑戰，使得SOA應用不至走上死亡之路(DOA)，IT需要兩種能力為其所用。首先，IT必須能夠像真正的用戶那樣監控應用程序的性能，因為這是唯一能感受到所有服務組件的環節要素所在。除此以外，如果發現服務水平受到影響，他們必須能夠迅速的追蹤不利操作，查明引起性能下降的問題根源所在。如果能系統的利用這些能力，IT就能夠：

　　· 通過發現性能瓶頸與縮短問題解決時間來提高服務水平。

　　· 排除不必要的評估會議和毫無成果的改造嘗試，降低操作管理的成本和失誤幾率。

　　那么現存的終端用戶在實現其應用程序滿足IT需求的同時應該如何監控其技術交付從而避免應用程序走上死亡之路(DOA)呢?讓我們看看對于監控技術在應用于SOA性能管理的調查情況：

　　· 嗅探器或是其他的包捕獲程序即可很容易的評估出在傳輸規則下包響應的來回時間，但是對于那些傳輸路徑并未通過在網絡中安裝了這些程序的關鍵點的交易則無法判斷出準確的響應時間。拿Mashups應用做一個例子：關鍵的數據項目由第三方應用程序提供，旁路的嗅探器會安裝在網絡服務器前端。在數據中心，基于SOA應用的基礎上嗅探器依舊會遺漏掉Web服務而是更多的監測到來自服務器端或是第三方的服務。

　　· 服務器監測工具只能針對其所監測的局限范圍做出事務處理時間響應的報告。舉例而言，流行的J2EE應用程序服務器端監測工作只能對安裝了這個應用程序服務器的范圍內做出事務處理響應時間的判斷。直接由Web或是第三方服務所提供的事務處理服務沒有涉及到應用程序層面則無法被J2EE監測工具直接管理。

　　· 傳統的網站性能監測服務可以準確的監測到SOA應用程序是否可行。但是它并不能就性能做出一個有經驗可參考的報告提供給真正的使用者，或是給出一份針對問題的精細記錄信息從而完成糾正性的完善。

　　· 純粹的SOA管理產品可以幫助IT部門從相互依賴的各種服務中建立起有效模型，從而提供有限的事務處理方式的信息，但是這樣的產品往往會忽視整體基礎架構的良性發展。最關鍵的是它無法對最終的性能表現做出預判并給予最終用戶以經驗指導。

　　在提供“真實”可行的信息以管理SOA的性能方面，這些遺產工具不僅在所收集的性能數據類型上不夠完善，在收集數據的來源方面也存在缺陷。至關重要的是要界定應用程序性能在被終端用戶感應到的反應時間，而不是服務器、網絡J2EE、數據庫或其他局限范圍內的度量。毫無疑問的是，終端用戶體驗是唯一重要的事情。此外，在mashup應用程序中，網頁是由多個服務器或第三方數據中心來支持的，當應用程序通過內容傳輸工具執行的時候，程序在內容都已經到達瀏覽器的時候也許都還沒有組合起來。結果，唯一衡量SOA應用性能好壞的有效方法就是直接從真實用戶的瀏覽器來測量。

為真實用戶確保實時監測和事務處理追蹤能力可以避免SOA一步一步走向死亡之路，IT部門需要在其SOA性能管理工具中擁有如下的三個整合基礎功能：

　　有效監測：“沒有度量標準就沒有管理”。SOA管理的第一步是要找到一個界定SOA應用程序是否滿足服務水平要求的定量的方法。換句話說，“正確的應用反應(數據、頁面、行動等等)是否在合適的時間內傳輸給了正確的用戶?”有許多質量保證技術來確保正確的應用程序反應的交付。而且，多數組織都具有必要的安全措施來確保信心傳送到正確的人手上。但是，確保信息在正確的時間內通過復雜的基于網絡的SOA基礎架構傳達給終端用戶卻又是另外一回事了。具有能力對真實用戶體驗應用性能進行非干擾性的監測是絕對必要的，原因有二：一是因為這是唯一辦法來準確監測SOA應用程序服務水平保障和報表真實用戶感受到的問題; 二是因為它創造了進行流程改進和提高應用程序反應時間的關鍵推動力。這種監測手段始于終端用戶瀏覽器，也就是所有的應用程序真正組合到一起的地方。只有在瀏覽器上，IT才可能考慮“最后一里”的情況并識別是否有會影響到客戶滿意度的事情發生。由遺產工具搜集而來的數據主要側重于監測特定的技術局限范圍――如網絡路由器、Apache網絡服務器、WebSphere應用服務器或者是NET框架――都不能用于推斷識別SOA復雜應用程序的真實最終用戶在瀏覽器中的體驗。

　　隔離分析：一旦了解了最終用戶在應用程序性能方面的體驗，它就應該與SOA相關反應交付中涉及到的所有的基礎架構和應用組件性能資料聯系起來。因為復合應用程序是由像“黑匣子”一樣的服務構成的，它們的性能是不能夠被這些組合程序的工具所控制和調節，對于這些運行在真實或虛擬基礎架構組件之上的應用是不可能完全的被IT運作所掌控，他們可能有來自不同數據中心的事務交易或是由第三方服務方所提供服務端，最重要的一點這些不管是整體基礎架構也好，第三方數據中心也好，還是不同的應用組件也好需要緊密的相互關聯起來并對其性能做出準確的報告。性能的相關性可以通過對日志文件的細致分析或是通過各階段IP匹配與請求發起的時間等做出判斷，但是即便在所有的日志文件都可得的情況下這種方法依然會是非常困難并且會有難以避免的錯誤出現，而且一旦出現事務交易涉及到了外部的數據中心那日志文件將很難記錄下來從而在分析時造成錯誤。另一種簡單的機制則是標記出每一個事務交易是由哪一個終端用戶所發起，并在整個基礎架構中采用非干擾性的動態追蹤，在每一階段記錄下適當的性能數據。這種端到端的性能觀測需要基于用戶的使用經驗所能提供的對于整體狀況的鳥瞰視角，從而對細微的事件、錯誤或性能瓶頸所對最終用戶在響應時間上的影響做出判斷。

　　優化：全面的瀏覽器到數據庫的事務交易性能視角可以確保提供可靠的信息從而使得特別的或是反復試驗所得的方法將不再需要用來對性能問題做出鑒別和響應。如果缺少可靠的信息那么IT部門的事件響應團隊可能需要花費更多的時間去辯論，努力找出問題所出現的原因，在很大程度上他們會更多試圖重建這次問題而不是馬上著手于解決這個問題從而恢復整體的業務功能。通過長期對這些相互關聯的事務交易性能的信息進行分析，IT部門可以準確的判斷出性能影響中最關鍵的主要沖突所在并能在下一次問題對用戶滿意度或業務生產力造成影響之前將其解決。此外，這些信息也能更好對基礎架構、服務以及應用程序性能的改善帶來著實有效的幫助。

　　將以上三種功能集成到一個單一的SOA性能管理工具里可以為IT部門提供一個前期響應系統用以監測并在最終用戶端性能問題引發大范圍沖擊造成巨大損失之前迅速做出響應。業務沖擊或性能瓶頸的相關信息應第一時間及時反饋到運作人員用以完成對基礎設施或流程的改進，同時為開發人員優化程序應用。

　　毋庸置疑，SOA的出現可以大大提升業務靈活性，降低應用程序開發成本。但是，如果沒有一個真正的面向用戶的方式用以管理SOA部署實施以及一個系統化的生產管理，那SOA應用的前途真的有可能踏上不歸的死亡之路。 
(來自www.csdn.net)