The following section describes the main principles that Aware IM is built upon.
Aware IM is built on an assumption that most data management systems have many common aspects. Essentially any data management system requires data to be entered and stored somewhere (usually in a database), it also requires the data to be found, retrieved and edited and it offers some user interface to perform all these operations. Most systems also perform processing of this data according to certain rules (this is often referred to as “business logic” of a system).
Apart from these main generic aspects most systems also need to take care of security issues, manage documents, generate reports, communicate with other systems etc.
The cornerstones of the Aware IM approach to the implementation of the above mentioned aspects of a data management system are listed below.
Business objects are carriers of data
In Aware IM the world of a data management system consists of business objects. Business objects encapsulate the data that needs to be entered, retrieved, edited and processed.
In Aware IM there is no data that exists outside of a business object.
In a way this model very closely reflects the real world. Business objects exist in every business – customers, accounts, orders, payments etc. The data that a business object encapsulates is represented as attributes of a business object. For example, an order may have the placement date, customer, line items, shipment address, shipment date, shipment number etc.
Business objects form relationships
Business objects can be linked with other related objects. For example, an order object can be related to an order line item object (an order may contain multiple order line items and an order line item belongs to a particular order).
Business rules are carriers of business logic
In Aware IM data processing (or business logic) is encapsulated in business rules. A rule specifies one or more actions that should be executed when the rule conditions are met. Conditions are optional and if none are specified actions are executed unconditionally. In other words a rule states what should happen and when.
Here are some examples of rules:
If Account.Holder.Age < 16 Then REPORT ERROR ‘Account holder must be 16 years old or over’
LineItem.Total = LineItem.Price * LineItem.Quantity
If Reservation.Status WAS CHANGED TO ‘Offered’ Then SEND ReservaitonOfferEmail TO Reservation.Member
REQUEST SERVICE ProcessPayment OF PaymentProcessingSystem
If Fee.Status=’Applied’ Then PROTECT Fee.Amount FROM ALL
Actions of business rules can perform a variety of tasks. Most importantly they can create and modify business objects, i.e. perform data processing. They can also perform calculations, create or print documents, display information, exchange data with other software, etc.
Business rules are triggered when there is a change in data
Rules are triggered when certain events happen inside the system. Most importantly, rules are triggered when there is a change in the system’s data, i.e. when business objects are created or modified.
When an object is modified (for example, the value of an object attribute changes) Aware IM evaluates all rules that depend on the changes executing the actions of those rules for which the conditions are satisfied. Note that:
- Execution of actions may have a ripple effect – Aware IM tracks all changes made by the actions during rule execution and continuously re-considers all rules that depend on the data changed by the actions.
- Not only does Aware IM consider all rules that depend on the modified object directly, but it also considers rules that depend on the changes indirectly, i.e. through objects that are related to the modified object.
- Rule execution continues until there are no more actions to execute. The change to the system’s data therefore moves the system from one logically consistent stable state to another logically consistent stable state through a period of instability when relevant rules are executed.
Processes are Links between User Interface and Business Logic
The initial trigger that leads to the creation or modification of a business object is almost always some external request to the system usually from a user who sends this request via the User Interface. In many cases this request starts a process, which creates or modifies a business object(s).
A process usually consists of actions that create a business object or find the existing object and modify it. This triggers evaluation of business rules. The rules start a chain reaction of other modifications until the system settles down. When this happens the process communicates the results back to the user.
Therefore a process represents a link between the User Interface and business rules – it triggers business rules in response to the request from the User Interface by performing initial creation or modification of a business object and then communicates the result back to the User Interface.
For example, a process transferring funds between two accounts can be made up of the following rules:
- Display funds transfer form: ENTER NEW FundsTransfer
- Display receipt: DISPLAY DOCUMENT TransferReceipt
- Display client details: VIEW Customer
Note that the process is very small and is mainly concerned with allowing the user to enter necessary details and presenting the results of the operation to the user. All the business logic behind the funds transfer operation (such as checking whether there are sufficient funds in the source account, calculation of fees for the transfer operation etc) is expressed in business rules related to the object FundsTransfer (they are not shown here). Aware IM evaluates these rules as soon as the user enters the data for the FundsTransfer object (between “Display funds transfer form” and “Display Receipt” operations).
Although a process is primarily used as a link between the user interface and business logic, it can also be used as a container of un-ordered business rules. It is possible to call such a process from other processes or business rules and let the rule engine evaluate the rules and invoke the appropriate actions. Thus it is possible to combine the data-oriented approach to business rules (when rules are triggered by the change of data) with the service-oriented approach when the rule engine is explicitly invoked from some place in the system.