Many things we see today in the Internet-based applications are like visiting the past. When the Internet was new few years back, it merely provided a forum for static document display. You click on an url and there is a roundtrip with the fetching of that web-page. It was a stateless entity. Remember, transaction processing and statelessness are oxymorons. Transactions deal with “unit of work” and hence somewhere someone has to keep track of the progress of that uow (unit of work). If for some reason, the uow did not complete, then various schemes need to be provided for backing out to the last equilibrium point when you begin next time. You cannot withdraw money from one account and not deposit in another account in a money-transfer transaction. If the system goes down in between, then its an incomplete “unit of work”. These are stuff we did 20 years ago and books were written on two-phase commit etc. Doing such transactional applications on the internet requires the presence of software that manages the integrity of the uow.
As we step into the second phase of the Web (Web 2.0) for making rich internet applications available to serious users (banking, finance, shopping,..), transactional integrity via state management is key. Typically this function is provided at the application server level. The backend database engine provides data integrity via checkpoint, backup, etc. Application level checkpointing and recovery need to be provided at the mid-tier by the application server software. Some state management is done at the client side also, specially for form-based transactions (fill out an entire form via multiple interactions).
Many such functions were developed during the late 1970s and 1980s to enable online systems developments for the airline and banking industries. The architecture was a hop-step-and-jump style, with a dumb terminal front-end, and transaction processing monitor (TP Monitor like CICS) in the mid-tier, and a backend database like DB2 or Oracle. With the Internet, we are back to the future again with a hop-step-and-jump style 3-tier architecture. The middle tier is now the application server that combines the functions of a TP Monitor, a development IDE and runtime for application logic, load balancing, portal construction, workflow logic (BPM), etc. I sometime call the application server as the equivalent of six blind people identifying an elephant. Each one has a different view of what it is.
Like many apsects of computing, we keep re-inventing the same stuff over and over again. But the wisdom of the past years comes in handy for old-timers like me.