偶長期以來一直想寫一篇關於SOA的文字，但是遲遲没有動筆。
偶今天感冒在家，終於可以有這個機會咯。
面向服務的體系架構（Service Oriented Architeture，即SOA）在今天這個軟件業中，可謂是如雷貫耳，如日中天。其架勢直逼當年“面向對象”（Object Oriented ，OO）出道之時。偶們都知道，對象是現實世界中實體的縮影，面向對象編程，即面向現實世界中的實體編程。那麼“服務”又是什麼涅？如何面向“服務”去架構呢？這個東東雖然大家都聽說過，但是真正理解起來的想法可謂是千奇百怪哦。
偶雖然也不能說真正讀懂SOA，但是偶覺得偶想象中的SOA，絕對是架構設計的巔峰之作。更為重要的是，SOA並不遥遠，近得唾手可得。
從面向過程到面向對象到現在的面向服務，軟件的抽象程度逐漸提高，軟件的复用率也逐漸被人們作為重要話題一再提及，面向過程時期講的是函數的复用，面向對象時期講的是類和對象的重用。從零散的函數升級到了整體的對象級别，明顯是層次的進步。到了面向服務時代，就應該是組件級、或者說構件級的重用。
然而項目中可能會出現千奇百怪，種類繁多的各種服務構件。有時候，被調者根本不知道誰會來調用，調用者也不知道應該去調用誰？（您可能覺得不太可能，但是偶可是深有體會的哦，偶要調用的組件可能還没有寫好，可能還只出現在計劃中，你根本不知道它會部署在哪台server中，是一個什麼樣的接口，但是偶這邊的業務也得進行了）。
談到這裏，不得不引出所謂的服務中間件的概念了。其實這對偶來說是一個很陌生的概念，也是一個正在探索的概念。像ESB(SUN的openESB)和ogsi都可以作為中間件的基礎。偶覺得，既然要SOA,要分布式，就要進行得徹底一點。服務的使用和服務的提供應該圍繞着這個中間件來進行，我注册了（不一定要實現），你就可以使用。所以SOA應該不再是點對點式的服務提供和調用的關系。服務調用者不一定要知道服務提供者的接口細節，因為我只關注你在中間件上的服務注册信息而已。至於調用方式到底原則跨平台跨語言的Web Service，還是選擇皇家正統的EJB，那就看到底要把這個架構做到何種程度的松散耦合了。
很多人看到這裏（如果能忍受偶的繁體文字和淩亂文筆堅持看到這裏的話）都覺得SOA是一個很亂很亂的東西咯。所以不得不再談談關於如何將這些亂七八糟的東西整合到一起來，即所謂的集成。
要做應用集成，就看看以下幾種繼承的層次
數據集成：說白了就是用同一個數據庫，同一些表啦。需要集成雙方知道對象的底細啦（數據庫都知道了，還不是底細？）
方法集成：就是你調我的方法來獲取我的數據，你可以不用知道偶的數據庫設計結構啦。但是你必須綁定在我的方法上。
業務集成：在應用系統之間建設業務集成總線，實現業務數據按照一定的規則在應用系統之間流動。這個好像有點SOA的感腳咯。
表示層集成：通過注册表示層的url和唯一的一個門户系統，就可以把多個應用系統進行集成，偶們現在正是這麼做的，偶滴感腳：耦合程度很低，但是很多問題哦。
B2B集成：跨組織的應用訪問，通過傳輸協議（HTTP）和數據描述（XML）為核心的技術路線，繼承程度不可能很高。但是雙方耦合程度也最低。
如果涉及到SOA和應用集成的話，那麼傳統的一些架構模式可能不再適用了，像什麼MVC啦之類，因為最起碼，在你的架構裏，得多加一個層面“集成層”。
綜上所述，偶要做出一個小小的，不算很嚴謹的結論啦（各位GGJJ，偶發現自己真是不擅長言辭，不要罵偶膚淺）。SOA是一個架構設計思想，而不是一種具體的技術，要實現SOA，首先得定出game rule。對於多個業務系統之間，這個rule必須保證是中立，不依賴於任何一方的。然後業務系統要想納入這個SOA的集群中，就必須依賴於制定這個rule的Service Manager，而非另外一個真正要被依賴的業務系統。彼此把接口暴露給Service Manager就可以了。
SOA的要義就是：
松散耦合
位置透明
規則中立
偶肯定地認為，在不久的將來，SOA必定會大行其道，成為改變軟件世界的一次革命。偶將成為SOA的忠實FANS,哈哈
