La interoperabilidad es una de las principales promesas de los Servicios Web. Los servicios web est�n dise�ados para ser independientes del sistema operativo subyacente y del lenguaje de programaci�n. En esta p�gina veremos los problemas b�sicos de interoperabilidad de los Servicios Web. Nos enfocaremos en las dos plataformas m�s populares - Java y Microsoft .NET.
�Introducci�n
La interoperabilidad de los Servicios Web se puede dividir en dos categor�as b�sicas: interoperabilidad SOAP e interoperabilidad WSDL.
En las p�ginas anteriores aprendimos que SOAP es un protocolo de muy alto nivel que obliga la estructura de los documentos XML intercambiados sobre alg�n protocolo de transporte. Esta es una definici�n bastante vaga. La vaguedad de esta definici�n hace que SOAP sea extremadamente extensible y versatil, pero tambi�n hace que la interoperabilidad sea todo un desaf�o. A un nivel b�sico, empezamos nuestra cuesti�n para conseguir la interoperabilidd al nivel del protocolo de transporte. Las dos partes implicadas en un intercambio de mensajes deben ponerse de acuerdo para utilizar el mismo protocolo de transporte, como HTTP, SMTP, o JMS. Pero la compatibilidad con el protocolo de transporte no garantiza necesariamente la interoperabilidad. Hay otros problemas que afectan a la interoperabilidad. Un ejemplo es el tipo de codificaci�n de los datos. Un estilo de codificaci�n define c�mo se codifican program�ticamente en XML los tipos de datos. La especificaci�n SOAP no obliga a ning�n estilo de codificaci�n particular, y los desarrolladores son libres para usar el estilo de codificaci�n que quieran. En teor�a virtualmente hay infinidad de estilos de codificaci�n incompatibles entre si. Afortunadaente hay una convenci�n est�ndar. La secci�n 5 de la especificaci�n SOAP define un estilo de codificaci�n, y �ste se ha convertido 'de facto' en el estilo de codificaci�n est�ndar para SOAP. Esta codificaci�n proporciona o b�sico para los test autom�ticos de interoperabilidad SOAP que llevan a cabo peri�dicamente los principales vendedores de soluciones SOAP. Pudes ver los resultados de estos test en http://soap.systinet.net/interop/soap/index.html
Cada dia encontramos m�s que WSDL tiene mucho que ver con la interoperabilidad de los Servicios Web. WSDL es el lenguaje de descripci�n para los Servicios Web. Normalmente un documento WSDL lo generan autom�ticamente las herramientas del marco de trabajo de los Servicios Web (por ejemplo WSDCompiler de WASP) partiendo del c�digo escrito en un lenguaje de programaci�n particular. Los desarrolladores pueden utilizar el documento WSDL para generar proxys o esqueletos del lado cliente, que proporcionen el acceso conveniente a los Servicios Web. As� la clave para activar la interoperabilidad de los servicios web es la habilidad de uno de los marcos de trabajo de Servicios Web de consumir los documentos WSDL generado por otros marcos de trabajo. El esfuerzo para la interoperabilidad de WSDL acaba de despegar. Puedes ver m�s detalles (en Ingl�s) en http://soap.systinet.net/interop/wsdl/index.html.
Aunque todav�a quedan algunos problemas de interoperabilidad, los vendedores est�n progresando muy r�pidamente, y podemos esperar que muy pronto se cumpla la promesa de la interoperabilidad de los Servicios Web.
�C�mo no Verse Atrapado
Ahora veremos algunos trucos b�sicos sobre c�mo escribir Servicios Web interoperables usando los marcos de trabajo disponibles hoy en d�a. Estos trucos podr�an simplificar significativamente nuestra vida y la de otros desarrolladores que usen nuestros Servicios Web. Esperamos que algunos de estos trucos queden obsoletos muy pronto.
�Mantener Simples nuestros Tipos -- evitar Construcciones Avanzadas del Esquema XML.
El est�ndar de Esquema XML es muy complejo y dif�cil de implementar. Adem�s, el procesamiento del Esquema XML consume mucho tiempo, por eso muchos marcos de trabajo sacrifican el soporte del Esquema XML por razones de rendimiento. Algunas construcciones avanzadas del Esquema XML (como choice) son muy dif�ciles de expresan en un lenguaje de programaci�n, y muy pocos marcos de trabajo de Servicios Web la soportan. Por eso el factor clave en el �xito de la interoperabilidad de los Servicios Web es usar tipos de datos b�sicos, como tipos primitivos, arays, y estructuras. Como mejor pr�ctica, descomp�n los tipos complejos de tu interface en interfaces m�s simples y claros con tipos de datos b�sicos. Evita tambi�n el uso de t�cnicas espec�ficas (como pasar par�metros INOUT) que no est�n ampliamente soportadas.
�Proporcionar Definiciones del Esquema XML para todos nuestos Tipos de Datos
Un problema muy com�n en los marcos de trabajo de hoy en d�a es su limitada habilidad para importar varios Esquemas XML y documentos WSDL. Siempre es buena idea proporcionar un esquema XML completo y las definiciones WSDL en un s�lo fichero WSDL en vez de importarlos de distintas localizaciones. Especificamente el marco de trabajo Microsoft .NET es sensible a las funciones de importaci�n de Esquemas XML.
Ejemplo:
Cuando encontramos que necesitamos incluir varios ficheros WSDL y ficheros de Esquemas XML en un servicio .NET, encontraremos que es m�s f�cil pasar las definiciones de esquemas XML junto con la definici�n WSDL al compilador de l�nea de comandos MS .NET WSDL en vez de intentar importar los esquemas dentro del fichero WSDL:
wsdl.exe /language:CS /protocol:SOAP MyService.wsdl MySchema.xsd JavaCollections.xsd
�M�ltiples Uniones WSDL
Algunos marcos de trabajo (por ejemplo, MS .NET) generan m�ltiples uniones WSDL que nos permiten acceder al Servicio Web a trav�s de varios protocolos (por ejemplo, HTTP GET, HTTP POST, y SOAP). El marco de trabajo del lado del cliente necesita conocer la uni�n a utilizar, por eso necesitamos especificar m�s par�metros (normalmente el nombre totalmente cualificado del servicio y el nombre del puerto WSDL) cuando se generan las uniones del lenguaje de programaci�n a partir del documento WSDL.
Ejemplo:
M�s adelante ejecutaremos el cliente Java com.systinet.demos.weather.WeatherClient para acceder al
MS .NET weather service que est� disponible en la site XMethods. Observa que este cliente debe usar un m�todo de b�squeda ligeramente diferente para especificar un nombre de servicio totalmente cualificado (como javax.wsdl.QName) y un n�mero de puerto WSDL:
lookup("http://www.vbws.com/services/weatherretriever.asmx?WSDL",
new javax.wsdl.QName("http://tempuri.org/",
"WeatherRetriever"), "WeatherRetrieverSoap", WeatherRetrieverSoap.class)
�Estilo de Documento por Defecto con Codificaci�n Literal
Algunos marcos de trabajo de Servicios Web, incluido MS .NET, generan, por defecto, un estilo de documento de servicio wrb, usando codificaci�n litegal. Aunque el Servicio Web utiliza documento/literal, el marco de trabajo .NET hace que el servicio aparente ser del estilo RPC para los clientes .NET. Esto no es necesario para otros marcos de trabajo, y muchos usuarios podr�an encontrar d�ficil acceder al Servicio Web usando un cliente al estilo RPC. Por eso si estamos escribiendo un Servicio Web RPC, debemos forzar para generar el RPC al estilo WSDL.
Ejemplo:
Usamos la directiva [SoapRpcService] en nuestras implementaciones del Servicio Web RPC en MS .NET:
<%@ WebService Language="C#" Class="MSNetStockService" %>
using System.Web.Services;
using System.Web.Services.Protocols;
using System.Web.Services.Description;
[SoapRpcService]
public class MSNetStockService {
[WebMethod]
public double getQuote(string symbol) {
if(symbol == "SUNW") {
return 10;
}
if(symbol == "BEAS") {
return 11;
}
if(symbol == "MSFT") {
return 50;
}
return 0;
}
}
�Uso �nico de SOAPActions para nuestros m�todos
Si empezamos el desarrollo de nuestro Servicio Web con una definici�n de documento WSDL, debemos considerar la utilizaci�n de atributos �nicos SOAPAction para todos nuestros m�todos en la uni�n WSDL. Algunos marcos de trabajo tratan con SOAPAction cuando enrutan mensajes SOAP a los m�todos de implementaci�n del Servicio Web.
Ejemplo:
Consideremos el siguiente fragmento de uni�n WSDL del Servicio Web MS .NET mencionado anteriormente:
<binding name="MSNetStockServiceSoap" type="tns:MSNetStockServiceSoap">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="rpc" />
<operation name="getQuote">
<soap:operation soapAction="http://tempuri.org/getQuote" style="rpc" />
<input>
<soap:body use="encoded" namespace="http://tempuri.org/"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" />
</input>
<output>
<soap:body use="encoded" namespace="http://tempuri.org/"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" />
</output>
</operation>
</binding>
�C�digos de Ejemplo
Ahora veremos unos cuantos ejemplo de interoperabilidad de Servicios Web. Usaremos una simple aplicaci�n bancaria que es capaz de seguir la pista de los clientes, las cuentas y los balances. Tambi�n usaremos el servicio metere�logico de MS .NET que se lista en la site XMethods como un ejemplo del mundo real de acceso a los Servicios Web, por eso necesitaremos estar conectados a Internet mientras ejecutamos esta demo:
NOTA:
Necesitar�s descargar el 
c�digo fuente. Asumimos que has
desempaquetado este archivo en el directorio c:\wasp_demo. Podr�s encontrar todo el c�digo fuente de los ejemplos en el subdirectorio src de ese directorio.
�Acceder a un Servicio MS .NET desde Java
Empezaremos con un ejemplo de cliente Java/servicio .NET. Como mencionamos anteriormente, accederemos al servicio metere�logico de MS .NET. Pulsa sobre el enlace y prueba el servicio on-line usando el marco de trabajo MS .NET. Luego �chale un vistazo al documento WSDL de este servicio. Observar�s que define tres uniones (WeatherRetrieverSoap, WeatherRetrieverHttpGet, y WeatherRetrieverHttpPost).
Ahora crearemos un cliente Java para este servicio. Ejecuta el script run_weather_client.bat situado en el directorio bin del directorio de ejemplo. Por favor, observa que estamos usando un m�todo lookup que especifica el nombre del servicio totalmente cualificado y el n�mero del puerto WSDL. Este m�todo nos permite especificar que queremos usar la uni�n SOAP.
lookup("http://www.vbws.com/services/weatherretriever.asmx?WSDL",
new javax.wsdl.QName("http://tempuri.org/",
"WeatherRetriever"), "WeatherRetrieverSoap", WeatherRetrieverSoap.class)
�Llamar a un Servicio Java desde un Cliente MS .NET
El escenario opuesto es bastante sencillo. Primero arrancamos el entorno de ejecuci�n del Servicio Web con el comando startserver.bat, y luego compilamos y desplegamos nuestro Servicio Web bancario llamando al comando deploy.bat. Ahora ya estamos listos para mostrar tres clientes MS SOAP diferentes accediendo a nuestro servicio.
NOTA:
Necesitar�s una versi�n 6.0 o superior de MS IE para ejecutar esta demo.
Primero ejecutaremos un cliente MS JavaScript SOAP. LLamamos al script run_web_client.bat. Especificamos un n�mero de la Seguridad Social (podemos usar 001-0001-01, 002-0002-02 o 003-0003-03), y pulsamos el bot�n Get Accounts, lo que rellenar� el combobox de cuentas. Elgimos una cuenta y recuperamos su balance pulsando el bot�n Get Balance. Puedes ver m�s detalles si miras el c�digo fuente JavaScript que puedes encontrar en el fichero src\msjsclient.html.
NOTA:
Necesitar�s descargar e instalar el MS SOAP Toolkit 2.0 para poder completar el siguiente ejemplo. Tambi�n necesitar�s tener MS Excel en tu ordenador.
Ahora veamos la misma funcionalidad accediendo desde Microsoft Excel (usando Visual Basic). Abre la hoja Excel src\Bank.xls y usa los mismos pasos descritos en el ejemplo anterior para navegar por la aplicaci�n. Puedes encontrar el c�digo del cliente SOAP en el editor de Visual Basic (Tools->Macro->Visual Basic Editor) en el m�dulo de la Sheet1.
NOTA:
Necesitar�s descargar e instalar el MS .NET Framework SDK para ejecutar la parte C# de este ejemplo.
El �ltimo ejemplo demuestra como acceder a nuestro Servicio Web Java desde un cliente C#. Ejecuta el script run_csharp.bat para generar un proxy est�tico C# desde el servicio WSDL y compila y ejecuta la aplicaci�n cliente. Este ejemplo va un paso m�s all� en que pasa una estructura Transfer desde C# a Java. Los ejemplos anteriores s�lo pasaban tipos de datos simples. Observa la definici�n de esquema XML del tipo Transfer (incluye el elemento Balance):
<xsd:schema targetNamespace="http://idoox.com/wasp/tools/java2wsdl/output/com/systinet/demos/bank/">
<xsd:complexType name="Transfer">
<xsd:sequence>
<xsd:element name="type" type="xsd:string"/>
<xsd:element name="accountNumberBeneficiary" type="xsd:string"/>
<xsd:element name="comment" type="xsd:string"/>
<xsd:element name="balance" type="ns0:Balance"/>
<xsd:element name="amount" type="xsd:double"/>
<xsd:element name="timestamp" type="xsd:dateTime"/>
<xsd:element name="accountNumber" type="xsd:string"/>
<xsd:element name="transferID" type="xsd:long"/>
<xsd:element name="commentBeneficiary" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="Balance">
<xsd:sequence>
<xsd:element name="changed" type="xsd:dateTime"/>
<xsd:element name="transfer" type="ns0:Transfer"/>
<xsd:element name="comment" type="xsd:string"/>
<xsd:element name="balance" type="xsd:double"/>
<xsd:element name="accountNumber" type="xsd:string"/>
<xsd:element name="transferID" type="xsd:long"/>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
El compilador WSDL de .NET generar� las estructuras adecuadas en C#. Puedes ver el esqueleto en el fichero src/ms/JavaService.cs. Ejecuta el cliente Java llamando al script run_java_client.bat, y observar�s que hace exactamente lo mismo.
NOTA:
Ambos clientes comparten el mismo Servicio Web, y ambos clientes hacen reintegros de la misma cuenta. Por eso
si ejecutas la demo varias veces te ver�s sin fondos. Y obtendr�s una TransferProcessingException que dice algo as� como 'Fondos insuficientes". Una cosa interesante que podr�as observar es que C# es capaz de pasar de forma transparente la excepci�n en el lado del cliente con el mismo mesnaje. Reinicia el entorno de ejecuci�n de Servicios Web, usando el script startserver.bat para renovar tus fondos.