#技術分享# SOA 我的一點愚見

       自去年加入新的公司到如今整一年了，職涯過程有些迂迴，但整體實在曲折中攀升，首先談談我所參與公司的產品，該產品定位於SOA架構（SOA這玩意其實不是很新鮮的事物，大致上對其有必定的認知）。可是沒有實操的經驗，因此一路走來到如今，感受是失敗居多，同時也印證了古語：「失敗是成功之母」，特別是最近的一段時間，我一直在反思這一年來SOA下如何設計與架構以及實施，多少有點本身的體會，記錄下來，算是本身成長的步伐。
  
     第1、業務的成熟度，SOA下最核心的一條就是 服務的可重用性。撇開技術不談，首先服務發佈是爲了知足某一特定的業務實現，因此，業務的成熟度直接影響到SOA架構下服務的設計與可實施程度，選擇SOA架構的背景是業務具備必定的成熟度，並且在相對的一段時間內，該業務是趨於穩定的，而不是變化的。另一種情景就是做爲產品設計者，對產品進行了高度的抽象，能夠把底層公用的服務進行明確的描述說明，在這種模式下，SOA的引入纔可能體現其複用的價值。不然，接口滿天飛，每一個業務的變動都須要對接口進行一次修正，而與之關聯的服務都必須對此作出適應性的調整。其後果沒法想象。
  
       第2、渠道與業務服務剝離，首先這裏定義的渠道是以總狹隘的渠道，是技術上的渠道，例如 http表單、WS服務、Restful、socket、ftp、MQ等，這些都是做爲數據傳輸的技術實現，僅僅是一種數據通訊的載體，在SOA模式下，必定要把渠道與服務作明確的切割，這裏角度的討論的粒度比較細緻一些。服務是業務邏輯的實現，渠道僅僅是數據傳輸的通道，渠道能夠多種，可是業務實現只有一種，把這種思惟投影與傳統的J2EE架構上，則表現爲四層架構（web層、應用層、服務層、數據層），這種也是我的比較推崇的架構模式，傳統的三層架構是一種被一些專家定義爲是貧血模型，其實我也贊同這種觀點。而這種投影在SOA架構則體現爲（ web層、應用層、服務BPEL、服務提供層、數據層 ），惟一去別的一點就是 傳統的四層架構 服務層的服務提供了一個總體的業務實現，而SOA下，能夠把服務切割的更加細緻，經過BPEL的組裝實現一個完整的業務邏輯。三層架構下，實施SOA，對服務的粒度切割帶來了更多的限制。

     第3、服務消息的設計，記得之前有這樣的一個面試笑話：問：什麼是J2EE，答曰：增刪改查 就是J2EE。不管是什麼複雜的系統以及應用，都是圍繞數據展開，這就帶了一個新的話題：業務建模。在SOA模式下，爲了實現其服務的靈活組裝，必然要對服務之間的數據進行適配處理，如何符合接口之間消息設計沒有必定的規則與邏輯，對於服務流程定製是一種可以噩夢，要分別針對不一樣的服務之間進行數據適配，顯然這種是不可取的，特別是針對產品性的開發。一開始要內部業務流轉的模型進行高度的抽象，從而定義出合理的接口消息協議。從而更好地實現服務的組裝。

    第4、 事務控制，在SOA下，技術挑戰之一就是事務的控制，這一點我也沒有很好的答案，一種是基於JTA的跨庫事務，一種是基於跨域的數據庫事務，二者沒法同時知足，這個也是一直困擾個人一點，無解。
   第5、安全性考慮，安全在SOA下顯得尤其重要，由於其分佈式部署帶來的一些問題，例如消息的完整性、消息的不可抵賴性、接口的容錯性等這些都直接影響SOA運行的健壯性。    第6、SOA下數據服務的提供，在SOA下，數據層是一個什麼樣的角色，如何定位數據層、以及數據層在SOA模式下提供什麼方式的服務能夠更好的知足系統，目前對於如今的我仍是有所難度，例如SOA模式數據共享問題，元數據管理等等此類的問題。          寫完這些，都11點半了·~~ 收拾一下，買菜作飯。技術在重要也是爲了生活。堅持不作技術男。哈哈~~~~~~