???????? 剛剛讀了Grady Booch主持的一個關于SOA的在線討論的談話記錄，它被發表在IBM developerWorks，你可以訪問該鏈接看到這個記錄——《
Grady Booch 討論 IBM Rational 桌面工具的 V7 發行版、SOA 和 Eclipse》。?
???????? 我在2005年末開始關注SOA的相關主題，我的視線主要是從技術角度深入的，同時我是從需求與過程認識SOA的。這一點與Grady Booch所持的觀點相同（大多數人也可能認同這種觀點，這也是我最初堅定不移的，然而隨后許多做市場宣傳的人出來講SOA，把我最初對SOA的認識改變了，甚至迷失了，而從Grady的顧慮來看，是我看到的很多人對SOA理解存在錯誤——“SOA 的最大顧慮的問題：我的體驗是組織未能理解正確的體系結構——以及導致該體系結構的過程——是正確使用 SOA 的前提。”）——
Bill Higgins：Grady，是什么在過去幾年來導致人們對 SOA 產生了濃厚的興趣？它是技術驅動的還是市場驅動的？
Grady Booch：我認為它是事物發展的必然結果。曾經有一段時期，各個組織忙于 Web 化 (Webify) 他們的系統（如果“google”是一個動詞，那么我當然也可以使“Webify”成為一個動詞）。在此期間，各個團體設法獲得合適的體系結構來將過去對客戶不可見的功能置于在線。因此，隨著 Web 標準和最佳實踐的發展而存在技術“推動”，還存在著象征需要此類訪問的客戶的業務“拉動”。大多數組織都完成了較易訪問的資產的 Web 化，現在最引人注目的潮流是使較難訪問的資產變得可訪問——即傳統上處于非以 Web 為中心的遺留系統中的資產。所以，體系結構問題就是……如何做？
當然，此類異類系統之間的連接并不新鮮。遠程過程調用、文件共享、FTP 等全都是眾所周知的機制，諸如 CICS 等消息傳遞機制或諸如 CORBA 及其后繼者最近所展示的機制也是如此。如果您有以 Web 為中心的系統，并且您希望通過防火墻傳遞消息，好了，這就是 SOA 的起源。我們如今看到的 Web 服務實際上解決的是使用標準 Web 協議來通過防火墻傳遞消息的問題——即帶大 S 的 SOA。這就是我認為人們當今在為 SOA 而努力的原因，也是為什么支持它們的工具現在是如此及時的原因。?
?????? 作為分布式體系結構的一種，SOA主要解決異構系統的遠程調用問題，和EJB等一樣。而在SOA中主要采用Web Service，大寫的Web Service特指SOAP Web Service，經過一年多的發展，它越來越成為業界的標準了。
?????? 我曾在2006年4月份寫過一篇有關SOA的文章，主要討論Web Service——實現SOA的首選方案——的本質，和ESB，其實那時我的設想還是從模仿硬件體系結構出發，進行隱喻的。后來我接觸的澳大利亞維多利亞理工大學的研究成果，其主要是構建中間件——在我看來就是Workflow和Adapter的結合。在我和國內某中間件廠商的技術人員——他主要就是研究SOA——時，感到大家對SOA的理解越來越泛化了，使用傳統的CORBA或者自行研發的遠程協議實現“服務”亦被稱為SOA。
??????? SOA的概念其實很簡單，就是將程序功能（就是函數、方法function,procedure一類的東西）封裝成可以互相調用的“服務”——服務就是粗顆粒度的方法。如果僅僅討論SOA理論的話，應該不會涉及到具體技術，互相調用暗含了異構系統互相調用的意味，而這種調用在面向對象理論中就被稱為消息傳遞了。
??????? IBM、BEA等公司做的事情就是在做上層的封裝，也就是說通過他們的工具你不需要學會.Net下編寫Web Service的方法，也不需要學會配置Axis——其實軟件開發的發展就是一層層的向上抽象，計算機科學家不斷將重復的勞動進行封裝，交由編譯器、虛擬機、中間件等去完成。我們接觸到的澳大利亞那個項目就是針對遺留系統產生適配器，比如一個系統使用的是.Net構建的，那么我們只需要通過我們的軟件做一些配置，比如選擇“.Net”接口，就可以將原系統的某個方法變成Web Service，如果是用Java編寫的，也同樣只需要做配置就可以了。BEA的那套東西也大概如此，你不需要自己動手寫Web Service了。
??????? 其實這都是聽上去很簡單的事情，實現起來考慮的事情比較多，比如訪問失敗，重復調用，安全問題等等，這只不過是IT領域公共的問題，在SOA研究的一個分支而已。程序實現只是操作步驟，比如很容易就學會使用Eclipse+Axis創建Web Service，使用Net調用該Web Service。困難的是將什么設計成service？
??????? 我們最近在規劃的一個項目就涉及到很多的遺留系統，不同平臺、不同的程序語言、不同的數據庫。所有的功能只創建一次是個很好的決策，我認為，我們主要會使用Delphi和Java，要創建30多個系統，原來是不可能Delphi和Java互操作的，但現在可能了，因此設計很重要，比如Delphi進行了一個復雜的處理，而且是跨數據庫的（這樣估計是不能使用存儲過程來避免重復了），這樣Java就不必重寫一個了，只要給需要調用的方法穿一件Web Service的外套就好了。而以前用VB、PB編寫的系統也可以復用了——其實這是Web Service的初衷。
?????? 我依然覺得找到硬件體系結構的感覺來劃分服務就比較好了。然而分布式調用的性能問題、安全問題、穩定性問題等，也會影響服務的劃分。
???????
?????? Grady談到的另一個Web Service好處就是其使用公共協議，無論是XML還是HTTP，都可以解決防火墻阻斷問題（當然原來用防火墻避免的安全問題現在只能另想辦法了）。
?
?????? SOA的發展（也就在過去的一年里）讓各個層次的IT人員都可以找到自己的位置，有服務提供商（據說很多公司已經盈利很多了），這包括之間面向最終用戶的service，比如我們把Office Live一類的都可以稱為web service；另外還包括面向客戶端程序員的service，比如利用google提供的map service來構建自己的地圖系統。還有服務創建者，有的服務提供商同時也是這個角色，服務創建者可能會赤裸裸的手工編寫SOAP文檔，WSDL等，但大多數會使用.Net平臺，Eclpse、RAD等工具，更抽象的創建則會使用中間件。然后就是提高這些工具的廠商，比如IBM，BEA，Oracle，Microsoft等，當然還有就是更高層次的協議、規范的制訂者和領導者，比如IBM、BEA、Oracle等提出的SCA/SDO標準。而針對該標準的工具也已經被集成在IBM、BEA的集成環境中了。如果SOA的出現就像當年J2EE的出現一樣的話，那么標準的推出特別是相應的產品的推出，就會像當年的J2EE一樣將分布式系統，或者企業級信息系統的實施遇到的困難比如跨數據庫事務處理、遠程過程調用等變得容易，而且是提供一攬子解決方案，來解決前面所說的問題，當然還包括不同語言特殊類型轉換、跨服務事務操作等現實問題。另外架構師、領域專家要劃分或設計服務，這與在J2EE領域的研究發展是類似的。
???????
??????? 國際廠商都在宣傳SOA落地，然而我們對于SOA的理解還過于樸素，很關鍵的問題是我們又落后了，當咱們戰戰兢兢編寫Web Service來實現異構系統互操作時，國際廠商已經經過大量項目的實踐研究出種種模式、最佳實踐、特殊問題的解決方案，甚至已經提出標準了。我雖然還沒有仔細研究兩個規范，但是從對于J2EE的經驗來看，標準肯定是用來簡化服務的創建、調用、部署的。而這又會是一場新的拼殺，Microsoft、各種學術機構也都有自己的套路，來解決相同的問題。就像.Net和J2EE同樣解決企業級問題一樣的，IBM在SOA占據了領跑者的位置，就像SUN領導J2EE規范一樣。