canonical

???? http://www.primeton.com/

??? 普 元軟件公司是國內專業的中間件提供商，從國家得到了不少投資，做出來的東西也是相當的龐大。最近普元EOS的宣傳和發展的勢頭都很盛。其宣傳材料中屢次提 到“軟件的涅磐“這一用語，這明顯是一種危言聳聽之舉，當然這在業內也不算什么新鮮的事情。按照EOS的宣傳，"以圖形化的構件組裝方式“畫”出來的軟件 無論從結構上、形式上還是開發過程上都堪稱簡捷而美的軟件"。這一提法倒是別開生面。圖形化與簡潔，與美竟然還存在著這樣必然的聯系，實在是一種創舉。
???? 從普元公開的資料來看，EOS的一個鮮明特征是全面基于xml描述，即所謂的xml數據總線。表面上看起來，xml結構內置于系統內核中似乎很時尚，但實 際上，EOS產生的xml描述文件中的大量條目都是EOS自身的結構要求，而與實際業務無關，即EOS描述文件中的有效信息量密度很低。這是一個危險的信 號。EOS的xml描述本身可以看作是一種完全新的編程語言，但這個語言似乎沒有什么抽象能力和組合能力，對于關聯的表達能力也很弱（到處都是數字 id)。如果直接手工編寫，那是一件要死人的事情。只有通過集成開發環境的可視化界面，EOS才呈現出可理解的一面。
???? EOS的概念與Language Workbench是不同的，其中的結構似乎很難進行有效的擴展。而所謂的xml總線技術更加劇了這一點。xml數據總線其實與面向過程編程類似，只是過 程變成了service，數據變成了xml節點而已。對象與簡單數據結構在結構表達上的本質差異就在于對象通過成員函數可以封裝動態結構。雖然xml節點 的表達能力遠遠超越了普通的數據類型，但充其量也不過是對現有數據的規整的樹形表示，并不具有動態計算能力（甚至是最簡單的lazy evaluation）。喪失了動態計算能力，就意味著我們很難在系統中動態引入結構，程序中所操縱的結構都需要事前定義出來，這將極大的限制系統的可擴 展性。另一方面，xml節點受限于自身格式，其描述關聯的能力也要弱于java對象結構本身。對象通過引用訪問相關對象，其隱含意義是對象處于同一地址 （狀態）空間中，可以非常自然的保證對象的唯一性并實現同步訪問。在跨越狀態空間的邊界時，xml表示是有意義的，因為我們需要把所有的結構都暴露出來并 加以描述(外在化）。而在狀態空間內部，我們需要更加緊致有效的表述方式。
???? 在具體的實現中， EOS暴露給程序員的xml操縱API相當的原始，使用起來很繁瑣。在前臺展示頁面中，如果不使用EOS的界面組件，提取數據本身就是一種不小的困難。 EOS的前臺展示組件與后臺的結合也比較弱，后臺改變之后，缺乏有效的手段來檢測并保證前后臺結構的同步性。所謂的前臺構件層似乎只是提供了一些幫助函數 和功能固化的組件，并沒有提供什么有效的利于結構抽象和結構重組的機制。
???? 整個EOS的構架看起來很象是一個monster, 我很難想象它的各個部分如何才能獨立的，深入的發展下去。