現在、新しいプロジェクトのJava EEサーバーとしてJBossまたはGlassfish（またはその他）を使用しますか？[閉まっている]

今日、約1年で完了する予定の新しいJava EEプロジェクトを開始した場合、どのアプリケーションサーバーを選択しますか、またその理由は何ですか。

あなたの答えの一部はあなたの決定のためのあなたの議論を含むべきです。また、選択したJava EEサーバー、および市場に出回っている他の利用可能なサーバーについて、どれだけの経験があるかについても説明します。私たち全員が調査の感覚をつかみ、それがあなたの答えに入れられたと思ったので、これらは興味深いものです。

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

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

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

JMS、ESBなど、他の主要なJ2EEテクノロジを使用する必要がありますか？もしそうなら、あなたが本当にそれなしではできないのなら、あなたは再び本格的なJ2EEコンテナに制限されています。たとえば、BPMにコミットする前に慎重に考えて調査し、（ほとんど）すべてのコストでAquaLogic BPMを回避します-極端に醜いです。

本格的なJ2EEコンテナーを本当に使用する必要がある場合は、オープンソースの方が堅牢でサポートがよく、費用対効果が高いため、まずオープンソースを検討してください。彼らはより大きな顧客基盤とよりオープンなサポートインタラクションを持っているので、より良い修正をより速く得る傾向があります。ただし、Resinは未成熟であり、GlassFishやJBossに比べて避けたいと思います。デプロイとサポートに問題があることがわかりました。顧客ベースや成熟度などが広いため、JBossを選択します。GlassFishは、自動化されたビルド/デプロイメントプロセスに組み込むのが困難ですが、特定の機能の一部（必要な場合）には適している場合があります。

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

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

最良の方法は、JettyでStringTemplate / WebStringTemplateを使用することです。ライセンス料、評判とサポートなどが不要で、クリーンで堅牢、高速、保守可能なソリューションです。私が今日始めたのはこの点です。

ほとんどのアプリケーション/システムは、サーブレットとJDBCがまともなアーキテクチャ/デザインである場合に、本当に必要なすべての豪華なJ2EE機能を選択します。もっと必要だと思う理由を質問してください。

本格的なコンテナーの中で、MAJORパブリックWebサイトをサポートしている場合を除いて、WebLogicとWebSphereは避けます（私の現在の雇用主のWebサイトはWebLogicにデプロイされており、毎月1100万以上のヒットがあり、他は同等です）。WebLogicの真の名声は、比較的簡単なクラスタリングですが、独自のベンダーロックイン機能を（ほぼ）すべてのコストで回避しています。WebSphereは、文字通り一切犠牲を払わずに回避できる悪夢にすぎません。過去に2、3回行った後で、WebSphereを含むプロジェクトを行うことを拒否します。プロプライエタリ機能の使用を推進する特別なニーズがない限り、どちらの製品も膨大なライセンス料に見合う価値はありません。多くのフォーチュン500企業の上級アーキテクト/エンジニアとしての10年間で、私はそのような必要性をまだ見ていません。一方、

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

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

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

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

私がよく尋ねる最初の質問は、「Tomcatでこれを行うことはできますか？」です。JMSまたはJTAが必要なために答えが「いいえ」の場合は、アプリケーションサーバーを使用します。

3年ほど前にWebLogic 8を使用しましたが、WebLogicの使いやすさとライセンス/コストモデルに満足しています。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ファイルをどこかで変更しない限り、サーバーを再起動する必要はほとんどありません。

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

jBossの引数：

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

jBossに対する反対意見：

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

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

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

ここで説明しなかったもう1つのポイントはパフォーマンスです。サービスのタイプまたはユーザー数が原因でこれが問題になる場合は、次のことが当てはまります。

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

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

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

私はあなたの好みのOSを決定基準として含めるかもしれません。OSとアプリサーバーに同じベンダーを使用している場合、サポートが容易になります。すでに1つまたは両方のベンダーと関係がある場合は、ベンダーが対処するのに適しているかどうかを検討してください。

技術的な観点からは、GlassFishを選択します。これは、最近の革新をサポートしているためです。とにかく、JBossが悪いとは思いません。単に最新ではないからです。

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

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

Tomcat、OpenEJB、およびActiveMQを組み合わせることで、どこまで行けるかを知り、驚きました。それは私には低コストの代替手段のように思えます。

Spring dm Serverも調べます。それはTomcatに基づいていますが、それらが追加したOSGiのピースはどこにでも簡単に並べられると思います。それがSpringフレームワークと同じ品質で行われている場合、それは確かに非常に良いでしょう。

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

チェックアウト http://www.atomikos.com/Publications/J2eeWithoutApplicationServer。

Webプロジェクトの場合、必要に応じて軽量のWebコンテナーを保持し、Wicketなどと組み合わせて、JSP / JSFまたはStrutsの複雑さを回避します。

HTHガイ