誰か WCF と ZeroC ICE を比較した人はいますか?
https://stackoverflow.com/questions/99548
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
ZeroC の ICE (www.zeroc.com) は面白そうなので、これを見て、WCF を使用する既存のソフトウェアと比較してみたいと思います。特に、WCF アプリはサーバー コールバック (HTTP 経由) を使用します。
比べた人いる？どうだった？現時点では相互運用性はあまり重要ではないため、特にパフォーマンスの面に興味があります。ありがとう！
解決
私は数年前に ICE について非常に簡潔にレビューしました。これまで直接比較したことはありませんが、WCF についてある程度の知識があれば、私の考えはある程度関連性があるかもしれません。
まず、ICE は特定のリモート通信メカニズムであり、WCF はより高レベルのリモート通信フレームワークであるため、WCF と ICE を比較することは完全に公平ではありません。
WCF は SOAP Web サービスを実装するものとして考えられることが多く、これが実際にこれまでの主な用途ですが、あらゆる種類のエンコードやトランスポート チャネルを使用したリモート サービスの実装にも使用できます。つまり、理論的にはパフォーマンスの高い通信に使用できることを意味します。アプリケーション間で。
これに対して、ICE は、アプリケーション間の通信を効率的に行うためにバイナリ エンコーディングを使用する、クロスプラットフォームのリモート通信メカニズムです。これは CORBA を簡略化して進化させたもので、CORBA、DCOM、.NET Remoting、および JNI に直接的に相当します。
ただし、ICE と WCF の間に直接の対応関係はありませんが、.NET アプリがリモートで通信する必要がある場合は、どちらも候補になります。考慮すべき決定点には次のようなものがあります。
リソース調達。ICE の経験よりも、WCF の経験を持つ開発者を見つける方が簡単です。
パフォーマンス。パフォーマンスが必要な場合は、ICE のパフォーマンスが高速ですが、WCF もパフォーマンスの高い構成で使用できます。あるいは、.NET Remoting は非常に優れたパフォーマンスを提供する可能性があり、MS スポンサーのベンチマークが何と言っても、WCF よりも 10% 優れていることがわかりました。
クロスプラットフォーム。Windows 以外のアプリケーションと通信する必要がある場合、使用できる WCF オプションには制限があります。さらに、SOAP スタックごとに標準の実装方法が異なるようであるため、真に汎用的な Web サービスを作成するのは困難になる可能性があります (ただし、WS-I は役に立ちます)。
初日からあらゆるパフォーマンスが必要ない場合は、個人的にはまず WCF を検討し、パフォーマンスが重要になった場合は ICE を検討します。それでも、ICE に移行するよりもサービス ボックスをスケールアウトした方がコストがかからない可能性があります。また、特殊なクロスプラットフォームのニーズがない場合は、バイナリ エンコーディングなどのために WCF を再構成することをいつでも検討できます。
他のヒント
アパッチの節約 ICE と WCF のもう 1 つの候補です。Facebook によって開発され、オープンソース化されました。 アパッチの節約 これは、エンコード側で非常に効率的であるだけでなく、すべてのクライアントを壊さずに構造体へのフィールドの追加もサポートしているため、ある意味で優れています (これは私たちのプロジェクトにとって非常に役立つことがわかりました)。
Googleプロトコルバッファ ホームページで .NET サポートについて言及されていないため、実際には候補ではないようです。ただし、一部のコミュニティ アドオンは C# をサポートしています。加えて、 氷 既存のサービスを使用している場合、Google プロトコル バッファのエミュレーションを提供します。
データポイント:コールバック マルチプラットフォームおよびマルチ言語プロジェクトを Ice から Thrift に変換し、かなり良い結果が得られました。Ice は多くの機能を備えているため、切断リスナーや接続イベントなどを実装する必要がありました。私たち自身。また、あるケースでは、Ice が回避させてくれたビッグ オブジェクト ロックという諺に引っかかってしまいました。これにより Thrift サーバーでデッドロックが発生しましたが、C# 側であまり遅延のないコーディングを行うことで簡単に修正できました。
ベンチマークを終えたばかりですが、私たちのアプリケーションでは、大量のデータをプッシュするものはすべて Ice よりも高速か、Ice と同等です。より多くのオーバーヘッドを伴う短いメッセージ (つまり、プロトコルを介してステータスを更新する「ハートビート」) は少し遅くなります。
最も重要な点は、コールバック サービスを正しく実装するには、Thrift インターフェイスを拡張し、Thrift の「プロセッサ」とコールバック クライアント/サーバーとともに独自のプロトコルを定義する必要があるということでした。しかし、私たちのアプリケーションが /非常に / 特殊であることは率直に認めます。既存のプロトコルとサーバーで十分です。しかし、.Net からの多重ソケットを使用するためにさえ、それらを拡張することは、それほど難しいことではありませんでした。
ICE を使用して、C++、Java、C# の両方で書かれたモジュールを統合しています。良い点は、サーバーがリモート マシン上のコンポーネントにもアクセスできるため、より高いパフォーマンスが必要な場合は、処理を別のマシンに移すことができることです。
私は WCF と ICE の両方を使用しましたが、実装面では ICE の方がクリーンだと思います。ICE には、非常に詳細で読みやすいドキュメントもあります。
ICE は、負荷分散、自動リモート クライアント更新など、WCF では実行できないいくつかの機能をサポートしています。
