服務模型vs Extender模型？

Question

我剛完成徹底檢查Apache Felix Application Demonstration形狀。文章狀態：

當創建一個基於OSGi的應用主要有兩個正交 問題需要考慮：

1. 服務模式與擴展模式
2. 捆綁的應用程序和託管框架

第一個問題實際上是創建基於OSGi的 應用程序時的一個普遍問題。當創建可擴展的OSGi應用程序時，可以使用兩種通用方法。服務模型方法 使用OSGi服務概念和服務註冊表作爲 可擴展性機制。擴展模型方法使用OSGi 已安裝的捆綁集作爲可擴展性機制。兩種方法 都有它們的優點和缺點，並且它們可以獨立地或一起使用 。

我認爲這是一個普遍接受的最佳實踐，關於第二點，更喜歡捆綁的應用程序，除非有一個真正的理由，您被迫使用託管框架。

關於第一點，在研究了服務模型和擴展模型之後，我理解了它們之間的區別，但我仍然試圖找出不同模型的優缺點。

每個模型（Service vs Extender）的優點和缺點是什麼？確定使用哪一個或什麼時候使用兩者的最佳實踐有哪些？

Answer 1

服務更常用，它們通常應該是您的首選，除非您有充足的理由設計新的擴展器。

OSGi是一個面向服務的平臺。服務API形成雙方（消費者和提供者）之間的合同。合同是根據包含接口的Java包定義的，提供者通過實現這些接口來提供它。消費者使用服務註冊表來查找想要使用的接口的實例。

擴展模式有點更靈活和抽象，但更難以理解和使用。本質上，擴展器軟件包代表代表提供了其他一些軟件包，它們通常通過包含某種聲明來加入。

例如，假設您想爲您的應用程序實現幫助系統。軟件包可以簡單地包含一些商定路徑下的HTML文檔，中央幫助系統軟件包可以掃描軟件包以查找這些文檔並將它們添加到主幫助索引。用服務做這件事將會非常麻煩：假設你遵循「白板」風格，你將不得不用getHelpDocuments()方法定義一個HelpProvider Java接口;希望提供幫助的每個包都必須實現此接口並將其註冊爲服務。另一方面，幫助系統擴展器包必須相對聰明，因爲它必須跟蹤來來往往的包。但至少你只需要編寫一次這個智能代碼。是

擴展的現實生活中的例子如下：

• 聲明式服務是一個擴展，看起來在其他包的Service-Component聲明，並做各種東西代表他們 - 實例化的組件，出版服務等
• 藍圖是一種類似的擴展器。它尋找Bundle-Blueprint聲明，或在約定的路徑下的XML文件。
• OSGi企業規範定義了一個JPA擴展器，該擴展器查找包含由Meta-Persistence標頭聲明的persistence.xml文件的包。當它找到一個時，它爲該捆綁創建一個持久單元。
• Eclipse包含用於創建諸如視圖，透視圖，菜單等的擴展器（令人困惑地稱爲擴展註冊表）。這些都是在包的根目錄中的plugin.xml文件中聲明的。

總結...服務用於基於合同註冊和查找對象。擴展器用於擴展bundle的功能，通常基於某種聲明性資源或頭部而不是可執行代碼。

Answer 2

擴展模型主要用於框架。它需要深入研究捆綁impl來完成它的工作。所以它不適合鬆散耦合。其優點是它可以定義一個全新的抽象，如藍圖或聲明式服務或cdi。所有這些框架都使用擴展模型來根據規範來連接你的bundle。

服務模型對您的應用程序本身來說是正確的。服務允許隱藏實現的細節以及來自服務用戶的實例化。所以這對鬆耦合非常有用。

最後，兩者通常一起使用。例如，您可以使用cdi註釋來在您的套件內進行連接，並指定您提供並使用服務。因此，當您使用服務模型鬆散地連接您的包時，cdi框架利用擴展器在內部連線您的包。