軟件質量保證SOA逐步成熟 如何使用ESB簡化SOA復雜性 SOA構架
關鍵字：使用ESB 簡化SOA復雜性
為什么在面向服務的景觀圖中又加入了一個移動的部分?難道對面向服務的應用的管理還不夠復雜?引入企業服務總線(ESB)的原因和許多年前選擇企業應用集成策略的原因是一樣的。
在SOA實現的早期階段，當目錄僅僅由一個或者兩個基于項目的服務組成的時候，ESB看起來是英雄無用武之地。但是幸運的是，如果在企業中采用ESB，那么服務的部署會被加速。任何一項策略都被要求能夠提供隨需應變的擴展性，可靠性和足夠的性能等特點。從構架的角度，使用一個合理的原則避免服務混亂不失為一個好的想法。
隨著企業SOA的逐步成熟，業務功能會從各種源頭被挖掘和發現出來。這些服務的提供者可能是遺留的應用，第三方軟件包或者主要解決方案提供的功能。雖然理想狀態是所有這些服務都使用相同的技術，但是現實情況證明這是不可能的。很有可能Web Service標準僅僅是使用的技術中的一個而已。
高級的SOA功能，比如服務編排(archestration)，自動業務流程，事件驅動架構和復雜事件處理，都依賴于健壯的企業應用集成架構。
將這些注意事項牢記在心，判定帶有ESB的完整功能的integration broker的標準就很清楚了。
可靠性和可用性
由于多層應用的出現，對分布式軟件中所有移動部分的可見性是一項重大的挑戰。由于消費者完全從應用面向對象開發中分開，服務的消費者必須能夠發現服務并且預計服務的可用性、質量和性能特征。ESB能夠處理服務注冊，同時有助于兼容SLA(服務等級協議，service level agreement)。為了監控服務的健康狀態，就必須清楚該服務對其他服務的依賴，以及運行平臺的狀態。當問題被檢測出來，就會發出警報和通告。許多integration broker的產品或者提供內建的監控功能，或者，更常見的情況，提供鉤子(hook)給監控工具以便獲得更全面的可見性。這些工具可以提供審計，日志和異常處理的通用服務。
擴展性
基于總線的架構提供了對服務的真實的部署拓撲結構的一種抽象。增加Web服務器、應用服務器、第三方軟件、遺留應用和數據庫實例——服務描述中功能的真正執行者——的處理能力，將不會影響到服務的消費者。實際上，工作可以進一步委托給聯合的總結，這樣ESB本身可以按照最有效的利用硬件和網絡資源的方式來部署。
安全
已經實現的服務不應該承擔管理什么用戶在什么情況下能夠訪問服務的重擔。用戶的角色可能隨著時間而變化。這種橫切(cross-cutting)的功能應該處于ESB中的各種服務之外。
延伸性和敏捷性
隨著業務適應于變化的時代和新的機會，業務流程同樣會變化。對于一個成功的SOA實現來說，對靈活性的規劃非常關鍵。轉換應當在盡可能的靠近往來于商業信息模型的集成端點處完成。這種方法可以便于流程的靈活自動化，組合服務的編排(orchestration)和將流程相關的商業規則從服務的商業功能中抽取出來。
總之，功能完善的integration broker會提供核心的ESB功能，以及其他的一些異構的服務拓撲中必須的功能。這類技術能夠為復雜的結構提供一個“簡化的”外殼，否則這種簡化需要在每個應用或者服務里面取實現。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
