Directriz: Desarrollo de servicios web
Esta pauta describe cómo descubrir, crear, probar, desplegar y publicar servicios web utilizando el entorno de moldeado RAD 6.0.
Relaciones
Elementos relacionados
Descripción principal

Introducción

RAD 6.0 proporciona un extenso conjunto de herramientas para dar soporte al descubrimiento, creación, comprobación, desarrollo y publicación de servicios Web. Éstos permiten el desarrollo de servicios web basados en los estándares más actuales y dan soporte al despliegue hacia varios entornos en tiempo de ejecución. Las herramientas también proporcionan asistentes para dar soporte y facilitar los distintos métodos de desarrollo. Este documento describe los distintos métodos proporcionados por RAD 6.0 para desarrollar un servicio web y discute las distintas consideraciones en cuanto a desarrollo en relación con las opciones de despliegue de servicios web y nivel de interoperatividad.

Métodos de desarrollo

Los asistentes de servicios web de RAD 6.0 le permiten crear un servicio web utilizando métodos que van de lo general a lo detallado o viceversa. El método top-down, que va de lo general a lo detallado, le permite empezar con un documento de Web Services Description Language (WSDL) y generar un bean de Java o un Enterprise JavaBean (EJB) de esqueleto que pueden utilizarse para crear un servicio web. El método bottom-up, que va de lo detallado a lo general, le permite crear un servicio web a partir de un bean de Java que ya exista, un EJB, un archivo DADX (Document Access Definition Extender), un URL o un archivo ISD (Web service Deployment Descriptor). La Figura 1 describe la creación de servicios web proporcionada por RAD 6.0.

Métodos para crear servicios web RAD 6.0

Figura 1 - Métodos de creación de servicios web RAD 6.0

Durante la creación de un servicio Web, el asistente le permite opcionalmente:

  • Comprobar el servicio web tan pronto como sea creado utilizando la herramienta Explorador de servicios web.
  • Generar un proxy de cliente que puede utilizar en aplicaciones de cliente para acceder a l servicio web.
  • Comprobar un proxy de cliente utilizando la herramienta UTC (Cliente de prueba universal) o una aplicación JSP de ejemplo que genera la herramienta.
  • Publicar el servicio web en una registro de UDDI utilizando la herramienta Explorador servicios web.

Los servicios web desarrollados en RAD 6.0 tienen que crearse en un proyecto web o EJB y contienen productos que cumplen con los estándares siguientes:

  • Web Services Definition Language (WSDL) versión 1.1
  • Simple Object Access Protocol (SOAP) versión 1.1 (incluidas las implementaciones Apache SOAP 2.2 y 2.3)
  • Universal Description, Discovery and Integration (UDDI) versión 2.0
  • Web Services Inspection Language (WSIL) versión 1.0
  • Java API for XML-based Remote Procedure Call (JAX-RPC), también conocido como JSR-101
  • JSR-109 y JSR-921(Implementación de servicios web empresariales)
  • Perfil básico de interoperatividad de servicios web (WS-I) 1.0 (conformidad opcional)
  • WS-Security

Para obtener más información sobre estos temas consulte Concepts: Web Services for J2EE.

Desarrollo Top-down

El desarrollo Top-down (de lo general a lo abstracto) le permite tomar la definición abstracta de un servicio web contenida en un documento WSDL y generar una implementación concreta para el mismo. (Nota: RAD 6.0 también proporciona un asistente para crear un documento WSDL). Se da soporte a las dos métodos siguientes:

  • Creación de un bean de Java de esqueleto a partir de un documento WSDL

    Puede crear un bean de Java de esqueleto a partir de un documento WSDL y exponerlo como servicio web. Los métodos de bean de Java generados corresponden a las operaciones descritas por el documento WSDL y contienen una implementación trivial que puede sustituir. Las consideraciones siguientes se aplican a este método y sus productos de trabajo generados:

    • Puede especificar el URI de un documento WSDL, o, como alternativa, el de un documento WSIL o HTML que haga referencia a un archivo WSDL como origen del servicio web.
    • El archivo WSDL debe contener un elemento de servicio. También puede generar opcionalmente un documento de referencia WSDL estandarizada (WSIL) para el servicio web resultante.
    • El servicio web generado debe crearse en un proyecto Web.
  • Creación de un EJB de esqueleto a partir de un documento WSDL

    De forma similar, este método le permite crear un EJB de sesión sin estado de esqueleto a partir de un documento WSDL y exponerlo como servicio web. Los métodos en el EJB corresponden a las operaciones descritas en el documento WSDL y contienen una implementación trivial que puede sustituir. Las consideraciones siguientes se aplican a este método y a sus productos de trabajo generados:

    • Este método sólo se puede utilizar si selecciona IBM WebSphere v6 como entorno de tiempo de ejecución del servicio web (consulte Dependencias de despliegue)
    • Puede especificar el URI de un documento WSDL, o, como alternativa, el de un documento WSIL o HTML que haga referencia a un archivo WSDL como origen del servicio web.
    • El archivo WSDL debe contener un elemento de servicio. También puede generar opcionalmente un documento de referencia WSDL estandarizada (WSIL) para el servicio web resultante.
    • El servicio web generado debe crearse en un proyecto EJB. Además, se crea un proyecto de direccionador para habilitar el servicio web con el fin de recibir solicitudes sobre el transporte HTTP (Nota: El transporte JMS no está soportado en este método). El proyecto de direccionador puede ser un proyecto web o EJB y no puede ser el mismo proyecto que el que contiene el servicio web pero debe estar en el mismo archivo EAR.

Desarrollo Bottom-up

El propósito del desarrollo bottom-up (de lo detallado a lo general) es exponer un componente o recurso de la aplicación existente como servicio web. A continuación se explican los diferentes métodos.

  • Creación de un servicio web a partir de un bean de Java

    Este método le permite seleccionar un bean de Java existente y expone sus métodos como un servicio web. Los productos de trabajo resultantes incluyen:

    • Archivo WSDL: Este archivo describe el servicio web y tiene una extensión de nombre de archivo .wsdl. Puede escoger entre tres estilos de WSDL (Documento/Literal, RPC/Literal y RPC/Codificado). Para ver el impacto en la interoperatividad de cada opción, consulte Conformidad con el perfil básico de WS-I.
    • Service Endpoint Interface (SEI): Esta interfaz Java define los métodos del servicio web. Su nombre de archivo tiene un sufijo _SEI.
    • Descriptor de despliegue de servicios web: el archivo webservices.xml especifica los detalles de implementación y despliegue del servicio web.
    • Archivos de correlación JAX-RPC: Estos archivos definen cómo se correlacionan los elementos Java de los servicios web con el WSDL.
  • Creación de un servicio web a partir de un EJB

    Puede exponer los métodos de un bean de sesión sin estado como servicio web. Los productos de trabajo generados son similares a los generados para un bean de Java e incluyen un archivo WSDL, una SEI, un descriptor de desarrollo de servicios web y archivos de correlación JAX-RPC. Las consideraciones siguientes se aplican a este método y a sus productos de trabajo generados:

    • El servicio web generado debe crearse en un proyecto EJB.
    • Se debe crear un proyecto de direccionador para habilitar el servicio web y poder recibir solicitudes de clientes. Si utiliza SOAP sobre HTTP como método de transporte, cree el proyecto de direccionador como proyecto web. De no ser así, si el cliente utiliza SOAP sobre JMS, créelo como proyecto EJB (el direccionador JMS está implementado como un Bean de mensaje en este caso). Los proyectos de direccionador y servicios web no pueden ser los mismos pero deben contenerse en el mismo archivo EAR.
    • Si utiliza el transporte SOAP sobre JMS, debe configurar un proveedor JMS en su servidor. Tampoco podrá utilizar el Explorador de servicios web para comprobar su servicio web.
  • Creación de un servicio web a partir de un archivo DADX

    Este método le permite recortar datos de DB2 a los que se accede a través de DB2 XML Extender o sentencias SQL regulares dentro de un servicio web. Los datos a los que se accede a través de DB2 XML Extender consisten en documentos XML correlacionados a una base de datos DB2 mediante un documento Document Access Definition (DAD). El punto de partida del método es un archivo DADX que especifica cómo crear un servicio web utilizando el conjunto de operaciones definidas por sentencias SQL regulares o en un archivo DAD. Los productos de trabajo generados incluyen un archivo WSDL, una SEI, un descriptor de desarrollo de servicios web y archivos de correlación JAX-RPC. Las consideraciones siguientes se aplican a este método y a sus productos de trabajo generados:

    • Este método sólo se puede utilizar si selecciona IBM SOAP como entorno en tiempo de ejecución del servicio web (consulte Dependencias de despliegue).
    • Opcionalmente, puede generar un archivo DADX a partir de una combinación de una o varias sentencias SQL, procedimientos almacenados o archivos DAD .
    • El archivo DADX ha de estar contenido en un grupo DADX que defina la conexión JDBC y otras informaciones compartidas entre los archivos DADX del grupo.
    • El servicio web generado debe crearse en un proyecto Web.
  • Creación de un servicio web a partir de un URL

    A partir de su URL, puede crear un servicio web que acceda directamente a un servlet que se ejecute en un servidor remoto. El asistente le permite describir la interfaz de servlet en términos de puertos, operaciones y parámetros y genera un documento WSDL que describe el servicio web resultante. Las consideraciones siguientes se aplican a este método y a sus productos de trabajo generados:

    • Este método sólo se puede utilizar si selecciona IBM SOAP como entorno en tiempo de ejecución del servicio web (consulte Dependencias de despliegue).
    • Normalmente, el puerto corresponde a la parte del nombre de dominio/host del URL, la operación corresponde a la parte del contexto de servlet y URI, y los parámetros corresponden a los parámetros de entrada del servlet.
    • El servicio web generado debe crearse en un proyecto Web.
    • No existe un servicio web para desplegar porque ya ha sido implementado por el URL activo.
  • Creación de un servicio web a partir de un archivo de descriptor de despliegue (ISD)

    Cuando se despliega un servicio web, sus atributos de configuración y tiempo de ejecución se definen en un archivo de descriptor de despliegue ISD. Este archivo proporciona información sobre el servicio que debería ponerse a disposición de clientes mediante el entorno de ejecución SOAP, por ejemplo, URI, métodos, clases de implementación (JavaBeans y EJB), serializadores y deserializadores. Puede crear un servicio web a partir de un archivo ISD utilizando esta información disponible. Esto le permite recortar implementaciones de servicios web existentes y volverlas a desplegar como nuevos servicios web sin tener que volver a especificar su información de configuración y correlación. Las consideraciones siguientes se aplican a este método y a sus productos de trabajo generados:

    • Este método sólo se puede utilizar si selecciona IBM SOAP como entorno en tiempo de ejecución del servicio web (consulte Dependencias de despliegue).
    • El servicio web generado debe crearse en un proyecto Web.

Directrices de desarrollo

Las secciones siguientes tratan sobre consideraciones importantes relacionadas con el desarrollo de un servicio web en RAD 6.0. Describen las opciones de desarrollo disponibles basadas en el despliegue y los requisitos de conformidad con WS-I de su servicio web.

Dependencias de despliegue

Los métodos (top-down y bottom-up) disponibles para crear un servicio web dependen del entorno de tiempo de ejecución que elija para desplegar. RAD 6.0 da soporte a los entornos de tiempo de ejecución de servicios web siguientes:

  • IBM WebSphere v6

    Este es el entorno de tiempo de ejecución de los servicios web predeterminados en RAD 6.0 y el recomendado para uso productivo. Soporta un protocolo de transporte JMS y HTTP, permitiendo que los servidores y clientes de servicios web se comuniquen vía conexiones HTTP o vía colas y temas JMS. Tenga en cuenta que un servicio web puede ser implementado como EJB si es accesible a través del transporte JMS.

  • IBM SOAP

    El entorno de tiempo de ejecución IBM SOAP da soporte a los protocolos Apache SOAP versión 2.2 y 2.3 (consulte Recursos) y era el único entorno de tiempo de ejecución de servicios web soportado en WebSphere Studio versión 5.0 y anterior. Sólo debe utilizarse por motivos de compatibilidad con versiones anteriores.

  • Apache Axis 1.0

    Este entorno de tiempo de ejecución da soporte a la implementación SOAP de Apache Axis versión 1.0 (consulte Recursos). No está recomendado para la producción debido a problemas de interoperatividad entre servicios web potenciales (consulte la sección Problemas de uso del entorno de tiempo de ejecución Apache Axis 1.0 en los Contenidos de ayuda de la herramienta).

Se recomienda que elija el entorno de tiempo de ejecución IBM WebSphere v5 a no ser que su destino de despliegue requiera específicamente que utilice un SOAP Apache o una implementación Apache Axis (de ser así, tenga cuidado con las limitaciones asociadas descritas en la Limitaciones de la herramienta del contenido de ayuda de los servicios web). La Tabla 1 resume las propuestas de creación de servicios web soportadas por RAD 6.0 para cada entorno de tiempo de ejecución.

Enfoque IBM WebSphere v6 IBM SOAP Apache Axis 1.0
Creación de un JavaBean de esqueleto a partir de un documento WSDL
Creación de un EJB de esqueleto a partir de un documento WSDL
No
No
Creación de un servicio web partir de un JavaBean
Creación de un servicio web a partir de un EJB
No
Creación de un servicio web a partir de un DADX
No
No
Creación de un servicio web a partir de un URL
No
No
Creación de un servicio web a partir de un descriptor de despliegue de servicios web (ISD)
No
No

Tabla 1 - Propuesta de creación de servicios web compatible con entorno de tiempo de ejecución

Conformidad con el perfil básico de WS-I

El perfil básico de interoperatividad de servicios web (WS-I) es un conjunto de requisitos publicados por la organización de WS-I para promover la interoperatividad de servicios web entre plataformas, sistemas operativos y lenguajes de programación. Define los requisitos de tráfico WSDL y de protocolo (SOAP/HTTP) que debe satisfacer un servicio web para estar en conformidad con WS-I. RAD 6.0 incluye herramientas de validación que pueden utilizarse para verificar la conformidad de los servicios web con los requisitos del perfil básico de WS-I 1.0. Puede establecer un nivel de conformidad con WS-I (Solicitar, Sugerir o Ignorar (predeterminado)) para el espacio de trabajo o proyecto antes de desarrollar un servicio web o ejecutar las herramientas de validación tras su desarrollo.

Es recomendable desarrollar servicios web en conformidad con el perfil básico de WS-I. Debe seguir las directrices expuestas a continuación para asegurase de que lo están:

  • Utilice Documento/literal o RPC/literal para el estilo WSDL (RPC/codificado no es conforme con WS-I)
  • Utilice SOAP sobre HTTP como protocolos de transporte y mensajería (SOAP sobre JMS no es conforme con WS-I)
  • No utilice ninguna opción de seguridad para el servicio web (la firma digital XML y el cifrado XML no son conformes con WS-I)

Consideraciones sobre el proxy cliente

  • Existen 2 tipos de proxies cliente que puede generar opcionalmente al crear un servicio web:
  • Proxy de bean Java

El bean de Java del proxy de cliente le permite invocar métodos de servicio web mediante llamadas a procedimientos remotos. Sólo se puede crear en un proyecto web de cliente si se selecciona IBM SOAP o Apache Axis 1.0 para el entorno de tiempo de ejecución cliente. De no ser así, para un entorno de tiempo de ejecución IBM WebSphere v6, se puede crear en un proyecto Web, Java, EJB o de cliente de aplicación.

  • Funciones de servicios web definidas por el usuario

Esta opción le permite crear una función DB2 definida por el usuario (UDF) para cada método del servicio web que desee invocar. Requiere que el paquete de UDF del consumidor de servicios web DB2 y el DB2 XML estén instalados en la base de datos. La UDF se crea y se añade a la definición de base de datos con todos los productos relacionados de trabajo del cliente almacenados en un proyecto web.

  • Seleccione un EAR diferente para el servicio web y el cliente del servicio web para reducir las posibilidades de encontrar errores de tiempo de ejecución. Recuerde que se espera que un cliente sea una aplicación diferente que el servicio web, y los servicios web no están concebidos para la comunicación entre aplicaciones.

Recursos

Para obtener información adicional sobre los siguientes temas, consulte el enlace correspondiente.