27

私はOSGiに関するプレゼンテーションをたくさん見ましたが、 OSGiはより良いモジュール化を実現する上で有望だと思います。どうやら「ホットデプロイメント」と「異なるバージョンの x を並行して実行する」ことも市長のセールス ポイントです。

OSGi が解決すると約束していることは問題でさえあるのだろうか...? 同様の主張がメイドだったOOの初期を思い出しました：

オブジェクト指向が新しいとき、大きな論点は再利用性でした。オブジェクト指向を使用する場合、「一度書く」だけで「どこでも使用できる」と広く主張されていました。

実際には、これはかなり低レベルの例でしか機能していませんでした。その理由は、再利用可能なコードを書くのが難しいからだと思います。技術的にではなく、インターフェース設計の観点から。将来のクライアントがクラスをどのように使用したいかを予測し、正しい選択を前もって行う必要があります。これは定義上困難であり、潜在的な再利用性の利点を提供できないことがよくありました。

OSGiを使用すると、ここでも、私たちが実際には持っていない問題の潜在的な解決策である約束に陥る可能性があるのではないかと私は疑っています。あるいは、もしそれらを持っていたとしても、OSGi に助けを求めることを正当化するのに十分な量と重大度でそれらを持っていません。たとえば、モジュールのサブセットの「ホットデプロイメント」は間違いなく素晴らしいアイデアですが、実際にどのくらいの頻度で機能しますか? 特定の問題のモジュール化が間違っていたことが判明したためではないことがどれくらいありますか? 複数のモジュール間で共有されるモデル エンティティはどうですか? これらのモジュールはすべて同時に変更する必要がありますか? それとも、インターフェイス コントラクトを維持できるようにするために、オブジェクトをプリミティブにフラット化し、モジュール間通信でのみ使用しますか?

OSGi を適用する際の最も難しい問題は、モジュール化を「正しく」行うことだと思います。OO でクラスのインターフェイスを正しく設定するのと同様に、OSGi を使用しても問題は同じままです。今回はより大きなスケールで、パッケージまたはサービス レベルでさえもです。

ご想像のとおり、私は現在、プロジェクトで使用する OSGi を評価しようとしています。私たちが抱えている主な問題は、コードベースが大きくなるにつれて複雑さが増していることです。私は、システムをより小さなモジュールに分割して、相互作用がますます定義されないようにしたいと考えています。

  • 何をモジュール化するかを決定するのに役立つフレームワークがないことを考えると、OSGi はあなたにとって報われたことがありますか?
  • チームで作業することで、生活が楽になりましたか?
  • バグの数を減らすのに役立ちましたか?
  • 主要コンポーネントの「ホットデプロイ」に成功したことがありますか?
  • OSGi は時間の経過とともに複雑さを軽減するのに役立ちますか?
  • OSGi はその約束を守りましたか?
  • それはあなたの期待に応えましたか？

ありがとう！

4

6 に答える 6

21

OSGiは、実行時にモジュール化を実施するため、これまではなかったものであり、紙の設計と実装がばらばらになることがよくあるため、成果を上げています。これは、開発中に大きな勝利になる可能性があります。

チームが単一のモジュール（場合によってはバンドルのセット）に集中できるようにし、モジュール化を正しく行うと、チームでの作業が容易になることは間違いありません。Ant + IvyやMavenのようなビルドツールと依存関係で同じことができると主張する人もいるかもしれませんが、OSGiが使用する依存関係の粒度ははるかに優れており、典型的な「すべてと台所の流し台を引きずる」ことはありません。そのJARレベルの依存関係が原因です。

依存関係が少ないモジュラーコードは、よりクリーンでコードが少なくなる傾向があり、その結果、テストと解決が容易なバグが少なくなります。また、コンポーネントの設計を可能な限りシンプルでわかりやすくすると同時に、より複雑な実装をプラグインしたり、キャッシュなどの側面を個別のコンポーネントとして追加したりすることもできます。

ホットデプロイメントは、実行時に使用しない場合でも、アプリケーションを正しくモジュール化したかどうかを検証するための非常に優れたテストです。バンドルをランダムな順序で開始できない場合は、その理由を調査する必要があります。また、任意のバンドルを更新できれば、開発サイクルを大幅に短縮できます。

モジュールと依存関係を管理できる限り、大きなプロジェクトは管理しやすく、簡単に進化させることができます（間違いなく悪い「完全な書き換え」からあなたを救います）。

OSGiの欠点は？これは非常に低レベルのフレームワークであり、意図された問題を非常にうまく解決しますが、それでも自分で解決する必要があることがあります。特に、Java EE環境から来た場合、無料のスレッドセーフや、必要に応じて非常に役立つその他の概念を入手できる場合は、OSGiでこれらの解決策を自分で考え出す必要があります。

よくある落とし穴は、OSGiの上に抽象化を使用しないことで、平均的な開発者がこれを簡単に行えるようにすることです。ServiceListenersやServiceTrackersを手動で混乱させないでください。バンドルとは何か、許可されていないことを慎重に検討してください。開発者にBundleContextへのアクセスを許可しますか、それとも何らかの形式の宣言型モデルを使用してこれらすべてを非表示にしますか。

于 2010-02-15T21:21:56.693 に答える
9

私はここ数年、OSGi を使用してきました (ただし、Web プロジェクトではなく、Eclipse プロジェクトのコンテキストで)。フレームワークがモジュール化の方法を考えることから解放されないことは明らかです。ただし、ルールを定義することはできます。

パッケージを使用し、特定のパッケージが他のパッケージのクラスにアクセスできないことを (設計ドキュメントで? 口頭で?) 定義すると、この制約を強制せずに、それが壊れます。新しい開発者を雇うと、彼らはルールを知りません。彼らはルールを破ります。OSGi を使用すると、ルールをコードで定義できます。システムのアーキテクチャを維持するのに役立ったので、これは私たちにとって大きな勝利でした。

OSGi は複雑さを軽減しません。しかし、それは間違いなくそれを処理するのに役立ちます.

于 2010-01-29T12:14:55.377 に答える
5

私は OSGI を 8 年以上使用していますが、OSGI 以外のプロジェクトに飛び込むたびに、シートベルトを着用していない状態でスピードを出しすぎていると感じます。OSGI を使用すると、プロジェクトのセットアップと展開が難しくなり、事前にモジュール化について考える必要がありますが、実行時にルールを適用することは容易になります。例として、maven apache camel を取り上げます。新しい Maven プロジェクトを作成し、依存関係として apache camel を追加すると、アプリケーションはすべての依存関係を持っているように見え、実行時に ClassNotFoundExceptions だけに気付くでしょう。これは悪いことです。OSGI コンテナーで実行して apache camel モジュールをロードすると、依存関係が満たされていないモジュールは開始されず、問題が何であるかが事前にわかります。

また、常にホット デプロイメントを使用しており、アプリケーションの一部をオンザフライで再起動せずに更新しています。

于 2010-02-09T10:24:46.767 に答える
4

私は 1 つのプロジェクトで OSGI を使用しました (認めますが、それほどではありません)。それは良い約束を提供しますが、@Arneが言ったように、モジュール化する方法については自分で考える必要があります.

OSGIはアーキテクチャをより安定させたので、私たちのプロジェクトを助けてくれました。モジュール化を破ることはより「困難」であるため、モジュール化の方法に関して下した決定は、より長い間有効であり続けました。
別の言い方をすれば、OSGI がなく、配信に時間のプレッシャーがある場合、あなたやあなたのチーム メンバーが妥協、近道、その他のハッキングを行い、アーキテクチャの本来の意図が失われることがあります。

したがって、OSGI は複雑さ自体を軽減しませんでしたが、時間の経過とともに複雑さが不必要に増大するのを防ぎました。それは良いことだと思います:)

私はホット デプロイ機能を使用したことがないので、それについてコメントすることはできません。

最後のポイントに答えるために、それは私の期待に応えましたが、学習曲線といくらかの適応が必要であり、その見返りは長期的なものだけです.

（補足として、あなたの質問は、「mavenはビルドシステムのawtである」という格言を少し思い出させます）

于 2010-01-29T18:43:17.383 に答える
4

OSGi は報われません。実際のところ、OSGi は使いやすくなく、1 日または 1 年の終わりに、作業を開始するのにどれくらいの時間がかかるかに応じて、価値が追加されません。

  • それどころか、アプリケーションは全体的にモジュール化されなくなります。それどころか、何も共有しないアーキテクチャではなくすべてを共有するアーキテクチャであるため、他のアプリケーションから分離されず、より公開されます。
  • バージョン管理はスタックのさらに下にプッシュされます。OSGI で実行時にそれを行うためだけに、maven の推移的な依存関係と格闘します。
  • ほとんどのライブラリは、独自のクラスローダーとのバンドルとしてではなく、アプリケーション クラスローダーのライブラリとして機能するように設計されています。
  • サード パーティの開発者がサンドボックス化する必要があるプラグイン アーキテクチャに適しているか、単に EJB2.0 である可能性があります。

次のスライドを追加しました。OSGi が強制された場合に、OSGi をうまく使用する方法を示すサンプル コードを追加します。 http://www.slideshare.net/ielian/tdd-on-osgi

于 2014-01-28T00:09:09.600 に答える