OSGi vs jboss熱部署

Question

據我所知，在OSGi中，您可以在運行時更新jar而無需重新啓動服務器。但是jboss也有熱部署，其中全耳更新並且服務器仍在運行。

那麼OSGi在jboss中的企業java項目中有什麼好處？

Answer 1

我相信答案和每個OSGi用例都是一樣的：模塊化和更精細的更新粒度。

OSGi不僅僅是在運行時更新jar而不重啓服務器。從您的問題的角度來看，它是在運行時更新jar而不必重新啓動應用程序。我承認我不知道JBoss AS中EAR熱部署的具體實現，但是在任何情況下，EAR更新都不可能被設計爲保留應用程序的整個狀態。服務器仍在運行，但實質上在更新時重新啓動應用程序。這種狀態損失的程度實際上取決於你如何設計你的應用程序，但事實仍然是，你正在做單一的事情。

對於OSGi而言，情況並非如此：應用程序由大量的bundle組成，每個bundle都有希望設計爲處理單獨的功能部分。這種方法可以實現應用程序內部的熱部署，因爲該框架旨在考慮重新啓動任何單個jar爲整個應用程序帶來的影響，並讓其他jar適當地作出反應。這提供了儘可能保留應用程序狀態的能力。

因此，在企業案例中OSGi設計的好處是應用程序的活躍性。沒有必要強調這一點的重要性。的確，有些應用可能會安全地重新啓動的用例。但在我看來，OSGi是目前Java EE唯一真正可擴展和可維護的選擇。最重要的應用程序服務器已經移動（或將要移動到）OSGi運行時（並因此給予OSGi應用程序支持）的事實證明了這一點。

Answer 2

l10i寫道：有了OSGi，情況並非如此：應用程序是由一大組的軟件包組成的，每個軟件包都有希望設計爲處理功能的單獨部分。這種方法可以實現應用程序內部的熱部署，因爲該框架旨在考慮重新啓動任何單個jar爲整個應用程序帶來的影響，並讓其他jar適當地作出反應。這提供了儘可能保留應用程序狀態的能力。

爲了詳細說明這一點，最好的OSGi應用程序是通過OSGi服務註冊表集成的面向服務的應用程序。這個服務註冊表是動態的，服務可以隨時進出，OSGi服務使用者可以對這種動態性做出適當的反應。 因此，假設您的應用程序由許多捆綁包組成，包括使用支付服務的捆綁包（例如用於處理信用卡支付）以及提供該支付服務的另一捆綁包。如果您發現自己處於支付服務需要更新的情況下（因爲您有一個關鍵的修復程序，或者您找到了更便宜的服務提供商等），您可以更新此支付服務，甚至無需停用此服務的使用者。爲此，您可以自行更新支付服務包，但是我建議在這種情況下，先安裝新版本的支付服務包以及舊版本。這是可能的，因爲OSGi允許同一個bundle的多個版本共存。然後，一旦新的捆綁軟件啓動並運行，您可以刪除舊的支付服務捆綁包，在這一點上，消費者將自動轉到使用新的支付服務捆綁包，由OSGi服務註冊中心提供。

上述示例的這種體系結構非常強大，確保您的企業應用程序保持穩定，並且可以通過使用OSGi服務與動態安裝，卸載或更新OSGi捆綁軟件的能力相結合來實現。

BTW有更詳細一點，以上面的例子包也可以寫成使用一個特定類型的所有服務 - 什麼是最適合你取決於你的情況。

有許多的方式來使用OSGi服務註冊表，你可以用ServiceTracker API，這是相當低的水平使用。在大多數情況下，最好爲此使用框架，如OSGi聲明性服務（DS），OSGi藍圖或其他框架。在大多數情況下，這些框架通過注入工作，併爲您處理OSGi Service Registry的動態性。有關DS或Blueprint的信息，請參閱OSGi 4.2 Enterprise Specification。