SOA焦慮症

1996年，Gartner提出了SOA概念。

Gartner還曾提出兩個很著名的概念：

ERP，企業資源計劃。以企業資源的角度來組織企業的人、財、物、信息。此概念產生於大生產時代MRP以後，號召把企業的上下游也歸入到企業通盤戰略考慮當中。由於社會已經變成了產業鏈，從原材料到生產到物流到銷售到售後服務，每一個環節都影響生產企業。生產已經變的不是第一重要了，供不該求時代已經結束。進入營銷渠道的時代。

CRM，客戶關係管理。以客戶服務的角度出發來從新組織企業的人、業務、流程、信息。此概念在ERP的基礎上，把眼光從供應鏈上游和生產企業轉移到了客戶終端。生產時代結束，營銷推銷時代也快結束，不考慮客戶感覺，不和客戶交互交流，一味生產和推銷，是不可能獲勝的。

（從什麼角度來組織資源和流程，頗像技術界的面向過程、面向對象、面向組件、現在面向服務了）

在這樣的大背景下，Web2.0也是順應這個概念產生的，口碑營銷、精確分衆、圈子、即時通訊、短信、博客，各類交互工具順應時代而產生。

ERP和CRM都是應用層面的產物。

這樣的應用，在信息化方面如何落地。

因而，SOA概念隨即而出。

1996年的美國，互聯網已經很發達了。可是互聯網技術並無跟上。企業仍然封閉在本身的信息化世界。雖然有CORBA、COM+、RMI/EJB這些技術模型在支撐，但向互聯網公衆提供信息服務，而非上下游合做夥伴提供信息服務，CORBA、COM+、RIM/EJB仍然在穿透防火牆和通用數據格式傳輸上仍然存在問題，三個體系都有本身的通信協議和數據傳輸協議，普通消費者沒法參與其中。

2000年，XML產生。隨機基於HTTP的SOAP、WSDL、UDDI產生，Webservice做爲一個基於互聯網通用技術基礎上發展的數據通信協議和數據傳輸訪問協議體系產生了。

可是Webservice只是定義了基於通用互聯網技術的數據通信和數據傳輸訪問。就至關於底層通路通了。可是基於上面的應用呢，仍是沒有一個規範。就至關於，路通了，可是在這條路上什麼樣規格的車跑起來最順暢，尚未這個規範。（固然你能夠不要規範，本身造個本身的車，之後在和擁有統一規格的車一塊兒管理和運行時交互時就有了問題。這個描述也爲了回答至關一部份人提出的那個問題：咱們既然有了Webservice，那幹嘛還要SCA/SDO呢？）

SOA就是幹這件事的。

可是，SOA，業界大佬太急。就如同在.COM大潮中，每一個企業都急於申明咱們是一家.com公司。因而，這個市場混淆了各類視聽。

作工做流的、作OA的、作業務基礎平臺的、作組件的、作中間件的、作EAI的，都號稱本身已是SOA了。有的說SOA是爲了業務敏捷（能夠靈活調整系統以適應快速發生變化的業務競爭。現摘錄一段話：SOA經過把傳統應用模塊分解成更小的構件，並把這些構件看成能夠重用的Web服務，CIO們就能經過選擇和安排所需構件，來生成最貼合的系統。這和當年咱們作WINDOWS DNA架構是多麼類似。但當年SOA已經提出，但並無人說WINDOWS DNA架構是SOA架構。沒流行這個名詞的緣由？？），有的說SOA是爲了系統整合，有的說SOA是企業總線，有的說SOA是種業務分析設計思想，有的說SOA是技術架構模型，有的說SOA相似UML的做用，可使業務設計人員和技術設計人員有共同語言，有人更說SOA就和web2.0同樣，就是個概念。頗像當年微軟急於把本身全部產品都打上.NET標誌同樣，最後弄的你們都搞不清楚什麼是.NET了。直到2007年發佈WPF、WCF、WF以後，.NET的技術走向纔算基礎架構定型。SOA和當時的.NET很是類似。

現在，SOA規範才真正落地爲SCA和SDO。工做流規範業界已經成型，WF也符合業界工做流規範，因此SOA中並無定義工做流規範。而對應WPF的SOA顯然也不須要，畢竟SOA考慮的是業務接口服務層面，而非這個服務以什麼樣的圖形界面規範來讓客戶存取，沒有必要（中國普元補上了這一環節。中國普元也是OSOA頂級成員之一。光有接口沒有UI，仍是須要程序員動手寫這個UI，業務人員不可能沒有UI去作靈活改變業務功能和流程，即便有BPEL和DSL也不行。別給業務人員任何技術的東西，別想着DSL和UML就能讓業務人員用起來）。因此，SCA和SDO已經夠用了，SOA架構真正成型。

但SCA和SDO是2007年8月才定型的（雖然2005年已經草案了）。因此以前急於號稱是SOA產品的廠商不知做何感想。

我閱讀了SCA和SDO標準，我也對比了過去我研究的CORBA，我也對比了微軟的WCF，架構思想竟然很是相似。

當年DEC和IBM主導定義的CORBA，太複雜，SUN和微軟都作了定製化裁減，發展了本身的RMI/EJB和COM+。因爲Webservice的出現，微軟當即發展了基於Webservice的架構體系：WCF。可是JAVA世界因爲標準制定牽扯了大量廠商的利益，發展緩慢。而IBM也不肯意尷尬的在SUN的JAVA世界作個影子巨人。IBM一直盤算着如何作領袖。

因而SOA真正架構，吸取了CORBA的教訓（IBM因爲當年的CORBA沒有帶起業界標準非常懊惱，此次要捲土重來，更加學聰明瞭，誰說大象不能跳舞），也結合了Webservice，也借鑑了WCF（WCF也是在Webservice基礎上發展起來的架構，不少技術借用了Webservice的技術，而非另起一套底層），終於產生。

而OSOA組織，最近纔出現SUN的蹤跡，而SCA和SDO標準中並無SUN提交的草案。

JAVA和.NET兩大平臺，封閉而專有。而IBM須要的是一種業界標準制定者。SOA這回達成了IBM的意願。不管是JAVA，仍是.NET，甚至是PHP，只要符合SCA和SDO，就能夠提供業界標準服務接口。

掙脫了語言和專屬平臺優缺點的樊籠，IBM藍色巨人又成爲自由的業界之神。

我爲何這麼關注和信任和理解SOA。其實和我自身所處的軟件行業很是有關係。

我是作企業管理軟件的。很早業界就都有共識：軟件不能這樣賣了。咱們把一套辦公系統賣給了運營商，人家用咱們的軟件作服務，收費比咱們賣軟件還多。

因此，就連賣軟件老大微軟也在喊着軟件服務化。

過去是在企業內部運行的軟件，一個企業不外乎也就那麼多人那麼多數據。可是，一旦把軟件服務化、互聯網化了，就不抵有多少人訪問了。

因此，咱們如何應對軟件服務化、互聯網化。

上億人訪問的Webservice，其架構就不能象搭建企業內部運行的軟件架構，你看Google，都有幾十萬臺PC集羣的計算資源才能支撐互聯網服務。咱們過去的傳統的企業內部機房磁盤陣列和計算機集羣架構不適合在公網上了，咱們的數據庫也不適合服務幾億人了。

因此，我特別關注咱們如何軟件服務化，軟件服務化的架構是什麼樣的？

其實，業界都在往一個方向跑，不論是Google、仍是Yahoo、仍是微軟、仍是我們的百度、QQ、盛大、阿里，你們都在往軟件服務化、互聯網的方向跑。（若是你僅僅是把眼光放到SAAS，放到和過去的ASP[應用服務託管]去對比，眼界顯然須要更高一些）

應用軟件運行須要基礎設施。首先，基礎硬件設施，幾十萬臺PC的集羣如何虛擬文件系統和計算資源分配，這就是雲計算要解決的問題。如今雲計算是個熱門，Yahoo、Google、IBM、微軟都在研究和建設。但微軟慢了一步（微軟在互聯網計算上一直不敏感，用傳統軟件的方式看互聯網），因此WFS沒有出來（可能沒想通做爲集羣中的一個節點資源，如何加入集羣，和集羣同構，還能符合我的桌面計算管理）。

有了雲計算硬件基礎，還須要數據存取軟件基礎。有了分佈式文件系統，文件存取應該沒什麼問題，但關係數據的存取，這是如今全部數據庫產品都沒有解決的。Amazon看到了機會，推出了S3服務。全球互聯網就是個超級計算機，而S3就是這個計算機上的數據庫。

而全部的SOA應用，都必須在一個容器中運行，不然，有外界調用這些服務，這些服務運行中使用的資源誰來管理呢（不少人不明白容器是幹什麼用的，不明白中間件的來歷，也不明白爲何JAVA和.NET都要作容器。若是你作應用，你本身還要負責那麼多底層的分配與釋放與併發，那麼你作的既不專業，也累，也不穩定，不如交給系統商去管理）。容器負責內存、資源的分配、調度、回收，負責安全，負責事務，負責併發，負責池化。而這些SOA服務，也必須能隨時升級，就必須具有軟件熱插拔的功能。如今熱的OSGi研究就屬此類。

有了這些基礎設施，咱們的應用就必須SOA化，成爲軟件服務，讓全部人來使用。使用者一方多是一個C#寫的客戶端，多是一個PHP網站，多是一個JAVA網站，也多是一個FLASH。

全球大大小小的公司提供了這麼多Open API，如何調用。用各自的語言？JAVA？C#？PHP？Javascript？

我想會產生一種新的語言來組織這些Open API，而不是這麼技術化的程序員使用的開發編碼語言。

它，會是DSL。Domain Specific language。它可能會高於Javascript，但和Javascript相似，但又低於JAVA，C#這些重型開發語言。但它確定是動態語言。這樣隨時改變流程，隨時改變應用。這就是業務敏捷。

這就是我預想中的將來SOA時代計算環境。

你，還在用傳統的業務基礎平臺思路搭建企業管理軟件架構嗎？

將來SOA時代，將來軟件服務化時代，你，準備好了嗎？

後記：
20%的企業在上第一代系統，不須要SOA。但軟件產品提供商須要考慮SOA，以防將來的集成。但如今對於企業沒有需求，不會由於SOA加分買單。
30%的企業在所有替掉第一代系統，不須要SOA。但軟件產品提供商須要考慮SOA，以防將來的集成。但如今對於企業沒有需求，不會由於SOA加分買單。
30%的企業在整合本身內部的第二代系統，可能須要SOA，但實質上採用的少。但軟件產品提供商須要考慮SOA，以防將來的集成。客戶可能會由於SOA加分買單。
10%的企業在整合本身的上下游，須要SOA。
10%的企業開始爲最終客戶提供信息交互服務，如同咱們看到的Google API同樣，須要SOA。

如今關注和編寫SOA時機正確嗎？正確，由於你看上面的比例，有50%的企業有SOA需求。 但若是你面臨的客戶市場偏偏不是這50%，而是另外的50%，那麼奉勸你繼續作好如今的產品，SOA還不須要。