java - Web サービス (SOA/REST) を実装できる場合でも、EJB を RMI で実装すると便利ですか?

Question

これはこれと似ているように聞こえるかもしれませんが、そうではありません。

私は EJB と RMI をある程度理解しており、しばらくの間 S​​OA の下で Web サービスに取り組んできました。Web サービス (SOA/REST、ただし主に SOA) を公開する代わりに、RMI の下でリモート インターフェイスを公開する EJB を使用して作業することがなぜ便利なのか知りたいです。どちらが優れているかを尋ねているのではなく、Web サービスよりもリモート インターフェイスを使用して EJB を実装する方がよい理由を知りたいだけです。

多くの Web ページを確認しましたが、すべてが古くなっているように見えました。これまでのところ、リモート インターフェイスを公開する EJB は、Java レガシー システムと統合する場合にのみ WS よりも優れているということです。トランザクションを管理したい場合は、EJB をローカル インターフェイスで実装できます。また、RMI ではなく EJB を選択することが、Web サービス インターフェイスよりも効率的だとは思いません。

私は正しいですか？足りないものはありますか？

よろしくお願いします。

Answer 1

次の場合、EJB の方が優れています。

• 1 つのトランザクションで実行する必要がある呼び出しの数を実行する必要があります (理論的には、トランザクション Web サービスがありますが、すべての実装がそれらを提供するわけではありません)。(ステートフル) EJB は、トランザクション管理に関して優れています。ステートフルネスが必要なときはいつでも EJB の方が Web サービスより優れています。
• パフォーマンスが必要 - Web サービスは遅い - HTTP 経由でプッシュされた XML/JSON を使用し、EJB で使用される RMI over IIOP プロトコルはより効率的です。
• Java Web サービスの古い仕様 (醜い Axis 1.0 のもの、JAX-WS と互換性がない) を使用するレガシー システムに接続する必要があります。すべてを Web サービスに接続し、互換性のない WSDL 定義、奇妙な SOAP を処理することは悪夢になる可能性があります。封筒。EJB には後方互換性があり、古い EJB 2 は問題なく EJB 3.1 に接続できます。
• 最新の EJB (EJB 3.X) は、2 つまたは 3 つの単純な注釈を追加することで、インターフェースを JAX-WS SOAP/WSDL サービスまたは JAX-RS REST サービスとして公開できます。

では、なぜ (REST) Web サービスがこれほど人気が​​あるのでしょうか? EJB は、別の Java アプリケーションにのみ接続できます。最新のリッチ インターネット アプリケーションの大半は JavaScript で記述されているため、それらをバックエンドに接続する唯一の方法は、何らかの Web サービス (通常は REST + JSON) を使用することです。そのようなアプリケーションでは、EJB はほとんど役に立ちません。

Answer 2

RMI をワイヤ プロトコルとして使用する場合は、クライアントとサービスの両方を Java で記述する必要があります。

SOAP は XML over HTTP を使用し、REST はクライアントとサービス間の通信に純粋な HTTP を使用します。会話の両端は、HTTP 経由で適切な要求を送信できる任意の言語で記述でき、制限がはるかに少なくなります。

これが、HTTP を介した Web サービスが RMI に勝った理由の 1 つだと思います。いつでもシンプルでオープンな勝利。

Answer 3

それらは異なる目的のための異なるものです。

EJB は、密結合されたN層システム内で使用するためのものであり、すべての要素を制御できます。それらは、通常のメソッド呼び出しのように見えるものを使用して言語で直接コーディングし、IIOP または EE ベンダーが展開した他のプロトコルを介して LAN タイプのパフォーマンスを提供します。

SOAP/REST は、インターネット全体での使用、または B2B や、両端を制御できず、疎結合が必要なその他の状況での使用に最適です。すべての XML が原因でパフォーマンスが大幅に低下しますが、業界標準のプロトコルが途中で使用され、単一ソースの問題に対する両端の保護が提供されます。