Creación de SOA con servicios web usando WebSphere Studio, parte 1: Introducción a SOA y servicios web

Este tutorial es la primera parte de una serie de introducción a los conceptos y la tecnología de la arquitectura orientada a servicios (SOA) y de los servicios web, y muestra cómo aplicar estos conceptos en la práctica usando IBM WebSphere® Application Developer Integration Edition. Además, en este tutorial se explora el estado actual de la tecnología de servicios web. (Ver todas las partes de esta serie de tutoriales).

Warner Onstine, Senior Mentor, ArcMind

Warner Onstine, Senior Mentor de ArcMind, Inc., es un desarrollador con más de 8 años de experiencia en la industria, la mayor parte de los cuales dedicó al desarrollo de aplicaciones Web. Warner es coautor del libro Professional Java Tools for Extreme Programming, que contiene capítulos sobre Maven, pruebas unitarias en Swing y cobertura de código con jcoverage.



Rick Hightower, Chief Mentor, ArcMind

Rick Hightower, Chief Mentor de ArcMind, Inc., es un desarrollador que ha cosechado múltiples logros, premios de la industria y certificaciones. Es coautor de los libros Professional Jakarta Struts y Java Tools to Extreme Programming, y escribió 1/5 del libro Mastering Tomcat. Rick es autor de numerosos tutoriales bien recibidos sobre EJB 2.0 CMP CMR, XDoclet, Apache Axis, ETTK, WSDK, Struts Tiles, etc. para IBM developerWorks.



05-08-2011

Acerca de este tutorial

Objetivo del tutorial

Este tutorial es la primera parte de una serie de introducción a los conceptos y la tecnología de la arquitectura orientada a servicios (SOA) y de los servicios web, y muestra cómo aplicar estos conceptos en la práctica usando IBM WebSphere Application Developer Integration Edition (Application Developer Integration Edition). Además, en este tutorial se explora el estado actual de la tecnología de servicios web.

Los servicios web son programas que permiten que los sistemas interactúen entre sí a través de una red. Haciendo uso de estándares abiertos y de la potencia de Internet, permiten a las empresas interactuar entre sí más fácilmente que nunca. Las empresas tienen una necesidad cada vez mayor de trabajar estrechamente. Por eso, la capacidad de los servicios web de colaborar con ellas de una manera estándar y bien definida ha generado un enorme interés y muchísima actividad en el ámbito de los servicios web.

Debido a todo el entusiasmo que generan, se podría pensar que los servicios web no son más que una tecnología sobrevalorada. Si bien existe mucha exageración en torno a algunos de sus aspectos, los servicios web y las tecnologías XML subyacentes tienen ciertamente un enorme valor para las empresas actuales.

En esta serie de tutoriales se demostrará que los servicios web y SOA, si bien no son una solución milagrosa, podrían cambiar para siempre la manera de integrar procesos de negocios, tanto procesos de diferentes empresas como procesos internos de una misma empresa. Constituyen el siguiente paso lógico en la evolución de la Web. Con los servicios web, estamos transitando una nueva etapa de negocios a pedido, en la que las empresas pueden intercambiar servicios e integrar procesos de negocios entre sí. Esto lleva la cuestión de la Integración de aplicaciones empresariales (EAI, por sus siglas en inglés) a otro nivel, donde se pueden incorporar múltiples empresas en un único proceso de negocios, así como incorporar más fácilmente múltiples procesos de negocios de una empresa en un único proceso.

Impulsado por estas importantes necesidades de negocios, el mundo de los servicios web está evolucionando rápidamente, y se están generando una gran cantidad de innovaciones, aclaraciones y especificaciones al respecto. Entre los acontecimientos más destacados se encuentran los siguientes:

  • La labor de la Web Services Interoperability Organization (WS-I), una organización abierta de la industria que promueve la interoperabilidad de servicios web en diferentes plataformas, sistemas operativos y lenguajes de programación.
  • El desarrollo de JAX-RPC (API Java para llamada a procedimiento remoto (RPC, por sus siglas en inglés) basada en XML), una especificación estándar conforme a la JSR-101 del Java Community Process. JAX-RPC proporciona la API fundamental para el desarrollo y la implementación de servicios web basados en el protocolo simple de acceso a objetos (SOAP, por sus siglas en inglés) en la plataforma Java.
  • El desarrollo de JSR-921 (Implementing Enterprise Web Services), que actualiza JSR-109, está basada en tres JSR (67, 93 y 101) y define servicios web para la arquitectura de Java 2 Platform, Enterprise Edition (J2EE).
  • El desarrollo de la especificación Web Services Security (WS-Security), que contempla un conjunto estándar de extensiones SOAP y se usa para generar servicios web seguros.

Para ayudar a los desarrolladores en su interés por los servicios web y otras tecnologías de J2EE, IBM lanzó como descarga gratuita una versión de prueba de Application Developer Integration Edition, con soporte técnico para los aspectos más importantes de los servicios web, entre los que se incluyen:

  • Versión incrustada de IBM WebSphere Application Server (Application Server) - Express Versión 5.1, que incluye soporte para el desarrollo con Enterprise JavaBeans (EJB) (solo para uso experimental y ajeno a la producción)
  • Soporte para SOAP 1.1, Web Services Description Language (WSDL) 1.1, EJB 2.0 y Universal, Description, Discovery and Integration (UDDI) Versión 2.0
  • Web Services Description Language for Java (WSDL4J) y API Java (UDDI4J)
  • Soporte para JAX-RPC (JSR-101)
  • Soporte para la arquitectura de JSR-109 para servicios web basados en J2EE
  • Herramientas para crear, describir, implementar, acceder, publicar y descubrir servicios web, entre las que se incluye una base de datos básica para su uso por parte de JDBC
  • Soporte de seguridad tal como se lo define en la especificación WS-Security
  • Soporte para la implementación de servicios web según los perfiles y escenarios definidos en WS-I
  • Un registro UDDI privado compatible con UDDI Versión 2
  • Soporte para la especificación Basic Profile 1.0 de WS-I
  • Documentación, tutoriales y muestras adicionales

En resumen, Application Developer Integration Edition proporciona una plataforma básica que simplifica la creación de sistemas basados en servicios web, permitiéndole explorar este nuevo mundo de servicios web y ver de qué se trata todo el entusiasmo que generan.

En esta serie de tutoriales, usted aprenderá lo fácil que es usar servicios web y cómo empezar a emplear esta tecnología de inmediato con la ayuda de Application Developer Integration Edition. Los tutoriales utilizan un enfoque práctico y se centran en cómo aplicar los conceptos de servicios web fundamentales para proporcionar soluciones reales. Los primeros tutoriales contienen los fundamentos y los siguientes profundizan en la tecnología. Este tutorial, el primero de la serie, ofrece una introducción a los servicios web, instrucciones de instalación, configuración y ejecución de Application Developer Integration Edition y una visión general de las herramientas y capacidades que forman parte de Application Developer Integration Edition.

Conocimientos necesarios para este tutorial

Este tutorial presupone un conocimiento práctico del lenguaje de programación Java y de XML. Si bien no es obligatorio, sí es conveniente contar con un conocimiento de la tecnología J2EE y Ant. Todas las aplicaciones de ejemplo se implementan en la solución incrustada Application Server Express que está incluida en IBM WebSphere Software Development Kit for Web Services (WSDK). Se proporcionan scripts de compilación de Ant para que la generación y la implementación de las aplicaciones de ejemplo sean más fáciles y más confiables. En la sección Recursos, ubicada en la parte final de este tutorial, encontrará referencias a documentos introductorios sobre Ant, el lenguaje de programación Java, XML, WebSphere y la tecnología J2EE.

Contenido de este tutorial

Este tutorial, además de presentar la serie completa de tutoriales, constituye una introducción a los servicios web y a Application Developer Integration Edition. Examina los siguientes temas, herramientas y técnicas:

Temas

  • Fundamentos de Application Developer Integration Edition
  • Compatibilidad WSDL en Application Developer Integration Edition
  • Fundamentos de los servicios web
  • Instalación de Application Developer Integration Edition
  • Generalidades de WSDL, SOAP y UDDI
  • Trabajo con Application Developer Integration Edition

Herramientas

  • Asistente para servicios web de Application Developer Integration Edition
  • Exploración de servicios web de Application Developer Integration Edition (cliente/servidor)

Técnicas

  • Inicio y detención del servidor
  • Obtención de información del servidor
  • Ejecución de una aplicación de muestra
  • Uso del asistente para servicios web de Application Developer Integration Edition para crear un servicio web a partir de un JavaBean

Contenido de la serie completa

Esta serie consiste en una introducción práctica a los servicios web a través de Application Developer Integration Edition. Cada una de las lecciones mantiene un equilibrio entre las descripciones de la tecnología y los laboratorios paso a paso de Application Developer Integration Edition. Los tutoriales, lejos de ofrecer un análisis académico de las tecnologías o especificaciones de los servicios web, se centran en la solución de problemas específicos. La intención no es que usted simplemente sepa cómo usar estas herramientas y tecnologías, sino que además aprenda cuándo es necesario aplicar cada una de ellas para resolver problemas reales. Esta serie consta de los siguientes tutoriales:

Introducción a los servicios web y a Application Developer Integration Edition Versión 5.1

  • Fundamentos de los servicios web XML
  • Descarga, instalación y ejecución de Application Developer Integration Edition
  • Introducción a SOAP, WSDL y UDDI
  • Características y herramientas de Application Developer Integration Edition

Construcción de un modelo de lenguaje unificado de modelado (UML) y generación de código Java a partir de ese modelo con Application Developer Integration Edition Versión 5.1

  • Introducción al modelado UML
  • Laboratorio: Creación de un modelo UML
  • Laboratorio: Creación de código Java a partir del modelo UML

Creación de un servicio web a partir de una clase Java con Application Developer Integration Edition Versión 5.1

  • Introducción a JAX-RPC
  • Exposición de una clase Java como servicio web
  • Laboratorio: Creación de un servicio web a partir de una clase Java simple
  • Application Developer Integration Edition y componentes JSR-109
  • Laboratorio: Creación de un servicio web a partir de una clase Java con tipos complejos
  • Descripción de servicios web con WSDL
  • Arquitectura WSDL (con estilos de mensajería y codificación)
  • Asignación entre WSDL y lenguaje de programación Java
  • Profundización en WSDL y WSDL4J
  • Laboratorio: Descripción de servicios web a través de la publicación de servicios con UDDI y WSDK 5.1
  • API de publicación UDDI
  • Proceso de publicación: definición de interfaz, implementación, generación de WSDL y publicación del servicio
  • Configuración del registro UDDI WSDK
  • Publicación de servicios en el registro
  • Laboratorio: Publicación de servicios web

Descubrimiento de servicios web con UDDI y Application Developer Integration Edition Versión 5.1

  • Profundización en UDDI y UDDI4J
  • API de consulta UDDI
  • Proceso de descubrimiento: búsqueda, generación de interfaz e implementación
  • WSDK, descubrimiento de servicios e invocación de servicios
  • Laboratorio: Descubrimiento de servicios web

Acerca de los laboratorios de esta serie

Posiblemente, usted habrá escuchado hablar de los antipatrones de software. Bueno, también existen antipatrones de código de ejemplo. Por un lado, está el patrón de dominio demasiado complicado, en que el dominio presentado en el ejemplo es más complejo que la tecnología que se pretende aprender o bien demasiado oscuro para demostrar lo que el ejemplo pretende enseñar. Los laboratorios se esfuerzan mucho por evitar este patrón y eligen un dominio simple que sea intuitivamente obvio.

Después está el patrón en que los pasos 1-4 son tan obvios que no requieren explicación. Lo que es intuitivamente obvio para una persona puede no serlo para otra, y cuando las cosas no funcionan bien, uno quiere una explicación paso a paso. Por eso, los laboratorios hacen todo lo posible por nunca omitir un solo paso. Si usted desea saltearse algunos pasos, tiene toda la libertad para hacerlo. Sin embargo, las instrucciones paso a paso están presentes en todos los laboratorios.

Por último, está el patrón demasiado simple para usarlo en la vida real. Este patrón es, por lo menos al principio, inevitable. Para combatir este antipatrón, los laboratorios, a medida que avanza esta serie de tutoriales, se vuelven cada vez más realistas (y complejos). Por ejemplo, el primer laboratorio es apenas más complejo que un Hola a todos; sin embargo, los laboratorios posteriores usan tipos complejos, intermediarios, seguridad y mucho más. Al finalizar esta serie, usted debería sentirse seguro para abordar problemas reales de servicios web y realizar las siguientes tareas:

  • Consumir un servicio web
  • Generar servicios web al estilo RPC
  • Exponer componentes JavaBeans y Enterprise Java Bean (EJB) como servicios web
  • Crear componentes JavaBean y EJB que consuman servicios web
  • Describir, descubrir y publicar servicios web

Usted debería poder hacer todo esto después de algunos tutoriales con laboratorios. Es probable un tutorial le lleve uno o dos almuerzos.

Todos los tutoriales están centrados en un videoclub. El sistema incluido en los tutoriales permite que el usuario elija qué categoría de película le gustaría alquilar; sobre la base de su historial de alquileres, el servicio web le sugerirá otras películas. El sistema arranca de manera simple: la primera implementación devuelve una cadena codificada de forma rígida que muestra cómo escribir un servicio web con Application Developer Integration Edition. Las versiones posteriores del mismo servicio web envían una matriz de objetos de DVD. Finalmente, se registran los servicios en un registro UDDI y se asegura el sistema.

Herramientas necesarias para este tutorial

Como mínimo, es necesario contar con Java SDK 1.3.1 para ejecutar Application Developer Integration Edition Versión 5.1.

Novedades de Application Developer Integration Edition Versión 5.1
Application Developer Integration Edition agrega compatibilidad con Business Process Execution Language for Web Services (BPEL4WS), conectividad con sistemas back-end a través de J2EE Connector Architecture, beans de reglas de negocios y extensiones del modelo de programación. Al basarse en la popular plataforma Eclipse, Application Developer Integration Edition también se beneficiará de un excelente entorno de desarrollo integrado (IDE, por sus siglas en inglés).

Application Developer Integration Edition Versión 5.1 incluye:

  • Interfaz de usuario basada en Eclipse
  • Entorno de desarrollo para BPEL4WS
  • Entorno de desarrollo para J2EE
  • Entorno de desarrollo para Java
  • Entorno de desarrollo para servicios web
  • Entorno de desarrollo para XML
  • Herramientas para bases de datos relacionales
  • Entorno de desarrollo Web
  • Desarrollo en equipo
  • Herramientas del servidor para prueba e implementación
  • Herramientas de seguimiento, supervisión y análisis de rendimiento
  • Depurador

Específicamente, Application Developer Integration Edition tiene numerosas herramientas para trabajar con servicios web, que utilizaremos en los diferentes tutoriales:

  • Editor de WSDL
  • Web Services Explorer
  • Descubra: exploración de registro UDDI
  • Asistente para servicios web para crear y transformar servicios web a partir de JavaBeans, EJB y URL externas que devuelven datos, procedimientos almacenados y consultas SQL
  • Implemente servicios web en entornos de prueba Application Server o Tomcat
  • Publique servicios web en un registro UDDI privado o público
  • Compatibilidad con UDDI Versión 2, SOAP, WSDL y Web Services Invocation Language (WSIL)
  • Compatibilidad con tiempo de ejecución de Apache Axis 1.0

Breve introducción a Application Developer Integration Edition (Eclipse)
Eclipse es un IDE de código abierto que se puede descargar desde el sitio Web principal de Eclipse (ver Recursos). Eclipse consiste en una plataforma extensible que tiene, entre otras características, numerosos complementos disponibles para el desarrollo Java y Web. Está diseñada para soportar una funcionalidad apenas suficiente, de manera que los desarrolladores de complementos solamente se tienen que preocupar por el funcionamiento de su propia funcionalidad. Por supuesto que Eclipse es un IDE completo que, a través de sus numerosos complementos, constituye una excelente opción para los desarrolladores de Java (y otros lenguajes, como C++).

El modelo de desarrollo de Eclipse consta de cuatro conceptos principales:

  • Banco de trabajo
  • Perspectivas
  • Vistas
  • Editores

Cuando se inicia Eclipse, aparece el componente GUI principal del sistema: el Banco de trabajo. Todo lo que usted haga tendrá lugar en el Banco de trabajo. Piense en el Banco de trabajo como si fuera un escritorio donde se apila una colección de perspectivas. El menú y la barra de herramientas principales del Banco de trabajo muestran la funcionalidad potencial en función de las tareas actuales en las que usted participa. Las perspectivas de Eclipse están en el Banco de trabajo y representan una determinada colección de tareas. Una perspectiva es una agrupación lógica de editores y vistas de un determinado proyecto que permite navegar por el proyecto o por los archivos que lo conforman. Dos ejemplos de perspectivas de Eclipse son la perspectiva Java y la perspectiva Debug (Depuración). Una vista podría ser un esquema de un archivo XML o una lista de errores de compilación en los diferentes archivos del proyecto. Un editor puede ser específico de ciertos tipos de archivos y ofrecer capacidades de edición propias del tipo de archivo, o bien puede ser un editor de texto general que permite abrir cualquier clase de archivo de texto. No se puede hacer mucho más que cortar, pegar y guardar.

Application Developer Integration Edition agrega una nueva perspectiva de Eclipse llamada Server (Servidor). Además, la perspectiva Server agrega dos nuevas vistas: la vista Server Configuration (Configuración de servidor) y la vista Server (Servidor) (ver figura 1).

Figura 1. Perspectiva Server

Asistentes para servicios web de Application Developer Integration Edition
Existen tres asistentes que facilitan el desarrollo de servicios web. Estos asistentes lo ayudarán a crear servicios y clientes Web.

Todos los servicios web creados con Application Developer Integration Edition deben estar desarrollados dentro de un proyecto Web dinámico. El asistente para proyectos Web dinámicos le solicitará un nombre de proyecto Web, un nombre de archivo .ear y una raíz de contexto Web para la aplicación Web implementada si decide configurar el proyecto manualmente.

El asistente para servicios web lo guiará por la selección de implementaciones de servicios web compatibles. A continuación se enumeran cuatro tipos de servicios web compatibles:

  1. servicio web JavaBean: toma un componente JavaBean existente y crea el WSDL y los proxies necesarios para ajustar el componente JavaBean detrás de una fachada de servicios web.
  2. servicio web Skeleton JavaBean: crea un servicio web usando un stub JavaBean generado por asistente sobre la base de las operaciones definidas en una definición WSDL.
  3. servicio web EJB: toma un componente EJB existente y crea el WSDL y los proxies necesarios para ajustar el componente EJB detrás de una fachada de servicios web.
  4. servicio web Skeleton EJB: crea un servicio web usando un stub EJB generado por asistente sobre la base de las operaciones definidas en una definición WSDL.

El asistente para clientes de servicios web lo guiará en la creación de un objeto del lado cliente que ajusta todas las llamadas a los diferentes objetos de biblioteca que se ocupan de llamar a los servicios web. Además de generar el cliente, también genera una prueba del cliente.

A continuación, el tutorial analizará algunas de las tecnologías en las que se basan los servicios web, como WSDL, SOAP y UDDI. Luego, usted podrá usar WSDK para ejecutar un servicio web que viene instalado en el servidor. Si por el momento no desea informarse sobre WSDL, SOAP o UDDI, puede saltearse las secciones correspondientes y volver más adelante.

Acerca de los autores

Rick Hightower trabaja en Arc-Mind Inc., donde se especializa en la mentoría y consultoría de Struts y J2EE. Rick es un desarrollador con 14 años de experiencia en el desarrollo de software (siete de ellos en la plataforma Java). Rick ha escrito varios libros sobre la tecnología Java, así como artículos para Java Developer's Journal e IBM developerWorks. Recientemente, Rick terminó un libro sobre Struts en SourceBeat. También escribió numerosos tutoriales bien recibidos sobre EJB 2.0 CMP CMR, XDoclet, Apache Axis, ETTK, WSDK, Struts Tiles, etc. para IBM developerWorks.

Warner Onstine trabaja en Arc-Mind Inc. Es un desarrollador con más de 8 años de experiencia en la industria, la mayor parte de los cuales dedicó al desarrollo de aplicaciones Web. Warner es coautor del libro Professional Java Tools for Extreme Programming, que contiene capítulos sobre Maven, pruebas unitarias en Swing y cobertura de código con jcoverage.


Fundamentos de los servicios web XML

¿Qué es un servicio web?

Los servicios web tienen diferentes significados. Para algunos, un servicio web es simplemente una aplicación Web que presta un servicio. Para otros, un servicio web implica una transacción monetaria. Y hay otros que piensan que una aplicación de servicios web es aquella que usa el protocolo SOAP. Sin embargo, ninguna de estas definiciones se ajusta al significado de servicio web. Entonces ¿qué es un servicio web?

Un servicio web es una aplicación que acepta solicitudes con formato XML de otros sistemas a través de una red (Internet o intranet) mediante protocolos de comunicaciones ligeros e independientes del proveedor.

¿Entendió? Ya me parecía. Analicemos la definición:

  • Un servicio web es una aplicación que acepta solicitudes con formato XML...: Esto significa que si se realiza una llamada a función remota en un servicio web, o bien se le envía un mensaje, esa solicitud debe estar encapsulada entre etiquetas XML.
  • ...de otros sistemas a través de una red (Internet o intranet)...: Los servicios web son similares a otras tecnologías de computación distribuida que permiten aplicaciones empresariales distribuidas y remotas. Más adelante se compararán los servicios web con DCOM, RMI y CORBA.
  • ...mediante protocolos de comunicaciones ligeros...: Las tecnologías y protocolos en los que se basan los servicios web tienen un diseño relativamente ligero y dejan muchas de las características más complicadas, como la seguridad, la administración de sesiones y la gestión de transacciones, en manos de las extensiones de las especificaciones de los servicios web.
  • ...e independientes del proveedor.: Como los servicios web están basados en protocolos estándar abiertos, los sistemas de servicio web ofrecen una interoperabilidad en todas las plataformas que implementan una pila de servicios web. Esta interoperabilidad es uno de los principales atractivos de los servicios web respecto de la EAI.

Además, estas tecnologías y protocolos han sido definidos dentro de organizaciones de estándares independientes como OASIS y W3C. Al usar estos protocolos estandarizados, cualquier aplicación compatible con XML y habilitada para la red puede invocar un servicio web, independientemente del lenguaje de programación o del sistema operativo utilizados.

¿Qué es una SOA?

Esencialmente, una SOA es una colección de servicios que se comunican entre sí. La comunicación puede implicar una simple transmisión de datos o bien dos o más servicios que coordinan una actividad. Es necesario contar con algún medio para conectar los servicios entre sí. Un servicio es una función bien definida y autónoma que no depende del contexto o estado de otros servicios.

Entonces ¿en qué quedamos? En una SOA, es crucial la definición de una interfaz. Es esta definición de la interfaz (generalmente expresada con el WSDL analizado más adelante) la que sirve de contacto entre lo que proporciona el servicio y lo que puede esperar el cliente. Para garantizar un acoplamiento flojo de las partes interesadas, deben ponerse de acuerdo respecto de dos elementos esenciales: un formato común (qué apariencia tiene la carga del mensaje) y un protocolo común (cómo llega el mensaje). La combinación más común es SOAP (formato) sobre HTTP (protocolo), pero existen otros formatos de servicios web válidos, como REST y XML-RPC, y otros protocolos válidos, como SMTP e IIOP.

Por lo general, las SOA se expresan como un cliente que envía una solicitud a un proveedor de servicios. El proveedor de servicios puede enviar o no una respuesta. Estas son algunas interacciones típicas:

  • Recepción de mensajes (sin mensaje de devolución)
  • Recepción y respuesta (solicitud-respuesta)
  • Solicitud de respuesta (mensaje de salida y mensaje de entrada)
  • Publicación o suscripción (solo mensajes de salida)

Como se puede observar, hay una gran variedad de acciones que se pueden realizar al respecto. Veamos cómo se puede usar cada una de estas opciones.

Un servicio posible para el primer caso (servicio web que recibe mensajes pero no produce una respuesta) sería un agregador de blogs, al que se le hace ping cada vez que aparece una nueva entrada en un determinado blog. El servicio informa al agregador sobre este nuevo registro. Además, el agregador recopila el último registro del blog para la aplicación Web de agregación, que luego lo muestra en el sitio y genera una nueva fuente RDF Site Summary (RSS) o Resource Description Framework (RDF) con la nueva información.

Una típica aplicación de solicitud-respuesta podría ser cualquier tipo de servicio de información dinámica (por ejemplo, un servicio meteorológico). Un cliente envía una solicitud de los últimos datos del tiempo en el área de Tucson, Arizona, y recibe una respuesta que se muestra en un widget de escritorio.

Una típica solicitud de respuesta es el resultado de dos servicios que trabajan en conjunto. Un servicio requiere información del otro, entonces envía una solicitud y espera una respuesta. Esta acción es más típica de una aplicación empresa a empresa (B2B), en que un servicio de pedidos requiere la autorización de tarjeta de crédito de un cliente que acaba de hacer un pedido. El servicio envía una solicitud al servidor de autorización de la tarjeta de crédito y espera una respuesta para poder completar la transacción.

Un ejemplo final de publicación o suscripción es aquel en que un servicio permite que los clientes se suscriban. Cuando se produce un acontecimiento, se envía un mensaje a todos los suscriptores para su consumo. Podemos poner por ejemplo el servicio meteorológico, que esta vez, en lugar de esperar a que los clientes envíen una solicitud, envía un mensaje periódicamente (por ejemplo, una vez por hora) a todos los clientes que puede alcanzar.

Importancia de los servicios web

Existen dos motivos esenciales por los que es tan importante evaluar y finalmente adoptar las tecnologías de servicios web. En primer lugar, los servicios web constituyen una evolución natural en la computación distribuida basada en estándares que satisface las necesidades de consumidores y empresas que desean acceder a servicios electrónicos a pedido. Representan un paso más allá de los protocolos establecidos de la computación distribuida como DCOM, RMI y CORBA. El segundo motivo es que las tecnologías de los servicios web abren nuevas oportunidades para la EAI, las aplicaciones B2B y la reutilización intraempresarial de componentes.

Los servicios web son más una evolución que una revolución
Muchos profesionales técnicos han cuestionado la necesidad de contar con otro protocolo de computación distribuida. Después de todo, ¿qué tienen de malo DCOM, RMI y CORBA? Veamos:

  • DCOM es de propiedad privada, lo cual invalida el objetivo de la interoperabilidad basada en estándares.
  • RMI está basado en la tecnología Java, por lo que no se lleva bien con otros lenguajes.
  • CORBA se acerca un poco más. Está basado en estándares y es independiente del proveedor y del lenguaje. Sin embargo, está limitado por la forma complicada y ad hoc en que utiliza la potencia y la flexibilidad de Internet. La tunelización de llamadas CORBA por a través de un firewall requiere varios doctorados y muchísima suerte.

A diferencia de los protocolos mencionados, los servicios web están basados en estándares, son independientes del proveedor y del lenguaje y están diseñados desde el comienzo para potenciar la naturaleza distribuida y centrada en servicios de Internet.

Arquitectura de servicios web

Los sistemas basados en servicios web son sistemas distribuidos con un acoplamiento flojo. El sistema de servicio web más sencillo tiene dos participantes: un proveedor de servicios y un solicitante de servicios. El proveedor presenta la interfaz y la implementación del servicio y el solicitante (también denominado consumidor o cliente) usa el servicio web. Esta sencilla arquitectura se puede ver en la figura 2:

Figura 2. Proveedor de servicios

En un sistema más sofisticado podría haber un registro, que podría actuar como un intermediario de los servicios web. El proveedor podría publicar los servicios en el registro y el solicitante podría descubrir servicios en el registro (ver figura 3).

Figura 3. Solicitante de servicios

Escenarios de negocios para los servicios web

Una arquitectura de servicios web es aquella que facilita una comunicación sistema a sistema (B2B, empresa a consumidor (B2C), punto a punto (P2P) o intranet) que trasciende los lenguajes de programación, los sistemas operativos y las plataformas específicas del proveedor. Los servicios web están basados en especificaciones estandarizadas e independientes del proveedor que se pueden implementar en cualquier lenguaje de programación y en cualquier sistema operativo o plataforma de software. Así, un cliente de servicios web podría escribirse en el lenguaje de programación Java e invocar un servicio web de Microsoft .NET. Este servicio .NET podría incluso usar un servicio web de Perl (alojado en un servidor Linux) y un servicio web C++ (alojado en un servidor Sun Solaris) para cumplir la solicitud del cliente

La siguiente lista ofrece una muestra de escenarios en los que la estandarización y la naturaleza centrada en servicios de las tecnologías de servicios web cobran cada vez más importancia:

  • Servicios electrónicos componentizados (B2B): Los servicios web representan el próximo paso en la evolución del modelo de negocios de los proveedores de servicios de aplicaciones (ASP). Como el acceso a los servicios web se realiza de manera estandarizada mediante XML, las empresas pueden adquirir un acceso único o bien una suscripción para acceder a los servicios online ofrecidos por otras empresas. Si un portal de noticias quiere publicar cotizaciones bursátiles en su sitio Web, debe llegar a un acuerdo con una empresa de minería de datos que ofrezca acceso a su motor de cotizaciones bursátiles. Para obtener acceso a ese motor, el portal de noticias debe usar un lenguaje de programación, un protocolo y una API que el motor de cotizaciones pueda comprender. Es cierto que la empresa de minería de datos podría escribir múltiples interfaces para satisfacer a diferentes clientes, pero esto sería una pérdida de tiempo y de recursos. Si la empresa de minería de datos estandarizara la interfaz de su motor de cotizaciones usando servicios web, cualquier sistema de información compatible con XML podría potencialmente acceder al motor de cotizaciones. Este servicio de cotizaciones bursátiles se podría vender a cientos de clientes, sin necesidad de personalización o adaptación alguna.
  • EAI: La interoperabilidad es una característica fundamental de los servicios web. En lugar de perder el tiempo adaptando las aplicaciones a los sistemas legados o generando conductos personalizados para que las distintas aplicaciones internas se puedan comunicar entre sí, es posible encapsular las aplicaciones legadas con interfaces de componentes de servicios web. Esto se puede hacer incluso manteniendo los actuales mecanismos de invocación privados. Con el tiempo, se podrían eliminar progresivamente las puertas de enlace personalizadas y las conexiones privadas a favor de la nueva interfaz XML abierta. Una empresa podría incluso adoptar servicios web como una arquitectura de mensajería estándar para su intranet y reducir así muchos de los altos costos asociados con la integración de sistemas legados, aplicaciones personalizadas y otros sistemas de información empresarial en un sistema interno común.
  • Reutilización intraempresarial de componentes: Cuando las empresas crecen y sus equipos de desarrollo se fragmentan, se le suele dedicar tiempo al desarrollo de componentes y funcionalidades que ya existen en otros sectores de la organización. La comunicación de la existencia de estos componentes no siempre es fácil o práctica. Los servicios web proporcionan el marco necesario para describir las interfaces, los formatos aceptables, los protocolos (puede ser compatible con múltiples mecanismos) y la ubicación de un determinado componente a través de WSDL. Esta información se localiza mediante UDDI, que admite búsquedas por categoría y por palabra clave. Una vez que se localiza una interfaz de servicios, solo es cuestión de guiar la aplicación cliente al puerto especificado y enviar una solicitud usando la interfaz, el formato y el protocolo descriptos en el documento de la interfaz.

Estos tres escenarios, planteados en términos un tanto generales, representan solo algunas de las formas en que los servicios web XML se usan, y se seguirán usando, en el ámbito de la computación empresarial. Más adelante, analizaremos en más detalle las tecnologías de servicios web más populares: WSDL, SOAP y UDDI.

Interoperabilidad y perfiles de WS-I

Estos tres escenarios plantean ciertos presupuestos que nos llevan a preguntarnos: ¿los servicios web pueden seguir interoperando si cambian los diferentes estándares en los que se basan? Desde la perspectiva del usuario, el uso de colecciones arbitrarias de servicios web no debería obstaculizar la interoperabilidad entre los servicios web.

WS-I se formó con la intención de promover una interoperabilidad estandarizada en el mercado de servicios web. Sin una combinación controlada de las diferentes tecnologías que conforman los servicios web, la interoperabilidad sería casi imposible.

Por ejemplo: la Empresa X decide usar WSDL Versión 1.2, SOAP Versión 1.1 y UDDI Versión 1 para sus servicios web. Por su parte, la Empresa Y decide usar WSDL Versión 1.1, SOAP Versión 1.2 y UDDI Versión 2. Si bien ambas empresas usan servicios web, el cliente o servicio debería estar al tanto de las dos combinaciones de protocolos para poder interactuar con ambas. Los protocolos en sí no son suficientes para alcanzar la interoperabilidad. Sin embargo, una agrupación estandarizada de protocolos permitiría que la Empresa X, la Empresa Y y sus clientes y registros adopten un conjunto común de protocolos y versiones. Sin esta agrupación estandarizada, las empresas y clientes solo podrían elegir aquellos protocolos y versiones que consideran apropiados para su conjunto único de restricciones o requisitos, y rogar que puedan comunicarse entre sí.

La iniciativa WS-I aborda el problema que enfrentan las Empresas X e Y. Un perfil es una agrupación de protocolos de servicios web y sus versiones bajo un mismo título. Si las empresas cuentan con esta agrupación, pueden negociar sus requisitos de protocolos a un nivel más granular. Además, los perfiles limitan el número de conjuntos de protocolos oficiales, que pasan de ser incalculables a tener el grado de finitud que decida WS-I.

Para profundizar el tema de WS-I Basic Profile, lea el tutorial de mejores prácticas y perfil de servicios web en el sitio de IBM developerWorks.


Introducción a WSDL

Fundamentos de WSDL

WSDL es el lenguaje de descripción de servicios web. WSDL proporciona una gramática para describir servicios como un conjunto de extremos que intercambian mensajes. Un documento WSDL sirve como una descripción independiente del lenguaje y de la plataforma (XML) de uno o más servicios. Describe los servicios, la manera de acceder a ellos y qué tipo de respuesta (si hubiera) se debe esperar. Un documento WSDL puede ser intercambiado de manera privada o asentado en un registro UDDI (público o privado) para permitir un acceso más amplio. En realidad, se podría exponer una interfaz 100% basada en Java, documentación basada en texto o cualquier otra interfaz para el servicio. WSDL ofrece un formato de interfaz estandarizado y neutral.

WSDL es un formato de archivo basado en XML que sirve para describir:

  • Tipos
  • Mensajes
  • Operaciones
  • Interfaces (llamadas portTypes)
  • Ubicaciones
  • Enlaces de protocolo

WSDL se usa para describir servicios web como un conjunto de extremos que operan en los mensajes. WSDL puede describir información orientada a documentos o a procedimientos.

En WSDL, los mensajes describen la comunicación entre el cliente y el servicio según la representación de los tipos de datos intercambiados. Las operaciones constan de mensajes entrantes y salientes. Los portTypes consisten en una colección de operaciones y son enlazados con ciertos protocolos (esto se denomina enlace). WSDL es compatible con enlaces con protocolos SOAP 1.1, HTTP GET/POST y MIME. Sin embargo, WSDL es extensible y se puede usar con otros tipos de protocolos de red y formatos de mensaje.

En otro tutorial de esta serie se analizará minuciosamente un documento WSDL y se describirán sus diversos componentes. Sin embargo, para despertar el interés de los lectores, las siguientes páginas contienen un documento WSDL anotado.

Documento WSDL de muestra

Los documentos WSDL comienzan con una sección declarativa que presenta dos componentes clave. El primer componente declarativo está compuesto de las diversas declaraciones de espacios de nombres, que se definen como atributos del elemento raíz. El segundo componente es un elemento <types> opcional que se usa para definir tipos de datos especiales que se usarán más adelante dentro del documento WSDL.

Los tipos se definen con el esquema XML y se corresponden con el contenido XML. Si bien WSDL no especifica un mecanismo de esquema en particular, el esquema XML es el predeterminado. El esquema XML define el contenido legal de una instancia XML, como en el caso de una definición de tipo de documento (DTD). Se incluye:

  • Definición de elementos permitidos
  • Atributos de los elementos
  • Elementos secundarios de los elementos principales
  • Orden de los elementos secundarios
  • Texto permitido en un elemento o atributo (tipos de datos)
  • Valores fijos de elementos y atributos
  • Valores predeterminados de elementos y atributos

A diferencia de DTD, el esquema XML tiene un establecimiento inflexible de tipos (cadena, entero, fecha, etc.). Además, usted puede definir sus propios tipos basándose en los tipos escalares que restringen aún más el contenido permitido.

<?xml version="1.0" encoding="UTF-8"?> 
<wsdl:definitions 
    targetNamespace=http://dvdonline-interface xmlns=
       "http://schemas.xmlsoap.org/wsdl/" 
    xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" 
    xmlns:impl="http://dvdonline" 
    xmlns:intf="http://dvdonline-interface" 
    xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" 
    xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" 
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"> 
    <!-- Types are defined with XSD --> 
    <types> 
    <schema 
        targetNamespace=http://dvdonline-interface 
        xmlns="http://www.w3.org/2001/XMLSchema"> 
        <!-- Define a custom type that maps to an array of strings --> 
        <complexType name="ArrayOf_SOAP-ENC_string"> 
            <complexContent> 
                <restriction base="SOAP-ENC:Array"> 
                <attribute 
                    ref="SOAP-ENC:arrayType" 
                    wsdl:arrayType="xsd:string[]"/> 
                </restriction> 
            </complexContent> 
        </complexType> 
        <!-- Define an element based on the above type --> 
        <element name="ArrayOf_SOAP-ENC_string" 
            nillable="true" 
            type="intf:ArrayOf_SOAP-ENC_string"/> 
    </schema> 
    </types> 
    ...

En la próxima página se muestra el resto del documento WSDL incluyendo los siguientes elementos:

  • <message>
  • <portType>
  • <binding>
  • <service>

Documento WSDL de muestra (continuación)

A continuación se puede observar el resto del documento WSDL, que consta de dos elementos <message> (una solicitud y una respuesta), un elemento <portType> (que contiene un único elemento <operation>), un elemento <binding> (que define en más detalle el elemento <operation>) y un elemento <service>.

... 
    <!-- Define the response of this service
            as a message composed of a type defined above --> 
    <wsdl:message name="getDVDsResponse"> 
        <wsdl:part name="return" 
            type="intf:ArrayOf_SOAP-ENC_string"/> 
    </wsdl:message> 
    <!-- Define the input parameters of this service 
            as a message composed of basic XSD types --> 
    <wsdl:message name="getDVDsRequest"> 
        <wsdl:part name="in0" type="SOAP-ENC:string"/> 
        <wsdl:part name="in1" type="xsd:int"/> 
        <wsdl:part name="in2" type="SOAP-ENC:string"/> 
    </wsdl:message> 
    <!-- Define the portType for this example as the operation(s) 
            supported by this service --> 
    <wsdl:portType name="DVDOnlineStore">

        <!-- Define an operation as a composition of input and 
            output messages --> 
        <wsdl:operation name="getDVDs" 
            parameterOrder="in0 in1 in2">
            <wsdl:input message="intf:getDVDsRequest"/>
            <wsdl:output message="intf:getDVDsResponse"/>
        </wsdl:operation>
    </wsdl:portType> 
    <!-- Bind the above portType to the SOAP protocol --> 
    <wsdl:binding name="DVDOnlineServiceSoapBinding" 
        type="intf:DVDOnlineStore"> 
        <wsdlsoap:binding 
            style="rpc" 
            transport="http://schemas.xmlsoap.org/soap/http"/> 
        <wsdl:operation name="getDVDs"> 
            <wsdlsoap:operation soapAction=""/> 
            <wsdl:input> 
                <wsdlsoap:body
                    encodingStyle
                    ="http://schemas.xmlsoap.org/soap/encoding/" 
                    namespace="http://dvdonline-interface" 
                    use="encoded"/> 
            </wsdl:input> 
            <wsdl:output> 
                <wsdlsoap:body 
                    encodingStyle
                    ="http://schemas.xmlsoap.org/soap/encoding/" 
                    namespace
                    ="http://dvdonline-interface" 
                    use="encoded"/> 
            </wsdl:output> 
        </wsdl:operation> 
    </wsdl:binding> 
    <!-- This is the actual service description. It defines the service 
        name, port binding, and the URL for invoking the service --> 
    <wsdl:service name="DVDOnlineService"> 
        <wsdl:port name="DVDOnlineServicePort"
            binding="tns:DVDOnlineServiceSoapBinding"> 
            <soap:address 
                location="http://localhost:80/dvdonline/services/

                dvdonlineservice" /> 
        </wsdl:port> 
    </wsdl:service> 
</wsdl:definitions>

No codifique a mano el servicio web de este tutorial: use Application Developer Integration Edition para generar un archivo WSDL basado en una interfaz Java y un conjunto de clases relacionadas. Otro cliente podría usar una utilidad WSDL2Client para generar un stub Java basado en su documento WSDL y luego podría usar este stub para comunicarse con su servicio. De hecho, usted también podría usar una utilidad similar de C#, Python, Perl, VB.Net, etc. para generar un stub y comunicarse con su propio servicio. En un futuro tutorial, se usará un archivo WSDL similar al utilizado anteriormente para generar un stub de cliente a fin de llamar operaciones definidas por un servicio web.


Introducción a SOAP

¿Qué es SOAP?

SOAP es una especificación de W3C aceptada por la industria que sirve para describir mensajes (documentos XML y sus adjuntos) de manera que puedan ser enviados a través de una red. El protocolo XML de SOAP se ubica arriba del transporte usado para enviar el protocolo del mensaje y abajo de los documentos XML de dominio específico en la pila del protocolo, como se puede ver en la figura 4.

Figura 4. Pila del protocolo

Ejemplo de SOAP

POST /dvdonline/services/DVDOnlineService HTTP/1.0 
Content-Length: 581 
Host: localhost 
Content-Type: text/xml; charset=utf-8 
SOAPAction: "" 
<!-- The start of the SOAP Message --> 
<SOAP-ENV:Envelope 
    SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" 
    xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" 
    xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"> 
    <SOAP-ENV:Body> 
        <!-- The start of the domain-specific XML document --> 
        <ns1:getDVDs xmlns:ns1="http://dvdonline-interface"> 
            <in0 xsi:type="xsd:string">Action/Adventure</in0> 
            <in1 xsi:type="xsd:int">10</in1> 
            <in2 xsi:type="xsd:string">wonstine@arc-mind.com</in2> 
        </ns1:getDVDs> 
        <!-- The end of the domain-specific XML document --> 
    </SOAP-ENV:Body> 

</SOAP-ENV:Envelope> 
<!-- The end of the SOAP Message -->

En resumen, SOAP es un mecanismo que permite enviar y recibir documentos XML independientemente del protocolo de transmisión o de la estructura del documento XML enviado. La especificación SOAP define dos maneras diferentes de emplear SOAP. En primer lugar, SOAP se puede usar para describir un documento XML genérico. A este formato de mensaje SOAP se lo conoce como estilo de mensajería o de documento. En segundo lugar, existe un formato SOAP más específico que exige que el documento XML anidado siga la semántica RPC. Un mensaje SOAP al estilo RPC describe una llamada a procedimiento con su nombre y valores de parámetro o una devolución de procedimiento. Actualmente, Application Developer Integration Edition proporciona un conjunto de herramientas y una infraestructura necesarios para crear aplicaciones de servidor y de cliente que se puedan comunicar usando SOAP.

La transmisión de un mensaje SOAP involucra tres roles principales:

  1. El remitente SOAP crea y envía un mensaje SOAP a un receptor SOAP final.
  2. Se puede posicionar un intermediario SOAP opcional para que intercepte un mensaje SOAP entre un remitente SOAP y un receptor SOAP final. Los intermediarios que interceptan un mensaje SOAP pueden analizarlo a fin de realizar determinadas acciones, como filtrar, registrar, almacenar en caché, etc. antes de enviar el mensaje al destino SOAP final. Al intermediario SOAP se lo puede considerar un remitente-receptor.
  3. El destino deseado del mensaje SOAP generado por el remitente SOAP (que no es un intermediario) se denomina receptor SOAP final. Ver figura 5.

Figura 5. Roles SOAP

Debido a la naturaleza flexible y ligera de la especificación SOAP, no hay ninguna agencia dentro del protocolo para los requisitos de computación distribuida comunes como:

  • Seguridad
  • Estado de la conversación
  • Transacciones

Estructura del mensaje SOAP

Un mensaje SOAP, que es un documento XML basado en el protocolo SOAP, consta de cuatro partes:

  1. El elemento SOAP <Envelope>, el elemento raíz de un mensaje SOAP, contiene un encabezado SOAP opcional y elementos de cuerpo SOAP obligatorios. Por lo general, el prefijo de espacio de nombres del protocolo SOAP (http://schemas.xmlsoap.org/soap/envelope/) se declara la etiqueta de apertura del sobre.
  2. Un elemento <Header> opcional y extensible describe los metadatos, como información sobre la seguridad, las transacciones y el estado de la conversación.
  3. El elemento <Body> obligatorio contiene el documento XML del remitente. El documento XML del remitente no debe contener ninguna declaración XML o declaración DOCTYPE. Existen dos paradigmas principales a los que se puede ajustar el documento del remitente: el estilo documento y el estilo RPC, que se describirán en las siguientes secciones. Las reglas de serialización del contenido del cuerpo se pueden especificar estableciendo el atributo encodingStyle. El espacio de nombres de codificación SOAP estándar es http://schemas.xmlsoap.org/soap/encoding/.
  4. Ciertos elementos llamados <faults> pueden ser usados por un nodo de procesamiento (intermediario SOAP o destino SOAP final) para describir situaciones excepcionales que pudiera detectar al leer el mensaje SOAP.

Asimismo, una nota W3C especifica la manera de incrustar y describir adjuntos de un mensaje SOAP. El adjunto puede ser cualquier tipo de archivo, basado en binarios o en caracteres. En lugar de crear un nuevo esquema de codificación, la especificación Attachments (Adjuntos) emplea las reglas de la especificación MIME, como se puede ver en la figura 6.

Figura 6. Mensaje SOAP

Modelo RPC

La computación distribuida es un requisito empresarial con diversos protocolos y tecnologías que permiten que los procesos llamen procedimientos de una manera transparente. Desgraciadamente, muchos de estos protocolos y tecnologías no son interoperables. SOAP parece ser único en cuanto a que ha recibido apoyo en toda la industria, eliminándose de esta forma los principales problemas de interoperabilidad para aquellos que lo emplean. Específicamente, el modelo RPC de SOAP facilita la incrustación de SOAP dentro de su infraestructura de TI actual. SOAP al estilo RPC describe la semántica de una llamada a procedimiento y su valor de devolución. Si bien los esquemas de codificación y de tipos de datos son extensibles al modelo RPC, existen esquemas sencillos ampliamente utilizados que describen los tipos simples y compuestos.

La mayoría de las implementaciones de SOAP al estilo RPC siguen el modelo de computación distribuida stub-esqueleto tradicional.

  • Un stub es un objeto que representa otro objeto en un proceso diferente (por lo general, en una máquina física diferente). El cliente interactúa con un stub en su propio proceso. Mientras tanto, el stub se comunica con un proceso de servidor serializando y deserializando datos desde y hacia un socket.
  • Un esqueleto es un objeto que se ubica en el servidor. Llama procedimientos en un objeto en nombre de los clientes (stubs) a través de la red. Como el stub, es responsable de serializar y deserializar parámetros y valores de devolución.

En el caso de SOAP, el stub y el esqueleto serializan datos en un documento SOAP. Application Developer Integration Edition trae herramientas para generar el código del stub y del esqueleto que se necesita para que un objeto de cliente y un objeto de servidor se puedan comunicar. Esto alivia al desarrollador, que ya no tiene que escribir el código necesario para habilitar la comunicación SOAP. De hecho, el uso de stubs y esqueletos distingue al desarrollador del protocolo subyacente tan bien que no es necesario que quien use el modelo RPC tenga algún conocimiento de SOAP. A continuación se presenta un listado de una llamada a un procedimiento denominado getDVDs y la devolución:

Llamada SOAP al estilo RPC

<?xml version="1.0" encoding="UTF-8"?> 
<SOAP-ENV:Envelope 
    SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" 
    xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" 
    xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"> 
    <SOAP-ENV:Body> 
        <!-- Here is the start of the procedure call --> 
        <!-- in0, in1, and in2 are 3 input parameters to the called 
            procedure --> 
        <ns1:getDVDs xmlns:ns1="http://dvdonline-interface">

            <in0 xsi:type="xsd:string">Action/Adventure</in0> 
            <in1 xsi:type="xsd:int">10</in1>
            <in2 xsi:type="xsd:string">wonstine@arc-mind.com</in2> 
        </ns1:getDVDs> 
        <!-- Here is the end of the procedure call --> 
    </SOAP-ENV:Body> 

</SOAP-ENV:Envelope>

Devolución SOAP al estilo RPC

<?xml version="1.0" encoding="UTF-8"?> 
<SOAP-ENV:Envelope 
    xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" 
    xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <SOAP-ENV:Body> 
        <!-- Here is the start of the return description --> 
        <!-- The returned value is an array of strings but 
                that in this case the array length is 1 -->

        <ns1:getDVDsResponse 
            SOAP-ENV:encodingStyle
            ="http://schemas.xmlsoap.org/soap/encoding/" 
            xmlns:ns1="http://dvdonline-interface"> 
            <getDVDsResult xsi:type="SOAP-ENC:Array" 
                SOAP-ENC:arrayType="xsd:string[1]" 
                xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"> 
                <item xsi:type="xsd:string">Fight Club</item> 
            </getDVDsResult> 
        </ns1:getDVDsResponse>

        <!-- Here is the end of the return description --> 
    </SOAP-ENV:Body> 
</SOAP-ENV:Envelope>

Modelo de documento

Mientras que el modelo RPC hace hincapié en la facilidad de integración por sobre la amplitud de expresión y no requiere un gran conocimiento de SOAP, la comunicación SOAP basada en el modelo de documento requiere un conocimiento de SOAP mucho mayor, pero brinda una libertad unilateral para describir los datos transmitidos. El modelo de documento también se describe como unidireccional o asincrónico, ya que no existe un concepto de llamada y devolución como en el caso del modelo RPC. Básicamente, un mensaje al estilo documento permite describir un documento XML arbitrario usando SOAP. Por lo tanto, los requisitos de codificación del estilo RPC no se aplican al estilo documento, en el cual cada mensaje puede seguir su propio protocolo. La flexibilidad que existe para dictar el contenido del elemento <Body> con el estilo documento también se extiende al elemento <Header>. Esto permite usar diferentes protocolos, incrustándolos en <Header>, a efectos de seguridad, transacciones, etc. El siguiente es un listado de un documento SOAP al estilo documento:

<?xml version="1.0" encoding="UTF-8"?> 
<SOAP-ENV:Envelope 
    xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" 
    xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
    <SOAP-ENV:Body> 
    <!-- Here is the start of the user-defined XML document --> 
    <dvdos:order xmlns:dvdos="http://dvdonline.com" dvdos:ID
         ="_a89-sd9sd-334"> 
        <dvdos:customer> 
            <dvdos:name>David Fraser<dvdos:name> 
            <dvdos:address>123 Main St.<dvdos:address> 
            <dvdos:city>Atlanta<dvdos:city> 
            <dvdos:state>GA<dvdos:state> 
            <dvdos:zip>30324<dvdos:zip> 
            <dvdos:shipper 
                dvdos:accountId="_123-3443-223" 
                dvdos:name="Special"/> 
        </dvdos:customer> 
        <dvdos:dvd dvdos:ID="34werer2"> 
            <dvdos:title>Big Blue Rocks</dvdos:title> 
            <dvdos:artist>Donald Cameron</dvdos:artist> 
            <dvdos:releaseDate>12-12-2001</dvdos:releaseDate> 
            <dvdos:listPrice>12.32</dvdos:listPrice> 
            <dvdos:price>3.33</dvdos:price> 
        </dvdos:dvd> 
        <dvdos:dvd dvdos:ID="wer345e"> 
            <dvdos:title>Big Iron Tracks</dvdos:title> 
            <dvdos:artist>John Buchanan</dvdos:artist> 
            <dvdos:releaseDate>9-9-1976</dvdos:releaseDate>

            <dvdos:listPrice>12.22</dvdos:listPrice> 
            <dvdos:price>2.22</dvdos:price> 
        </dvdos:dvd> 
    </dvdos:order> 
    <!-- Here is the end of the user-defined XML document --> 
    </SOAP-ENV:Body> 

</SOAP-ENV:Envelope>

Introducción a UDDI

¿Qué es UDDI?

UDDI son las siglas de Universal Description, Discovery, and Integration. El proyecto UDDI, lanzado por IBM, Microsoft y Ariba a principios del año 2000, se ha convertido en una entidad madura y centrada en soluciones que tiene por objeto proporcionar un marco abierto para registrar y localizar servicios de negocios. El término UDDI es un tanto ambiguo y, de hecho, puede hacer referencia a: el proyecto UDDI, la especificación UDDI, la API UDDI o incluso a un servidor de registro UDDI específico. Por eso, la respuesta para la pregunta "¿Qué es UDDI?", en apariencia simple, dependerá por completo del contexto en que se formule. En las próximas páginas abordaremos varias de estas facetas. En documentos posteriores de esta serie, se darán más detalles sobre la especificación UDDI y la API UDDI.

Existen dos maneras de buscar un sitio Web en Internet: escribir la URL directamente o usar un motor de búsqueda para ubicar un sitio que cumple los criterios proporcionados. Esta localización se realiza exactamente igual que con sitios Web estándar o aplicaciones basadas en la Web porque los servicios web operan en Internet o en una intranet empresarial. Es necesario saber la dirección de red del servicio o usar el equivalente de un motor de búsqueda para servicios web.

Si se conoce la dirección del servicio web que se quiere invocar o la dirección de su interfaz (WSDL, algún tipo de XML, interfaz Java estándar, etc.), es posible contactar el servicio directamente. Esto generalmente ocurre en una intranet empresarial o en una extranet B2B en que se comparte la dirección de servicios importantes con colaboradores. Sin embargo, si no se conoce la dirección del servicio o su interfaz, será necesario buscar el servicio consultando un registro de servicios web.

Para que un socio, un potencial cliente o una aplicación interna pueda invocar un servicio de negocios, primero debe localizar una aplicación de negocios o interna que exponga el servicio requerido, descubrir la interfaz y la semántica de la llamada y después escribir o configurar su software para colaborar con el servicio web. Para hacerlo sin complicaciones, se necesita un mecanismo estandarizado de publicación de servicios web y luego localizarlo y enlazarlo con ellos. Ingrese el proyecto UDDI en www.uddi.org. UDDI es un consorcio multisectorial de más de 100 empresas que reconocen la necesidad de contar con un marco abierto independiente de la plataforma para describir servicios, descubrir empresas e integrar servicios de negocios por Internet.

¿Qué es un registro UDDI?

UDDI proporciona un mecanismo neutral de publicación y localización de descripciones de servicios. Es compatible con diferentes tipos de descripciones de servicios, incluidos documentos WSDL, interfaces Java estándar y algunos tipos de XML. La especificación define una de registro integral que ejecuta dos tareas esenciales: registrar una empresa y sus servicios y localizar y enlazar con un servicio registrado. Un nodo de registro UDDI actúa como proveedor de servicios, publicando servicios de negocios a pedido; registro de servicios, exponiendo un directorio explorable de servicios web; y un solicitante de servicios, localizando un servicio solicitado y enlazando al cliente con ese servicio. Tanto el registro como la localización se efectúan enviando comandos UDDI en el cuerpo de un mensaje SOAP a un registro UDDI.

Un registro UDDI expone servicios web que permiten a los clientes registrar una interfaz con el nodo, así como explorar, inspeccionar y enlazar con servicios que ya han sido registrados. Para acceder a estos servicios UDDI, el cliente envía mensajes SOAP codificados según el estilo de codificación del esquema UDDI. En la figura 7 se puede ver la arquitectura básica de la consulta de un nodo de registro UDDI. La solicitud SOAP es enviada al servidor y deserializada por el procesador SOAP del nodo de registro UDDI. Las llamadas UDDI se hacen en el servicio de registro que, a su vez, consulta la base de datos UDDI. La respuesta pasa a través del procesador SOAP para su serialización y luego se remite al servidor Web para su envío a la aplicación cliente.

Figura 7. Arquitectura de la consulta de un nodo de registro UDDI

Fundamentalmente, el uso de UDDI requiere un nodo de registro y un cliente capaz de enviar solicitudes SOAP codificadas en UDDI. Es posible crear registros privados para una intranet empresarial o una extranet B2B. Existen registros públicos disponibles en ibm.com, microsoft.com, sap.com, uddi.org y xmethods.com. En la actualidad, las empresas se centran en el uso de registros privados. Reconocen a UDDI como una manera estándar de registrar y localizar servicios empresariales dentro de una extensa intranet empresarial o bien como una manera estandarizada y conveniente de exponer un registro de servicios para sus socios comerciales. Sin embargo, pasarán varios años antes de que el mercado de consumidores esté listo para usar registros UDDI públicos para localizar e invocar servicios electrónicos. Si bien su uso es muy limitado, el potencial de UDDI es inmenso, especialmente teniendo en cuenta todo el apoyo recibido desde diversas industrias.

Registro de servicios con UDDI

Los registros XML de UDDI almacenan información sobre empresas, sus servicios y la manera en que se puede acceder a estos servicios. Existe un modelo de datos y una API UDDI diferenciados que facilitan la publicación de empresas y de sus servicios, así como la consulta de esta información. Por analogía, se suele comparar este sistema con una guía telefónica electrónica, en que los diferentes tipos de información son clasificados y organizados de diferentes maneras. Específicamente, se dice que UDDI es compatible con tres tipos de datos de registro: Páginas Blancas (que organizan las empresas por nombre), Páginas Amarillas (que organizan las empresas por categoría) y Páginas Verdes (que organizan las empresas por servicio).

  • Páginas Blancas: UDDI funciona como una guía de páginas blancas que permite buscar empresas por su nombre o algún otro identificador único como DUNS, Thomas Register, etc. Esta información es facilitada a través del elemento businessEntity.
  • Páginas Amarillas: En las páginas amarillas, las empresas están ordenadas por categoría. UDDI también admite la clasificación de empresas por industria, producto o servicio ofrecido y ubicación. Esta información también está asociada con el elemento businessEntity.
  • Páginas Verdes: En una guía telefónica, las páginas verdes contienen cupones. Por algún motivo, el término páginas verdes hace referencia a la capacidad de UDDI de registrar empresas y permitir búsquedas de empresa por los tipos de servicio y las capacidades que proporcionan. Esto se hace a través de los elementos businessService y bindingTemplate. La figura 8 representa los diversos datos UDDI y sus relaciones.

Figura 8. Datos UDDI y sus relaciones

En resumen, UDDI admite el registro y la consulta de empresas por:

  • Nombre
  • Identificación externa
  • Industria
  • Productos o servicios
  • Ubicación geográfica
  • Tipo de servicio técnico
  • Proceso de negocios

En los tutoriales de UDDI de esta serie, se dará más información sobre la arquitectura UDDI y otros detalles.


Configuración de Application Developer

Es posible elegir entre varias versiones de Application Developer Integration Edition. En este tutorial se usará Application Developer Integration Edition Versión 5.1. Entonces, lo primero que hay que hacer es descargar esta versión en http://www.ibm.com/developerworks/websphere/downloads/WSADIEsupport.html. Una vez descargada, es necesario instalarla. En el directorio en que se descargó, debería aparecer un ejecutable llamado wsextract.exe. Haga doble clic en este archivo y empiece a recorrer la extracción y la instalación de Application Developer Integration Edition. Una vez completada la extracción, se le preguntará si desea iniciar el instalador. Haga clic en Finish (Finalizar) para cerrar el extractor e iniciar el instalador. El instalador le preguntará qué desea instalar. Elija los valores predeterminados a menos que ya hubiera descargado algunos de los archivos opcionales. Asegúrese de elegir una ubicación adecuada con espacio suficiente en el disco para alojar la instalación. Ver figuras 9 y 10.

Figura 9. Configuración de Application Developer



Figura 10. Instalador de Application Developer

Una vez finalizada la instalación, seleccione Start (Iniciar) > Programs (Programas) > IBM WebSphere Studio > Application Developer Integration Edition Version 5.1 para iniciar Application Developer Integration Edition Versión 5.1. La primera vez que el programa se inicie, le preguntará con qué área de trabajo desea comenzar. Elija la predeterminada, que debería estar en My Documents\IBM\wsappdevie51\workspace. ¡Ya está listo para empezar su primer proyecto de servicios web!


Trabajo con Application Developer

Paseo rápido por Application Developer Integration Edition

Application Developer Integration Edition está basado en Eclipse 2.1.1, pero agrega ciertas características para facilitar el desarrollo con J2EE, como la creación de EJB y servicios web, con sus vistas correspondientes. Dicho esto, empecemos con el primer proyecto.

En primer lugar, es necesario crear el proyecto de manera que contenga la sencilla aplicación Helloworld. Seleccione File (Archivo) > New (Nuevo) > Web > Dynamic Web Project (Proyecto Web dinámico). Existen dos versiones de proyectos Web disponibles en Application Developer Integration Edition: estáticos y dinámicos. Al elegir dinámico, le informa a Application Developer Integration Edition que creará JSP, servlets, servicios web y otros contenidos dinámicos. Si hubiera elegido estático, solamente podría crear un HTML estático. Póngale al proyecto el nombre HelloWebServices y haga clic en Finish (Finalizar). Debería poder observar una imagen similar a la figura 11.

Figura 11. Proyecto Web dinámico

Como se puede apreciar, Application Developer Integration Edition crea ciertos elementos predeterminados cuando crea el proyecto Web dinámico, como el proyecto DefaultEAR y las carpetas JavaSource y WebContent, ubicadas debajo del proyecto principal.

Ahora cree los archivos Java como parte del servicio de respaldo. La primera clase que se debe crear es la que genera la salida. Llamémosla HelloName. Debería tener una apariencia similar a:

package com.ibm.wsad.ws.test;

public class HelloName {
    private String name;
    
    public void setName(String name) {
        this.name = name;
    }
    
    public String getGreeting() {
        return "Hello " + this.name + "!";
    }
}

Todo esto es bastante simple, teniendo en cuenta que lo único que se pretende es producir una cadena de devolución para la llamada al servicio web.

A continuación aparece el servicio web. Llamémoslo HelloService. Debería ser similar a:

public class HelloService {
    public HelloName getSample(String name) {
        HelloName hn = new HelloName();
        hn.setName(name);
        return hn;
    }
}

Básicamente, se crea una instancia de HelloName y se la devuelve a través del método getSample(). Entonces, ahora que la clase está configurada, ¿cómo se la transforma en un servicio web real? Use el asistente para servicios web para convertir la clase simple en un servicio web completamente funcional. En primer lugar, haga clic con el botón derecho en el archivo Java HelloService y seleccione New (Nuevo) > Other (Más) > Web Services (servicios web) > Web Service (servicio web) > Next (Siguiente). En los tres paneles que siguen, acepte los valores predeterminados. En futuros tutoriales, se analizarán las opciones de estos paneles. El último panel contiene tres opciones en Style and Use (Estilo y uso). Ver figura 12.

Figura 12. Creación de un nuevo servicio web

Como se puede ver, las opciones son Document/Literal (Documento/Literal), RPC/Literal (RPC/Literal) y RPC/Encoded (RPC/Codificado). Elija Document/Literal. Las primeras dos opciones son las únicas compatibles con el perfil básico 1.0 de WS-I. Si se selecciona la última opción, el sistema muestra una advertencia.

Haga clic en Finish (Finalizar) para completar la creación del servicio web y comenzar a implementarlo. Entonces ¿qué es lo que el crea el asistente? Ver figura 13.

HelloService_SEI: La interfaz de extremo de servicio del servicio web. Puede ser usada por el cliente o por implementadores que busquen producir otras implementaciones. Según JSR-109, la interfaz extiende java.rmi.Remote y tiene los mismos métodos que el JavaBean del servicio web, en este caso, getSample().
HelloName_Ser y _Deser: Sirven para serializar y deserializar la clase HelloName creada. Solamente las usa el servidor WebSphere.
HelloName_Helper: Una clase usada solamente por WebSphere.

Figura 13. Archivos generados

El asistente también genera un archivo WSDL para el servicio web y, conforme a JSR-109, lo coloca en el directorio WEB-INF. El asistente pone una copia del archivo en un directorio WSDL bajo Web Content (Contenido Web) para su uso por parte de otras herramientas de Application Development, como WSDL Browser. Si abre el archivo WSDL HelloService.wsdl de manera predeterminada, lo abrirá con el nuevo WSDL Editor. La figura 14 muestra los resultados que se generan en el panel gráfico como consecuencia de abrir el archivo. También se puede ver parte del panel textual que muestra información sobre el nodo seleccionado.

Se puede hacer clic en la flecha azul que apunta a la derecha en el área Types (Tipos) para expandir la definición gráfica del esquema (por ejemplo, los tipos y elementos definidos para los servicios web). Si expande todo haciendo clic en los símbolos +, podrá observar todo el esquema, como se puede ver en la figura 15. Se puede cambiar entre la vista gráfica y la vista de origen de datos usando las pestañas ubicadas en el sector inferior izquierdo del editor.

Figura 14. WSDL Editor

Figura 15. Vista de origen de datos del WSDL

Como este es un servicio simple, no se puede hacer demasiado, así que pasemos a una prueba real del servicio. En primer lugar, en la perspectiva Web, haga clic en el ícono de Web Services Explorer.

Haga clic en el botón Browse (Examinar) y elija el proyecto de muestra HelloWebServices. Ver figura 16.

Figura 16. Examen del servicio web

Una vez seleccionado el proyecto adecuado, la url correspondiente debería tener una apariencia similar a:

http://localhost:9080/HelloWebServices/wsdl/com/ibm/ws/test/HelloService.wsdl

Haga clic en el botón Go (Ir) para explorar ese servicio específico. Podrá ver todas las operaciones que ofrece el servicio, en este caso, getSample. También hay un cuadro de texto para escribir el parámetro nombre que se le da al servicio web. Escriba cualquier nombre que desee y haga clic en Go (Ir). Ver figura 17. También debería aparecer una ventana de estado en la parte inferior que muestra el resultado de la ejecución de esta operación, como se puede ver en la figura 18.

Figura 17. servicio web

Figura 18. Mensaje de respuesta del servicio web

Esto es todo. Si así lo desea, puede ver el mensaje SOAP real que entra al servidor y sale de él haciendo clic en el vínculo de cualquiera de las páginas, como se puede ver en la figura 19.

Figura 19. Mensaje de origen SOAP


Conclusión

Revisión del tutorial

En este tutorial:

  • Se describió toda la serie de tutoriales, de la cual esta es la parte 1
  • Se dio una introducción a Application Developer Integration Edition
  • Se dio una introducción a los servicios web
  • Se mostró cómo instalar y ejecutar Application Developer Integration Edition
  • Se mostró cómo crear y ejecutar un servicio web simple usando Application Developer Integration Edition
  • Se dio una introducción a SOAP, WSDL y UDDI
  • Se mostró cómo consultar un servicio web usando Web Services Explorer
  • Se analizaron algunas de las herramientas de Application Developer Integration Edition

Este tutorial ofrece una buena visión general de los servicios web y de cómo usar Application Developer Integration Edition, pero todavía falta mucho. En el próximo tutorial de la serie, se enseñará a crear un modelo UML y a usar ese modelo para crear un código Java. Esto es útil cuando se consulta un servicio web, se recupera el modelo (a través de SOAP y WSDL) y se crea un cliente a partir de esa especificación.

Recursos

Aprender

Obtener los productos y tecnologías

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=SOA y servicios web
ArticleID=681874
ArticleTitle=Creación de SOA con servicios web usando WebSphere Studio, parte 1: Introducción a SOA y servicios web
publish-date=08052011