Gluecode Software 的主要創始人 Jeremy Boynes，展望 Apache Geronimo 的遠大前程
Gluecode Software 是日益增多的成功地商業化開源軟件的公司之一，它已經將好些很有前途的開源中間件組件（包括 Apache Geronimo 和 Apache Derby 等）合并到 J2EE 應用服務器堆棧中。在最近 IBM 宣布收購 Gluecode 公司后，我們與 Jeremy Boynes（Geronimo 的主要創建者和 Gluecode 的 CTO）進行了座談，聆聽了他對 Geronimo、Java? 未來發展方向和開源狀況的展望。
當首席技術官 Jeremy Boynes 加入 Gluecode Software 時，他帶來了關于將開源軟件和企業級應用開發相結合的第一手資料。他過去是 Bravanta 和 Netmosphere 的首席架構師，通過使用開源軟件，他幫助這兩家公司降低了成本開支。他擁有 20 年的企業計算經驗，曾在 Cisco、BT、Centrum Systems 和 Sequent Computer Systems 任職。他擁有電子工程師學位，并且作為創建者和負責人參與了眾多的大型開源項目，包括 OpenEJB、ObjectWeb、Derby Java 數據庫以及 Apache 基金會的 Geronimo J2EE 服務器項目。
IBM 已經宣布收購 Gluecode Software，這符合它扶持和參與開源社區，同時鼓勵采用開放標準的目標。像 Eclipse、Derby 和 Apache HTTP 服務器（httpd）一樣，IBM 引進 Gluecode Software 的基于 Geronimo 的平臺，來為它現有的中間件陣容提供開源中間件。
|
不要認為 Geronimo 僅僅只是另外一個 J2EE 服務器，其實它是用來構建各種各樣特定基礎設施服務的系統框架的一個開端。
—— Jeremy Boynes |
我們的 developerWorks 成員問 Jeremy：作為 Geronimo 的架構師之一，請為我們介紹一下 Geronimo 的設計目標、架構以及它是如何脫穎而出的。或許您還可以給我們一些關于這種規模的開源項目是如何聚合在一起的方面的見解。
developerWorks：您可以描述一下 Geronimo 的架構么？它的主要組件是什么？
Jeremy Boynes：從 Geronimo 一開始，項目的主要目標就是，通過將支持 J2EE 規范不同部分的許多現有開源項目進行集成，以產生 J2EE 1.4 的實現。該架構專注于兩個主要方面：提供一個框架，該框架有助于集成，但是對其他項目毫無影響；提供一組系統服務模塊，這些模塊組裝在一起就成為最終的服務器。
該架構的核心是 Geronimo 內核和 GBean 框架。該核心提供一個基礎設施，用于控制其他服務是如何配置、激活和管理的，并且控制它們之間的依賴性是如何分辨的。這個核心已經保持得很小，這使得 Geronimo 可以壓縮到最小的設備中。
實際上該核心有兩個變種。一個是輕量級的，設計用于命令行工具或非托管服務器。另一個設計用于傳統的服務器，并且使用 JMX 以便所有組件都得到管理和監控。
在該核心中，我們安裝了一系列模塊，它們提供諸如事務、安全、日志記錄、命名、遠程控制之類的系統服務 —— 應用程序期望使用的基礎設施是可用的。
通過使用這種靈活性，我們可以組裝這些服務以形成特定的應用程序環境。例如，該項目的主要目標是產生一個 J2EE 1.4 環境，我們通過將合適的服務組裝在一起實現了這個目標。盡管這種組裝模型也可以用于其他配，但是我們主要為 Spring 社區工作以產生一個直接支持 Spring Framework 的組裝模型。
這種靈活性功能極其強大，但它在配置控制和管理方面也有其自身的困難。為了解決這些困難，我們在內核中構建了一個強大的配置管理系統，這允許模塊被組裝、注冊和封裝，以便安裝到任何 Geronimo 內核中。特定服務器具體運行哪些配置可由該服務器本身進行控制，如果在企業級環境中，則由外部管理服務進行控制。
我們實際上也將這種配置管理功能擴展到終端用戶應用程序。這使得機構可以在集成或測試環境中創建一個已完整部署的應用程序，然后將其確切的二進制版本經過發布過程轉移到生產環境，或者分發給客戶。
額外的好處是，通過離線完成所有部署，我們可以實際減少生產服務器中的開銷。它也允許我們在部署期間執行廣泛的優化，即潛在地掃描字節碼和優化代碼路徑，而不會影響在線系統。
developerWorks：我知道該項目的關鍵需求之一就是要完全遵循 J2EE 標準。為什么要這么做呢？
JB：這么做基本上是因為，它對我們的用戶非常重要。J2EE 在為應用程序定義框架這方面做了很多貢獻。這些應用程序由不同機構獨立實現，但它們的行為在所有平臺上都是一致的（經 Compatibility Test Suites 驗證過）。這為企業用戶提供了一種保證，如果他們選擇 J2EE，那么不會只針對單獨的供應商解決方案編寫應用程序，或者說應用程序供應商可以一次編寫應用程序，然后在任何客戶環境中運行。
當然，現實世界中的 J2EE 規范還是不完整的，直至今日，仍有一些領域需要知道正在使用的是哪種實現。然而關鍵是，用戶開始選擇他們針對特定解決方案的局限程度。當然，使用開源這種限制會少很多。
證明還只是第一步。為了成功，Geronimo 需要在基本規范之上，為用戶提供明顯的優勢。在該項目中，我們優先關注企業環境中對生產部署影響最大的技術領域。它們主要是與管理、配置、可靠性、可伸縮性和性能相關的特性。
developerWorks：J2EE 規范的哪些部分很難處理，哪些部分比較容易處理？
JB：項目過程中曾經流傳著一個關于“88-itis”笑話 —— 為實現 JSR-88 部署規范的每個工作人員開始都用各自的方言交流，然后很快就變得混亂起來。
需要著重說明的是，該規范的某些部分處理起來非常容易，這是因為我們可以集成許多優秀的開源解決方案。例如，對于 Web 容器我們可以集成 Jetty 服務器或 Apache Tomcat，兩者都具有優秀的“血統”。同樣，我們的 JAXP（用于 XML 處理的 Java API）實現使用了 Apache Xerces，我們的 JMX（Java 管理擴展）實現使用了 MX4J（JMX 的開源實現），我們還基于 Apache Derby（以前稱為 Cloudscape）提供了一個嵌入式數據庫，等等。
面臨嚴峻挑戰的領域，同時也就是阻撓所有 J2EE 實現的領域：使用 Web 服務和 IIOP 與其他服務器的互操作。
developerWorks：已經存在許多能夠勝任的商業 J2EE 服務器。為什么 Geronimo 開源還如此重要？
JB：也有其他的開源 J2EE 服務器，例如 ObjectWeb 的 JOnAS。像 Geronimo 這種項目只能通過開源才能成功，此外，為了獲得商業實體和獨立開發人員的支持，它也必須在類似 Apache License 的 BSD 許可證下進行開發，因為該許可證允許開發混合開源項目和專有技術的解決方案。
例如，Geronimo J2EE 服務器通過 Apache Software Foundation 發布，它基于諸如 Apache Tomcat、Jetty、OpenEJB 和 ActiveMQ 等其他開源項目的組合。
其他組合由該項目或其他機構提供。例如，系統供應商可能使用專有軟件（直接依附于操作系統級別的日志）來替代事務管理程序，而企業用戶可能使用集成他們自己的一致性和審計基礎設施的安全策略來替代安全策略提供程序。
developerWorks： 您是否覺得 Geronimo 的組件化特性有助于開源的開發模型？
JB：我認為類似 Geronimo 采用的模塊化方法，對于任何這種規模的軟件項目都是很重要的，無論對于開源項目還是對于單獨機構的內部項目。
然而我們的最大獲益是，開發受到開放社區的驅動。在社區中，無論個人還是公司都能夠參與到項目中并從中獲益。基于 Apache Software Foundation 及其強調開放、精英和協作的社區，能確保項目的長期發展，同時也防止項目受控于個人行為或單個機構的商業動機。
developerWorks：作為完整的 J2EE 服務器，Geronimo 毫無疑問適合于大型的、分布式的、事務的企業級應用。但對于小型應用來說，哪些方面不適合于使用 Geronimo？
JB： 組件化的架構使 Geronimo 可以從小內存設備一直擴展到企業級應用。我們特別注意將內核保持為占用較小的內存，這樣它就可以用于受限的設備，如機頂盒。然后，用戶可以根據將要運行的應用程序的需要，選擇哪些服務需要配置到框架中。
例如，用于分支機構的簡單服務器可以配置一個 Web 容器、安全代理，還可以配置一個消息發傳遞客戶機，然后在本地運行應用程序。遠程管理和配置功能方便了從一個中心位置對大量設備的管理。
因為 Geronimo 實際上用于服務器應用程序，因此現在可能還并不適合考慮部署到手持或蜂窩設備。盡管如此，隨著這些設備功能的不斷增強，未來我們也許會探索這一領域。
developerWorks：您能談一談將可伸縮性構建到 Geronimo 中的一些方法么？
JB：很高興您提到的是可伸縮性而不是單純的性能（盡管我們在這個領域也非常出色）。在這個使用普通服務器硬件和零許可證成本軟件的年代，可伸縮性常常使我們能夠更有效地將應用程序擴展到更多的機器，而不是像以前升級為更龐大的服務器。
預配置應用程序和根據需要定制服務器配置的能力，使用戶可以將服務器資源更多地投入到應用程序的工作當中，而不是應用服務器的管理開銷。
可伸縮性的傳統制約因素是對 CPU、內存和 I/O的訪問。為了管理 CPU 資源，我們提供了一套線程池。通過調節線程池，可以均衡對入站 Web、EJB 和連接器請求或者由服務器本身生成的請求（比如事務回滾）可用的資源。未來，我們打算將不同服務的線程池組合為一個單獨的工作管理基礎設施，用于均衡負載。我們也引入了中央事務上下文這一核心概念，它使組件無需在共享線程池或緩存上同步，就可以訪問每一個事務信息。
為了滿足內存的可伸縮性，我們認真地控制執行任務時容器分配的內存總量。不幸的是，我們控制不了應用程序自身需要的資源。隨著我們從實際應用程序中獲得經驗，這是一個仍需調整的領域。
我們在適當的地方使用了 NIO（Java 的最新 I/O）功能，以提高 I/O 的可伸縮性。我們特別關注的領域是事務日志，在該領域中，通過與 ObjectWeb 的協作建立了 HOWL 項目 —— 非常高效的日志子系統。
最后，這個問題還處于早期階段。隨著 Geronimo 在真實場景中的壓力測試，實際的信息將會公諸于眾。這方面的問題也一定會引起開發人員的關注。
developerWorks：項目的最大挑戰和最大成功是什么？
最大的挑戰就是項目本身所具有的復雜性，需要實現整個平臺。這些都是在協作但獨立的開源項目生態系統上進行的，這平添了幾分興奮。我想這也是最大的成功 —— 這么多的人能夠團結在一起，共同完成它。
developerWorks：項目開始時，Geronimo 已經構建到什么程度了，還有多少需要編寫？
JB：項目開始時，并沒有實際構建 Geronimo 內核。但是許多可以集成的項目 —— 比如 OpenEJB、MX4J、Jetty —— 都已經有了，并且早已存在了。這些項目的絕大多數都需要進行改進以符合 J2EE 1.4 規范。而當我們 2003 年 8 月啟動項目時，該規范還沒有最終定案。
我們現在馬上就要完成了，但是即使經過了完全驗證，在性能調優、可用性、國際化、文檔化、新特性等到方面仍需努力。
坦白地說，隨著項目的發展，我們知道許多領域需要改進，我們也期望把更多的新思想融合到其中。還有很多工作要做，社區是向每個人開放的，歡迎大家積極參與。
developerWorks：除了日常開發的項目之外，還有其他喜歡的項目嗎？
JB：Apache Derby。看到它走向開源，我非常興奮。實際上，我以前使用過 Cloudscape。看到這樣的項目加入 Apache 并可用，我非常興奮，這使我能夠更加隨心所欲地開發自己的數據庫。
developerWorks：您認為開源在企業中已經有一席之地了么？
JB：企業與以前相比，更加接受開源解決方案，尤其是最近的 12 到 18 個月。企業基礎設施之一 —— 操作系統對 Linux 的廣泛采用，向我們展示了企業越來越易于接受開源技術。我們看到，隨著企業開始對用于數據庫和應用基礎設施的開源技術進行評估，開源技術得到了不斷提升。這些成熟的市場具有清晰定義的規范（適用于商業化），我期望 3 年到 5 年后，開源解決方案在這些市場中會扮演一個重要的角色。
developerWorks：如果需要修改開源的某些部分，您認為會是哪里呢？
JB：有許多東西需要修改。最重要的是，每個開源社區需要修改的都有所不同。實際上根本沒有開源運動，只有各種各樣不同的社區和正在進行的不同形式的開發，開發涉及從 Linux 操作系統、Apache 項目（如 httpd 和 Geronimo），到諸如 Eclipse 和 ObjectWeb 之類的聯盟，或者一些 SourceForge 項目中人們喜愛的桌面應用程序。有太多各種各樣的問題，所以我很難說出具體哪些部分需要改進。
開源的一部分挑戰仍是通信、協作、設法合作、理解商業公司扮演的角色，但仍要考慮個人所做的貢獻，等等。所以最大的挑戰是文化。每個單獨的項目都通過不同的方法應對這些挑戰。
developerWorks：Java 的下一件大事是什么？
JB：是 Geronimo [笑]。Java 語言正處于一個令人關注的階段，越來越多的企業應用開始采用它。我們正在進入一個嶄新的階段，即通過在應用基礎設施級別上使用托管運行時環境和虛擬化技術，可以大大方便人們的工作。所以，我想我們不久將會看到一個令人興奮的增長期。
我們已經看到這種獨立趨勢的蔓延，像 Spring Framework 就非常符合用戶所想。我認為這種百花齊放的情形非常好。而且，也有標準化的過程，因此企業可以完全放心這種技術的未來發展。我們處在一個令人矚目的時代，太多的改革正在進行，太多的新思想不斷涌現，太多的新事物正經受考驗，例如 AOP（面向方面編程）和其他一些輕量級框架。我想這一切都非常令人鼓舞。
developerWorks：您還有其他想要與我們 developerWorks 讀者一起分享的想法么？
JB：從技術觀點來說，惟一最重要的是，我希望我們不要再將 Geronimo 只是作為另一個 J2EE 服務器，而是要把它作為構建各種各樣基礎設施服務的系統框架的一個開端。按照這種想法，制約該框架的只會是我們的想像力。快來參加我們，幫助我們一起構建未來。
同時，我要感謝所有相關人員，因為太多我在這里無法一一提到。感謝為 Geronimo 項目或其他相關項目做出貢獻的人們！