タイトルが示すように、これは特に Java EE と Glassfish に関連しています。
私が学んだことから、アプリケーション クライアントは、glassfish と通信できるアプリケーション クライアントで実行されます。ただし、注釈に関してはこれには制限があるようです。
2 つの異なるアプリケーション タイプから Glassfish アプリケーション サーバーに接続する場合の違いの例を誰か教えてもらえますか?
アプリケーション クライアント アプローチの利点は何ですか? また、Java EE 用のアプリケーション クライアントを開発する際に最も一般的に使用されるアプローチは何ですか?
アプリケーション クライアントは実際にはコンテナ内で実行され、サーブレットや EJB と同じように、サーバー上で定義された Java EE リソースに完全にアクセスできます。これは通常、ユーザー アプリケーションではなく、ある種の管理クライアントに使用されます。 ここに 1 つの説明があります。
Java EE アプリケーション クライアントに加えて、一部の Java EE リソースへのアクセスを可能にするシン クライアントの概念もありますが、アプリケーション クライアントほど簡単ではありません。JNDI参照が利用できないため、通常は絶対名でJNDIルックアップを使用する必要があります。この典型的なケースは、JMS メッセージのスタンドアロンのプロデューサー/コンシューマーです。これは基本的に、フル App Client の軽量オプションです。
単純にユーザー アプリケーションを作成する場合は、ほとんどの場合、シン クライアント モデルを使用するか、サーブレットまたは Web サービス呼び出しを介して Java EE アプリからサービスを利用する単純な古いアプリケーションを使用することをお勧めします。
どちらの場合も、アプリ サーバーへの接続に関連するコード (実行する必要がある作業) はそれほど難しいものではありませんが、別のドキュメントで説明されています。
以下は、スタンドアロンの Java アプリケーションから EJB にアクセスする方法の説明です。
アプリケーション クライアントを使用して、GlassFish v3 で Java EE 6 アプリケーション クライアントから EJB にアクセスする手順は次のとおりです: http://docs.sun.com/app/docs/doc/820-7695/beakt?l=en&a=見る
アプリケーション クライアントから EJB にアクセスすると、EJB を「直接」操作する場合よりも多くの Java EE サービスに「自動的に」アクセスできます。スタンドアロンの場合、これらのサービスのいくつかへのアクセスをまとめることができますが、そのアクセスを機能させるためにアプリケーション開発者/デプロイヤーに負担がかかります。
EJB にアクセスするスタンドアロン アプリケーションを作成することは、短期的には簡単に思え、多くの人がその戦略に投資するでしょう。クライアント アプリケーションを多数のマシンに展開する場合、サービス アクセス戦略を組み合わせることによる負担が重荷になる可能性があります。
アプリケーション クライアント コンテナーを使用するアプリケーション クライアントのデプロイも無料ではありません。利点は、展開の問題を克服するためにアプリ サーバー ベンダーのサポートがあるという事実です。
GlassFish (v2.1、v2.1.1、または v3) を使用している場合は、クライアント アプリケーションの展開を大幅に簡素化する Java Web Start サポートも利用できます。