面向服務的體系結構-SOA

 

   偶長期以來一直想寫一篇關於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,哈哈