Uno de los clientes de 3Metas tiene una base instalada muy importante de aplicaciones construidas en Visual Fox Pro 7, 8 y 9. Durante los últimos meses hemos trabajado en conjunto para desarrollar una estrategia de migración de estas aplicaciones hacia una arquitectura orientada a servicios (SOA) construida con WCF y el Framework 3.5 de .Net.

Uno de los aspectos claves de un proceso como estos consiste en evitar al máximo que se siga construyendo funcionalidad en Visual Fox Pro (VFP) así que el primer paso de la estrategia consiste en la integración de VFP con servicios de Windows Communication Foundation (WCF) de forma tal que las aplicaciones actuales se vean beneficiadas de las mejores en la lógica de negocios o de nuevas funcionalidades que se construyen con la última tecnología disponible.

1. Lo primero que debe hacerse es construir un servicio de WCF en lo que no profundizare especialmente.

2. En nuestro caso una vez que tuvimos construido el servicio construimos una fachada para su utilización desde VFP.

3. En esta fachada establecemos las referencias a los servicios por medio de la herramienta de Visual Studio, allí verificamos el tipo de conversión que se realizará sobre las colecciones genéricas. Como queremos proteger la inversión del cliente en este proyecto esta fachada deberá poderse usar desde VFP pero también desde aplicaciones desarrolladas con .Net hoy y en el futuro.

4. Creamos una clase que estará visibles por COM desde VFP y que será la fachada para esta herramienta.

5. Esta clase debe estar decorada como COM visible [ComVisible(true)] y para asegurar las opciones de Intellisense también agregamos la decoración de generación de la Interfaz [ClassInterface(ClassInterfaceType.AutoDual)]

6. Aunque visual Studio 2008 (VS2008) crea el constructor de forma predeterminada preferimos asegurarnos así que agregamos el constructor, tener presente aquí que el constructor no puede sobrecargarse ni recibir parámetros para evitar problemas en COM

7. Luego creamos los métodos que serán consumidos por VFP y se los decora como visibles para COM [ComVisible(true)].

8. En nuestro caso los métodos del servicio de WCF devuelven colecciones genéricas de tipos específicos, por ejemplo la colección de colores de la entidad color: [CollectionDataContract(Name = "Colores", Namespace ="http://myDomain.com/Data/2010/01")] public class Colores: Collection<ColorEntity> {}, para que estos métodos puedan ser consumidos desde VFP y teniendo en cuenta la restricción de COM para el manejo de genéricos se realiza una modificación al método para que no retorne la colección sino que retorno un arreglo de objetos que es algo que si puede ser manejado por VFP, la posibilidad de convertir la colección genérica en un arreglo se adiciono con LINQ, así que debe establecerse la referencia a LINQ en el proyecto y la clase, al final debe quedar algo como esto:

   1:  using System;

   2:  using System.Collections.Generic;

   3:  using System.Linq;

   4:  using System.Text;

   5:  using System.Runtime.InteropServices;

   6:  using ServicioProducto;

   7:  

   8:  namespace ServicesFacade

   9:  {

  10:  

  11:      [ComVisible(true)]

  12:      [ClassInterface(ClassInterfaceType.AutoDual)]

  13:      public class ProductoFacadeVFP

  14:      {

  15:          //default constructor

  16:          public ProductoFacadeVFP() {}

  17:  

  18:          /// <summary>    

  19:          /// Metodo trae los colores del Sistema

  20:          /// </summary>

  21:          /// <returns></returns>

  22:          [ComVisible(true)]

  23:          public Color[] GetColores()

  24:          {

  25:              Colores colores = null;

  26:  

  27:              try

  28:              {

  29:                  ServicioProductoClient srv = new ServicioProductoClient();

  30:                  colores = srv.GetColores();

  31:                  srv.Close();

  32:              }

  33:              catch (Exception ex)

  34:              {

  35:                  throw ex;

  36:              }

  37:  

  38:              return colores.ToArray();

  39:          }

  40:       }

  41:  }

9. Al compilar este proyecto se obtendrá una DLL y un archivo de configuración que corresponde a la forma como se establecerá la comunicación con el servicio (Address y Bindings), estos dos archivos son los que deben entregarse a los desarrolladores de VFP para que consuman los servicios.

Completada la fase de preparación y construcción de los servicios y su fachada los desarrolladores de VFP ya pueden integrar estos componentes en sus aplicaciones, para ello deben realizarse las siguientes actividades:

1. Registrar la Interfaz COM de la fachada de los servicios por medio del comando regasm, idealmente debería utilizarse el parámetro CODEBASE, la instrucción sería algo como esto si se corre desde el directorio del Framework 2.0 de .Net: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727>RegAsm.exe “C:\3Metas\Clients\Cliente\Proyecto\ServiceFacade\ ServicesFacade.dll” /CODEBASE

2. Uno de los aspectos más importantes de WCF es la separación de la configuración del servicio del código, el address y el binding del servicio que están definidos en el archivo de configuración, este archivo de configuración se generó al compilar la fachada. Para cada proyecto en el que va a utilizarse la fachada se debe copiar el archivo de configuración del servicio en la misma ruta del ejecutable de la aplicación de VFP o para depuración en la ruta donde reside el proyecto, este archivo debe renombrarse con el nombre de la aplicación de VFP y la extensión .config, en nuestro caso queda algo como esto: aplicaciondelcliente.exe.config. Muchos de los errores que se pueden presentar al usar la fachada tienen que ver con el hecho de que la aplicación no encuentra el archivo de configuración.

3. Registrada la interfaz COM de la fachada y renombrado y ubicado correctamente el archivo de configuración del servicio ya está todo listo para que el desarrollador pueda utilizar los servicios desde VFP. Solo debe utilizar el método CREATEOBJECT con el nombre de la clase de la fachada. Por ejemplo:

   1:  LOCAL Colores

   2:  LOCAL MyColor as ServiceFacade.ServicioProducto.Color

   3:  LOCAL ProductoFacade as ServicesFacade.ProductoFacadeVFP

   4:  

   5:  ProductoFacade = CREATEOBJECT("ServicesFacade.ProductoFacadeVFP")

   6:  Colores = ProductoFacade.GetColores()

   7:  

   8:  OPEN DATABASE "C:\3Metas\Clients\Integration\sampledata" EXCLUSIVE

   9:  USE color IN 0 EXCLUSIVE ALIAS tblColor

  10:  ZAP

  11:  

  12:  FOR EACH Item IN Colores

  13:      INSERT INTO color (ColorId) VALUES (Item.ColorId)

  14:  ENDFOR

Listo, el equipo de desarrolladores de VFP está consumiendo servicios de WCF.

Aclaraciones importantes:

· Con Visual Fox Pro se pueden consumir servicios Web, así que si se exponen los servicios de WCF con un binding básico HTTP el servicio de WCF se ve exactamente igual que un servicio web y por tanto se consume sin problemas desde FoxPro, sin embargo desde la perspectiva técnica puede llegar a tener problemas con objetos de negocios que VFP no entienda o que el servicio de WCF este expuesto por otro binding lo que haría imposible consumirlo desde VFP nativo, en nuestro caso las aplicaciones no estaba construidas consumiendo servicios web y el cliente no quería invertir tiempo de los desarrolladores en que aprendieran a consumir servicios web desde VFP, de allí tenía sentido que ellos consumieran objetos COM que les son familiares.

Al crearse el proyecto de fachada podría configurarse por medio de VS2008 la conversión de las colecciones genéricas en arreglos (ARRAYS). Sin embargo, eso haría que la fachada perdiera tipos de datos que podrían ser utilizados por clientes de .Net

En 3Metas utilizamos las últimas tecnologías en desarrollo de software, por eso muchas de nuestras aplicaciones trabajan bajo la arquitectura de servicios (SOA).  Por esta razón en uno de nuestros clientes usamos servicios de Windows Communication Foundation para compartir datos entre diferentes plataformas y aplicaciones como por ejemplo Windows Mobile, Aplicaciones WPF, Aplicaciones Silverlight y ASP.NET.

Una de las tareas que debemos realizar después de crear estos servicios es la publicación de los mismos en un servidor web para que sean expuestos y utilizados por las diferentes aplicaciones. En este pequeño tutorial publico los servicios en un servidor web IIS 7 con Windows Server 2008.

1. Se crea un sitio web, se le asigna un puerto específico, en el caso de nuestro cliente,  es el puerto 81 el que utilizan los servicios  WCF. Sin embargo podemos escoger cualquier puerto y verificar que este puerto este abierto en el firewall si los servicios van a  estar expuestos a internet.

2. Se copian los archivos publicados de la solución de los servicios en una carpeta específica, que es la misma que se ha definido al momento de crear el sitio web en el IIS.

3. Nos aseguramos que el namespace  ServiceModel este activo y registrado en nuestro servidor IIS, para ello abrimos la consola de comandos en modo administrador y ejecutamos el siguiente comando: “%windir%\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModelReg.exe” -r –y

4. La ejecución de este comando nos muestra unos resultados como parece en la siguiente figura

5. Se revisan los Handler Mappings como se ve en la figura:

6. Doble clic sobre Handler Mapping, aparece la siguiente pantalla:

7. En esta pantalla revisar si existen las entradas para la definición de los *.svc, ya que en nuestro caso los Hosting de los servicios WCF son en IIS con ASP.NET.

8. Para crear estos handlers hacemos clic derecho sobre la lista, nos muestra el siguiente menú:

9. Seleccionamos la primera opción  Add Managed Handler que nos muestra la siguiente pantalla en la cual colocamos los datos a ingresar:

8. Los valores a colocar para Request path: *.svc, Type: System.ServiceModel.Activation.HttpHandler, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, Name: svc-Integrated. Las restricciones las dejamos por default. Este es el primer registro. Debemos colocar otros 2 registros.

9. Los valores a colocar para Request path: *.svc, Type: %SystemRoot%\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll, Name: svc-ISAPI-2.0. Las restricciones las dejamos por default. Este es el segundo registro.

10. Los valores a colocar para Request path: *.svc, Type: %SystemRoot%\Microsoft.NET\Framework64\v2.0.50727\aspnet_isapi.dll, Name: svc-ISAPI-2.0-64. Las restricciones las dejamos por default. Este es el tercer registro si es para un servidor de 64 bits.

11. Luego verificamos si nuestros servicios quedaron funcionando de manera correcta, en la pantalla siguiente:

12. Seleccionamos un servicio, como el que se muestra en la figura, clic derecho y en el menú que aparece le damos Browse, lo cual nos abre una ventana del explorador de internet para verificar si nuestro servicio está funcionando de manera correcta.

13. El explorador de internet nos debe mostrar una pantalla como la siguiente: indicando que el servicio está funcionando correctamente.

14. El siguiente paso es corregir en el web.config del sitio ASP.NET que hostea u hospeda  los servicios WCF, las cadenas de conexión a las bases de datos que utilizamos para que nuestros servicios puedan funcionar de manera correcta.

En nuestro caso verificamos la sección ConnectionStrings del web.config y colocamos los valores correctos:       <connectionStrings>

<add name=”XXXXXNETDB” connectionString=”Data Source=YYYYY;Initial Catalog=MiBaseDatos;User;Password=3Metas; Timeout=999999″ providerName=”System.Data.SqlClient” />

<add name=”XXXXXNETDBII” connectionString=”Data Source=YYYYY;Initial Catalog=MiOtraDB;User;Password=3Metas; Timeout=999999″ providerName=”System.Data.SqlClient” />

<add name=”ZZZZDB” connectionString=”Data Source=YYYYY;Initial Catalog=JJJJJJ;User;Password=3Metas; Timeout=999999″ providerName=”System.Data.SqlClient” />

</connectionStrings>

15. El siguiente paso es ir a la solución que consume los servicios que estamos exponiendo en el IIS en nuestra solución ASP.NET a través de los archivos *.svc  y colocar la dirección correcta de cada uno de los servicios en el app.config si es una aplicación  Windows, o en el web.config si es una aplicación web.

Verificamos y cambiamos el endpoint de los Servicios WCF que estemos exponiendo en nuestra aplicación :

<endpoint address=”http://servidor:81/ServicioRendimientos.svc”

binding=”wsHttpBinding” bindingConfiguration=”WSHttpBinding_IServicioRendimientos”

contract=”ServicioRendimientosClient.IServicioRendimientos”

name=”WSHttpBinding_IServicioRendimientos”>

<identity>

<dns value=”localhost” />

</identity>

</endpoint>

16. Como podemos observar en el tag address=http://servidor:81/ServicioRendimientos.svc, hemos cambiado a servidor:81 que es el nombre del servidor y el puerto por donde definimos en el sitio que se va a exponer los servicios WCF.

17. Probar nuestra aplicación que consume los servicios para comprobar que todo esté funcionando como debe ser.

Bueno eso es todo por ahora, espero haber podido ayudarles en este proceso de instalación de los servicios WCF en un servidor IIS.

En 3Metas hemos trabajado mucho los últimos meses en el desarrollo de aplicaciones para dispositivos móviles que corren Windows Mobile. Recientemente actualizamos nuestras máquinas de desarrollo a Windows7 y hemos encontrado un problema cuando se consumen servicios de WCF.

Como sabrán para consumir un servicio WCF desde un dispositivo móvil usando el compact framework hay que crear una clase proxy utilizando la utilidad NetCFSvcUtil.exe que hace parte del conjunto power toys del compact framework 3.5 de .net.

El problema es que cuando se utiliza esta utilidad en Windows 7 siempre se produce un error como este:

Attempting to download metadata from ‘http://localhost/DinnerNow/service/DeliveryService.svc’ using WS-Metadata Exchange or DISCO.
Error: An error occurred in the tool.

Error: Error in the application.

Hay una incompatibilidad entre el tool de generación de la  clase proxy y Windows7, afortunadamente ya fue resuelto y puede obtenerse una actualización del tool desde este enlace. O se puede generar el archivo proxy en Vista o XP y pasarlo al proyecto en Windows7.