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.