LANSA 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.
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 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.
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. One can see the obvious benefit of enforcing rules at the database level, being that this centralized model eliminates duplication. The downside being that every RDBMS vendor has their own proprietary way to implement concepts like triggers and stored procedures so that enforcing rules 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 a data services layer that provides 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, for instance, 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 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 an 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.
LANSA OAMs are accessible from any program on any platform
Today, LANSA OAMs can be accessed directly by LANSA programs or via our open client/server middleware technology. It is our vision that any program on the network should be able to access that layer and call those OAMs directly. To this end we are already working to open up our data services layer by building support for other technologies like Microsoft .NET and by providing a generic Web Services interface.