SOA框架 5大缺陷待完善

        作為一個具有發展前景的應用系統架構，SOA尚處在不斷的發展中，肯定存在許多有待改進的地方。Stencil Group諮詢公司的Brent Sleeper在《The five missing pieces of SOA》中列舉了SOA在可靠性、安全性、編制、遺留系統支援和語義方面還存在嚴重不足。
         作為一個具有發展前景的應用系統架構，SOA尚處在不斷的發展中，肯定存在許多有待改進的地方。Stencil Group諮詢公司的Brent Sleeper在《The five missing pieces of SOA》中列舉了SOA在可靠性、安全性、編制、遺留系統支援和語義方面還存在嚴重不足。

　　缺憾之一 : 可靠性（ReliaBIlITy）

　　SOA還沒有完全為事務的最高可靠性——不可否認性(nonrepudiation)、訊息一定會被傳送且僅傳送一次（once-and-only-once delivery）以及事務撤回（rollback）——做好準備，不過等標準和實施技術成熟到可以滿足這一需求的程度並不遙遠。

　　缺憾之二 : 安全性（SecurITy）

　　在過去，訪問控制只需要登入和驗證；而在SOA環境中，由於一個應用軟體的元件很容易去跟屬於不同域的其他元件進行對話，所以確保迥然不同又相互連線的系統之間的安全性就複雜得多了。

　　缺憾之三 : 編排（Orchestration）

　　統一協調分散式軟體元件以便構建有意義的業務流程是最複雜的，但它同時也最適合面向服務型別的整合，原因很顯然，建立在SOA上面的應用軟體可以被設計成可以按需要拆散、重新組裝的服務。作為目前業務流程管理（BPM）解決方案的核心，編排功能使IT管理人員能夠通過已經部署的套裝或自己開發的應用軟體的功能，把新的元應用軟體（meta-application）連線起來。事實上，最大的難題不是建立模組化的應用軟體，而是改變這些系統表示所處理資料的方法。

　　缺憾之四 :遺留系統處理（Legacy support）

　　SOA中提供整合遺留系統的介面卡，遺留應用介面卡遮蔽了許多專用性API的複雜性和晦澀性。一個設計良好的介面卡的作用好比是一個設計良好的SOA服務：它提供了一個抽象層，把應用基礎設施的其餘部分與各種棘手問題隔離開來。一些廠商就專門把遺留應用軟體“語義整合”到基於XML的整合構架中。 但是整合遺留系統的工作始終是一個挑戰。

　　缺憾之五 : 語義Semantics

　　定義事務和資料的業務含義，一直是IT管理人員面臨的最棘手問題。語義關係是設計良好SOA架構的核心要素。就目前而言，沒有哪一項技術或軟體產品能夠真正解決語義問題。為針對特定行業和功能的流程定義並實施功能和資料模型是一項繁重的任務，它最終必須由業務和IT管理人員共同承擔。不過，預製元件和經過實踐證明的諮詢技能可以簡化許多難題。

　　採用XML技術也許是一個不錯的主意。許多公司越來越認識到制定本行業XML標準的重要性。譬如，會計行業已提議用可擴充套件業務報告語言（XBRL）來描述及審查總賬型別的記錄。

　　重要的是學會如何以服務來表示基本的業務流程。改變開發方式需要文化變遷，相比之下，解決技術難題只是一種智力操練。

　　效能（performance）：SOA的第六個缺憾？

　　批評SOA的人士經常會提到效能是阻礙其採用的一個障礙，但技術的標準化總需要在速度方面有一些犧牲。這種懷疑觀點通常針對兩個方面：SOA的分佈性質和Web服務協議的開銷。

　　不可否認，任何分散式系統的執行速度都不如獨立式系統，這完全是因為網路的制約作用造成的。當然，有些應用軟體無法容忍網路引起的延遲，例如那些對實時性要求很高的應用軟體，所以在應用SOA架構之前，搞清楚它的適用範圍就顯得很重要了。

　　除了上述幾點之外，筆者認為還有兩點也頗值得關注：

　　鬆耦合和敏捷性要求之間的權衡難題：服務鬆耦合設計其實是一把雙刃劍，在帶來應變敏捷性的同時，也給業務建模和服務劃分帶來難題。這就是為什麼在SOA討論中，業務建模的爭論總是最多。

　　跨系統整合難題：面向服務的體系結構（SOA）設計將跨越計算機系統，並且還可能跨越企業邊界。我們不得不考慮在使用Internet時安全性功能和需求以及如何連結夥伴的安全域。Internet協議並不是為可靠性（有保證的提交和提交的順序）而設計，但是我們需要確保訊息被提交併被處理一次。當這不可能時，請求者必須知道請求並沒有被處理。（來自IT商業新聞網）

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14780828/viewspace-528627/，如需轉載，請註明出處，否則將追究法律責任。