Interoperabilidad de los Servicios Web
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.
Tutoriales
