XMLRPC y SOAP - Web Services
Surgimiento de XMLRPC y SOAP.
El surgimiento de XMLRPC/SOAP tiene sus raíces en la manera que son
invocados procedimientos remotos en diversos sistemas de computo, por ende es
conveniente describir este proceso.
Diversos Sistemas Operativos y Lenguajes
La gran mayoría de las corporaciones van conformando su sistema de información através
de las necesidades que surgen en distintas áreas de operación, esto trae consigo una
disparidad en áreas que varían desde lenguajes, protocolos de comunicación, sistemas
operativos , bases de datos y otros elementos, esta discrepancia no seria tan crítica si los
diversos sistemas pudieran permanecer aislados, sin embargo, la realidad es otra.
Esta comunicación entre sistemas heterogéneos presenta el siguiente problema:
El sistema del departamento de Compras esta en Windows/Visual Basic y requiere
información del departamento de Contabilidad que utiliza HP-UX/Oracle, el nuevo
departamento de Web requiere acceso tanto al de Contabilidad y Compras para desplegar
información de clientes pero éste ya se encuentra en el flexible y portable lenguaje Java;
las incongruencias se hacen evidentes desde privilegios de acceso (seguridad)
, representación de datos, transacciones y otra gran gamma de posibilidades.
La solución por excelencia: CORBA,complicado y costoso.
La manera en que muchas empresas aislan sus sistemas de este tipo de consecuencias
es através de CORBA ("Common Object Request Broker Architecture") , através de
CORBA se logra una interoperabilidad de sistemas, sin embargo, esta interoperabilidad
tiene su costo.
El entrar en los detalles específicos de un diseño CORBA serian excesivos, sin embargo,
basta decir que antes de programar en "x" lenguaje, debe ser llevado un diseño en un
lenguaje llamado IDL ("Interface Definition Language"), esto por si solo es una ardua labor,
posteriormente debe realizarse el diseño (vía el IDL) en el lenguaje especifico, instalar un
software llamado ORB ("Object Request Broker") que aisla a los diversos sistemas y
finalmente coordinar toda esta instalación. Obviamente lo anterior requiere no solo trabajo
extenso, sino un conocimiento exhausto acerca de las implicaciones que trae a un sistema
CORBA (Seguridad, Transacciones, y otras consideraciones); entre el mundo de
XMLRPC/SOAP y esto se simplifica.
Através de XMLRPC/SOAP se logra que el intercambio de información sea llevado acabo
en XML, aquí se esta tomando el primer paso en sencillez: la representación de datos no
posee ningún formato especifico ya que XML es texto-simple; aunado a esto
XMLRPC/SOAP ha sido diseñado alrededor de HTTP (el protocolo utilizado en Internet),
esto no sólo facilita el problema de acceso("Firewalls") que siempre es un problema en
sistemas CORBA, sino que abre la puerta a la posibilidad de acceder métodos remotos en
maquinas de cualquier empresa, en el proceso automatizando intercambios de información
de una manera transparente.
XMLRPC o SOAP, cual es la diferencia ?
XMLRPC fue el primer mecanismo que surgió para invocar procedimientos remotos vía
XML, ofrece una manera muy sencilla de invocar operaciones en sistemas heterogéneos
através de una estructura simple; SOAP ("Simple Object Access Protocol") es una
implementación más robusta para llevar acabo una intercomunicación en XML, a diferencia
de XMLRPC a SOAP se le han integrado diversos mecanismos que le permiten operar en
ambientes distribuidos mas complejos tales como: un lenguaje neutro para su descripción (
WSDL/"Web Services Description Language" ) y directorios distribuidos para su ubicación
(UDDI/"Universal Discovery, Description and Integration" o ebXML/"Electronic Business
XML Working Group"); en las siguientes secciones serón ejemplificados los usos de ambas
tecnologías.
Arquitectura de XMLRPC.
En XMLRPC siempre se habla en términos de cliente/servidor, existe un sistema que
realiza la solicitud ("el cliente") y otro que la atiende ("el servidor"), y como es de
imaginarse un elemento clave en ambos puntos es:el parser XML.
Implementaciones de XMLRPC.
Aunque es posible diseñar desde cero cualquier tipo de cliente y/o servidor para emplear
XML, hoy en día ya existen diversas implementaciones para diversos ambientes y
lenguajes , es através de estas implementaciones que se logran ahorrar diversas labores
como configuraciones de parser, cuestiones de seguridad, integración a servidores de
paginas y otros detalles secundarios, utilizando estas estructuras ("Frameworks") se
concentra en los procedimientos específicos y no en detalles comunes o secundarios que
siempre son utilizados en XMLRPC.
Algunas implementaciones:
XMLRPC Apache ( http://ws.apache.org/xmlrpc/ ) para el lenguaje "Java" .
Frontier::RPC ( http://www.cpan.org ) para el lenguaje "Perl" .
XMLRPC-PHP ( http://sourceforge.net/projects/phpxmlrpc/ ) para el lenguaje "PHP" .
XMLRPC-Python ( http://www.pythonware.com/products/xmlrpc/ ) para el lenguaje "Python" .
XMLRPC-C ( http://xmlrpc-c.sourceforge.net/ ) para los lenguajes "C" y "C++" .
XMLRPC-ASP ( http://aspxmlrpc.sourceforge.net ) para el lenguaje "COM/VBasic" .
Arquitectura de SOAP.
SOAP esta diseñado para llevar acabo intercambios de información en XML para sistemas
altamente distribuidos, en especifico: "Internet". Uno de los conceptos integrados a SOAP
que no existe en XMLRPC es el uso de un lenguaje neutro (descendiente de XML) para
describir las funciones/métodos residentes en "el servidor", esto tiene una ventaja muy
evidente:
Al utilizar un lenguaje neutro(WSDL/"Web-Services Description Language") para
describir las funcionalidades de "el servidor", éste funciona como un contrato al
que se deben apegar los distintos "clientes"; lo anterior facilita que puedan ser
escritos "clientes" en diversos lenguajes a partir de este contrato.
Como se puede observar en la gráfica anterior, a partir de WSDL ("Web-Services
Description Language") se describen las funcionalidades del web service, en XMLRPC es
necesario conocer de antemano que funciones/métodos residen en "el servidor" y no solo
esto, sino que además se requiere conocer el lenguaje en el que esta escrito "el servidor",
através de WSDL se logra aislar el lenguaje especifico del web service.
Además del uso de WSDL("Web-Services Description Language"), a SOAP se le ha
incorporado UDDI("Universal Description, Discovery and Integration Directory"); el principio
de UDDI radica en el intercambio comercial entre empresas denominado "E-Business",
atrvés de UDDI se logra concentrar y publicar web services en un directorio centralizado;
además de UDDI existen otros mecanismos para concentrar y publicar web-services tales
como ebXML y WSIL.
De esta manera si usted posee 5 o 10 web services tales como: Ofrecer estado de tiempo,
cotizaciones sobre sus productos comerciales, procesamiento de transacciones financieras
u otro más, es posible publicarlos a un directorio UDDI, permitiendo que estos sean
descubiertos en un directorio conocido y centralizado.
Este mecanismo facilita el intercambio comercial por un medio electrónico, algo que resulta
difícil através de XMLRPC ya que no existe una metodología para descubrir servicios en
una red como Internet; desde luego un desarrollo con SOAP es sumamente más complejo
que con XMLRPC, esto se debe principalmente a que se debe interactuar con tecnologías
adicionales como WSDL y UDDI, pero a su vez ofrece mayor flexibilidad y potencial a
escala.
Implementaciones de SOAP.
Al igual que XMLRPC, hoy en día ya existen diversas herramientas para desarrollar
aplicaciones SOAP que incluyen generadores de WSDL para distintos lenguajes,
servidores UDDI y otros paquetes más; algunas de estas herramientas son:
Toolkit IBM web services ( http://www.alphaworks.ibm.com/tech/webservicestoolkit ) para el lenguaje Java.
Toolkit Microsoft SOAP ( http://msdn.microsoft.com/webservices/ ) para "COM/VBasic/.Net".
Soap::Lite ( http://www.soaplite.com ) para el lenguaje Perl .
Web services Pack de Sun ( http://java.sun.com/webservices/webservicespack.html) para el lenguaje Java.
WASP ( http://www.systinet.com ) para los lenguajes C++ y Java.
¿Qué es un Servicio Web?
El consorcio W3C define los Servicios Web como sistemas software diseñados
parasoportar una interacción interoperable maquina a maquina sobre una red. Los
ServiciosWeb suelen ser APIs Web que pueden ser accedidas dentro de una red
(principalmenteInternet) y son ejecutados en el sistema que los aloja.La definición de
Servicios Web propuesta alberga muchos tipos diferentes de sistemas,pero el caso común
de uso de refiere a clientes y servidores que se comunican mediantemensajes XML que
siguen el estándar SOAP.En los últimos años se ha popularizado un estilo de arquitectura
Software conocidocomo REST (Representational State Transfer). Este nuevo estilo ha
supuesto una nuevaopción de estilo de uso de los Servicios Web. A continuación se listan
los tres estilos deusos más comunes:
Remote Procedure Calls (RPC, Llamadas a Procedimientos Remotos): LosServicios Web
basados en RPC presentan una interfaz de llamada aprocedimientos y funciones distribuidas, lo
cual es familiar a muchosdesarrolladores. Típicamente, la unidad básica de este tipo de servicios
es laoperación WSDL (WSDL es un descriptor del Servicio Web, es decir, elhomologo del IDL
para COM).
Las primeras herramientas para Servicios Web estaban centradas en esta visión.Algunos lo
llaman la primera generación de Servicios Web. Esta es la razón porla que este estilo está muy
extendido. Sin embargo, ha sido algunas vecescriticado por no ser débilmente acoplado, ya que
suele ser implementado pormedio del mapeo de servicios directamente a funciones específicas
del lenguajeo llamadas a métodos. Muchos especialistas creen que este estilo debedesaparecer.
Arquitectura Orientada a Servicios (Service-oriented Architecture, SOA). LosServicios Web
pueden también ser implementados siguiendo los conceptos de laarquitectura SOA, donde la
unidad básica de comunicación es el mensaje, másque la operación. Esto es típicamente
referenciado como servicios orientados amensajes.Los Servicios Web basados en SOA son
soportados por la mayor parte dedesarrolladores de software y analistas. Al contrario que los
Servicios Webbasados en RPC, este estilo es débilmente acoplado, lo cual es preferible ya quese
centra en el “contrato” proporcionado por el documento WSDL, más que enlos detalles
de implementación subyacentes.
REST (Representation State Transfer). Los Servicios Web basados en RESTintentan emular al
protocolo HTTP o protocolos similares mediante larestricción de establecer la interfaz a un
conjunto conocido de operaciones
REST vs Web Services 4/19estándar (por ejemplo GET, PUT,…). Por tanto, este estilo se centra
más eninteractuar con recursos con estado, que con mensajes y operaciones
¿Cuáles son las características de REST y SOAP endefinitiva?
Según hemos visto a lo largo del documento, el principal beneficio de SOAP recae enser
fuertemente acoplado, lo que permite poder ser testado y depurado antes de poner
enmarcha la aplicación. En cambio, las ventajas de la aproximación basada en
RESTrecaen en la potencial escalabilidad de este tipo de sistemas, así como el acceso
conescaso consumo de recursos a sus operaciones debido al limitado número
deoperaciones y el esquema de direccionamiento unificado.A modo de resumen, veamos
las características de ambas aproximaciones en lasiguiente tabla:
