Re: I'm truly happy with this one, folks!

A postscript.

I believe that problems do not generally result from the use of inappropriate technology, but rather the inappropriate use of technology. This was my argument with the original supposition that the main problems were caused by a change of technology. The problem probably was that the f-wits didn't know what they were doing.

Most systems can be implemented using any technology from single tier mainframe to client-server gui and relational database to n-tier distributed architectures.

I know of one project which was intended to support thousands of concurrent users. The designers chose to use tuxedo as a middle tier. They then, however, decided that the easiest way to build the required tuxedo services was to implement a code generator which generated transaction types of select (x2), insert,update or delete for each table. Unsurprisingly the system would not scale. In the first load test (shortly before the delivery date), the system ground to a halt at 5 users.

The problem is caused by failing to understand why a transaction monitor like tuxedo allows scalability. Firstly, it allows a connectionless protocol. Secondly, it handles distribution of transactions over multiple processes which can be on different servers. If you generate 1 transaction for each row processed you lose the advantage of this distribution because the cost of managing the transactions becomes much higher than the cost of the actual transactions. Additionally, you cannot optimise the design of the middle tier for good performance. You cannot blame tuxedo or Oracle for the problem.

One of the things I find is that traditional mainframe systems tended to be designed around transactions which in turn tended to reflect a user activity.

Most of the "transactional" systems I've come across which use a relational database are designed around the data model, so you get nonsense like filling in an invoice header in one screen/window and filling in the invoice lines in another because these are in different tables.

The situation actually seems to be getting worse with GUI design where systems mandate the use of a mouse, despite the fact that it takes many seconds to switch between mouse and keyboard. Sometimes usability seems to be taken to mean easy to use by someone who has never seen the system before despite the fact most of the users of the system will be using it for years.

Probably the best (ie most efficient) user interface I've ever seen was that for an airline reservation system where some incantation like string of maybe 20 characters was all it took to book 2 return tickets between 2 airports, going out on one specific flight and returning on another. Received on Sat Feb 23 2002 - 11:05:35 CST