この質問は、OSGI と開発ロードマップに精通している方に向けたものです。私は Eclipse/Equinox で育ちましたが、拡張可能なソフトウェアを構築する際に拡張ポイント フレームワークが非常に貴重であることを発見しました。これは、拡張ポイントを Java コードから消費できるようにするスキーマの構築を通じて豊富な xml メタデータを作成できるためです。設計時の xml 検証を含む plugin.xml。これを、拡張ポイントを定義および使用するための PDE Eclipse ツールと組み合わせることは、Equinox の私のお気に入りの機能の 1 つです。
ECore パッケージを使用して Equinox サーバー側スキーマを拡張して hibernate スキーマにマップすることから、web.xml 拡張ポイントをモデル化してモジュラー Web アプリケーション開発を可能にすることまで、考えられるほぼすべてのコンテキストで拡張ポイントを使用したと思います。各プラグインには、拡張機能に基づいて生成される単一の web.xml ファイルに貢献する機能があります。私は、JSF 構成ファイルを単一の拡張ポイントに同様の方法で移植して、プラグインがマネージド Bean を提供できるようにすることを楽しんできました。モジュラー Web アプリケーション開発の世界では、拡張ポイントは醜い戦争を分離するという課題に対する優れたソリューションだと思います。代替フレームワークに加えて Eclipse の UI を見ると、拡張ポイントのない生活を想像するのは難しいですが、私は'
私の最大の不満は、サービス インターフェイスで定義されたメソッド呼び出しの xml 表現を定義するために xml スキーマを使用する "service-points" (より適切な言葉がないため) などを作成するためのオプションの xml ベースのリッチ メタデータ レイヤーがないことです。 「service-extensions」のようなもので OSGI サービスをコードではなく xml で使用できるようにすることで、開発がより柔軟になり、保守が容易になります。
それが OSGI サービスに高レベルのメタデータ レイヤーを提供するための最良のアプローチであるかどうかはわかりませんが、OSGI サービス コントラクトを Java インターフェースよりもスマートにサービス消費の xml パラダイムにすることの利点を示しているため、良い例です。サービスバインディングだけではありません。上記のように、サービスを注入したり、サービス参照を取得したり、Java コードでメソッドを呼び出して HttpService に http コンテキストを登録するなどの単純なことを行うボイラー プレート コードは、すべて xml で実行できます。さらに一歩進んで、純粋な OSGI サービスを使用して複雑な拡張可能な UI フレームワークをリッチ クライアント アプリケーション (今日の Eclipse の拡張ポイントなど) または Web アプリケーション フレームワークで構築することが、簡単ではないにしても可能になります。一意の ID、URL マッピング、およびコントローラーを使用して拡張可能な Web アプリケーションの標準コンテナーを定義し、同じフレームワークで他のサービスポイントを使用して、他のバンドルがメニュー タブなどをメイン メニューに相対的なインデックス順序とリンクで追加できるようにします。バンドルにある jsp ページへの参照。Web.xml は http サービスのサービス ポイントになり、バンドルが web.xml の「service-point」の「service-extensions」を介してサーブレット マッピングまたはフィルタを提供できるようになります。
拡張ポイント フレームワークを OSGI に移植することを提案しているわけではありませんが、サービスがサービス インターフェイスに含まれるメソッド呼び出しを「サービス ポイント」として公開できるように、宣言型 OSGI サービス用の xml ベースのメタデータ レイヤーを持つという同じ精神に従っています。これは、他の宣言型サービスまたはバンドルが「サービス拡張」を通じて使用できる xml スキーマとして定義されます。Eclipse 拡張ポイントについて私が気に入っているのは、拡張機能を簡単に追加できることです。バンドル クラスパスに基づいて利用可能な拡張ポイントの適切なダイアログが表示され、PDE ツールを使用すると、ターゲット拡張機能のスキーマに基づいて拡張 UI が動的にレンダリングされます。点。この xml メタデータ レイヤーにより、バンドル開発者は OSGI サービス メソッドを「サービス ポイント」として公開できます。OSGI サービスについても同じパターンに従うことができます。たとえば、MANIFEST エディターには「サービス拡張」というタブがあり、「追加」をクリックすると、バンドル クラスパスに基づいて利用可能なすべてのサービス ポイントのダイアログが表示されます。新しい「サービス拡張」を作成するための UI は、「サービス ポイント」に関連付けられたスキーマを中心に構築されます。これは、バンドルのアクティブ化中に、サービス ポイントによって定義されたメソッド呼び出しに変換されます。「サービスポイント」に関連付けられたスキーマを中心に構築されます。これは、バンドルのアクティブ化中に、サービス ポイントによって定義されたメソッド呼び出しに変換されます。「サービスポイント」に関連付けられたスキーマを中心に構築されます。これは、バンドルのアクティブ化中に、サービス ポイントによって定義されたメソッド呼び出しに変換されます。
これが私がOSGIサービスをどのように使用したいかです! UI コントリビューションやプロジェクト ネイチャー ビルダー、リソース リスナー、エディター コントリビューションなど、Eclipse で見られるすべての優れた UI フレームワークは、OSGI サービスと、サービス メソッド呼び出しをラッピングするための豊富な xml メタデータ レイヤーを使用して、同様の方法で構築および拡張できます。 「サービスポイント」と「サービス拡張」としての実際の呼び出しに。というわけで、今日の OSGI でこの機能を提供するものを見せてほしいという切実な要求があります。何も知らない場合、Eclipse 拡張ポイントの優れた点を採用し、OSGI Declarative Service モデルに似たものを構築して、プレーンな OSGI でより簡単で優れた拡張性を享受できるようにするこのアプローチに賛成または反対する理由は何ですか! - ダンカン・クレブス