展開で使用される実際のアプリケーション サーバーにできるだけ依存せずに Java アプリを構築するための最良の (最も簡単でシームレスな) 方法は何ですか?
たとえば、Apache Geronimo にデプロイしたいのですが、後で GlassFish を使用したいとします。移行はどれほど難しいでしょうか? 各アプリサーバーの使用を抽象化する最良の方法は何ですか?
無知で申し訳ありませんが、私はJava開発に比較的慣れていません。新しいプロジェクトを開始したいのですが、必要な機能に個別の API を使用するか、最初から選択したアプリ サーバー上で開発するかについて確信が持てません。
ご協力いただきありがとうございます、
イヴァン
あまり詳細に立ち入ることなく、必要最低限のJava EEコードを記述できたとしても、その周りの構成はそれほど単純ではありません。各アプリケーションサーバーには、独自の設定ファイルと命名規則のセットがあります（たとえば、ASの場所を指定するための形式はIBM WASとJBOSSで異なります）。これらはアプリケーション開発にとってそれほど重要ではありませんが、展開フェーズに入ると、これらは重要になります。ライブラリとコードに関する限り、EJB標準に準拠している限り、アプリケーションサーバーの大部分でアプリケーションを実行できます（WASとJBossを知っています-私が書いたコードはそうする必要はありませんでした）これらのサーバーの変更。ただし、構成は別の獣でした！）。
可能な限り Java EE 仕様に従い、サーバー仕様にはできるだけ従わないようにします。
JBossやWASなどの Java EE アプリケーション サーバーの共通点を探ると、サーバー ベンダーが従わなければならない Java EE 仕様が答えになります。Java EE の問題について 2 つの解決策がある場合、サーバーの仕様ではなく Java EE の仕様に準拠している解決策を確認できます。
Jboss と Sun AS に関する私の経験から、AS 独立性については忘れてください。
たとえば、SQL では、ベンダー固有の機能を使用しなくても、かなり多くのことができます。まあ、Java EE ではそうではありません。Jboss と SAS の場合、「hello world」アプリケーションでさえも異なる構成が必要になります。そして、より多くのアプリケーションが成長し、より多くのベンダー固有の機能を使用する必要があります。
特に、公式の Sun Java EE チュートリアルを見ると、最初から SAS 固有の構成ファイル (sun-web.xml、sun-ejb-jar.xml など) が採用されていることがわかります。
ただし、上記のすべては、Java EE 機能 (EJB、JMS、mbeans など) をすべて使用する場合にのみ適用されます。サーブレット/jsps を 1 つの war-archive にパッケージ化しただけでも、そのようなアプリケーションは非常に移植性が高いことがわかりました。
リソースがある場合は、最初のターゲット サーバーだけでなく、複数のアプリケーション サーバーの開発とテストを検討してください。これにより、最初から、構成可能にする必要があるものを特定し、それに応じてコーディングすることができます。
個人的には、Glassfish 3.0.1 はリファレンス実装であるため、特別な努力をしなくても動作するはずです。