Por Alberto Rodriguez
© Copyrights 1997 by FoxPress, All rights reserved
FoxPress, Septiembre 1997
Hay muchos programadores para los que programar consiste en estar delante de un teclado escribiendo código, cualquier otra actividad es una pérdida de tiempo.
Sin embargo, la experiencia ya viene demostrando como antes de empezar a escribir código es necesario previamente parar a pensar:
El análisis de la aplicación no sólo debe satisfacer las necesidades presentes sino que tiene que estar preparada para los posibles cambios que el cliente pueda pedir sin tener que reescribir totalmente la aplicación: la experiencia de aplicaciones similares y el conocimiento del mercado debe hacernos dejar las suficientes puertas abiertas como para poder implementar mejoras a la aplicación; esto es lo que se suele llamar flexibilidad.
Se puede decir que todas las aplicaciones tienen la misma arquitectura básica y se pueden subdividir en tres partes:
Entendemos por aplicaciones mono-capa, aquellas que tanto la propia aplicación como los datos que maneja se encuentran en la misma máquina y son administradas por la misma herramienta: podríamos decir que son una sola entidad
Figura 1. Arquitectura Típica de una aplicación de una sola capa.
Estas aplicaciones son más conocidas como aplicaciones Cliente/Servidor y lo más característico es que dividen una aplicación entre un cliente y un servidor estableciendo un middleware que controla las comunicaciones entre ambos. Un programa Visual FoxPro que interroga a una Base de Datos SQLServer es un ejemplo de aplicación en dos capas.
En la raíz de las aplicaciones cliente/servidor está la separación de la aplicación en componentes encapsulados u objetos. La ventaja de romper una aplicación en trozos es que cualquier cambio de uno de esos componentes no tiene un impacto directo sobre los otros o en el resto de la aplicación.
En las arquitecturas two-tier, la aplicación se divide en dos entidades separadas.
La arquitectura two-tier dividida en dos entidades con el interfaz por un lado y las reglas de negocio junto con el Acceso a Bases de Datos por otro se muestran en la Figura 2.
Figura 2. Arquitectura Two-tier con el interfaz y las reglas de negocio encapsuladas juntas.
O se podría poner en el mismo lado el interfaz junto con las reglas de negocio y tendríamos lo que se muestra en la Figura 3.
Figura 3. Arquitectura Two-tier con el acceso a la Base de Datos y las reglas de negocio encapsuladas.
¿Qué método es mejor? Como regla general poner reglas de negocio ligados a un interfaz es una mala idea ya que fuerza a que cada cambio en la aplicación nos lleve a ir usuario por usuario cambiándole la aplicación.
Encapsular las reglas de negocio junto con los datos tiene la ventaja de que se pueden cambiar sin tener que tocar los interfaces de los clientes que seguramente estarán muy distribuidos. El inconveniente es que normalmente los Servidores de Datos no son muy moldeables y es bastante complicado implementar reglas de negocio en los servidores.
Muchas aplicaciones two-tier combinan de forma conjunta ambos sistemas. Es con frecuencia impracticable o indeseable, encapsular completamente los procesos con los datos.
En estas aplicaciones el Servidor de Datos procesa las Consultas y realiza todas las actividades relacionadas con la Base de Datos. Cada Cliente inicia y deja abierta una conexión al servidor para poder enviar las peticiones y poder procesar las respuestas.
Normalmente la lógica se establece en el cliente usando un lenguale 3GL o 4GL o en el servidor mediante Triggers y Procedimientos Almacenados. Dependiendo de donde establezcas la lógica tendrás un Fat Client o un Fat Server.
Este modelo suele ser costoso de mantener, difícil de escalar y pesado de depurar.
Como se podría esperar cada uno de los componentes de la aplicación en una arquitectura three-tier se separa en una sola entidad. Esto te permite implementar componentes de una manera más flexible. Algo que no creo que sorprenda es la afirmación de que este tipo de arquitectura es la más compleja.
Figura 4. Arquitectura Three-Tier.
En esta Arquitectura todas las peticiones de los clientes se controlan en la capa correspondiente a la lógica del negocio. Cuando el cliente necesita hacer una petición se la hace a la capa en la que se encuentra la lógica del negocio. Esto es bastante importante pues eso quiere decir que:
Lo ideal sería que el Gestor de Reglas de Negocio no sólo OLE y ODBC sino otros estandares como DBLib, OLI, DRDA, SQL/API y X/Open
La elección entre arquitecturas two- y three-tier es independiente del Hardware que se tenga. Los desarrolladores han estado implementando aplicaciones Cliente/Servidor desde los primeros tiempos de la programación excediendo muchas veces las posibilidades del Hardware sobre el que corrían. Se rompe la aplicación en muchos trozos que dialogan entre sí.
Afortunadamente, en la actualidad el hardware, las redes y los sistemas operativos permiten a los desarrolladores implementar aplicaciones de una forma que antes era abosolutamente imposible. Una aplicación desarrolladda usando un modelo en tres capas se puede desarrollar en un PC, incluso en un NetPc o en entornos tan diversos como Mac, Microsoft Windows NT™ o servidores Unix dando servicios a aplicaciones de datos en redes Microsoft Windows® o Mac. Una apliación Three-tier no sirve para nada si no es escalable.
Implementar aplicaciones cliente/servidor conlleva muchos problemas que podríamos subdividir en tres categorías:
Es necesario tomar estas consideraciones debido a que la aplicación se rompe en múltiples trozos que corren en diferentes PC y con frecuencia envoviendo diversos Sistemas Operativos.
El problema principal de las aplicaciones Cliente/Servidor es el control de las comunicacines y las notificaciones de los eventos asíncronos. Este problema también existe en las arquitecturas three-tier lo mismo que en las two-tier donde los datos y las reglas de negocio se guardan de forma conjunta.
Si la aplicación va a funcinar en entornos que unicamente son Windows , se podría usar OLE o DDE para disparar los eventos y controlar las tareas. Es fácil de usar, rápido de implementar y funciona en la red.
Si la aplicación va a funcionar en diversos entornos se debería considerar seriamente el uso de herramientas que soporten otros estándares coo el standard Distributed Computing Environment (DCE) que define la forma cómo se deben tratar los servicios, la seguridad y el acceso a redes y ya que es implementado por casi todos los vendedores permitiría trabajar con diversos entornos y sistemas.
Para hacer aplicaciones cliente/servidor que funcionen bien se debe tener en cuenta algunos aspectos como:
Arquitecturas que almacenan grandes bases de datos en los servidores de red y usan una lógica que está en cada PC cliente violan las reglas anteriores y su rendimiento es bastante malo.
La optimización de las velocidades de acceso es el gran problema de estas aplicaciones. En una implementación cliente/servidor, algunos datos se deben guardar en el cliente por razones de optimización. Esto ocurriría con algunas tablas estáticas que cambian poco
Admitida que estas Arquitecturas son más complicadas y es una dificultad añadida a la hora de implementarlas. Sin embargo, la complejidad añadida y los esfuerzos aplicados conllevan unos beneficios reales.
Aplicación de mantenimiento de una tabla en VFP 5.0.
Características:
Aplicación de mantenimiento de una tabla en VFP 5.0.
Características:
Este es el formato ideal para las aplicaciones mono-capa que en un futuro corto se tendrán que pasar a Cliente/Servidor. El hecho de tener las vistas sin parametrizar conllevará costos añadidos en la transformación y en la optimización dela red.
Aplicación de mantenimiento en VB de una tabla .DBF
Características: