Blueprint OSGi仕様をご覧になることをお勧めします。この仕様は、OSGiの機能を使用して、必要と思われるように動的サービスを簡単に実装できるように設計されています。
IBMガイド(グーグルで検索すると最初に表示されます)を見るのではなく、最初にこのガイドを確認してください。これは非常に簡単です。
http://www.javabeat.net/2011/11/blueprint-and-service-dynamism-in-osgi/
ブループリントを使用すると、Springコンテキストと非常によく似たコンテキストが得られます。バンドルを開始すると、Blueprintエクステンダーがバンドルのコンテキストを自動的に作成します。
どのOSGiバンドルでもサービスを公開できます(通常は単なるPOJOです)。これは、機能を他のバンドルと共有するための標準的な方法です。共有する機能が1つ以上の一般的なAPIバンドルで宣言されていることを確認してください。これにより、APIの実際の実装は、ダウンタイムなしでいつでも動的に変更できます。
エクスポートされたサービスを宣言する単純なブループリントコンテキストは、次のようになります。
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">
<!-- Exported service declaration -->
<service interface="com.package.api.SomeServicePojo" ref="beanId" />
<bean id="beanId" class="com.package.impl.ServicePojoImpl" />
<!-- ... lots of beans here -->
</blueprint>
別のバンドルは、次のようにそのサービスをインポートする場合があります。
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">
<!-- Import service declaration -->
<reference interface="com.package.api.SomeServicePojo" id="service" />
<bean id="otherBean" class="com.package.client.ServiceUser">
<property name="service" ref="service" >
</bean>
<!-- ... lots of beans here -->
</blueprint>
ご覧のとおり、サービスはServiceUserに注入されます。ただし、実際に注入されたインスタンスはプロキシであることに注意してください。サービスの実際の実装は、実行中のOSGi環境に新しいBlueprintバンドルをインストール/開始することにより、いつでも交換できます。
エクスポート/インポートされたものを「サービス」と呼んでいますが、実際には何でもかまいません。たとえば、文字列!! したがって、たとえば、エクスポートされたファクトリを使用して、この方法でドメインモデルの実装を動的に変更できます。
ただし、 API定義バンドルを変更するには、OSGi環境を再起動する必要があります...柔軟になるようにAPIを慎重に設計した場合でも、API実装バンドルを交換するだけでAPIの一部の側面を変更できる場合があります。 API自体ではないため、再起動は必要ありません。
これは、キャッシュの問題を処理する唯一の方法でもあります...スワップする予定のバンドルとは別のバンドルにキャッシュを保持している場合は、問題なく動作するはずです...キャッシュをアンインストールしなくても状態は失われません-バンドルを保持しています...しかし、明らかに、新しくインストールしたAPI実装と互換性のないオブジェクトがキャッシュに含まれている場合、世界中のテクノロジーで違いを魔法のように処理することはできません...自分でそれを行うことができます、たぶん、しかし私の意見では、それはほとんど利益のために非常に複雑になるでしょう...古いキャッシュされたオブジェクトを使用すると壊れるかもしれない変更を行うときにキャッシュをクリアするようにプログラムするだけです!