En las tres anteriores entregas de esta serie sobre SOAP con herramientas clásicas hemos visto cómo crear y consumir servicios Web con Visual Basic y código de Script. Consulta el histórico del Blog para leer estos artículos.
Los componentes que hemos creado y consumido hasta ahora eran objetos sin estado. Esto es, si disponemos de una DLL escrita en VB que contiene una clase que debe mantener información entre llamadas no funcionará correctamente ya que cada llamada realziada a través de SOAP es independiente de las demás y se realiza sobre un objeto diferente en el servidor.
Por ejemplo, consideremos la siguiente clase 'PruebaSOAP2.Persona' que dispone de dos métodos: uno para anotar e nombre de una persona y el otro para saludarla:
Private mNombre As String
Public Sub AnotaNombre(sNombre As String)
mNombre = sNombre
End Sub
Public Function DimeNombre() As String
DimeNombre = mNombre
End Function
El método 'AnotaNombre' de esta clase almacena la cadena que se le pase como parámetro en una variable privada de la clase. el método 'DimeNombre', port el contrario, la recupera. Es obvio que para que esta clase funcione como es debido se debe poder realziar llamadas sucesivas sobre una misma instancia de ésta o el estado interno de la variable 'mNombre' se perdería.
Vamos a probar a consumirla mediante SOAP directamente. Compile la clase y expógala como unobjeto SOAP tal y como hemos aprendido. Ahora intente ejecutar este código:
Dim o
Set o = GetObject("soap:wsdl=http://dilbert/personaws/PruebaSOAP2.Persona.soap?WSDL")
o.AnotaNombre "Jose" MsgBox o.DimeNombre
En el mensaje final debería aparecer la palabra "Jose". Sin embargo vemos que en realidad se muestra en blanco. Ello se debe a lo que comentaba antes: cada llamada al servicio Web es atendida por un objeto diferente y nuevo en el servidor. Está claro que esto limita bastante la capacidad de reutilizar como servicios Web algunos componentes con estado heredados.
Por suerte, como casi todo, esto también tiene solución. Y para colmo es casi igual de fácil que todo lo visto hasta ahora.
Lo primero que debemos hacer es exportar nuestra aplicación COM+ desde la consola de administración de servicios de componentes. en el diálogo que aparece seleccione la opción 'Proxy de aplicación' y escoja una ruta en la que crear un paquete de instalación MSI.
Pulse para aumentar
Ahora dispone de un paquete de instalación que podrá instalar en cualquier equipo con Windows XP o Windows 2003 Server. Hágalo. Tenga en cuenta que para poder probarlo deberá instalar el proxy en otro equipo diferente al que contiene el servicio Web. Una vez instalado en otro equipo podrá comenzar a utilizar el objeto con el siguiente código:
Dim o
Set o = WScript.CreateObject("PruebaSOAP2.Persona")
o.AnotaNombre "Jose"
MsgBox o.DimeNombre
Este código funcionará ahora perfectamente, devolviendo en el cuadro de diálogo el valor del nombre fijado en la llamada anterior, es decir, manteniendo el estado entre llamados.
"¡Eh!, ¡un momento!, pero ¿qué es esto?. ¡No estoy utilizando SOAP!". Tranquilo, todo tiene una explicación. En realidad sí está utilizando SOAP y las llamadas se están realizando a través de HTTP al servidor en el que está instalando el componente original. La diferencia respecto a lo que hemos visto hasta ahora es que estamos utilizando un Proxy .NET Remoting generado de forma automática por COM+ durante la exportación y expuesto como un objeto COM regular durante la importación. Es éste el que nos aisla de las complejidades de SOAP y nos permite utilizar el servicio Web remoto como si fuese un componente local. Como ya me he acostumbrado a decir durante toda esta serie de artículos: ¡impresionante!.
En la carpeta 'C:\WINDOWS\system32\Com\SOAPAssembly' del sistema cliente podemos encontrar el archivo '.config' que controla el funcionamiento del proxy. Podemos modificarlo o añadirle nuevos nodos sin problema para modificar el comportamiento del Proxy.
Con este artículo termino la serie comenzada hace unos días sobre servicios Web con herramientas tradicionales que creo que le resultará interesante a todo el mundo. Lo cierto es que apenas hay información disponible sobre estos temas y creo que ha resultado intersante mostrar aquí los resultados de mis investigaciones al respecto.
las posibilidades de estas técnicas son casi ilimitadas para muchos escenarios de soporte e integración de código heredado, accesibilidad de componentes a través de redes de comunicaciones sin preocuparnos de cortafuegos, etc, etc..
¡Qué lo disfrutes!
💪🏻 ¿Este post te ha ayudado?, ¿has aprendido algo nuevo?
Pues NO te pido que me invites a un café... Te pido algo más fácil y mucho mejor
