作者 Scott Delap and Floyd Marinescu譯者 Jason Lai（賴翥翔）& 郭曉剛 發布于 2008年4月30日 下午12時12分

社區

Java

主題

應用服務器

標簽

Spring框架,

Spring Dynamic Modules

從獲得一千萬美元風投開始算起剛滿一年，如今SpringSource（Spring框架背后的公司）搖身一變，成為應用服務器提供商，并且舉著SpringSource應用平臺（SpringSource Application Platform）的黃鉞白旄對現有的Java EE服務器陣營發起挑戰。SpringSource應用平臺是構建在Spring、OSGi和Apache Tomcat之上的應用服務器，這個新的應用服務器摒棄了原有的Java EE服務器標準，自然而然地將Spring編程模型展現其中，隨之而來的還有一套基于OSGi內核構建的全新部署和打包系統。今天是該項目在SpringSource評估許可下Beta發布版發布的重要里程碑。在隨后一個月內會有基于開源許可（GPLv3）版本和訂閱版本的通用發布版（General Availability，GA）放出。

SpringSource應用平臺不是Java EE應用服務器。盡管對于WAR部署它提供了支持，但EAR部署和其它EE的規范，如EJB等，都不在支持范圍之列。SpringSource應用平臺被重新設計，并把關注點直接放在對被開源項目所廣泛使用的Spring組合的支持上。特別地，這個應用服務器是基于Spring組合編程模型構建的，利用Spring Dynamic Module實現基于OSGi的部署。SpringSource在Eclipse基金會的Equinox OSGi運行時環境的基礎上創建了一個具備日志、跟蹤、啟動、類加載、管理和其它特性的“內核”，Tomcat被作為一個包（bundle）納入到平臺當中，從而實現對Web功能的支持。

InfoQ借此機會對Spring框架的共同創始人兼SpringSource的CEO Rod Johnson進行一次采訪，對這個新的應用服務器展開探討。在闡釋這個新平臺的必要性時，Rod一針見血地指向目前開發和生產環境的許多痛處，比如跨配置文件出現的元數據重復現象，還有本質上在項目中常常在服務器上再部署服務器（即在部署應用時，在同一個部署單元附帶部署許多工具和框架），而與此同時這些部件卻主要只使用它們應用服務器中的Web容器部分的事實。因此，SpringSource希望在當今的開發需要的基礎上提供一個更為簡單的平臺。

在談到這個新應用服務器的優點時，Johnson強調了模塊化：對于服務器本身以及提供給開發人員的打包和部署模式來說，這是個兩全之策。通過利用OSGi，以及OSGi包之間依賴關系相互作用的性質，運行的應用服務器只會激活在它上面運行的應用所需要的特性，從而削減服務器的內存占用和啟動時間。這個依賴關系支持的功能還允許依賴類庫的多個版本共存，以支持不同應用；因而應用服務器的某些部分就可以很容易地更新和重啟，而無需重啟整個服務器。從開發的角度看，服務器的模塊化也使得在代碼變化時，可以很快地進行極其細粒度的重部署。

Johnson在言及OSGi和SpringSource對Eclipse Equinox OSGi的使用時，高度評價了OSGi規范的運行時實現所帶來的基礎平臺，但也表示OSGi在日常的應用開發上屬于比較底層的地位。Johnson闡述到，SpringSource希望幫助開發人員在企業環境中輕松獲得價值。在新的編程模式的構造背后，這個新的應用服務器將OSGi的許多復雜性抽象了出來。Johnson接著說，應用服務器將會支持PAR，一套新的可部署單元，簡化企業應用在使用OSGi上的復雜性（下文會詳細說明）。

當被問到對于沒有對OSGi提供原生支持的遺留類庫的支持時，Johnson回應到，他們已經在上面花費了很大心血，使得應用服務器環境和類加載功能能夠以兼容的方式和遺留類庫協作。

當被問到對不提供OSGi原生支持的類庫的遺留支持時，Johnson回答說他們已經在這方面投入了大量精力，保證應用服務器環境和類加載功能可以和遺留類庫兼容工作。SpringSource還會為他們在如Tomcat之類的項目上所做的任何變更給這些項目提交補丁，使這些類庫可以和OSGi包兼容。

Johnson解釋到，應用服務器的主題代碼將在GPL v3的許可證下發布。開發人員在服務器、編程模式和部署單元上要接觸到的所有部分都會以開源的形式提供。SpringSource還將提供應用服務器的商業版本，包括支持、保障、管理和監控的功能。

談到Spring應用平臺發布之后對Spring組合繼續支持JavaEE有什么影響，Johnson回答說：

……我們從根本上說并不打算把Spring用戶社區驅趕到任何方向。我們僅僅是給用戶另一種選擇。Spring的哲學是用戶總是正確的。用戶是聰明的，他們完全明白自己的需要。不管用戶是否選擇SpringSource應用平臺，我們覺得用戶總會歡迎多一點選擇的……

Johnson保證SpringSource一定會繼續確保Spring組合以及其他SpringSource產品兼容于其它應用平臺。接著Johnson還評論了即將到來的Java EE 6規范：

Java EE 6重點在模塊性，這個方向是正確的。很可能SpringSource應用服務器會在一定程度上符合Java EE 6。Java EE 6分成A、B、C三種規格（profile）。我們幾乎肯定會實現A和B規格，C規格里面我非常確定將實現Entity Beans 1.1模型以及一些遺留技術。我還不能說是100%確定，因為Java EE 6規范還沒有定案。

最后，InfoQ和Johnson討論到了SpringSource應用平臺的大局方面。對于轉換到OSGi，他的回答是：

傳統的應用服務器模型正逐漸過時。BEA和IBM正在用OSGi逐步重新實現他們的應用服務器。 SpringSource現在就提供OSGi支持。從統計數字上看，大多數人都不會部署到完整的平臺上，他們部署到Tomcat。他們選擇了Spring 編程模型而非Java EE。市場已經作出了選擇，問題只是開發者還要和服務器斗爭多長時間。

Johnson解釋說他對SpringSource應用平臺成功的自信來自三個原因：

• 它是第一個建立在現代技術基礎上的產品。符合Java EE規范已經不是至高無上的目標。干凈的代碼基礎是我們的一項競爭優勢。我們在設計和實現中滿足的是現今的需求，而不是10年前的需求。
• POJO編程是現在行業的方向所在。過去POJO編程是被強行嫁接到其它產品上的。在我們的產品中，POJO編程是設計的前提。
• SpringSource應用平臺采用的OSGi技術是下一代技術的基礎。

除了Rod Johnson，InfoQ還與SpringSource的Rob Harrop探討了新應用服務器的一些技術細節。對于與傳統Java EE應用服務器相比有何增減，他說：

……JPA和JMS都支持，但我們沒有包含任何特定實現。對于JPA，我們支持Hibernate、 OpenJPA和Toplink。我們在OSGi環境中增加了對加載時織入的支持，而且會尊重應用的邊界，因此不會意外污染應用間共享的庫。不包括 JNDI，我們用OSGi Service Registry來取代它。Servlets是通過內嵌的Tomcat來支持的。JEE中有而SpringSource應用平臺沒有的東西包括 Entity Beans等等。

接下來InfoQ問到Spring Dynamic Modules。Spring DM成為公開項目已經有一段時間了。對于模塊化部署，我們向Harrop詢問Spring DM是否增加了什么新東西：

這個平臺引入了應用的概念，應用由一個或多個Bundle組成。應用中的包有明確的作用域，可以防止發生應用間的沖突。在應用把服務發布到OSGi service registry的情況下，防止沖突尤其重要，誰也不想見到服務之間發生沖突。

我們引入了Import-Library語句，因此在應用中使用第三方庫變得更加簡單。你不需要再寫一大串不直觀的 Import-Package聲明，Import-Library可以自動為指定的庫引入所有必需的package。像Hibernate JPA這樣的庫還可以跨多個Bundle，可見Import-Library確實物有所值。

至于為了讓Spring DM在平臺中運行而進行的擴展，為數不多。

Harrop接下來說明了新的PAR格式：

Spring DM掌控下的Bundle（Spring DM powered bundles）是包含META-INF/spring/*.xml文件的普通OSG Bundle。Bundle啟動的時候META-INF/spring/*.xml文件會自動成為該Bundle的 ApplicationContext。Spring DM提供了一種機制讓各Bundle通過Spring NamespaceHandler導入和導出服務。

一個PAR（Platform ARchive）本質上是一組OSGi Bundle，通常其中有一部分是在Spring DM掌控下的。這些Bundle共同組成了一個邏輯上的應用。編程的時候完全是純粹的OSGi、Spring和Spring DM——PAR沒有改變什么。

以前一般用Buddy Classloaders之類的技術來解決遺留/非OSGi庫的問題，SpringSource這次是怎么做的呢？Rob回答說：

簡單來說我們避免做這樣的事。Buddy類裝載、動態import、require-bundle，這些我們都明確回避，因為維持一致的類空間太困難了。我們也不會提供任何專有的替代機制。

相反，我們給Equinox增加了一些低級的鉤子，以實現典型的場景下的資源裝載。我們擴展了類裝載來支持加載時織入，并且把裝載語義丟到一邊。我們操縱context classloader，讓第三方一如既往地看到類。PAR是其中的核心角色，因為它定義了上下文類裝載以及加載時織入的可見范圍。

對于一些最糟糕的情況，我們會提供修補版的庫，讓它們能在OSGi中工作。修補版的庫可以通過SpringSource Enterprise Bundle Repository獲得，我們的修改也會提交回相應的項目。

最后Harrrop著重強調了這個應用服務器在模塊化上的優勢，應用服務器因此可以維持最低的內存占用。平臺在運行中才設置依賴項，因此只有確實用到的依賴項才會被裝載。

最近幾年中有過許多關于Java EE標準是否已經死亡的討論，而今天我們看到一個可能很重要的應用服務器不帶Java EE支持。這種變化對于未來有何影響？你怎么看？

查看英文原文：SpringSource Launches New Application Server without Java EE