In practice most commercial applications can be broken down into interactive or batch. Interactive systems are activated by a specific user. Batch systems can be activated by schedulers or by the completion of an event, ideally married to a workflow subsystem. The new generation B2B systems are effectively batch systems, using transaction messaging to deliver data to be processed.
There is however another class of applications which are event-driven. On detection of some event or other, a specific process is executed. As mentioned above this is quite a common way of initiating batch routines in workflow systems, but it has a role to play in interactive systems as well, in which some real-time processing is involved.
eal-time processing is of course not new. All process control (feed-back or automatic) systems function in real-time and there is a whole breed of software products designed to support programmable logic controllers, etc. While PLCs are the common devices used today for controlling instruments, production lines, machinery and chemical processes, a lot of the earlier work was done using interrupt-driven minicomputers with appropriate operating systems. This required a specific skill set which had nothing to do with the commercial world. This explains to some extent why many specialised applications based on PCs are using the wrong software e.g. Windows, when robust real-time operating systems are available.
As an example of what could be achieved in marrying interactive and event-driven systems, consider the requirements of a "stocks-and-shares" trading system. There are many traders, each with their own workstation and with their own customers, but all sharing a common database. Traders will interrogate the database and identify which items they are interested in. Some of these items they will be currently working with, interacting with the system in a conventional way.
When a change occurs new details are derived from various external sources and the database updated. With an interactive system this new information could be detected only if the database was searched, which is not practical for a lot of items and could involve delays since the database can’t be searched again and again continually.
Thus when an item changes, the software on the server is activated and relevant data sent to each and every workstation that has registered an interest in that specific item (not every item to every workstation).. In the workstation a background task is loaded but dormant, which is activated when a message is received from the server. This software can do various things in the workstation, but its role is to alert the user that something interesting is happening.
Early trading systems were built on Unix workstations or PC’s with OS/2, because Windows didn’t have the essential multi-tasking (a real-time OS feature!). Today NT or Linux would be the obvious choice.
While the above example is an important one, it is very specialised and would only be cost justified in such a high value application. However with the Internet a lot of services could exploit similar ideas, albeit with less sophistication.
The simplest example of this sort in the Internet is "push technology". Once a browser is connected to a server then while the interactive HTTP session is in progress, unsolicited messages can be transmitted to the browser. Typical software displayed these messages on "ticker-tape" banners. This early "push" technology was so severely rejected by users (it was so annoying!) that Microsoft dropped support for it from the current releases of Internet Explorer.
While I for one do not want to see the banners reintroduced, since I am already fed up with unsolicited e-mail and couldn’t stand any more advertising, there are some new applications that can exploit push technology. This will be particularly more attractive in the next few years when it becomes practical to leave a workstation permanently connected. Even trivial things can then be useful e.g. an alert that e-mail has arrived.
The potential of auctions over the Internet has already been established and there will be other group-oriented activities developed as we progress. An Internet auction could be one of simply placing a bid and the lowest bidder being informed by the "agent" of success. But with an event-driven version the auction can be interactive and real-time. Exciting isn’t it?
I’m sure some event-driven applications already exist, but it will be much easier if the relevant system software becomes a standard browser feature. The early event-driven systems failed because of the horrors of Windows 3.1. There are no excuses now!
