El API Apache SOAP v2.2

Este documento explica los cambios que debemos hacer para migrar desde Apache SOAP v2.1 a Apache SOAP v2.2.

�XMLParserLiaison Reemplazado con JAXP

Anteriomente usamos una soluci�n casera para conseguir un analizador XML independiente. Sin embargo, dada la liberaci�n del mecanismo Java para hacer esto, nos hemos decidido a usar JAXP. �Qu� significa esto? Significa que si tenemos un c�digo que usaba XMLParserLiaison tenemos que cambiar ese c�digo. Afortunadamente, los cambios son simples: el ejemplo [differences between v1.2 and v1.3 of the "messaging"], nos muestra exactamente que hacer!

Algunas veces, este cambio podr�a ser necesario incluso si no tenemos ning�n c�digo que use directametne XMLParserLiaison. Si est�s viendo esto, por favor, recompila tu c�digo con el jar de la versi�n 2.2 en tu classpath y el problema se solucionar�.

�Mantenimiento de Sesi�n HTTP

De nuevo soportamos el mantenimiento de sesi�n HTTP. El ejemplo addressbook2 muestra un ejemplo de su uso.

El soporte por sesi�n est� activado por defecto. Si estuvieramos interesados en cualquier servicio HTTP de sesi�n con un cierto comportamiento, podr�amos ver otro comportamiento ya que el c�digo ahora mantiene correctamente las sesiones HTTP. Si queremos desactivar el soporte de sesi�n HTTP, necesitamos crear nuestro propio objeto SOAPHTTPConnection, seleccionar la propiedad de mentenimiento de sesi�n a false y seleccionar el transporte adecuado de llamada para este SOAPHTTPConnection:

Call call = new Call ();
SOAPHTTPConnection shc = new SOAPHTTPConnection ();
shc.setMaintainSession (false);
call.setSOAPTransport (shc);

// now make calls with "call"

Tener el soporte de sesi�n en el lado del cliente finalmente significa que Apache SOAP puede usarse para implementar servicios Web con estado sin tener ninguna intervenci�n del usuario para menejar esto.

�Obtener Informaci�n de Entorno para Servicios RPC

Una cuesti�n com�n con Apache SOAP v2.1 era c�mo un autor de servicios RPC podr�a acceder a informaci�n de Entorno como el objeto HTTPSession o las cabeceras HTTP. La respuesta V2.1 era que ten�amos que escribir un proveedor personalizado para hacer esto. Aunque en v2.2 hay una forma mejor y m�s simple.

RPCJavaProvider (el proveedor que ejecuta todos los servicios de estilo RPC) ahora tiene el siguiente comportamiento: cuando busca el m�todo en la clase destino para llamarlo y que procese la solicitud de servicio; si no se encuentra un m�todo con la firma correspondiente, se hace una segunda b�squeda. La segunda b�squeda busca un m�todo con argumento adicional (el primero) del tipo org.apache.soap.rpc.SOAPContext (por favor mira la documentaci�n del API para ver los detalles de esta clase). Si lo encuentra, se le pasa un ejemplar de SOAPContext a la clase manejadora del servicio.

Tener acceso al SOAPContext entrante nos da mucha libertad: podemos acceder a todo lo siguiente mediante el m�todo getProperty:

• El objeto HTTPServlet usando la clave org.apache.soap.Constants.BAG_HTTPSERVLET
• El objeto HTTPSession usando la clave org.apache.soap.Constants.BAG_HTTPSESSION
• El objeto HTTPServletRequest usando la clave org.apache.soap.Constants.BAG_HTTPSERVLETREQUEST
• El objeto HTTPServletResponse usando la clave org.apache.soap.Constants.BAG_HTTPSERVLETRESPONSE

Si la solicitud original SOAP estaba en la forma de SOAP Attachments, entonces podemos obtener las partes MIME no referenciadas usando los m�todos getBodyPart.

�Otros Problemas de Migraci�n

Si tienes otros problemas de migraci�n por favor, chequea las FAQs en http://xml.apache.org/soap/faq.