EOS/普元：概述：中國IT業的悲哀

公司引入了普元的EOS作為公司的基礎架構平台，今后的所有項目將逐步向EOS的遷移，但對EOS的研究又讓我不得不說出以下話： 

1、EOS確實夠簡單，但未免簡單過了頭：從語言層面看EOS 
因為EOS將成為我們的開發語言，所以有必要從語言的層面認識EOS。 
去除EOS的圖形化外衣，我們看到EOS就是一門以XML表示的類似Basic的腳本語言，這門語言相當簡單，因為其語法元素極少，如下： 

過程聲明 <-> 構件的創建 
過程調用 <-> 構件調用 
條件語句 <-> 構件圖中的IF結點 
循環語句 <-> 構件圖中的"{" 和 "}"結點 

因為語法元素少，加之圖形化的編程方式，這就形成了EOS的”入門容易“的優勢。 

現在讓我們理清思緒，仔細考察這門簡單的語言，我們會發現這門語言竟是如此簡單，甚至連最基本”變量聲明與賦值操作“的語法元素都不具備，大家是否會覺得驚呀？這是因為EOS不需要聲明變量，EOS提供了一個全局變量給所有的構件使用，這就是EOS大力吹捧的”XML數據總線“。 
全局變量和局部變量都不需聲明，可以直接使用，那么語言編譯器是否可以提供類型檢查，或者是否能提供”未用變量“的警告的呢？答案是不能，這些問題必須在運行時才能解決。 

進一步沿着語言層面思考下去，我們會發現這門語言”沒有類型“，注意我說的不是”弱類型“或”類型檢查“。這門語言中所有變量全部都是”字符串“，系統也不能提供格式化的機制實現其宿主語言(java)類型與字符串間的轉換。 

有人可能會懷疑，既然這門語言這么簡單，功能這么弱，那它根本就不可能在實際項目中使用，而我們從普元的宣傳和他長長的客戶名單列表里頭看到的並不是這樣的狀況，這是為什么呢？其實答案還是在java，因為java是EOS的宿主語言，也就是說我們可將EOS看作類似groovy/jruby之類的擴展語言，當這些擴展語言實現不了某些功能時，我們就可以直接使用宿主語言進行開發，這就與在C語言中使用匯編類似。 

好了，現在我們已經清楚EOS實際提供了兩個語言層面：一個是簡單但功能弱的語言層面，一個是復雜（java復雜嗎？）但功能強大的語言層面。這種做法其實和groovy/jruby沒什么區別。 

討論了語言，現在可以設想一下這門語言的應用，我設想的EOS應用的最佳方式是將EOS作為一個工具包，以利用EOS的圖形化能力給應用提供可視化的配置能力，當然對於以工作流為核心的應用，將EOS作為流程配置的工具也是極佳的應用方式。這樣的應用方式就類似於將groovy應用於項目的單元測試一樣，因為這些擴展語言因為其某些不足不可以成為應用的基礎（核心）語言。 

然而，普元公司可不這樣定位自己的產品，他們希望自己的EOS作為應用的平台或者核心語言，現在扯上SOA的大旗后，EOS甚至可以作為企業的基礎架構，我想問：EOS能當此大任嗎？ 

2、構件？ 
EOS宣傳的”構件“是什么意思呢？其對”構件“的定義是”構之件也”，好象還是不明白吧？ 
讓我們再次從語言層面來看這個問題，EOS中的構件就是過程，其實再簡單不過，更准備地說，EOS中的構件就是一個不過參數沒有返回值的過程，這樣的過程其語義如何准確描述和定義呢？EOS的構件同樣無法解決這一問題，那么構件的組裝就和過程的嵌套沒有什么兩樣。 
甚至於EOS中的構件都算不上是”模塊“，因為模塊通常包括了一組功能或者說一組接口。而EOS的構件只有一個功能，因此將EOS的構件理解為”接口“也是錯誤的。然而EOS的產品白皮書以及EOS在市面上的宣傳都有意忽略了EOS構件的本質的特征，這些只是為了忽悠的需要，說的和做的根本不是一個東西。當然我們大家都能理解，這就是國情。 

3、IDE的作用？ 
圖形化的IDE對我們應用的作用是核心的，本質性的嗎？應用甚至企業的基礎架構的圖形化有這么重要嗎？開個玩笑，也許EOS的插件本身就可以用EOS本身來實現，這樣這門語言就是自洽的了。 

4、EOS與IOC有關系？ 
EOS和IOC有關系，這個說法比較新鮮。EOS的構件本就是過程式的，何來依賴注入？難道是說EOS能自動注入一個構件所需要的嵌套構件，這就可以稱為IOC了？這樣說任何語言都是IOC的。 

5、EOS的O-X mapping？ 
O-X mapping？照貓畫虎也畫得太不象了吧，EOS中何來對象，何來“O”？竟敢也趕這個時髦。 
我理解EOS所說的O-X mapping只是將數據庫中的記錄取出放到其XML總線上，這就叫記錄到XML的映射了，只是仔細了解過EOS的數據庫操作構件的人都應該明白這個O-X mapping的含義吧。這樣的名詞只能拿來嚇唬一下半懂不懂的經理級人物，李佳不也說這應該叫做X-R mapping嗎？ 

6、EOS與AOP？ 
EOS有一個組件攔截功能，具體說就是允許為組件配置一個過濾器，以實現組件調用前的處理和組件調用后的處理，這個功能實在是太簡單了，達到幾乎沒有實用價值的地步。這樣一個功能也能扯上AOP嗎？諸位自己判斷吧。 



說了這么多，在不斷佩服EOS的攻關能力的同時，也不斷地為國內的IT技術人而悲哀。在我看來，稍有技術敏感的人都應該能看到EOS作為企業技術平台的嚴重問題，然而現實是那么多的做了多年技術的程序員/經理/老總們，竟然都那么迷信圖形化，那么討厭代碼，輕易做出將EOS做為基礎架構的決策。這不是中國IT產業的悲哀嗎？ 

參考資料： 
http://www.iteye.com/topic/13888?page=1 
http://canonical.iteye.com/blog/33794 
http://canonical.iteye.com/blog/33795 
http://www.bjug.org/20050524.html

http://www.iteye.com/topic/210475