Switch on payments
Australian software developer Distra has found another way to apply distributed computing to the world of business. The company has created a Java-based distributed transaction processing platform on which it has built an electronic payments switch. A switch acts as an intermediary between the bank that acquired the transaction from the retailer and the bank that issued the card to the customer, and also between local institutions and foreign payment networks, enabling the movement of funds.
In Australia, most switches are operated by banks and other financial institutions. Coles Myer operates its own switch, as do telcos, utilities, and other organisations in various geographical markets. Although the Australian market is relatively mature, electronic payments are growing by between eight and 13 percent per year, says Rod Dew, Distra’s sales and marketing manager. Globally, the growth is between 20 and 30 percent, which means banks and other financial institutions may need to double their processing capacity every three years. This makes the scalability of distributed systems very attractive.
Switches traditionally run on small clusters of large mainframes running software created by very few suppliers and using two-phase commit in the database to ensure that each transaction is either completed or does not happen at all. (You wouldn’t want a situation where a customer’s credit card was debited, but a corresponding credit was not applied to the retailer’s account.) These vendors “haven’t cracked some of the fundamental distributed problems,” says Dew. In particular, fault tolerance is handled inelegantly by proprietary and expensive hardware, as opposed to being inherent in the switch application hardware. Additionally, the traditionally monolithic approach limits scalability. “It may be parallel, but not what I’d call massively parallel,” he says. In contrast, Distra provides fault tolerance at the application level.
Distra’s product can run on any Java Virtual Machine, and has been tested on Himalaya, Solaris, Linux, and Tru64. As for performance, an installation with four entry-level Sun servers distributed across two sites can switch 1500 EFT transactions per second with full real-time disaster recovery. This performance would satisfy the largest acquiring operation in Australia and can easily be increased to meet future needs, says Dew.
The design of the underlying transaction processing platform means it can survive “n-1” failures (processing will continue, albeit at a reduced rate, as long as at least one node is still functioning). “If you lose a server, processing continues immediately on another server.” This also means that a single logical switch can be distributed across multiple sites, with practically instantaneous failover even if one of the sites goes offline. Reliability is essential for this type of application: “They’ve got to have this running 100 percent of the time,” says Dew.
Additional benefits are that particular processes can be moved around for convenience (eg, to take a server offline for maintenance or replacement, or to handle a peak load in a particular geographical area), and that granular changes can quickly be made to suit marketing campaigns, etc.
“Early adopters of a pure Java switch will reap benefits,” says Dew. Other developers could add additional functionality around the switch, for example for ATM management or card issuing systems, he explains. Distra’s goal is to create a development community around its transaction- processing environment.
There is significant competition between banks for transaction acquisition, and offering the cheapest rates is a major inducement to retailers. Dew says that the distributed architecture used by Distra’s switch means hardware costs are reduced, software licensing and maintenance costs should be lower, and Java developers are easy to find at a relatively low cost for custom development.
Anything else?
While Distra’s current focus is on retail EFT payments, there is the potential to build other applications on its distributed transaction platform to service markets such as health, travel, wholesale banking, and stock markets.
Sun has other technologies that could be applied to distributed computing, suggests Mayo. JINI was originally floated as a way of handling hardware services such as printing and storage, but it now looks like it will be more useful for software services. In particular, it provides a mechanism that makes services self-describing to the rest of the system.
JavaSpaces provides persistent, network-based storage, allowing communication between independent but related processes. This could be used in a military context by having one system responsible for identifying targets, and another that takes care of shooting them.
The spotter application posts each target in a JavaSpace, and the shooter application watches that space for new targets, decides whether they are in range, and takes the appropriate action. More prosaically, an ATM might perform a transaction and drop the details into a JavaSpace monitored by software responsible for the back-end processing. These routines could behave selectively, for instance picking out transactions associated with a particular bank. If the number of transactions (or targets) starts to approach the limit, you simply add more back-end processes (or shooters) to keep up.
