System State Consistency and Security

The part of the application that implements its specific functionality is called the business logic. For example, a medical application's business logic might include classes to implement a search query of all patients suffering from a condition. The business logic can be expected to be the most frequently changed part of the system, as it evolves to meet the needs of the users.

The inherent variability of the business logic, as well as its tendency to increase in size, pose a particular challenge to the client-cluster Internet-based application. While focusing on implementing features via the business logic, developers can easily forget about maintaining internal state consistency and security.

Unlike the business logic — which focuses on individual features — state consistency and security are global properties of the entire application. Thus, it is very important to provide dedicated subsystems for them, so that the business logic has a consistent, safe internal environment in which to operate. Failure to isolate security and state maintenance functions from the rest of the system introduces subtle errors in these critical functions every time a new feature is added to the application.

The UML [Mul97] Component Diagram in Figure 3 illustrates the major components in the LongJump architecture. The security subsystem consists of three subordinate subsystems. The first (Perimeter Filters) processes messages received from the clients, to make sure that these messages are valid. Hence, business logic components do not have to be concerned about malformed requests. Such damaged data might arrive from a faulty client; attackers also routinely manufacture subtly invalid messages in order to break into a server.

The second part of the security subsystem deals with user authentication. Its task is to establish the user's individual or group identity, and block unauthorized access. Once a valid identity descriptor has been issued by the Authentication package, it becomes bound to the request. The identity descriptor is used by the Permissions package in order to allow or deny an operation. This allows different users or groups of users to have varying levels of privilege in the LongJump system.

Objects from the Permissions package work closely with those from the System State Common Core, which is a part of the System State Engine. In the LongJump architecture, all users see the same information, with the Permissions package enforcing access. When components such as billing are added to the Business Logic package, this approach reduces errors while maintaining strong security.

For example, if a particular customer tries to view their own account information, it will come from exactly the same place — even the very same operation — as if a billing representative made the request. If, however, the customer somehow managed to query someone else's account information, the Permissions package would block the operation. Unlike the billing representative, customers should not have the ability to view account data other than their own.

As a second example, if the application were to include a messaging service for customers, then the Permissions package would block the billing representative from viewing these messages. The billing department's mandate does not allow the reading of private mail belonging to customers. These two examples illustrate how the LongJump architecture maintains state consistency, security and user privacy.

Of course, the billing representative will almost certainly connect to a LongJump application via a desktop PC, while a client might well be using a wireless handheld. The Networking subsystem includes a common set of application interfaces, which hide the differences (if any) in the underlying networking protocols. The Protocol Selector is used to choose the right protocol.

In addition to the System State Common Core, the System State Engine includes a Persistence Layer to manage the saving of data to secondary storage. Such a layer decouples an application's Object Oriented subparts from the details of the file system or the table-based structures of a Relational Database Management System (RDBMS).

The RDBMS paradigm is poorly suited to the representation of business rules, which is why modern methods for developing an application's business logic are Object Oriented in nature, and seek to isolate the database behind persistence layers (J2EE application servers, for example, follow this pattern). The Prevalence method [Vil02]is one simple way to implement persistence.