PL vs GUI

Kal Krishnan gave us a couple of interesting insight at the September meeting of the SDForum Business Intelligence SIG. In his talk "Event Based Architectures For Real-Time BI", he explained the iSpheres Event Server, a system for real time Business Process Management (BAM) that captures, transforms and does complex processing on business events as they happen.

Two things about his presentation struck me. The first was a claim that the iSpheres Event Server could handle 470,000 events per second. It is an impressive performance even when you discount by a factor of 3 or 4 for benchmarkism. I have heard that a stock market feed can have a peak rates of 100,000 messages per second so we get some hope that the iSpheres server would be able to handle it.

The other insight was that iSpheres uses a programming language to specify the behavior of the Event Server. Kal told us that they had started out by providing a GUI with icons and drag and drop as their programming interface and this had proved to be too cumbersome for programming the number of events that an event server needs. So, a few years ago they rethought the programming interface and designed an event programming language instead.

I have remarked before on this issue. In practice, you always have to provide a programmable interface, either with a programming language or through an API. From this, it is straightforward to provide a GUI, either as a plug in to an existing development system or by automatically generating the GUI from the language or API specification.