概述

在企業(yè)傳統(tǒng)的系統(tǒng)開發(fā)中，企業(yè)往往在設計架構的時候都是采用了緊耦合形式，這是封閉的，自成一體的。這種架構下的的MRP、ERP、OA等產(chǎn)品很難適應或快速響應市場或客戶靈活多變的需求，以及后續(xù)的擴展。在這樣的市場、及客戶需求下，從而催生了軟件產(chǎn)品一種新的設計或架構的理念：面向服務架構（SOA架構）。

SOA架構，是一種粗粒度、開放式、松耦合的服務結構，要求軟件產(chǎn)品在開發(fā)過程中，按照相關的標準或協(xié)議，進行分層開發(fā)。通過這種分層設計或架構體系可以使軟件產(chǎn)品變得更加彈性和靈活，且盡可能的與第三方軟件產(chǎn)品互補兼容，以達到快速擴展，滿足或響應市場或客戶需求的多樣化、多變性。

SOA體系架構帶來的主要觀點是業(yè)務驅動IT，即業(yè)務驅動和業(yè)務更加緊密地聯(lián)系在一起。以粗粒度的業(yè)務服務作為基礎來對公司業(yè)務進行建模，這樣就可以產(chǎn)生簡潔的業(yè)務和系統(tǒng)視圖;以業(yè)務服務為基礎來實現(xiàn)的IT系統(tǒng)更靈活、更易于重用、也更快地應對企業(yè)業(yè)務需求的變化;以業(yè)務服務為基礎，通過顯式地方式來定義、描述、實現(xiàn)和管理業(yè)務層次的粗粒度服務（包括業(yè)務流程），提供了業(yè)務服務模型和相關IT業(yè)務之間提供了更好的“可追溯性”，縮小了它們之間的差距，使得業(yè)務服務的變化更容易傳遞到IT。

利用SOA架構開發(fā)的時候，其基于松耦合的特性能給企業(yè)帶來諸多的好處：

第一、更易維護

業(yè)務服務提供者和業(yè)務服務使用者的松散耦合關系及對開放標準的采用確保了該特性的實現(xiàn)。建立在以 SOA基礎上的信息系統(tǒng)，當需求發(fā)生變化的時候，不需要修改提供業(yè)務服務的接口，只需要調整業(yè)務服務流程或者修改操作即可，整個應用系統(tǒng)也更容易被維護。

第二、更高的可用性

該特點是在于服務提供者和服務使用者的松散耦合關系上得以發(fā)揮與體現(xiàn)。使用者無須了解提供者的具休實現(xiàn)細節(jié)。

第三、更好的伸縮性

依靠業(yè)務服務設計、開發(fā)和部署等所采用的架構模型實現(xiàn)伸縮性。使得服務提供者可以互相彼此獨立地進行調整，以滿足新的服務需求。

現(xiàn)在，國內許多企業(yè)已經(jīng)使用了SOA架構，但是是否它就真的沒有缺點，答案顯然不是：

SOA的不足

作為一個具有發(fā)展前景的應用系統(tǒng)架構，SOA尚處在不斷發(fā)展中，肯定存在許多有待改進的地方。隨著標準和實施技術的不斷完善，這些問題將迎刃而解，SOA應用將更加廣泛。

缺憾之一 ： 可靠性（Reliability）

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

缺憾之二 ： 安全性（Security）

在過去，訪問控制只需要登錄和驗證；而在SOA環(huán)境中，由于一個應用軟件的組件很容易去與屬于不同域的其他組件進行對話，所以確保迥然不同又相互連接的系統(tǒng)之間的安全性就復雜得多了。

缺憾之三：編排 （Orchestration）

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

缺憾之四：遺留系統(tǒng)處理（Legacy support）

SOA中提供集成遺留系統(tǒng)的適配器， 遺留應用適配器屏蔽了許多專用性API的復雜性和晦澀性。一個設計良好的適配器的作用好比是一個設計良好的SOA服務：它提供了一個抽象層，把應用基礎設施的其余部分與各種棘手問題隔離開來。一些廠商就專門把遺留應用軟件“語義集成”到基于XML的集成構架中。 但是集成遺留系統(tǒng)的工作始終是一種挑戰(zhàn)。

缺憾之五 ： 語義 Semantics

定義事務和數(shù)據(jù)的業(yè)務含義，一直是IT管理人員面臨的最棘手的問題。語義關系是設計良好SOA架構的核心要素。 就目前而言，沒有哪一項技術或軟件產(chǎn)品能夠真正解決語義問題。為針對特定行業(yè)和功能的流程定義并實施功能和數(shù)據(jù)模型是一項繁重的任務，它最終必須由業(yè)務和IT管理人員共同承擔。不過，預制組件和經(jīng)過實踐證明的咨詢技能可以簡化許多難題。

采用XML技術也許是一個不錯的主意。許多公司越來越認識到制定本行業(yè)XML標準的重要性。譬如，會計行業(yè)已提議用可擴展業(yè)務報告語言（XBRL）來描述及審查總賬類型的記錄。 重要的是學會如何以服務來表示基本的業(yè)務流程。改變開發(fā)方式需要文化變遷，相比之下，解決技術難題只是一種智力操練。

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

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

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

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

松耦合和敏捷性要求之間的權衡難題：

服務松耦合設計其實是一把雙刃劍，在帶來應變敏捷性的同時，也給業(yè)務建模和服務劃分帶來難題。這就是為什么在SOA討論中，業(yè)務建模的爭論總是最多的原因。

跨系統(tǒng)集成難題：

面向服務的體系結構設計將跨越計算機系統(tǒng)，并且還可能跨越企業(yè)邊界。我們不得不考慮在使用 Internet 時安全性功能和需求，以及如何鏈接伙伴的安全域。Internet 協(xié)議并不是為可靠性（有保證的提交和提交的順序）而設計的，但是我們需要確保消息被提交并被處理一次。當這不可能時，請求者必須知道請求并沒有被處理。

其次，個性化問題。SOA通過所謂粗粒度服務接口和分級，確實提高了效率。實現(xiàn)流程化以后，也確實簡化了開發(fā)難度。如果這個流程不適合我這個企業(yè)的實際情況，我還是需要個性化開發(fā)。國內的中小企業(yè)占到了企業(yè)總量的70%，他們的需求很具個性化，而且比較在意價格的因素。實際上這和SOA高度集成的性質是不相符的。