soa(service oriented architecture
，面向服務的體系結構
)是由元件、服務、業務過程組成的可以滿足機構業務需求的體系結構，是一種非常好的建立複雜系統的體系架構的模型。
soa有助於**重用、降低成本、風險，還可縮短產品進入市場的時間。
從某種意義上說，
soa更多是一些指導原則，並不依賴具體的實現技術。儘管
soa可以使用其它技術實現(如
corba
、dcom
、rmi
、rpc
可以提供同步通訊，而
mom則可實現非同步通訊)，
soa概念的提出和
web服務技術的發展緊密相關，二者通常結合使用。
soa規範系統的體系結構，
web服務技術則提供一種定義服務、提供通訊的機制。而且
web服務可以整合基於不同應用、不同軟體或分布在不同的硬體平台上、由各種不同的系統提供的服務，大大降低成功實施
soa的複雜程度。 在
soa中，服務是通過介面定義的，並在執行時被呼叫。服務並不專門針對特定客戶，它可以由眾多客戶共享。這就意味著服務不保留和它所服務的客戶對話的狀態資訊，它是無狀態的。無狀態並不意味著服務不能有例項資料和在資料庫中儲存資料。但是，除了在介面中暴露的資料，這些資料對客戶來說是不可見的。進一步說，當服務被呼叫執行時，它並不知道在此之前執行的請求和後面將執行的請求。這給服務帶來了乙個非常關鍵的特性
:每個服務所需資訊全部通過呼叫引數來傳遞。服務的所有相關任務在一次服務被呼叫時完成，因為服務通常並不儲存從一次呼叫轉移到另一次呼叫的資訊。 用
soa建立的系統具有很高的擴充套件性，由於服務的無狀態性也很高效。由於不用保留會話的資訊，負載均衡和錯誤恢復等更易實現。如需提高系統的效能，只用增加新的服務例項的實現
(新增更多的伺服器
)即可。而且，由於每乙個服務並不是專門為特定的客戶提供服務，大量的客戶能共享較少的服務例項
(在多執行緒實現時就是執行緒
)。使用有狀態的服務儘管也可以實現上述功能，但複雜性成倍增長，因此通常不這麼做。
soa的核心概念「重用」和「互操作」己存在了
20多年。儘管其他分布式技術和標準未能取得成功，
soa還是有成功的可能。這取決於以下幾個因素:
1.基於鬆散藕合產生的靈活性
:soa
是第乙個考慮了業務發展長期性的
it架構，它認為變化是永恆的。從本質上說，
soa是一組鬆散藕合的服務，服務的建立和替換成本相對低廉。與傳統的緊藕合架構相比，鬆散藕合架構更能適應業務的變化。在
soa中可以用乙個服務替換另乙個服務而無須關心其底層的實現技術，唯一要考慮的服務介面是用通用的
web服務和
xml標準定義的。靈活性帶來的另乙個好處是可以充分利用現有的
it資產
:遺留應用和資料庫，通過將它們納入
soa而不是替換它們來使其成為企業整體解決方案的一部分。這種架構最終將使企業的
it架構能夠更快速、更有效地適應業務需求的變化，換句話說，就是能夠「隨需應變」。
2.「業務相關」。
soa與其他
ti架構的最大區別在於它與業務的關聯性，一直以來，
it存在的主要問題是
it人員與業務的脫節，而
soa中的每一項服務都可以完成實際業務流程中的一項任務，例如，可以把一項服務叫做「更新客戶訂單狀態」。如此一來，服務立刻與業務發生了密切的關係，業務人員可以參與服務的建立並且用它們定義新的業務流程，從而實現服務驅動型企業的目標。由於
web服務遮蔽了底層的技術細節，因此業務人員和
it人員都可以專注於業務邏輯的實現，二者的共同語言就是「服務」。這是一種全新的思路並且將對企業
it系統的建設產生深遠的影響。
soa帶來的兩大優勢靈活性和業務關聯性是過去的
ti系統不曾提供的，為什麼
corba
或其他分布式計算技術不具備這些特點?與
soa相比，
corba
更強調技術，它需要一批精通相關技術的開發人員，而這樣的技術專家實在不多。
soa則相對簡單並基於真正的通用標準
web服務系列規範，這使得很多人都能掌握其實現技術。
更進一步地來看，
corba
與soa
在架構途徑和哲學上都存在一些根本差異。在
soa中，分布式的資產是「粗粒度
(coarse grained)
」的服務，它們完成一些有用的功能，諸如「更新客戶訂單狀態」等。而在
corba
中，分布式的資產是物件，每乙個物件都有自己的屬性和方法。例如，
order
物件具有
status
屬性和update
方法，對於架構設計師來說處理這些物件是非常煩瑣的並且需要具備相當的知識和技能。要保持這些「細粒度」物件的一致性是非常困難的。在
soa中，控制和功能可能要弱一些，但是它很容易管理，這種方法的技術性可能不夠強，但它卻能很好地協調機構和人在
it專案中的作用。
soa可能成功的乙個根本原因是「業務驅動」。僅由
it部門設計開發的
it架構由於缺少重用能力和企業範圍內的一致性，很難獲得長期的成功。
soa的出現將使我們能看到
it與業務完美結合的成功例項
:業務夥伴幫助推動企業
it架構的實現，這並不是因為他們喜歡架構設計，而是因為他們看到了
soa與業務的緊密聯絡。
本文出自 「唐大老師
」 部落格，請務必保留此出處http://tscjsj.blog.51cto.com/412451/84636
面向服務的體系結構 SOA
偶長期以來一直想寫一篇關於soa的文字，但是遲遲沒有動筆。偶今天感冒在家，終於可以有這個機會咯。面向服務的體系架構 service oriented architeture，即soa 在今天這個軟體業中，可謂是如雷貫耳，如日中天。其架勢直逼當年 物件導向 object oriented oo 出道之...
面向服務的體系結構 實現難題
show toc 歡迎來到 msdn 體系結構 發布日期 6 21 2004 更新日期 6 21 2004 本期的其他文章 通過建立並遵循能夠將公司特有的各種標準結合起來的路線圖來確保成功 easwaran g.nadhan eds 部門主管 摘要 本文討論了各種用來解決企業在實現面向服務的體系結構...
用面向服務的體系結構做什麼？
對soa的需要 於需要使業務 it 系統變得更加靈活，以適應業務中的改變。通過允許強定義的關係和依然靈活的特定實現，it 系統既可以利用現有系統的功能，又可以準備在以後做一些改變來滿足它們之間互動的需要。現在再來談什麼是soa已經過時，對於soa人人心裡都有一筆賬。我們還是從最基本的說起，什麼是so...