Question

Can anyone suggest a good reason to use web services instead of RPC (not xml-rpc) as a comms channel between two C++ processes both of which will be developed by the same team? Note: Web services do not guarantee ordered delivery!

Was it helpful?

Solution

When people have a hammer, they tend to see all problems as nails. That's why people tend to put webservices everywhere as if it were the only way for two processes to communicate.

In your case RPC seems to be a better choice, more performance, less memory usage, simpler to implement (in C++)...

OTHER TIPS

Web services are great when you need:

  • Support for many languages and platforms
  • SOA based applications
  • Distributed services

If you dont need any of these, or never will, then there's nothing wrong with RPC at all. If your application's processes all live on the same machine and you need to communicate between them, RPC is a perfectly acceptable solution.

If you don't need to do anything beyond what local RPC can handle and are confident that you never will, then there's no reason not to use it.

Since there are many technologies out there which readily provide SOA architecture, multi-lingual support, multi-platform support, and don't require a web server, if you aren't using either end as a UI front end delivery mechanism, then there really isn't any requirement for a web server. In fact, such a beast, loaded down with something like IBM's Websphere will have substantial resource costs. A better architectural choice would be something like CORBA. See TAO for a good example of something to play with.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top