En esta sección analizaremos brevemente algunas de las consideraciones claves que enfrenta el diseñador de cualquier sistema de RPC. Las mismas caen en cuatro amplias categorías:
- Diseño de la interfaz
- Diseño del cliente
- Diseño del servidor
- Diseño del protocolo
Comencemos por el primer punto. El corazón del asunto es cuánta transparencia se aspira alcanzar. Dado los problemas con los parámetros por referencia y con los punteros, y la literal imposibilidad de alcanzar semánticas exactamente una vez, algunos autores argumentan que en el caso de tener que enfrentar caídas, la transparencia ni siquiera debería intentarse. Los mismos están a favor del agregado de una palabra clave, remote, en la declaración del cualquier procedimiento que puede ser llamado remotamente para advertirse al compilador y evitar el engaño del programador. Por otro lado, aunque los problemas de la RPC parecen formidables en el papel, en la práctica, las caídas son muy raras y la mayoría de los problemas pueden ser manejados con un diseño cuidadoso del stub y del compilador.
Un tema importante que aún no hemos tocado es cómo se producen los stubs. Una posibilidad es tenerlos todos escritos a mano. Otra es tener un compilador que la produzca como un subproducto del proceso de compilación y, de hecho, hay varios productos en el mercado para estas tareas, generalmente bajo denominaciones como RPC compiler o similares.
Otra exigencia relativa al lenguaje es el manejo de excepciones. Si no hay algún mecanismo adecuado para los errores de RPC capturados por alguna parte del programa distinta del procedimiento cliente, entonces cada uno de estos procedimientos tendrá que chequear todos los posibles errores retornados y estar preparado para manejarlos. Una situación altamente no transparente.
Por último, vienen las consideraciones de binding. Más precisamente, cómo los servidores exportan sus nombre, cómo los clientes pueden seleccionar un caso específico de un servidor cuando hay varios idénticos, entre otras; son todas exigencias que necesitan una atención cuidadosa.
Las principales cuestiones en el diseño del cliente involucran el agotamiento de temporizadores y los huérfanos. ¿El stub cliente debería indicar un agotamiento de temporizador después de no lograr ninguna respuesta, o sólo debería esperar? Si se utilizan temporizadores, ¿qué acción se debería tomar, qué semántica se debería proveer y cómo se deberían manejar los huérfanos?
La principal exigencia que interesa en el diseño del servidor es el paralelismo. En un extremo, cada vez que viene un pedido para la ejecución de un procedimiento servidor, se crea un nuevo proceso y el procedimiento corre como parte de ese proceso. Si vienen otros pedidos de otros clientes antes de que el primero haya terminado, se crean más procesos y todos ellos corren en paralelo, independientemente entre sí. En el otro extremo, existe un único proceso asociado con cada procedimiento servidor. Si entra un segundo pedido antes de que el primero haya terminado, debe esperar su turno. El primer enfoque soporta la carga de la creación de procesos en cada RPC, pero potencialmente permite la ejecución de llamadas en paralelo. El segundo es más simple y más rápido si hay únicamente una llamada a la vez, pero no permite ningún paralelismo si hay múltiples llamadas.
Por otro lado, la principal exigencia en el diseño del protocolo es lograr alta performance. Hay una gran cantidad de controversias sobre este punto. Muchos investigadores creen que la única manera de hacer que la RPC funcione rápido es correrla sobre la interfaz de la capa de red, lo que implica que deberá meterse dentro de las bibliotecas de RPC soluciones a los problemas originados a partir de la ausencia de las capas intermedias.
Finalmente, y hablando comparativamente, dado el relativo bajo nivel de las funciones involucradas con sockets, el paradigma de alto nivel denominado RPC resulta mucho más fácil de utilizar y tiende a reemplazar a los sockets en los casos más comunes o en aplicaciones relativamente simples. Escribir una aplicación distribuida utilizando RPCs es casi tan fácil como escribir una aplicación que correrá sobre un único equipo haciendo transparente casi todas las cuestiones relativas a la red. Con ellas la situación es muy similar a la de un código local, aunque cambie la semántica como vimos oportunamente.
Debe tenerse en cuenta que aquí no se cuenta con la flexibilidad de los sockets ni con el control que puede ejercerse sobre el sistema que se está desarrollando, pero puede considerarse este hecho como el precio a pagar en pos de la transparencia.