1.0 Introducción
2.0 Software soportado y especificaciones
3.0 Cambios realizados desde el release anterior
4.0 Limitaciones
4.1 No es posible
ejecutar el ejemplo Supply Chain Management
5.0 Problemas conocidos
5.1 Explorador de servicios Web
5.2 El servidor de
supervisión TCP/IP no funciona en Linux
5.3 Interoperabilidad con
el soporte de ejecución SOAP de IBM
5.4 Generar un
documento WSDL a partir de un archivo DADX
5.5 Generador de JSP de las herramientas
Web
5.6 Caso práctico Hospital
5.7 Utilizar el cliente de prueba
universal
5.8 En
algunos casos, se permiten múltiples salidas con los servicios Web de DADX
5.9 La preferencia
de controlador JDBC está destinada sólo a Linux
5.10
Hay que actualizar los archivos de ejemplo de DAD si XML Extender no está instalado en el
directorio por omisión
5.11 Problemas relacionados con los
servicios Web de DADX
5.12
Los diálogos emergentes del Explorador pueden no visualizarse correctamente si están funcionando a
la vez Mozilla y Netscape
5.13 Soporte para la generación de
DADX
5.14
Errores de WSDL después importar un archivo de servicios Web de 4.0.x
5.15 Problemas al utilizar
Linux con GTK
5.16 Utilizar el servidor
Tomcat con el soporte de ejecución de AXIS
5.17 Problemas al
utilizar la línea de mandatos de los servicios Web
5.18 Creación de
servicios Web sin un servidor existente
5.19 Generar una
aplicación de ejemplo de servicios Web
5.20 Importar
archivos WSDL con autenticación básica HTTP
5.21 Problemas de
utilización del soporte de ejecución de WebSphere v5.0.2
5.22
Configurar un grupo DADX con información de origen de datos
5.23 Cargar
el localizador mediante el Cliente de prueba universal
5.24 Preferencias de recursos no
observadas
5.25 Problemas de
utilización del soporte de ejecución de Apache Axis 1.0
5.26 El JSP de ejemplo de
servicio Web no puede compilarse
5.27 Error de localhost no
definido
5.28
Limitaciones permanentes al utilizar el soporte de ejecución SOAP de IBM
5.29 El cliente y
el servicio Web utilizan un soporte de ejecución diferente
5.30 Pulsar Finalizar
en el asistente de cliente de servicios Web
5.31 Hoja de apuntes de los servicios
Web
La característica de herramientas de servicios Web le permite descubrir, crear y publicar servicios Web de beans Java, DADX, beans de empresa y URL. En este archivo readme se describen los problemas conocidos, las limitaciones y los métodos alternativos asociados a las siguientes funciones de las herramientas de servicios Web:
- Generar un documento WSDL a partir de un bean Java, un documento DADX, un bean de empresa, un archivo ISD y un URL.
- Generar un proxy Java o esqueleto a partir de un documento WSDL.
- Crear y desplegar un servicio Web a partir de un bean Java, un DADX, un bean de empresa o un URL.
- Descubrir y publicar servicios Web.
- Generar una aplicación Web de ejemplo a partir de un proxy Java.
- Cuestiones relacionadas con la interoperatividad.
En este release de las herramientas de servicios Web, el código generado está en conformidad con las siguientes especificaciones:
- SOAP (protocolo simple de acceso a objetos) Versión 1.1
- UDDI (descripción, descubrimiento e integración universal) Versión 2.0
- WSDL (lenguaje de descripción de servicios Web) Versión 1.1
- WSIL (lenguaje de inspección de servicios Web) Versión 1.0
Este release de las herramientas de servicios Web da soporte a los siguientes entornos de tiempo de ejecución:
- soporte de tiempo de ejecución de servicios Web IBM WebSphere v5.0.2
- soportes de tiempo de ejecución IBM SOAP Versión 2.2 y Versión 2.3.
- soporte de tiempo de ejecución Apache Axis 1.0
Si se propone lanzar el entorno de prueba de WORF fuera del entorno de trabajo utilizando Mozilla, le recomendamos que haga servir como mínimo Mozilla Versión 1.3.1. La salida que se obtiene al invocar el servicio Web y los archivos de descripción podrían no representarse correctamente si se utilizan versiones anteriores del navegador Mozilla.
El soporte de ejecución DADX requiere DB2 7.2 con el paquete de arreglos 6 o superior, DB2 8.1 o superior.
Las siguientes características son nuevas en las herramientas de servicios Web v5.1:
- Soporte de tiempo de ejecución de servicios Web IBM WebSphere v5.0.2. Este es el entorno de ejecución estratégico de servicios Web de IBM que da soporte a JSR-109 y JAX-RPC.
- Soporte de tiempo de ejecución Apache Axis 1.0. Este entorno de ejecución da soporte a JAX-RPC y está destinado a los usuarios que prefieren efectuar el desarrollo en la plataforma abierta Apache Axis.
- Proporciona una herramienta de línea de mandatos de de servicios Web que permite al usuario crear servicios Web desde un bean Java, EJB o un archivo WSDL, y publicar y despublicar empresas y servicios en registros UDDI.
- Integración total del Explorador WSDL en el Explorador de servicios Web.
- Proporciona herramientas de ensamblado de aplicaciones de servicios Web, que incluyen:
- Editor de servicios Web y Editor de cliente de servicios Web para editar los descriptores de despliegue de JSR-109 e IBM WebSphere v5.0.2.
- Acción de menú emergente para llamar a la función EndpointEnabler.
- Acción de menú emergente para llamar a la función WebServiceDeploy.
- Guía de ayuda del usuario para la creación de servicios Web compatibles con WS-I por medio de las preferencias. El usuario puede elegir que el asistente de servicios Web requiera, sugiera o ignore la compatibilidad con WS-I al crear servicios Web.
- Generar y consumir documentos de consulta de servicios Web WSIL en función del proxy.
- Permitir al usuario actualizar los descriptores de despliegue de WebSphere v5.0.2 con configuraciones de seguridad de ejemplo.
- Soporte SOAP a través de JMS como transporte para mensajes SOAP al crear servicios Web desde EJB.
- Soporte para categorías UDDI definidas por usuario.
- Soporte para validación de servicios Web. Si se establece esta preferencia, la herramienta valida que una aplicación de empresa y/o los módulos que contiene cumplan un conjunto de normas que definen la compatibilidad con JSR-109.
El ejemplo Supply Chain Management no puede ejecutarse en WAS Express.
- Al utilizar el explorador de servicios Web con el registro UDDI privado, el formulario para gestionar aserciones de publicador de un nodo de empresa no se cargará en las siguientes situaciones:
- No está conectado al nodo de registro que contiene el nodo de empresa.
- Está conectado al nodo de registro que contiene el nodo de empresa, pero ese nodo de empresa no es propiedad del ID de usuario/Contraseña que se utiliza para conectarse al registro.
- No podrá utilizar el explorador de servicios Web para consultar o publicar mediante un registro UDDI habilitado para una autenticación básica. Un ejemplo de este tipo de registro sería un registro privado que estuviera desplegado en un servidor con la autenticación básica activada. Tenga en cuenta que ninguno de los registros públicos (IBM, Microsoft, SAP, NTT y XMethods) se ve afectado por este problema.
- Cuando se utiliza una búsqueda avanzada en el explorador de servicios Web para localizar empresas en un registro UDDI privado de WAS configurado con un componente de fondo Cloudscape y con una o más interfaces de servicios especificadas como parámetros, la búsqueda fallará y en la ventana de estado se verá el mensaje:
com.ibm.uddi4j.wsdl.client.UDDIWSDLProxyException: No se ha podido obtener una lista de todos los proveedores de servicios. ------------------------------------------------------------------------------ La excepción anidada es:E_fatalError (10500) Se produjo un error técnico grave mientras se procesaba la petición. : Fault code=Client Fault string=Client Error Fault actor=null Detail=null DispositionReport: ErrCode=E_fatalError ErrInfoText=E_fatalError (10500) Se produjo un error técnico grave mientras se procesaba la petición.
- El registro de XMethods dispone de procedimientos para verificar los servicios Web publicados, suprimiendo aquellos a los que no se puede acceder o los que no funcionan. Para impedir que se suprima un servicio Web publicado, asegúrese de que se puede acceder en Internet a todas las referencias a URL que haya en los archivos WSDL.
El registro UDDI de empresas de SAP devolverá un mensaje E_fatalError en el caso de una petición de buscar empresa por categoría con findQualifier igual a "combineCategoryBags" (tModelKey igual a UUID:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2). En la ventana de estado se visualizará el mensaje de error que se indica a continuación. Este es un problema exclusivo del registro UDDI de empresas de SAP.
com.ibm.uddi4j.wsdl.client.UDDIWSDLProxyException: No se ha podido obtener una lista de todos los proveedores de servicios. ------------------------------------------------------------------------------ La excepción anidada es:Se produjo un error técnico grave mientras se procesaba la petición. : Fault code=Client Fault string=UDDI Error Fault actor=null Detail=null DispositionReport: ErrCode=E_fatalError ErrInfoText=Se produjo un error técnico grave mientras se procesaba la petición. en com.ibm.uddi4j.wsdl.client.UDDIWSDLProxy.findAllServiceProviders(UDDIWSDLProxy.java:1626) en FindBusWithQualifier.main(FindBusWithQualifier.java:35)
- Los informes de aserción de publicador devueltos por el registro UDDI de empresas de SAP no contienen datos de estado. Por lo tanto, en los informes devueltos por SAP, no habrá ningún valor en la columna de estado de aserción de publicador del formulario que sirve para gestionar aserciones de publicador. Este es un problema exclusivo del registro UDDI de empresas de SAP.
- Al intentar publicar una empresa, servicio o interfaz de servicio en el Registro UDDI XMethods, recibirá un mensaje de error relativo a una "Anomalía de reconocimiento SSL". Se trata de un problema conocido que IBM y XMethods están investigando.
El servidor de supervisión TCP/IP no funciona en Linux. Los intentos de insertar el servidor de supervisión entre un servicio Web y un cliente de servicios Web (por ejemplo, los archivos JSP de ejemplo de servicios Web, los archivos JSP de bean Java de herramientas Web y el cliente de prueba universal) interferirán en las comunicaciones entre el cliente y el servicio. En concreto, el cliente quedará indefinidamente colgado al producirse la primera respuesta del servicio. Para recuperar el sistema ante esta condición en los archivos JSP de ejemplo o en el cliente de prueba universal (UTC), cierre todos los navegadores, luego lance un navegador nuevo desde fuera de WebSphere Studio y teclee el URL apropiado para los archivos JSP de ejemplo generados o para el cliente de prueba universal.
Para supervisar el tráfico SOAP en Linux, intente hacerlo con otra herramienta de supervisión, como el túnel TCP/IP, que está incluido en la unidad ejecutable Apache SOAP y se puede bajar de http://ws.apache.org/soap/index.html.tool. Inicie el túnel e invoque una operación de cliente de servicio Web. El tráfico de peticiones y respuestas debe mostrarse en el túnel, pero el cliente parecerá suspendido. Detenga el túnel. Esto hará que el cliente se desbloquee y que la operación se lleve a cabo. Reinicie el túnel antes de intentar la llamada siguiente.
- Al utilizar el soporte de ejecución SOAP de IBM, la generación de WSDL con parámetros complejos puede producir problemas relacionados con las herramientas de Microsoft que consumen WSDL. Las herramientas de Microsoft no manejan adecuadamente las sentencias XSD include, por lo que puede ser necesario incorporar esquemas XSD en el WSDL generado. Esto se puede llevar a cabo seleccionando
Ventana > Preferencias > Servicios Web > Generación de código > Utilizar esquema incorporado.Al utilizar el soporte de ejecución SOAP de IBM, si se marca el recuadro de selección "Habilitar correlación basada en elemento", el asistente de servicios Web está plenamente habilitado para generar correlaciones basadas en elementos, además de las correlaciones normales basadas en tipos. Desde el menú principal de WSAD, este recuadro de selección está en la página de preferencias siguiente:
Ventana > Preferencias > Servicios Web > Generación de código.Si esta preferencia no está habilitada, lo que es el valor por omisión, la unidad ejecutable SOAP de Apache/IBM tal vez no pueda interoperar con las unidades ejecutables de servicios Web de otros proveedores que envíen mensajes cuyos elementos no tengan propiedades "xsi:type".Las unidades ejecutables de servicios Web de los otros proveedores están sujetas a diversas políticas sobre la inclusión de las propiedades xsi:type.Algunas siempre las incluyen.Otras nunca lo hacen.Unas cuantas proporcionan una opción de configuración.Las hay que omiten xsi:type para determinados tipos, como las matrices.
El error típico producido por la unidad ejecutable SOAP de IBM/Apache es:
targetException=java.lang.IllegalArgumentException: No se ha encontrado ningún deserializador para deserializar un ':MyElement' con el estilo de codificación 'http://schemas.xmlsoap.org/soap/encoding/'.
Cuando están habilitadas, las correlaciones basadas en elementos se generan en:
- el archivo de descriptor de despliegue para los casos de beans Java/EJB ascendentes y los casos de esqueleto WSDL
- el proxy en los casos de cliente
Las correlaciones basadas en elementos tienen el formato:
<isd:map
encodingStyle="encoding style"
xmlns:x="un-espacio-nombres"
qname="x:un-nombre-local"
xml2JavaClassName="un-nombre-clase-deserializador"/>Se genera una correlación basada en elemento para:
- Cada componente definido en cada entrada wsdl:message.
- Cada componente definido en cada salida wsdl:message, solo para los casos de esqueleto y proxy.
- Cada elemento raíz o elemento local de cada tipo complejo al que se haga referencia desde componentes del archivo WSDL.
El asistente de servicios Web sigue las especificaciones SOAP y XSD a la hora de determinar si el nombre de elemento de una correlación basada en elemento debe estar o no calificado (es decir, si tiene o no un espacio de nombres).
El asistente de servicios Web de WSAD, para decidir si hay que usar nombres de elementos calificados o no calificados, aplica las siguientes normas:
- Para los nombres de componentes de WSDL se usan nombres no calificados.
- Para los elementos raíz de XSD se usan nombres calificados.
- Para los elementos locales de XSD se usan nombres no calificados si el esquema especifica elementFormDefault="unqualified", que además es el valor por omisión si el esquema no tiene ningún atributo elementFormDefault.
- Para los elementos locales de XSD se usan nombres calificados si el esquema especifica elementFormDefault="qualified".
De algunas unidades ejecutables se sabe que generan elementos no calificados en los mensajes de SOAP a pesar de tener un esquema que especifica el uso de elementos calificados por medio del atributo "elementFormDefault" del esquema XSD. En tales casos, tal vez tenga que editar manualmente un WSDL o XSD del servicio y cambiar el valor de elementFormDefault por "unqualified".
Ejemplo de correlación basada en elemento no calificada por espacio de nombres:
<isd:map
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:x=""
qname="x:name"
xml2JavaClassName="org.apache.soap.encoding.soapenc.StringDeserializer"/>Ejemplo de correlación basada en elemento calificada por espacio de nombres:
<isd:map
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:x="http://www.ibm.com/"
qname="x:name"
xml2JavaClassName="org.apache.soap.encoding.soapenc.StringDeserializer"/>Fíjese en que solo se generará una correlación basada en elemento para un nombre de elemento dado. Es decir, si el esquema utiliza el mismo nombre de elemento más de una vez, pero con distintos tipos, solo se seleccionará de manera aleatoria uno de los elementos para una correlación basada en elemento. Los otros elementos con nombres idénticos de distintos tipos no podrán deserializarse. Lo mismo ocurre si el esquema utiliza el mismo nombre para un elemento que para un componente de WSDL.
- Cuando se empieza por un bean de servicio que devuelve una matriz de tipo Map (correlación) o una matriz de tipo Hashtable (tabla hash) estando habilitada la opción "correlación basada en elemento", el proxy SOAP generado correlacionará incorrectamente el tipo de retorno con un tipo java.lang.String[]. Se producirá una excepción ClassCastException en tiempo de ejecución. Para evitar que se produzca este problema, ejecute el asistente Cliente de servicio Web con el documento WSDL recién creado y regenere el proxy SOAP en el proyecto de cliente.
- Para mejorar la interoperatividad con los servicios Web de Microsoft, se ha actualizado la unidad ejecutable DADX para que sea posible generar servicios Web de estilo de documento. Para habilitar esta característica, utilice el asistente de configuración de DADX y abra la página de propiedades de un grupo de DADX que deba utilizarse. En la parte inferior de la página de propiedades, el campo de entrada "Utilizar estilo de documento" debe estar establecido en verdadero.
- La generación de un proxy Java para operaciones de llamada DADX con múltiples parámetros de salida no está soportada.
- Al crear un servicio Web DADX, en ocasiones puede aparecer el mensaje "IWAB0177E Error al generar WSDL a partir de un archivo DADX." En la mayoría de los casos, este mensaje es una indicación de que hay algún problema relacionado con una base de datos y deberá consultar las anotaciones de la consola del servidor para obtener los detalles del problema. Compruebe también lo siguiente:
- Los archivos DAD (*.dad) deben estar ubicados en el directorio de grupo DADX. Así es cómo la ejecución de WORF localiza los archivos DAD.
- Si está intentando generar un archivo DAD a partir de un archivo de correlación de RDB con XML (.rmx), asegúrese de que el archivo DAD está ubicado en la misma carpeta que el archivo DADX.
- El esquema DADX ha dejado de usar el código de documento WSDL para la documentación. Ahora, este código forma parte del esquema DADX. Esto puede provocar problemas de validación en los archivos DADX antiguos que no se hayan migrado con el esquema actualizado. Por ejemplo, si el archivo DADX antiguo contenía el XML:
<wsdl:documentation xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
Proporciona consultas para obtener información de orden de componentes en myco.com.
</wsdl:documentation>La nueva entrada de documento sería:
<documentation>
Proporciona consultas para obtener información de orden de componentes en myco.com.
</documentation>
Hay que añadir el archivo db2java.zip de controlador DB2 a la vía de acceso de clases ws.ext.dirs de WebSphere. Para añadir db2java.zip, siga estos pasos:
- Pase a la perspectiva Servidores (Ventana > Abrir perspectiva > Servidor).
- En el panel Configuración del servidor, expanda Servidor.
- Pulse dos veces en WebSphere v.4.0 Test Environment. Se abre el editor de instancias.
- En el editor de instancias, pulse la pestaña Vías de acceso y después pulse Añadir JAR externos en la sección Vía de acceso de clases específica de WebSphere (ws.ext.dirs) para añadir /home/db2inst1/sqllib/java12/db2java.zip a la vía de acceso de WebSphere.
- Seleccione Archivo > Guardar (nombre del archivo) para guardar los cambios y después salga del editor de instancias.
Para obtener actualizaciones de la documentación del caso práctico Hospital, vaya a WebSphere Developer Domain y pulse Biblioteca.
Al lanzar el cliente de prueba universal desde el asistente de servicios Web, el URL de proveedor de JNDI está establecido en el puerto por omisión de WebSphere v5, que es el 2809. Si está utilizando un servidor WebSphere v4 o si ha cambiado el número de puerto, no podrá hacer búsquedas en el directorio JNDI. Si intenta acceder al directorio JNDI, recibiría el mensaje de error:
IWAD0403E No se ha podido construir el árbol de JNDI: Se ha capturado CORBA.COMM_FAILURE al resolver reference=WsnNameService inicialPara salir al paso de este problema:
- Pulse dos veces en el servidor que está utilizando. Así se abrirá la página de propiedades del servidor.
- Seleccione la pestaña Puertos.
- Copie el puerto bootstrap de ORB.
- Abra la ventana Propiedades de JNDI en el cliente de prueba universal.
- Pegue el puerto bootstrap en el cuadro de entrada de texto URL de proveedor.
Normalmente, en nuestras herramientas no están soportadas múltiples salidas de un servicio Web. Sin embargo, en el caso de los servicios Web de DADX, se permiten múltiples salidas si se establece que la propiedad de grupo Utilizar estilo de documento tiene el valor true. En este caso, cuando Utilizar estilo de documento es true, las distintas salidas se combinan entre sí para formar un solo documento XML.
Se ha añadido una nueva categoría de preferencias de servicios Web (Ventana > Preferencias > Servicios Web) que se llama Controladores JDBC. Esta preferencia está disponible en todas las plataformas, pero solo está pensada para utilizarse en Linux. En Linux, puede resultar difícil determinar la ubicación del archivo JAR que contiene los controladores JDBC. Por lo tanto, se ha añadido esta página de preferencias para permitirle especificar qué archivo JAR hay que usar. Actualmente, la información de este archivo JAR tan solo se usa en el código de validación de DADX.
Los archivos DAD ubicados en el directorio Dir_instalación_WS\wstools\eclipse\plugins\com.ibm.etools.webservice_<versión>\samples\DADX_examples tal vez tengan que modificarse para que reflejen la configuración concreta del sistema.
Cerca de la parte superior del archivo hay una línea como esta:
<!DOCTYPE DAD SYSTEM "c:\dxx\dtd\dad.dtd">
Si XML Extender se ha cargado en una ubicación que no sea c:\dxx, hay que actualizar esta serie mediante otra que refleje la ubicación real. Esto también atañe a las máquinas Linux, donde la ubicación suele ser /usr/IBMdb2xml.
- En la página Propiedades de grupo DADX de servicio Web del asistente de servicios Web, puede ocurrir que los cambios no entren en vigor inmediatamente. Por lo tanto, le recomendamos que, cuando haga cambios en las propiedades de grupo DADX, utilice el asistente de configuración de grupo DADX.
- Después de editar y validar un archivo DADX, es posible que en la vista Tareas aparezca un mensaje con la indicación de que es preciso reconstruir el proyecto. En tal caso, pulse el proyecto en cuestión con el botón derecho del ratón y seleccione Reconstruir proyecto. Tal vez tenga que hacerlo otra vez para que el mensaje desaparezca de la vista Tareas.
Los diálogos emergentes del explorador de servicios Web pueden no visualizarse correctamente si están funcionando a la vez Mozilla y Netscape. Son emergentes el diálogo Examinar WSDL y el diálogo Examinar categoría. Para salir al paso de este problema, utilice Mozilla o Netscape, pero no los dos navegadores al mismo tiempo.
Las funciones definidas por usuario (UDF) figuran en el asistente Generar DADX, pero actualmente no existe soporte para generar DADX a partir de las funciones definidas por el usuario. Solo hay soporte para generar DADX a partir de archivos DAD, procedimientos almacenados y sentencias SQL. Si se selecciona una función definida por usuario (UDF), se generará un archivo de esqueleto DADX simple.
Si ha importado un archivo de servicios Web de 4.0.x, es posible que reciba los siguientes mensajes de error:
Error La parte 'result' tiene definido un valor 'anyElement' que no es válido para el tipo. Las declaraciones de tipo deben hacer referencia a valores válidos definidos en un esquema.
Error La parte 'return' tiene definido un valor 'findPatientResult' que no es válido para el elemento. Las declaraciones de elemento deben hacer referencia a valores válidos definidos en un esquema.
Error La parte 'response' tiene definido un valor 'findPatientResponse' que no es válido para el elemento. Las declaraciones de elemento deben hacer referencia a valores válidos definidos en un esquema.Para salir al paso de este problema:
- Suprima los archivos WSDL.
- Regenere los servicios Web volviendo a ejecutar el asistente Servicios Web.
- El ejecutar WebSphere Studio en Linux con GTk, el asistente de creación de servicios Web siempre toma por omisión el tipo de servicio Web "Servicio Web de bean Java de esqueleto", independientemente de la selección efectuada en el entorno de trabajo. El usuario debe alterar temporalmente el valor por omisión y elegir el tipo de servicio Web deseado.
- El problema se produce en Linux con servidores Tomcat 4.1 y 4.0 que tienen instalado webapp con Axis. Si el servidor se ha iniciado y es necesario reiniciarlo en algún punto del asistente de servicios Web, el asistente puede colgarse debido a que Axis impide que el servidor Tomcat se detenga.
Esto puede solucionarse deteniendo el servidor antes de iniciar el asistente de servicios Web y deseleccionando "Ejecutar en servidor" en la página del asistente que genera la aplicación de servicio Web de prueba.
- Opción FileNStoPkg: La opción -fileNStoPkg para WSDL2WebService en la línea de mandatos no funciona actualmente. Utilice -NStoPkg y escriba cada correlación en la línea de mandatos. Otra opción es utilizar el asistente de servicios Web si es necesaria la correlación de espacio de nombres con paquete.
- Directorio con espacio: Evite ejecutar WSDL2WebService desde un directorio que contenga un espacio en el nombre del directorio. De lo contrario, el archivo compile.bat (o compile.sh en Linux) generado no se compilará.
- Descripciones de despliegue de cliente y archivos WSDL: Después de ejecutar Bean2WebService, EJB2WebService, WSDL2WebService, los descriptores de despliegue del lado del cliente (webservicesclient.xml, ibm-webservicesclient-bnd.xmi, ibm-webservicesclient-ext.xmi y _mapping.xml) se encuentran bajo lado-cliente/META-INF. Si el usuario tiene previsto crear una aplicación cliente gestionada, debe seguir los siguientes procedimientos:
- Para ejecutar el cliente gestionado en forma de Cliente de aplicación EJB o J2EE, el usuario debe empaquetar todos los descriptores de despliegue de META-INF del archivador, además de copiar el wsdl del lado de servicio (bajo WEB-INF/wsdl si el servicio está en un contenedor Web o META-INF/wsdl si el servicio está en un contenedor EJB) en META-INF/wsdl del proyecto cliente.
- Para ejecutar el cliente gestionado dentro del contenedor Web, el usuario debe empaquetar todos los descriptores de despliegue de WEB-INF del archivador de cliente (generalmente en forma de WAR o de proyecto Web en WebSphere Studio). El archivo WSDL también debe copiarse desde el lado de servicio en WEB-INF/wsdl. El usuario también debe editar manualmente webservicesclient.xml (mediante un editor de texto o, en WebSphere Studio, el editor xml) sustituyendo todas las apariciones de META-INF por WEB-INF.
Nombre de clase con subrayado: Al crear un servicio Web desde un bean Java o desde EJB, si el nombre de clase del bean de servicio contiene un subrayado y el carácter siguiente está en minúsculas (por ejemplo, test.Simple_bean), el servicio no podrá iniciarse en WebSphere Application Server. La solución consiste en utilizar un nombre de bean de servicio sin subrayados o utilizar una letra mayúscula después del subrayado (por ejemplo, test.Simple_Bean).
- En un caso práctico de creación de un servicio Web sin un servidor Web existente en el área de trabajo, al pulsar el botón Atrás en la tercera página, el botón Siguiente quedará inhabilitado. La solución consiste en cancelar el asistente y reiniciarlo. Para evitar este problema, cree el servidor y la configuración antes de iniciar la creación del servicio Web o evite pulsar Atrás en la tercera página si no existe ningún servidor Web.
- Cuando el usuario pulsa un archivo Java con el botón derecho en el entorno de trabajo, la acción de menú emergente Generar aplicación de ejemplo del menú Servicios Web genera JSP de ejemplo de servicios Web para un proxy SOAP IBM. Para generar JSP de ejemplo de servicios Web para los demás soportes de ejecución de servicios Web (IBM WebSphere 5.0.2 y Apache Axis 1.0), pulse un archivo WSDL con el botón derecho y elija la acción de menú emergente Generar cliente en el menú Servicios Web. Al recorrer el asistente, seleccione Probar el proxy generado.
Al generar esqueletos o clientes desde un archivo WSDL que contenga importaciones relativas y esté protegido por autenticación básica HTTP, el usuario verá un mensaje de error que indica que el archivo WSDL no puede resolverse aunque se hayan especificado el ID de usuario y la contraseña correctos. El problema consiste en que el ID de usuario y la contraseña sólo se utilizan para recuperar el archivo WSDL original, y no los archivos importados por él.
Para evitar este problema, el usuario puede bajar primero el archivo WSDL y todos los archivos importados por éste al entorno de trabajo y, a continuación, generar el esqueleto o el cliente a partir del archivo WSDL bajado.
- Sin soporte para WSDL: La adición de WSDL al URL de punto final de un servicio Web desplegado en WebSphere v5.0.2, ejecutado en el entorno de prueba o de servidor remoto, para obtener el archivo WSDL del servicio Web desplegado no está soportada. El archivo WSDL generado puede encontrarse en WebContent/WEB-INF/wsdl del proyecto Web para servicio Web de bean Java y en ejbModule/META-INF/wsdl del proyecto EJB para servicio Web EJB. Si es necesario el servicio WSDL desde un proyecto Web, el usuario puede hacer referencia a la copia del archivo WSDL bajo WebContent/wsdl del proyecto Web o crear su propia ubicación bajo WebContent y servir el WSDL desde el proyecto Web.
- Tener un JAR de utilidad o más de una carpeta fuente: Al crear un servicio Web desde un bean Java o EJB, pueden generarse archivos innecesarios en el módulo si existe más de una carpeta fuente en el proyecto Web o si los beans se encuentran en un JAR de utilidad dentro del archivo EAR. Dado que estos archivos generados ya existen en el módulo (en el JAR de utilidad o en otra carpetas fuente), deben suprimirse para que el proyecto pueda compilarse y para que el servicio Web funcione correctamente. Otra solución consiste en fusionar las carpetas fuente en una o copiar los beans del JAR de utilidad en la carpeta fuente.
- Matriz no soportada en RPC/literal: Al crear un servicio RPC/literal, la firma de método no puede contener una matriz. Si es así, el servicio no puede invocarse con el código de cliente generado. Actualmente, no hay ninguna solución para este problema. Intente utilizar document/literal o RPC/encoded, si es posible.
- Sobrecarga de métodos no soportada en document/literal: La sobrecarga de métodos (mismo nombre de método, parámetros de entrada diferentes) no está soportada al crear un servicio de tipo document/literal. Actualmente, no hay ninguna solución para este problema. Intente utilizar RPC/literal o RPC/encoded, si es posible.
- Importación de WSDL: La sentencia import de WSDL sólo puede tener URL absolutos o relativos en el mismo directorio. Por ejemplo, la importación relativa no está soportada en el siguiente formato:
<import namespace="http://someNamespace/" location="../someFile.wsdl"/>- Elemento binding antes del elemento portType: Recibirá un "Error al generar archivos Java y descriptores de despliegue desde WSDL (detalle: nombre de operación duplicado)" al generar un esqueleto o proxy de cliente desde un archivo WSDL que contenga el elemento binding antes del elemento portType.
- Elementos abstractos: Al generar esqueletos desde un archivo WSDL con una operación que utilice elementos o tipos abstractos, los JavaBeans generados no se compilarán.
- Tipos sin correlaciones JAX-RPC por omisión: Al generar esqueletos desde un archivo WSDL con operaciones que tengan parámetros de entrada/salida de tipos que no tengan correlaciones JAX-RPC por omisión, el bean de implementación generado no se compilará. El problema consiste en que, cuando se crea javax.xml.soap.SOAPElement desde javax.xml.soap.SOAPFactory, lanza una javax.xml.soap.SOAPException. El bean de implementación no captura ni relanza esta excepción y, por tanto, no se compilará.
- Mismo tipos de esquema para entrada y salida: Al generar esqueletos desde un archivo WSDL que utiliza el mismo tipo de esquema XML para sus mensajes de entrada/salida y para los mensajes de error, los artefactos generados no funcionarán durante la ejecución. Para solucionar este problema, no comparta las definiciones de tipo de esquema XML entre los mensajes de entrada/salida y los mensajes de error.
- Referencias a elemento XSD con minOccurs y maxOccurs: Al generar esqueletos desde un archivo WSDL, no utilice referencias a elementos XSD con valores minOccurs y maxOccurs especificados por el usuario (<element ref="..." minOccurs="0" maxOccurs="unbounded"/>). la utilización de tales elementos provocará una java.util.MissingResourceException durante el inicio del servidor.
- Las API del bean emitido son diferentes de las del bean de servicio: Si las API de los beans generados por el emisor son diferentes de las del bean de servicio al crear un servicio Web desde un bean Java o EJB, puede producirse un error de ejecución como el siguiente:
El método es indefinido.
No se ha encontrado una operación Java coincidente.
Son ejemplos de bean de servicio cuyas API son diferentes a las de los beans generados:
- beans con campos públicos,
- campos booleanos con método get denominado getBooleanValue en lugar de isBooleanValue,
- nombre de método en mayúsculas
Literal de documento con envoltura: Al crear un servicio Web ascendente mediante literal de documento, por omisión, la opción de envoltura está activada. Puede producirse un problema de interoperabilidad si tiene más de una entrada con tipos diferentes o no tiene ninguna entrada en absoluto. La solución consiste en utilizar RPC/literal. Bean Java con el nombre en minúsculas o con subrayados: Al crear un servicio Web desde un bean java con el nombre de archivo en minúsculas o con subrayados seguidos de una letra en minúsculas, obtendrá el error:
Error al generar archivos Java y descriptores de despliegue desde archivo WSDL con detalles de getOutputStream() IOException.Configuración de seguridad diferente: No genere servicios Web con configuraciones de seguridad diferentes en el mismo módulo/proyecto. Utilice proyectos independientes para cada servicio Web.
Si se utiliza WebSphere Application Server V5.0 para alojar un servicio Web DADX, el archivo group.properties del grupo DADX debe utilizar la siguiente propiedad initialContextFactory:
initialContextFactory=com.ibm.websphere.naming.WsnInitialContextFactoryAsimismo, debe añadirse lo siguiente al archivo web.xml del proyecto que contiene el grupo DADX. (Suponiendo que el nombre JNDI del origen de datos sea jdbc/hospital.)
<resource-ref id="ResourceRef_1058550453092">
<res-ref-name>jdbc/hospital</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>CONTAINER</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>
Si el Cliente de prueba universal no puede precargar la clase de localizador de cliente generada por el soporte de ejecución de WebSphere v5.0.2 o Axis, se debe a que el nombre de la clase de bean Java del proyecto Web de servicio es el mismo que el nombre de la clase SEI del proyecto Web del cliente. Para solucionar este problema:
- Elimine el proyecto Web de cliente del área de trabajo.
- Pulse el proyecto Web de cliente con el botón derecho y pulse "Suprimir".
- Localice el archivo application.xml en el proyecto EAR y efectúe una doble pulsación sobre el archivo para abrir el editor Descriptor de despliegue de aplicación. Seleccione el módulo del proyecto Web de cliente y pulse "Eliminar". Cierre el editor y guarde los cambios.
- Cree el proyecto Web de cliente bajo un EAR diferente, en el que el nombre del proyecto EAR debe derivarse alfabéticamente del nombre del proyecto EAR de servicio. Por ejemplo, si el nombre del proyecto EAR de servicio es "DefaultEAR", cree el proyecto EAR nuevo con el nombre "ClientEAR".
- Vuelva a ejecutar el asistente de servicios Web.
Las preferencias de sobreescribir archivos, creación de carpetas y reserva automática de archivos no se conservan al crear servicios Web mediante el soporte de ejecución de WebSphere v5.0.2 y Axis. La creación de carpetas se permite siempre y la reserva automática de archivos nunca se habilita.
Al utilizar el soporte de ejecución de WebSphere v5.0.2, el archivo WSDL, SEI y los artefactos de despliegue (serializadores y deserializadores) se sobreescriben siempre. Los artefactos de desarrollo (bean de servicio, beans de tipo complejo, clases de retención y ayuda) nunca se sobreescriben. Sin embargo, el usuario recibirá un aviso acerca de la sobreescritura de los descriptores de despliegue, si existen. Puede elegir Aceptar para sobreescribir los descriptores de despliegue y continuar con el trabajo o pulsar Cancelar para evitar que se sobreescriban los descriptores.
Al utilizar el soporte de ejecución de Apache Axis 1.0, los emisores de Axis generan de nuevo cada vez todos los archivos Java de servidor/cliente, deploy.wsdd y undeploy.wsdd. En el caso práctico de generación de servicio, WSDL2Java sólo generará el archivo de implementación de esqueleto, si aún no existe. Si esta implementación ya existe, no se sobreescribirá.
La creación de servicios Web mediante el soporte de ejecución de Apache Axis 1.0 se sustenta en los emisores Java2WSDL y WSDL2Java suministrados en Axis 1.0. El soporte para documento/literal y documento/literal (con envoltura) es problemático en Axis 1.0; por tanto, el usuario debe utilizar RPC/encoded al crear servicios Web mediante el soporte de ejecución de Apache Axis 1.0.
Al definir una correlación personalizada entre paquete y espacio de nombres, aparecen un paquete y un espacio de nombres por omisión erróneos en la tabla después de pulsar el botón Añadir; el usuario debe sobrescribir estos valores por omisión y especificar su propia correlación de paquete y espacio de nombres.
Al generar esqueletos o proxys de servicio Web desde un archivo WSDL que utilice el mismo nombre para uno de sus elementos <service> y para el elemento <port>, no utilice JSP de ejemplo como cliente de prueba. Los JSP de ejemplo generados contienen errores y no se compilarán. Los intentos de ejecutar los JSP de ejemplo en el servidor provocarán un ERROR 500 en el navegador, que indica que los JSP de ejemplo no pueden cargarse, y excepciones en la consola del servidor, que indican que el contenedor de servlets no ha podido compilar los JSP de ejemplo.
El asistente de creación de servicios Web puede fallar durante la generación de WSDL si el nombre de sistema principal "localhost" no está definido en la máquina. El cliente de prueba universal (UTC) tampoco se lanzará satisfactoriamente si no se ha definido "localhost".
En Windows, debe figurar la siguiente entrada en el archivo [INSTALL-DRIVE]\WINNT\system32\drivers\etc\hosts:
127.0.0.1 localhost
En Linux, debe figurar la siguiente entrada en el archivo /etc/hosts:
127.0.0.1 localhost
El soporte de ejecución SOAP de IBM debe utilizarse principalmente por razones de compatibilidad hacia atrás. Es muy aconsejable utilizar el asistente de servicios Web con el soporte de ejecución de IBM WebSphere 5.0.2 a todos los efectos de producción. Al utilizar el asistente de servicios Web con el soporte de ejecución SOAP de IBM, el usuario puede verse sometido a las siguientes limitaciones:
- Generar un documento WSDL desde un bean Java
- Para los tipos de datos char y java.lang.Character, hay que especificar correlaciones personalizadas porque no existen correlaciones por omisión entre char o java.lang.Character y XSD WSDL.
- Los tipos de envoltura de primitivos java.lang.Boolean, java.lang.Byte, java.lang.Short, java.lang.Integer, java.lang.Long, java.lang.Float y java.lang.Double no pueden coexistir con los correspondientes tipos primitivos individuales boolean, byte, short, int, long, float y double en todos los parámetros de entrada de un bean de servicio. Por ejemplo, un bean de servicio en el que los tipos java.lang.Integer e int aparezcan como tipos de parámetro de entrada no puede convertirse en un servicio Web completo. Cuando se intente utilizar el asistente Servicio Web para crear un servicio Web a partir de este tipo de bean de servicio, aparecerá un mensaje de aviso, a menos que los métodos que contengan los tipos primitivos o los tipos de envoltura no estén seleccionados en la página Métodos de bean Java de servicio Web del asistente. Sin embargo, debe asegurarse de que estos métodos no estén seleccionados la primera vez que vea la página Métodos de bean Java de servicio Web. Si vuelve a esta página y borra los métodos problemáticos después de haber visto el aviso, es posible que se cree un servicio Web incompleto. En ese caso, debe reiniciar el asistente para poder seleccionar los métodos adecuados la primera vez que vea la página Métodos de bean Java de servicio Web.
- Las matrices multidimensionales no están soportadas. Una alternativa en Java consiste en insertar beans Java entre las dimensiones. Por ejemplo, en lugar de MyType[][], funcionará el patrón MyArray[], donde MyArray tenga una propiedad de tipo MyType[].
- Para un método con una lista de argumentos de entrada que contenga una combinación de Elemento DOM y tipos de bean simples, se necesita la entrada de una o varias correlaciones personalizadas. La especificación WSDL (lenguaje de descripción de servicios Web) Versión 1.1 da soporte a un estilo de codificación para todos los componentes de entrada (parámetros). La unidad ejecutable SOAP (protocolo simple de acceso a objetos) Versión 2.2 no tiene soporte de correlación por omisión para Elemento DOM con codificación SOAP para tipos primitivos y beans con codificación XML Literal.
- Si al configurar una correlación personalizada intenta utilizar la clase de serializador o deserializador de la unidad ejecutable SOAP (es decir, las clases del paquete org.apache.soap.encoding.soapenc) y aparece el mensaje de error "La clase de serializador/deserializador seleccionada no se puede cargar desde este proyecto", lo más probable es que el archivo soap.jar no esté en la vía de construcción de su proyecto Web. Para corregir el problema, cancele el asistente y utilice el diálogo de propiedades del proyecto Web para añadir Dir_instalación_WS\wstools\eclipse\plugins\com.ibm.etools.webservice\runtime\soap.jarr a la vía de construcción del proyecto Web; luego reintente el asistente de servicios Web.
- La correlación personalizada no está soportada en los tipos complejos anidados. Aunque los tipos anidados aparecerán en la página de correlación del asistente, se pasarán por alto las correlaciones personalizadas de esos tipos.
- Al crear un servicio Web a partir de una clase Java cuya interfaz contiene un tipo Java abstracto, la página Correlaciones de Java con XML de servicios Web puede establecer incorrectamente que el campo de deserializador para el tipo abstracto es org.apache.soap.encoding.soapenc.BeanSerializer. Esto fallará en tiempo de ejecución, porque el código deserializador de la clase BeanSerializer no podrá construir una instancia del tipo abstracto. Para evitarlo, elija la opción Correlación personalizada del tipo, si lo considera necesario, y cambie el campo de deserializador por el nombre de una clase escrita para deserializar el tipo abstracto.
- Actualmente, las herramientas de servicios Web no dan soporte a la creación de servicios Web a partir de beans Java que contengan clases internas anidadas (es decir, clases internas definidas dentro de una clase de nivel superior). Para evitar que se produzca este problema, debe mover las clases internas a las clases de nivel superior en archivos Java aparte.
- Al crear un servicio Web a partir de un bean Java que utilice otros beans Java con propiedades de tipo Vector, Hashtable o Map, se generará XSD con tipos complejos que contengan los tipos "Vector" y "Map" del espacio de nombres "http://xml.apache.org/xml-soap". Dado que actualmente no existe ningún esquema para este espacio de nombres, el validador de XSD emitirá mensajes de error y aviso como los siguientes:
Estos errores y avisos no interferirán en el proceso correcto de WSDL y XSD realizado por los asistentes de servicios Web. Los tipos "Map" y "Vector" se correlacionarán correctamente con sus equivalentes en Java. Tenga en cuenta que otros proveedores podrían tener dificultades al procesar WSDL o XSD que contenga estos tipos, porque las especificaciones WSDL 1.1 o SOAP 1.1 no reconocen el espacio de nombres http://xml.apache.org/xml-soap. Para mejorar la interoperatividad, plantéese la posibilidad de adaptar las clases de colecciones Java a las matrices y beans, para luego construir los servicios Web a partir de los adaptadores.
- Error src-resolve: No se puede resolver el nombre 'xsd2:Vector' en un componente de definición de tipo.
- Aviso src-import.0: No se ha podido leer el documento de esquema importado 'null'.
- Generar artefactos Java a partir de un documento WSDL
- El soporte está limitado a un solo part (componente) por cada elemento input o output (entrada o salida). No están soportados múltiples part lógicos en un mensaje de entrada o de salida. En este caso, se procesaría el primer part, y los demás se pasarían por alto.
- Al generar esqueletos o proxys de servicios Web a partir de un archivo WSDL que utilice el tipo base64Binary del espacio de nombres xsd (http://www.w3.org/2001/XMLSchema), la unidad ejecutable de servicios Web utilizará en realidad el xsi:type base64 del espacio de nombres soapenc (http://schemas.xmlsoap.org/soap/encoding/). En general, los dos tipos se pueden intercambiar libremente. Sin embargo, es posible que la diferencia entre el tipo del mensaje y el tipo del esquema provoque que algunas unidades ejecutables de protocolo SOAP rechacen el mensaje. Si fuera así, puede crear manualmente un serializador similar a Base64Serializer de SOAP Apache, pero que se escriba xsd:base64binary en vez de soapenc:base64.
- Los esqueletos de beans Java no se compilarán si se crean a partir de documentos WSDL que contengan nombres de operaciones y componentes que no sean identificadores Java válidos. Los nombres de operaciones y componentes WSDL deben ser identificadores Java válidos para conseguir una creación satisfactoria de un esqueleto de bean Java.
- Los asistentes de servicios Web emplean por omisión identificadores URI "http" al generar WSDL; sin embargo, algunos documentos WSDL de otras herramientas pueden emplear ocasionalmente identificadores URI de servicios Web, Acción SOAP o espacio de nombres destino que empleen esquemas distintos de "http", como puede ser "urn". Al generar proxys o esqueletos a partir de un documento WSDL que contenga identificadores URI no http, los asistentes de servicios Web pueden correlacionar los URI con el paquete Java "com.example", en vez de hacerlo con un paquete que tenga más sentido. En algunos casos, los asistentes de servicios Web no pueden manejar del todo esos URI y se emite el mensaje de error "IWAB0234E Se produjo un error interno"
- Ahora, al generar proxys Java y esqueletos Java a partir de WSDL, tiene la oportunidad de correlacionar los tipos intrínsecos boolean, byte, short, int, long, float y double de XSD con los tipos de envoltura "java.lang" (por ejemplo, java.lang.Integer), en lugar de hacerlo con los primitivos Java (por ejemplo, int). Por omisión, los asistentes de servicios Web harán la correlación con los primitivos Java. Para conseguir que los asistentes hagan la correlación con las clases de envoltura "java.lang", abra Ventana -> Preferencias -> Servicios Web -> Generación de código, y marque el recuadro "Correlacionar tipos de datos XML simples con clases de envoltura java.lang".
- Cuando se especifica una correlación personalizada de un tipo Java con un tipo XSD al crear un servicio Web desde un bean Java o EJB, el campo de clase de bean se establece automáticamente en el nombre completo del tipo Java y no se puede editar. En una correlación personalizada de una matriz Java, el nombre de la clase de bean tendrá un formato de matriz (por ejemplo, "java.lang.String[]") y se representará como tal en los archivos de descriptor de despliegue ".isd" y "dds.xml". Los nombres de clase que tienen este formato no se procesan correctamente en la unidad ejecutable SOAP y se producirá un error parecido a este:
Error de despliegue en el servicio SOAP http://tempuri.org/webservice.AddressBook': no se ha podido resolver el nombre de clase: java.lang.String[]: java.lang.String[]
Como consecuencia, no será posible una correlación personalizada del serializador para una matriz Java del lado del servicio. Una manera de evitar parcialmente este problema es dejando vacío el campo de la clase de serializador en la correlación personalizada. Ello suprimirá la generación del nombre de clase de tipo matriz en el descriptor de despliegue y permitirá que el servicio funcione. Tenga en cuenta que este problema y la manera de evitarlo no afectan a la clase de deserializador ni a la capacidad de correlacionarlo de forma personalizada.
- Consideraciones de tiempo de ejecución
- Si selecciona "Habilitar correlación basada en elemento" como preferencia de generación de código de servicios Web y seleccionó el despliegue en un servidor WebSphere Application Server V4, podría aparecer la siguiente entrada en el archivo ISD y en dds.xml:
<isd:map
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:x=""
qname="x:un-nombre"
xml2JavaClassName="un-serializador"/>El editor XML podría señalar el siguiente error:
El valor del atributo "xmlns:x" no es válido. Los enlaces de espacio de nombres prefijados no pueden estar vacíos.
Esto no afecta negativamente al servidor WebSphere Application Server V4. Sin embargo, no intente desplegar este archivo dds.xml en otro servidor que utilice Xerces 2.x (XML4J 4.x) o superior, como por ejemplo en WebSphere Application Server V5. De lo contrario, se producirían errores de análisis de Xerces similares cuando el servidor cargase el archivo dds.xml. Debe regenerar el archivo dds.xml volviendo a las instrucciones paso a paso del caso práctico de servicios Web y seleccionando el tipo de servidor adecuado. Así se generará el archivo dds.xml correcto para ese tipo de servidor.
Asimismo, se producirían errores de análisis de Xerces similares al intentar desplegar el servicio Web desde ese archivo ISD. Una manera de salir al paso de este problema consiste en editar manualmente el archivo dándole el formato:
<isd:map
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
qname="un-nombre"
xml2JavaClassName="un-serializador"/>
- Al invocar un servicio Web creado a partir de un bean Java o EJB, si recibe una excepción SOAPException con otra targetException como:
"java.lang.IllegalArgumentException: No se puede crear instancia de ..."
El problema puede deberse a que un método expuesto como servicio Web contiene un bean Java sin un constructor público por omisión como parámetro y/o tipo de retorno. Se necesita un constructor público por omisión para que la unidad ejecutable SOAP construya el objeto como parte del proceso de deserialización.- Los archivos de seguridad, cl-ver-config.xml y sv-ver-config.xml, desplegados actualmente en el proyecto Web son los archivos de WebSphere Versión 4.0 y no coinciden exactamente con las DTD. Pero los archivos funcionarán en las dos versiones, 4.0 y 5.0, de WebSphere a pesar de los errores de validación que indican que hay que declarar "xmlns:ds" o "xmlns:SOAP-SEC".
- Si se abre la configuración del servidor en un editor, el asistente de servicios Web tal vez no pueda iniciar el servidor debido a que no se haya añadido el proyecto Web de servicio Web a la configuración del servidor. El problema se resolverá cerrando el editor de configuraciones de servidor.
- Servicios Web ISD
- Después de cumplimentar una correlación personalizada al crear servicios Web Java o EJB, la información de correlación personalizada, excepto el URL de ubicación XSD, se almacena en el archivo ISD. La información se recupera al crear servicios Web a partir de ese archivo ISD. Por consiguiente, al crear servicios Web a partir de un archivo ISD, en la página Correlaciones de Java con XML de servicios Web del asistente, debe cumplimentar el URL de ubicación XSD manualmente.
Si crea un servicio Web desde un bean Java o EJB, eligiendo el soporte de ejecución SOAP de IBM para el servicio y Apache Axis 1.0 como soporte de ejecución de cliente, puede que reciba el error:
WSDL no encontrado
Para evitar el problema, cree primero el servicio Web sin elegir generar un proxy. A continuación, cree un cliente de servicio Web desde el archivo WSDL generado.
En el asistente de cliente de servicios Web, si el usuario pulsa Finalizar en la página Configuración de entorno de cliente, obtendrá el error:
"null" no puede resolverse
La solución consiste en pulsar Siguiente en esa página y en la siguiente y, a continuación, pulsar Finalizar.
En las hojas de apuntes Crear, probar y validar un servicio Web compatible con WS-I y Crear un servicio Web desde un archivo WSDL, si utiliza el archivo HelloService.wsdl de wsad_install/wstools/eclipse/plugins/com.ibm.etools.cs.wsdl.content_5.1/examples, modifique la ubicación del puerto de servicio en función al soporte de ejecución, de la forma siguiente:
Para IBM SOAP:
location="http://localhost:9080/HelloWorldSample/servlet/rpcrouter"
Para Apache Axis o WebSphere 5.0.2:
location="http://localhost:9080/HelloWorldSample/services/Hello_Port"
Si importa su propio archivo wsdl, asegúrese de que la ubicación está establecida correctamente de acuerdo con el soporte de ejecución seleccionado.
Volver al archivo readme principal
(C) Copyright IBM Corporation 2000, 2003. Reservados todos los derechos.