Discussion

J2EE gained great prevalence as a design pattern in the early part of this decade. To a great extent its popularity coincided with an increase in Web applications. As the successor to C++, it also found use in non-Web apps that could be heavy on general processing, calculations, and transactions. But its use there has been somewhat limited because of requirements for very fast complex transaction processing.

While the Java server was coming to be defined in the late '90s as a general purpose distributed server based around J2EE and implementing EJB containers, Grid computing was making its way out of the scientific world into commercial implementations. In recent years, a variety of methods that are somewhat 'grid like' have been making there way into the world of Java-centric computing. In different ways they address some limitations that J2EE exhibits when it is pushed higher into the realm of high-performance computing.

We recently got a chance to discuss this topic with John Davies, technical director and head of research, Iona. With a long track record working on transactional systems for high-powered financial companies, Davies has seen a variety of systems over the years. In March, he spoke at TheServerSide Java Symposium in Las Vegas on the topics of extreme transaction processing, low latency and performance.

Extreme transaction processing (XTP) has been defined by technology analyst group Gartner Group as an application style aimed at supporting large-scale, high-performing transactions across a distributed environment on commodity hardware and software. Lately, a variety of approaches have emerged that help in some way to improve Java program performance across distributed systems that may match Gartner's criteria for XTP.

"I think that the J2EE application server was a successful pattern for a number of years. It became a de facto standard in 2001 and 2002, when everything had to be a J2EE application server, said Davies.

"But inefficiencies of J2EE have led people to look for alternative technologies. Whether you call it Grid, Data Grid, High-Performance Computing, XTP, or whatever, there is a whole realm of computing needs in that area," he said.

The standard J2EE app server, of course, had some legs. In financial areas, it found some resistance.

"People that used it in practice at the high-performance end of the world, where applications were less Web-centric, and more server-side-centric, found there were a lot of inefficiencies, for example, with the EJBs," said Davies, who was CTO and co-founder of C24, a specialist at complex financial app integrations, before it was sold to Iona.

EJBs and associated proxies, Davies said, did effectively abstract the location of objects, but, he continued, this added many layers to system architecture. "And then there were all these inefficiencies of getting finally through to the data base - just a huge number of layers that we had to go through to get to what we actually wanted," he said.

Layers can mean latency, and this can be an issue in global finance, where the difference between microsecond- and millisecond-response time can make a big difference in the amount of money made on any deal. Besides EJBs and proxies, Davies noted that processing pauses for garbage collection is still the most important issue for Java when it is cast in financial settings.

"There has always been a need for a higher-end thing, and J2EE just wasn't that. A typical design means you establish an EJB object which talks to the EJB's stateless session bean which in turn talks to another EJB object which talks to a stateful or entity bean, for example," said Davies. "So each time you are going through different layers, and if those are truly distributed in a clustered environment you have serialization and other things [with which to deal]."

Davies noted among companies creating high-performance alternatives: Tangosol [creator of Coherenece, and now part of Oracle], which came up with a caching layer approach; and Gigaspaces which built software based on the JavaSpaces standard. He also said that Amazon's new EC2 [Elastic Computing Cloud] services and GemStone's established GemFire software bear watching. He agrees that greater success for these varied alternatives is due in some part to the lower cost of memory these days.

"In 1999, 2000, and 2001 we didn't have the kind of memory we have today. To get a machine with a gigabyte was a pretty big server," he said. Approaches can be combined. In fact, at TSS JS, Davies described a complex transaction handler his team built that combined Artix Data Services, Azul hardware, GigaSpaces, and Mule software.

"We are seeing a general movement from applications being hosted by an application server to applications being hosted by a Grid or a virtualized server. This is definitely a trend that has been demonstrated in the last few years," Davies told his TSSJS audience.

"An application server eats up huge amounts of resources just to say, 'Hello world,'" he said.

Contrast this to software that lets you distribute methods or tasks over multiple machines. "This is becoming the mainstream," said Davies.

"You are very constrained in a J2EE server by the deployment topology," he said. Davies said he sees EJBs "dying off," and a corresponding movement from "application servers to what have been known as grid technologies."

PRINTER FRIENDLY VERSION