web-dev-qa-db-ja.com

現在、JBossまたはGlassfish(または別の)をJava新しいプロジェクトのEEサーバーとして使用しますか?

約1年で終了する新しいJava EEプロジェクトを今日開始した場合、どのアプリケーションサーバーを選択しますか?

あなたの答えの一部には、あなたの決定に対するあなたの議論が含まれるべきです。また、あなたが選択したJava EEサーバーおよび市場で利用可能な他のサーバーでどれだけの経験がありますか。あなたの答えに。

136
user14070

私は過去10年以上にわたって、WebLogic、WebSphere、JBoss、GlassFish、Resin、Jetty、Tomcat、およびその他のいくつかを使用しました。したがって、新しいプロジェクトを検討している場合、最初にいくつか質問をします。私がもう疑問に思わないことの1つは、ママのために泣くまで拷問されない限り、私はJSPの使用を完全に拒否するということです。

誰かの義務のために、特定の製品と互換性/展開する必要がありますか?それらを無視するか、そうでなければ彼らを説得する方法はありませんか?もしそうなら、あなたの答えがあります。

EJBを使用する必要がありますか?本当に?可能な場合は避けてください。これらは、非常に大規模なエンタープライズクラスのシステムでのみ必要です。それらは単なるツールであり、大きなツールであることを覚えておいてください(「ゴールデンスレッジハンマー」と言うことはできますか?)。それらは酷使されすぎているので、本当に必要なのかどうか本当に疑問です。それらが必要な場合は、お気に入りのJettyを含むいくつかのオプションが削除されます。

JMS、ESBなど、他の主要なJ2EEテクノロジーを使用する必要がありますか?もしそうなら、そしてあなたは本当にそれなしではできません、そしてあなたは再び本格的なJ2EEコンテナに制約されます。たとえば、BPMにコミットする前に慎重に検討して調査し、(ほぼ)すべてのコストでAquaLogic BPMを避けます。極端にextremeいです。

本格的なJ2EEコンテナを実際に使用する必要がある場合は、オープンソースの方が堅牢で、サポートが優れており、費用対効果が高いため、最初にオープンソースを検討してください。彼らはより大きな顧客ベースとよりオープンなサポート対話を持っているので、彼らはより良い修正をより速く得る傾向があります。ただし、Resinは未熟であり、GlassFishまたはJBossに比べて避けたいと思います。デプロイとサポートに問題があることがわかりました。幅広い顧客ベース、成熟度などの理由で、JBossを好むでしょう。GlassFishは自動化されたビルド/デプロイメントプロセスに組み込むのが困難ですが、その特定の機能(必要な場合)のほうが優れている場合があります。

Apacheが必要な特別な理由はありますか?次に、Tomcatに傾倒します。

サーブレットだけで対応できますか?次に、Jettyを使用します。これは、最軽量、最速、最も簡単で、最も柔軟なソリューションです。 Jettyを使用できるようになることに傾倒している場合、その理由に関するすべての仮定に疑問を呈するでしょう。 YAGNIが適用されます。

最良の方法は、JettyでStringTemplate/WebStringTemplateを使用することです。これは、ライセンス料、確固たる評判、サポートなどを必要としない、クリーンで堅牢、高速、保守可能なソリューションです。

ほとんどのアプリケーション/システムは、適切なアーキテクチャ/設計を備えたサーブレットとJDBCだけが本当に必要なときに、多くの派手なJ2EE機能を選択します。なぜもっと必要だと思うのか質問してください。

本格的なコンテナのうち、MAJORパブリックWebサイトをサポートしている場合を除き、WebLogicとWebSphereを避けます(私の現在の雇用者のWebサイトはWebLogicにデプロイされており、月あたり1,100万以上のヒットがあり、他のWebサイトは同等です)。 WebLogicの本当の主張は、比較的簡単なクラスタリングですが、(ほとんど)すべてのコストで独自のベンダーロックイン機能を避けます。 WebSphereは単なる悪夢であり、文字通りすべての犠牲を払って回避します。過去にカップルをやった後、WebSphereを含むプロジェクトを行うことを拒否します。プロプライエタリ機能の使用を促進する特別なニーズがない限り、どちらの製品も多額のライセンス料の価値はありません。多くのフォーチュン500企業のシニアアーキテクト/エンジニアとしての10年で、私はまだそのような必要性を見ていません。一方、私はそのようなプロプライエタリな製品を選んだために多くの痛みを見てきました。

非常に大規模でトラフィックの多い公共のウェブサイトであっても、プロプライエタリ製品は依然として疑わしいものです。私は、年間数百万ドルのライセンス料を、優れたハードウェアと、優れたコンサルタントの一握りからの質の高い時間に費やして、単純なスケーラビリティソリューションに対処したいと考えています。その後、年間数百万ドルを使用して、ニースのウェブサイトで販売する価値のあるものを作成できます...

編集:考慮すべき別の部分...

私は最近遭遇しました Terracotta 。私はすべてを再考し、すぐに重要なシステムに展開することを検討しています。特に、Terracottaは他の何よりも優れたクラスタリングを行うため、クラスタリングにWebLogicを推奨することはもうありません。

181
Rob Williams

「アプリケーションサーバー」という用語はあいまいです。 GlassFish v3を使用すると、たとえば従来のWebコンテナーから小さく始めて(OSGiおよび単純な「コンテナーの追加」機能を使用して)進化させて、JPA、JAX-RS、EJB、JTA、JMS、ESBを追加できます、など...それは同じ製品、同じ管理インターフェースなどです。これはあなたにとってアプリケーションサーバーとしての資格がありますか? -アレクシス(日)

10
Alexis MP

私が通常自問する最初の質問は、「Tomcatでこれを実行できますか?」です。 JMSまたはJTAが必要なために答えが「いいえ」の場合、アプリケーションサーバーに頼ります。

WebLogicの使いやすさとライセンス/コストモデルに満足して約3年前にWebLogic 8を使用しました。 2つのプロジェクトに使用しました。1つはWebサービスで、もう1つはポータルです。これらのプロジェクトのいずれにおいても、WebLogicまたはWebLogic Portalで問題は発生しませんでした。

過去2年間、私はWebSphereで働いていました。 IBMと交渉したときはいつでも、常にWebLogicの同等の2倍の費用がかかりましたが、企業ポリシーではWebSphereを使用する必要がありました。 WebSphereの学習曲線はWebLogicよりもかなり急であることがわかり、ビルド/デプロイ/テストのライフサイクルは非常に時間がかかり、開発環境でTomcatを使用しました。しかし、WebSphereで私が抱えていた最大の問題は、web.xmlを解析する新しい問題を実行するためだけに次のパッチリリースにアップグレードせざるを得なかったバグに遭遇したときでした。すべてを完了するには48時間のシフトが必要でした。

現時点では、私はJBossを使用しています。約3か月前、TomcatとJetspeed 2を使用して新しいプロジェクトに着手しようとしていましたが、Jetspeed 2は現在少し停滞しているようで、JBoss Portal 2.7.0がJSR 286/Portlet 2.0サポートと共にリリースされたことがわかりました。 JBossを試してみたところ、セットアップと管理が非常に簡単でした。ビルド/デプロイ/テストサイクルは非常に高速であり、Spring XMLファイルをどこかで変更しない限り、サーバーを再起動する必要はほとんどありません。

9
Brian Matthews

私はjBossを3〜4年間使用しています。

JBossの引数:

  1. オープンソース。
  2. 利用可能な商用サポート。
  3. 大規模でアクティブなユーザーコミュニティ。

JBossに対する議論:

  1. 汎用アクセスなし、サポートJava EE 5コンテナーリリース。
  2. 多くのドキュメントがありますが、冗長です。 「どうすればxを実行できますか?」に対する答えを見つけるのが難しい場合があります。
  3. 4.xの管理ツールは、他の商用製品と比較して貧弱です。
7
johnstok

GlassFish 3.1をチェックしてください!モジュール上に構築されたJava EE 6ベースのGlassFish v3カーネル、バージョン3.1は、クラスタリング、集中管理、高可用性を実現します。

詳細については、 http://blogs.Oracle.com/nazrul/entry/glassfish_3_1 を参照してください。

4
Nazrul

ここで説明しなかったもう1つのポイントはパフォーマンスです。サービスのタイプまたはユーザーの数のためにこれが懸念事項である場合、以下が適用されます。

  • TomcatはGlassfishより遅いようです
  • GlassfishはResinより遅いようです
  • ResinはG-WAN + Javaよりもはるかに遅い

G-WANはJVMのみに依存していることに注意してください。(明示的に指定されていない限り)それ以上のコンテナを使用しないため、Webアプリケーションのパフォーマンスに重要な部分に予約することができます。

G-WANは他の言語(C、C++、C#、D、Objective-C)をサポートしているため、他のタスク用にJavaを保持しながら、生Cでアプリケーションの一部を処理することもできます。

3
gert

私はまだWebLogicが市場で最高のJava EEアプリサーバーだと思います。これらのライセンス料を支払う余裕があれば価値があると思います。

Tomcat、OpenEJB、およびActiveMQを組み合わせることで、どこまで行けるかを見て驚いた。それは低コストの選択肢のように思えます。

また、Spring dm Serverも調べます。 Tomcatに基づいていますが、彼らが追加したOSGiの作品はどこにでも短い順序であると思います。 Springフレームワークと同じ品質でできていれば、本当に良いことです。

2
duffymo

優先するOSを決定基準として含める場合があります。 OSとアプリサーバーに同じベンダーを使用している場合、サポートが容易になるはずです。片方または両方のベンダーと既に関係がある場合は、それらが対処できるかどうかを検討してください。

技術的な観点から、GlassFishを選択するのは、最近のイノベーションをサポートしているからです。とにかく、JBossが悪いとは思わない。単に最新ではない。

私の経験のほとんどはWebLogicに関するものですが、JBossとGlassFishを使用しました。私は、完全なSunオープンソーススタック(OpenSolaris、GlassFish、MySQL)で新しいサイトをリリースしたばかりで、わずかな不満だけで素晴らしい経験となりました。

2
Ed.T

別の方法:アプリサーバーをまったく使用しません。

http://www.atomikos.com/Publications/J2eeWithoutApplicationServer をご覧ください。

Webプロジェクトの場合、必要に応じて軽いWebコンテナーをWicketのようなものと組み合わせて、JSP/JSFまたはstrutsの複雑さを回避してください。

HTHガイ

1
Guy Pardon