同じチームによって開発される 2 つの C++ プロセス間の通信チャネルとして、RPC (xml-rpc ではない) の代わりに Web サービスを使用する正当な理由を誰か提案できますか? 注: Web サービスは、注文した配送を保証するものではありません。
4 に答える
ハンマーを持っている人は、すべての問題を釘と見なす傾向があります。そのため、2 つのプロセスが通信する唯一の方法であるかのように、Web サービスをあらゆる場所に配置する傾向があります。
あなたの場合、RPCはより良い選択であり、パフォーマンスが向上し、メモリ使用量が少なく、実装が簡単です(C ++で)...
Web サービスは、次のような場合に最適です。
- 多くの言語とプラットフォームのサポート
- SOA ベースのアプリケーション
- 分散サービス
これらのいずれも必要ない、または必要ない場合は、RPC に何の問題もありません。アプリケーションのプロセスがすべて同じマシン上にあり、それらの間で通信する必要がある場合、RPC は完全に受け入れられるソリューションです。
ローカルRPCが処理できる範囲を超えて何もする必要がなく、決してそうしないと確信している場合は、それを使用しない理由はありません。
SOA アーキテクチャ、多言語サポート、マルチプラットフォーム サポートを容易に提供し、Web サーバーを必要としない多くのテクノロジが存在するため、UI フロント エンド配信メカニズムとしていずれかのエンドを使用していない場合は、実際には、Web サーバーの要件ではありません。実際、IBM の Websphere のようなものを搭載したこのような獣は、かなりのリソース コストがかかります。より良いアーキテクチャーの選択は、CORBA のようなものでしょう。遊ぶための良い例については、TAO を参照してください。