Extrategia de Acceso a datos usando FOXISAPI

Por Ramón Seoane

 

Cada vez hay más demanda de aplicaciones que usan la tecnología de Internet para conectarse a bases de datos remotas. Entre las herramientas que pueden proveer una extraordinaria versatilidad y velocidad a la hora de desarrollar aplicaciones ‘activas’, se encuentra Visual Foxpro y una serie de utilidades que se describen en este documento. Explosión del fenómeno Internet

Actualmente el tráfico en la red está creciendo de forma , que Internet está siendo integrado en las estrategias de negocio de todas las empresas. Como consecuencia de esto, hay una gran demanda de desarrolladores que puedan dotar a los sitios web de la dinámica que exige un mundo donde la información es tan cambiante.

Demanda de aplicaciones de bases de datos activas

Las aplicaciones de bases de datos son la llave para construir aplicaciones activas en Internet. Hasta hace poco las páginas HTML sólo mostraban contenido estático que sólo podía ser cambiado mediante editores y cuyo mantenimiento era muy costoso. Pero hoy en día, con las nuevas tecnologías de acceso a datos, el usuario desde su browser puede solicitar la información que precisa en cada momento.

Visual Foxpro está preparado para el cambio

Visual Foxpro está en disposición de ser ofrecido como una herramienta válida para el diseño de aplicaciones activas en Internet si tenemos en cuenta su característica RAD (Rapid Application Development), la velocidad de acceso a datos, la posibilidad de generar componentes OLE public, etc.

¿Por qué construir aplicaciones Web?

De todos es sabido que Internet está presente en todos los aspectos de la Informática hoy en día. Los desarrolladores de Software y vendedores de herramientas, están enfocando sus próximas plataformas de desarrollo sobre el Web. Veamos que ventajas tiene el desarrollo de tales aplicaciones:

Distribución amplia, administración centralizada

Como plataforma cliente/servidor, Internet provee dos características importantes:

  • ? Fácil acceso desde cualquier conexión de red. El uso de un protocolo estándar como es TCP/IP, universalmente utilizado y reconocido como medio de transporte de la información en Internet, supone una total accesibilidad desde cualquier punto del planeta que disponga de un software mínimo de conexión y navegación a unos costes reducidos.
  • ? Mantenimiento centralizado. Esta característica permite que cualquier cambio en la aplicación sea automáticamente visto por aquellos clientes que se conecten de nuevo. Lo único que se exige es una compatibilidad a nivel de explorador.

    Interfaz cliente universal

    La gran aceptación que ha tenido el uso de una única herramienta para el acceso a distintas fuentes de información, ha supuesto grandes cambios en el diseño del software para que éste se adapte a la nueva interfaz.

  • ? Clientes multiplataforma. El uso de un único software cliente que pueda romper los inconvenientes derivados de la variedad de sistemas operativos existentes, se puede ver amenazado por las guerras de hegemonía dentro de Internet, lo que nos llevaría de nuevo a la disgregación y a las incomodidades tanto para el desarrollador como para el cliente.
  • ? Sin necesidad de actualizaciones. Las aplicaciones ya no tienen que ser instaladas en la máquina cliente, sino que serán mantenidas en el servidor. Limitaciones de las aplicaciones Web

    Hemos comentado varias de las ventajas que tiene programar aplicaciones en la Web. Pero también es importante comprender las limitaciones que nos podemos encontrar cuando afrontemos el desarrollo de una aplicación de tales características.

    Detalles de configuración

    El desarrollo de aplicaciones Web requiere más recursos que una aplicación estándar, pues se trabaja con distintas entidades en vez de un entorno único. Por un lado, el servidor Web; por el otro, la aplicación cliente (backend); en el medio un conector que los comunique y todo ello programado utilizando distintos lenguajes de programación y de script.

    Limitaciones de interfaz de HTML

  • ? Clientes sin acceso a datos. El browser no tiene acceso directo a los datos, los cuales son mantenidos y accedidos por el servidor. El acceso a datos está basado en transacciones y cualquier actualización basada en datos recuperados del servidor, requerirá que el documento HTML que contiene lo
  • ? s datos sea cargado de nuevo.
  • ? Limitación de los scripts. Aunque Microsoft y Netscape proveen interfaces HTML mejoradas en sus browsers a través de JavaScrit y VBScript, el modelo de objetos implementado es muy limitado comparado con el de las típicas herramientas visuales.
  • ? Interfaz generada por el servidor. Cada vez que se requieran nuevos datos, la página HMTL deber ser cargada entera desde el servidor.
  • ? No hay facilidad de impresión. La única opción de imprimir lo que se está visualizando es utilizar la opción de impresión del browser. Cómo funciona el Web Activo

    En la figura 1 se muestra cómo la arquitectura Activa de Microsoft enlaza el cliente y el servidor

    El browser provee la parte visual de una aplicación Web. La interfaz consiste básicamente en texto HTML así como gráficos y formularios que pueden ser embebidos dentro de los documentos HTML. Toda la entrada de datos es manipulada a través de páginas formateadas HTML que son interpretadas y posteriormente visualizadas por el browser.

    Los lenguajes de script como VBScript y JavaScript pueden ser usados para aportar alguna lógica a la página HTML por medio del modelo de objetos/eventos que permite la manipulación de objetos así como responder a eventos. Mediante estos lenguajes podremos mejorar el aspecto de las páginas web al manipular los distintos controles ActiveX y Applets de Java usando el típico mecanismo de propiedades, eventos y métodos.

    En el otro lado de la conexión se encuentra el servidor Web, que es el responsable de servir las páginas con la información requerida. Tradicionalmente dichas páginas eran simples ficheros de texto .html que contenían referencias a ficheros gráficos que también se descargaban desde el servidor. Pero el papel del servidor ha cambiado y se le asignan nuevas tareas, como la de permitir la interacción con aplicaciones ‘backend’ vía interfaz ISAPI.

    El funcionamiento básico consistiría en llamar al ISAPI o CGI (Common Gateway Interface) desde el servidor para procesar la consulta y obtener como resultado código HTML. El Internet Server API (ISAPI) es una API basada en Windows que permite a las extensiones ejecutarse en el espacio de direcciones del servidor Web, lo que las hace más rápidas. Las extensiones ISAPI pueden generar la salida requerida por sí mismas o bien servir de conexión con otras aplicaciones que se encarguen de procesar la información por ellas.

    Hay que tener en cuenta que tanto ISAPI como CGI son interfaces y no requieren ser implementadas en un lenguaje determinado. ISAPI puede ser implementada por cualquier lenguaje que pueda crear DLL’s Win32. Para CGI, valdría cualquier lenguaje que soportara la creación de EXE’s que pudieran leer y escribir de y hacia la entrada y salida estándar. En las siguientes figuras podemos ver esquematizado el funcionamiento de ambos modelos.

    Es importante recordar que Visual FoxPro nunca se ejecuta como una aplicación ISAPI directamente, más bien existe una interacción entre ellos a través de un mecanismo de envío de mensajes (OLE Automation, DDE, etc.). Es el caso de FoxISAPI y Web Connection. En la figura 4 se muestra cómo ISAPI es la base de la mayor parte de extensiones de servidor creadas por Microsoft.. FoxISAPI y Web Connection también son implementados usando ISAPI como interfaz de conexión.

    Qué se necesita para comenzar

    A continuación se muestra una lista de hardware y software que se recomienda para montar una aplicación Web.

  • ? Pentium 133 (32-64 megas) o superior. Esta es una configuración aceptable para comenzar, aunque pudiera ser menor si el número de accesos que se espera recibir es menor de mil al día. En casos de mayor tráfico, se recomienda la opción multiprocesador y al menos 128 megas de memoria.
  • ? Windows NT Server Se trata de una plataforma idónea para actuar como servidor de aplicaciones. Al igual que antes, en caso de esperar poco tráfico, Windows 95 con el Personal Web Server sería una opción válida. Junto con el NT Server se incluye:
  • ? Protocolo TCP/IP. Es necesario tener instalado este protocolo en la máquina que tenga el servidor montado.
  • ? Servidor Web (IIS). Con la versión 4.0 de NT viene el IIS 2.0, aunque se podrían utilizar otros servidores como Commerce Builder de Internet Factory, Website de O’Reilliy, Purveyor de Process Software, etc. Estos servidores soportan ISAPI, por lo que FoxISAPI podría ser empleado en todos ellos. No ocurre lo mismo con Internet Database Connector y Active Server Page, que sólo son soportados por IIS.
  • ? Interfaz de conexión. También necesitamos una aplicación que conecte los datos generados por Visual FoxPro con el servidor Web. Las Active Server Pages usan una extensión ISAPI para interpretar los ficheros .ASP, mientras que FoxISAPI y WebConnection usan un conector DLL explícto que es llamado directamente desde un link HTML.
  • ? Browser Es necesario para probar que las páginas generadas se leen correctamente. Tanto el Explorer como el Netscape en cualquiera de sus versiones nos valdrían para empezar.
  • ? Editores HTML. Es importante disponer de un editor de páginas HTML que nos haga el trabajo de generar la parte estática. Entre los más conocidos están: Frontpage, PageMill, NetObject... Active Server Pages (Páginas de Servidor Activas)

    La nueva técnica de acceso a datos mediante páginas .ASP, se incluye en la última versión de Microsoft del IIS, que actualmente es la 3.0. Se trata de un mecanismo de scripts basado en objetos que permite la mezla de código y HTML en una página usando Visual Basic Script o JavaScript.

    ASP es una parte del IIS y se instala cuando se actualiza de la versión 2.0 a la 3.0. La integración con el servidor se realiza mediante una extensión ISAPI, y se encarga de interpretar aquellas páginas con extensión .ASP. Dicha extensión es capaz de manejar peticiones multi-thread y pooling de conexiones con ODBC para aumentar el rendimiento en el acceso a los datos.

    La arquitectura de servidor activo está basada en componentes que interactúan entre si. La figura 5 muestra los componentes base incluidos en el Active Server que se describen a continuación:

  • ? Objeto Request. Suministra información acerca de la petición actual al Web. Devuelve información sobre las variables capturadas en un formulario HTML, información del servidor y su estado, además de acceder a la cabecera HTTP para obtener información de autentificación y cookies.
  • ? Objeto Response. Así como el objeto Request provee información acerca de las entradas desde el Web Server, el objeto Response es el responsable de crear la salida que se envía al servidor. Las páginas ASP interpretan código HTML común, pero además el objeto Response es capaz de generar código de salida bajo control de código. El método Response.Write permite escribir directamente en la salida.
  • ? Objeto Session/Application. Este par de objetos provee un mecanismo para mantener el estado entre peticiones. El primero gestiona cada sesión de usuario mientras dura la visita, y es implementado vía HTTP cookies. El segundo es parecido al session, pero dura mientras exista la aplicación- un directorio raíz virtual del servidor Web.
  • ? Conectividad a Bases de Datos con Active Data Object (ADO). Este componente basado en OLE, es una interfaz que provee un gran rendimiento en el acceso a datos , e implementa un mecanismo de acceso a la información a través de OLE DB y ODBC.

    PROS:

  • ? Integración total con IIS. Esto supone un mejor rendimiento y gestión en el acceso a datos.
  • ? Un único entorno de desarrollo. Debido a que el código y HTML residen en el mismo documento, la instalación y el manejo de las herramientas es más simple.
  • ? Facilidad en el caso de contenido activo simple. ADO provee acceso rápido a datos con un modelo de objetos mínimo.
  • ? Extensible con objetos Automation.

    CONTRAS:

  • ? Mantenimiento del código. Construir lógica compleja dentro de páginas HTML puede ser una tarea tediosa, incluso usando herramientas como Visual Interdev.
  • ? Entorno de desarrollo limitado. Aunque se disponen de wizards y otras utilidades para generar código, no se disponen de mecanismos de depuración y gestión de errores.
  • ? Limitaciones de los lenguajes de Script. VBScript está muy limitado para construir aplicaciones que realicen accesos a API’s o funciones especiales de manejo de ficheros, etc., por lo que habría que recurrir a llamadas a objetos Automation, con el consiguiente incremento de recursos manejados.
  • ? Gestión de datos con ODBC. Debido a que ODBC mantiene las tablas abiertas y puede haber muchos accesos al servidor, sería difícil bloquear una tabla para realizar tareas de mantenimiento.

    FOXISAPI

  • La capacidad de Visual FoxPro de crear servidores OLE ha permitido implementar aplicaciones Web basadas en este lenguaje. Para ello es preciso contar con una DLL incluída en la versión 5.0 del producto: FoxISAPI.DLL, que se encarga de instanciar un servidor OLE construido en Visual FoxPro para que realice el tratamiento de los datos. FOXISAPI es referenciado desde un link o formulario HTML mediante una sentencia del tipo: HREF="/scripts/foxisapi.dll/Tserver.Tclass.Tmethod?UID=1111&Nombre=Ramon”

    Foxisapi.dll crea una referencia al objeto pasado como parte de la URL y llama al método especificado. Dicho objeto es persistente, por lo que los accesos siguientes serán más rápidos, a no ser que se especifique explícitamente que el servidor sea descargado.

    El ejemplo anterior puede ser probado desde VFP mediante las dos instrucciones siguientes:

    oServer=CREATEOBJECT(“Tserver.Tclass”)

    lcResult=oServer.Tmethod(cPar1,cPar2,nPar3)

    Foxisapi espera recibir código HTML de la llamada a ese método para así devolverlo al servidor Web.

    Parámetros suministrados por FoxISAPI

    Cuando FoxISAPI llama al servidor OLE, le pasa 3 parámetros por cada método que invoque. El método del servidor debe soportar estos tres parámetros. 1º lcFormVar: Contiene los parámetros especificados en la URL o cualquier variable de formulario HTML obtenida vía GET o POST. La cadena de parámetros contiene un par clave/valor por cada una de las variables de formulario pasada. En el caso anterior, las claves serían UID y Nombre, mientras los valores serían 1111 y Ramon. Este formato es conocido como URL encoded y sigue unas normas específicas:

  • ? Los pares están separados por &
  • ? Los espacios se convierten en +
  • ? Todos los caracteres ‘extendidos’ se convierten a códigos escape Hex. (ASC(13) sería %0D)

    2º lcIniFile: Contiene el path a un fichero INI que a su vez contiene todas las variables del sistema, browser y servidor. Se pueden recuperar con la función GetProfileString.

    3º LnReleaseFlag: Determina si la referencia al servidor OLE debe ser liberada o mantenida. Este parámetro es pasado por referencia, por lo que basta con asignarle un valor ‘0’ para que se mantenga la referencia o ‘1’ para que se libere.

    Valor a devolver

    Una vez que nuestro código toma el control, podemos usar VFP para realizar cualquier operación de manejo de datos. El resultado final debe ser una cadena de texto que sea compatible HTML.

    Instalación de los componentes

    Esta es una de las tareas más incómodas de todo el proceso, pues hay que manejar distintos componentes en función de las combinaciones de plataforma-servidor Web que tengamos.

  • ? Registro del Servidor OLE. Si estamos desarrollando el proyecto en el mismo ordenador que el servidor, sólo tenemos que compilarlo desde VFP. Si lo instalamos en otro ordenador tendremos que ejecutar desde el S.O.: MyServer.exe /regserver (para .EXE) o \winnt\system32\regsvr32.exe Myserver.dll (para .DLL)
  • ? Copia del FoxISAPI.dll al directorio de Scripts y habilitar permisos.
  • ? Ejecutar DCOMCNFG en NT 4.0 para habilitar permisos en la cuenta IUSR_machine

    Novedades de la nueva versión de FoxISAPI

    Pooling de múltiples servidores Visual FoxPro OLE custom .

    Con esto se mejora la escalabilidad de las aplicaciones. Esta nueva característica permite a un servidor custom servir una petición cuando otro servidor está ocupado. Para mejorar el rendimiento, las instancias de los servidores custom debieran ser hechas persistentes poniendo el parámetro que envía foxisapi.dll a 0 desde la aplicación.

    El número de servidores custom disponible para atender las peticiones viene determinado por los valores que se establezcan en el fichero de configuración foxisapi.ini. Simplemente se debe crear una nueva sección entre corchetes con el nombre del servidor, a la que sigue una lista de custom servers que pueden atender el mismo tipo de petición. Ejemplo: 

    [FOXWEB.MISERVIDOR]
FOXWEB.SERVER=3
FOXWEB2.SERVER=2
URL ?  HTTP://Servidor/Scripts/FOXISAPI.DLL/FOXWEB.MISERVIDOR.Delay?30

    Para servidores custom .DLL, tenemos la limitación de un único servidor por cada Visual FoxPro runtime, por lo que tendríamos que limitar el número de instancias a 1. Por otra parte, los servidores .EXE deben ser construidos para ser instanciados como single-use.

    Depuración de los servidores custom

    Ya es posible depurar los servidores custom simplemente poniendo 0 como número máximo de instancias a crear para dicho servidor en el foxisapi.ini. Es necesario copiar el fichero ODEBUG.PRG al directorio home() de VFP así como asegurarse de copiar los ficheros fuente del servidor custom al directorio apropiado. También hay que asegurarse de que el servidor esté configurado como ‘persistente’ y que tenga habilitada la opción: ‘debugging info’ en el proyecto.

    Cuando el servidor custom sea instanciado, FOXISAPI.DLL arrancará Visual FoxPro y estará disponible la opción de depuración.

    Comandos FOXISAPI

    FoxISAPI viene con una serie de comandos que nos permitirán determinar el estado de nuestros servidores custom.

  • Status: Muestra el estado actual de los servidores custom
  • Reset: Libera todas las instancias de los servidores.
  • SingleMode: Hace un reset y limita el número de instancias de los servidores a 1.
  • Multimode: Hace un reset y devuelve el número de instancias según foxisapi.ini

    PROS:

  • ? Facilidad de manejo de todo tipo de datos
  • ? Permite la manipulación de los datos antes de devolverlos
  • ? Construcción de páginas HTML con el formato deseado

    CONTRAS:

  • ? Consume más recursos
  • ? Instalación un poco compleja al principio.
  • ? Es necesario dominar dos lenguajes para generar la página

    West Wind Web Connection

    Web Connection es otra utilidad que permite tabajar con un número predefinido de objetos que simplifica el proceso de desarrollo de aplicaciones Web. Las aplicaciones se construyen en una clase que contiene los objetos necesarios para comunicarse con el servidor. Mediante el uso de los métodos predefinidos podemos construir páginas HTML de una forma sencilla.

    Web Connection tiene dos formas de implementar la interfaz, bien como ISAPI (wwcgi.dll) o como CGI (wwcgi.exe). La versión EXE es empleada por los servidores Web compatibles con WinCGI, mientras que la DLL es llamada por los servidores ISAPI. Veamos dos ejemplos de URL.

    http://servidor/cgi-win/wwcgi.exe?TestPage para WinCGI, o http://servidor/cgi-win/wwcgi.dll?TestPage para ISAPI. El servidor de datos Visual FoxPro se encarga de recibir las peticiones. Se trata de un programa realizado en VFP y puede funcionar como un .EXE independiente. La comunicación con wwcgi se realiza a través de ficheros en un directorio previamente creado para ello. Cuando el servidor de datos recibe la petición, ésta se registra y se llama al programa y método especificado en la URL con los parámetros suministrados.

    PROS:

  • ? Las ventajas son similares a las de la FoxISAPI, pues ambos permiten programar directamente en VFP cualquier consulta por compleja que sea. CONTRAS:
  • ? La instalación es bastante compleja y la forma de operar con objetos a veces puede parecer algo engorrosa.

    REFERENCIAS

    FOXISAPI

    En http://www.microsoft.com/vfoxpro podemos bajar la última versión de la FoxISAPI con ejemplos. Para ello hay que registrarse previamente porque se encuentra en el área privada.

    En el área pública hay una utilidad para generar páginas HTML desde Visual FoxPro pero es más limitada.

    Wes Wind Web Connection

    Se puede encontrar información de este producto en la dirección http://www.west-wind.com de la compañía West Wind Technologies que preside Rick Strahl, autor de esta utilidad. Es un sitio interesante con bastante información sobre Visual FoxPro e Internet. Dispone de una página donde se puede enviar mensajes estilo news. Muy útil.

    Ramon Seoane es responsable de TI de MOLDURAS DEL NOROESTE, S.L.