4. características de los sistemas de procedimientos remotos
TRANSCRIPT
30
4. Características de los sistemas de procedimientos remotos
En este apartado explicaremos qué se entiende por un sistema de
procedimientos remotos, reseñaremos aquellos más populares y que se tomaron
como alternativas para la realización de este proyecto y, finalmente, veremos más en
detalle el protocolo xml-rpc, que será el finalmente elegido.
4.1. Características generales
Un sistema de procedimientos remotos, RPC por sus siglas en inglés (Remote
Procedure Call) es una comunicación entre procesos que permite a un programa de
ordenador ejecutar una subrutina o proceso en un espacio de memoria diferenciado
(usualmente en otro equipo, aunque esto no es un requisito indispensable) sin que el
diseñador de esta subrutina tenga que preocuparse explícitamente de los detalles de
esta interacción remota, abstrayéndose de ella.
Con el fin de conseguir que el diseñador se despreocupe de las comunicaciones
entre ambos equipos se diseña un protocolo (llamado también RPC), que permite al
usuario encapsular las comunicaciones dentro de las RPC, suponiendo un gran avance
frente a los sockets usados previamente y que requerían una gran atención por parte
del programador.
Normalmente las llamadas a procedimientos remotos son usadas dentro del
paradigma cliente-servidor. El cliente inicia el proceso solicitando al servidor que
ejecute cierto procedimiento o función, es en el servidor donde realmente se ejecuta
la tarea solicitada. Tras realizar la rutina deseada el servidor devolverá el resultado de
la operación al cliente.
Los primeros sistemas de llamadas a procedimientos remotos se remontan al
menos a los años 80, donde aparecen referencias a ellos en documentos de ARPANET.
Uno de los primeros sistemas comerciales que hace uso de RPC es “Courier” de Xerox
en 1981 y la primera implementación realmente popular de RPC en Unix fue Sun’s RPC
(actualmente llamado ONC RPC) el cual se usó como base para el sistema de ficheros
de red NFS.
31
Hoy en día la tendencia es a utilizar XML como lenguaje de descripción del
interfaz (define de qué manera se muestra la información que define los
procedimientos y los datos que estos pueden necesitar o devolver) y HTTP como
protocolo de red, dando lugar a lo que se han venido en denominar servicios web,
como ejemplos de estos cabe citar SOAP o XML-RPC.
Veamos a continuación como funciona, de forma general, un sistema de
procedimientos remotos:
• El cliente inicia el proceso RPC enviando una petición a un servidor
conocido, en la petición le debe indicar al servidor qué procedimiento
debe ejecutar y suministrarle los parámetros necesarios (si se
requieren).
• El servidor envía una respuesta al cliente y la aplicación continúa su
ejecución. En este punto hay múltiples variantes dependiendo del
sistema concreto de RPC que se utilice. Por norma general el cliente
queda en un estado de bloqueo (esperando a que termine la tarea en el
servidor) hasta que este le envíe la respuesta o buen se cumpla un
tiempo máximo de espera (timeout)
Una diferencia fundamental entre una llamada a procedimiento remoto una
llamada local es que la llamada a procedimiento remoto puede fallar debido a la red,
introduce un factor más que es, en principio, impredecible, luego deben implementar
mecanismos para tratar este tipo de complicaciones.
A continuación observamos gráficamente y de manera detallada el flujo de
eventos durante el desarrollo de una llamada a RPC:
1. El cliente llama al Stub con los parámetros adecuados a la función que
se desea invocar en el equipo remoto. El Stub puede definirse como una
pieza de código que es usada para convertir los parámetros en el
trascurso de una llamada a RPC.
32
2. El Stub empaqueta los parámetros que se le han pasado y realiza una
llamada al sistema para que este envíe la petición.
3. El sistema operativo del cliente envía, haciendo uso de la red, la petición
al servidor.
4. La petición llega al servidor, donde el so de este la recibe y la pasa a un
Stub propio que desempaqueta los parámetros que contiene.
Ilustración 5: Llamada del cliente rpc.
Ilustración 6: Empaquetado de los datos.
Ilustración 5: Envío de la petición.
33
5. El Stub del servidor realiza la llamada al procedimiento o subrutina,
haciendo uso para ello de los parámetros que viajaban en la petición.
6. El Stub del servidor envía una respuesta al cliente con el resultado del
procedimiento ejecutado. La secuencia de pasos seguiría a la inversa
desde aquí.
Ilustración 6: Llegada de la petición.
Ilustración 7: Llamada al procedimiento en el servidor.
Ilustración 8: Envío de la respuesta RPC.
34
Algunos de los puntos descritos previamente puede variar ligeramente
dependiendo del sistema o protocolo de procedimientos remotos que se use, en el
siguiente apartado se describirán algunos de los más comunes.
4.2. Sistemas de procedimientos remotos
En la actualidad existen gran multitud de sistemas de procedimientos remotos,
a continuación examinaremos algunos de los más populares y aquellos cuya adopción
se estudió y, posteriormente se desechó, para el desarrollo de este proyecto. Se
enumerarán sus características, fortalezas y debilidades, por último se compararán con
el candidato finalmente elegido que, como puede adivinar, será xml-rpc.
• CORBA
Corba son las siglas de Common Object Request Broker Architecture y es un
estándar que permite que software escrito en distintos lenguajes y ejecutándose en
distintas máquinas trabajen conjuntamente. Está muy orientado a objetos y se suele
emplear en entornos multicapa, también es usado por el proyecto Gnome para la
comunicación entre aplicaciones.
En un sentido general Corba es un mecanismo software que normaliza la
semántica de las llamadas a los métodos entre aplicaciones, ya residan estas en el
mismo espacio de memoria (misma máquina) o en diferentes espacios de memoria
(diferentes máquinas). La primera versión de Corba fue publicada en 1.991. Como
parte de su funcionamiento Corba genera un ORB, que no es más que una capa de
middleware que permite a los objetos realizar llamadas a métodos situados en otras
máquinas, también maneja la transferencia de la estructura de datos, de forma que
esta sea compatible entre los dos objetos, esto encaja perfectamente en la
generalidad de los sistemas de procedimientos remotos que hemos visto previamente.
Corba está disponible en multitud de lenguajes, pero suele implementarse
principalmente en dos lenguajes: C++ y Java, esto es debido sobre todo a la alta calidad
y extensa documentación que existe para poder usar Corba sobre estos lenguajes,
especialmente Java. A continuación podemos observar, como curiosidad, un diagrama
del funcionamiento de Corba
35
A modo de resumen enumeraremos las principales características de Corba:
� Ventajas
- Multiplataforma
- Multilenguaje
- Estándar
- Extensa documentación
- Versátil
� Desventajas
- Complejidad muy alta
- Uso no trivial a través de proxies, nat, etc.
Como podemos observar la principal desventaja de este protocolo es su
excesiva complejidad, usando una frase popular podría decirse que emplearlo para el
objetivo de este proyecto sería matar moscas a cañonazos. Por este motivo es por el
que finalmente descartamos su uso, ya que el empleo del mismo requiere el paso a
través de una curva de aprendizaje con una alta pendiente inicial y con nuestro
sistema pretendemos todo lo contrario, que cualquier usuario técnico sea capaz de
emplear en un tiempo de horas o días a lo sumo.
Ilustración 9: Estructura de un sistema CORBA.
36
• DCOM
DCOM son las siglas de Distributed Component Object Model, esta es una
tecnología propietaria de Microsoft que extiende los componentes de su tecnología
COM de manera que permite la ejecución de software distribuido en varios equipos
que se comunican entre sí. En el momento de su aparición DCOM supuso la respuesta
de Microsoft al estándar CORBA y se libró una batalla entre ambos para ver cuál se
establecía como el modelo de código y servicios sobre internet. Finalmente las
dificultades que tenía el hacer que estas tecnologías funcionasen a través de
cortafuegos y/o en máquinas desconocidas propició que el conjunto de peticiones http
normales y navegadores web modernos le ganasen la partida de popularidad, a pesar
de esto tanto DCOM como CORBA siguen conservando un nicho de mercado muy
reseñable.
El principal problema que presenta DCOM para nuestros intereses es el que es
una tecnología propietaria de Microsoft y que solo funciona sobre equipos que
ejecuten Windows. Por otra parte presenta notables puntos fuertes, entre los que
cabe destacar la alta eficiencia de su implementación, el escaso requerimiento de
ancho de banda, al igual que la mayoría de los protocolos de procedimientos remotos
permite escribir las aplicaciones en una multitud de lenguajes de programación, el
problema es que muchos de sus objetos y métodos son una transposición directa de
los objetos COM clásicos (nótese la pérdida de la primera D, esto implica que
simplemente permiten la comunicación entre procesos en el mismo espacio de
memoria, la misma máquina) que a su vez está íntimamente ligados al sistema
operativo Windows de Microsoft
A continuación mostramos un esquema superficial del funcionamiento del
protocolo DCOM, en el mismo se observa que la única diferencia entre el protocolo
Ilustración 10: Esquema funcionamiento DCOM.
37
DCOM y COM es la conexión entre el cliente y el servidor.
A modo de resumen enumeraremos las principales características de DCOM:
� Ventajas
- Multilenguaje.
- Estándar.
- Extensa documentación.
- Versátil.
- Uso de ancho de banda eficiente.
� Desventajas
- Complejidad alta, aunque asumible
- Solo operativo en sistemas Windows
Como podemos observar DCOM no cumple una de las principales
características que le pedimos a nuestro sistema, que sea multiplataforma. DCOM solo
cuenta con implementaciones para sistemas Windows, es cierto que estas son
altamente eficientes y cuentan con una enorme cantidad de documentación y
ejemplos de una gran calidad, aún así teniendo en cuenta que el parque de servidores
del Centro de Cálculo está formado principalmente por equipos corriendo Linux y el
uso que pretendemos darle a nuestro sistema debemos concluir que DCOM no es una
opción viable para nosotros.
• SOAP
SOAP, acrónimo de Simple Object Access Protocol es un protocolo
estandarizado por el World Wide Web Consortium (W3C) que define el intercambio
de información entre dos objetos por medio del uso de XML. Es un protocolo que
surge como una evolución de xml-rpc, al quedarse este protocolo corto para las
necesidades de grandes corporaciones. En un principio simplemente consistió en la
adición de algunos tipos de datos y espacios de nombres, una vez que el W3C aceptó el
estándar como propio el grupo de trabajo que se ocupa de él le ha ido añadiendo
características que no siempre han guardado una filosofía común (soporte de XML
schemas, tipos personalizados, permitir que algunos aspectos del estándar dependan
de la implementación del mismo, …). Una de las desventajas de los protocolos basados
en XML para el intercambio de información es la gran sobrecarga de información que
introduce este protocolo para el intercambio de datos, es decir para enviar una unidad
de información realmente útil el protocolo le añade varias más para su propio uso.
Esta última característica hace a este protocolo bastante lento y requiere de un uso
intensivo de las capacidades de red, esta sobrecarga puede ignorarse si los mensajes
38
que se intercambian son cortos, en cambio se hace especialmente patente cuando se
intercambian datos binarios como resultado de alguna operación o como parámetro
de algún método, en este caso la sobrecarga puede llegar a ser enorme. SOAP define
métodos para intentar paliar este problema, aún así este sigue siendo apreciable.
En la siguiente imagen se puede observar la estructura de encapsulamiento que
sigue el protocolo SOAP.
Ilustración 11: Encapsulamiento en SOAP.
39
Al igual que hemos hecho con los otros protocolos analizaremos a continuación
los pros y contras de este protocolo:
� Ventajas
- Multilenguaje.
- Estándar.
- Multiplataforma.
- Extensa documentación.
- Versátil.
- Complejidad asumible.
� Desventajas
- Uso de ancho de banda ineficiente.
- No permite el trabajo directamente con objetos.
En principio este protocolo cumple con todos los requisitos que le pedíamos a
nuestro sistema, si bien es cierto que penaliza muchísimo el envío de datos binarios a
través de él, este no va a ser el uso típico y, en todo caso, esa penalización sería
completamente asumible para un uso no enfocado a la transmisión de ficheros. Si
finalmente no ha sido este protocolo el elegido es debido a que el protocolo xml-rpc
que será el elegido comparte gran parte de las características con SOAP, solo que es
aún más sencillo como después veremos, si nos paramos a pensar esto es lógico, ya
que xml-rpc no es sino el antecesor de SOAP. Finalmente no nos decantamos por este
protocolo ya que hemos encontrado uno más adecuado, no por ninguna gran carencia
del mismo.
• Otros
A continuación exponemos otros sistemas de procedimientos remotos que se
han estudiado para su implantación pero que han sido descartados por no cumplir
alguna de las características básicas que requiere nuestro sistema:
- Pyro
La singularidad de este framework es que pretende crear la abstracción de que
un objeto existe independiente de su ubicación en una máquina u otra. Es realmente
potente, similar a Remote Method Invocation de Java, por desgracia al igual que este
está atado a un único lenguaje de programación, Python en este caso, por lo que no
sirve a nuestro propósito. Otra característica indeseada es que la implementación aún
40
no es completamente definitiva y entre versiones consecutivas no se asegura la
compatibilidad.
- Etch
Es un framework bastante novedoso (data del año 2.008) desarrollado por la
empresa Cisco, es multiplataforma y está enfocado a la construcción de servicios de
red. Está enfocado sobre todo a que sea liviano, independiente del transporte y
altamente eficiente en el uso que hace de la red. La gran contra que tiene es que las
implementaciones en algunos lenguajes comunes están aún un poco verdes (por
ejemplo php carece de ella) y la documentación disponible es inferior a la de otros
sistemas. En cuanto a la simplicidad de uso, aún no siendo excesiva, hay otras sistemas
que le superan.
- Json-rpc
Es un protocolo bastante similar a xml-rpc, la principal diferencia está en que
usa el formato json para encapsular los dats en lugar de xml. El principal problema es
que la versión actual considerada estable (la 2.0) es bastante nueva (2.010) y no está
tan extendido como xml-rpc. Aún así es un protocolo que está ganando popularidad
rápidamente y la cantidad de documentación e implementaciones del mismo crecen
día a día, podría haber sido también una opción válida a la hora de diseñar nuestro
sistema, posee bastantes implementaciones y es tiene un soporte amplio
multiplataforma, además su uso es relativamente sencillo, el factor que hizo inclinar la
balanza a favor de xml-rpc fue probablemente la mayor cantidad de documentación
disponible para éste último.
• From the scratch
En la fase de diseño y estudio del estado del arte se plantea la opción de
diseñar un protocolo de procedimientos remotos desde cero (from the scratch). Esta
opción posee una ventaja inherente, el sistema así diseñado e implementado se
adapta perfectamente a todos nuestros requerimientos, en la medida en que nosotros
seamos capaces de definir estos claramente. Podríamos conseguir un sistema trivial de
usar por parte de los posteriores diseñadores que fueran a hacer uso de él, la
documentación podría ser tan exhaustiva como nosotros quisiéramos ya que sería
nuestra tarea (aunque la experiencia nos dice que un gran proyecto siempre contará
con más y mejor documentación). Las desventajas de esta opción son también
evidentes: un gran tiempo de desarrollo e implementación, deberíamos realizar
versiones del mismo para cada lenguaje/sistema operativo en el que quisiéramos que
41
estuviera disponible, multiplicando los esfuerzos necesarios; otra problemática
asociada a un desarrollo propio es que la posibilidad de detección y corrección de
errores es menor que en uno de mayor envergadura y recorrido temporal. Por lo tanto
esta opción solo la contemplamos se todos los candidatos que tuviéramos para los
sistemas de procedimientos remotos requirieran una inversión de tiempo inicial muy
elevada, que justificara el tiempo que se invertiría en el desarrollo de un sistema
propio. Por suerte hemos visto que contamos con sistema que, sin ser ideales,
satisfacen nuestras necesidades en un grado lo suficientemente algo como para que
podamos descartar la opción de implementar un nuevo sistema desde cero.
• Xmlrpc
Dada la importancia que tiene el protocolo xml-rpc en el desarrollo de este
proyecto ya que es el que finalmente se ha elegido como base para el desarrollo del
sistema se le dedica todo un apartado al mismo, en él se explicarán las peculiaridades
y características más representativas del mismo, así como también se argumentará el
porqué de su elección.
Xml-rpc es un protocolo de procedimientos remotos el cual fue creado en 1.998
por Dave Winer de Userland Software y Microsoft. Este protocolo usa una sintaxis xml
especialmente definida para encapsular la información y la llamada a los métodos.
Eventualmente xml-rpc prosiguió su desarrollo con la adición de nuevas características
y terminó evolucionando en el protocolo SOAP, el cual vimos anteriormente.
4.3. Breve descripción de Xmlrpc
Entremos ahora en el detalle técnico de cómo trabaja realment el protocolo
xml-rpc. Un mensaje xml-rpc consiste en una petición HTTP usando el método post, el
cuerpo de esta petición es xml, el servidor recibe este mensaje y devuelve la respuesta
en un mensaje codificado también en xml. A continuación podemos observar un
ejemplo de un mensaje xml-rpc.
42
En el ejemplo anterior podemos observar que el mensaje se divide en dos
partes: la cabecera, que contiene información sobre cómo se efectúa la petición y el
cuerpo en el cuál viajan realmente los datos de la petición. En la cabecera la primera
línea que nos encontramos nos indica el protocolo (siempre será HTTP en alguna de
sus versiones, más adelante veremos qué es lo que esto implica), antes de eso está
indicada la ruta, el formato de esta ruta no está especificado, aunque suele ser una
ruta relativa acorde con el uso de http, por ejemplo en este caso se le está indicando al
servidor que debe mapear la petición al método que escuche en /RPC2. Esta indicación
de la ruta permite a un solo servidor xml-rpc el manejo de distintos servidores
ofreciendo servicios diferenciados sin más que ubicarlos en rutas distintas. En las dos
siguientes líneas se indican el user-agent (una descripción del cliente que realiza la
petición) y el host, el equipo desde el que la petición se realiza, estos dos parámetros
son obligatorios y deben figurar siempre en cada petición xml-rpc. La siguiente línea
nos informa de qué tipo de información viaja en la petición (Content-Type), el valor de
este campo será siempre text/xml. Por último se debe indicar la longitud de la petición
(Content-length) y esta debe ser correcta. Por suerte la inmensa mayoría de las
implementaciones de clientes xml-rpc rellenan estos datos automáticamente.
El payload (se podría traducir como la carga del mensaje) consiste en xml-rpc
en un xml con una único estructura <methodCall>, esta debe contener un
subelemento <methodName>, que será una cadena y contendrá el nombre del
método invocado, los caracteres válidos son los alfanuméricos, guión bajo, punto, dos
puntos y barra, es responsabilidad únicamente del servidor el cómo interpretar el
nombre del método y los caracteres que éste contenga. Si la llamada al procedimiento
requiere el paso de parámetros estos irán dentro de la etiqueta <param>, esta podrá
contener un número aleatorio de parámetros , cada uno de los cuales además tendrá
un tipo (se verá más adelante y un valor <value>. Los tipos de datos que define el
POST /RPC2 HTTP/1.0 User-Agent: Python 2.7 (WinNT) Host: myhost.com Content-Type: text/xml Content-length: 181
<?xml version="1.0"?> <methodCall> <methodName>ejemplos.getWeather</methodName> <params> <param> <value><i4>41</i4></value> </param> </params> </methodCall>
43
estándar xml-rpc se pueden dividir en escalares, estructuras y arrays. Veamos con
detalle cada uno de ellos:
Etiqueta Tipo Ejemplo
<i4> ó <int> Entero con signo de 4 bytes -12
<boolean> 0 (false) ó 1 (verdadero) 1
<string> String, cadena de texto Hola mundo
<double> Número con signo y doble precisión de
coma flotante
-12.332
<dateTime.iso8601>
Fecha y hora 19980717T14:08:55
<base64> Datos binarios codificados en base64 eW91IGNhbid0IHJlY
Vemos que que se pueden usar como parámetros los tipos de datos básicos
más usuales, también observamos que los datos en binario usan una codificación en
base64, en ésta cada conjunto de 6 bits del archivo binario se identifica con un
carácter US-ASCII, otras aplicaciones conocidas de la codificación base64 son los tipos
MIME en el protocolo de correo SMTP (los adjuntos en el correo electrónico). Como
ventaja esta codificación nos permite encapsular fácilmente datos binarios dentro de
un archivo de texto (que es lo que es, al fin y al cabo, un documento xml, aunque éste
tenga que cumplir con ciertas normas estructurales), como desventaja más relevante
cabe destacar que esta codificación incrementa, en media, el tamaño de la
información a transmitir en un 33%.
44
Los datos de tipos complejos que soporta el protocolo xml-rpc son estructuras
(structs) y vectores (arrays), veamos como se codificaría cada uno de ellos:
Cada <struct> contiene uno o varios <member>s los que a su vez deben
contener un nombre y un valor (<name> y <value>), el valor de cada miembro debe ser
bien uno de los tipos básico, bien una estructura o un array. Cada miembro puede ser
identificado aleatoriamente haciendo uso de su nombre. Por el contrario el uso de una
estructura no garantiza que cada miembro ocupe siempre la misma posición, es decir,
en el ejemplo anteriror, limiteInferior no tiene porqué ocupar siempre la primera
posición, esta es la diferencia fundamental entre este tipo de datos y los arrays,
El otro tipo de datos complejos que admite xml-rpc son los vectores (<array>s)
a continuación vemos cómo se codifican:
Lo primero que destacamos es que los <array>s no tienen miembros
diferenciados con nombres distintos como las estructuras, en su lugar tienen un único
elemento <data>, el cual puede contener un número indeterminado de <value>s,
como diferencia relevante con las estructuras, los distintos valores de un array no
tienen nombre, y por lo tanto solo pueden ser accedidos secuencialmente. Al igual que
<struct> <member> <name>limiteInferior</name> <value><i4>18</i4></value> </member> <member> <name>limiteSuperior</name> <value><i4>139</i4></value> </member> </struct>
<array> <data> <value><i4>12</i4></value> <value><string>Egypt</string></value> <value><boolean>0</boolean></value> <value><i4>-31</i4></value> </data> </array>
45
en las estructuras cada uno de los valores de un array puede ser cualquier otro tipo de
dato, incluyendo las estructuras y otros arrays.
Acabamos de analizar en detalle cómo sería una petición xml-rpc, veamos
ahora cómo sería una respuesta:
En la primera línea de la respuesta siempre figurará el protocolo HTTP (y la
versión usada en la respuesta) así como el código de respuesta, excepto en caso de un
error de bajo nivel la respuesta siempre será 200 OK. Al ser xml-rpc un protocolo
basado en HTTP es un protocolo de petición y respuesta, es decir cada respuesta cierra
automáticamente la conexión y no se guarda ninguna información entre distintas
peticiones relativas a estas, si se quiere usar otro tipo de comportamiento deberá ser
implementado por las capas superiores, el protocolo no proporciona funciones para
algo parecido a las “sesiones”. Como en el caso de la petición Content-Type debe ser
text/xml y Content-Lentgh debe estar presente y tener el valor correcto.
El cuerpo de la petición será nuevamente xml con una única estructura del tipo
<methodResponse>, el cual contiene, y esta es una peculiaridad importante de
este protocolo, un único parámetro <param>, es decir cada método obtiene una sola
respuesta y esta respuesta lleva como resultado un único parámetro. Por suerte
hemos visto que xml-rpc incorpora soporte para tipos de datos estructurados, lo que
nos permitirá usarlos en la respuesta de los métodos y simular así el paso de varios
parámetros distintos en la respuesta como miembros simples de un tipo de datos
compuesto (estructura o array). La etiqueta <methodResponse> puede no
contener el subelemento <param> y en su caso presentar el elemento <fault>
(uno de los dos siempre debe aparecer), esto ocurriría en caso de que se hubiera
HTTP/1.1 200 OK Connection: close Content-Length: 158 Content-Type: text/xml Date: Fri, 12 Oct 2012 19:55:08 GMT Server: myServer.com Linux Debian 3.2 <?xml version="1.0"?> <methodResponse> <params> <param> <value><string>Nublado</string></value> </param> </params> </methodResponse>
46
producido un error durante la ejecución del procedimiento, a continuación vemos en
detalle en qué consistiría una respuesta de error:
En caso de fallo <methodResponse> contiene un elemento <fault>, que
a su vez contiene un único valor <value>, el cual es una estructura con dos
miembros, <faultCode> el cual contiene un código predefinido relacionado con el
error producido y pensado para ser procesado automáticamente y <faultString>
que contiene una cadena descriptiva del error destinada a un usuario humano. Xml-rpc
no define por sí mismo los códigos de erros, esa tarea recae completamente en la capa
de aplicación, la inmensa mayoría de las implementaciones prácticas de xmlrpc ya
define por el usuario los códigos de error, siendo bastantes de ellos aceptados como
estándar de facto.
Una vez visto en detalle cómo opera el protocolo xmlrpc rseñemos algunas de
sus peculiaridades y las consecuencias que éstas tendrán en el desarrollo de nuestro
sistema.
Para empezar hemos dicho que xml-rpc opera sobre HTTP, el cual a su vez
funciona sobre TCP, este hecho trae consigo varias implicaciones reseñables. El
HTTP/1.1 200 OK Connection: close Content-Length: 426 Content-Type: text/xml Date: Fri, 12 Oct 2012 19:55:02 GMT Server: myServer.com Linux Debian 3.2 <?xml version="1.0"?> <methodResponse> <fault> <value> <struct> <member> <name>faultCode</name> <value><int>4</int></value> </member> <member> <name>faultString</name> <value><string>Too many parameters.</string></value> </member> </struct> </value> </fault> </methodResponse>
47
primero de ellos es que HTTP es un protocolo stateless, es decir es un protocolo sin
estados, cada petición-respuesta es una entidad única que no guarda relación con las
anteriores o siguientes. Xml-rpc asume este hecho y lo conserva, no implementa
ningún mecanismo de permanencia de información entre distintas peticiones ni una
funcionalidad similar a las “sesiones” que implementan los navegadores web
modernos, simplemente ofrece una llamada a un método y una respuesta a esa
llamada, en principio esto casa perfectamente con la filosofía del paradigma cliente-
servidor. Si en algún momento quisiéramos implementar algún tipo de diálogo entre el
cliente y el servidor sería tarea nuestro como diseñadores del sistema ocuparnos de él,
en una primera aproximación nuestros requerimientos no incluyen este tipo de
comportamiento, por lo que el protocolo es adecuado a nuestras necesidades. Otra
consecuencia directa del uso de HTTP y TCP (a diferencia de otros protocolos que usan
diferentes medios de transporte en la red) es que estos protocolos nos garantizan que
la información (la petición xmlrpc en este caso) llega a su destino y que llega en orden,
por lo que nos podemos despreocupar de esta casuística; por el contrario esto lo
consigue a costa de implementar un mecanismo de retransmisión que, bajo ciertas
circunstancias, puede suponer una considerable sobrecarga de la red. Para evitar esto
los sistemas que hacen uso de HTTP implementan conjuntamente dos mecanismos: el
tiempo de caducidad (timeout, tiempo máximo que se espera a una respuesta hasta
que el sistema considera que esta se ha perdido y solicita la retransmisión) y el número
máximo de reintentos (max. retries, donde se le indica al sistema cuál es el número
máximo de veces que se puede solicitar la retransmisión hasta concluir que no es
posible realizar la petición en ese instante y devolver un error a la capa superior).
Aunque el protocolo xmlrpc no define propiamente ningún valor para estos
parámetros, la mayoría de las implementaciones definen valores razonables para los
mismos, por lo que, salvo casos excepcionales, no deberemos preocuparnos en exceso
por ellos.
Cuando se diseñó el protocolo xml-rpc se plantearon unos objetivos que
hicieron que se decidiera implementar sobre HTTP, estos son:
• Firewalls: Se pretende que el protocolo funcione en distintos entornos
de red sin necesidad de configuraciones especiales. Las peticiones Post
de HTTP son capaces de operar a través de cualquier infraestructura de
red de manera totalmente transparente.
• Detectabilidad: Se pretende usar un formato limpio, extensible y muy
simple. Debería ser posible para alguien con conocimientos de HTML el
48
mirar un archivo que contuviera una llamada a procedimiento de xml-
rpc y enteder qué es lo que hace y cómo funciona. Así como ser capaz
de modificarlo tras un intento o dos.
• Fácil de implementar: Fácil de llevar a la práctica y adaptar a diferentes
entornos y sistemas operativos.
Por todos estos motivos se usa xmlrpc sobre HTTP, lo que conlleva las
consecuencias que acabamos de ver, a continuación podemos observar una torre de
protocolos de un servicio remoto implementado haciendo uso de xmlrpc comparado
con la torre clásica tcp/ip.
Tras haber estudiado con detenimiento el protocolo xmlrpc pasaremos a
describir sus principales puntos fuertes y debilidades, así como a justificar su elección
para el desarrollo de este proyecto frente a otras alternativas.
A modo de resumen enumeraremos las ventajas y desventajas de este
protocolo, teniendo siempre en cuenta los objetivos del sistema que pretendemos
desarrollar:
� Ventajas
- Multilenguaje.
- Estándar.
Ilustración 12: Torre de protocolos TCP/IP y xmlrpc.
49
- Multiplataforma.
- Extensa documentación.
- Versátil.
- Simplicidad.
- Uso de http, abstracción peculiaridades de la red
� Desventajas
- Uso de ancho de banda ineficiente. (especialmente con datos
binarios).
- No permite el trabajo directamente con objetos.
- Solo devuelve un parámetro en la respuesta.
Revisando los objetivos de nuestro sistema vemos que el número uno es la
simplicidad y la facilidad de adopción del mismo por personal no familiarizado con el
mismo. Este precisamente es, como acabamos de ver, uno de los objetivos de diseño
de xmlrpc, que logra con bastante éxito. El único protocolo de los estudiados que se le
puede aproximar en sencillez es json-rpc (que tiene la ventaja de un uso más eficiente
del ancho de banda), por el contrario xml-rpc gana por goleada en calidad y cantidad
de la documentación, lo que no hace sino reforzar la impresión de que hemos escogido
el mejor protocolo en cuanto a simplicidad y legibilidad. También observamos que
usando xmlrpc podremos abstraernos completamente de la complejidad de la red, lo
cual en un entorno como el centro de cálculo donde, como hemos visto, la gestión de
la red no depende completamente del centro es un gran beneficio, además
independizar las aplicaciones de la configuración de la red debería ser siempre un
objetivo básico, objetivo que garantizamos cumplir simplemente con la elección del
protocolo. El resto de objetivos también los cumple al ser un sistema extendido,
estándar, que funciona perfectamente en cualquier sistema operativo, cuenta con
implementaciones probadas y sólidas en todos (o casi todos) los lenguajes que se nos
puedan ocurrir (siendo éstas además bastantes simples de usar, hecho derivado de la
simplicidad del protocolo) y además cuenta con una ingente cantidad de
documentación disponible en la red.
Por el lado de las desventajas que nos puede acarrear la elección de este
protocolo está el hecho de que sea un protocolo de llamada a métodos (es decir su uso
consiste en invocar una función en otro equipo) y no permitir el uso de objetos o
modos más complejos y potentes de funcionamiento. La realidad es que esto no es
realmente una desventaja, sino un requerimiento de nuestro sistema, se deseaba
diseñar un sistema simple que permitiera la ejecución de ciertos procedimientos en
otros equipos (que es exactamente lo que nos permite xml-rpc), en ningún momento
50
hemos pretendido compartir objetos, memoria u otras estructuras entre dos
máquinas, aunque de utilidad en ciertas ocasiones, carece de ella en el proyecto que
tenemos entre mano. Tenemos también el incoveniente de que solo devuelva un
parámetro en la respuesta de cada método, esto podría suponer un grave problema a
primera vista, pero la existencia de los tipos compuestos (structs y arrays) en xml-rpc
hará que podemas implementar mecanismos de serialización/desserialización en
nuestro sistema de tal forma que el diseñador de los servicios se abstraiga
completamente de esta peculiaridad. Por último tenemos el problema del uso
ineficiente del ancho de banda, realmente este si es un aspecto en el que xml-rpc no
destaca precisamente, penalizando especialmente el trabajo con archivos (impone la
sobrecarga de la codificación en base64 y la del fichero xml, además de no
implementar mecanismos demasiado robustos de control de errores), este problema
resulta asumible por los siguientes motivos: el sistema de procedimientos remotos que
estamos diseñando no pretende en un primer momento realizar un uso intensivo de
archivos binarios, si estos se usan normalmente será de un tamaño pequeño y la
capacidad de red en la que se va a usar el sistema tiene capacidad más que suficiente
como para que nos podamos despreocupar de que la transmisión de información no
sea óptima.
Por todos los motivos expuestos con anterioridad y poniendo en una balanza
los pros y contras del protocolo, basaremos el diseño de nuestro sistema de
procedimientos remotos en xml-rpc, sobre el que contruiremos una suerte de
infraestructura común para satisfacer los otros requisitos de diseño y facilitar su
adopción en el entorno de trabajo donde nos encontramos.