4

私は現在pythonでツイストのパースペクティブブローカーを使用しており、過去にRabbitMQのようなものに切り替えることを検討しましたが、pbを単に置き換えることができるかどうかはわかりません-ここでリンゴとオレンジを比較しているように感じます. 私は最近、REST と SOAP に関する必然的な議論についてよく読んでおり、その結果、SOA のような「エンタープライズ」Web サービスに関する記事を読むようになりました。

Web とデスクトップに erp のような機能を実装する必要があるプロジェクトが近づいているので、サーバーとクライアント間の通信に使用するアプローチ/テクノロジを検討しています。しかし、私はこれらすべてについてできる限り多くのことを学ぼうとしているので、この特定の問題を解決するだけではありません。

サーバーとクライアント間の通信に何を使用していますか?

パースペクティブ ブローカーのような Python 固有のプロトコルが相互運用性を制限する可能性があることは理解していますが、AMQP プロトコルがそれを置き換えることができると想定するのは正しいですか?

私が間違っていなければ、twisted.pb と amqp はどちらも常時接続と非常に低いオーバーヘッド プロトコルを使用しています。しかし一方では、多数のクライアントを常に接続しておくことは問題になる可能性があり、他方では、http キープアライブやシリアライゼーション部分で使用するトリックを使用しても、Web サービスでは依然として問題になります。

私の仮定のいずれかが間違っている場合は、誰かが私を正しい方向に向けて詳細を学ぶことができれば幸いです.

4

1 に答える 1

12

いつも通り「場合による」。まず、用語を明確にしましょう。

Twisted のPerspective Brokerは基本的に、分散アクションの両端 (クライアント側とサーバー側の両方) を制御できる場合に使用できるシステムです。オブジェクトを一方の端から他方の端にコピーし、リモート オブジェクトのメソッドを呼び出す方法を提供します。コピーには、オブジェクトをネットワーク転送に適した形式にシリアル化し、Twisted 独自の転送プロトコルを使用して転送することが含まれます。これは、両端で Twisted を使用でき、Twisted 以外のシステムとインターフェースする必要がない場合に便利です。

一般的に言えば、Web サービスは、通信に HTTP を使用するクライアント/サーバー アプリケーションです。クライアントは HTTP を使用してサーバーに要求を送信し、サーバーは結果を返します。パラメータは、たとえば次のようにエンコードできます。GET または POST 要求を送信するか、または POST 要求のデータ セクションを使用して、たとえば、実行するアクションを説明する XML 形式のドキュメントを送信します。

RESTは、システムが公開するすべてのリソースとリソースに対する操作を直接アドレス指定できるようにするというアーキテクチャ上の考え方です。簡単に言えば、リソースへのアクセスまたは操作に使用される URI に、リソース名とそれに対して実行する操作が含まれていることを意味します。REST は、HTTP を使用して Web サービスとして実装することができ、一般的に実装されています。

SOAPはメッセージ交換用のプロトコルです。これは、いくつかのトランスポート方法の選択と、単一の XML ベースのメッセージ形式の 2 つの部分で構成されています。トランスポート メソッドは、たとえば、SOAP を Wed Services の実装候補にする HTTP にすることができます。メッセージ形式は、要求されたアクションとアクションの結果に関するすべての詳細を指定します。

JMSは、Java ベースのメッセージング システムの API 標準です。メッセージのセマンティクス (1 対 1 または 1 対多など) を定義し、アドレス指定、メッセージの作成、パラメーターとデータの入力、送信、および受信とデコードのメソッドを含みます。この API により、理論上は、すべてのコードを書き直すことなく、基礎となるメッセージング システムの実装を変更できることが保証されます。ただし、メッセージ システムの実装は、別の JMS 対応メッセージング システムとプロトコル互換である必要はありません。したがって、JMS システムが 1 つあるからといって、自動的に別の JMS システムとメッセージを交換できるわけではありません。それを機能させるには、おそらくある種のブリッジ サービスを構築する必要があります。これは、特にアドレス指定に関しては大きな課題となるでしょう。

AMQPは、メッセージング システムが従わなければならないワイヤ プロトコルを定義することによって、状況を改善しようとします。これは、異なるベンダーのメッセージング システムがメッセージを交換できることを意味します。

最後に、SOAは、アプリケーションが再利用可能なサービスに分割されるアーキテクチャの概念です。次に、これらのサービスを組み合わせて (「オーケストレーション」)、アプリケーションを実装します。新規お申し込みの都度、既存のサービスを再利用する機会があります。SOA はまた、再利用が実際に行われ、サービスが十分に一般的になるように設計されるように、非技術的なサポート活動を必要とするものでもあります。また、SOA は、レガシー システムの機能を意味のある全体にパッケージ化するための 1 つの方法であり、その後、より最新の手法を使用してさらに拡張および開発できます。SOA は、Web サービス、メッセージング システム、Enterprise Service Bus などのさまざまなテクノロジを使用して実装できます。

リクエストごとに 1 つの接続と、複数のリクエストに対して接続を開いたままにすることとのトレードオフについて考えました。これは、利用可能なリソース、メッセージング パターン、およびデータのサイズによって異なります。着信メッセージ ストリームが常に同じである場合は、接続の量があまり変わらないため、接続を開いたままにしても問題ない可能性があります。一方、複数のシステムからのメッセージのバーストがある場合は、リソースを解放し、接続が長くなりすぎないようにすることが役立つ場合があります。また、接続ごとに大量のデータが転送される場合、接続を開いたり閉じたりするオーバーヘッドは、合計トランザクションの長さに比べて小さくなります。一方、非常に小さなメッセージを大量に転送する場合は、接続を開いたままにしておくと効果的です。

AMQP は実際に Twisted 固有のプロトコルを置き換えることができます。これにより、Twisted 以外のシステムとのやり取りが可能になります。

これがお役に立てば幸いです。まだ疑問に思っていることがある場合 (これは非常に広い領域なので、疑問があると思います)、小さな質問に分割して個別に投稿することをお勧めします。そうすれば、答えはより正確になります。

于 2010-08-06T17:03:03.867 に答える