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]
About the Author
Brian Robinson is a freelance writer based in Portland, Ore.