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