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

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

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

在談到這個(gè)新應(yīng)用服務(wù)器的優(yōu)點(diǎn)時(shí)，Johnson強(qiáng)調(diào)了模塊化：對(duì)于服務(wù)器本身以及提供給開(kāi)發(fā)人員的打包和部署模式來(lái)說(shuō)，這是個(gè)兩全之策。通過(guò)利用OSGi，以及OSGi包之間依賴關(guān)系相互作用的性質(zhì)，運(yùn)行的應(yīng)用服務(wù)器只會(huì)激活在它上面運(yùn)行的應(yīng)用所需要的特性，從而削減服務(wù)器的內(nèi)存占用和啟動(dòng)時(shí)間。這個(gè)依賴關(guān)系支持的功能還允許依賴類庫(kù)的多個(gè)版本共存，以支持不同應(yīng)用；因而應(yīng)用服務(wù)器的某些部分就可以很容易地更新和重啟，而無(wú)需重啟整個(gè)服務(wù)器。從開(kāi)發(fā)的角度看，服務(wù)器的模塊化也使得在代碼變化時(shí)，可以很快地進(jìn)行極其細(xì)粒度的重部署。

Johnson在言及OSGi和SpringSource對(duì)Eclipse Equinox OSGi的使用時(shí)，高度評(píng)價(jià)了OSGi規(guī)范的運(yùn)行時(shí)實(shí)現(xiàn)所帶來(lái)的基礎(chǔ)平臺(tái)，但也表示OSGi在日常的應(yīng)用開(kāi)發(fā)上屬于比較底層的地位。Johnson闡述到，SpringSource希望幫助開(kāi)發(fā)人員在企業(yè)環(huán)境中輕松獲得價(jià)值。在新的編程模式的構(gòu)造背后，這個(gè)新的應(yīng)用服務(wù)器將OSGi的許多復(fù)雜性抽象了出來(lái)。Johnson接著說(shuō)，應(yīng)用服務(wù)器將會(huì)支持PAR，一套新的可部署單元，簡(jiǎn)化企業(yè)應(yīng)用在使用OSGi上的復(fù)雜性（下文會(huì)詳細(xì)說(shuō)明）。

當(dāng)被問(wèn)到對(duì)于沒(méi)有對(duì)OSGi提供原生支持的遺留類庫(kù)的支持時(shí)，Johnson回應(yīng)到，他們已經(jīng)在上面花費(fèi)了很大心血，使得應(yīng)用服務(wù)器環(huán)境和類加載功能能夠以兼容的方式和遺留類庫(kù)協(xié)作。

當(dāng)被問(wèn)到對(duì)不提供OSGi原生支持的類庫(kù)的遺留支持時(shí)，Johnson回答說(shuō)他們已經(jīng)在這方面投入了大量精力，保證應(yīng)用服務(wù)器環(huán)境和類加載功能可以和遺留類庫(kù)兼容工作。SpringSource還會(huì)為他們?cè)谌鏣omcat之類的項(xiàng)目上所做的任何變更給這些項(xiàng)目提交補(bǔ)丁，使這些類庫(kù)可以和OSGi包兼容。

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

談到Spring應(yīng)用平臺(tái)發(fā)布之后對(duì)Spring組合繼續(xù)支持JavaEE有什么影響，Johnson回答說(shuō)：

……我們從根本上說(shuō)并不打算把Spring用戶社區(qū)驅(qū)趕到任何方向。我們僅僅是給用戶另一種選擇。Spring的哲學(xué)是用戶總是正確的。用戶是聰明的，他們完全明白自己的需要。不管用戶是否選擇SpringSource應(yīng)用平臺(tái)，我們覺(jué)得用戶總會(huì)歡迎多一點(diǎn)選擇的……

Johnson保證SpringSource一定會(huì)繼續(xù)確保Spring組合以及其他SpringSource產(chǎn)品兼容于其它應(yīng)用平臺(tái)。接著Johnson還評(píng)論了即將到來(lái)的Java EE 6規(guī)范：

Java EE 6重點(diǎn)在模塊性，這個(gè)方向是正確的。很可能SpringSource應(yīng)用服務(wù)器會(huì)在一定程度上符合Java EE 6。Java EE 6分成A、B、C三種規(guī)格（profile）。我們幾乎肯定會(huì)實(shí)現(xiàn)A和B規(guī)格，C規(guī)格里面我非常確定將實(shí)現(xiàn)Entity Beans 1.1模型以及一些遺留技術(shù)。我還不能說(shuō)是100%確定，因?yàn)镴ava EE 6規(guī)范還沒(méi)有定案。

最后，InfoQ和Johnson討論到了SpringSource應(yīng)用平臺(tái)的大局方面。對(duì)于轉(zhuǎn)換到OSGi，他的回答是：

傳統(tǒng)的應(yīng)用服務(wù)器模型正逐漸過(guò)時(shí)。BEA和IBM正在用OSGi逐步重新實(shí)現(xiàn)他們的應(yīng)用服務(wù)器。 SpringSource現(xiàn)在就提供OSGi支持。從統(tǒng)計(jì)數(shù)字上看，大多數(shù)人都不會(huì)部署到完整的平臺(tái)上，他們部署到Tomcat。他們選擇了Spring 編程模型而非Java EE。市場(chǎng)已經(jīng)作出了選擇，問(wèn)題只是開(kāi)發(fā)者還要和服務(wù)器斗爭(zhēng)多長(zhǎng)時(shí)間。

Johnson解釋說(shuō)他對(duì)SpringSource應(yīng)用平臺(tái)成功的自信來(lái)自三個(gè)原因：

• 它是第一個(gè)建立在現(xiàn)代技術(shù)基礎(chǔ)上的產(chǎn)品。符合Java EE規(guī)范已經(jīng)不是至高無(wú)上的目標(biāo)。干凈的代碼基礎(chǔ)是我們的一項(xiàng)競(jìng)爭(zhēng)優(yōu)勢(shì)。我們?cè)谠O(shè)計(jì)和實(shí)現(xiàn)中滿足的是現(xiàn)今的需求，而不是10年前的需求。
• POJO編程是現(xiàn)在行業(yè)的方向所在。過(guò)去POJO編程是被強(qiáng)行嫁接到其它產(chǎn)品上的。在我們的產(chǎn)品中，POJO編程是設(shè)計(jì)的前提。
• SpringSource應(yīng)用平臺(tái)采用的OSGi技術(shù)是下一代技術(shù)的基礎(chǔ)。

除了Rod Johnson，InfoQ還與SpringSource的Rob Harrop探討了新應(yīng)用服務(wù)器的一些技術(shù)細(xì)節(jié)。對(duì)于與傳統(tǒng)Java EE應(yīng)用服務(wù)器相比有何增減，他說(shuō)：

……JPA和JMS都支持，但我們沒(méi)有包含任何特定實(shí)現(xiàn)。對(duì)于JPA，我們支持Hibernate、 OpenJPA和Toplink。我們?cè)贠SGi環(huán)境中增加了對(duì)加載時(shí)織入的支持，而且會(huì)尊重應(yīng)用的邊界，因此不會(huì)意外污染應(yīng)用間共享的庫(kù)。不包括 JNDI，我們用OSGi Service Registry來(lái)取代它。Servlets是通過(guò)內(nèi)嵌的Tomcat來(lái)支持的。JEE中有而SpringSource應(yīng)用平臺(tái)沒(méi)有的東西包括 Entity Beans等等。

接下來(lái)InfoQ問(wèn)到Spring Dynamic Modules。Spring DM成為公開(kāi)項(xiàng)目已經(jīng)有一段時(shí)間了。對(duì)于模塊化部署，我們向Harrop詢問(wèn)Spring DM是否增加了什么新東西：

這個(gè)平臺(tái)引入了應(yīng)用的概念，應(yīng)用由一個(gè)或多個(gè)Bundle組成。應(yīng)用中的包有明確的作用域，可以防止發(fā)生應(yīng)用間的沖突。在應(yīng)用把服務(wù)發(fā)布到OSGi service registry的情況下，防止沖突尤其重要，誰(shuí)也不想見(jiàn)到服務(wù)之間發(fā)生沖突。

我們引入了Import-Library語(yǔ)句，因此在應(yīng)用中使用第三方庫(kù)變得更加簡(jiǎn)單。你不需要再寫(xiě)一大串不直觀的 Import-Package聲明，Import-Library可以自動(dòng)為指定的庫(kù)引入所有必需的package。像Hibernate JPA這樣的庫(kù)還可以跨多個(gè)Bundle，可見(jiàn)Import-Library確實(shí)物有所值。

至于為了讓Spring DM在平臺(tái)中運(yùn)行而進(jìn)行的擴(kuò)展，為數(shù)不多。

Harrop接下來(lái)說(shuō)明了新的PAR格式：

Spring DM掌控下的Bundle（Spring DM powered bundles）是包含META-INF/spring/*.xml文件的普通OSG Bundle。Bundle啟動(dòng)的時(shí)候META-INF/spring/*.xml文件會(huì)自動(dòng)成為該Bundle的 ApplicationContext。Spring DM提供了一種機(jī)制讓各Bundle通過(guò)Spring NamespaceHandler導(dǎo)入和導(dǎo)出服務(wù)。

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

以前一般用Buddy Classloaders之類的技術(shù)來(lái)解決遺留/非OSGi庫(kù)的問(wèn)題，SpringSource這次是怎么做的呢？Rob回答說(shuō)：

簡(jiǎn)單來(lái)說(shuō)我們避免做這樣的事。Buddy類裝載、動(dòng)態(tài)import、require-bundle，這些我們都明確回避，因?yàn)榫S持一致的類空間太困難了。我們也不會(huì)提供任何專有的替代機(jī)制。

相反，我們給Equinox增加了一些低級(jí)的鉤子，以實(shí)現(xiàn)典型的場(chǎng)景下的資源裝載。我們擴(kuò)展了類裝載來(lái)支持加載時(shí)織入，并且把裝載語(yǔ)義丟到一邊。我們操縱context classloader，讓第三方一如既往地看到類。PAR是其中的核心角色，因?yàn)樗x了上下文類裝載以及加載時(shí)織入的可見(jiàn)范圍。

對(duì)于一些最糟糕的情況，我們會(huì)提供修補(bǔ)版的庫(kù)，讓它們能在OSGi中工作。修補(bǔ)版的庫(kù)可以通過(guò)SpringSource Enterprise Bundle Repository獲得，我們的修改也會(huì)提交回相應(yīng)的項(xiàng)目。

最后Harrrop著重強(qiáng)調(diào)了這個(gè)應(yīng)用服務(wù)器在模塊化上的優(yōu)勢(shì)，應(yīng)用服務(wù)器因此可以維持最低的內(nèi)存占用。平臺(tái)在運(yùn)行中才設(shè)置依賴項(xiàng)，因此只有確實(shí)用到的依賴項(xiàng)才會(huì)被裝載。

最近幾年中有過(guò)許多關(guān)于Java EE標(biāo)準(zhǔn)是否已經(jīng)死亡的討論，而今天我們看到一個(gè)可能很重要的應(yīng)用服務(wù)器不帶Java EE支持。這種變化對(duì)于未來(lái)有何影響？你怎么看？