Enterprise Management Tools:
Mo' Better Java

By ELLIS BOOKER

Java programmers are playing an up-tempo tune these days, grooving on a Java app scene that offers as many possibilities as the most freewheeling late-night jam session.

And while it's clear that the Java tools market has found its voice, are these tools up to the task of creating enterprise applications? Are Java integrated development environments (IDEs)-many of which now contain helpful drag and drop, debugging and wizard tools-suitable for core business apps?

Based on interviews with users, analysts and vendors, the answer is a qualified yes. Qualified because the Java standard is still moving forward and the tools are too new. But even with these caveats, those in the know agree that Java IDEs are better than ever.

The progress is occurring along three fronts. First, Sun Microsystems' Java spec is stabilizing and adding features aimed squarely at meeting the requirements of enterprise networks. Secondly, the tools that support the Java spec are more robust. And thirdly, a steady stream of alliances and mergers promises to add considerable muscle and flexibility to Java IDEs.

Among programmers, many are augmenting existing apps with Java-based interfaces on the client or Java middleware on servers. These techs have largely settled the debate Microsoft alone wants to have-whether Java is not only a programming language, but a suitable platform for deploying applications.

Reports from the field confirm Java's promise: It really does let programmers isolate core applications from the underlying operating system, letting them port applications across different hardware and operating systems.

Companies are programming and deploying in Java. And many say that as the tools increasingly support distributed, server-side Java, they'll be happy to play that tune as well.

"Compared to where we were six months ago, we've moved away from heavy, client-side Java," says Dick Costolo, an architect at Digital Knowledge Assets, a privately held company. Digital Knowledge Assets (www.dkaweb.com) is one of a number of developers that has shifted its emphasis. The company is developing an organizational knowledge-capture and distribution system, implemented mostly in server-side Java and built using Symantec Corp.'s Visual Cafe.

At Net-Temps Inc., both the client and server for the company's job-search app was built in Java. Net-Temps is using Sun's Java WorkShop, which can run on any platform with a Java Virtual Machine. "Hardware was a big issue for us, since we use DEC, Sun and a lot of other machines here," says Kevin Strange, vice president of Net-Temps.

"We have to make it easy for our developers to write applications across multiple platforms," says Steve Paulovich, development manager at Net-Temps. "Using Java as a base keeps the developers happy, because they can write applications that let our users run apps over multiple platforms." Appropriately, one of Net-Temp's services features a way to find Java programmers by searching against a database compiled from 900 employment agencies.

Few question that the industry is gravitating toward server-based apps. But some, like Digital Matrix Services Inc., a privately held company, are bucking the trend by embracing Java on the client.

Digital Matrix built an E-commerce solution aimed at smaller retailers that delivers an entire store's inventory-up to 100,000 items-to the customer's desktop as a Java app. The store app does not use any server-side techniques. "It's a radical design," says Herman Miranda, president of Digital Matrix.

"Essentially, we download the entire store, 100,000 items, to the client as a Java apple t. We tried to do this in HTML but couldn't," says Javier Martinez, the company's regional sales director.

Miranda says the project first started as a plan to build a CD-ROM application, but within months it changed focus as it became clear that it was possible to render the entire retail experience as a Java app. Both the client- and server-side Java in the Digital Matrix store app were written in Microsoft's J++, with additional HTML elements authored in Microsoft's Visual Studio.

To execute the app, Digital Matrix had to build a number of items on its own. This included a lightweight Java database that ships down to the client machine, along with the inventory and pricing information. All the data is compressed using techniques the company has used for years with its geographic information system.

It is worth recalling why programmers gravitated toward Java. Java is easier than C++, offering automatic handling of memory management and garbage collection. And Java is designed for networked a pplications. Moreover, Java's object-oriented nature can serve as a wedge for other object-oriented products-for example, databases-or techniques such as code reuse.

But some analysts caution that Java IDEs still have a long way to go. "What people are using Java for now is user interfaces, client-side things," says John Rymer, president of Upstream Consulting.

Among the biggest problems? Rymer says these tools don't come near to matching their 4GL predecessors in terms of simplifying the link with existing back-end systems such as databases and enterprise applications. "If you need to access SAP, you still have to write that glue code yourself," Rymer explains.

But that might change. Daiwa Securities America Inc. is using Java to build an ambitious middleware layer that it hopes will fill the gaps between the company's front-end and back-end systems. Under Daiwa's middleware approach, JavaBeans serve as software agents that automatically peel, translate and traffic data between the various serv er and client apps.

"Rather than a common format of a centralized system or a client-server approach, you make a little incision [in the application] and extract the transaction,'' says Jeffry Borror, director of information technology at Daiwa, a subsidiary of Daiwa Securities Co. Ltd., the second-largest brokerage firm in Japan.

Keep in mind that Daiwa is a clear exception. Most corporate IT staffs use Java exclusively-and some might say, conservatively-for presentation. But let's face it, even relying on Java for a user interface is not without its problems.

That's because of the well-documented incompatibilities between Java Virtual Machines among vendors and even between iterations of a single JVM from the same source. In addition, there is broad user concern over Java's future on Windows, given the ongoing court case between Sun and its largest Java licensee, Microsoft.

Gaps To Fill

Ron Bodkin, chief technology officer at C-bridge Internet Solutions Inc., a year-old develo pment shop that has done work for high-profile clients like Toyota Motor Sales USA, Caterpillar Inc. and Harley Davidson Inc., also admits that the Java tools have gaps to fill.

"We're still looking for multithreaded debuggers and layout managers," says Bodkin, who also uses Symantec's Visual Cafe. But if the development tools are still "pretty primitive," Bodkin defends Java against what he calls the "red herring" that it is too slow to handle high-end apps.

"For most applications, the bottleneck that holds the application up is the speed of the disk and the network, not computation on the server," Bodkin says.

Still others say that the arrival late last year of Sun's Enterprise JavaBeans spec will help ready the Java tools for industrial-strength applications. EJB is the distributed component model for Java, and will let JavaBeans work together in distributed environments. EJB should let developers concentrate on business logic, while letting shared EJB services handle the work under the covers . The finished EJB is expected this spring.

For now, none of the Java IDEs supports EJB, although most are now supportive of JavaBeans, which designates how a collection of Java components communicate in a local setting.

EJB will be key, not only for distributed apps, but for connections to transaction monitors and directory and security services. Meanwhile, the consensus among industry watchers is that a Java IDE vendor shakeout is at hand.

"Out of the 25 Java IDE vendors, I'd say only 20 percent have enterprise scalablity. It's critical that they integrate with existing solutions like BEA Inc.'s Tuxedo and IBM's MQSeries." says Jeetu Patel, vice president of research at DocuLabs Inc., a technology procurement advisory company.

Patel also says there is confusion in the market about which products do what, given the overlap at the moment between site management, content management and application development. One differentiating feature going forward, he predicts, will be "a very strategic tying of E-commerce [solutions] with applications development."

Joshua Duhl, president of Stillpoint Consulting, also thinks the herd will thin to "two or three tools," but expects ancillary products to appear. "We'll be moving up the food chain with products for component assembly, Java-Beans management and library facilities," he says.

Successful Java IDEs will be those that play nicely with other products and platforms, says Mansour Safai, vice president of the Internet Tools Division at Symantec, which produces one of the most popular Java IDEs in its Visual Cafe line. "Customers constructing mission-critical applications typically are using two to five other tool sets," he says.

Short of a shakeout, but nevertheless a trend, is how Java IDEs are already associated with server deployment platforms.

Take last year's moves by Borland International Inc. and Netscape Communications. Borland acquired CORBA middleware supplier Visigenic Software Inc. with a plan to release an application se rver that's easily accessible from Borland's development tools later this year. Netscape picked up application server pioneer Kiva, and is now working on integrating Kiva's server with its own SuiteSpot server line.

Some of the most compelling solutions are coming from the database vendors. Oracle has its Application Server, Sybase Inc. has its Jaguar CTS, and Microsoft has its Microsoft Transaction Server. All have development tools and server database products to go along with these deployment environments.

It's a fact of life that rarely do users wander outside these vendor-specific solutions. Although the presence of the Java standard and supporting tools ought to mean customers will mix and match systems, few are doing so.

One way to understand these systems is to think of them as "silos" that each contain these ingredients: A Java IDE, an application server, JavaBeans components, a database and consulting services.

"The reality is that if a customer buys components from different vend ors, the onus is on the customer to make them work together," says John Senor, vice president and general manager at the Enterprise Access Division of Information Builders Inc. (IBI).

Asked if the IDEs will interoperate in the future, Senor is guardedly optimistic.

"Yes, there will be a set of common Java capabilities, but this will only be an entry point," he says. "Customers will pick Oracle's or ours or Microsoft's because of the extensions."

A case in point: IBI implements the Java Database Connection interface, but tweaks it to return aggregated column values-something the plain-vanilla JDBC does not do.

In another example of standards-plus-optimization, IBI introduced a Java-based Object Request Broker called Enterprise Component Broker that works with IBI's own EDA middleware. This offers a way for JavaBeans to interact with all the connections offered by EDA, which include more than 70 database and file structures.

But there are also pure-play Java servers sans IDEs. WebLogi c Inc.'s Tengah server, the first commercial Java app server based on Java industry standards, now boasts more than 600 customers. Instead of producing its own IDE, WebLogic integrates with other vendors' tools.

Yet the "silo" customers predominate. A good example is $4.9 billion pet-food giant Ralston Purina Co., which rewrote the client-side of its homegrown scheduling application in Java late last year.

"We are getting around platform-specific code on the client," says Mary Patterson, director of manufacturing execution systems at Ralston Purina, about the benefit of the new approach. She says IBM's tool was picked because the company was already using IBM's C++ tool.

Java Front-Ends

The system uses Java clients as the front-end for a manufacturing execution system across a dozen plants at the company. A combination of shop-floor stations-both Windows NT and IBM OS/2-are used as access points. To complete the puzzle, Ralston Purina replaced an existing messaging middleware system with IBM's MQSeries.

The application, which rolled out in 150 days, was built with IBM's VisualAge for Java. IBM was a prime integrator on the project.

Analyst Rymer thinks there may be at least one innocent reason for the silos: A shortage of Java programmers. "People are being locked into these, in the short term, because few organizations have the skill to pull together a best-of-breed solution," he says.

Meanwhile, C-bridge Internet Solutions' Bodkin says a Java IDE is no replacement for an intelligent application design.

"No tool is going to help you if you have a badly managed organization without discipline and good procedures," Bodkin says.

So, if you want to jam with the Java crowd, step one is to get your programmers familiar with object-oriented technologies and the evolving Java standards.

But that's the easy part. If you get that far, appoint a team to review how your company could effectively deploy a distributed Java app. Whatever you do, make sure your people st udy the businesses process. Too many companies may be building Java apps that won't scale well or precisely fit into existing business applications.

Remember, as good as this technology is, you'll have to make the business case. Once you do, you'll be up on the bandstand with your fellow Java programmers.