Para ejemplificar el uso de web services vía SOAP se llevará acabo un diseño en Java mediante el "SOAP Engine" Axis; Axis es una implementación Open-Source desarrollada por la fundación Apache que permite la ejecución de web services en un "Servlet-Engine" como Tomcat.
Una de las principales ventajas de web services es que permite publicar funcionalidades/métodos ya existentes en un sistema, através de Axis y otros "SOAP Engines" es posible publicar estas funciones existentes para que sean invocadas de sistemas heterogéneos.
La Clase/método que será publicado como web service se describe a continuación:
Al igual que los diseños llevados acabo con XMLRPC, a continuación se programa un Cliente escrito en Java que realiza llamadas al web service previamente descrito.
Cliente PDVSA.java utilizado como Cliente de web service para cotización de Petróleo.
Mensajes SOAP enviados entre Servidor/Cliente de web service para cotización de Petróleo
Aunque dicho Cliente es capaz de accesar los servicios de Axis, su diseño se ha llevado acabo conociendo de antemano los detalles específicos del web service, esto es: los directorios de acceso, dominio y parámetros de entrada. Sin embargo, debido al ambiente distribuido de web services este tipo de detalles generalmente son difíciles de obtener y por ende se utilizan diversos mecanismos para facilitar su descubrimiento y acceso.
El diseño de Clientes en SOAP generalmente es llevado acabo a partir de un archivo escrito en WSDL ("Web Services Description Language"), a través de una definición de este tipo es posible distribuir los detalles del web service en un lenguaje neutro, lo cual permite que la definición (Cliente) sea implementada en distintos lenguajes y ambientes tales como: C++, Perl o VBasic/.NET.
WSDL también se encuentra basado en el lenguaje XML y este es generado a partir de diversas herramientas proporcionadas en distintos ambientes SOAP, a continuación se describe como es generado un archivo WSDL através de herramientas proporcionadas con Axis:
A pesar que ya fue generado un archivo WSDL para nuestro web service y este podrá ser accesado de diversas plataformas y lenguajes, existe otro eslabón crítico para desarrollos SOAP y este es: UDDI ("Universal Description, Discovery and Integration Directory") o ebXML ("Electronic Business XML Working Group").
UDDI surgió con la intención de centralizar web services comunes, así como ofrecer un deposito central donde se puede acudir a realizar búsquedas de web services específicos, las metodologías que han sido descritas anteriormente solo permiten que el web service sea descubierto siempre y cuando nos sea proporcionado el archivo WSDL.
UDDI ha sido desarrollado por un grupo de empresas entre las que figuran principalmente Microsoft, IBM y SAP, estas compañias así como algunos otros consorcios se encargan de mantener y ofrecer este tipo de servicios en Internet, algunos directorios de prueba que puede utilizar son los siguientes:
ebXML es otro tipo de registro para web services que surgió previo a UDDI y es desarrollado por OASIS ("Organization for the Advancement of Structured Information Standards") asi como la división de las Naciones Unidas CEFACT ("United Nations Centre for the Facilitation of Procedures and Practices in Administration, Commerce and Transport").
Puede consultar mayores detalles de ebXML en : http://www.ebxml.org
Para accesar un directorio UDDI o ebXML generalmente se utiliza un Navegador ("Netscape" o "Explorer") para dar de alta los respectivos web services por lo que su uso es relativamente sencillo, sin embargo, aunque un Navegador ("Netscape" o "Explorer") sea la forma clásica de accesar Directorios para web services" existen otros mecansimos como JAXM ("Java API for XML Registries") que permiten accesar este tipo de directorios de una manera programática.
WSIL es una especificación muy reciente iniciada por IBM y Microsoft que ofrece un mecanismo complementario a UDDI y ebXML para encontrar web services en una red como Internet. Existen dos razones principales por las que surgió WSIL:
Falta de Moderación : Debido a la misma escalabilidad con la que fue diseñado UDDI, existe una clara falta por moderar los web services que son publicados en este tipo de Directorios, lo anterior trae consigo la publicación de "Web Services Description Language/(WSDL)" invalidos, la duplicidad de WSDL e inclusive la publicación de web services no disponibles.
Falta de Calidad de Servicio (QoS) : Este punto aunque relacionado con el anterior se refiere a la garantia del servicio ofrecido por el proveedor del web service, esto es, debido a que UDDI es un directorio público en Internet, quién garantiza que el web service utilizado o comprado cumpla con determinados requerimientos ?. Esto nos lleva al antiguo concepto de negocios: Comprar o adquirir a quien ya conocemos, y es precisamente en este principio en el que esta basado WSIL.
A diferencia de UDDI donde se realizan busquedas en un directorio centralizado, mediante WSIL se inspecciona un "Web-Server" conocido realizando una búsqueda por web services y es mediante archivos escritos en WSIL que se logra su descubrimiento.
Sin embargo, es tan reciente dicha especificación que sus implementaciones son minimas, puede consultar mayores detalles de WSIL en :
template, XPath, Condicionales y Ciclos en XSL.