Companies large and small are now generating significant revenue and earning growing profits through Web-based electronic commerce. Everyone ­ from Wall Street trading houses to the hot new Internet consumer auctions ­ is hosting millions of on-line transactions a day. E-business is a multi-billion dollar industry and growing. That's serious money. But to capitalize on the vast potential of e-commerce, organizations must erect computing architectures capable of handling massive volumes of on-line transactions while providing security, scalability and maximum transactional control.

One key to creating a successful on-line commerce system is the use of modularized code to encapsulate various procedures, functions and services.

In this way, we can optimize the use of resources in a distributed network and streamline critical access to operations such as "get price," "sell item" or other frequently performed tasks. The distributed programming paradigm allows programmers to call procedures regardless of what machine or architecture they reside in. Just as in conventional programming, these procedures contain lines of executable code written to perform a specific task. The difference in the distributed world is that now the disparate systems in your enterprise can be glued together to function as if they were one system. This is a critical component to be able to quickly deliver a new e-commerce system that allows the user, from a browser, to launch a transaction that touches your customer care, order and billing, financial, and procurement systems. If your situation is like most environments, all of these systems I just mentioned would be from different vendors, written in different languages ­ probably sitting on top of more than one database. A transaction processing (TP) monitor provides the glue that will allow this to happen quickly and accurately.

The TP monitor is the crucial middleware management link in virtually all high-volume, on-line commerce ventures. It allows e-commerce tasks to be distributed and load balanced across multiple network resources, thereby supporting the massive processing and synchronization requirements unique to large scale, on-line businesses. In addition to providing split-second load balancing management, today's most sophisticated TP monitors also employ data-dependent routing to channel each bit of data or activity to the correct network destination.

Traditionally TP monitors have been inside the firewall; however, the more popular monitors now allow Web access directly from Java. In this model, Java applets download and execute a service call through an API provided by the vendor. BEA's Tuxedo, for example, uses a proprietary API called Jolt to enable Java programs to execute Tuxedo services on the enterprise side. TransArc's Encina also allows access to its services through Java.

There are currently three main ways to use highly modularized code to generate input from the user location ­ from the browser via the Web, through a firewall and into the distributed enterprise network ­ to start and complete some type of e-commerce activity. Most organizations now do this through a combination of Java applets, servlets or CGI scripts.

The somewhat newer device-dependent innovation called Java servlets operates at the Web server level. These allow Java applets to instantiate an object in the servlets which, in turn, connects via the API to an enterprise-level function, procedure or service. Servlets, in a sense, create a form of multitiered Java environment and serve again to modularize and concentrate often-used code closer to the center of the distributed e-commerce network. Some designers also utilize CGI scripts to run C or C++ programs which, although less scalable and less popular, does allow a Web server to execute and run programs on the enterprise server.

Control is another key issue in the implementation of any e-commerce architecture.

Good programming practices dictate that you retain control at the enterprise level ­ never giving users control over resources. This design approach is an absolute necessity when dealing with the potentially massive volumes of on-line transactions.

In virtually all instances, an on-line transaction takes place across a distributed network comprised of multiple resources, with key databases typically segmented by geography, product type or some other variable. With larger on-line systems called upon to handle literally millions of transactions a day, we simply cannot turn control of any resource to the user side for even a fraction of a second.

For this reason, we must employ the applet/servlet/CGI methods described earlier, which allow the user-side application to make an abstraction call to launch a service or a method invocation, and from there the TP monitor takes control to manage all transaction activities. In fact, e-commerce system designers spend most of their time working to optimize these services, tuning the system to move each transaction in and out almost instantaneously.

In our next WebWorks column, we will discuss the other primary TP monitor solutions from Microsoft, Iona and BEA Systems. By understanding the crucial elements of a successful e-business architecture, companies can tap into the booming on-line marketplace.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access