RPC、メッセージング、REST：用語

この記事の目的は、用語を議論することです。 この記事は、どのように、何のためにではなく、用語の使用についてのみです。 この記事は著者の意見を反映しており、科学的であると主張するものではありません。

エントリー

分散システムのプログラミングまたはシステムの統合の分野で作業している場合、上記のほとんどは新しいものではありません。



問題は、人々がさまざまなテクノロジーを使用して会い、それらの人々が技術的な会話を開始するときに発生します。 この場合、用語による相互誤解がしばしばあります。 さまざまなコンテキストで使用される用語をまとめてみます。

用語

この領域には明確な用語と分類はありません。 以下で使用される用語は、著者のモデルを反映したものです。つまり、厳密に主観的なものです。 どんな批判や議論も歓迎します。



用語をRPC（リモートプロシージャコール）、メッセージング、およびRESTの3つの領域に分けました。 これらの地域には歴史的なルーツがあります。

RPC

RPCテクノロジーは最も古いテクノロジーです。 RPCの最も顕著な代表はCORBAとDCOMです。



当時、主に高速で比較的信頼性の高いローカルネットワークでシステムを接続する必要がありました。 RPCの主なアイデアは、リモートシステムの呼び出しをプログラム内の関数の呼び出しに非常に似たものにすることでした。 リモート呼び出しのメカニズムはすべてプログラマーから隠されていました。 少なくとも彼らは彼女を隠そうとしました。 多くの場合、プログラマーはより深いレベルで作業する必要がありました。マーシャリングとアンマーシャリング （ロシア語ではどうですか？）という用語が登場しました 。 プロセス内の通常の関数呼び出しは、 プロキシでは呼び出し側で処理され、 ディスパッチャでは関数を実行するシステム側で処理されました。 理想的には、呼び出しシステムも処理システムも、システム間でデータを転送する複雑さを気にしませんでした。 これらの微妙な点はすべて、Proxy-Dispatcherに集中しており、そのコードは自動的に生成されました。



したがって、ローカル関数の呼び出しとリモート関数の呼び出しの違いに気付かないはずです。

現在、RPCには独特のルネッサンスがあります。その最も顕著な代表は、Google ProtoBuf、Thrift、Avroです。

メッセージング

時間が経つにつれて、呼び出された関数がまだローカル関数と異なるという事実からプログラマーを保護しようとしても、目的の結果にならないことが判明しました。 分散システム間の実装の詳細と基本的な違いは 、自動生成されたプロキシコードを使用して対処するには大きすぎました。 徐々に、システムが信頼性の低い、低速の低速環境で接続されているという事実がプログラムコードに明示的に反映されるべきであるという理解が得られました。



Webサービス技術が登場しました。 ABC：Address、Binding、Contractと言い始めました。 コントラクトが登場した理由は完全には明らかではありません。コントラクトは、本質的には入力引数のエンベロープ（エンベロープ）です。 契約はしばしばモデル全体を単純化するよりも複雑にします。 しかし...気にしないでください。



プログラマーは、 サービス （ Service ）またはサービスを呼び出すクライアント （ Client ）を明示的に作成しました。 サービスは一連の操作 （ Operation ）であり、それぞれが入力で要求 （ Request ）を受信し、 応答 （ Response ）を発行しました。 クライアントは明示的に （ Sent ）要求を送信し 、サービスは明示的にそれを受信（ Receive ）し、応答（送信）して応答を送信しました。 クライアントは（受信）応答を受信し、コールは終了しました。



RPCと同じように、ProxyとDispatcherはここのどこかで機能しました。 そして、以前と同様に、それらのコードは自動的に生成され、プログラマーはそれを理解する必要がありませんでした。 それだけでない限り、クライアントはプロキシからのクラスを明示的に使用しました。



要求と応答は、有線での送信を目的とした形式に明示的に変換されます。 ほとんどの場合、これはバイトの配列です。 変換は、 シリアライゼーションおよびデシリアライゼーションと呼ばれ、プロキシコードに隠されている場合があります。

メッセージングの集大成は、 ESB（Enterprise Service Bus）パラダイムの出現に現れます。 誰もそれが何であるかを実際に明確にすることはできませんが、誰もがESBデータがメッセージの形で移動することに同意しています。

REST

コードの複雑さとの絶え間ない戦いの中で、プログラマーは次のステップを踏み出し、 RESTを作成しました。



RESTの基本原則は、機能操作が大幅に制限され、 CRUD操作のセット（ 作成-読み取り-更新-削除）のみが残されることです。 このモデルでは、すべての操作が常に一部のデータに適用されます。 ほとんどのアプリケーションでは、CRUD操作で十分です。 ほとんどの場合、RESTテクノロジーはHTTPプロトコルの使用を伴うため、CRUDコマンドはHTTPコマンドに影響を及ぼします（ Post - Get - Put - Delete ） 。 RESTは必ずしもHTTPにバインドされているとは限らないという意見が絶えずあります。 しかし、実際には、HTTPコマンドの構文に対する操作シグネチャの反映が広く使用されています。 たとえば、関数呼び出し



EntityAddress ReadEntityAddress（string param1、string param2）



このように配置します：



GET：entityAddress？Param1 = value1＆param2 = value2

おわりに

分散システムまたは統合に関する議論を始める前に、用語を決定します。 プロキシが異なるコンテキストで常に同じことを意味する場合、たとえば、リクエストはRPCの観点ではほとんど意味を持たず、RESTテクノロジーを議論するときにマーシャリングは当惑します。