Service d'accès aux données LANSA – Protéger et servir
Un principe fondamental de l’architecture basée sur le référentiel LANSA consiste à préserver l’indépendance des applications des bases de données dont elles dépendent.
Dans chaque système, il existe un ensemble de règles qui contrôlent la façon dont les programmes de l’application sont autorisés à créer, lire, mettre à jour ou supprimer les données. Ces règles existent pour préserver la qualité et la cohérence des données ainsi que pour protéger l’intégrité d’un environnement transactionnel multi-utilisateurs. Le non respect de ces règles peut conduire à tout un tas de situations, de valeurs de données erronées dans un rapport à une panne totale du système.
Pas dans la base de données ni dans l’application
Ces règles sont normalement maintenues au niveau de la base de données au moyen de procédures stockées, de la validation de champ, de déclencheurs, etc., ou dans les programmes applicatifs. L’application de ces règles au niveau de la base de données procure un avantage évident, à savoir que ce modèle centralisé élimine toute duplication. L’inconvénient de ce système étant que tout distributeur RDBMS possède un moyen propriétaire d’implémenter des concepts comme les déclencheurs et les procédures stockées de sorte que l’application des règles à ce niveau vous contraigne à rester chez ce fournisseur. Vous pouvez éviter ce type de piège en codant les règles au niveau de la couche application, mais chaque programme doit ensuite intégrer le même ensemble de règles. Non seulement la productivité du développeur s’en trouve réduite, mais la maintenance permanente s’en trouve accrue.
Un service d’accès aux données totalement indépendant
LANSA a implémenté un service d'accès aux données (Data Services Layer) fournissant un point d'accès unique à l'ensemble des données et permettant de simplifier la gestion des formats, localisations et conventions. Des programmes spécifiques, appelés Object Access Modules, sont générés à partir d’un dictionnaire de données qui se trouve dans le référentiel. Ces OAM connaissent la structure de la base de données (champs et fichiers) et contiennent les règles qui régissent toutes les transactions de création, de lecture, de mise à jour et de suppression. Aussi, chaque fois qu’un programme où qu’il se trouve sur le réseau souhaite par exemple « créer_nouvel_employé » dans la table « comp_Employé » du système RH, cette requête sera dirigée via l’OAM approprié. Les futures modifications auraient pour seul résultat de régénérer cet OAM spécifique sur le serveur sans le moindre impact sur les autres programmes. Il est possible de rendre un OAM encore plus intelligent en utilisant les fonctions intégrées comme les déclencheurs indépendants ou les champs dérivés qui effectuent les calculs ou concatènent les chaînes à la volée.
Les OAM de LANSA sont accessibles à partir de n'importe quel programme ou plateforme
Les OAM peuvent être utilises par n’importe quel programme s’exécutant sur le serveur IBM i quelque soit le langage dans lequel ce programme a été écrit – que ce soit du RPG, du COBOL, du LANSA, du SYNON, du PHP, etc. … La technologie iFusion.NET embarque aussi un middleware qui permet au framework .NET d’accéder aux OAM. Le résultat « net » est que toutes vos applications – quelque soit leur âge ou leur technologie – peuvent utiliser une couche unique d’accès aux données pour utiliser les bases de données.