Los servicios Web [4] (WS) son aplicaciones que pueden ser descritas, publicadas, localizadas e invocadas a través de una red, generalmente Internet. Dicho de una manera más formal, los servicios Web son componentes de software alojados en servidores Web públicos o privados por Internet a los que se accede mediante mensajes del protocolo SOAP (también se podrían usar los mensajes XML-RPC, aunque es SOAP el protocolo más usado actualmente) codificados en formato XML a través de protocolos estándares de aplicación (HTTP, SMTP, FTP, etc.) y que proporcionan un servicio a los correspondientes clientes de software.
Para hacerse una idea rápida de cómo funciona un servicio Web se puede decir que es una llamada a un procedimiento remoto (RPC) basada en HTTP/SOAP.
Los servicios Web se basan en una colección de protocolos y estándares abiertos que sirven para intercambiar datos entre aplicaciones. Las organizaciones OASIS y W3C son los responsables de la arquitectura y reglamentación de los servicios Web. Para mejorar la interoperabilidad entre distintas implementaciones de servicios Web se ha creado el organismo WS-I encargado de definir de manera más exhaustiva estos estándares.
Algunas de las ventajas de los servicios Web son:
También existen algunos inconvenientes como son:
La arquitectura de comunicaciones de los servicios Web (organizada por niveles y protocolos implicados) se puede ver en la siguiente figura.
A continuación se describen los protocolos más importantes de cada nivel
XML-RPC es un protocolo para ejecutar llamadas a procedimientos remotos (RPC) que funciona sobre Internet. XML-RPC funciona mediante el intercambio de mensajes entre el cliente del servicio y el servidor, usando el protocolo HTTP para el transporte de dichos mensajes. Concretamente, XML-RPC utiliza peticiones POST de HTTP para enviar los mensajes, en formato XML, indicando:
El servidor devolverá el resultado en formato XML.
XML-RPC maneja un conjunto de tipos para el paso de parámetros, valores de retorno y errores. Estos tipos se representan mediante etiquetas XML. Existen tipos básicos y tipos compuestos:
Una petición XML-RPC está formada por:
Una repuesta XML-RPC está formada por:
Por último, hay que indicar que al estar basado en XML, XML-RPC es independiente de plataforma y de lenguaje de programación.
Algunas implementaciones XML-RPC son:
Al igual que XML-RPC, SOAP es un protocolo de intercambio de información que usa documentos XML. SOAP es más complejo que XML-RPC aunque también más potente. Algunas de las desventajas de XML-RPC con respecto a SOAP son:
Alguna de las características de SOAP son:
Los mensajes SOAP tienen el aspecto mostrado en la siguiente figura:
A continuación se detalla cada uno de estos elementos:
Al igual que XML-RPC, SOAP también maneja tipos de datos. Los tipos de datos son de dos clases:
Por último, y al igual que ocurría con XML-RPC, existen diversas implementaciones de SOAP. Algunas de las más conocidas son:
El lenguaje de descripción de servicios Web permite describir servicios Web utilizando una gramática XML. Un documento WSDL es en realidad un documento XML que describe algunas características de un servicio Web. La información que proporciona es:
WSDL es el equivalente a IDL (utilizado en RPCs, CORBA, etc.) aunque con algunas diferencias. Las principales son:
Las principales características de WSDL son:
Por último, hay que indicar que no es obligatorio proporcionar el WSDL para poder crear una aplicación cliente-servidor basada en servicios Web, aunque si es recomendable, ya que si lo proporcionamos podremos hacer uso de herramientas que nos permitirán generar el código de las comunicaciones (tanto para el cliente como el servidor) de forma automática y sólo tendremos que centrarnos en desarrollar la lógica de la aplicación.
UDDI es un estándar de un protocolo de descripción, descubrimiento e integración universal que especifica un servicio de directorio o servicio Web. De hecho, los registros UDDI son servicios Web y se accede a ellos, tanto para publicar como para descubrir un servicio Web, a través de SOAP/XML vía HTTP. Por tanto, UDDI dispone de un conjunto de métodos u operaciones para registrar y consultar datos en un registro UDDI. UDDI permite a los programadores y programas buscar servicios Web en tiempo de diseño o ejecución.
Existen dos tipos de registros UDDI:
Un registro UDDI proporciona tres clases de servicios de búsqueda:
Según lo anterior, se puede efectuar búsquedas de organizaciones por nombre y tipo de servicio para después profundizar y descubrir cómo se accede exactamente a un determinado servicio Web; es decir, cómo se obtiene el documento WSDL publicado junto al servicio Web en un servidor Web público (o privado), el cual describe la implementación del servicio.
Los registros UDDI ofrecen un conjunto pequeño de operaciones para registrar y consultar datos. Dichas operaciones son:
Por último, hay que señalar que aunque la mayoría de las implementaciones de registros UDDI son comerciales, existen implementaciones libres como pUDDIng o jUDDI (del grupo Apache).
El servidor Tomcat [5] es un contenedor de servlets con soporte para JSPs. Se trata de un subproyecto Open Source del proyecto Jakarta del grupo Apache. El servidor Tomcat actualmente es la implementación de referencia de las especificaciones de los servlets y los JSPs.
Los servlets son programas que se ejecutan en los servidores y añaden funcionalidad a un servidor Web. Un contenedor de servlets es una shell que está en el lado del servidor y permite ejecutar servlets e invocarlos por parte del usuario (o de otro servlet).
Las páginas de servidor Java (JSPs) es una tecnología orientada a crear páginas Web con código Java incluido. Es una tecnología equivalente a PHP o ASP. Tomcat incluye un motor JSP que está basado en Servlets, ya que con éstos se podría hacer lo mismo que con los JSPs aunque la programación de servlets es mucho más compleja. El motor JSP se encarga de traducir un JSP a un servlet equivalente de forma automática. Normalmente esta traducción se realiza la primera vez que se solicita la página JSP por lo que la primera petición será la más lenta en realizarse.
Podemos dividir los contenedores de servlets en:
Estos contenedores son parte del propio servidor Web. Este caso se da cuando se usa un servidor Web basado en Java y el contenedor de servlets está integrado en el mismo. Este el modo por defecto usado por Tomcat, ya que éste puede ser utilizado como un servidor Web.
El contenedor de servlets es una combinación de un plugin para el servidor Web y una implementación de contenedor Java. El plugin del servidor Web abre una Máquina Virtual Java dentro del espacio de direcciones del servidor Web y permite que el contenedor Java se ejecute en él. Si una cierta petición tuviera que ejecutar un servlet, el plugin tomaría el control sobre la petición y lo pasaría al contenedor Java (usando JNI). Un contenedor de este tipo es adecuado para servidores multithread de un solo proceso y proporciona un buen rendimiento pero está limitado en escalabilidad.
El contenedor de servlets es una combinación de un plugin para el servidor Web y una implementación de contenedor Java que se ejecuta en una JVM fuera del servidor Web. El plugin del servidor Web y la JVM del contenedor Java se comunican usando algún mecanismo de comunicación entre procesos (IPC) como puede ser sockets TCP/IP. Si una cierta petición tuviera que ejecutar un servlet, el plugin tomaría el control sobre la petición y lo pasaría al contenedor Java (usando IPCs). El tiempo de respuesta en este tipo de contenedores no es tan bueno como el anterior, pero obtiene mejores rendimientos en otras cosas (escalabilidad, estabilidad, etc.).
Tomcat puede utilizarse como un contenedor autónomo (principalmente para desarrollo y depuración) o como un plugin para un servidor Web existente (actualmente se soporan los servidores Apache, IIS y Netscape). Esto significa que siempre que instalemos Tomcat tendremos que decidir cómo usarlo. En el caso en que seleccionemos las opciones 2 ó 3, también necesitaremos instalar un adaptador de servidor Web.
Por último, hay que indicar que cuando se usa Tomcat en un entorno de producción no se hace como un contenedor independiente ya que existen algunos problemas:
Axis [12] es una implementación Open Source de la especificación SOAP del W3C. Forma parte del proyecto "Web Services" del grupo Apache. Axis es la evolución de Apache SOAP. La versión actual de Axis está escrita en Java, aunque actualmente se está desarrollando una implementación en el lenguaje C++.
Axis puede funcionar de dos modos diferentes:
Además de esto, la distribución de Axis incluye algunas herramientas como:
Por último, algunas de las ventajas que proporciona Axis son:
