jakarta-ee - Web層とビジネス層の間でRMIまたはJMSを使用することの長所と短所は何ですか？

Question

一般的なWebクライアントからサーブレット/WSからビジネス層（SpringまたはEJB）アプリの場合、リモートRPCやWeb（サーブレット）層からリモートビジネス層へのメッセージングなどのアプローチのトレードオフは何ですか？基本的な同期/非同期の側面？

Answer 1

Webクライアントとは、Webブラウザを意味しますか？もしそうなら、DWRやJAX-RSのようなものを見ることは私の推奨事項です。RMIまたはJMSは、両方がJavaコードである場合にのみ実際に機能します。

リモーティングテクノロジーを使用する場合の最大の問題は、テクノロジーがビジネスオブジェクトにどれほど侵入するかということです。たとえば、あらゆる場所でRMIインターフェース/例外を使用したり、ビジネスコード内でJMSAPIを使用したりします。

私の推奨事項は、Javaのあらゆる場所でPOJOを使用してから、Spring Remotingなどのテクノロジーを使用して、RMIやJMSなどのミドルウェアを階層化することです。ただし、ミドルウェアコードをビジネスロジックから完全に切り離して、いつでもテクノロジーを切り替えることができるようにします。 （そして、ビジネスロジックコードをよりシンプルに保ち、ビジネスの問題に焦点を合わせます）。

たとえば、Spring RemotingのCamel実装を参照してください。これにより、RMI、JMS、さらにはプレーンHTTP、電子メール、ファイル、XMPPなどのこれらのトランスポートとプロトコルのいずれかを使用できます。次に、単純なURI文字列の変更を使用してそれらを簡単に切り替えることができます。

Answer 2

Spring経由でRMIを使用しており、非常に使いやすく、かなり堅牢で高速です。私たちの要件はかなりレスポンシブなリンクであり、メッセージングコンポーネントを追加する必要はありませんでした。

Answer 3

SUNRMIが壊れました。

継続的なメッセージングを伴う非常に長時間実行されるアプリケーションの設定とガベージコレクション。継続的に機能するようにパッチを適用しています。私たちが実行するJMSアプリケーションは、RMIが行うメモリ不足エラーやgc問題を取得しません。System.gc（）を定期的に呼び出す必要があり、リソースを回復するためにインクリメンタルコレクションと連携しないものは、正しくコーディングされていません。

RMIの信頼性は、JDK 6と正しいプロパティ設定で向上しますが、JHC、それは厄介なフレームワークです。RMIは、nioでチャネルを使用し、system.gc（）のsunnioの使用を修正することで大幅に改善されます。

正解-ドメインコードからの通信（メカニズム）を分離します。RPCは緊密に結合されており、プロトコルとアプリケーションが相互に干渉する可能性があります。JMSは、プロトコルをアプリケーションから分離します。これは、はるかに優れたパラダイムです。