CAPITULO 1: “Enfoque de Reglas de Negocio en los Sistemas de Información y la arquitectura del
1.5. Consideraciones para la implementación de reglas de negocio
1.5.2. Arquitectura de sistemas y la implementación de reglas de negocio
La arquitectura cliente/servidor sustituye a la arquitectura monolítica en la que no hay distribución, tanto a nivel físico, como a nivel lógico. Consiste básicamente en un cliente que realiza peticiones a otro programa (el servidor) que le da respuesta. Aunque esta idea se puede aplicar a programas que se ejecutan sobre una sola computadora, es más ventajosa en un sistema operativo multiusuario distribuido a través de una red de computadoras. En esta arquitectura la capacidad de proceso está repartida entre los clientes y los servidores, aunque son más importantes las ventajas de tipo organizativo debidas a la centralización de la gestión de la información y la separación de responsabilidades, lo que facilita y clarifica el diseño del sistema.
29
La separación entre cliente y servidor es una separación de tipo lógico, donde el servidor no se ejecuta necesariamente sobre una sola máquina, ni es necesariamente un solo programa. Los tipos específicos de servidores incluyen los servidores Web, los servidores de archivo, los servidores del correo, etc. Mientras que sus propósitos varían de unos servicios a otros, la arquitectura básica seguirá siendo la misma.
La arquitectura cliente/servidor tradicional es una solución de dos capas. La arquitectura de dos capas consta de tres componentes distribuidos en dos capas: cliente (solicitante de servicios) y servidor (proveedor de servicios), se puede observar en la Figura 1. 3.
Figura 1. 3 : Esquema de arquitectura Cliente/Servidor clásica.
Estas aplicaciones de 2 capas trabajan bien en aplicaciones a escala de departamentos con un modesto número de usuarios, una base de datos sencilla y una red segura y rápida. La principal ventaja que presenta este tipo de aplicaciones es que los datos están centralizados. Esta centralización beneficia a la empresa pues es más fácil compartir los datos, se simplifica la generación de reportes y se proporciona consistencia en el acceso a los datos.
A continuación se enumeran las principales desventajas que presentan este tipo de aplicaciones: Difíciles de mantener: Esto viene dado por el hecho de que son difíciles de mantener las reglas de negocio de la lógica de aplicación ya que estas están programadas en cada cliente y esto implica que cualquier cambio tiene que ser redistribuido en todos los clientes.
Se compromete la confidencialidad: Al tener programada la lógica de aplicación en el cliente este tiene a su disposición todas las reglas de negocio de la empresa.
Capa Cliente
Aplicaciones ClienteCapa de servidor
Datos del negocio30
Están estrechamente limitadas a una fuente de datos: Los clientes casi siempre están configurados para acceder a una base de datos, en particular por lo que mover los datos a una base de datos diferente se hace realmente complicado.
Para mejorar este tipo de aplicaciones se introdujeron los procedimientos almacenados. Estos procedimientos almacenados son funciones de software pre-compilados que son manejados y se ejecutan dentro de la propia base de datos.
Una de las principales ventajas que trae consigo el uso de estos procedimientos almacenados es que como se localizan en la propia base de datos pueden procesar la información en su misma fuente, sin tener que transferir a través de la red.
En los sistemas tradicionales, las reglas de negocio suelen estar embebidas en el código de los programas, lo que provoca las desventajas siguientes:
Falta de claridad en las reglas del negocio, ya que las mismas están “perdidas” entre varios módulos y códigos que son entendibles por los programadores.
Cada vez que se cambia una regla es necesario recompilar el código de la aplicación. Suele ser dificultoso localizar el lugar exacto donde una regla de negocio se encuentra. Las reglas no pueden ser gestionadas por la gente del negocio.
Imposibilidad de compartir las reglas de negocio con otros proveedores o clientes.
Una estrategia para resolver estos problemas es separar las reglas de negocio del código, y almacenarlas en un repositorio, en el que son manejadas por un motor de reglas independiente al Sistema de Información del negocio. Por tanto las restricciones no se codifican en el sistema y este sólo puede realizar accesos necesarios al repositorio.
Arquitectura de tres capas
La arquitectura de tres capas es una representación abstracta del modus operandi de los Sistemas de Bases de Datos y, en última instancia, sirve para esquematizar cualquier sistema independientemente del medio ambiente en el que se desarrolle (
31 Figura 1. 4).
Figura 1. 4 : Arquitectura Cliente/Servidor en tres capas
Cada uno de los componentes de la aplicación en una arquitectura de tres capas queda bien delimitado. Esto permite implementar componentes de una manera más flexible.
En la arquitectura tradicional de tres capas, se instala una interfaz de usuario en la computadora del usuario final (el cliente). La arquitectura basada en web transforma la interfaz de búsqueda existente (el explorador de web), en la interfaz del usuario final. La parte funcional de la arquitectura de tres capas generalmente es conocida como la capa intermedia o capa de negocio. Esta es donde la mayoría de los procesos ocurren. La tercera capa comúnmente es el sistema de administración de la base de datos, es decir, donde los datos requeridos por la capa intermedia son almacenados. La tercera capa se localiza en un servidor separado, conocido como el servidor de base de datos.
Una de las diferencias claves entre el modelo tradicional cliente/servidor de dos capas y el de tres capas es el uso de lo que es conocido como “middleware”. En la industria de la computación, “middleware” es un término general que define a cualquier aplicación que sirve para “unir” o mediar entre 2 aplicaciones que usualmente trabajan independientes. Algunos de los más populares tipos de “middleware” son los Monitores de Transacciones (Transactions Monitors). Los Monitores de Transacciones trabajan prácticamente como policías del tráfico ya que estos se
Capa de Cliente
Aplicaciones ClienteCapa Intermedia
Aplicación de ServidorCapa Servidor
Datos del negocio32
colocan entre los clientes y el servidor de los datos y controlan el paso de las consultas o actualizaciones desde los clientes a la base de datos adecuada. Por otro lado dichos monitores mantienen abiertas solo aquellas conexiones a la base de datos que son necesarias lo que trae consigo un mejor rendimiento para el trabajo de la base de datos.
Una vez elegida esta arquitectura, aún cuando puede resultar más complicada y es una dificultad añadida a la hora de implementarla, conlleva ciertos beneficios reales (Mena and Vellón, 2008):
La posibilidad de integrar aplicaciones que accedan a las mismas bases de datos de una forma sencilla.
Separar las reglas de negocio de los interfaces especialmente en entornos multiplataforma permite que las reglas se cambien con un mínimo impacto sobre los usuarios de las aplicaciones.
El uso de modelos de tres capas aumenta considerablemente la flexibilidad a la hora de aplicar las posibilidades de la informática para aspectos específicos de la problemática del cliente.
Es fácil construir nuevas aplicaciones desde los componentes instalados si las reglas del negocio están en unos servidores de aplicaciones más que en cada aplicación.
Herramientas como el ODBC, que fuerza a las bases de datos a ser abstractas y transformarse en genéricos almacenes de datos, permiten permanecer completamente flexibles a la hora de determinar dónde guardar los datos independientemente de la aplicación que se use.
Las llamadas de la interfaz del usuario, en la estación de trabajo, al servidor de capa intermedia, son más flexibles que en el diseño de dos capas, ya que la estación sólo necesita transferir parámetros a la capa intermedia.
Con la arquitectura de tres capas, la interfaz del cliente no es requerida para comprender o comunicarse con el receptor de los datos. Por lo tanto, esa estructura de los datos puede ser modificada sin cambiar la interfaz del usuario en la PC.
33
El código de la capa intermedia puede ser reutilizado por múltiples aplicaciones si está diseñado en formato modular. Esto puede reducir los esfuerzos de desarrollo y mantenimiento, así como los costos de migración.
La separación de roles en tres capas, hace más fácil reemplazar o modificar una capa sin afectar a los módulos restantes.
Separando la aplicación de la base de datos, hace más fácil utilizar nuevas tecnologías de agrupamiento y balance de cargas.
Separando la interfaz del usuario de la aplicación, libera de gran procesamiento a la estación de trabajo y permite que las actualizaciones de la aplicación sean centralizadas en el servidor de aplicaciones.
Para cada una de las organizaciones técnicas, la arquitectura de tres capas incrementa la habilidad para responder a los cambios y permite reutilizar código, simplifica el mantenimiento y hace más fácil la migración a nuevas plataformas. Conforme continúa la transformación de las prácticas obsoletas, las organizaciones deben cambiar y crecer junto con las necesidades del medio, para ofrecer soluciones viables (Mena and Vellón, 2008).