私はたくさんのプレゼンテーションを見ましたOSGiそして、より優れたモジュール化の実施には有望だと思います。どうやら、「ホットデプロイメント」と「異なるバージョンの x を並行して実行」も大きなセールスポイントのようです。
OSGi が解決すると約束していることが本当に問題なのだろうか...? 同じような主張がなされていた OO の初期の頃を思い出しました:
OOの場合新しいものであったため、再利用性について大きな議論がありました。OO を使用すると、「一度書く」だけで「どこでも使える」と広く主張されていました。
実際には、これが機能するのはかなり低レベルの例だけでした。その理由は、再利用可能なコードを書くのが難しいからだと思います。技術的にではなく、インターフェース設計の観点からです。将来のクライアントがクラスをどのように使用するかを予測し、事前に適切な選択を行う必要があります。これは定義上難しいため、再利用の潜在的な利点が得られないことがよくありました。
OSGiを使用ここでも、私たちは約束、つまり実際には存在しない問題に対する潜在的な解決策に騙されてしまうのではないかという疑念を抱いています。あるいは、たとえ問題があったとしても、OSGi に助けを求めるほどの量と深刻さはありません。たとえば、モジュールのサブセットの「ホットデプロイメント」は確かに素晴らしいアイデアですが、それがどのくらいの頻度で行われるのでしょうか。本当にうまくいきますか? 特定の問題に対してモジュール化を間違えたためにうまくいかないことがどのくらいありますか? 複数のモジュール間で共有されるモデル エンティティはどうですか? これらのモジュールはすべて同時に変更する必要がありますか? または、インターフェイス コントラクトを維持できるように、オブジェクトをプリミティブにフラット化し、モジュール間通信でのみそれらを使用しますか?
最も難しい問題OSGiを適用する場合、モジュール化を「正しく」行うOO でクラスのインターフェースを正しく取得するのと同様に、OSGi でも問題は同じままですが、今回はパッケージやサービス レベルというより大きな規模になります。
ご想像のとおり、私は現在、プロジェクトで使用するために OSGi を評価しようとしています。私たちが抱えている大きな問題は、コードベースの拡大に伴って複雑さが増していることです。そこで、システムを、より少ない、より明確なインタラクションを持つ小さなモジュールに分割したいと考えています。
- いかなる枠組みも決定を下す助けにはならないので何モジュール化するために、OSGi が効果を発揮したことはありますか?
- チームで作業するときに、作業が楽になりましたか?
- バグの数を減らすのに役立ちましたか?
- 主要コンポーネントを正常に「ホットデプロイ」したことがありますか?
- OSGi は時間の経過とともに複雑さを軽減するのに役立ちますか?
- OSGi は約束を守りましたか?
- 期待に応えられましたか?
ありがとう！
ベストアンサー1
OSGi は、実行時にモジュール化を強制するため、効果を発揮します。これは、以前は実現できなかったことで、紙面上の設計と実装が乖離してしまうことがよくありました。これは、開発中に大きなメリットとなります。
チームが単一のモジュール (おそらくバンドルのセット) に集中できるようにし、モジュール化を適切に行えば、チームでの作業が確実に容易になります。Ant+Ivy や Maven などのビルド ツールと依存関係を使用して同じことを実行できると主張する人もいるかもしれませんが、OSGi が使用する依存関係の粒度ははるかに優れており、JAR レベルの依存関係で発生する典型的な「あらゆるものをドラッグして取り込む」という状況は発生しません。
依存関係の少ないモジュール式コードは、コードがよりクリーンで少なくなる傾向があり、その結果、バグが少なくなり、テストや解決が容易になります。また、可能な限りシンプルでわかりやすいコンポーネントの設計を促進しながら、より複雑な実装をプラグインしたり、キャッシュなどの側面を別のコンポーネントとして追加したりするオプションも提供します。
ホット デプロイメントは、実行時に使用しない場合でも、アプリケーションが正しくモジュール化されているかどうかを検証するための非常に優れたテストです。バンドルをランダムな順序でまったく起動できない場合は、その理由を調査する必要があります。また、任意のバンドルを更新できれば、開発サイクルを大幅に短縮できます。
モジュールと依存関係を管理できる限り、大規模なプロジェクトは管理可能であり、簡単に進化させることができます (おそらく悪い「完全な書き直し」から解放されます)。
OSGi の欠点は何でしょうか? これは非常に低レベルのフレームワークであり、意図された問題をかなりうまく解決しますが、自分で解決しなければならない問題がまだあります。特に、Java EE 環境から来た場合は、スレッド セーフティや、必要に応じて非常に役立つその他の概念が無料で提供されますが、OSGi でこれらの問題に対する解決策を自分で考え出す必要があります。
よくある落とし穴は、平均的な開発者にとってこれを簡単にするために OSGi 上で抽象化を使用しないことです。開発者が ServiceListeners や ServiceTrackers を手動で操作することは絶対に許可しないでください。バンドルで何ができて何ができないかを慎重に検討してください。開発者に BundleContext へのアクセスを許可しますか、それとも何らかの宣言型モデルを使用してこれらすべてを開発者から隠しますか。