Javaリモート通信技術と原理分析のグラフィカルな紹介

分散サービス フレームワークでは、最も基本的な問題の 1 つは、リモート サービスがどのように通信するかということです。RMI、MINA、ESB、Burlap、Hessian、SOAP、EJB など、Java 分野でリモート通信を実現できるテクノロジが多数あります。 JMS など、これらの用語の関係とその背後にある原則は何ですか? これらを理解することは、分散サービス フレームワークを実装するための基本知識です。高いパフォーマンス要件がある場合は、これらの背後にあるメカニズムをさらに深く理解してください。テクノロジーは必須です。

1 基本原則

ネットワーク マシン間の通信を実現するには、まずコンピュータ システムのネットワーク通信の基本原則を確認する必要があります。つまり、ネットワーク通信が行う必要があるのは、あるコンピュータから別のコンピュータにストリームを送信することです。コンピュータは、伝送プロトコルとネットワーク IO に基づいて実装されます。その中で、よく知られている伝送プロトコルには、tcp、udp などが含まれます。Tcp と udp はすべて、ソケットの概念に基づいており、特定の種類のアプリケーション シナリオに合わせて拡張されています。 IO には、bio、nio、aio の 3 つの主要な方法があります。すべての分散アプリケーション通信は、アプリケーションの使いやすさを目的として、通常、いくつかのアプリケーション層プロトコルを提供します。アプリケーションに近くなり、使いやすくなります。

2 メッセージ モード

結局のところ、エンタープライズ アプリケーション システムはデータの処理であり、複数のサブシステムを備えたエンタープライズ アプリケーション システムの基本的なサポートは間違いなくメッセージの処理です。

オブジェクトとは異なり、メッセージは本質的にデータ構造です (もちろん、オブジェクトは特別なメッセージとみなすこともできます)。これらのデータは、コンシューマとサービスの両方で処理する必要があります。異なるプロセス (マシン) であり、複数のまったく異なるクライアントによって使用される可能性があります。メッセージングは​​、プラットフォームからの独立性が高く、同時呼び出しや非同期呼び出しを適切にサポートできるため、ファイル受け渡しやリモート プロシージャ コール (RPC) よりも優れていると思われます。

Web サービスと RESTful の場合、メッセージング テクノロジの派生またはカプセル化と見なすことができます。

2.1 メッセージ チャネル モード

図に示すように、私たちがよく使用するメッセージ モードはメッセージ チャネル モードです。

メッセージ チャネルは、クライアント (コンシューマー) とサービス (プロデューサー) の間に導入される間接層として、この 2 つを効果的に分離できます。双方が通信する必要があるメッセージ形式、およびメッセージを処理するメカニズムとタイミングが実装されている限り、コンシューマはプロデューサについて「知らなくても」かまいません。

実際、このモデルは複数のプロデューサーとコンシューマーをサポートできます。たとえば、複数のプロデューサーがメッセージ チャネルにメッセージを送信できるようにすることができます。コンシューマーはプロデューサーを認識しないため、どのプロデューサーがメッセージを送信したかを考慮する必要がありません。

メッセージ チャネルはプロデューサーとコンシューマを切り離し、プロデューサーとコンシューマを任意に拡張できるようにしますが、チャネル リソースの位置を知っている必要があるため、それぞれがメッセージ チャネルに依存することになります。このチャネルへの依存を軽減するには、チャネル リソースを見つけるための Lookup サービスの導入を検討できます。たとえば、JMS では、JNDI を通じてメッセージ チャネル キューを取得できます。完全な柔軟性を実現するために、チャネル関連の情報を構成ファイルに保存できます。Lookup サービスは、まず構成ファイルを読み取ることでチャネルを取得します。

メッセージ チャネルは通常、キューの形式で存在します。この先入れ先出しデータ構造は、間違いなくこのメッセージ処理シナリオに最適です。 Microsoft の MSMQ、IBM MQ、JBoss MQ、オープン ソースの RabbitMQ、および Apache ActiveMQ はすべて、キューを通じてメッセージ チャネル モードを実装しています。したがって、メッセージ チャネル モデルの使用を選択する場合は、品質特性の観点から、このモデルを実装するさまざまな製品の包括的な分析とトレードオフを実行することがより必要になります。たとえば、メッセージ チャネルの同時実行性とパフォーマンスのサポート、メッセージ チャネルのエラー処理のサポート、メッセージの永続性、災害復旧 (フェールオーバー)、クラスタリングのサポートなどです。

チャネルによって送信されるメッセージは重要なビジネス データであることが多いため、チャネルが障害点またはセキュリティ ブレークスルー ポイントになると、システムに壊滅的な影響を及ぼします。

jndi のメカニズムについてもここで説明します。JNDI は特定の実装に依存するため、ここでは jboss の jndi の実装についてのみ説明します。

オブジェクト インスタンスを jboss jnp サーバーにバインドした後、リモート エンドがcontext.lookup() を使用してリモート オブジェクト インスタンスを取得し、呼び出しを開始します。jboss jndi の実装方法は、jnp サーバーからオブジェクト インスタンスを取得し、それをシリアル化してローカルに戻し、次にローカルで逆シリアル化して、クラス呼び出しを行うことです。地元で。

このメカニズムを通じて、ローカル クラスが jboss 上のオブジェクト インスタンスにバインドされている必要があることがわかります。そうしないと、デシリアライゼーション中に確実に失敗し、リモート通信はリモートで実行する必要があります。特定のアクションとそれに対応する結果が得られます。リモート通信は純粋に JNDI に基づいて実現できないことがわかります。

しかし、JNDI は、ejb と同様に、透過的なリモート呼び出しとローカル呼び出しを実現するために使用できるため、分散サービス フレームワークを実装する際の重要な技術ポイントでもあります。また、( datasource と同様に) 実際のデプロイメント メカニズムを隠すのにも適しています。他の計画。

2.2 パブリッシャー/サブスクライバー モデル

メッセージ チャネルが複数のコンシューマーをサポートする必要がある場合、プル モデルとプッシュ モデルの 2 つのモデルの選択に直面する可能性があります。プル モデルはメッセージのコンシューマによって開始され、主導権はコンシューマの手にあり、コンシューマは自身の状況に応じてプロデューサへの呼び出しを開始します。図に示すように:

プル モデルの別の実施形態は、状態が変化したときに、プロデューサーがその状態が変化したことをコンシューマーに通知することです。ただし、通知されたコンシューマは、コールバックを使用して、渡されたコンシューマ オブジェクトを呼び出すことで、より詳細な情報を取得します。

メッセージベースの分散システムでは、プル モデルのコンシューマーは通常、バッチ ジョブの形式で、事前に設定された時間間隔に従って定期的にチャネル ステータスをリッスンします。メッセージが渡されたことが判明すると、そのメッセージは実際のプロセッサ (コンシューマともみなされる) に転送され、メッセージを処理し、関連サービスを実行します。

モデルを推進する主導権は多くの場合プロデューサーの手にあり、消費者はプロデューサーからの通知を受動的に待ちます。そのためにはプロデューサーが消費者の関連情報を知る必要があります。図に示すように:

プッシュ モデルの場合、コンシューマはプロデューサを知る必要はありません。プロデューサがコンシューマに通知する場合、多くの場合、プロデューサ自体ではなく、メッセージ (またはイベント) が配信されます。同時に、プロデューサーは、さまざまな状況に応じてさまざまなコンシューマを登録したり、カプセル化された通知ロジックのさまざまなステータス変化に応じてさまざまなコンシューマに通知したりすることもできます。

どちらのモデルにも独自の利点があります。プル モデルの利点は、消費者をチャネルへの依存からさらに解放し、バックグラウンド タスクを通じてメッセージ チャネルに定期的にアクセスできることです。欠点は、別のサービス プロセスを導入し、スケジュールの形式で実行する必要があることです。プッシュ モデルの場合、メッセージ チャネルは実際に消費者監視の対象となり、メッセージが検出されると、消費者はメッセージを処理するように通知されます。

プッシュ モデルかプル モデルに関係なく、メッセージ オブジェクトについては、オブザーバー モデルと同様のメカニズムを使用して、プロデューサーへのコンシューマ サブスクリプションを実装することができるため、このメカニズムは、図に示すように、パブリッシャー-サブスクライバー モデル と呼ばれることがよくあります。表現:

通常、パブリッシャーとサブスクライバーは、変更を伝播するために使用されるインフラストラクチャ (つまり、メッセージ チャネル) に登録されます。パブリッシャはメッセージ チャネルを積極的に理解して、チャネルにメッセージを送信できるようにします。メッセージ チャネルがメッセージを受信すると、チャネルに登録されているサブスクライバを積極的に呼び出して、メッセージ コンテンツの消費を完了します。

購読者の場合、メッセージを処理する方法は 2 つあります。

1 つの方法は、ブロードキャスト メカニズムです。現時点では、メッセージ チャネル内のメッセージがキューから取り出されるときに、メッセージを複数のサブスクライバーに配信するためにメッセージ オブジェクトもコピーする必要があります。たとえば、CRM システムから顧客情報を取得し、渡された顧客情報に基づいて対応する処理を実行する必要があるサブシステムが複数あります。このときのメッセージチャネルを伝播チャネルともいいます。 もう 1 つの方法は、同期方法に従うプリエンプション メカニズムであり、同時に 1 つのサブスクライバーのみがメッセージを処理できます。パブリッシャ/サブスクライバ パターンを実装するメッセージ チャネルは、現在アイドル状態のサブスクライバのみを選択し、メッセージをデキューして、サブスクライバのメッセージ処理メソッドに渡します。 現在、JMS インターフェイス仕様の Topic オブジェクトに提供される MessagePublisher インターフェイスや MessageSubscriber インターフェイスなど、パブリッシャー/サブスクライバー パターンを適切にサポートできるメッセージ ミドルウェアが多数あります。

RabbitMQ は、このパターンの独自の実装も提供します

。 Microsoft の MSMQ はイベント メカニズムを導入していますが、キューがメッセージを受信したときにサブスクライバーに通知するイベントをトリガーできます。ただし、厳密にはパブリッシャーとサブスクライバーのパターンの実装ではありません。 Microsoft MVP Udi Dahan を主な貢献者とする NServiceBus は、MSMQ と WCF をさらにパッケージ化し、このモデルを適切に実装できます。

2.3 メッセージ ルーター モード

メッセージ チャネル モードであっても、パブリッシャー/サブスクライバー モードであっても、キューは重要な役割を果たします。ただし、エンタープライズ アプリケーション システムでは、システムがますます複雑になるにつれて、パフォーマンス要件もますます高くなり、複数のキューの同時展開をサポートする必要が生じ、異なるキューの展開が必要になる場合があります。 。これらのキューは、注文処理メッセージ、ログ情報、クエリ タスク メッセージなど、定義に従ってさまざまなメッセージを受信できます。現時点では、メッセージのプロデューサとコンシューマがメッセージ配信パスを決定する責任を負うことは適切ではありません。実際、S の単一責任の原則によれば、この種の責任の割り当ても不合理であり、ビジネス ロジックの再利用には役に立たず、プロデューサー、コンシューマー、メッセージ キュー間の結合も引き起こし、その結果、メッセージ キューの拡張に影響を及ぼします。システム。

これら 3 種類のオブジェクト (コンポーネント) はそのような役割を担うのに適していないため、パス選択を配信する機能を特に担う新しいオブジェクトを導入する必要があります。これがいわゆるメッセージ ルーター モード です。図に示すように:

メッセージ ルーティングを通じて、メッセージ配信のパスを指定するルーティング ルールを構成し、特定の消費者消費に対応するプロデューサーを指定できます。たとえば、routing キーワードを指定し、それを使用して特定のキューを指定のプロデューサー (またはコンシューマー) にバインドします。ルーティングのサポートは、メッセージの配信と処理に柔軟性をもたらし、システム全体のメッセージ処理能力の向上にも役立ちます。同時に、ルーティング オブジェクトは、メッセージ、キュー、パス アドレス指定の間の関係を調整する役割を担うメディエーター (Meditator) と同様に、メッセージ パスを検索して照合するロジックを効果的にカプセル化します。

3 アプリケーション レベルのプロトコル

リモート サービス通信。達成する必要がある目標は、1 台のコンピューターでリクエストを開始し、別のマシンがリクエストを受信した後にそれを処理し、結果をリクエスト側に返すことです。リクエストメソッドには、一方向リクエスト、同期リクエスト、非同期リクエストなどがあります。ネットワーク通信の原理によれば、これを達成するために必要なのは、リクエストをストリームに変換してリモートエンドに送信することだけです。リモート コンピュータは、要求されたストリームを処理後、ストリームに変換し、送信プロトコルを通じて呼び出し側に返します。

原理はこのようなものですが、アプリケーションの利便性を考慮して、業界はこの原則に基づいて多くのアプリケーションレベルのプロトコルを立ち上げており、通常はアプリケーションレベルのリモート通信を誰もが直接操作する必要がありません。プロトコルは以下を提供します:

1. ストリーム操作を直接実行する際の問題を回避するために、より使いやすい、または言語に適合する標準の送信形式を提供します。

2. ネットワーク通信メカニズムの実装は完了する必要があります。送信形式をストリームに変換すること。ストリームを受信した後、リモート コンピュータはストリームを送信形式に変換して保存するか、何らかの方法でリモート コンピュータに通知します。 。

したがって、アプリケーションレベルのリモート通信プロトコルを学習するときは、次の質問をしながら学ぶことができます:

1. 送信の標準フォーマットは何ですか?

2. リクエストを送信ス​​トリームに変換するにはどうすればよいですか?

3. ストリームを受信して​​処理するにはどうすればよいですか?

4. 送信プロトコルとは何ですか?

ただし、アプリケーションレベルのリモート通信プロトコルは、主にストリーム操作の点で改善されず、アプリケーション層でのストリームの生成と処理のプロセスが、使用される言語により適したものになります。または、送信プロトコルに関しては、通常はオプションです。Java 分野でよく知られているものは、RMI、XML-RPC、Binary-RPC、SOAP、CORBA、JMS、HTTP です。これらのリモート通信アプリケーションのレベル合意。

3.1 RMI (Remote Method Invocation)

RMI は、Java 用にカスタマイズされた典型的なリモート通信プロトコルであり、リモート通信中に、Java オブジェクト インスタンスを直接呼び出すことで通信を実現できることは誰もが知っています。この方法に従うことができれば最高です。このリモート通信メカニズムが RPC (Remote Procedure Call) となり、この目標に向けて RMI が誕生しました。

RMI はスタブとスケルトンを使用してリモート オブジェクトと通信します。スタブはリモート オブジェクトのクライアント プロキシとして機能し、リモート オブジェクトと同じリモート インターフェイスを持ちます。リモート オブジェクトへの呼び出しは、このメカニズムを通じて、オブジェクトのクライアント プロキシ オブジェクト スタブを呼び出すことによって完了します。これはローカル ジョブであるため、クライアントはサーバー上のいくつかのメソッドを直接呼び出します。利点は、厳密に型指定されており、コンパイル中にエラーをチェックできることです。欠点は、JAVA 言語のみに基づいており、クライアントとサーバーが密接に結合されていることです。

RMI に基づく完全なリモート通信プロセスの原理を見てみましょう:

1. クライアントがリクエストを開始し、リクエストは RMI クライアントのスタブ クラスに転送されます。スタブ クラスは、要求されたインターフェイス、メソッド、パラメーター、およびその他の情報をシリアル化して転送します。

2. ソケットに基づいてシリアル化されたストリームをサーバーに送信します。

3. サーバーはストリームを受信し、対応するスケルトンクラスに転送します。

4. スケルトンクラスは、要求された情報を逆シリアル化し、実際の処理クラスを呼び出します。

5. 処理クラスが処理を完了すると、結果が返されます。スケルトン クラス;

6. スケルトン クラスは結果をシリアル化し、ソケット経由でストリームをクライアントのスタブに送信します。

7. スタブはストリームを受信した後に逆シリアル化し、逆シリアル化された Java オブジェクトを呼び出し元に返します。

原則に基づいて、以前にアプリケーションレベルのプロトコルを学習する際に生じたいくつかの質問に答えてみましょう:

1. 送信の標準形式は何ですか? は Java ObjectStream です。

2. リクエストを送信ス​​トリームに変換するにはどうすればよいですか? 要求された Java オブジェクト情報を Java シリアル化メカニズムに基づいてストリームに変換します。

3. ストリームを受信して​​処理するにはどうすればよいですか? ストリームが入力されると、Java シリアル化メカニズムに基づいて、対応するリスニング ポートを開始し、RMI プロトコルに従って、対応する処理オブジェクト情報を取得し、呼び出して処理します。 , 結果は、Java シリアル化メカニズムに基づいて返されます。

4. 送信プロトコルとは何ですか? ソケット。

3.2 XML-RPC

RPCはC/Sモードを使用し、httpプロトコルを採用し、サーバーにリクエストを送信し、サーバーが結果を返すのを待ちます。リクエストにはパラメータ セットとテキスト セットが含まれており、通常は「クラス名.メソッド名」の形式になります。利点は、クロス言語およびクロスプラットフォームであり、C 側と S 側の独立性が高いことです。欠点は、オブジェクトをサポートしておらず、コンパイラでエラーをチェックできず、チェックできることだけです。実行時。

XML-RPC も RMI と同様のリモート呼び出しプロトコルです。RMI との違いは、要求された情報 (要求されたオブジェクト、メソッド、パラメーターなど) を標準の XML 形式で定義することです。言語を越えたコミュニケーションにも使用できます。

XML-RPC プロトコルのリモート通信プロセスを見てみましょう:

1. クライアントはリクエストを開始し、XML-RPC プロトコルに従ってリクエスト情報を入力します。

2. 入力が完了したら、 XML はストリームに変換され、送信用のトランスポート プロトコル

3. がストリームを受信して​​ XML に変換し、要求された情報を取得して XML-RPC プロトコルに従って処理します。処理が完了すると、XML-RPC プロトコルに従って結果が XML に書き込まれて戻ります。

4. 同様の質問に答えてください:

送信の標準フォーマットは何ですか?

標準形式の XML。

1. リクエストを送信ス​​トリームに変換するにはどうすればよいですか?
XML をストリームに変換します。

2. ストリームを受信して​​処理するにはどうすればよいですか?
リスニングポート経由で要求されたストリームを取得し、XML に変換し、プロトコルに従って要求された情報を取得し、それを処理し、結果を XML に書き込んで返します。

3. 送信プロトコルとは何ですか?
http.

4. 3.3 Binary-RPC

名前からわかるように、Binary-RPC は XML-RPC に似ていますが、唯一の違いは、送信の標準形式が XML からバイナリ形式に変換されることです。

同様に、次の質問にも答えてください:

送信の標準フォーマットは何ですか?

標準形式のバイナリ ファイル。

1. リクエストを送信ス​​トリームに変換するにはどうすればよいですか?
バイナリ形式のファイルをストリームに変換します。

2. ストリームを受信して​​処理するにはどうすればよいですか?
要求されたストリームをリスニングポート経由で取得し、バイナリファイルに変換し、プロトコルに従って要求された情報を取得し、それを処理し、結果を XML に書き込んで返します。

3. 送信プロトコルとは何ですか?
http.

4. 3.4 SOAP

   SOAP は、元々は Simple Object Access Protocol を意味し、分散環境向けの XML に基づいた情報交換のための軽量な通信プロトコルであり、SOAP は XML RPC の発展版であると考えることができます。両者はまったく同じであり、両方とも http+XML です。唯一の違いは、この 2 つによって定義された XML 仕様が Webservice で採用されているサービス呼び出しプロトコル標準でもあることです。そのため、ここではこれ以上詳しく説明しません。

Web サービスによって提供されるサービスは、Web コンテナーに基づいており、天気予報サービスなどのリモート サービス プロバイダーに似ています。要求応答メカニズムであり、クロスシステム、クロスプラットフォームです。サービスはサーブレットを通じて提供されます。

まず、クライアントはサーバーからWebServiceのWSDLを取得すると同時に、クライアント上でWebServiceサーバーとのリクエストとレスポンスを担当するプロキシクラス(Proxy Class)を生成します。データ（XML形式）をSOAP形式のデータストリームにカプセル化してサーバに送信すると、プロセスオブジェクトが生成され、Requestで受信したSOAPパケットが解析されて処理されます。処理が完了すると、計算結果は SOAP にラップされ、クライアントのプロキシ クラス (Proxy Class) に応答として送信されます。同様に、プロキシ クラスも SOAP パッケージを解析し、以降の操作を実行します。これはWebServiceの実行プロセスです。

Webサービスは一般に5つのレベルに分かれています:

1. Http 伝送チャネル;

2. SOAP カプセル化フォーマット;

3. UDDI は、ディレクトリ サービスです。企業は登録と検索を使用できますWebサービス;

4. 3.5 JMS

JMSは、Java分野でリモート通信を実現するための手段および方法です。ただし、RPCの効果は得られません。プロトコルレベルで定義すると、JMS は RPC プロトコルであるとは考えられませんが、実際には、他の言語システムにも JMS と同様のメカニズムがあり、この種のメカニズムを一律にメッセージメカニズムと呼ぶことができます。メッセージ メカニズムは通常、同時実行性の高い分散フィールドで推奨される通信メカニズムです。ここでの主な問題はフォールト トレランスです。

5. JMS は Java メッセージ サービスであり、JMS クライアントは JMS サービスを通じて非同期メッセージを送信できます。

   JMS は、ポイントツーポイント (P2P) とパブリッシュ/サブスクライブ (Pub/Sub)、つまりポイントツーポイント モデルとパブリッシュ/サブスクライブ モデルの 2 つのメッセージ モデルをサポートします
。

JMS でのリモート通信のプロセスを見てみましょう:

クライアントはリクエストを JMS 規制に準拠したメッセージに変換します

JMS API を通じてメッセージを JMS キューまたはトピックに置きます。 ;

1. JMS キューの場合は、対応するターゲット キューに送信され、トピックの場合は、このトピックにサブスクライブされた JMS キューに送信されます。

2. 処理側は、メッセージを受信した後、JMS キューをローテーションしてメッセージを取得し、JMS プロトコルに従ってメッセージを処理します。

3. 同様の質問に答えてください:

4. 送信の標準フォーマットは何ですか?
JMSで指定されたメッセージ。

リクエストを送信ス​​トリームに変換するにはどうすればよいですか?
1. パラメータ情報をメッセージに入力します。

ストリームを受信して​​処理するにはどうすればよいですか?
2. JMS キューは、メッセージを受信するためにローテーションでトレーニングされ、処理が完了した後も、送信またはマルチキャスト用のメッセージの形式でキューに入れられます。

送信プロトコルとは何ですか?
3. 制限はありません。

JMS に基づいており、リモート非同期呼び出しを実装するために一般的に使用されるメソッドの 1 つでもあります。

4. 4

   4.1 RPC と RMI

RPC の違いはクロスランゲージですが、RMI は Java のみをサポートします。

RMI はリモート オブジェクト メソッドを呼び出し、メソッドが Java オブジェクトと基本データ型を返すことを可能にしますが、RPC サービスに送信されるメッセージは外部データ表現 (XDR) 言語によって表されます。エンディアン クラスとデータ型構造の違いを抽象化します。 XDR で定義されたデータ型のみを渡すことができます。RMI はオブジェクト指向の Java RPC であると言えます。

1. RMI のメソッド呼び出しでは、リモート インターフェイスにより各リモート メソッドがメソッド シグネチャを持つことが可能になります。メソッドがサーバー上で実行されても、一致する署名がリモート インターフェイスに追加されない場合、RMI クライアントは新しいメソッドを呼び出すことができません。 RPC では、リクエストが RPC サーバーに到着すると、リクエストにはパラメータ セットとテキスト値が含まれており、通常は「クラス名.メソッド名」の形式になります。これは、要求されたメソッドが「methodname」という名前のクラスにあることを RPC サーバーに示します。次に、RPC サーバーは一致するクラスとメソッドを検索し、それをそのメソッド パラメーター タイプの入力として使用します。ここでのパラメータのタイプは、RPC リクエストのタイプと一致します。一致が成功すると、このメソッドが呼び出され、結果がエンコードされてクライアントに返されます。

2. RPC 自体には仕様はありませんが、基本的な動作メカニズムは同じです。つまり、シリアル化/逆シリアル化 + スタブ + スケルトンです。大まかに言えば、リモート呼び出しが実現できる限り、それは RPC です (例: rmi )。 net-remoting ws /soap/rest hessian xmlrpc thrift potocolbuffer。

3. Java は完全なソケット通信インターフェイスを提供しますが、ソケットを使用するには、クライアントとサーバーがアプリケーション レベルのプロトコルを使用してデータをエンコードして交換する必要があります。ソケットの使用は非常に面倒です。ソケットに代わるプロトコルは RPC (リモート プロシージャ コール) です。これはプロシージャ呼び出しの通信インターフェイスを抽象化し、プログラマにとってローカル プロシージャを呼び出すのと同じくらいリモート プロシージャを呼び出すのに便利です。 RPC システムは、XDR を使用してリモート呼び出しのパラメーターと戻り値をエンコードします。ただし、RPC はオブジェクトをサポートしていないため、オブジェクト指向のリモート呼び出し RMI (Remote Method Invocation) が必然の選択となっています。 RMI を使用すると、リモート オブジェクトの呼び出しはローカル オブジェクトの呼び出しと同じくらい便利です。 RMI は、TCP/IP プロトコルに基づいて構築されたリモート呼び出しメソッドである JRMP (Java Remote Method Protocol) 通信プロトコルを使用します。

4. 4.2 JMS と RMI

5. JMS サービスを使用すると、オブジェクトはネットワーク上の JVM から別の JVM に直接非同期で物理的に移動され (メッセージ通知メカニズム)、RMI オブジェクトはローカル JVM にバインドされます。関数のパラメータと戻り値のみがネットワーク経由で送信されます (要求応答メカニズム)。

6. RMI は一般に同期です。つまり、クライアントがサーバーのメソッドを呼び出すとき、クライアントの実行を続行するには、相手が戻るまで待つ必要があります。このプロセスは、ローカルのメソッドを呼び出すのと同じように感じられます。これもRMIの特徴です。 JMS は通常、メッセージを 1 つのポイントからメッセージ サーバーに送信するだけで、送信後はメッセージを誰が使用するかを気にしません。したがって、一般に RMI アプリケーションは密結合されているのに対し、JMS アプリケーションは比較的疎結合です。

4.3 WebサービスとRMI

RMIは、TCPプロトコルを介してシリアル化可能なJavaオブジェクトを転送します。バインディング言語、クライアント、およびサーバーはJavaである必要があります。 Web サービスには、言語やプラットフォームに関係なく、http プロトコルを介して XML テキスト ファイルを送信します。

4.4 WebサービスとJMS

Webサービスはリモートサービスの呼び出しに重点を置き、jmsは情報交換に重点を置きます。

ほとんどの場合、Web サービスは 2 つのシステム (コンシューマー プロデューサー) 間の直接の対話ですが、ほとんどの場合、jms は 3 者間システムの対話 (コンシューマー プロデューサー) です。もちろん、コンシューマまたはプロデューサのいずれかがブローカとしても機能する限り、JMS はリクエスト/レスポンス モードの通信を実装することもできます。

JMS は、クライアントとサービス プロバイダーを完全に分離する非同期呼び出しを実現でき、トラフィックのピークに耐えることができます。WebService サービスは通常、同期的に呼び出され、SOAP と比較して、JSON と REST は非常に優れた http アーキテクチャ ソリューションです。

JMS は Java プラットフォーム上のメッセージ仕様です。一般に、jms メッセージは XML ではなく、Java オブジェクトです。明らかに、jms は異種システムを考慮しません。率直に言えば、JMS は Java 以外のものを考慮しません。しかし幸いなことに、ほとんどの JMS プロバイダ (つまり、JMS のさまざまな実装製品) は異種混合の問題を解決しています。 WebService のクロスプラットフォームと比較すると、それぞれに独自のメリットがあります。

5 オプションの実装テクノロジ

現在、Java フィールドを使用して、リモート通信用のフレームワークまたはライブラリを実装できます。よく知られているものは、JBoss-Remoting、Spring-Remoting、Hessian、Burlap、XFire (Axis)、ActiveMQ です。 、Mina、Mule、EJB3 待って、それぞれの簡単な紹介と評価をしましょう。実際、分散サービス フレームワークには次のようなソリューションが含まれているため、分散サービス フレームワークを構築するには、これらのことを非常に深く理解する必要があります。分散フィールドとアプリケーション レベル フィールドの 2 つの側面。

もちろん、リモートネットワーク通信原理(トランスポートプロトコル+Net IO)に基づいた独自の通信フレームワークまたはライブラリを実装することもできます。

では、これらのリモート通信フレームワークやライブラリを理解するとき、どのような質問をして勉強しますか?

1. どのプロトコルに基づいていますか?

2. リクエストを開始するにはどうすればよいですか?

3. リクエストをプロトコルに準拠した形式に変換するにはどうすればよいですか?

4. 送信にはどのような送信プロトコルが使用されますか?

5. レスポンダーはリクエストを受信するためにどのようなメカニズムを使用しますか?

6. ストリームをトランスポート形式に復元するにはどうすればよいですか?

7. 処理後の対応方法は？

5.1 Spring-Remoting

Spring-remoting は Java 分野で Spring によって提供されるリモート通信フレームワークであり、このフレームワークに基づいて、通常の Spring Bean を特定のリモート プロトコルで公開することも非常に簡単です。リモートで呼び出される Bean として構成されます。

1. どのプロトコルに基づいていますか? リモート通信フレームワークとして、Spring は複数のリモート通信ライブラリを統合して、rmi、http+io、xml-rpc、binary-rpc などの複数のプロトコルをサポートします。

2. リクエストを開始するにはどうすればよいですか? Spring では、リモート呼び出し Bean にプロキシ実装を使用するため、リクエストは完全にサービス インターフェイス呼び出しを通じて開始されます。

3. リクエストをプロトコルに準拠した形式に変換するにはどうすればよいですか? Springはリクエストされたオブジェクト情報をプロトコルに従ってストリームに変換します。例えば、Spring Http InvokerはSpring自身が定義したプロトコルに基づいて実装されており、送信プロトコルはhttpであり、リクエスト情報はそれに基づいてストリームに変換されます。 Java シリアル化メカニズムを使用して転送を行います。

4. 送信にはどのような送信プロトコルが使用されますか? rmi、httpなどの複数の送信プロトコルをサポートします。

5. レスポンダーはリクエストを受信するためにどのようなメカニズムを使用しますか? レスポンダーはプロトコルに従ってリクエストを受信します。ユーザーは、Spring 設定メソッドを通じて通常の Spring Bean をレスポンダーまたはサーバーとして設定するだけで済みます。

6. ストリームをトランスポート形式に復元するにはどうすればよいですか? プロトコルに従って復元します。

7. 処理後の対応方法は？ 処理が完了したら直接返すだけで、spring-remoting はプロトコルメソッドに従って対応するシリアル化を実行します。

5.2 Hessian

Hessian は、caucho が提供するバイナリ RPC に基づくリモート通信ライブラリです。

1. どのプロトコルに基づいていますか? Binary-RPC プロトコルに基づいて実装されています。

2. リクエストを開始するにはどうすればよいですか? リクエストは、Hessian 自体が提供する API を通じて開始する必要があります。

3. リクエストをプロトコルに準拠した形式に変換するにはどうすればよいですか? Hessian は、カスタム シリアル化メカニズムを通じてリクエスト情報をシリアル化し、バイナリ ストリームを生成します。

4. 送信にはどのような送信プロトコルが使用されますか? ヘシアンはHTTPプロトコルに基づいて送信します。

5. レスポンダーはリクエストを受信するためにどのようなメカニズムを使用しますか? レスポンダーは、Hessian が提供する API に基づいてリクエストを受信します。

6. ストリームをトランスポート形式に復元するにはどうすればよいですか? Hessian は、プライベートなシリアル化メカニズムに従ってリクエスト情報を逆シリアル化し、ユーザーに渡される時点では、すでに対応するリクエスト情報オブジェクトになっています。

7. 処理後の対応方法は？ 処理後に直接戻り、ヘッセ行列は結果オブジェクトをシリアル化して呼び出し側に送信します。

5.3 Burlap

Burlap も caucho によって提供されます。hessian との違いは、XML-RPC プロトコルに基づいていることです。

1. どのプロトコルに基づいていますか? XML-RPCプロトコルに基づいて実装されています。

2. リクエストを開始するにはどうすればよいですか? Burlap が提供する API に基づいています。

3. リクエストをプロトコルに準拠した形式に変換するにはどうすればよいですか? リクエスト情報をプロトコルに準拠したXML形式に変換し、ストリームに変換して送信します。

4. 送信にはどのような送信プロトコルが使用されますか? HTTPプロトコル。

5. レスポンダーはリクエストを受信するためにどのようなメカニズムを使用しますか? HTTPリクエストをリッスンします。

6. ストリームをトランスポート形式に復元するにはどうすればよいですか? XML-RPCプロトコルに従って復元します。

7. 処理後の対応方法は？ 返された結果は XML で記述され、Burlap によって呼び出し側に返されます。

5.4 XFire、Axis

XFire と Axis は Webservice の実装フレームワークであり、WebService は完全な SOA アーキテクチャ実装標準と見なすことができるため、XFire と Axis を使用することは Webservice を使用することを意味します。

1. どのプロトコルに基づいていますか? SOAPプロトコルに基づいています。

2. リクエストを開始するにはどうすればよいですか? リモートサービスのプロキシを取得後、直接呼び出します。

3. リクエストをプロトコルに準拠した形式に変換するにはどうすればよいですか? リクエスト情報をSOAPプロトコルに従ったXML形式に変換し、フレームワークで送信するためのストリームに変換します。

4. 送信にはどのような送信プロトコルが使用されますか? HTTPプロトコル。

5. レスポンダーはリクエストを受信するためにどのようなメカニズムを使用しますか? HTTPリクエストをリッスンします。

6. ストリームをトランスポート形式に復元するにはどうすればよいですか? SOAP プロトコルに従って復元します。

7. 処理後の対応方法は？ 戻り結果は XML で記述され、フレームワークによって呼び出し側に返されます。

5.5 ActiveMQ

ActiveMQはJMSの実装です。結局のところ、メッセージ機構自体の機能によって同期/非同期の実装が容易になります。 /single 通信に基づく直接呼び出しなど、およびメッセージ メカニズムもフォールト トレランスの観点からは良い選択です。これは、Erlang がフォールト トレランスを実現できるための重要な基盤です。

1. どのプロトコルに基づいていますか? JMSプロトコルに基づいています。

2. リクエストを開始するにはどうすればよいですか? JMS APIに従ってリクエストを開始します。

3. リクエストをプロトコルに準拠した形式に変換するにはどうすればよいですか? よくわかりませんが、バイナリ ストリームだと思います。

4. 送信にはどのような送信プロトコルが使用されますか? ソケット、httpなどの複数の送信プロトコルをサポートします。

5. レスポンダーはリクエストを受信するためにどのようなメカニズムを使用しますか? プロトコルに準拠するポートをリッスンします。

6. ストリームをトランスポート形式に復元するにはどうすればよいですか? 質問3と同じ。

7. 処理後の対応方法は？ JMS API に従ってメッセージを生成し、JMS キューに書き込みます。

5.6 mina

mina は Apache によって提供される通信フレームワークです。これまでに述べたフレームワークやライブラリは基本的に BIO に基づいており、同時実行量が増加する場合には、mina が NIO を使用します。 BIO と比較してパフォーマンスが大幅に向上し、Java のパフォーマンスの向上は NIO と OS の密接な統合に密接に関係しています。

1. どのプロトコルに基づいていますか? 純粋なソケット+NIOに基づいています。

2. リクエストを開始するにはどうすればよいですか? Mina が提供するクライアント API 経由。

3. リクエストをプロトコルに準拠した形式に変換するにはどうすればよいですか? Mina は Java シリアル化メカニズムに従ってリクエスト オブジェクトをシリアル化します。

4. 送信にはどのような送信プロトコルが使用されますか? ソケット、httpなどの複数の送信プロトコルをサポートします。

5. レスポンダーはリクエストを受信するためにどのようなメカニズムを使用しますか? NIO モードでプロトコル ポートをリッスンします。

6. ストリームをトランスポート形式に復元するにはどうすればよいですか? Java シリアル化メカニズムに従って、リクエスト オブジェクトを逆シリアル化します。

7. 処理後の対応方法は？ 返品についてはMina APIをフォローしてください。

MINA は NIO なので、非同期呼び出しをサポートするのは当然のことです。

6 RPC フレームワークの開発と現状

RPC (Remote Procedure Call) は、簡単に言うと、アプリケーションがローカル メソッドを呼び出すのと同じようにリモート プロシージャやサービスを呼び出すことができるようにするプロトコルです。サービス、分散コンピューティング、リモート サービス呼び出し、その他多くのシナリオ。 RPC について言えば、業界には Dubbo、Thrift、gRPC、Hprose などの優れたオープンソース RPC フレームワークが数多く存在します。 RPC の特徴と一般的なリモート呼び出し方法、および優れたオープンソース RPC フレームワークをいくつか紹介します。

RPC 他のリモート呼び出し方法と比較すると、RPC、HTTP、RMI、Web サービスはすべてリモート呼び出しを完了できますが、実装方法と焦点が異なります。

6.1 RPC と HTTP

HTTP (HyperText Transfer Protocol) は、標準セマンティクスを使用して指定されたリソース (画像、インターフェースなど) にアクセスするアプリケーション層通信プロトコルであり、ネットワーク内の転送サーバーはプロトコルの内容を識別できます。 。 HTTP プロトコルは、リモート要求を完了して要求結果を返すためのリソース アクセス プロトコルです。

HTTP には、シンプルさ、使いやすさ、強力な理解性、および言語に依存しないという利点があり、Weibo を含むリモート サービス コールで広く使用されています。 HTTP の欠点は、プロトコル ヘッダーが重く、一般的なリクエストと特定のサーバー間のリンクが長いことであり、これには DNS 解決や Nginx プロキシなどが含まれる場合があります。

RPC はプロトコル仕様であり、HTTP は RPC の実装とみなすことも、HTTP を RPC の送信プロトコルとして適用することもできます。 RPC サービスは自動化の度合いが比較的高く、強力なサービス管理機能を実現でき、言語と組み合わせるとより使いやすく、優れたパフォーマンスを発揮します。 HTTP と比較すると、RPC の欠点は、比較的複雑であり、学習コストが若干高いことです。

6.2 RPC と RMI

RMI (リモート メソッド呼び出し) は、Java 言語でのリモート メソッド呼び出しを指します。RMI クライアントとサーバーは、メソッド シグネチャを通じてリモート メソッド呼び出しを実行します。 RMI は Java 言語でのみ使用できます。RMI はオブジェクト指向の Java RPC と考えることができます。

6.3 RPC と Web サービス

Web サービスは、サービスの管理と使用に焦点を当て、Web に基づいてサービスを公開、クエリ、および呼び出すためのアーキテクチャ方法です。 Web サービスは通常、WSDL を通じてサービスを記述し、SOAP を使用して HTTP を通じてサービスを呼び出します。

RPC はリモート アクセス プロトコルですが、Web サービスは RPC を通じてサービス呼び出しを行うこともできるアーキテクチャであるため、同じ RPC フレームワークとの比較には Web サービスの方が適しています。 RPC フレームワークがサービスの検出と管理を提供し、送信プロトコルとして HTTP を使用する場合、それは実際には Web サービスです。

Web サービスと比較して、RPC フレームワークは、フロー制御、SLA 管理などを含む、よりきめ細かいサービスのガバナンスを実行でき、マイクロサービスや分散コンピューティングにおいて大きな利点があります。

RPC は HTTP または TCP プロトコルに基づくことができます。Web サービスは HTTP プロトコルに基づく RPC ですが、そのパフォーマンスは TCP プロトコルに基づく RPC ほど良くありません。 RPC のパフォーマンスに直接影響する側面は 2 つあり、1 つは送信方法、もう 1 つはシリアル化です。

ご存知のとおり、TCP はトランスポート層のプロトコルであり、HTTP はアプリケーション層のプロトコルであり、データ送信に関しては、トランスポート層はアプリケーション層よりも下位であるため、一般に、下位層ほど高速になります。 , TCP は HTTP よりも高速である必要があります。

7 まとめ

リモート通信の分野には、次のような非常に多くの知識が含まれています: 通信プロトコル (Socket/tcp/http/udp/rmi/xml-rpc など)、メッセージメカニズム、ネットワーク IO (BIO/NIO/AIO)、マルチスレッド、ローカル呼び出しとリモート呼び出しの透過的なソリューション (Java クラスローダー、ダイナミック プロキシ、単体テストなどを含む)、非同期呼び出しと同期呼び出し、ネットワーク通信処理メカニズム (自動再接続) 、ブロードキャスト、例外、プール処理など）、Javaシリアライゼーション（各種プロトコルのプライベートシリアル化機構など）、各種フレームワークの実装原理（伝送形式、伝送形式をストリームに変換する方法、ストリームに変換する方法）情報を送信フォーマットに変換する方法、ストリームを受信する方法、ストリームを送信フォーマットに復元する方法など) 、どれをマスターする必要があるかは、実際のニーズに応じて異なります。原理を理解していれば簡単に実行できます。必要に応じてプライベートなリモート通信プロトコルを作成することもできます。分散サービス プラットフォームや大規模な分散アプリケーションの開発に従事している人は、少なくとも上記の知識点を理解する必要があると思います。

関連記事:

get、PUT、POST、削除リクエストのJava実装

Javaプログラミングの詳細な紹介、一般的な問題の概要

Javaマルチスレッドの基本の詳細な説明

以上がJavaリモート通信技術と原理分析のグラフィカルな紹介の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。