OSGiは何を解決しますか？
ウィキペディアや他のサイトで 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サービスレジストリは、バンドルがサービスを登録、取得、およびリッスンできる動的レジストリです。この動的なサービスモデルにより、バンドルはシステムで利用可能な機能を見つけ、提供できる機能を調整できます。これにより、変更に対するコードの柔軟性と回復力が向上します。
透明性-バンドルとサービスは、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を実行するように要求するだけで、その上にはほとんど追加されません。
Fast-OSGiフレームワークの主要な責任の1つは、バンドルからクラスをロードすることです。従来のJavaでは、JARは完全に表示され、線形リストに配置されます。クラスを検索するには、このリストを検索する必要があります（多くの場合非常に長く、150は珍しくありません）。対照的に、OSGiはバンドルを事前に配線し、各バンドルについてクラスを提供するバンドルを正確に認識します。この検索の欠如は、起動時の大幅なスピードアップ要因です。
レイジー-ソフトウェアのレイジーは優れており、OSGiテクノロジーには、本当に必要な場合にのみ物事を実行する多くのメカニズムがあります。たとえば、バンドルは積極的に開始できますが、他のバンドルがそれらを使用している場合にのみ開始するように構成することもできます。サービスは登録できますが、使用されるときにのみ作成されます。仕様は数回最適化されており、この種の怠laなシナリオに対応できるため、多大なランタイムコストを節約できます。
セキュア-Javaの下部には非常に強力なきめ細かいセキュリティモデルがありますが、実際には設定が非常に困難です。その結果、最も安全なJavaアプリケーションは、セキュリティなしまたは非常に限定された機能のバイナリ選択で実行されます。 OSGiセキュリティモデルは、きめの細かいセキュリティモデルを活用しますが、環境のオペレーターが完全に責任を負っている間に、バンドル開発者が簡単に監査できる形式で要求されたセキュリティの詳細を指定することにより、使いやすさを向上させます（元のモデルを強化します）。全体として、OSGiはおそらく、ハードウェアで保護されたコンピューティングプラットフォームを使用しない限り、最も安全なアプリケーション環境の1つを提供します。
Non Intrusive-OSGi環境のアプリケーション（バンドル）は独自のものです。 OSGiが制限することなく、VMのほぼすべての機能を使用できます。 OSGiのベストプラクティスは、Plain Old Javaオブジェクトを記述することです。そのため、OSGiサービスに必要な特別なインターフェイスはありません。Java StringオブジェクトでもOSGiサービスとして機能できます。この戦略により、アプリケーションコードを別の環境に移植しやすくなります。
どこでも実行-まあ、それは依存します。 Javaの当初の目標は、どこでも実行することでした。明らかに、Java VMの機能が異なるため、すべてのコードをすべての場所で実行することはできません。携帯電話のVMは、銀行業務アプリケーションを実行するIBMメインフレームと同じライブラリをサポートしない可能性があります。世話をする2つの問題があります。まず、OSGi APIは、すべての環境で使用できるわけではないクラスを使用しないでください。第二に、実行環境で利用できないコードが含まれている場合、バンドルは開始すべきではありません。これらの問題は両方とも、OSGi仕様で対処されています。
OSGiには次の利点があります。
- 各プラグインは、独自のクラスローダーを持つバージョン管理されたアーティファクトです。
- 各プラグインは、含まれる特定のjarと、他の特定のバージョン付きプラグインの両方に依存します。
- バージョン管理と分離されたクラスローダーにより、同じアーティファクトの異なるバージョンを同時にロードできます。アプリケーションの1つのコンポーネントがプラグインの1つのバージョンに依存しており、別のコンポーネントが別のバージョンに依存している場合、両方を同時にロードできます。
これにより、アプリケーションを、オンデマンドでロードされるバージョン付きのプラグインアーティファクトのセットとして構築できます。各プラグインはスタンドアロンコンポーネントです。 Mavenがビルドを構築し、それが作成されるアーティファクトの特定のバージョンのセットによって繰り返し定義されているように、OSGiが実行時にこれを支援します。
OSGiモジュールのホットプラグ可能性についてはあまり気にしません（少なくとも現在）。それはより強制的なモジュール性です。クラスパスで何百万もの「パブリック」クラスを使用できないことは、循環依存から十分に保護されます。パブリックインターフェイスについては、Java言語構造「パブリック」だけでなく、ライブラリ/モジュールの条件：他の人が利用できるようにするコンポーネントは（正確に）何ですか？機能を実装するために本当に必要な（他のモジュールの）インターフェイスは（正確に）何ですか？
ホットプラグが付属しているのは素晴らしいことですが、ホットプラグ機能のすべての組み合わせをテストするよりも、通常のアプリケーションを再起動したいです...
- 類推すると、車のモーターをオフにせずに変更できます。
- 顧客向けに複雑なシステムをカスタマイズできます。 Eclipseの力をご覧ください。
- コンポーネント全体を再利用できます。単なるオブジェクトよりも優れています。
- コンポーネントベースのアプリケーションを開発するには、安定したプラットフォームを使用します。これの利点は非常に大きいです。
- ブラックボックスの概念でコンポーネントを構築できます。他のコンポーネントは、非表示のインターフェイスについて知る必要はなく、公開されたインターフェイスのみを参照します。
- 同じシステムで複数の同等のコンポーネントを使用できますが、アプリケーションを危険にさらすことなく、異なるリリースで使用できます。 OSGiはJar Hell問題を解決します。
- OSGiでは、 CBD を使用してシステムを設計するための思考を開発します。
Javaを使用するすべての人が利用できる多くの利点があります（これらを今思い出しました）。
明確にするために編集。OSGiページは私のものよりも簡単な答えを出しました
簡単な答え：OSGiサービスプラットフォームは、ネットワークサービスを連携させるための標準化されたコンポーネント指向のコンピューティング環境を提供します。このアーキテクチャにより、アプリケーションの構築、保守、展開の全体的な複雑さが大幅に軽減されます。 OSGi Service Platformは、再起動を必要とせずに、さまざまなネットワークのデバイスで構成を動的に変更する機能を提供します。
単一のアプリケーション構造（Eclipse IDEなど）では、新しいプラグインをインストールするときに再起動することは大したことではありません。 OSGi実装を完全に使用すると、実行時にプラグインを追加し、新しい機能を取得できますが、Eclipseを再起動する必要はありません。
繰り返しますが、毎日の大したことではなく、小さなアプリケーションの使用です。
しかし、マルチコンピューターの分散アプリケーションフレームワークを検討し始めると、そこから興味深いものになります。重要なシステムのアップタイムを100％にする必要がある場合、実行時にコンポーネントをホットスワップしたり、新しい機能を追加したりする機能が役立ちます。確かに、現在これを行うための機能の大部分はありますが、OSGiはすべてを共通のインターフェースを持つ素敵な小さなフレームワークにバンドルしようとしています。
OSGiは一般的な問題を解決しますか、それについてはわかりません。つまり、それは可能ですが、オーバーヘッドは単純な問題にとっては価値がないかもしれません。しかし、より大規模なネットワーク化されたアプリケーションを扱うようになったとき、それは考慮すべきことです。
OSGiに夢中になるいくつかのこと：
1）implentationsとそのコンテキストローダーには多くの癖があり、多少非同期になる可能性があります（confluence内でfelixを使用します）。 [main]がほぼすべての同期を実行する純粋なスプリング（DMなし）と比較して。
2）ホットロード後のクラスは等しくありません。たとえば、hibernateにタンゴソルキャッシュレイヤーがあるとします。 OSGiスコープ外のFork.classで満たされています。新しいjarをホットロードしても、フォークは変更されていません。 Class [Fork]！= Class [Fork]。同じ根本的な原因で、シリアル化中にも表示されます。
3）クラスタリング。
これらのことを回避できますが、それは大きな大きな痛みであり、アーキテクチャに欠陥があるように見えます。
そして、ホットプラグを宣伝している方へ.. OSGiのナンバー1クライアントですか？ Eclipse。バンドルをロードした後、Eclipseは何をしますか？
再起動します。
私はまだOSGiの「ファン」ではありません...
私はフォーチュン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ギガラムと40ギガの空きギグディスクとIntel i5-3437U 1.9 GHz CPUを搭載したマシン上
このアップグレードの「利点」は、（運用）展開の改善として販売されました。これは、年に約4回、1年に2〜4回の小規模な修正展開で行われます。 15人（QAと開発者）に1日45分を追加することは、正当化されるとは想像できません。大規模なエンタープライズアプリケーションでは、アプリケーションがコアアプリケーションである場合、それを変更するのは当然です（小さな変更は広範囲に影響を与える可能性があります-企業全体の消費者と通信し、計画する必要があります）、記念碑的なアクティビティ-間違ったアーキテクチャOSGi。アプリケーションがエンタープライズアプリケーションではない場合、つまり、各コンシューマーは、独自のサイロ化されたデータベース内の独自のデータサイロにヒットし、多くのアプリケーションをホストするサーバー上で実行される可能性が高い独自の調整済みモジュールを持つことができます。少なくとも、これまでの私の経験です。
Javaベースのアプリケーションで、JVMをシャットダウンせずにモジュールの追加または削除（アプリケーションの基本機能の拡張）が必要な場合、OSGIを使用できます。通常、JVMをシャットダウンするコストが高い場合、機能を更新または強化するだけです。
例：
- Eclipse：プラグインをインストール、アンインストール、更新、相互依存するためのプラットフォームを提供します。
- AEM：WCMアプリケーション。機能の変更はビジネス主導であり、メンテナンスのためのダウンタイムを許容することはできません。
注：Springフレームワークは、OSGI Springバンドルのサポートを停止しました。これは、トランザクションベースのアプリケーションまたはこれらの行のある点では不必要な複雑さであると考えています。プラットフォームを構築するような大きなもので、絶対に必要でない限り、私は個人的にOSGIを考慮しません。
OSGiは、明白な理由なしに、コードにNoClassDefFoundErrorおよびClassNotFoundExceptionをスローさせます（おそらく、OSGi構成ファイルでパッケージをエクスポートするのを忘れたためです）。 ClassLoaderを持っているので、実際には2つの異なるクラスローダーによってロードされた2つの異なるクラスであるため、com.example.Fooをcom.example.Fooにキャストできません。 Eclipseプラグインをインストールした後、EclipseをOSGiコンソールで起動することができます。
私にとって、OSGiは複雑さを追加しただけで（grockにもう1つのメンタルモデルを追加したため）、例外のために煩わしさを追加しました。私はそれが「提供する」動的性を本当に必要としなかった。すべてのモジュールにOSGiバンドル構成が必要なため、侵入的でした。それは間違いなく簡単ではありませんでした（より大きなプロジェクト）。
私の悪い経験のために、私はそのモンスターから離れる傾向があります、どうもありがとう。 jar依存関係の地獄に苦しむのは、OSGiが導入するクラスローダー地獄よりも簡単に理解できる方法だからです。
OSGiには次の利点があります。
■Javaベースのポータブルで安全な実行環境
■サービス管理システム。バンドル間でサービスを登録および共有し、サービスプロバイダーをサービスコンシューマから切り離すために使用できます。
■動的モジュールシステム。OSGiがバンドルを呼び出すJavaモジュールを動的にインストールおよびアンインストールするために使用できます。
■軽量でスケーラブルなソリューション
他の人はすでに利点の詳細を概説しています。OSGiを見たり使用したりした実用的なユースケースをここで説明します。
- 私たちのアプリケーションの1つでは、イベントベースのフローがあり、OSGiプラットフォームに基づいたプラグインでフローが定義されているため、明日、別のクライアントが別の/追加のフローを必要とする場合、もう1つのプラグインをデプロイし、コンソールから設定するだけで完了です。
- たとえば、さまざまなストアコネクタをデプロイするために使用されます。たとえば、すでにOracle DBコネクタがあり、明日mongodbを接続する必要がある場合、新しいコネクタを作成してデプロイし、コンソールを介して詳細を構成します。コネクタの展開は、OSGiプラグインフレームワークによって処理されます。
少なくとも、OSGiを使用すると、モジュール性、コードの再利用、バージョン管理、および一般的なプロジェクトの配管について考えることができます。
その公式サイトにはすでにかなり説得力のある声明があります。
OSGiテクノロジーが非常に成功した主な理由は、驚くほど多くの環境で実際に機能する非常に成熟したコンポーネントシステムを提供することです。 OSGiコンポーネントシステムは、実際にはIDE（Eclipse）、アプリケーションサーバー（GlassFish、IBM Websphere、Oracle/BEA Weblogic、Jonas、JBoss）、アプリケーションフレームワーク（Spring、Guice）、産業オートメーション、住宅用ゲートウェイなどの非常に複雑なアプリケーションを構築するために使用されます。電話など。
開発者にとってのメリットは？
開発者：OSGiは、今日の大規模な分散システムと小型の組み込みアプリケーションにモジュラーアーキテクチャを提供することにより、複雑さを軽減します。社内および既製のモジュールからシステムを構築すると、複雑さが大幅に軽減され、開発および保守費用が大幅に削減されます。 OSGiプログラミングモデルは、コンポーネントベースのシステムの可能性を実現します。
OSGiを使用する利点 の詳細を確認してください。
私はOSGiでほぼ8年ほど作業を行ってきましたが、実行時にコンポーネントを更新、削除、インストール、または交換する必要がある場合にのみOSGiを検討する必要があると言わざるを得ません。これはまた、モジュール式の考え方を持ち、モジュール性の意味を理解する必要があることも意味します。 OSGiが軽量であるという議論がいくつかあります-はい、それは本当ですが、軽量で保守および開発が容易な他のフレームワークもいくつかあります。 Javaなんとか安全を確保する場合も同様です。
OSGiを正しく使用するには堅牢なアーキテクチャが必要であり、OSGiを使用せずにスタンドアロンで実行可能なjarに簡単に変更できるOSGiシステムを作成するのは非常に簡単です。