アプリケーションサーバー（EJBを使用）がJava EEクライアント/サーバー通信の唯一の方法ですか？

Question

WebクライアントとSwingクライアントの両方で最大100人の同時ユーザーにサービスを提供するJavaクライアント/サーバーERPアプリケーションを想像してください。永続化のために、Persistence APIとHibernateを使用できます。  しかし、クライアント/サーバー通信に関しては、リモート通信のプログラミングコストを抑えるために、EJBでASを使用する代わりに、本当に代替手段がありますか？

EJBとアプリケーションサーバーをスローするためだけに、非常に重量のあるソリューションのようです。 RMIを使用する標準的な方法もありますが、最近は自分ですべてをコーディングしたい人がいます...

リモーティング部分に加えて、ASを使用すると多くの機能を無料で入手できることを知っています。そして、多分それは行く方法です。しかし、エンタープライズアプリケーション用のクライアント/サーバー通信を行うためのASに他の（プログラミングコストが低い）代替手段は本当にありますか？

Answer 1

個人的には、Seamは私が抱えていない問題の究極の解決策であると考えていますが、それ以外にも多くのオプションがあり、それらのほとんどにSpringが使用されています。

• RMI ;
• ヘッシアン （バイナリHTTPベースのプロトコル）;
• HTTP呼び出し側（HTTPを介したJavaシリアル化）;
• Webサービス;または
• JMS でも。

HTTPベースのリモート処理メソッドの利点は、Springのセキュリティモデルに簡単にプラグインできることです。さらに、インターセプターなどにアクセスできます。

Answer 2

軽量のリモート処理フレームワークを使用できます。このセクションには、Springの多くのオプションがあります。

両方の単語を1つだけ聞いたら、2つ提案します。縫い目または春。私自身はSeamが好きですが、軽量のリモート処理には Spring より実行可能なソリューションとサポートがあります。 ASがJBossの場合も、シーム。

Answer 3

アプリケーションサーバーはかなり重いソリューションです。要件に応じて、単純なサーブレットコンテナ（Tomcatなど）で実行できることを確認します。代わりに Spring-remoting を使用すると、リモート処理がはるかに簡単になります。完全なEJBの。 Spring-remotingは、実際に使用されているリモート処理手法を抽象化します。ヘッセ行列は、軽量プロトコルとして高い評価を得ています。

何らかの低レベルの問題（接続の確立、スレッド化など）について考える必要はないので、何らかのサーバーフレームワーク（ASまたはサーブレットコンテナー）を用意するのは良いことです。