Nuxeo公司探祕：從Python遷移到Java

成立於2000年的Nuxeo公司是一家開源的企業內容管理領域的專業公司。2006年，他們宣佈正在進行從Python到Java的核心技術平臺的遷移。四年之後，InfoQ再次採訪了Nuxeo的CEO Eric Barroc，以瞭解這種技術轉換的進展情況，以及他們新的技術棧和在ECM領域所處的地位。同時，我們也對動態和靜態類型語言各自的優點進行了一些探討。

　　ECM市場的發展遵循這樣一個常見的模式：起初市場由專業的企業軟件提供商如Documentum、Interwoven、Vignette和Stellent所主宰。隨後，IBM帶着FileNet，微軟帶着Sharepoint也進入了這個市場。隨着這些大型的通用軟件提供商進入這個市場，開源軟件公司也逐漸成爲令人矚目的參與者。這些開源軟件公司包括Nuxeo和Alfresco。按照Barroca的說法，在更普遍的意義上，ECM工具也逐漸成爲了一種日用品軟件：

大家每天都面臨着這樣一個問題：如何管理範圍日益增加的電子化存儲信息，如何識別可能泄露的信息，並避免法律糾紛。理所當然地，隨着微軟的Sharepoint把基本的內容管理特性和概念交付到主流商業用戶的手中，使得ECM產品逐漸成爲一種日常能見的技術。我們相信開源軟件的成熟和增長，以及近來認可的工業標準都會促使用戶將人力物力投入到這個領域中。

與此同時，業務也在尋求實現新系統，更新技術的機會。90年代構建的產品已經走近產品生命週期的終點。現在創建的內容，是移動、社交、開放和互操作的世界，這正是Nuxeo平臺架構孜孜以求的目標。

　　Nuxeo的核心架構構建在Java EE之上，使用Java EE作爲主要技術棧並通過OSGi提供的模塊系統進行構建。Nuxeo構建了自己的運行庫作爲其使用的組件模型，例如，它允許在服務端和客戶端之間交換調入或調出的EJB服務。

　　產品大量使用了Java EE的標準，包括：

數據存儲抽象層使用JDBC、JPA和JSR-170
事務管理使用JTA (XA)，連接池則使用JCA技術（若未提供應用服務器，則使用Apache Geronimo）
Web引擎和REST API使用JAX-RS
UI層使用JSF(與Seam和RichFaces配合使用)

　　Barroca告訴我們：“這些標準實施良好，雖然組件並非標準，但功能卻更加強大，幾乎能解決所有問題”。“Lucene、Hibernate、Eclipse以及許多不很知名的組件，使得應用系統的構建變得輕而易舉。我們認爲Python能很好地運用於許多應用場景，但對於我們的目標市場而言，它並不是合適的技術平臺。

　　Nuxeo產品總共使用了大約100個庫。除了Barroca在前面提到的外，關鍵的庫還包括：以jBPM作爲工作流引擎、OpenSocial和OAuth的內嵌控件和社交特性（Apache Shindig），以及Apache Chemistry提供的CMIS（內容管理互操作服務）。

　　系統的構建基於Maven和Hudson，並以JUnit作爲單元測試框架。目前，產品支持JBoss、Tomcat和Jetty，而且平臺的大部分內容也能夠運行於純粹的OSGi之上。要增添一個新的支持Nuxeo運行的應用服務器還是比較快的，幾天就能完成相應的工作。

　　Java庫所具有的深度和廣度是轉換到Java平臺的一個主要動力，但Barroca還提到了其他原因。

市場：Java應用系統的市場非常龐大。所有的公司都知道Java技術，大多數公司也在使用Java應用系統。很多公司在IT系統中使用了Java技術。所有的系統集成商都具有廣博的Java知識。

社區: 同樣龐大。例如，Java Apache社區就非常了得。每年都有一些關於Java技術的大型會議（JavaOne、ApacheCon、Devoxx、Jazoon等等），以及成百上千的小型會議。

技術規範：在Java世界中，很多技術都有基於已發表的技術規範的實現與參考實現。這有助於規範的清晰化，代碼的互操作性，同時也推動了規範的實現者去做到極致。

我們還受益於許多高水平的工具。這些工具包括虛擬機、調試工具、集成開發環境以及監控和性能定基等。

　　Barroca談到了重新構建的平臺架構與開源開發模型在ECM領域開闢了新的市場，使得Nuxeo佔據了有利的位置。

新型的獨立軟件提供商（ISV）正在使用ECM 平臺，將業務知識打包到軟件中，以創建和銷售這些內容應用。從建築項目管理和生物科技與生命科學的臨牀試驗管理，到州和地方政府控制指揮中心所使用的軟件，這些應用跨越了不同行業和職能部門。

　　我們平臺的靈活性和融合了開源技術的軟件特性爲開發內容應用的架構師和開發者提供了便利。這種開發模式使得新的構建內容應用方式變得簡單，清晰，快速。

　　開源ECM也帶動了內容管理市場發展出新的需求。之前，企業之所以沒有部署ECM，是因爲高昂的前期費用，或者缺乏對所構建和定製的應用系統的控制。現在，這些問題有了新的解決方案。

　　一個備選方案是在JVM上運行Jython編寫的程序，因爲Jython是用Java編寫，以JVM作爲目標運行平臺的Python實現。但Nuxeo沒有采用這個方案。

我們不惜時間，希望能夠實實在在地利用在ECM解決方案積累的六年經驗，按照我們的想法去從頭構建一個完整的平臺。這不僅是編程語言的轉換，也是平臺的轉換。我們要創建一個完整的ECM平臺，由開發者所設計，爲開發者而設計，那些ECM廠商還停留在口頭上的想法，我們卻在技術上將他們變成了現實。在這個行當裏，很多商業軟件廠商的擴張策略是通過併購來構建自己的軟件產品線。但他們只有一套軟件，卻沒有一個技術平臺。在過去的四年裏，我們已經可以構建完整的技術平臺，並通過它來創建內容應用。

　　考慮到Nuxeo系統的項目被重新設計和重寫了，我們該如何比較兩個系統之間的差異。

在性能方面，取決於你的度量值，新的系統在規模上至少提升了10到100倍。功能特性的數量增加了大約4倍。在開發者的兼容性和易用性方面，不僅保持了先前的優點，還提供了更多的工具和體驗。新平臺的整體表現比舊平臺翻了一番，但離翻兩番的提升還有些差距。

　　起初的轉化工作花費了超過55個人年的工作——而Barroca之前粗略的估計是10-20個人年的開發代價。

如果算上其他貢獻者和持續的開發，我們花費了150——200個人年。但是我不是很喜歡用人年來衡量軟件開發，因爲對於開發者而言，都沒有誰有固定的人年值，更何況公司呢。我們有一個非常資深的開發團隊。

　　那麼，Nuxeo的老用戶對於這個改變的反應如何呢？Barroa告訴我們：

從安裝數量上看，約80%的客戶可以接受這個改變。對於那些不願採用新平臺的機構，可由社區的力量來保證對舊平臺的繼續支持。這就是開源開發模式的迷人之處。一種技術能夠存活依賴於用戶和開發者羣，我們把這看作一種“有未來”的優勢。

　　既然Nuxeo同時使用了Python和Java，因此有必要談談這兩種語言的優點。通常的主張是動態語言有着更快的編碼速度，因爲他們天生具有更強的表現力。靜態語言則可以在測試階段節省更多的時間，因爲缺乏類型信息使得用動態語言編寫的代碼更難測試，而且動態語言也比靜態語言運行速度慢，擴展時所需代價更大。Barroca告訴我們：

在研發Nuxeo的實踐中，我們同時使用了動態類型語言和靜態類型語言（Python和Java）來編寫大規模的應用系統，其中有成千上萬個類，數以百萬計的代碼行規模，我們可以肯定地說靜態類型語言更適合編寫此類應用系統。

使用靜態類型語言編程，我們可以對編寫的代碼進行有效的靜態分析，這會帶來如下的好處：

集成開發環境可以提供正確的代碼自動補全
集成開發環境可以知道所有類中所有方法和字段的用法，便於搜索和重構
更多的編譯時檢查
發現代碼中存在的模式和缺陷的工具
根據代碼使用的實際類型生成文檔的工具

在絕大多數的情況下，動態類型語言的方法總是接受同一種類型的參數，所以除了少輸入一下參數的類型外，動態語言不會帶來任何好處。但靜態類型語言使用顯式類型，這不但沒有任何阻礙，並且它本身也是好的文檔。

另一種情形是，當需要真正的多態時，現代的靜態語言提供了泛型，以此獲得一部分（並非全部）動態類型語言的優勢。

有些時候，例如Python、Javascript、Ruby和其他動態類型語言，體現出來的另一種優勢是，可以在運行時修補一個對象實例，給它添加行爲（在Python領域，這常被稱作Monkey Patching）。這好像不錯，但它對理解代碼，代碼靜態分析，調試等來說就太糟了。它可能在修修補補時很方便，但從長期來看，並不是個好辦法。

最後，動態類型語言也提供了反射工具來找出一個未知類型對象的屬性和方法，但是Java從Java 5開始早就有這些特性了，所以動態類型語言在這方面也沒有什麼優勢。

　　Barroca希望深入探索最近在Java EE 6和Java SE 7中發佈或者即將要發佈的技術。這些技術包括：模塊系統、JSF 2、Bean驗證、媒體組件和新的NIO庫。他仍然相信Java對他們的產品而言是最好的技術。

我們也爲我們所創造的技術而感到自豪，從運行時到我們在高層（包括UI）所創建的模塊。它並沒有被公開，因爲我們完全將其看作是ECM的一部分。但平臺中仍有一些好東西有助於改善Java應用程序。擴展系統、基於Seam/JSF的模塊化UI、分佈式彙編引擎和許多組件都是我們在創建模塊化Java應用系統時，頻繁用到的重要技術。在定製基於Nuxeo的應用系統時，不需要分離出UI來單獨定製，你可以通過插件來完成。這是一個非常開放和可擴展的模型。