私たちは、次のニーズを特定した Web アプリケーション (イメージ バンクと呼びましょう) を開発しています。
- アプリケーションは、一連のユーザーで構成される顧客に対応します。
- 新しい顧客は動的に作成でき、顧客はそのユーザーを管理します
- お客様は、動的に変更できるさまざまな機能セットを持っています
- 顧客は、独自の機能を開発して展開することができます。
- アプリケーションは同種であり、現在のバージョンがありますが、顧客のバージョン リフトは個別に処理できます。
- アプリケーションは全体として管理する必要があり、顧客は拡張が容易なリソースを共有する必要があります。
質問:これを標準の OSGi フレームワークで構築する必要がありますか?それとも、新しいアプリケーション フレームワーク (Virgo、Aries、または今後の OSGi 標準) のいずれかを使用する方がよいでしょうか?
より多くの背景といくつかの最初の考え:
私たちは、すぐに数百の顧客 (企業) とそれぞれ数百のユーザー (従業員) を持つことを想定している Web アプリを構築しています。それをモジュラーにしたいので、OSGi. 将来的には、顧客自身がアプリケーションにコンポーネントを開発してプラグインする可能性があるため、顧客を分離する必要があります。また、さまざまな顧客にさまざまな機能セットを提供したい場合もあります。
異なるクライアントが同じバンドルを共有している場合、アプリケーションの異なるクライアントに異なるサービス実装を提供する「正しい」方法は何ですか?
アプリ サーバー アプローチ (Virgo を調べました) を使用して、顧客ごとに 1 回ずつ各バンドルを独自の「アプリ」にロードすることができます。しかし、OSGi を採用しているような気がしません。多数のアプリケーションをホストしているわけではなく、サービスの 99% が同じ実装を共有します。すべてのお客様に。また、アプリケーションを 1 つとして管理 (構成、監視など) したいと考えています。
各サービスは、「顧客トークン」プロパティとともに顧客ごとに 1 回登録 (適切に構成) できます。少し面倒なので、エクステンダー パターンまたは ManagedServiceFactory で処理する必要がありますか? また、顧客 A のサービスを登録する前に、それぞれの依存関係の A バージョンを取得する必要があります。
「現在の」顧客は各リクエストで認識され、スレッドにバインドできます。サービスを検索するたびに顧客トークンを提供しなければならないのは少し面倒です。ブループリントのようなコンポーネント フレームワークを使用するのが難しくなります。この問題を回避するには、サービス フックを使用して、登録されている各サービス タイプをプロキシし、プロキシが現在の顧客 (スレッド) に従って適切なインスタンスにディスパッチできるようにします。
上記の回避策 (ハック?) を実装して OSGi エクスペリエンス全体を開始することは、間違った道を進んでいることを示しているように感じます。だから何をすべきか？乙女座に戻る？上で概説したものに似たものを試してみませんか？なんか全然違う？！
ps。ここまで読んでくれてありがとう！;)