Given that your company has been building transaction applications for decades, how different can it be to build a Web-transaction application? Besides, the boss says, all the back-end stuff is already in place. What's the big deal?

It is true that much of what goes into an internal system remains when building a Web version. Product, billing and payment, and shipping information are collected; credit information is verified; inventories are checked; items are removed from inventory; production or picking orders are triggered; data is verified; databases are updated--everything one does for conventional transaction applications.

"You have similar issues when it comes to the integration of different systems, and similar problems with managing distributed transactions," says Rhett Guthrie, chief architect at Axys Solutions LLC, a custom development shop that has built a number of Web-transaction applications for its clients. "The closer you get to the back end, the more similar the problems become."

Conversely, the differences become more substantial as you move toward the client portion of the application. If a Web transaction is interrupted because the customer gets impatient and clicks away or because a link is broken, the entire transaction can fail. Often, there is no mechanism for rolling back or re-establishing the transaction at an interim stage. If the customer comes back, the transaction must start over.

"The Web is a stateless environment," says Beth Gold-Bernstein, senior analyst at Hurwitz Group, an IT consulting firm. "It's a loose connection, which makes it very hard to recover." By comparison, conventional transactions typically have a continuous connection to systems that manage and maintain the state of the transaction until it's completed and confirmed.

The statelessness of the Web, says Gold-Bernstein, forces developers into substantially different ways of thinking about an application. For example, a developer building a transactional application that lets a customer order a product must somehow check inventory to ensure the product is indeed available. In a conventional client-server transaction application, this is not especially difficult. The developer has the application make a synchronous call to the database that manages the inventory. The application checks the item's availability and reserves it until the transaction is committed. Since the call to the database is bidirectional, the application knows right away whether the item is available. If the transaction is interrupted, the system recognizes the interruption but will have stored all the transaction information each step of the way. When the connection is re-established and the customer logs back on to the system, the transaction can resume where it left off.

However, when building a Web-transaction application, the developer cannot assume a direct synchronous connection between the client and the back-end database. Neither can the developer count on the system maintaining much in the way of state, unless such a mechanism is built into the application from the start.

"The developer is going to have to think differently. He isn't going to be able to check the availability of every item," Gold-Bern-stein says. The inventory data might be sitting on the server of a different company, such as a fulfillment house or a supplier. Instead of having direct, real-time access to that data, the developer might only have a log file that lists out-of-stock items. The log file would be updated periodically, perhaps in response to messages reporting that items are newly out of inventory, or other items have been replenished and are thus removed from the list.

But the issue of state is just one of many significant differences about Web transactions, and important disparities exist on the middle tier and back end as well. Security, integration, performance, scalability, the multiparty complexity of many Web transactions, and even testing all emerge as serious hurdles.

continued...page 2, 3

Illustration by Doug Ross