Sugerencias para la resolución de problemas de serialización y deserialización de servicios web

Utilice estas sugerencias para solucionar los problemas que pueda tener al realizar la serialización y deserialización en los servicios web.

Cada sección de este tema muestra un problema que puede encontrar al serializar y deserializar servicios web. Se proporciona una solución para ayudarle a resolver el problema.

La información de huso horario en java.util.Calendar deserializado no es como se esperaba

Cuando el cliente y el servidor se basan en código Java™ y se recibe una instancia java.util.Calendar, el huso horario de la instancia de java.util.Calendar recibida podría ser distinto del de la instancia de java.util.Calendar que se ha enviado.

Esta diferencia se produce porque la instancia java.util.Calendar se codifica como xsd:dateTime. Es necesario un xsd:dateTime para codificar la hora correcta (hora base más o menos un desplazamiento del huso horario), pero no es necesario conservar la información de entorno local, incluido el huso horario original.

El hecho de que no se conserva el huso horario para el entorno local ha de tenerse en cuenta a la hora de comparar instancias de Calendar. La clase java.util.Calendar iguala comprobaciones de método que tengan husos horarios iguales cuando se determina la igualdad. Dado que el huso horario de la instancia de Calendar deserializada podría no coincidir con el entorno local actual, utilice los métodos de comparación antes y después para probar que los dos Calendar hacen referencia a la misma fecha y hora como se muestra a continuación:
java.util.Calendar c1 = ...// Fecha y hora en el huso horario 1
java.util.Calendar c2 = ...// Misma fecha y hora equivalente, pero en el huso horario 2

// c1 y c2 son distintos porque sus husos horarios son distintos
if (c1.equals (c2)) System.out.println("c1 y c2 son iguales");

// pero el resultado de la comparación de c1 y c2 es "no antes y no después" dado que representan 
la misma fecha y hora
if (!c1.after(c2) & !c1.before(c2) {
						System.out.println("c1 y c2 son equivalentes");
}

La combinación de enlaces de cliente y servidor de servicios web produce errores

Las especificaciones de servicios web para Java EE (Java Platform, Enterprise Edition) y JAX-RPC (API Java para llamadas a procedimiento remoto XML) no admiten la correlación de ida y vuelta entre el código Java y los documentos WSDL (Web Services Description Language) para todos los tipos Java. Por ejemplo, no puede convertir o serializar una fecha Java a código XML y volverla a convertir o deserializarla a una fecha Java. Esta acción se deserializa como Calendar Java.

Si ha creado una implementación de Java a partir de un documento WSDL y genera enlaces cliente del documento WSDL, las clases cliente pueden ser distintas de las clases servidor aún cuando las clases cliente tengan el mismo nombre de paquete y clase. Las clases de cliente de servicio web deben mantenerse independientes de las clases de servidor de servicio web. Por ejemplo, no coloque las clases de enlaces de servidor de servicio web en un archivo JAR (archivador Java) de programa de utilidad y, a continuación, incluya un archivo JAR de cliente de servicio web que hace referencia al mismo archivo JAR de programa de utilidad.

Si no mantiene las clases de cliente y servidor de servicios web independientes, se pueden producir distintas excepciones, en función de las clases Java utilizadas. A continuación figura un error de rastreo de pila de ejemplo que puede producirse:
com.ibm.ws.webservices.engine.PivotHandlerWrapper TRAS0014I: La siguiente excepción era java.lang.NoSuchMethodError: com.ibm.wssvt.acme.websvcs.ExtWSPolicyData:
   method getStartDate()Ljava/util/Date; 
not found 
at com.ibm.wssvt.acme.websvcs.ExtWSPolicyData_Ser.addElements(ExtWSPolicyData_Ser.java: 210)
at com.ibm.wssvt.acme.websvcs.ExtWSPolicyData_Ser.serialize (ExtWSPolicyData_Swer.java:29)
at com.ibm.ws.webservices.engine.encoding.SerializationContextImpl.serializeActual 
(SerializationContextImpl.java 719)
at com.ibm.ws.webservices.engine.encoding.SerializationContextImpl.serialize 
(SerializationContextImpl.java: 463)
El problema se ha producido por utilizar una interfaz como se muestra en el siguiente ejemplo para la interfaz de punto final de servicio en la implementación del servicio:
package server:
public interface Test_SEI extends java.rmi.Remote {
		public java.util.Calendar getCalendar () throws java.rmi.RemoteException;
		public java.util.Date getDate() throws java.rmi.RemoteException;
}
Cuando se compila y ejecuta esta interfaz mediante la herramienta de línea de mandatos Java2WSDL, el documento WSDL establece la correlación de los métodos como se detalla en el ejemplo siguiente:
<wsdl:message name="getDateResponse">
		<wsdl:part name="getDateReturn" type="xsd:dateTime"/>
</wsdl:message>

<wsdl:message name="getCalendarResponse">
		<wsdl:part name="getCalendarReturn" type="xsd:dateTime"/>
</wsdl:message>
La correlación JAX-RPC que implementa la herramienta Java2WSDLha establecido la correlación de las dos instancias java.util.Date y java.util.Calendar con el tipo XML xsd:dateTime. El paso siguiente consiste en utilizar el archivo WSDL generado para crear un cliente para el servicio web. Cuando ejecuta la herramienta de línea de mandatos WSDL2Java en el WSDL generado, las clases generadas incluyen una versión distinta de la interfaz server.Test_SEI, por ejemplo:
package server;
public interface Test_SEI extends java.rmi.Remote {
		public java.util.Calendar getCalendar () throws java.rmi.RemoteException;
		public java.util.Calendar getDate() throws java.rmi.RemoteException;
}

La versión de cliente de la interfaz service.Test_SEI es distinta de la versión de servidor en que los dos métodos getCalendar y getDate devuelven java.util.Calendar. El código de serialización y deserialización que espera el cliente es la versión cliente de la interfaz de punto final de servicio. Si la versión servidor se encuentra inadvertidamente en la variable CLASSPATH del cliente, ya sea en tiempo de compilación o de ejecución, se produce un error.

Además del error NoSuchMethod, puede producirse IncompatibleClassChangeError y ClassCastException. Sin embargo, casi cualquier excepción de tiempo de ejecución puede producirse. El método recomendado es ser diligentes separando las clases de enlaces de servicios web de cliente de las clases de enlaces de servicios web de servidor. Ponga siempre las clases de enlaces de cliente y las clases de enlaces de servidor en módulos distintos. Si estas clases de enlaces están en la misma aplicación, ponga las clases de enlaces en archivos JAR del programa de utilidad que no se comparten entre módulos.


Icon that indicates the type of topic Reference topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rwbs_trbserialize
File name: rwbs_trbserialize.html