Interoperabilidad con Otras Implementaciones SOAP
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.
Tutoriales
