私たちの SW アーキテクチャーにおける OSGi + Java + JNI + C/C++ の元の概念を置き換えるために、Python と C/C++ の組み合わせを考えています。
Felix や Equinox などの OSGi フレームワークのすべての機能を置き換える必要はまったくありません。
私のPythonコードで本当に必要なもの：
そのような Python フレームワークについてアドバイスをお願いできますか?
OSGi が提供するものの多くは、Java のアーキテクチャー (クラス・ローダーとタイプ・セーフ) に密接に関連していると思います。サービス レジストリの実装はそれほど難しくありませんが、OSGi の精度でそれを管理することは事実上不可能です。OSGi が提供する複数の名前空間の機能は、モジュールを別のプロセスに移動しない限り、明らかに Python では機能しません。この場合、モジュール間通信のためにより高価なプロセス間通信が必要になります。ネイティブ ベースの Apache Celix から始めることもできますが、ネイティブ コードはその依存関係に関する多くの情報を提供しないため、そのユーティリティについて同様の疑問を抱いています。
より一般的な解決策は、Universal OSGi の元のアイデアです。このモデルでは、展開と管理のために OSGi フレームワークをそのまま維持します。ただし、他の言語で記述されたバンドルをマップできるハンドラー バンドルを作成します。たとえば、Python ハンドラまたは C++ ネイティブ。ハンドラーは、ネイティブ サービス レジストリ モデルを OSGi サービス レジストリにマップします。OSGi サービス レジストリは適切にイベント化されるため、これは驚くほど簡単に実行できます。ネイティブ ハンドラは、開始/停止などのバンドル イベントをマッピングして、オペレーティング システムにネイティブ コードの開始/停止を指示します。
PeterはすでにApacheCelixについて言及しています。それをチェックする価値があるかもしれません。Celixの一部はRemoteServiceAdmin（RSA）の実装であり、分散環境での使用を可能にします。最終的に、この実装により、JavaベースのOSGiフレームワークとの通信も可能になり、Celix+RSAがJNIの代替となります。これには、ネイティブコードとJavaコードが同じプロセスを共有しないという追加の利点があります。一方の端で問題が発生した場合でも、もう一方の端は実行されたままになります。
Celixに沿って、Native-OSGiも見ることができます。これは、Celixと一部のC ++ OSGiのようなフレームワーク（CTKプラグインフレームワークとnOSGi）が、ネイティブOSGiのような実装の組み合わせアプローチを考え出すための取り組みです。これには、明確に定義されたAPI、バンドル形式、コード共有などが含まれます。
要件を見ると、CelixとNative-OSGiが適していると思います。