19

エンタープライズ Web アプリケーションの Spring と Jboss の長所と短所は何ですか。

4

7 に答える 7

59

これは良い質問です。ここで、これはリンゴとオレンジの比較であると誤って述べている人もいます。つまり、Jboss はコンテナーであり、Spring は Struts のような単なるフレームワークです。ただし、これが少し混乱している理由は、JBoss と Spring の両方が元の単純な起源から大幅に拡張され、お互いに近づいているためです。JBoss を理解する簡単な方法の 1 つは、名前が元の「EJBoss」であり、オープンソースの J2EE アプリケーション サーバーであることを意図していたため、EJB コンテナーとして機能するよりも Tomcat よりも優れていたため、WebSphere と競合することができたということです。およびその他の専用アプリケーション サーバー。

また、Spring は IoC フレームワーク (現在は「依存性注入」と呼ばれています) であり、本質的にオブジェクトのファクトリであるため、より「疎結合」な設計に従うことができます。

しかし、その人気により、両方の製品が拡大しました。たとえば、JBoss には独自の IoC コンテナがあります: JBoss IoC

JBoss は、JBoss Microcontainer と呼ばれる独自の軽量 IoC コンテナーを提供します。JBoss Microcontainer は、Spring、Pico Container、および Plexus と概念が似ている軽量の制御/依存性注入コンテナーの反転です。

また、Spring は完全にうまく動作し、JBoss と (ほぼ) うまく共存できますが、本格的な EJB コンテナーは必要なく、Tomcat で簡単に実行できます。Spring の全体的な設計目標は、軽量設計のアイデア、POJO の使用、および重いコンテナーの要件の欠如に基づいていました。これは EJB とは非常に相反するものであり、JBoss とは相容れないように思われます。

Rod Johnsonは、JBoss で Spring を実行できない理由はないと指摘しています。

Spring は、任意のアプリケーション サーバー (またはアプリケーション サーバーの外部) で動作するように設計されています。Spring を使用することは、サーバーが提供する必要があるものを無視することを意味するわけではありません。多くの場合、選択肢が増えるだけです。

したがって、2 つのシステムのどの部分を使用するか、どの Java 標準に準拠するかを決定する必要があります。この記事によると、JBoss と Springは、標準にどれだけ準拠しているかをカバーしていますが、どちらのテクノロジーを選択するかによって、どちらか一方を選択しているように見えます。

JBoss と Spring Source は、XML から統合、ツール、最終的には仮想化に至るまで、すべてをめぐって争っています。健全な競争です。

[をちょきちょきと切る]

時が経てばわかることですが、この戦いは開発者にとってより良いものになるだけだと思います。.Net よりも多くの選択肢があり、Java に関するイノベーションが増えます。JBoss にとっては厳しいテストになるでしょうが、実行が完璧であれば対処できるものです。そうでなければ、Spring Source を探して、JEE 6 の認識されている利点と実際の利点との間のくさびを駆動します...遅かれ早かれ、独自のモデルに対抗するためにアプリケーションの移植性を実証する必要がありますが、それは実現していません。

さまざまな Java 標準への準拠に関する最新情報については、Spring 5 に関するフィードバックのリクエストをご覧ください。Spring 設計者が直面している制約についてのアイデアを得ることができますが、Spring 市場では、Spring がさまざまな EE サーバーを確実にサポートすることが重要であるという事実も強調されています。

EE ベースラインもソフトにアップグレードする予定です。ここには個々の要件が事実上存在するため、これは少し注意が必要です。また、運用環境での企業の採用レベルを考慮する必要があります

確実に Servlet 3.0+ (現在の Servlet 2.5 ランタイム互換性から) に上げますが、Spring 5 アプリケーションを引き続き EE 6 ベースライン サーバーで実行したいので、それ以上には上げません。Java EE 7 の市場状況と、まだ Servlet 3.0 API に基づいている多数のサーバーを考えると、なぜこれが避けられないのかについての議論については、私の以前のブログ投稿を参照してください。[中略] 2002 年以降の JMS 1.1 API をサポートし続けなければならないのは残念です… JPA 2.1+ と Bean Validation 1.1+ に引き上げたいのですが、TomEE 1.7 と JBoss EAP 6.4 のどちらかが必要なようです。ハードJPA 2.0とBean Validation 1.0 APIがあり、WebLogic 12.1.3にはJPA 2.1がありますが、Bean Validation 1.1 APIはありません(関連しているにもかかわらず)。

于 2010-10-28T16:57:05.813 に答える
13

すでに述べたとおりですが、要点をもう一度述べさせてください。JBoss はアプリケーション サーバーです。一部の Java アプリケーション サーバーには、

  • ウェブスフィア
  • グラスフィッシュ
  • Jボス

Spring はフレームワークです。かなり大きなフレームワークですが、私にとって主な機能の 1 つは MVC です。MVC は、ビューからモデルをコントローラーから分離する設計パターンです。モデルはデータの表現です。これは、データベースや XML ファイルなどによって裏付けることができます。ビューは、モデルを表示するために使用されるものです。これは、Web フロントエンドまたは Windows アプリケーションのいずれかです。ユーザーはビューを操作します。ユーザーは、モデルを更新したいという希望を表明します。ここでコントローラーの出番です。コントローラーを使用して、モデルに更新を指示します。ビューはモデルに基づいているため、ビューも更新されます。これは単純化しすぎていますが、一言で言えば。あなたが見ることができる他のMVCフレームワークはStrutsです。

前に言ったように、Spring が提供する他の機能があります。

  • セキュリティ フレームワーク
  • 制御の反転
  • 依存性注入
于 2009-03-09T20:39:22.290 に答える
2

JBoss はコンテナーであり、spring はコンテナー内で実行されるものです。あなたはリンゴとオレンジを比較しています。

于 2009-03-09T20:15:20.867 に答える
1

アプリケーションは JBoss 上でモノリシック (1 つの JVM プロセスですべてを実行) として実行されます。スケーリングするには垂直/水平クラスターが必要であり、Spring の使用を調整してマイクロ サービス アーキテクチャを実装することもできます。

于 2016-02-12T17:47:33.903 に答える
0

java6 と CDI (@inject を参照) の意見は間違っているため、もはや春だけではありません。15 年前の EJB2 (および EJB3 でさえ) は正しかったのですが、今日では CDI コードは websphere、weblogic、jboss、glassfish など、必要なアプリケーション サーバーで管理されています。

于 2014-03-19T09:31:35.370 に答える