這麼久，一直在關注SOA，看了許多關於SOA的文章，從概念，到實現，現在想以自己的語言來總結一下所學到的。
看 了這麼多文章，我覺得我最喜歡的一句就是：SOA是一場架構革命，其實質就實將系統模型與系統實現分離出來。一個大型的系統不可能僅僅由一個功能模塊組成，而恰恰相反，企業級系統正是由多個具有獨立功能的子系統組成，而各個子系統之間需要保持良好的封裝性，各個系統只通過提供向外部的統一的接口來交互。這就是所謂的鬆耦性。 同時，SOA架構要求各個子系統（組件模塊）的交互需要時獨立於平臺的（不管時J2EE，.NET,CORBA）。所以SOA的架構是一個組件模型，它將應用程序的不同功能單元－－服務(Service)，通過服務間定義良好的接口和契約（contract）聯繫體來。
而且接口需要採取中立的方式定義，獨立於具體的實現服務和硬件平臺，操作系統和編程語言，使得構建這樣得系統得服務可以使用統一和標準得方式進行通信。這種具有中立接口得定義得特徵也被成爲服務之間得鬆耦合。
所以SOA架構具備了以下特徵
1，服務得封裝性(encapsulaiton)。將服務封裝成用於業務流程得可重用得組件得應用程序函數。它提供信息或簡化業務數據從一個有效得，一致得狀態向另一個狀態的轉變。封裝隱藏了複雜性。服務API保持保持不變，使得用戶遠離具體實施上的變更。
2，服務的重用（reuse）。
3，服務的互操作（interoperability）。
4，服務是自治的（Autonomous）功能實體。
5，服務之間的鬆散耦合度（Loosly Coupled）。
6，服務是位置透明的（location transparency）。
所以SOA架構的基本單元是服務（service）。它的三個參與具體是：服務提供者者（service provider），
服務代理者（service broker） 和服務消費者（service consumer）。
SOA有三個抽象級別
1 ，操作 2，服務 3，業務流程
實現SOA的主要技術包括
1。XML
xml （extensible markup language） 是一個基於文本的W3C 規範的標記語言，與HTML使用標籤來描述外觀和數據不同，xml嚴格定義了可移植化的結構數據（structured data）。它可以作爲數據描述語言的語言（metadata 元數據），如標記語法或詞彙，交換格式和通信協議。
2。SOAP
簡單對象訪問協議（Simple Object Access Protocol）是一個基於XML的，用於在分佈式環境下交換信息的輕量級協議。SOAP在請求者和提供者對象之間定義了一個通信協議，這樣，請求對象可以執行遠程提供對象的方法調用。
3。WSDL
Web 服務描敘語言WSDL（Web Service Description Language） 是一個提供描述服務IDL（Interface Description Language）標準方法的XML詞彙。Web 服務描述語言（WSDL）規範定義了一個 XML詞彙表，該詞彙表依照請求和響應消息，在服務請求者和服務提供者之間定義了一種契約。我們能夠將Web服務定義爲軟件，這個軟件通過描述SOAP消息接口的 WSDL文檔來提供可重用的應用程序功能，並使用標準的傳輸協議來進行傳遞。
WSDL描述包含必要的細節,以便服務請求者能夠使用特定服務：
● 請求消息格式
● 響應消息格式
● 向何處發送消息。
4.UDDI
統一描述，發現和繼承（Universal Description ，Description and VIntegration）規範提供了一組公用的SOAP API，使得服務代理得以實現。UDDI爲發佈服務的可用性和發佈所需服務定義了一個標準接口（基於SOAP消息）。UDDI實現將發佈和發現服務的SOAP 請求解釋爲用於基本數據存儲的數據管理功能調用。
爲了發佈和發現其他SOA服務，UDDI 通過定義標準的 SOAP 消息來實現服務註冊（Service Registry）。註冊是一種服務代理，它是在 UDDI 上需要發現服務的請求者和發佈服務的提供者之間的中介。一旦請求者決定使用特定的服務，開發者通常藉助於開發工具（如Microsoft Visual Studio .NET）並通過創建以發送請求並處理響應的方式訪問服務的代碼來綁定服務。
SOA不需要使用UDDI，但由於 UDDI 是建立在SOA上來完成自身工作的，所以UDDI是服務發現的一個好的解決方案
5．ESB
企業服務總線ESB（Enterprise Service Bus）是SOA架構的一個支柱技術。 作爲一種消息代理架構它提供消息隊列系統，使用諸如SOAP或JMS (Java Message Service)等標準技術來實現。
SOA架構是很吸引目光的，但是SOA也具有一些自身的不足
缺憾之一 : 可靠性(Reliability）
SOA還沒有完全爲事務的最高可靠性——不可否認性(nonrepudiation)、消息一定會被傳送且僅傳送一次（once-and-only-once delivery）以及事務撤回（rollback）——做好準備，不過等標準和實施技術成熟到可以滿足這一需求的程度並不遙遠。
缺憾之二 : 安全性（Security）
在過去，訪問控制只需要登錄和驗證；而在SOA環境中，由於一個應用軟件的組件很容易去與屬於不同域的其他組件進行對話，所以確保迥然不同又相互連接的系統之間的安全性就複雜得多了。
缺憾之三:編排 (Orchestration
缺憾之四:遺留系統處理（Legacy support）
SOA中提供集成遺留系統的適配器， 遺留應用適配器屏蔽了許多專用性API的複雜性和晦澀性。一個設計良好的適配器的作用好比是一個設計良好的SOA服務：它提供了一個抽象層，把應用基礎設施的其餘部分與各種棘手問題隔離開來。一些廠商就專門把遺留應用軟件“語義集成”到基於XML的集成構架中。 但是集成遺留系統的工作始終是一種挑戰。
缺憾之五 : 語義 Semantics
性能（performance）：SOA的第六個缺憾
批評SOA的人士經常會提到性能是阻礙其採用的一個障礙，但技術的標準化總需要在速度方面有一些犧牲。這種懷疑觀點通常針對兩個方面：SOA的分佈性質和Web服務協議的開銷。
不可否認，任何分佈式系統的執行速度都不如獨立式系統，這完全是因爲網絡的制約作用造成的。當然，有些應用軟件無法容忍網絡引起的延遲，例如那些對實時性要求很高的應用軟件。所以在應用SOA架構之前，搞清楚它的適用範圍就顯得很重要了。
除了上述幾點之外，我認爲還有兩點也頗值得關注：
鬆耦合和敏捷性要求之間的權衡難題:
服務鬆耦合設計其實是一把雙刃劍，在帶來應變敏捷性的同時，也給業務建模和服務劃分帶來難題。這就是爲什麼在SOA討論中，業務建模的爭論總是最多的原因。
跨系統集成難題：
面向服務的體系結構設計將跨越計算機系統，並且還可能跨越企業邊界。我們不得不考慮在使用 Internet 時安全性功能和需求，以及如何鏈接夥伴的安全域。Internet 協議並不是爲可靠性（有保證的提交和提交的順序）而設計的，但是我們需要確保消息被提交併被處理一次。當這不可能時，請求者必須知道請求並沒有被處理。
最後我希望用一句 IBM 的一位權威級的人物（女性－－偉大！ ^_^） 的一句話來結尾
Five SOA Entry Points
People, Process, and Information. And Reuse and connectivity！！！