「Spring DM in action」という本を見つけました。Spring for OSGI の最新リリースをチェックし始めたとき、Spring がこのプロジェクトを廃止したことがわかりました。
Spring での開発経験があるので、モジュラー アプリケーションを作成する方法として、Spring と OSGI について読み続けるか、Spring Boot に切り替える必要があるかを理解したいと思います。
8036 次
3 に答える
7
コメントを書きたかったのですが、文字数が足りませんでした。
OSGi のモジュール化とダイナミクスが必要な場合は、Spring DM (現在の Gemini Blueprint) が優れたテクノロジです。これを使用して、プラグイン インフラストラクチャを備えた高性能のメッセージ指向ミドルウェアを作成しました。プラグイン インフラストラクチャが必要でした。これは、顧客が実行時に Web インターフェイスを介してモジュールを追加/交換/更新し、ルートを変更できるようにしたいと考えていたためです。各メッセージは、0-N groovy スクリプト (db に格納され、実行時に変更可能) を介して変換されました。処理エンジンは、Spring バッチと Spring 統合に基づいていました。
したがって、OSGi の実際の使用例がある場合、それは優れたテクノロジになる可能性があります。
しかし、ほとんどの場合、モノリシックな Web アプリケーションのレイヤーを分離するために、人々はそれを使用しようとしましたが、これは役に立たず、利益よりも多くの作業をもたらします。開発者が OSGi を使用してドメイン モデルの各グループを小さなモジュールに分割するアプローチを見たことがあります。これは、利益がゼロになるため、利益を得る以上にアプリケーション設計に害を及ぼします。
また、この本は、ソフトウェアの「開発方法」に関する別のアプローチを提供するための良いアイデアかもしれません。
于 2015-03-02T22:39:14.380 に答える
1
タイトルの質問に：「OSGi」は確かです。OSGi サービスは、マイクロサービス モニカの非常に (最も?) 自然な候補です。
あなたの投稿の内容に：
ここに飛び込んで、「両方」と言わなければなりません。OSGi、IMHOは、Java に起こる最高のものです。なんで？より小さく、よりモジュール化されたコード片の生成を促進することにより、より良い設計慣行に従うように求められます。
私は spring-boot も大好きですが、クライアント側のアプリケーションを作成するのにより適している (読み、「すばらしい」) ことがわかりました。
Spring でのあなたの経験についてのポイントまで - 恐れないでください。Spring XML 構成に慣れている場合は、青写真の構文がほとんどの場合同一であることがわかります...そして、OSGi を活用するシステム内でさまざまな Spring の部分を引き続き幅広く使用できます。
参考までに - 私は、OSGi に根ざした大規模なシステムをいくつか開発したという観点から話しています (また、典型的な WAR/サーブレット展開の荒野への進出もいくつかあります)。
于 2015-10-14T12:33:18.340 に答える