SOA架構師注意的問題

　　那什么是企業級SOA架構設計師的具體角色呢?什么是SOA架構設計師與設計和開發人員之間的差別呢?相信這些都是使大家最容易產生迷惑的問題。舉個實際的例子來說，當構建一個基于SOA架構的系統的時候，針對一個具體的 service，系統設計人員主要應該關注的是這個service能夠為外部用戶提供什么樣的服務，也就是說系統設計人員關注的是這個service所提供的功能。而對于SOA架構設計師來說，他們更關心的可能是當有一千個用戶同時調用這個 service的時候，什么會發生?也就是說架構設計師關注的應該是一些商業需求和服務級別(service-level)需求。所有的架構設計師的角色都包含了在構建一個系統的一開始就應該盡量減少可能存在的技術風險。而技術風險一般指的是一切未知的、未經證明的或未經測試所帶來的風險。這些風險通常與服務級別(service-level)需求相關，偶爾也會與企業具體的業務需求相關。無論是哪種類型的風險，在項目初期設計整體系統架構的過程中更易于發掘這些風險，如果等到架構實施時再發覺這些風險，那么很可能會致使大量的開發人員等在那里，直到這些風險被妥善解決。如果進一步的細化，我們可以看到SOA架構設計師的主要任務包括對整個系統解決方案輪廓的構建，需求分析，對體系結構的整體決策，相關組件建模，相關操作建模，系統組件的邏輯和物理布局設計。

　　作為SOA架構設計師必須要能夠領導整個開發團隊，這樣才能保證設計和開發人員是按照構建好的系統架構來開發整個系統的，這一點十分的重要。這就要求一名架構設計師不僅要有很好的技術洞察力，同時還要具有一定的項目管理和項目實施的能力。在系統開發的過程中，架構設計師必須要有良好的溝通和表達能力，這就體現在由架構設計師構建的系統模型是否具有很好的可讀性和易理解性。如果由架構設計師構造出的系統模型不是很清晰的話，就可能會影響設計和開發人員對于整個系統架構的理解。為了避免這種情況的出現，定期由架構設計師主持的開發團隊內部討論是十分重要的。

　　構建SOA架構時應該注意的問題

　　原有系統架構中的集成需求

　　當架構師基于SOA來構建一個企業級的系統架構的時候，一定要注意對原有系統架構中的集成需求進行細致的分析和整理。我們都知道，面向服務的體系結構是當前及未來應用程序系統開發的重點，面向服務的體系結構本質上來說是一種具有特殊性質的體系結構，它由具有互操作性和位置透明的組件集成構建并互連而成?；赟OA的企業系統架構通常都是在現有系統架構投資的基礎上發展起來的，我們并不需要徹底重新開發全部的子系統;SOA可以通過利用當前系統已有的資源(開發人員、軟件語言、硬件平臺、數據庫和應用程序)來重復利用系統中現有的系統和資源。SOA是一種可適應的、靈活的體系結構類型，基于SOA構建的系統架構可以在系統的開發和維護中縮短產品上市時間，因而可以降低企業系統開發的成本和風險。因此，當SOA架構師遇到一個十分復雜的企業系統時，首先考慮的應該是如何重用已有的投資而不是替換遺留系統，因為如果考慮到有限的預算，整體系統替換的成本是十分高昂的。

　　當SOA架構師分析原有系統中的集成需求的時候，不應該只限定為基于組件構建的已有應用程序的集成，真正的集成比這要寬泛得多。在分析和評估一個已有系統體系結構的集成需求時，我們必須考慮一些更加具體的集成的類型，這主要包括以下幾個方面:應用程序集成的需求，終端用戶界面集成的需求，流程集成的需求以及已有系統信息集成的需求。當SOA架構師分析和評估現有系統中所有可能的集成需求的時候，我們可以發現實際上所有集成方式在任何種類的企業中都有一定程度的體現。針對不同的企業類型，這些集成方式可能是簡化的，或者沒有明確地進行定義的。因而，SOA架構師在著手設計新的體系結構框架時，必須要全面的考慮所有可能的集成需求。例如，在一些類型的企業系統環境中可能只有很少的數據源類型，因此，系統中對消息集成的需求就可能會很簡單，但在一些特定的系統中，例如航運系統中的EDI(Electronic Data Interchange 電子數據交換)系統，會有大量的電子數據交換處理的需求，因此也就會存在很多不同的數據源類型，在這種情況下整個系統對于消息數據的集成需求就會比較復雜。因此，如果SOA架構師希望所構建的系統架構能夠隨著企業的成長和變化成功地繼續得以保持，則整個系統構架中的集成功能就應該由服務提供，而不是由特定的應用程序來完成。

原文轉自：http://www.kjueaiud.com