ウィキペディアやOSGiに関する他のサイトを読んだことがありますが、全体像がよくわかりません。それはコンポーネントベースのプラットフォームであり、実行時にモジュールをリロードできると言っています。また、どこにでもある「実用的な例」は、Eclipseプラグインフレームワークです。
私の質問は：
OSGiの明確でシンプルな定義は何ですか？
それはどのような一般的な問題を解決しますか？
「一般的な問題」とは、「OSGiが仕事をより効率的/楽しく/簡単にするためにOSGiで何ができるか」のような、私たちが毎日直面する問題を意味します。
回答:
複雑さの軽減 -OSGiテクノロジーで開発することは、バンドル、つまりOSGiコンポーネントを開発することを意味します。バンドルはモジュールです。内部を他のバンドルから隠し、明確に定義されたサービスを通じて通信します。内部を非表示にすると、後で変更する自由が増します。これにより、バグの数が減るだけでなく、適切なサイズのバンドルが明確に定義されたインターフェースを通じて機能の一部を実装するため、バンドルの開発がより簡単になります。OSGiテクノロジーが開発プロセスのために何をしたかを説明する興味深いブログがあります。
再利用 -OSGiコンポーネントモデルにより、アプリケーションで多くのサードパーティコンポーネントを非常に簡単に使用できます。OSGiに対応したJARを提供するオープンソースプロジェクトが増えています。ただし、商用ライブラリも既製のバンドルとして利用できるようになっています。
現実の世界 -OSGiフレームワークは動的です。それはその場でバンドルを更新することができ、サービスは行き来することができます。従来のJavaに慣れていた開発者は、これを非常に問題のある機能と見なしており、その利点を理解できていません。ただし、実世界は非常に動的であり、動的なサービスが出入りできるため、サービスは多くの実世界のシナリオに完全に適合しています。たとえば、サービスはネットワーク内のデバイスをモデル化できます。デバイスが検出されると、サービスが登録されます。デバイスがなくなると、サービスは登録解除されます。この動的なサービスモデルに一致する、実世界のシナリオには驚くべき数があります。したがって、アプリケーションは、独自のドメインでサービスレジストリの強力なプリミティブ（表現力豊かなフィルター言語で登録、取得、一覧表示、サービスの表示と非表示を待機）を再利用できます。これにより、コードの記述が節約されるだけでなく、グローバルな可視性、デバッグツール、および専用のソリューションに実装されるよりも多くの機能が提供されます。このような動的な環境でコードを書くことは悪夢のように聞こえますが、幸いなことに、すべてではないにしてもほとんどの苦痛を取り除くサポートクラスとフレームワークがあります。
簡単な導入 -OSGiテクノロジーは、コンポーネントの単なる標準ではありません。また、コンポーネントのインストール方法と管理方法も指定します。このAPIは、管理エージェントを提供するために多くのバンドルで使用されています。この管理エージェントは、コマンドシェル、TR-69管理プロトコルドライバー、OMA DMプロトコルドライバー、AmazonのEC2用のクラウドコンピューティングインターフェース、またはIBM Tivoli管理システムと同じくらい簡単です。標準化された管理APIにより、OSGiテクノロジーを既存および将来のシステムに非常に簡単に統合できます。
動的更新 -OSGiコンポーネントモデルは動的モデルです。バンドルは、システム全体を停止することなく、インストール、開始、停止、更新、およびアンインストールできます。多くのJava開発者は、これが確実に実行できるとは考えていないため、最初は本番環境で使用しません。ただし、これを開発でしばらく使用した後、ほとんどが実際に機能し、展開時間を大幅に短縮することに気づき始めます。
適応性 -OSGiコンポーネントモデルは、コンポーネントの混合とマッチングを可能にするためにゼロから設計されています。これには、コンポーネントの依存関係を指定する必要があり、オプションの依存関係が常に利用できるとは限らない環境にコンポーネントが存在する必要があります。OSGiサービス・レジストリーは、バンドルがサービスを登録、取得、およびlistenできる動的レジストリーです。この動的サービスモデルにより、バンドルはシステムで使用可能な機能を見つけ、提供できる機能を適応させることができます。これにより、コードは変更に対してより柔軟で回復力があります。
透明性-バンドルとサービスは、OSGi環境の第一級市民です。管理APIは、バンドルの内部状態へのアクセスと、他のバンドルへの接続方法を提供します。たとえば、ほとんどのフレームワークには、この内部状態を示すコマンドシェルが用意されています。アプリケーションの一部を停止して特定の問題をデバッグしたり、診断バンドルを組み込んだりできます。数百万行のログ出力や長い再起動時間を監視する代わりに、ライブコマンドシェルを使用してOSGiアプリケーションをデバッグできます。
バージョニング -OSGiテクノロジーはJARの地獄を解決します。JAR地獄は、ライブラリAがライブラリB; version = 2で動作するが、ライブラリCはB; version = 3でしか動作しないという問題です。標準のJavaでは、運が悪い。OSGi環境では、すべてのバンドルが慎重にバージョン管理され、共同作業が可能なバンドルのみが同じクラススペースで一緒に配線されます。これにより、バンドルAとCの両方が独自のライブラリで機能するようになります。このバージョン管理の問題を抱えたシステムを設計することはお勧めしませんが、場合によってはそれが救命につながる可能性があります。
シンプル -OSGi APIは驚くほどシンプルです。コアAPIは1つのパッケージであり、30未満のクラス/インターフェイスです。このコアAPIは、バンドルの作成、インストール、開始、停止、更新、アンインストールに十分であり、すべてのリスナーとセキュリティクラスを含みます。ほんの少しのAPIに多くの機能を提供するAPIはほとんどありません。
小 -OSGiリリース4フレームワークは、約300KBのJARファイルに実装できます。これは、OSGiを組み込むことによってアプリケーションに追加される機能の量に対する小さなオーバーヘッドです。したがって、OSGiは、非常に小さいデバイスから小さいデバイス、メインフレームまで、幅広いデバイスで動作します。実行する最小限のJava VMを要求するだけで、その上にほとんど追加されません。
高速 -OSGiフレームワークの主な責任の1つは、バンドルからクラスをロードすることです。従来のJavaでは、JARは完全に表示され、線形リストに配置されます。クラスを検索するには、このリスト（多くの場合非常に長く、150も珍しくありません）を検索する必要があります。対照的に、OSGiはバンドルを事前に配線し、各バンドルについて、どのバンドルがクラスを提供するかを正確に把握しています。この検索の欠如は、起動時の大幅なスピードアップ要因です。
レイジー-ソフトウェアのレイジーは優れており、OSGiテクノロジーには、本当に必要な場合にのみ物事を行うための多くのメカニズムがあります。たとえば、バンドルは熱心に開始できますが、他のバンドルがそれらを使用しているときにのみ開始するように構成することもできます。サービスは登録できますが、使用時にのみ作成されます。仕様は何度も最適化されており、この種の遅延シナリオを可能にすることで、多大な実行時コストを節約できます。
セキュア -Javaの下部には非常に強力なきめ細かいセキュリティモデルがありますが、実際に構成するのは非常に困難です。その結果、ほとんどの安全なJavaアプリケーションは、バイナリの選択で実行されます。セキュリティがないか、機能が非常に制限されています。OSGiセキュリティモデルは、きめの細かいセキュリティモデルを活用しますが、バンドルの開発者が要求されたセキュリティの詳細を簡単に監査できる形式で指定し、環境のオペレーターが完全に責任を負うことで、使いやすさを向上させます（元のモデルを強化します）。全体として、OSGiは、ハードウェアで保護されたコンピューティングプラットフォームが不足してもまだ使用可能な最も安全なアプリケーション環境の1つを提供する可能性があります。
非侵入型-OSGi環境のアプリケーション（バンドル）は、そのままにしてください。OSGiが制限することなく、仮想マシンのほぼすべての機能を使用できます。OSGiのベストプラクティスは、Plain Old Java Objectを作成することです。このため、OSGiサービスに特別なインターフェイスは必要ありません。JavaStringオブジェクトでもOSGiサービスとして機能できます。この戦略により、アプリケーションコードを別の環境に簡単に移植できます。
どこでも実行-まあ、それは異なります。Javaの本来の目的は、どこでも実行できるようにすることでした。明らかに、Java VMの機能は異なるため、すべてのコードをどこでも実行することはできません。携帯電話のVMは、銀行アプリケーションを実行するIBMメインフレームと同じライブラリをサポートしない可能性があります。注意すべき問題が2つあります。まず、OSGi APIは、すべての環境で利用できるわけではないクラスを使用するべきではありません。第2に、実行環境で使用できないコードが含まれているバンドルは開始しないでください。これらの問題はどちらもOSGi仕様で対処されています。
OSGiには次の利点があります。
これにより、オンデマンドで読み込まれるバージョン管理されたプラグインアーティファクトのセットとしてアプリケーションを構築できます。各プラグインはスタンドアロンコンポーネントです。Mavenがビルドを構造化して、再現性があり、作成したアーティファクトの特定のバージョンのセットによって定義できるように、OSGiは実行時にこれを行うのに役立ちます。
OSGiモジュールのホットプラグ機能についてはあまり気にしていません（少なくとも現在のところ）。それはより強制されたモジュール性です。何百万もの「パブリック」クラスをクラスパスで利用できないようにしておくと、循環依存から十分に保護されます。Java言語構成体「パブリック」だけでなく、ライブラリの観点からも、パブリックインターフェイスについて十分に考える必要があります。 /モジュール：他の人が利用できるようにしたいコンポーネントは（正確に）何ですか？機能を実装するために本当に必要な（他のモジュールの）インターフェースは（正確に）何ですか？
ホットプラグが付属しているのは素晴らしいことですが、ホットプラグ機能のすべての組み合わせをテストするのではなく、通常のアプリケーションを再起動したいのですが...
Javaを使用するすべての人が利用できる多くの利点があります（私はこれらを今思い出しました）。
明確にするために編集。OSGiページは私のものより良い単純な答えを与えました
簡単な答え：OSGiサービスプラットフォームは、ネットワークサービスを連携させるための標準化されたコンポーネント指向のコンピューティング環境を提供します。このアーキテクチャにより、アプリケーションの構築、保守、および展開の全体的な複雑さが大幅に軽減されます。OSGiサービスプラットフォームは、再起動を必要とせずに、さまざまなネットワークのデバイスで動的に構成を変更する機能を提供します。
単一のアプリケーション構造、たとえばEclipse IDEでは、新しいプラグインをインストールしたときに再起動することは大した問題ではありません。OSGi実装を完全に使用すると、実行時にプラグインを追加し、新しい機能を取得できますが、Eclipseを再起動する必要はありません。
繰り返しになりますが、毎日の大したことではなく、小さなアプリケーションの使用です。
しかし、マルチコンピュータの分散型アプリケーションフレームワークを見始めると、そこから面白くなります。重要なシステムの稼働時間を100％にする必要がある場合、コンポーネントをホットスワップしたり、実行時に新しい機能を追加したりする機能が役立ちます。確かに、これを実行するための機能はほとんどありますが、OSGiはすべてを共通のインターフェースを持つ素敵な小さなフレームワークにバンドルしようとしています。
OSGiは一般的な問題を解決しますか、それについてはよくわかりません。つまり、それは可能ですが、単純な問題ではオーバーヘッドは価値がないかもしれません。しかし、より大規模でネットワーク化されたアプリケーションを扱う場合は、検討する必要があります。
OSGiに夢中になるいくつかのこと：
1）インプリメンテーションとそのコンテキストローダーには多くの癖があり、多少非同期になる可能性があります（合流の内部ではfelixを使用します）。純粋なスプリング（DMなし）と比較すると、[メイン]はすべての同期をほぼ実行しています。
2）ホットロード後のクラスは等しくありません。たとえば、休止状態にtangosolキャッシュレイヤーがあるとします。OSGiスコープ外のFork.classで埋められます。新しいjarをホットロードし、フォークは変更されていません。Class [フォーク]！= Class [フォーク]。同じ根本的な原因により、シリアル化中にも表示されます。
3）クラスタリング。
これらの問題を回避することはできますが、これは大きな大きな問題であり、アーキテクチャに欠陥があるように見えます。
そして、ホットプラグを宣伝しているあなたに.. OSGiの＃1クライアント？日食。バンドルをロードした後、Eclipseは何をしますか？
再起動します。
OSGiはコードをスローNoClassDefFoundErrorしますClassNotFoundExceptionが、明確な理由はありません（おそらく、OSGi構成ファイルでパッケージをエクスポートするのを忘れたためです）。ClassLoadersがあるため、実際には2つの異なるクラスローダーによって読み込まれた2つの異なるクラスであるため、クラスのcom.example.Fooキャストに失敗する可能性がありますcom.example.Foo。Eclipseプラグインをインストールした後、EclipseをOSGiコンソールで起動できます。
私にとって、OSGiは複雑さを追加するだけでした（私が理解するためのメンタルモデルが1つ追加されたため）、例外のために煩わしさを追加しました。それが「提供する」ダイナミクスを本当に必要としていませんでした。すべてのモジュールにOSGiバンドル構成が必要なため、煩わしいものでした。それは間違いなく単純ではありませんでした（より大きなプロジェクトでは）。
私の悪い経験のために、私はそのモンスターから離れる傾向があります、ありがとうございました。OSGiがクラスローダーの地獄に導入するよりもずっと簡単に理解できるので、私はむしろjarの依存関係の地獄に苦しんでいます。
私はまだOSGiの「ファン」にはなっていません...
私はFortune 100企業でエンタープライズアプリケーションを使用しています。最近、私たちが使用する製品は、OSGi実装に「アップグレード」されました。
ローカルCBAデプロイメントを開始しています... [2/18/14 8：47：23：727 EST] 00000347 CheckForOasis
最終的にデプロイされ、「次のバンドルが静止してから再起動されます」[2/18/14 9：38：33：108 EST] 00000143 AriesApplicat I CWSAI0054I：アプリケーションの更新操作の一部として
51分...コードが変更されるたびに...以前のバージョン（OSGi以外）は、古い開発マシンに5分未満でデプロイされました。
16ギガRAMと40ギガディスク、Intel i5-3437U 1.9 GHz CPUを搭載したマシン
このアップグレードの "メリット"は、改善（運用）展開として販売されました。これは、年に約4回、1年に2〜4個の小さな修正を展開するアクティビティです。15人（QAと開発者）に1日あたり45分を追加します。正当化されるとは想像できません。大規模なエンタープライズアプリケーションでは、アプリケーションがコアアプリケーションである場合、それを変更するのは当然です（小さな変更は広範囲に影響を与える可能性があります。企業全体の消費者と通信して計画する必要があります）。 OSGi。アプリケーションがエンタープライズアプリケーションではない場合、つまり各コンシューマーは、独自のサイロ化されたデータベース内の独自のデータのサイロにアクセスし、多くのアプリケーションをホストするサーバーで実行している可能性のある独自の調整済みモジュールを持つことができます。少なくとも、
Javaベースのアプリケーションで、JVMをシャットダウンせずにモジュールの追加または削除（アプリケーションの基本機能の拡張）が必要な場合は、OSGIを使用できます。通常、JVMのシャットダウンにかかるコストがさらに大きい場合は、機能を更新または拡張するだけです。
例：
注：SpringフレームワークはOSGI Springバンドルのサポートを停止しました。これは、トランザクションベースのアプリケーションまたはこれらの行のあるポイントのための不必要な複雑さと見なされました。私は個人的には、OSGIを絶対に必要な場合を除いて、プラットフォームを構築するような大きなものでは考慮しません。
私はOSGiで約8年ほど作業しており、ランタイムでコンポーネントを更新、削除、インストール、または置換するビジネス上の必要がある場合にのみ、OSGiを検討する必要があると言わなければなりません。これは、モジュール式の考え方を持ち、モジュール性の意味を理解する必要があることも意味します。OSGiは軽量であるといういくつかの議論があります-はい、そうですが、軽量で保守や開発が容易なフレームワークもいくつかあります。同じことは、java blah blahを保護するためにも当てはまります。
OSGiを正しく使用するには堅牢なアーキテクチャが必要です。OSGiシステムを簡単にスタンドアロンで実行できるjarにすることも、OSGiを使用しなくても簡単です。
また、モバイル側でミドルウェアやアプリケーションの移植性を高めるためにも使用されています。モバイル側は、WinMo、Symbian、Androidなどで利用できます。デバイス機能との統合が発生するとすぐに、断片化する可能性があります。
少なくとも、OSGiを使用すると、モジュール性、コードの再利用、バージョン管理、および一般にプロジェクトの配管について考えることができます。
他の人はすでに利点の詳細を概説しています。これにより、OSGiを見たり使用したりした実際的なユースケースについて説明します。
公式サイトにはすでにかなり説得力のある声明があります。
OSGiテクノロジーが非常に成功している主な理由は、驚くほど多くの環境で実際に機能する非常に成熟したコンポーネントシステムを提供することです。OSGiコンポーネントシステムは、IDE（Eclipse）、アプリケーションサーバー（GlassFish、IBM Websphere、Oracle / BEA Weblogic、Jonas、JBoss）、アプリケーションフレームワーク（Spring、Guice）、産業オートメーション、住宅用ゲートウェイなどの非常に複雑なアプリケーションの構築に実際に使用されます。電話、およびはるかに。
開発者にとってのメリットは？
開発者：OSGiは、今日の大規模分散システムや小規模な組み込みアプリケーションにモジュール式アーキテクチャを提供することで、複雑さを軽減します。社内および既製のモジュールからシステムを構築すると、複雑さが大幅に削減され、開発および保守の費用が大幅に削減されます。OSGiプログラミングモデルは、コンポーネントベースのシステムの期待を実現します。