Applying control theory concepts in software applications

Summary

Control theory is a discipline originated in mathematics and engineering science but was adopted also in psychology, social sciences and other research domains. It deals with influencing the behaviour of dynamical systems. In this article it is shown that concepts of control theory can also be applied to software architectures that have a need for controlling dynamical behaviour. Software applications that react to external input in form of GUI requests, batch input or service calls are in deed dynamical systems whose behaviour depends on current event, environment and actual system state.

Basics of control theory

The goal of controlling a system is to reach or retain stability. In control theory, stability is described with the Lyapunov stability criteria and mathematical models that set into relation the input and output of the system. In real world software applications where business cases are executed the mathematical models have no meaning whereas the stability term has. In a most general approach, stability is retained in an application when business rules are respected. Business rules in this sense are regarded here in a rather broad interpretation. They include not only the inherent rules that are executed and validated within the application but also rules imposed by environment, business structure, organisation, infrastructure, network and common sense.

For example you will never find a business rule saying that typos are not allowed, this is a common sense rule which must not be declared explicitly. But if a user introduces a typo into the name of a customer the system will be in an instable state because this customer will be vanished when the user tries to search him by name (without typo).

Often in IT business stability of a system is confounded with robustness. In control theory a robust control system is one that is able to handle situations that are slightly different or not foreseen by the applied mathematical model. Mathematical models are always simpler than the real world systems they describe. A robust system can cope with out-of-bound signals and unexpected events without crashing. Various techniques can be applied to make a control system robust like threshold control, self-learning processes, predictive control or high-gain control methods.

For software industry the meaning of robustness is very similar. An application is said to be robust when it can handle unexpected input, undefined situations, user errors or system failures without crashing down and going into an instable state. Stack traces on a user window are generally no good indication for robustness.

One precondition for setting up a control system is that the system is controllable at all. Controllability is defined as the possibility to issue an appropriate control signal that changes the state of the system. If a heating system has no valve to increase and decrease hot water supply no signal will be able to control the temperature. The system state is not controllable. Often the executing part of a control system is designed as an actuator, a device that converts energy into some kind of motion. Similarly it must be ensured that in a software application the states of system variables, domain objects and processes are controllable. This includes specifying which states should be controlled, defining appropriate variables, parameters, entities or other objects and providing interfaces that change their state. These are the valves and actuators of a software application.

The counterpart of controllability is observability. The system state must be observable through appropriate measurement facilities. If a system is not observable the current values of some of its states cannot be determined by the controller and, consequently, it will be unable to fulfil the control specifications referred to these outputs. A solution to reach observability is integrating a sensor for one or more system variables.

In control theory a lot of models have been developed but they all can be put down to two basic designs, the closed loop and the open loop controller. In Figure 1 a common closed loop controller design is shown.

An example is the heating system of a house for controlling temperature. A sensor monitors the output of the system which is in this case the air temperature. The controller compares the measured values with a reference or setpoint and calculates from the reference rules if the heater must be switched on or a hot water valve must be opened. If so the heater increases the temperature which is then an input variable of the system. This is an example of a feedback controller: The variable measured by the sensor is the same as the controller is trying to control. The controlled variable is "fed back" into the controller. Feedback control usually results in intermediate periods where the controlled variable is not at the desired setpoint. This slowness of feedback can be minimised by using an appropriate open loop controller (Figure 2)

Figure 2: open loop controller

In this design a disturbance is measured by the sensor before it has an effect on the system. If in the above example it is known that opening a window will decrease the air temperature a sensor could measure the opening of the window and switch on the heater before the air temperature actually has gone down. This is an example of a feed-forward controller: The controller acts before a disturbance affects the system. The difficulty with feed-forward controllers is that all possible disturbances and their influence on the system must be known, accounted for and observed by an appropriate sensor. If in the example the opening of the door is not observed the feed-forward controller will let the house cool down.

Another characteristic of controllers is how many variables of the system they control. Single-Input-Single-Output controllers (SISO) measure one system variable like air temperature in the above example of the house heating system. Multi-Input-Multi-Output controllers control more than one system variable (Figure 3). In real control systems often a synthesis of open and closed loop, feedback and feed-forward, SISO and MIMO controllers are used in sequential, hierarchical, nested or networked combination.

Common Control Frameworks

Cibet Control Framework

The Cibet framework (http://www.logitags.com/cibet/) can be used to build nice control systems for controlling business processes. It is one of the most flexible control frameworks that allows integrating a lot of different control mechanisms into an application. In fact control schemes are pluggable so that any customised control could be integrated.

Figure 4 shows the general design of the Cibet control framework.

The sensor is an interceptor that intercepts business cases or other events. The sensor type is strongly dependant on the application technology like platform, application framework, runtime container or database access technology. The actual release provides sensors for JPA, EJB, pojos, singletons, static methods and Spring beans.

The sensors transfer the metadata of the business case like affected domain object, call parameters and the context containing the actual user and the calling instance to the controller. The Cibet controller compares these incoming data with a reference in form of a setpoint configuration. Setpoints define the conditions for business cases and what control schemes to apply on them. There exist several controls which could be applied like

-         The event context of the business case: invocation of a method, persistence event, release in a dual control process, redo or restore events.

-         The class and method which are involved in the business case

-         The state change of a domain object in a persistence business case

-         The caller or invoker of the business case.

-         The parameters of a method invocation

The evaluation of incoming data and setpoints is done in the controller part but the actual application of control schemes is done in instances of Actuator. Actuators have an influence on the business process and on the system. Actually there exist five build-in actuators:

-         INFOLOG is for tracking purposes and writes an information message to the standard log file.

-         ARCHIVE is for archiving and historizing business cases especially to fulfil legal requirements. Archived business cases can be redone or restored.

-         FOUR_EYES implements four eyes principle. A business case must be approved and released by a second user before it is executed in the production environment. The approving user must be different from the user who initiated the business case

-         SIX_EYES implements six eyes principle. A business case must be approved and released by a second and third user before it is executed in the production environment

-         SPRING_SECURITY
integrates Spring Security in order to authorise business cases

Spring Security

The Spring Security framework (http://static.springsource.org/spring-security/site/) provides mechanisms to control business processes with the target to secure them. The emphasis lies on two control schemes: Authentication and authorisation. Authentication is the control process to identify and authenticate the initiator of a business process who could be a user, another process or another device. Authorisation control checks if the initiator has the permission to execute the business process. The system design which can be set up to control web requests with Spring Security is a sequential open loop control system (

Figure 5). Please note that this is a simplified picture. In reality, the process is far more complex.

The sensor is a ServletFilter; in fact it is a whole chain of filters. The request and the http metadata are transferred to a set of controllers, the most important being the AuthenticationManager and the AccessDecisionManager. The AuthenticationManager checks if the web requester is already authenticated and authenticates him if not using as reference a user database, an LDAP system, CAS or other means. As an output it denies access or transfers the request to the AccessDecisionManager. This controller checks if the user has an appropriate role and permissions to access the web resource. As reference it could take configured URL patterns, permission definitions, access control lists and so on. The output is either access or denial to the system.

Spring Security allows also controlling access to service layer methods or domain objects with the help of aspect-oriented programming (AOP). The sensor is in this case an advice realised with AspectJ or Spring AOP.

Java Security Architecture

The Java virtual machine itself provides with the SecurityManager and Permissions framework (http://java.sun.com/javase/6/docs/technotes/guides/security/permissions.html) a mechanism to control application access to system resources. This is a code-based authorisation framework, that is, the permissions are granted based on code characteristics: where the code is coming from and whether it is digitally signed and if so by whom. The java.lang.SecurityManager class contains a set of check methods which are executed when the application accesses system resources by invoking jdk methods. The control design is depicted in Figure 6.

The sensor is in this case an interceptor directly integrated into the Java virtual machine. It intercepts not all jdk methods but only those which are defined as secured by jdk and which are listed in the above mentioned Permissions documentation.

The sensor calls the SecurityManager’s check methods which takes the part of the controller. The actual resource, method and method parameters are compared with the reference which is a policy file with defined permissions and the context. If the evaluation grants access the method is invoked or the resource accessed, otherwise a SecurityException is thrown.

This control system has a closed loop design because the sensor detects the same item as the controller is trying to control.

JAAS Authorisation

The Java Authentication and Authorisation Service (JAAS) (http://download.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html) is another framework included into the jdk which uses control mechanisms inherent to the virtual machine. In fact, it is an extension to the Java Security Architecture in that it authorises access to system resources not only to executing code but also to authenticated users who are executing the code.

In Figure 7 the control design with JAAS authorisation is shown. An authenticated subject which in JAAS terms can be a user or another service invokes a business method which is encapsulated in a PrivilegedAction class. The Subject class contains a doAs() method which associates the provided Subject with the current access control context and then invokes the run method from PrivilegedAction. The action thus executes as the specified Subject. Thus the Subject.doAs() method acts as a sensor for all business logic that is wrapped in a PrivilegedAction and executed via the doAs() method. The JAAS AccessController class compares the actual action, subject and context with the reference in the policy file and executes the PrivilegedAction or throws a ServiceException.

JMX

While the subject of Cibet, Spring Security or JAAS is to control business processes Java Management Extensions framework (http://java.sun.com/javase/technologies/core/mntr-mgmt/javamanagement/) is a framework for controlling resources. JMX is used to manage and monitor application and system resources such as devices, interfaces, application domain objects or virtual machine properties. These resources are represented as MBeans which are registered in an MBean server. JMX is typically used for:

-         Consulting and controlling application configurations.

-         Monitoring of application or system parameters and collecting of statistics

-         Notifying about unexpected state changes of parameters or failure situations

JMX provides built-in components to create open- and closed loop control systems. With the Timer functionality an open loop system can be set up (

Figure 8). The sensor is in this case the system clock which measures the time as input variable. References for the Timer MBean are the configured execution time and period, the registered notification messages and listeners. The Timer MBean acts as the controller, checks if the time matches the configuration and sends notifications to the listeners. The notification listeners take the role of an actuator. They are the executing part of the controller and perform any action that will make an input to the system.

JMX provides also a Monitor MBean which can be used to build closed loop control systems. A Monitor is an MBean that periodically observes the value of an attribute in another MBean. If the attribute meets a certain condition, the Monitor emits a notification to registered listeners. Different types of monitors allow the collection of statistical data, comparison of data over time, watching the crossing of thresholds and signalling the attainment of specified values. A control system based on the Monitor functionality is depicted in Figure 9.

Here the observed MBean is the sensor. The output variable could be any attribute of the observed resource, e.g. the memory usage of a MemoryMXBean. The Monitor MBean is the controller and compares the output variable with its configured thresholds, comparison values and other monitor definitions. If the observed variable matches the reference Monitor sends a notification to the NotificationListeners which act as Actuator in the system. They can take appropriate action on the system that directly influences the observed variable which will be fed-back into the sensor.

Conclusion

The principles of control theory originally coming from engineering science can be found also in many frameworks used in software development. The design concepts of control theory like open loop and closed loop controller give another vision and maybe a clearer and more general view on the functionality and inner working of many software frameworks. Surely there could be found many other examples of applied control theory concepts in the IT world.

About the author

Dr. Wolfgang Winter is an architect and system analyst at Atos Worldline GmbH, a 100% daughter of Atos Origin S.A. His main focus is server side development on Java EE platform in payment, card and transaction processing. In his spare time he tries to keep his web site about cycling in the South of France up-to-date and publishes open source project Cibet under the label LogiTags.