愛恨交加：OSGi的Spring和EJB之路？
對于OSGi，有人評論稱OSGi是“Spring之后的下一個big thing”。不過該文的作者后來又覺得，OSGi也有不少的問題，其中之一就是它在把技術(shù)變得復(fù)雜化。作者是這樣說的：
51CTO編輯推薦：OSGi入門與實踐全攻略
我對OSGi不懷疑并承認(rèn)OSGi解決了許多問題，而且它支持一些出眾的結(jié)構(gòu)模型比如高模塊化（high modularization）以及微服務(wù)（micro services）。然而從另外一個角度來說，在使用了OSGi幾年之后，也體驗了它在不同領(lǐng)域的表現(xiàn)（我是指開發(fā)領(lǐng)域）之后，我真的開始懷疑OSGi了。
這是我喜歡和討厭的OSGi的一些方面：
它從幾百個具有代表性的小bundle中創(chuàng)建出一個系統(tǒng)的概念非常棒。OSGi bundle很好的一點是它們定義了邊界：不僅從依賴關(guān)系的意義上，而且從運行時間的意義上也是這樣。每個bundle可以充當(dāng)一個微應(yīng)用，有自己的lifecycle和用戶，每個bundle能夠仔細(xì)地斷定出哪個對象對外暴露。好好地使用它們，會帶給系統(tǒng)以松耦合，并增加再使用的可能性。而與此同時，OSGi的lifecycle使life更加復(fù)雜。實際上，追蹤服務(wù)和管理服務(wù)所引發(fā)的各個問題很討厭（我曾看到過在它們的bundle activators使用大型的state machines來管理所有事情，這種樣板化代碼沒有人愿意寫）。幸運的是有Spring DM來幫我們管理這些。坦白說，如果沒有Spring DM我絕不會動手開始OSGi項目。盡管Spring DM大大降低了bundle啟動的復(fù)雜度，但仍然很麻煩。我仍然需要啟動OSGi的運行時間、安裝啟動bundles，我還需要確保所有其他我所需要的bundles已經(jīng)安裝和啟動。
我個人覺得，作為開發(fā)者，我們應(yīng)當(dāng)迫使自己執(zhí)行系統(tǒng)的約束。我們不得不自動核對定義的限制，比如說，如果我們讀取了一些我們并不想讀取的類，構(gòu)建程序就會失敗。OSGi的版本概念，通過定義輸入和輸出包，將架構(gòu)參數(shù)（architectural constraints）首次帶入開發(fā)者的日常生活，并引入了一系列新的問題。OSGi是這樣解決運行時間的版本問題的：它給每個bundle自己的class loader，并讓class loader看起來像它所在的版本一樣。這也帶來一系列問題，因為它改變了你環(huán)境工作的方式。你的代碼在所有你的單元測試中都可以通過，但一旦執(zhí)行在OSGi的運行時間上，就會崩潰；Libraries崩潰因為這提升了運行時間中的類；Singletons被設(shè)計為靜態(tài)對象不止一次地被創(chuàng)建，周而復(fù)始。當(dāng)你在不斷地調(diào)整你的模塊構(gòu)建說明時你會經(jīng)常終止，而且絕對會在你的整個系統(tǒng)中傳播反直觀的依賴關(guān)系。Spring DM也是這個問題：通過在你的服務(wù)中添加一些指令并且不斷地調(diào)整你的class loaders，你仍然需要調(diào)整和傳送依賴關(guān)系。
尤其是類的導(dǎo)入更是帶來很麻煩的問題。你很快會注意到，沒有強(qiáng)大和自動集成的測試組件來配合OSGi，你無法繼續(xù)下去。
現(xiàn)在說一下我的結(jié)論：
在考慮OSGi之前，我會切實核實是否在不關(guān)閉系統(tǒng)的情況下我能否在運行時間中轉(zhuǎn)換bundles，即使在這種情況下，我也會再次查看這些需求，來看看是否我會把他們限制在一個角落里，在這里我可以使用其他技術(shù)在動態(tài)時間上來動態(tài)地加載模塊。還有其他選擇可以生成這種結(jié)構(gòu)條例（比如使用一個IOC container，使用獨立的container來執(zhí)行模塊依賴等等……）許多這些東西都很接近KISS原則，避免所有其他附件的樣板化代碼并構(gòu)建配置，這因此讓你更加敏捷。
回歸到我的題目上，還有一種技術(shù)擁有這樣的特點（我是指讓技術(shù)更加復(fù)雜），那就是EJB。Spring是最流行的實例：技術(shù)更加復(fù)雜，開發(fā)周期更加困難。也許我們會在未來的幾年內(nèi)在OSGi中看到同樣的境遇？我無法斷定，時間將驗證一切。
【編輯推薦】
