Una arquitectura para el desarrollo de sistemas de gestión empresarial. La Arquitectura AF y ASPL Fact.

Transcripción

1 Una arquitectura para el desarrollo de sistemas de gestión empresarial. La Arquitectura AF y ASPL Fact. Francis Brosnan Blázquez David Marín Carreño Marcos Olmos Domínguez En esta ponencia se hablará de la Arquitectura AF: una arquitectura que se propone para la implementación de sistemas de gestión empresarial, así como del proyecto a partir del cual esta arquitectura surgió: ASPL Fact. 1. Introducción A lo largo de los últimos años, se han iniciado varios proyectos de desarrollo de aplicaciones para gestión empresarial. Muchos de ellos fueron abandonados tras la etapa inicial del proyecto. Algunos otros continúan su desarrollo, pero el aprovechamiento del código existente en los mismos para su uso en otros proyectos es prácticamente nulo debido a su implementación monolítica. A finales de 2002, Advanced Software Production Line comenzó el desarrollo de ASPL Fact con el objetivo de crear una aplicación de facturación para Gnome, pero de modo que estuviera desarrollada bajo un modelo de componentes distribuidos altamente especializados. De este modo, a través de los primeros hitos de desarrollo de ASPL Fact, se ha ido definiendo una arquitectura de componentes distribuidos de fácil implantación e instalación, que da soporte a llamadas de procedimiento remotas y proporciona servicios de mantenimiento de sesiones, usuarios, y permisos: la Arquitectura AF. Advanced Software Production Line propone esta arquitectura como un estándar para el desarrollo de aplicaciones de gestión empresarial dentro del marco de desarrolladores de software libre. 2. La Arquitectura AF 2.1. Qué es? La Arquitectura AF consiste en un conjunto de librerías de soporte para el desarrollo de aplicaciones de gestión empresarial. Lo que se pretende es establecer un entorno de desarrollo en el cual, no solo estén estandarizados el mayor número de mecanismos posibles, sino que el desarrollador se dedique a la programación de sus aplicaciones de una manera muy general, evitando detalles como la comunicación, la sincronización y el acceso a bases de datos por citar algunos. ISBN

2 El modelo de programación propuesto consiste es un sistema cliente-servidor TCP basado en el paso de mensajes en formato XML. Lo interesante de la arquitectura es que permite al programador usar los servicios de la arquitectura de una manera muy limpia, en concreto: El desarrollador no tendrá que programar una sola línea de threads pues la comunicación con los servidores se realizar de manera abstracta a través de una api escrita en c que es completamente asíncrona. El desarrollador no tendrá que escribir código para crear sockets de conexión, gestionar buffers, mensajes, etc. Todo es realizado de manera abstracta, como si tratásemos directamente con estructuras de datos. La arquitectura está diseñada para que los componentes servidores sean independientes de la interfaz utilizada, además, éstos componentes también tienen mucho código de soporte dentro de la arquitectura para ser desarrollados rápidamente. La arquitectura está diseñada para que los componentes servidores sean independientes de la interfaz utilizada, además, éstos componentes también tienen mucho código de soporte dentro de la arquitectura para ser desarrollados rápidamente. Se ha estandarizado la api utilizada por las aplicaciones clientes (libafdal) para comunicarse con los servidores, así, la utilización de nuevos servidores a través de sus interfaces de aplicación es común y homogénea. Al realizar la comunicación con los servidores de manera abstracta, a través de estructuras de datos, se evita que aparezca código SQL por toda la aplicación, consiguiendo esto último que la aplicación desarrollada no sea mantenible a través de los cambios. La arquitectura, además, proporciona numerosos servicios que simplifican los clientes y los servidores. Algunos de estos: gestión de sesiones, permisos y mecanismos de seguridad (aun no están implementado, pero será implementado de manera transparente). La gestión de sesiones permitirá a los clientes autenticarse una sola vez en el sistema, en concreto al servidor central, y tener acceso al resto de servidores, siguiendo un modelo de seguridad similar al de kerberos. Por otra parte, los servidores son programados de manera que la arquitectura se encarga de determinar la corrección de las sesiones sobre las que son establecidas las peticiones. Finalmente, la gestión de usuario está centralizada, permitiendo que nuevos servidores no tengan que tener noción ninguna sobre los usuarios que existen, como gestionarlos y el nivel de acceso de que disponen Implementación actual Toda la arquitectura, en la actualidad, está implementada en el lenguaje C, utilizando la librería glib. Esto haría muy sencilla la construcción de bindings a otros lenguajes como C++ o Python. En la actualidad, la arquitectura AF está compuesta por varios componentes: Roadrunner Librería de comunicaciones desarrollada por la empresa sueca CodeFactory. Es una implementación asíncrona del protocolo de intercambio de mensajes sobre TCP BEEP. Esta librería abstrae completamente del interfaz de sockets de Berkeley, y proporciona todas las ventajas del protocolo BEEP, como la posibilidad de establecer varios canales de comunicación independientes por conexión, etc. 65

3 Coyote AfDal Una arquitectura para el desarrollo de sistemas de gestión empresarial. La Arquitectura AF y ASPL Fact. Esta librería, desarrollada ya dentro de la arquitectura por Advanced Software Production Line, está íntimamente relacionada con Roadrunner. Implementa los perfiles que la arquitectura AF empleará para las comunicaciones, así como todas las funciones auxiliares necesarias para el análisis léxico y sintáctico de los mensajes. Esta librería es el corazón de la arquitectura. Todos los componentes de la misma emplearán sus servicios, ya que incorpora, entre otras, los mecanismos de: Gestión de sesión y de llaves. La arquitectura emplea mecanismos de sesión y de llaves para la transmisión de las capacidades de los usuarios desde el servidor central hasta cada uno de los servidores proveedores de servicios. Gestión asíncrona de peticiones y procesado de respuestas. Librerías libafdal* libafgs Estas librerías, que en la actualidad se generan manualmente (aunque a medio plazo se generarán de manera automática) incluyen todas las interfaces de solicitudes de servicios para cada uno de los servidores de la arquitectura, así como los tipos que representan cada uno de los objetos de negocio con los que se trabajará. Esta librería implementa la parte común de todos los servidores de la arquitectura, de modo que la realización de un servidor se convierte en un mecanismo completamente trivial, debiéndose codificar sólo una variable que define los servicios que implementa el servidor, así como las funciones a las que se llamará cuando un cliente solicite estos servicios. af-kernel Este es el servidor central de la arquitectura. Se encarga de la gestión de usuarios y permisos, así como de la generación y mantenimiento de sesiones y llaves. Estos componentes son los que definen las capas que forman la arquitectura AF. Para implementar una aplicación que la utilice, sólo es necesario realizar un servidor que proporcione servicios que accede a la base de datos, genera sus registros log mediante la librería afgs. Tras esto, hay que implementar la capa libafdal* correspondiente al servidor, que será la librería llamada por el programa cliente para acceder a los servicios implementados Estado del proyecto y evolución futura. En la actualidad (septiembre de 2003), la primera versión de la arquitectura AF, tras la liberación del tercer hito, y poco antes de la liberación del cuarto hito de desarrollo de ASPL Fact, se encuentra definida en su mayor parte. La arquitectura congelará su API en el lanzamiento de la versión 0.1 de ASPL Fact, prevista para Diciembre del presente año. Esta congelación se realizará para construir la primera versión estable del sistema de facturación, aunque el desarrollo en la arquitectura no se detendrá. De hecho, existen dentro de Advanced Software Production Line varios proyectos que implicarán mejoras importantes dentro de la presente arquitectura: AF-Gen: consiste en la construcción de un generador automático de código a partir de un lenguaje de definición de objetos de negocio. De este modo, desde una descripción de un objeto de negocio en un formato similar a IDL o a XDR, se tendrán, dependiendo de los casos, los esqueletos o el código completo de las funciones que 66

4 realicen los servicios relacionados con dichos objetos de negocio, tanto en la capa de servidor, como en la capa libafdal*, llegando incluso a la generación automática de formularios para interfaces de usuario. AF-Sec: este proyecto está orientado al análisis de vulnerabilidades en el protocolo de intercambio de mensajes empleado, de modo que se consiga un aumento en la seguridad del mismo. Así mismo, también incorporará la implementación de varios niveles de seguridad para el acceso a los servicios (en la actualidad, existe un único nivel de seguridad al que se accede con un par usuario/contraseña). En un futuro se ha previsto el soporte de scripting en el lado del servidor. De este modo, por ejemplo, la solicitud del servicio de "creación de factura" podría hacer, mediante un script creado por el administrador, que el servidor de facturación se comportara como cliente del servidor de contabilidad para insertar un apunte contable. 3. ASPL Fact 3.1. Qué es? ASPL Fact era, inicialmente, un proyecto para hacer un programa de facturación bajo GNU/Linux sobre el entorno Gnome. A día de hoy, ASPL Fact es un paquete software formado por 4 servidores para la Arquitectura AF (a saber: servidor para gestión de clientes/contactos, servidor para gestión de artículos, servidor para gestión de impuestos y servidor para la gestión de facturación) y por un programa cliente (el propio programa \asplfact). Todos estos programas proporcionarán las características de un programa de facturación, pero... En un futuro, cualquiera de estos servidores pueden emplearse para otra aplicación, ya sea de contabilidad, de control de almacenes, o de control de pedidos... La aplicación cliente ASPL Fact es completamente independiente de la base de datos. la estructura de ésta puede cambiar, pero el código del cliente ASPL Fact se mantendrá igual: la aplicación está completamente abstraída de la base de datos. 4. Por qué utilizar la Arquitectura AF? Hemos enumerado antes las ventajas de utilizar la Arquitectura AF a nivel técnico y haciendo referencia directa a problemas existentes en el desarrollo de aplicaciones de gestión comercial, pero no hemos hablado aún de las ventajas generales de esta propuesta. Tal y como está definida la arquitectura, obliga a los desarrolladores a programar en un modelo basado en capas, donde cada una se dedica a algo más específico que la anterior. Por lo tanto, cada una de las capas de comunica con la siguiente de manera abstracta hasta que la petición se resuelve finalmente. Esta idea es la misma que el estandar OSI para comunicaciones. El otro modelo posible de programación es el de una sola capa. Este tipo de aplicaciones tienen concentrada en un mismo nivel el acceso a datos (SQL), la lógica para manipular estos datos y la interfaz de usuario. Las ventajas del modelo basado en una sola capa es que es más facil de programar inicialmente y más rápido en el acceso a la base de datos frente al modelo basado en varias capas. 67

5 Pero, las desventajas que ofrece el modelo basado en una capa son: Obliga a realizar la programación de manera muy dependiente al interfaz que se esté utilizando. Esto es un problema a la hora de compartir código con otros proyectos, pues todo el código está fuertemente acoplado a la interfaz. En un modelo basado en varias capas, existe una parte, que es la que gestiona las peticiones a los datos, que es completamente independiente del interfaz. Impide que se pueda construir un modelo real cliente servidor que permita una existencia independiente entre el servidor y el cliente. Esto ocasiona que no se pueda realizar proceso en los datos a no ser que el cliente esté arrancado, o se programen demonios add-hoc que realicen ese proceso. En un modelo basado en varias capas es posible la existencia de procesos de ejecución independiente a las interfaces haciendo posible el proceso en background. Dificulta el mantenimiento del software. La característica esencial de las aplicaciones de gestión empresarial es que todas, de un modo u otro, están apoyadas sobre una base de datos. Pues bien, el acceso directo a los resultados de las sentencias SQL hace que cualquier cambio en el esquema de la base de datos signifique revisar las sentencias que ya existienses y que guardasen relación. En un modelo basado en varias capas, el acceso a los datos se realizar de una manera abstracta, es decir, la interfaz de usuario no tiene conocimiento alguno sobre cómo está implementada la base de datos, los campos que posee y las relaciones existentes. El código hecho así, no hay que revisarlo debido a cambios en el esquema de datos. 5. Referencias e información relacionada Toda la documentación actual acerca del proyecto puede obtenerse de su página web: Acerca de la librería Roadrunner puede encontrarse información en: ( 68