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.
Juan Peláez
CTO
3Metas Corp.
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
Referencias:
http://www.dotnet247.com/247reference/msgs/15/75021.aspx
http://www.west-wind.com/presentations/VfpDotNetInterop/DotNetFromVFP.asp
http://www.west-wind.com/presentations/dotnetfromVfp/DotNetFromVfp_ComplexObjects.asp
http://blogs.msdn.com/calvin_hsia/archive/2005/09/02/460206.aspx
Publicidad
Migrando aplicaciones de visual fox pro a .net? tratando de establecer una politica o un proceso de desarrollo para sus aplicaciones legacy? contactenos a sales@3metas.com, nuestro equipo tiene la experiencia y las habilidades necesarias para tener resultados exitosos.