1

私は、目の前のタスクを達成することを主な目的として、osgi を検討し始めました。基本的に、Web ベースのアプリケーションを配布し、Web アプリ全体の特定の機能を個別に構築して、機能 a、b、c を使用して Web アプリを A にデプロイし、機能 a、c を使用して B にデプロイできるようにすることができます。 、d。

joomla にプラグインをインストールする方法に少し似ています。たとえば、Web アプリケーションの別の側面を追加したい場合は、すべての html とits adminセクションを使用して小さな戦争を構築し、この機能の管理セクションをメインの管理パネルで使用できるようにします。

2 番目の質問は、Spring DM についてです。おそらく私はSpringを使用し、Spring DMが提供するものを見るのは当然のようです.Spring DM .1.2.1をダウンロードした後、そのlibフォルダーにはバージョン2.5.6.SEC01のSpring jarが含まれていることがわかりましたが、使用する予定でした3.1.2なので、すべてがうまく連携する方法について少し混乱しています.

読んでくれてありがとう

4

2 に答える 2

4

私はちょうどそのような運動をしているので、春のオーバーヘッドなしであなたがそれをどのように行うかを明らかにすることができます。私は明確な区分を作成しました。すべてのアプリケーションコードはブラウザにあり、すべてのデータ処理はサーバーにあります。HTML5により、ブラウザは印象的でポータブルで強力なアプリケーション環境に成長しました。1つは、マルチプロセッシング、メッセージング、モジュール性、およびすばらしいビジュアルを備えています。ブラウザのフレームワークとしてangularjsを使用しています。

Angularは、ページURLのハッシュ部分をJavascriptの「モジュール」にマッピングする中央ルーティングテーブルと連携します。これにより、どのモジュールがアプリケーションの一部であるかを非常に簡単に定義できます。サーバーはこの部分を簡単に制御できます。

サーバー側には、Javascriptコード、htmlフラグメント、およびデータ処理を含むバンドルがあります。柔軟性が高いため、これはOSGiHttpサーバーモデルに基づいています。ただし、キャッシュ、ストリーミング、範囲など、バンドル内の静的リソースの適切なサポートを追加しました。

サーバーでは、DSとbndtoolsを使用してバンドルを開発しました。Smalltalkのように機能するため、これは印象的な開発エクスペリエンスです。変更すると、すぐにサーバーに反映されます。バンドルを追加したり、バンドルを削除したりしても、サーバーは稼働し続けます。開発中にサーバーが再起動することはまれです。

不利な点は、残念ながらOSGiを活用するコンポーネントが非常に少ないことです。Springが典型的な例であるほとんどのコンポーネントは、アプリケーションを中心点から配線するためのクラスローディングハックに大きく依存しています。これは基本的にモジュール式ではありません。このため、OSGiサービスモデルを活用する、非常にまとまりのある、結合されていない多くのコンポーネントを開発する必要がありました。時間があれば、それらをオープンソースプロジェクトに寄付します。

于 2012-08-29T07:19:15.790 に答える
0

州の要件を達成するために、少なくとも直接ではなく、OSGi を検討する必要があるかどうかはわかりません。あなたが言った：

基本的に、Web ベースのアプリケーションを配布し、Web アプリ全体の特定の機能を個別に構築して、機能 a、b、c を使用して Web アプリを A にデプロイし、機能 a、c を使用して B にデプロイできるようにすることができます。 、d。

これらが要件である場合は、実際に OSGi に直接関心を持つ必要はなく、モジュラー拡張をサポートする Web アプリ フレームワークを見つけてください。これはおそらく、フレームワーク自体が OSGi を使用していることを意味します。私は Spring に詳しくありませんが、Struts 2 (同等の Web アプリ フレームワーク) には、ユース ケースを実現するため のOSGi ベースのプラグインがあることは知っています。

一方、あなたのアイデアが OSGi で遊ぶことである場合は、Web アプリ自体ではなく、Web アプリケーション フレームワークの作成など、より低レベルのタスクを選択することをお勧めします。

于 2012-09-04T17:35:59.480 に答える