¿Alguien puede sugerir una buena razón para usar servicios web en lugar de RPC (no xml-rpc) como un canal de comunicación entre dos procesos C++ que serán desarrollados por el mismo equipo? Nota: ¡Los servicios web no garantizan la entrega ordenada!¿Por qué usar servicios web en lugar de RPC entre dos procesos internos?
Cuando las personas tienen un martillo, tienden a ver todos los problemas como si fueran clavos. Es por eso que las personas tienden a poner servicios web en todas partes como si fuera la única forma en que dos procesos se comunican.
En su caso RPC parece ser una mejor opción, un mayor rendimiento, menor uso de memoria, más sencillo de implementar (en C++) ...
servicios Web son grandes cuando se necesita:
Si usted no necesita ninguno de estos, o nunca lo hará, entonces no hay nada malo con RPC en absoluto. Si todos los procesos de su aplicación viven en la misma máquina y necesita comunicarse entre ellos, RPC es una solución perfectamente aceptable.
Si no necesita hacer nada más allá de lo RPC local puede manejar y confía en que nunca lo hará, entonces no hay razón para no usarlo.
Dado que hay muchas tecnologías que ofrecen arquitectura SOA, soporte multilingüe, soporte multiplataforma y no requieren un servidor web, si no está utilizando ninguno de los dos extremos como entrega de interfaz de usuario de interfaz de usuario mecanismo, entonces realmente no hay ningún requisito para un servidor web. De hecho, una bestia tan cargada con algo como la Websphere de IBM tendrá costos sustanciales de recursos. Una mejor elección arquitectónica sería algo como CORBA. Vea TAO para ver un buen ejemplo de algo con lo que jugar.
No estoy necesariamente hablando en la misma máquina física aquí, pero de todos modos estoy de acuerdo con usted. –
Eso es genial, el punto sigue en pie :) –