VB6 también lo dice en SOAP

 Créase  o no, VB6 sigue suelto en más lugares de los que aparentan. Recientemente conocí el caso de una telco colombiana que tiene tanto su front-end como su middleware en la vieja plataforma Windows: VB6 en el cliente, Windows DNA en el lado servidor

Acá es donde la política se mezcla con la tecnología. Y la verdad es que no se puede ser 100% una cosa o la otra: hay que tener cintura. Simplemente. La telco está decidida a ir a .NET pero no da, sea el presupuesto, sea el tiempo o sea el recurso que sea, para reconstruir todo junto a un mismo tiempo. Lo cierto es que se proyecta reescribir el lado servidor en .NET, en tanto que el lado cliente quedará de momento en Visual Basic 6

Entonces la pregunta es: cómo comunicamos cliente y servidor? Sin ser yo un experto en VB6, y mucho menos experto en interoperabilidad entre VB6 y VB.NET, quiero compartir lo que gentilmente me explicaron los que sí conocen

A grandes rasgos hay dos mecanismos basados en servicios web. Uno usa una pieza tardía que se habilitó a VB6: el SOAP Toolkit, que llegó a su versión 3. El otro mecanismo se basa en el lado cliente VB6 delegando a un .NET local la tarea de proxear el servicio web

Alternativa 1: proxeando con SOAP Toolkit
Paso 0: Crear los COM. El mecanismo que acá se describe está tomado de un paper público MSDN, el cual en verdad considera que se parte de una parte servidora en VB6 que expone componentes COM vía SOAP Toolkit. Como ese no es el caso de esta compañía (que hasta hoy accede a esos componentes COM pero por los mecanismos distribuidos naturales de la arquitectura Windows DNA, previos a los servicios web) quizás deban crear componentes COM vacíos de contenido, tan sólo para declarar la firma de los métodos a exponer como métodos web (web methods)


Figura 1 – el cliente usa SOAP Toolkit para invocar los métodos web expuestos en un servidor ASP.NET

Paso 1: De los COM a los WSDL. Entonces, con la .dll de los componentes COM vacíos ya generada, hay que usar una herramienta que el SOAP Toolkit facilita: se trata del generador WSDL. Para más detalles de cómo aplicarlo, se recomienda leer la sección "Using the WSDL/WSML Generator" en la ayuda del SOAP Toolkit. Así, podremos crear los archivos de descripción WSDL de cada servicio web a exponer

Paso 2: De los WSDL a los servicios web VB.NET. Con cada uno de estos archivos de descripción, siguiendo la recomendación del paper, va a servir para generar la cáscara o el esqueleto de la clase VB.NET que extenderá de System.Web.Services.WebService. Para ello hay que usar el comando WSDL.EXE con un formato similar a

WSDL /server /l:vb /out:<nombre componente>.vb <archivo de descripciones>.wsdl

Paso 3: Implementar los servicios web VB.NET. Siempre según el paper antes mencionado, se sugiere quitar de la clase generada el modificador MustInherit de la declaración de la clase, así como también el modificador MustOverride de cada método web a publicar. Entonces hay que implementar cada método y publicar el proyecto

Paso 4: Invocar desde un cliente VB6 al servicio web .NET. Cada puesto cliente debe tener instalado el redistribuible del SOAP Toolkit (SOAP Toolkit Redistributable). El proxy para invocar al servicio web está implementado en la clase MSSOAP.SoapClient30. La forma de invocar es realmente simple y está sobradamente documentada en la ayuda

Según testigos, ya que yo no lo probé, funciona. Lo que sí, usa un protocolo basado en SOAP RPC, no en documentos SOAP como lo establece el perfil básico WS-I. Además, la versión de SOAP usada era la vigente al momento de generar el SOAP Toolkit, no la 1.2 actual. Pero funciona

Alternativa 2: proxeando con .NET en el cliente
Esta alternativa se basa en el concepto de VB Fusion. VB Fusion hace referencia a la posibilidad de extender aplicaciones VB6 con VB.NET. Los detalles de cómo lograrlo están explicados en el libro gratuito "COM and .NET Interoperability", o también en el artículo "Exposing .NET Components to COM". Por todo esto no me voy a extender yo acá. Sí quiero aconsejar un artículo más, dado las diversas alternativas para lidiar con VB6 y VB.NET, que comenta las buenas prácticas

En términos generales, esta alternativa aprovecha los proxies que Visual Studio 2005 genera automáticamente, y los wrappea (adapta) a componentes COM a través de la facilidad COM Interop que la plataforma .NET previó

Esta alternativa presenta una ventaja respecto de la anterior: privilegia la calidad de la comunicación SOAP ya que aplica la última versión de este estándar (según el comité WS-I), implementada en la plataforma .NET. La contra que debemos admitir es que obliga a instalar la plataforma .NET en cada escritorio cliente. No obstante, este es un costo de única vez. Además, la alternativa anterior no requería la plataforma .NET pero sí el redistribuible del SOAP Toolkit.

Como sea, ahora les dejo la palabra a aquellos que hayan probado una o ambas alternativas (o que simplemente tengan ganas de aportar sus opiniones) a que me postéen sus comentarios

Esta entrada fue publicada en Software Architecture. Guarda el enlace permanente.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s