私は、パフォーマンスとスケーラビリティを最優先に考えた JEE6 アプリケーションを構築しています。
ビジネス ロジックと JPA2 ファサードは、ステートレス セッション Bean (EJB3.1) で保持されます。現時点では、SLSB は インターフェースのみ @Remoteを実装しています。Bean が別の Bean にアクセスする必要がある場合、RMI を介してアクセスします。
この背後にある私の推論は、アプリケーションがクラスター化されたアプリケーションサーバーの束で実行されると、RMI 部分により実行がクラスター全体に自動的に分散されるという仮定です。
それは正しい仮定ですか？
その欠点（オブジェクトがentityManagerセッションを失い、値渡し）に対処しても問題ありませんが、少なくともそう思います。しかし、一定のリモート呼び出しが必要以上の負荷を追加していないかどうか疑問に思っています。
EJB 仕様では、クラスタリングを実現する方法が指定されていないため、これは使用される特定の実装によって異なります。実際、EJB の仕様は、デプロイメントについて想定しないように意図的に書かれています。クラスタリングのサポートを義務付けているわけではありませんが、それを可能にする方法で書かれています (EJB モデルの多くの制限は、潜在的なクラスタリングの問題 (ファイル システムへのアクセスなど)。実装者は、クラスタリングをサポートするかどうかを自由に決めて、仕様に準拠します。
Glassfish では、リモート EJB への参照が配布自体を行います。詳細については、こちらの回答を参照してください。各リクエストは、異なるノードにディスパッチされる可能性があります。それはおそらくほとんどの実装が機能する方法です。したがって、あなたの仮定は正しいと言えます。
ただし、ある EJB が別の EJB を呼び出すケースを最適化し、可能な限り同じノードで侵入をディスパッチしようとすることを願っています。これは、デプロイメントが同種かどうか (すべてのノードが同じ Bean を持っているかどうか) によって異なります。繰り返しますが、仕様はそのような点に関して少しあいまいです。しかし、ほとんどの展開は実際には均一であると思います。同じ耳がすべてのノードに展開されます。
リモート呼び出しとローカル呼び出しのパフォーマンス オーバーヘッドに関して、(Glassfish で) いくつかの対策を行いました。ここで私の答えを見てください。リモート インターフェイスを介した同じ .ear 内の EJB 間呼び出しは、ローカル呼び出しよりも 3 倍遅くなりました。大きく聞こえるかもしれませんが、ここではミリ秒単位で話しているので、相対的なオーバーヘッドはメソッドが実際に何をするかによって異なります。他のアプリの性能はわかりません。サーバ。
それが役に立てば幸い。