幾千年來，巴別塔的故事一直是人類面對的一個核心的困境。為了交流和溝通我們人類創造出語言，但溝通與交流仍然存在障礙……相同語言之間的溝通依語境的不同，尚且存在巨大的鴻溝，不同語言之間更是讓人坐困愁城。

在物質文明高度發達、人工智能都已觸手可及的今天，程序員一樣在面對這樣的困境。我們的先輩基於那時的技術條件，基於那時的業務需求，映射性地逐步發展出FORTRAN/COBOL這樣命令式的程序設計、C/PASCAL這樣過程式的程序設計，到C++/JAVA這樣的面向對象的程序設計，再到今天WebService這樣面向服務的程序設計。於是各式各樣的異構性層出不窮無所不在，硬件（CPU和指令集、硬件結構、驅動程序）、操作系統（不同操作系統的API和開發環境）、數據庫（不同的存儲及訪問格式）都不盡相同，高級語言更是依賴於特定的編譯器和操作系統API編程，它們彼此互不兼容，需要開發和運行環境的支撐。這樣的異構性使得各種不同軟硬件之間在不同平臺不能互聯互通，再加上網絡協議和通信機制的不同，系統之間還不能有效地相互集成，如同不同族群之間互相比劃著溝通。很難協同組織去面對挑戰。

雖然語言不同，但人類需要表達的內核是相似相通的，同理，各種應用系統之間的許多基礎功能和結構是有相似性的，它們提供的服務和功能是相似的。如果每次開發都從零開始，就像每次造一款汽車都去重新發明一次輪子，那無疑是可笑的。

於是，屏蔽各種異構性，實現某種標準的互操作，以實現復用（而不用每次都去發明輪子），通過松耦合，通過將具體的業務抽象，通過服務的表達和業務過程的原子化去架構規劃整個業務流程，這個架構就是SOA。

——SOA就是這樣的一個範式，用於組織和利用可能處於不同所有權範圍控制下的分布式系統。

打一個形象的比喻，一個企業的最終服務就像是要安排各國大廚準備一桌頂級的菜肴，需要日本的生魚片、清酒，法國的鵝肝、生蠔，德國的啤酒、肘子，中國的爆炒、佛跳墻，在這種情況下，你並不用再去學習各種語言和大廚們交流，只需要自己編排好上菜的順序，在他們制作好的菜肴照片下寫好交付時間，交給大廚，互相點頭確認，按點去取菜,有統一的侍者規範上菜, 以保證最佳用戶體驗。每個大廚後面自成體系，團隊內部用各自的語言交流，如同API後面的那個應用。而你編排的上菜順序，就是流程驅動,服務員取菜就好比是API調用。

實際上，中國古代的四大發明中的印刷術，就是SOA思想應用的典範。沒有印刷術之前，書籍需要手工抄寫，因此效率低下，質量也不穩定，無法保證一致性。有了印刷術，出版效率和內容一致性提高了數量級！最初的印刷是刻板，這就是“復用”，如同軟件通過組件的封裝，達到重復和在不同場合使用的“復用”效果。但是，刻板印刷就是一個緊耦合，一塊刻板只能印某一本書的某一頁，其中具體的“字”無法復用，就如同軟件技術中微軟VB開發的com+組件就只能在windows環境中使用，無法與JAVA開發的EJB組件進行復用和編排，因為他們與開發環境和運行環境是緊耦合的，要在UNIX環境下使用，必須重新開發，相當於換書就得換版。而後的活字印刷就徹底解決了這個問題，文字和版面之間是松耦合，通過排版來實現一本書的印刷版面…….這又是數量級的躍升——如同我們可以封裝服務，形成一個個API，通過服務編排的API聯動來實現業務流程。

現在流行的所謂微服務，就是單個的活字，通過SOA串聯成為文章（服務）。講到這裏，就必須提到schema。松耦合的活字印刷要想做好，每個字之間都需要遵循一定規範，比如字體，字符的大小，都要遵循一定的模式和契約。如同我們可以封裝服務，形成一個個API，服務的共享通過API模式和契約(schema and contract)來協調，通過服務編排的API聯動來實現業務流程。

schema就像是活字印刷裏每個字，都應該有的固定規範，比如字體、大小、線條寬度等等，沒有這個規範，有的字大、有的字小，印出來亂七八糟，而這恰恰是目前微服務領域的現狀：基於XML的很多微服務根本沒有schema！它們僅僅是山寨SOA。

綜上所述，SOA是把復雜的業務系統切分成一塊塊小的獨立系統，每個系統都叫一個服務，對外提供一組獨立的API，然後通過API聯動組織起完整的業務來。在每家企業發展的初期，通常一個或幾個數據庫表格就完成了業務，像大多數小企業那樣。但當企業的業務系統復雜性膨脹到一定規模後，就必須考慮如何將各個子系統按照彼此獨立的服務切分開來，不然以後會亂成一團麻，根本就無法管理。

這種聯動，按照業務流程的要求是可以一步步串起來，提供無限的復雜度。這是企業內部的情況。那麽，在外部呢？現在各種雲服務廠商也有著無數的API，每一個都可以看成一個獨立的服務。但如果把這些獨立的服務也串起來呢，那就可以創造出一個個全新的應用。比如：有三個獨立的單位，第一個單位是地方衛生系統，他的數據庫保存的是該地某個人的醫療保險記錄；第二個單位是某個醫院，他的數據庫中保存的是某個人在該醫院所有的就診記錄；第三個單位是保險公司，他的數據庫裏保存的是某個人的參保記錄。本來他們的系統互不相幹，通過SOA的API聯動，就可以很方便地根據一定條件從上述幾個子系統中分別獲取數據後，組織起一個完整的新業務流程。比如，如果某人以前參加過社保醫療保險，並且去年就診次數不多於5次，同時前三年沒有在保險公司購買過任何醫療保險，那麽就可以給這個人提供50萬的醫療保險，不然就少一點或者拒接保險申請，等等。

……可見，API聯動的想象空間是無限的，但前提是開放！

因為每一個API就如同一個單獨的音符，你稍微聯動一下，它就能形成一個曲調；

如果你是一個大師，你就能寫成一個恢弘的交響樂章；

如果你......進入CDIF......

SOA與基於CDIF的API的聯動