今日、約1年で終了する新しいJava EEプロジェクトを開始した場合、どのアプリケーションサーバーを選択しますか。その理由は何ですか。
あなたの答えの一部はあなたの決定のためのあなたの議論を含むべきです。また、選択したJavaEEサーバーおよび市場で入手可能な他のサーバーでの経験も豊富です。私たち全員があなたの答えに入れられた調査と考えの感覚を得るので、これらは興味深いです。
今日、約1年で終了する新しいJava EEプロジェクトを開始した場合、どのアプリケーションサーバーを選択しますか。その理由は何ですか。
あなたの答えの一部はあなたの決定のためのあなたの議論を含むべきです。また、選択したJavaEEサーバーおよび市場で入手可能な他のサーバーでの経験も豊富です。私たち全員があなたの答えに入れられた調査と考えの感覚を得るので、これらは興味深いです。
過去 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 機能を選択します。もっと必要だと思う理由を質問してください。
本格的なコンテナーのうち、主要な公開 Web サイトをサポートしていない限り、WebLogic と WebSphere は避けます (私の現在の雇用主の Web サイトは WebLogic にデプロイされており、1 か月あたり 1,100 万以上のヒットがあります。他のものは同等です)。WebLogic の本当の名声は、比較的簡単なクラスタリングですが、独自のベンダーロックイン機能を (ほぼ) すべての犠牲を払って回避します。WebSphere は、文字通り何としても避けたい悪夢にすぎません。私は、過去にいくつかのプロジェクトを行った後、WebSphere を含むプロジェクトを行うことを拒否しています。プロプライエタリな機能の使用を促進する特別な必要性が本当にない限り、どちらの製品も莫大なライセンス料に値するものではありません. 多くのフォーチュン 500 企業のシニア アーキテクト/エンジニアとして 10 年間、私はそのような必要性をまだ見ていません。一方で、
非常に大規模でトラフィックの多い公開 Web サイトであっても、プロプライエタリな製品は依然として疑わしいものです。単純なスケーラビリティ ソリューションに対処するために、年間数百万ドルのライセンス料をいくつかの優れたハードウェアに費やし、少数の本当に優れたコンサルタントから質の高い時間を費やしたいと考えています。年間の余分な数百万は、その素敵なウェブサイトで販売する価値のあるものを作成するために使用できます...
編集:考慮すべき別の部分...
最近テラコッタに出会いました。私はすべてを再考しており、すぐに重要なシステムに展開することを検討しています. 特に、Terracotta は他の何よりも優れたクラスタリングを行うため、そのクラスタリングに WebLogic を推奨することはもうありません。
「アプリケーション サーバー」という用語はあいまいです。GlassFish v3 を使用すると、たとえば従来の Web コンテナーで小規模に開始し、(OSGi と単純な「コンテナーの追加」機能を使用して) 進化させて、JPA、JAX-RS、EJB、JTA、JMS、ESB など、必要なものを追加できます。など...それでも、同じ製品、同じ管理インターフェースなどです。これは、あなたにとってアプリケーションサーバーとしての資格がありますか? -アレクシス (日)
私がよく自問する最初の質問は、「Tomcat でこれを実行できますか?」です。JMS または JTA が必要なために答えがノーの場合は、アプリケーション サーバーに頼ります。
私は約 3 年前に WebLogic 8 を使用していましたが、WebLogic の使いやすさとライセンス/コスト モデルに満足していました。1 つは Web サービス、もう 1 つはポータルの 2 つのプロジェクトに使用しました。これらのプロジェクトのいずれにおいても、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 の引数:
jBoss に対する反論:
GlassFish 3.1 をチェックアウトしてください! モジュール式の Java EE 6 ベースの GlassFish v3 カーネルの上に構築されたバージョン 3.1 は、クラスタリング、集中管理、および高可用性を提供します。
詳細については、 http://blogs.oracle.com/nazrul/entry/glassfish_3_1を参照してください。
ここで説明されていないもう 1 つの点は、パフォーマンスです。サービスの種類またはユーザー数が原因でこれが懸念される場合は、以下が適用されます。
G-WAN は JVM のみに依存していることに注意してください。G-WAN は (明示的に指定されていない限り) 追加のコンテナーを使用しないため、Web アプリケーションのパフォーマンスが重要な部分に予約することができます。
G-WAN は他の言語 (C、C++、C#、D、Objective-C) をサポートしているため、他のタスクのために Java を維持しながら、生の C でアプリケーションの一部を処理することさえできます。
私は今でも、WebLogic が市場で最高の Java EE アプリケーション サーバーであると考えています。そのライセンス料を払えるなら、それだけの価値があると思います。
Tomcat、OpenEJB、および ActiveMQ を組み合わせることで、どこまで行けるかを知って驚きました。それは私には低コストの代替手段のように思えます.
Spring dm Server も調べます。それはTomcatに基づいていますが、彼らが追加したOSGiの部分はすぐにどこにでもあると思います. Springのフレームワークと同じクオリティで作れたら、なかなかいいですよね。
ご希望のOSを決定基準として含める場合があります。OS とアプリ サーバーに同じベンダーを使用している場合、サポートが容易になるはずです。いずれかまたは両方のベンダーとすでに関係がある場合は、そのベンダーとの取引が適切かどうかを検討してください。
技術的な観点からは、GlassFish を選択します。それは、最近のイノベーションをサポートしているためです。JBoss が悪いとは思いませんが、とにかく最新ではありません。
私の経験のほとんどは WebLogic ですが、JBoss と GlassFish も使用しています。完全な Sun オープン ソース スタック (OpenSolaris、GlassFish、MySQL) で新しいサイトをリリースしたばかりで、わずかなフラストレーションだけで素晴らしい経験でした。
別の方法: appserver をまったく使用しません。
チェックアウトhttp://www.atomikos.com/Publications/J2eeWithoutApplicationServer。
Web プロジェクトの場合、必要に応じて軽量の Web コンテナーを保持し、Wicket などと組み合わせて、JSP/JSF またはストラットの複雑さを回避します。
HTHガイ