許多人將Web服務看作SOA基礎架構的構件塊，這并不奇怪。我認為Web服務可以是SOA的構件塊，但并不一定是必需的。下面我將介紹為什么以及如何可以將部署在WebLogic Server上的應用程序組件看作作為SOA一部分的服務。
應用程序可以被分解為實現業務功能的組件。每一個應用程序都有特定的業務、功能和操作需求。功能需求要迎合實現，在這方面我不準備花太多時間介紹，因為我們討論的是已經成為企業一部分的、需要轉化為SOA構件塊的應用程序。此時我們需要關注的是，如何關聯業務需求并為該應用程序提供一個輕松的操作環境。
許多業務需求都歸結為對應用程序的服務水平協議(SLA)的滿足，業務需求可能包括以下方面:
并發用戶
響應時間
錯誤率
工作負載優先化(業務功能按照優先級進行分解)
應用程序采用率(就用戶數目而言的應用程序擴展路線圖)
可用性
操作需求與維護基礎架構有關，可能包括以下方面:
應用程序監控
部署策略
維護(補丁、升級)
問題診斷
大多數情況下，WebLogic實例上部署了許多應用程序，難以將上述需求關聯到該環境中。
隔離:給出上述場景之后，我們來看一種將這樣的環境轉化為SOA的一部分的方法。第一步是要隔離被認為是關鍵型的應用程序或組件�？梢酝ㄟ^將這些應用程序部署到各自的WebLogic實例中，然后關聯適當的存儲器和WebLogic資源到該應用程序來實現隔離。然后這些服務器實例可以被集群化，這樣就有助于進行故障轉移，從而使環境具有高度可用性。不要忘記:業務期望值越高，基礎架構的成本就越昂貴。如果需要隔離應用程序的特定組件，可以利用定制的執行隊列(Execute Queue)或工作管理器(Work Manager)(9.0中的新特性)，為它們配置適當的線程數。創建執行隊列可以為應用程序組件提供分離的請求通道，并防止請求缺乏關鍵型業務功能。在連接池級進行隔離可以確保數據庫資源的可用性。
服務器特征:我們需要從吞吐量、負載之下的響應等方面來了解服務器特征。這是通過進行負載/壓力測試，然后調優環境以獲得WebLogic Server實例的最佳性能指標來完成的。這是一項重要的任務，因為它可以幫助規劃以后的應用程序采用率，從而提供一個可伸縮的環境。
災難恢復規劃:關鍵型應用程序應該有適當的災難恢復規劃。我信任hot-hot型而不是hot-standby(熱備份)型的冗余環境。如果備份不能運行該怎么辦?如果出現故障，有多少服務器實例才足以維持峰值負載?關于這方面的詳細信息也必須在文檔中注明。所有這些可以確保在出現故障時能夠有一個運行良好的環境，而保護業務是底線。
統一管理:我曾經在一些機構中看到他們用一個操作小組來管理多個WebLogic域。這樣的環境是難于維護和管理的�？紤]需要進行更新的場景。還有監控——這是一項日常操作任務——必須查看多個WebLogic Server控制臺以收集信息。我的建議是，在可能的地方對類似的應用程序創建多個集群而不是多個域。集群提供對應用程序的固有隔離級別，這會產生較少的域以及更易于管理的環境。
操作是面向流程的:對環境的操作很大程度上是面向流程的，且需要進行詳細的記錄。錯誤模式和正確的解決方案的記錄都是一個動態過程。環境進行升級和打補丁的停機時間必須符合高可用性的業務需求。必須為維護設置適當的過程。還要定義逐步升級的過程，并寫入文檔。作為部署過程的一部分，還應該采用域模板，以便產生跨不同環境的一致域。
提供透明性:一個管理良好的環境需要有針對關鍵性業務破壞的報警機制。在問題診斷時，服務器日志中的信息必須有一定的透明度。應用程序必須記錄有助于問題診斷的關鍵信息。在問題診斷時，可以使用諸如來自Splunk之類的工具來聚合來自服務器環境中不同日志的信息。此外，預期和實際的關鍵性技術指標也應該被收集并關聯起來。例如，在容量規劃期間，可以基于業務需求預測特定數目的并發用戶，而這個數字可能與生產環境中實際得到的數字不同。這類技術指標應該定期報告，以方便以后的環境調優。
結束語
在本文中，我介紹了一種經過大大簡化的方法，用于將駐留在WebLogic上的應用程序轉化為SOA中的資產。此外，我沒有談到的其他領域(比如數據庫、外部系統)也需要進行分析和研究。上述概念也可以應用于這些系統。這些特性都帶有相關的成本，因此必須分析實現它們的投資回報(ROI)。最后您將得到一個可以滿足業務和功能需求的環境，就可以很好地實現SOA了。本文并未涵蓋所有的SOA要素，但是它提出了一個用于滿足復雜的WebLogic環境中的某些SOA需求的解決方案。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
