Hibernate の父である Gavin King [1] は、開発者に Java EE 6 プラットフォームにアップグレードすることを推奨し、現在のアップグレードへの躊躇には実際には根拠がないことを指摘しました。
Java EE 6 のリリース後、新しいプラットフォームにアップグレードすることに多くの抵抗があることに気づきました。これらの反対意見のほとんどは、Tomcat/Jetty および一部のオープンソース フレームワーク (Hibernate や Spring など) のユーザーによって提起されています。
もちろん、非標準のオープンソース テクノロジーを選択することには多くの利点があります。さらに、EE 6 では、興味のあるオープン ソース フレームワークを使用できます。Servlet 3 と CDI は、サードパーティのフレームワークをシームレスに統合できます。したがって、EE 6 を使用しない理由はありません。それでも、誰かがこう言うのを見かけました。
EE アプリケーション サーバーへのアップグレードは困難です
これは実際の技術的な問題というよりも、特定の組織の政治的な問題であるようです。もちろん、GlassFish や JBoss などのサーバーのアップグレードは非常に簡単な作業です。 (サードパーティのフレームワークをアップグレードする場合は、さらに手間がかかります。) 組織によっては、サーバーのアップグレードには非常に負荷の高いプロセスを採用していますが、サーバー内で実行されているフレームワークのアップグレードにはそれほど負荷がかかりません。したがって、開発チームはサードパーティのフレームワークをアップグレードすることが容易になります。
Java EEを放棄するのではなく、より説得力のあるより良いプロセスを開発することが最も重要だと思います。古くて時代遅れのサーバー プラットフォームでアプリケーションを実行することには多くのリスクが伴うため、プロセスではそのような行為を奨励すべきではありません。
しかし、実際的な観点から見ると、ほぼ全員が近い将来に Servlet 3 にアップグレードすることを計画しています。 Tomcat、Jetty、JBoss、GlassFish、Resin、WebLogic、Oracle、WebSphere のいずれを使用している場合でも、これはサーバーのアップグレードを意味します。これは、ゴールデンタイムである EE 6 Web プロファイルにアップグレードする絶好の機会です。
EE アプリケーション サーバーが大きすぎる
反対意見は、EE Server には (現在) 利用できない多くの機能が含まれているということです。反対派の議論には通常、jar パッケージのサイズと、サーブレット エンジン + サードパーティ フレームワークおよび EE アプリケーション サーバーが占有するディスク領域についての議論が含まれます。実際、この議論には問題があります。
ここで説明したディスク使用量とディスク容量は、$ で測定すると実際には取るに足らないものであり、サーバー インストール パッケージのサイズよりもアプリケーションの war パッケージの方がはるかに重要です。実際には、サーバーには war のサイズを最小限に抑えるための多くの機能が含まれています。
さらに、最も説得力があるのは、Java EE 6 Web Profile がまったく巨大ではないということです。認定された Web プロファイル サーバーが市場に出ると、大規模な EE アプリケーション サーバーと小規模なサーブレット コンテナーの間のバランスを見つけることができます。
J2EE と EJB2 が悪い!
JCP の標準化プロセスにより、この問題は実際には存在しなくなりました。
1. EJB2登場から8年！それでもそれがあなたの最善の選択ですか？
2. JCP の継続的な標準化を通じて優れた仕様が統合されており、その一部は確実に使用できます。しかし、JCP は標準化に 100% 成功したわけではありません。
3. EE 6 プラットフォームで作業している人は皆、EJB2 と J2EE を嫌います。だからこそ、人々はこれらの問題の解決を支援するために絶えず日本共産党に参加しています。たとえば、Hibernate の創設者であり、この記事の著者です。本当に彼に EJB2 についてのレッスンを教えたいですか? :-)
4. Entity Beans に携わるほぼ全員が現在退職しています。
実際には、Java EE 6 Web Profile で十分です。 Java EE 6 を実際に試してみないと、開発における EE6 のメリットを実感することはできません。
アプリケーション サーバーの移植性は非常に謎です。
本当に？アプリケーションを分割し、異なるアプリケーション サーバーにデプロイしている人がたくさんいます。ああ、これは 100% 完璧なアプリケーションの変更ゼロ移植、つまり移植性のプラトニックの理想を意味するのを見てきました。絶対的な真理やプラトン的な理想に対する弱点は理解していますが、最初に例を見てみましょう。
移植性の問題の非常に典型的な見方を次に示します。
コードの 9%、外部メタデータの 85% は異なるサーバー プラットフォーム上で完全に互換性があり、残りの 1% と 15% は適切に分割できます。
0% コード、80% の外部メタデータが非標準の単一ベンダーのコンテナ アーキテクチャに関連付けられている
これらのポイントを分割しているときに、突然、このセクションのトピックを、アプリケーション サーバーの移植性は謎すぎるということから、コンテナの移植性についてはまったく気にしないということに変更したいと思いました。テーマの変更というアイデアは、サーバーの移植性の問題が現実のものであり、多くの組織にとって非常に役立つものであることを裏付けています。
私は常に、EE 6 以外の技術メンテナによる EE 6 の実際のレビューを見たいと思っていました。上記の議論の一部は現実世界から来たものではないため、EE プラットフォームでのアプリケーション開発の実際の技術的問題についての議論を引き起こすのは困難です。 JCP 仕様の最新ラウンドは、反 EE 陣営から (一時的に?) 離脱したようですが、成功を裏付ける事実に欠けています。
編集者注:
[1] Gavin King: Hibernate の創設者、EJB3 専門委員会のメンバー、JBoss の中心メンバーの 1 人、Seam フレームワークのリーダー、JSR-299 (CDI) 仕様のリーダー、そして書籍「Hibernate in Action」の著者。
出典: Java EE 6 にアップグレードする必要があります。