Web アプリケーションが中央支払い処理エンジンであるとします。この場合、各ユーザーは、クレジット カードを処理する異なるクレジット カード プロバイダーを持っている場合があります。
すべての実装が準拠するインターフェイスがあります。
アプリケーションを再コンパイルせずに、新しい実装を展開フォルダー (.jar ファイル) にドロップするだけで済むパターンがあるかどうかを知りたいです。ほとんどの場合、管理セクションに移動して、新しいクレジット カードの実装に関する詳細を入力する必要があります。
例: アプリケーションが現在 Authorize.net をサポートしているとします。したがって、すべてのユーザーが authorize.net を使用しています。ここで、新しい実装をコーディングして .jar ファイルをドロップし、admin に移動して、新しいクレジット カード プロバイダーを登録します。
これで、ユーザーはシステムにログインして、新しい実装を使用することを選択できます。
これは、再コンパイルすることなく実行できますか? 春のDIはこれに役立ちますか?
あなたが説明していることは、「基本的な」Spring Bean コンテナーメカニズムよりも OSGi に適しているように聞こえます。通常、アプリが起動して実行されると、Spring ApplicationContextは変更されません。対照的に、OSGi は、この種の実行時の動的動作用に設計されており、Spring と組み合わせて使用できます。Spring Dynamic Modulesのドキュメントを見て、それがどのように機能するかを理解してください。
を参照することをお勧めしますjava.util.ServiceLoader。これにより、実行時にクラスパスに動的に追加されるインターフェイス実装の「ルックアップ」を実行できます。基本的に、サービス jar には、指定されたインターフェイスを実装するクラスのリストを含む /META-INF/services/some.package.InterfaceName という名前のテキスト ファイルが含まれている必要があります。
ただし、(J2EE Web アプリケーションのように) 実行中の Web アプリケーションのクラスパスを拡張する標準化された方法はないため、サーブレット コンテナーによっては、デプロイメント ディレクトリに新しい jar を追加した後に Web アプリケーションを再起動する必要がある場合があります。
@Rob H は、あなたがやりたいことをネイティブにサポートするため、OSGi の優れたオプションを提示します。
新しいテクノロジーを導入しないもう 1 つのオプションは、支払い方法を他の Java EE アプリケーションに委譲し、中央の支払い処理エンジンから独立して開始、追加、または更新できるようにすることです。管理者は、新しい支払い方法を適切なアプリケーションに簡単にマップできます。