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.

Read the full article here, fromTheServerSide: 

Applying control theory concepts in software applications 

http://williamlouth.wordpress.com/2010/10/04/cars-cost-aware-runtimes-and-services/

OpenCore‘s metering runtime allows for a new breed of software that is cost aware; with cost referring to some degree of effort, elapsed time, resource consumption, financial liability, etc.

Cost aware software can dynamically alter its execution behavior, call paths and task scheduling based on previous cost patterns as well as current costing within some active execution context. Cost aware software is better able to prioritize, predict, provision, protect, problem diagnose and govern resource consumption – in real time.

http://williamlouth.wordpress.com/2010/11/27/opencore-6-1-m3-–-priority-interceptors/

With the ever increasing growth in cloud application deployments, both to PaaS & IaaS platforms, architects and operation staff need to rethink how quality of service (QoS) can be delivered without the level of direct control over networking possible today within enterprises. Fortunately this is at a time of significant transformation in the software industry that will see more and more software runtimes and services delivered with built-in metering, cost awareness and self regulation capabilities. Such new capabilities are part of our CARS vision which will be fully realized by the end of this year when we deliver the first iteration of a comprehensive application level QoS? solution built directly intoOpenCore’s activity based costing & metering runtime. A solution that will be driven largely by policy configuration though just like with other parts of our technology highly extensibly and scalable.

 

http://williamlouth.wordpress.com/2010/11/09/opencore-6-1-m2-metering-supervisors/

But what if we wanted to take control of the execution possibly throwing an exception to abort/terminate the current execution. How many applications today can truly handle such post development behavioral introductions? Not many. Not in a safe manner at least.

Part of the problem is in identifying suitable and safe control points in the execution path which could handle such introductions and react accordingly not just re-throwing dynamically introduced exceptions. We want the software to be cost aware so it can more effectively prioritize, predict, provision, and protect. So in the latest OpenCore 6.1 milestone release we added a method, supervise(), to the Probes.Current interface to allow the application to signal an appropriate point in the execution for external supervision.