Share
Email
Print
RSSLANSA Data Services Layer – to protect and serve
A fundamental tenet of the LANSA repository-based architecture is to keep applications separated from the databases upon which they depend. This is vital for data integrity.
In every system, there exists a set of rules that control how an application's programs are allowed to Create, Read, Update or Delete data. These rules exist to maintain the quality and consistency of the data and also to protect data integrity in a multi-user, transactional environment. Failure to follow the rules can lead to anything from bad data values in a report to a total system crash. You ignore the data integrity process at your peril.
LANSA independent data services layer
Not in the database and not in the application
Normally these rules are maintained at the database level, using stored procedures, field validation, triggers etc., or in the application programs. The obvious benefit of enforcing rules at the database level is that this centralized model eliminates duplication. The downside is that every RDBMS vendor has their own proprietary way to implement concepts like triggers and stored procedures so that enforcing rules for data integrity at this level locks you into a specific vendor. You can avoid this kind of database lock-in by coding rules at the application layer, but then every program needs to incorporate the same set of rules. This not only reduces developer productivity but increases ongoing maintenance.
A completely independent data services layer
LANSA has implemented its data services layer to provide a single access point for all data and serves to abstract formats, locations and conventions. Specific programs – called Object Access Modules – are generated from a data dictionary held in the repository. These OAMs know about the structure of the database (fields and files) and contain the rules that govern all Create, Read, Update and Delete transactions. So whenever any program anywhere on the network wants to ‘create_New_Employee’ in the ‘comp_Employee’ table in the HR system, that request will be directed via the data services layer and the appropriate OAM. Future changes would only cause that specific OAM to be regenerated on the server and would not impact any other programs. It is possible to make a data services layer, specifically the OAM, even more intelligent by using built-in features like database independent triggers or derived fields that perform calculations or concatenate strings on-the-fly.
The LANSA Data Services Layer is accessible from any program on any platform
OAMs can be used by any program running on the IBM i server regardless of the development language used e.g. RPG, COBOL, LANSA, Synon, PHP etc. LANSA’s iFusion.net technology also includes middleware that enables applications built with the .NET framework to access LANSA’s data services layer and these OAMs. The net result is that all of your applications – irrespective of their age or technology – use a common data services layer to access the underlying databases.
