 |
Para lograr que las aplicaciones Cliente/Servidor existieran, hubo que inventar múltiples capas de comunicación que fueran resolviendo los diferentes problemas de los sistemas distribuidos, en ambientes heterogéneos. La mayor parte de estas capas están aún en pleno desarrollo e investigación, por lo que las soluciones adoptadas han utilizado la combinación más básica y simple posible.
La base de todo el sistema (aparte de tener una red de comunicación confiable, que permite enviar mensajes entre los procesadores) es una idea muy simple: extender el llamado de procedimiento hacia un sistema distribuido.
Las funciones y procedimientos existen desde tiempos inmemoriales en la computación, apareciendo desde las primeras versiones de FORTRAN en los años '50. Hay pocas herramientas de programación tan conocidas y comunes a todos los lenguajes hoy en día. Menos claros son los métodos de paso de parámetros, manejo de variables locales y globales, etc. Sin embargo, la semántica básica de la ejecución de un llamado y retorno de un procedimiento son muy familiares en la computación.
Por otro lado, los sistemas distribuidos eran muy difíciles de programar, usando primitivas básicas de paso de mensajes, que implicaban tener que codificar todo, tanto los datos como los pedidos, en una secuencia de bytes que luego tenía que ser decodificada en el receptor.
A comienzos de los '80, un grupo de investigadores propuso un nuevo paradigma de programación de sistemas distribuidos: llamado de procedimiento a distancia (remote procedure call: RPC). La idea era muy simple, un procesador invoca un procedimiento que debe ejecutarse en otro procesador y luego espera el retorno. En el fondo, es aprovechar la distinción habitual entre llamador/llamado y colocar una parte en cada computador. La idea básica de la ejecución se ve en la Figura 1.
La ejecución es fácil de implementar usando mensajes, el llamador envía un mensaje y luego espera la respuesta (que es el retorno del procedimiento). Lo que no es trivial es que los parámetros y el valor de retorno deben ser encapsulados en mensajes. Por otro lado, para proveer independencia de las representaciones de los objetos en memoria requiero codificar los valores según algún estándar. Esto se hace agregando un poco de código (que típicamente se conoce como un stub) tanto en el llamador como en el llamado que codifica y decodifica todos los valores.
Una invocación completa de RPC puede verse en la Figura 2.
En general, al procesador que llama el procedimiento se le dice Cliente, y al que es llamado se le dice Servidor. Estos roles no son fijos en el tiempo, por ejemplo el código del procedimiento llamado (en el Servidor) puede invocar otro procedimiento a distancia, siendo Cliente de otro RPC. La implementación debe preveer incluso que el Servidor invoque un RPC en el Cliente, invirtiendo los roles por un momento.
La primera implementación que se hizo popular en sistemas abiertos, fue realizada por Sun Microsystems, y el producto se llama RPC, lo que tiende a confundir el concepto con una implementación particular. Sun también implementó una capa de codificación y decodificación de mensajes para ser completamente independiente de la representación de los datos en cualquier arquitectura. Esta capa se llama XDR, y es parte del estándar de facto que permite que todas las aplicaciones se comuniquen en forma independiente del hardware involucrado.
Otra definición importante pendiente es cómo codificar el procedimiento a ser llamado. No es posible hacer linking como se hace con las aplicaciones locales. Por otro lado, el servidor está dispuesto a proveer ciertos servicios solamente. Para ello, debe definirse un esquema complejo de ``nombres", que luego se traducen a procedimientos locales. El servidor decide qué servicios presta y los registra para que los clientes puedan accesarlos por sus ``nombres". Esto implica que el cliente debe conocer el nombre del servicio de antemano, y para eso debe haber un acuerdo previo que decida exactamente a qué servicio corresponde cada nombre.
Aparte de proveer una semántica conocida, RPC permite independizar las implementaciones del cliente y del servidor, muy parecido a un sistema de abstracción de datos o a un sistema orientado a objetos. Sin embargo, también introduce problemas nuevos, como las fallas parciales. Hacer aplicaciones tolerantes a fallas es algo fuera de la especialidad común de los profesionales de la computación. Normalmente, cuando los computadores se caen, se caen por completo, no por pedazos, y las aplicaciones son a lo más capaces de sobrevivir a fallas totales y reconstruir su estado a partir de bitácoras en disco.
Los sistemas distribuidos, en cambio, sufren de múltiples fallas parciales, se caen ciertos computadores, la red o segmentos de la red. Peor aún, es imposible estar seguro, desde una aplicación, de qué tipo de error se trata, e incluso es imposible saber si es un error o sólo un retraso por sobrecarga. Un ejemplo típico es la frase famosa de que un sistema distribuido es un sistema en el cual un usuario no puede trabajar porque una máquina, de la que nunca ha oído hablar, no está respondiendo. Las interdependencias de las máquinas entre ellas, al ligarlas como clientes y servidores vía aplicaciones, hacen que las posibilidades de fallas crezcan en forma multiplicativa.
Por ello, al planificar una instalación, debe pensarse cuidadosamente en la distribución de servicios de modo de minimizar las interdependencias innecesarias. Si el servidor de correo no responde, es normal no tener correo, pero el resto de los servicios deben seguir operando normalmente. Las aplicaciones también deben decidir qué hacer si una base de datos respondió pero la siguiente no, puesto que ahora no solo hay que manejar la consistencia dentro de una base de datos, sino que entre varias.
La flexibilidad también tiene su precio.
This document was generated using the LaTeX2HTML translator Version 2002-2-1 (1.71)
Copyright © 1993, 1994, 1995, 1996,
Nikos Drakos,
Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999,
Ross Moore,
Mathematics Department, Macquarie University, Sydney.
The command line arguments were:
latex2html -no_navigation -t RPC -split 0 rpcc.tex
The translation was initiated by Jose M. Piquer on 2008-08-16
