La interoperabilidad fue una de las principales razones para la creacci�n de SOAP en un primer momento. Sin embargo, como en cualquier especificaci�n no trivial, la especificaci�n SOAP deja varios �tems para la interpretaci�n. Como resultado (y tambi�n debido simplemente a implementaciones no conformes) un SOAP envelope generado por una implementaci�n SOAP podr�a no ser entidido correctamente por otra implementaci�n.
Hay un esfuerzo activo por mejorar la interoperabilidad de varias implementaciones SOAP que est� siendo dirigido en la "SOAP Builders" mailing list. Algunos de los problemas/soluciones descritos aqu� han sido encontrados por usuarios de Apache SOAP activos en este esfuerzo (incluyendo a Sam Ruby, Dug Davis y a Glen Daniels).
Si quieres leer m�s sobre problemas de interoperabilidad, puedes ver el art�culo de Keith Ballinger en MSDN. En ese art�culo Keith indentifica 3 tipos de problemas comunes de interoperabilidad: problemas de transporte, problemas de XML y problemas SOAP. Este documento explica c�mo poder configurar y mejorar la interoperabilidad de Apache SOAP con otras implementaciones de SOAP para cada uno de los tres tipos de problemas. Es importante observar que las pruebas de interoperabilidad es una tarea cont�nua y que en un futuro pueden venir otros problemas.
�Problemas de Transporte
Las dificultades aparecen principalmente con la cabecera SOAPAction que usa SOAP. Esta permitido que el valor de esta cabecera sea null (es decir, no se especifique ning�n valor), el string vac�o ("") - lo que significa que no se ha especificado "intent", o un string entrecomillado arbitrario. Los APIs Apache SOAP del lado del cliente no tienen dificultad en generar cualquiera de estos valores de SOAPAction. Y por eso no creemos que haya ning�n problema de interoperabilidad a nivel de transporte con Apache SOAP.
Otro uso com�n de SOAPAction es como el mecanismo para enrutar o despachar el SOAP envelope entrante hacia el c�digo destino que lo procesa. Apache SOAP no soporta esto - el despacho se hace realmente basado s�lo en el espacio de nombres URI del primer hijo del elemento <SOAP:Body>. Esto puede causar potenciales problemas de interoperabilidad ya que SOAP no excluye entradas de cuerpo sin espacio de nombres. Si un usuario de Apache SOAP desea implementar un servicio que debe recibir y procesar entradas de cuerpo sin espacio de nombres, actualmente no hay un mecanismo interno para enrutar esas solicitudes. Deber�a requerir algunas (relativamente peque�as) modificaciones en la infraestructura de enrutado para permitir el enrutado basado en SOAPAction.
�Problemas con XML
Hay varios problemas con XML que podr�an ocurrir, el art�culo de Keith identifica uno que causa dificultades en Apache SOAP: la presencia de un Byte Order Mark (BOM) para solicitudes SOAP codificadas en UTF-8. Si usamos Apache Xerces, creemos que Apache SOAP fallar� al leer la solicitud SOAP apropiada codificada en UTF-8 si tambi�n incluye un BOM. Aunque es legal tener un BOM para mensajes codificados en UTF-8, no es necesario que lo tenga. El �nico atajo conocido en este momento es no enviar el BOM. Apache SOAP siempre env�a SOAP envelopes usando UTF-8 actualmente y no genera el BOM. Aunque no hay soluciones conocidas para este problema cuando usamos Apache Xerces, no se sabe si usar un analizador JAXP alternativo eliminar� este problema.
El segundo tipo de problemas con XML est� relacionado con el soporte de Esquema XML. El problema viene con el hecho de que hoy en d�a hay realmente tres versiones de XML Schema en uso: la versi�n con una URI 1999 fue actualizada cuando sal�o la primera especificaci�n de SOAP v1.1 en Abril del 2000, la versi�n con una URI 2000 refleja una vesi�n casi definitiva y la especificaci�n recomendada con una URI 2001 se convirti� en final en Mayo de 2001. Apache SOAP actualmente se comporta de esta forma:
- Serializadores internos para tipos Java correspondientes a varios tipos simples de esquemas XML ser�n por defecto indicando el tipo resultante usando el Esquema XML del espacio de nombres 2001. Si se desea usar uno de los otros espacios de nombres de los esquemas XMLen los SOAP envelopes generados por Apache SOAP, entonces tenemos que editar org/apache/soap/Constants.java y cambiar los valores de las constantes NS_URI_CURRENT_SCHEMA_XSI NS_URI_CURRENT_SCHEMA_XSD a uno de los seleccionados (indicados justo antes de estas constantes). Una vez construido, el sistema resultante generar� SOAP envelopes usando el espacio de nombres deseado.
- Apache SOAP deserializar� correctamente SOAP envelopes conteniendo tipos simples de esquema XML de cualquiera de los tres espacios de nombres. Es decir, un envelope que contenga par�metros tipados usando cualquier combinaci�n de URIs de esquemas ser� reconocida y mapeada correctamente al objeto Java apropiado.
- Si el comportamiento por defecto de un serializador o deserializador no es satisfactorio, el usuario siempre puede reemplazar el comportamiento por defecto implemenando un nuevo serializador/deserializador y registrandolo como el serializador/deserializador para los tipos deseados.
Creemos que la arquitectura actual de Apache SOAP ofrece el mejor compromiso entre flexibilidad y regidez: serializa cualquier forma dada y deserializa todas las posibles formas.
�Problemas con SOAP
Dependiendo de xsi:type. El problema de interoperabilidad m�s com�n que tiene Apache SOAP hab�a sido anteriormente relacioando con el requirimiento de que todo envelope SOAP (RPC) le�do por Apache SOAP sea auto-descritivo en t�rminos de tipos. Es decir, Apache SOAP no funciona (por defecto) sin que todo valor tipado sea explicitamente tipado en el envelope usando el atributo xsi:type (ver la especificaci�n del Esquema XML para m�s detalles. Todos los SOAP envelopes generados por Apache SOAP siempre tendr�n toda la informaci�n de tipos, sin embargo, otras implementciones de SOAP no lo hacen (y no tienen porque hacerlo). De ah� el problema de interoperabilidad.
La soluci�n correcta para este problema es que el sistema de ejecuci�n SOAP tenga en cuenta la descripci�n del servicio sobre el que SOAP envelope es una solicitud, digamos una forma WSDL. Apache SOAP no tiene cuidado de WSDL y no es bueno que lo haga.
Al igual que la versi�n 2.1, Apache SOAP tiene una solucion para este problema. El problema b�sico es que algui�n tenga que decirle al motor SOAP el tipo de cada par�metro de una llamada SOAP RPC para que el motor SOAP pueda deserializar el par�metro. El atajo nos permite usar el elemento name del par�metro como el tipo de esquema y asociarlo a un tipo Java para mapearlo. Un ejemplo aclarar� esta soluci�n. Consideremos el siguiente SOAP envelope que representa una llamada RPC:
<SOAP:Envelope xmlns:SOAP="soap-uri">
<SOAP:Body SOAP:encodingStyle="soap-enc-uri">
<ns1:foo xmlns:ns1="ns1-uri">
<arg1>.. value of arg1 ..</arg1>
<x:arg2 xmlns:x="x-uri">.. value of arg2 ..</arg2>
</ns1:foo>
</SOAP:Body>
<SOAP:Envelope>
El problema es que Apache SOAP no podr� deserializar <arg1>...</arg1> y <x:arg2>...</x:arg2> a los objetos Java apropiados sin ayuda. Cuando no se encuentra un atributo xsi:type indicando el tipo de <arg1> o <x:arg2>, Apache SOAP usa el nombre del par�metro (arg1 o x:arg2, en este caso) con una URI de espacio de nombres "" para nombres no cualificados como el tipo. As�, el ejemplo de arriba, buscar� un deserializador para deserializar los tipos de esquema {""}arg1 y {"x-uri"}arg2 (donde el string dentro de los corchetes representa el URI del espacio de nombres del elemento). Todo lo que los usuarios necesitan hacer es decirle a Apache SOAP qu� deserializador usar para cada uno de estos tipos.
Los Serializadores para tipos se especifican mediante el descriptor de despliegue para el lado del servidor y llamando al API apropiado. Si queremos permitir que un servidor Apache SOAP reciba el envelope anterior, y que lo decodifique como hemos explicado, el descriptor de despliegue necesitar� tener los siguientes mapeos de tipos:
<isd:map encodingStyle="soap-enc-uri"
xmlns:z="" qname="z:arg"
xml2JavaClassName="name-of-deserializer-class"/>
<isd:map encodingStyle="soap-enc-uri"
xmlns:x="x-uri" qname="x:arg"
xml2JavaClassName="name-of-deserializer-class"/>
Si queremos permitir que un cliente Apache SOAP reciba el envelope anterior (en respuesta a alguna llamada) y lo decodifique seg�n los explicado, el lado del cliente necesitar�a hacer los siguiente:
SOAPMappingRegistry smr = new SOAPMappingRegistry ();
Deserializer sd1 = new appropriate-deserializer ();
smr.mapTypes (Constants.NS_URI_SOAP_ENC,
new QName ("", "arg1"), null, null, sd1);
Deserializer sd2 = new appropriate-deserializer ();
smr.mapTypes (Constants.NS_URI_SOAP_ENC,
new QName ("x-uri", "arg2"), null, null, sd2);
Aunque la aproximaci�n de Apache SOAP nos permite evitar el soporte de WSDL en muchos casos, hay casos donde a�n no es suficiente. Notablemente, si el nombre de un par�metro coindide con otro nombre dentro de ese par�metro o en cualquier otro lugar, no podemos usar el nombre como una clave para el tipo. Es decir, hay una asumpci�n impl�cita de que los nombres ser�n �nicos.
Observa que no se puede usar org.apache.soap.encoding.soapenc.BeanSerializer en ninguno de los de arriba. La raz�n es que el serializador de beans determina el tipo Java a producir consultando el tipo Java. En los registros anteriores el tipo Java se indic� como null para evitar que el registro de mapeo de tipos registre estre serializador como uno por defecto para tipos Java. As� los deserializadores indicados debe conocer (intr�nsecamente) el tipo del objeto Java que van a producir. Hay deserializadores para todos los tipos internos en el paquete org.apache.soap.encoding.soapenc para yudar a los usuarios a usar esta caracter�stica.
No entender cabeceras mustUnderstand.
Apache SOAP actualmente no implementa el concepto de cabecera mustUnderstand de SOAP. Esto provoca potenciales problemas de interoperabilidad ya que Apache SOAP podr�a ignorar cosas que no deber�a. El atajo que ofrece Apache SOAP es la habilidad de decirle al sistema de ejecuci�n, sobre un b�sico servicio, para servicios RPC solamente, si debe fallar o no si se ve una cabecera mustUnderstand. Esto est� disponible mediante un atributo en el descriptor de despliegue. El valor por de defecto del atributo checkMustUnderstands es false, lo que significa que no debe hacer ning�n chequeo en absoluto. Los buenos ciudadanos de servicios SOAP deber�an poner �ste a true para decirle al entorno de ejecuci�n que compruebe los atributos mustUnderstand de las cabeceras.
Acceder a cabeceras.
El proveedor RPC en Apache SOAP no proporciona acceso a ninguna cabecera en el SOAP envelope para la implementaci�n del servicio real. Si necesitamos acceder a ellas, el atajo es escribir nuestro propio proveedor que acceda a las cabeceras y luego procese el cuerpo (posiblemente delgando en otros proveedores).
Devolver par�metros.
SOAP RPC tambi�n tiene la noci�n de par�metros de retorno: respuestas que llevan m�s de un valor de retorno. El servicio por defecto RPC de Apache SOAP no proporciona soporte para dichos par�metros de retorno ya que se van m�s all� del �mbito de Java (que s�lo tiene un valor de retorno). De nuevo, el atajo aqu� es escribir un proveedor personalizado que permita a la implementaci�n del servicio no s�lo seleccionar un valor de retorno, sino devolver cualquier n�mero de valores de retorno.
�Probar la Interoperabilidad
Como se mencion� �ntes, el forum SOAP Builders est� liderando el cargo de las pruebas de interoperabilidad. Hay varias sites que est�n documentando varias partes de la red:
El ejemplo bidybuy de la versi�n Apache SOAP v2.2 es una implementaci�n de la prueba Bid Buy desarrollada por el forum SOAP Builders. Proprociona un ejemplo claro y comprensivo de implementaci�n de un servicio Web interoperable no trivial y un cliente del servicio.