Java comes together

• By Brian Robinson
• May 15, 2000

As government moves inexorably into the distributed computing era, two methods have found favor for tying new and legacy applications into a single enterprise environment: the Common Object Request Broker Architecture (CORBA) and, more recently, Enterprise JavaBeans.

Some people are confidently labeling the latest entry, Enterprise Edition of Java 2 (J2EE), as the core platform for all future enterprise application development, even though few products supporting the standard have been shipped. From a technical standpoint, J2EE holds great promise, but squabbles between two of its principal backers could hinder market acceptance (see "Vendors bicker about control").

J2EE is the equivalent of an application server standard. It lets agency developers assemble applications using their own J2EE components and commercially available components — a boon for productivity.

If developers stay true to the standard, the applications they build will run on a variety of platforms, which means you won't need to pay expensive specialists to tailor applications to every platform your agency runs.

"Other things being equal, the productivity gains by using J2EE are compelling," said George Haley, managing principal with Strategic Technology Resources, a high-tech consulting and integration company in Chicago. "Using J2EE instead of, for example, CORBA with C++ can easily result in design and implementation cost and schedule reductions in excess of 50 percent."

A major benefit of J2EE is that it includes several core software capabilities that developers working in other environments would have to create by assembling products from different vendors.

J2EE-compliant applications can be linked via application-programming interfaces to a host of standard Java services, including Enterprise JavaBeans, the Java Interface Definition Language, Java Database Connectivity, Java Message Service, Java Transaction API and Java Transaction Service.

Importantly, J2EE also includes RMI-IIOP, a combination of the Java Remote Method Invocation and the Internet InterORB Protocol. IIOP is a communication method that all Object Request Brokers (ORBs) that are compliant with the popular CORBA use to interact with each other.

RMI is a way for both Java applets, which run on the user's Web browser, and servlets, which run on the Web server, to speak to each other and invoke each other's methods. Until now, Java hasn't been able to speak to other distributed objects, particularly CORBA ORBs.

RMI-IIOP is essential because it provides the full cross-platform functionality that Java itself could not supply.

Standards to Live By

In World Wide Web development, there's been a lot of debate over developers having to be "locked in" to specific vendor solutions. "That's been true even with CORBA, because each vendor's CORBA implementation is different," said Scott Dietzen, chief technology officer for e-commerce in the server division of BEA Systems Inc., San Francisco, Calif. "About 18 months ago, there were some 40 application development vendors and close to 40 different programming models."

BEA and others were determined that wouldn't happen with Java, Dietzen said, which is why his company hooked up with Sun Microsystems Inc. and IBM Corp. initially to start the J2EE effort. Now, he said, developers "only have to learn this stuff once, and it works across all other J2EE products."

That's actually a major driver for the adoption of J2EE all by itself, according to Rob Veitch, director of business development for Sybase Inc., Emeryville, Calif., because one of the biggest blocks to dissemination of enterprise application architectures is that "you can't hire the people to develop them."

"The consultant we work with on these situations has a nine-month jobs pipeline and charges double the usual fee," Veitch said. "Having a standardized development environment means we can train more people who will know how to manipulate it."

It also can substantially reduce the time and aggravation of development. Jeff Nelms is the technology architect at American Management Systems Inc. for the next-generation version of the Defense Department's Standard Procurement System. The previous version was developed using Sybase's PowerBuilder, but this time around the system will be ported to Java.

"J2EE provides a very nice platform to do this on," Nelms said. "I've done many systems using C++ in the past where I've had to manage the database transactions myself, and that's a very tedious and time-consuming business. With J2EE, all I have to do is set up the transactional semantics in a module, and the transactions are handled automatically."

Limiting Factors

Those transactional abilities, and such features as flexible database connectivity and built-in security, make J2EE a very good product even in its first generation, said David Lutz, principal scientist for Mitre Corp.'s Composable Software and Architectures Group, which is supporting various agencies in their development using CORBA and distributed objects. It's added the fundamental elements needed to apply Java at the enterprise level, he said.

Nonetheless, if there are any doubts that would creep into the minds of agency personnel, they might be inspired by the question of security, Lutz said, "which people feel there can always be more of. Java has its own security, but CORBA has a much more sophisticated approach." If there is any reluctance to accept J2EE immediately, it might be over uncertainties such as this rather than any obvious deficiencies in J2EE itself.

Another possibly limiting factor comes from the fact that there are so many legacy systems out there, according to Walker White, chief technologist for Oracle Service Industries, a part of Oracle's government group.

"Java can't be everything to all of the environments that people want to work with," he said. "There may be some other technology that can be used as the core of these solutions, with Java as a "ring' around the outside of that core."

But he believes that Java, in some form, always will be a part of the development environments of the future. Hence, he said, there will always be a need, in some way, for J2EE.

— Robinson is a freelance journalist based in Portland, Ore. He can be reached at [email protected]