我對SOA的反思 SOA架構的本質

年初的時候，寫過一篇名為「

國內eai正當時，bpm為時尚早，workflow持續增長，soa依然概念

」的blog日誌。那個時候，我認為soa還依然是個很「虛」的概念。而現在，我只能說：sorry，那時候的我，錯了。soa已經不再是概念，而是乙個實實在在的構架了。

在寫完那篇帖子之後，我一直在反思soa到底是什麼，是一種什麼樣的架構。因為在在tibco中國研發中心工作的原因，可以接觸到tibco的一些最新的soa產品。

雖然了解到一些基於soa構架的產品，但總覺得依然「隔著一層紙」，並不清楚什麼才是真正的soa架構。

很多時候，我依然會認為soa構架只是滿足把應用暴露成service（或者說是webservice），以soap等之類的訊息進行資訊的傳輸，以及基於service之間的一些業務邏輯的整合應用（比如bpel）等。

我相信，這樣的困惑，在國內很多中介軟體產品、應用產品中都存在，在很多國內的開發人員、架構師心中也存在。

昨天，有幸參加了csdn主辦的「soa產業鏈及未來企業軟體趨勢」研討會，收穫不小。參見昨天寫的blog隨感「

參加「soa

產業鏈及企業軟體趨勢研討會

」的感想

」。經過那些專家們（毛新生、tiger、李勇、梁耀文等）的解惑，對soa是一種什麼樣的構架，有了一些更深刻的認識。

但說真的，如果不是目前在tibco中國研發中心工作的經歷，以及所接觸到一些國外最新產品構架的巨變，僅憑昨天的聽講，也很難把握毛先生他們所說的那些soa理念。

具體昨天有哪些重要的理念就不在重複的敘述了，參看「

參加「soa

產業鏈及企業軟體趨勢研討會

」的感想

」，裡面有詳細的敘述。

今天只談反思：soa架構的本質。

剛剛看到一篇新聞，講的是sap

代號為a1s的新產品軟體設計方法，參見「

新聞分析：解密代號a1s

」。這和昨天研討會上，

sap的李勇先生，所闡述的一些觀點很類似：

sap的產品在往

soa架構遷移中，經歷了三個大的步驟：第一步，提供更好的服務層面的容器或平台的支援；第二步，把業務抽象成服務，確切地說，是抽象業務物件（

business object

）；第三步，把面向垂直或水平層面的各個產品，基於業務物件進行整合。

事實上，這就包含了昨天各個專家所闡述的soa架構的本質：一切圍繞業務物件（business object）或業務模型（

business model），至於「服務」，只是這些業務模型暴露出來的形式，因為以統一的服務形式暴露出來，更便於不同**商和客戶之間的資訊互動。

在gartner十年前提出soa概念的時候（2023年），尚沒有web service技術。soa架構的本質，並不是說把你的應用或者元件包裝成service就是soa，而是說，你需要基於一種構架，能夠讓你的產品能夠更適應「業務敏捷性（business agility）」。但是這種業務敏捷性僅僅是一家提供商或產品是很難滿足的，肯定需要各個不同的**商協助完成，不同的產品之間能夠比較容易的進行訊息互動。這樣的靈活度肯定不是傳統的基於訊息的eai產品所能夠滿足的，需要一種新的協議或標準來支撐。—— 當web service誕生之後，所有的大廠商都發現這是一種非常符合他們需求的技術。

但是服務的本質，是在後端能夠提供一套「業務模型」。而製成這種業務模型或業務物件構建的技術，正好就是前幾年所熱炒的「模型驅動構架（

model-driven-architecture）」。事實上，現在各大廠商都在基於這個構架在轉變自己的產品構架，bea，ibm，tibco都在進行著這樣的巨變。

在回頭想想我們常說的「soa真理三角」：資料（data）——元件架構（component architecture）——組合（composition）。因為幾乎所有的業務模型最終需要被「業務物件+業務元件」反映出來，而它們之間需要進行一系列的組合和互動，來滿足業務的處理。

在soa聯盟組織的sdo和sca標準，正是用於解決資料和元件模型描述的問題，這方面幾乎所有的eai廠商都加盟進來了，ibm、bea、iona、oracle、sap、sybase、tibco、software ag等等，這其中好包含國內的普元軟體。

我對SOA的反思 SOA架構的本質

我對SOA的反思 SOA架構的本質

我對SOA的反思 SOA架構的本質

我對SOA的理解

相關推薦