A critical issue to address in all data intensive applications is that of maintaining the integrity of the data and the security of system functionality. This becomes even more difficult and important as systems become more complex and functionality is continually distributed further out across an interconnected world. Though there are multiple aspects to the AOA solution to this problem, not surprisingly, at the heart of this solution sits the AOA object, the LOD.

The foundation to AOA integrity rests on the requirement that ALL persistent data has to pass through an AOA object to get to and from a data source, which is usually a database. This addresses integrity and security in two ways:

All database data sits securely behind the LOD, with the only data exposed to rules and interfaces being that which is defined in the LOD. Thus, application areas can easily be limited to subsets of the total data. This is particularly of value to query interfaces, where the user needs flexibility of data access, but access that is none-the-less limited to an appropriate subset of the total.

All physical data in an object is encapsulated from programs and interfaces through the object, with only its logical structure exposed. This enables validations to be defined for a LOD and performed at several levels.

Domain Validations – The lowest level component that is received and stored in AOA is an object attribute. But since the value of every attribute passes through a domain during retrieval or storage of attribute values in all situations, the validations from that domain assure the quality of the data in all situations. When either a rule or an interface tries to set invalid data into an attribute, the function is rejected and an error message is automatically returned.

Entity Access Permissions – A maintenance LOD is composed of many entities, usually with varying modification requirements. In many cases, entity components exist in the LOD because their data needs to be presented on interfaces or used inside rules, with no need or intent to be modified. In other cases, the only modification of an entity is the inclusion/exclusion of data for that entity within the LOD, with no need to modify attribute values. It is only in a minority of cases that an entity’s contents need to be created, updated or deleted. The entity permissions defined in the LOD definition restrict interfaces and rules to those modification functions specified therein.

LOD Commit Constraints – Many of the validations that are performed on data are rules that consider the consistency of data values across entities and attributes and can only be defined via some form of procedural rule. For example, it may be that the total of Financial Aid Awards for a student cannot exceed the Cost of Tuition for that student. These kinds of validations are defined for an object as Object Constraints specified in VML and are automatically triggered whenever the object is committed to the database.

Server Level Validations – The above validations are quite adequate when all maintenance activity is performed on a secure server. However, the industry is gravitating toward the movement of functionality further out onto nodes of the internet and the realization of Universal Design Objects will only accelerate the problem. All the validations above will accompany an object through its internet journey, of course, but what could keep knowledgeable hackers from manipulating the meta rules from those objects once they are out into the public domain? The answer lies in a revalidation of all data once it is returned to the main server. Since those validations are driven from an object definition kept back at the original source, any manipulation of the rules out on the internet will be ignored.