Inicio > Tecnología > Servicios de datos

Capa de Servicios de Datos LANSA– para Proteger y Servir

Un principio fundamental de la arquitectura basada en el respositorio LANSA es separar las aplicaciones de las bases de datos en las cuales dependen.

En cada sistema existe un conjunto de reglas que controla cómo los programas de una aplicación pueden crear, leer, actualizar o suprimir datos. Estas reglas existen para mantener la calidad y consistencia de los datos y también proteger su integridad en un ambiente transaccional de múltiples capas. El fracaso para seguir las reglas puede llevar a cualquier cosa, desde valores de datos erróneos dentro de un informe hasta un fallo total de sistema.

Capa Independiente de Servicios de Datos LANSA

No en la base de datos ni en la aplicación

Típicamente estas reglas se mantienen a nivel de base de datos, usando procedimientos almacenados, validación de campo, disparadores, etc., o en los programas de aplicaciones. Se ve el beneficio obvio de forzar las reglas al nivel de la base de datos siendo que este modelo elimina la duplicación. Lo malo es que cada proveedor de RDBMS tiene su propio método de implementación de conceptos tales como disparadores y procedimientos almacenados, así que forzar las reglas en este nivel le ata a un proveedor específico. Esto se puede evitar al codificar las reglas en el nivel de aplicación, pero así, cada programa necesita incorporar el mismo conjunto de reglas. Esto reduce la productividad del desarrollador y aumenta el mantenimiento en curso.

Una Capa de Servicios de Datos completamente independiente

LANSA ha implementado una capa de servicios de datos que provee un sólo punto de acceso para todos los datos y sirve para abstraer formatos, localizaciones y protocolos. Programas específicos – llamados Módulos de Acceso al Objeto – son generados a partir de un diccionario de datos almacenado en el repositorio. Estos OAMs (por sus siglas en inglés) conocen la estructura de la base de datos (campos y archivos) y contienen las reglas que gobiernan todas las transacciones de Crear, Leer, Actualizar y Suprimir. Así que, por ejemplo, cuando un programa en cualquier sitio de la red quiere 'crear_Nuevo_Empleado' en la tabla 'comp_Empleado' en el sistema de Recursos Humanos, tal pedido será dirigido por el OAM apropriado. Cambios futuros solamente causarían que tal OAM fuera regenerado en el servidor y no tendría ningún impacto en otros programas. Es posible crear un OAM aun más inteligente al usar características incluidas como disparadores independientes de la base de datos o campos derivados que hacen cálculos o concatenan cadenas al instante.

Los OAMs de LANSA son accesibles desde cualquier programa en cualquier plataforma

Los Módulos de Acceso de Objetos (OAMs) pueden ser utilizados por cualquier programa en operación en el servidor IBM i sin importar el lenguaje de desarrollo que fuera utilizado, por ejemplo, RPG, COBOL, LANSA, Synon, PHP etc. La tecnología de iFusion.net también incluye middleware que permite que las aplicaciones construídas con el framework de .NET accedan a estos OAMs. El resultado final es que todas las aplicaciones – independientemente de su edad o tecnología – pueden usar una capa común de servicios de datos para acceder las bases de datos subyacentes.