Server-Side Java Takes Off

Welcome Guest. | Log In| Register | Membership Benefits

March 30, 1998

Server-Side Java Takes Off

Platform helps users link IS to real-world business needs

By Rich Levin

here's no disputing Java's growing popularity as a server-side development platform. IS shops nationwide are moving to build portable server-side Java solutions that bridge heterogeneous platforms, breathe new life into legacy systems, and bind information systems more tightly to real-world business requirements.

In the process, IS managers say their programming teams are gaining shorter developm ent cycles and smoother rollouts of new and updated applications. Server-side Java development is also freeing organizations from proprietary vendor implementations of traditional server-side technologies such as C/C++, Cobol, and Report Program Generator (RPG).

"People are moving Java to the server because it's so similar to C++," says Anne Thomas, distributed object computing analyst with the Patricia Seybold Group in Boston. "Java's automatic memory and easier thread management means programmers can create applications faster, and the programs have fewer bugs. That makes Java an excellent language for building server applications and components."

Even Microsoft, once Java's detractor, has joined the stampede toward server-side Java. This month, the company introduced an overhauled version of its Visual J++ development tool that's completely focused on building Windows-centric, server-side Java applications.

`The Place To Play'
"Clearly, the server is the place for Jav a to play, and we think it's a great language to write server-side functionality in," says Jon Roskill, Microsoft's group product manager for visual-development tools.

But development teams barreling down the road to server-side Java can hit a few bumps along the way. Early adopters of large-scale solutions are confronting technical, performance, and hardware capacity issues that have stalled some efforts and complicated others.

The first hurdle: Choosing a server-side Java-development strategy from the confusing array of competing APIs, middleware, and architectural approaches. Some shops are building monolithic server applications, replacing C++ code with Java. Others are using Java database and servlet APIs, distributed objects over RMI (remote method invocation), or Corba architectures to provide system services.

Still others are using proprietary application servers or early prototype implementations of Enterprise JavaBeans, JavaSoft's emerging server-side component model. The confusion is compounded by mixed messages from officials of Sun Microsystems' JavaSoft business unit, caretakers of the Java spec, who admit that the proliferation of various server-side Java technologies has stupefied developers.

"Java is being used on servers in a lot of different ways," says Jim Mitchell, JavaSoft's VP of architecture and technology in Palo Alto, Calif. "When I talk to customers, there's some confusion when to use straight code, when to use servlets, when to use beans or Enterprise JavaBeans. We need to make that message absolutely clear."

Blazing Trails
Programmers at Nike Inc., the $9 billion sporting goods manufacturer in Beaverton, Ore., are moving many of the company's legacy two-tier applications off the mainframe and on to distributed server-side Java applications. But the reengineered apps still have to live within the same patchwork quilt of operating systems and hardware platforms their mainframe and client-server predecessors brought about.

Unfortunately, native server-side Java technologies, such as servlets and RMI, weren't designed to easily bridge cross-language borders. For that, Nike dispensed with Java's native server-side technologies and went instead with the Object Management Group's Corba, a distributed object framework. For server-side Java application services, Nike chose the Gemstone/J application server, from Gemstone Systems Inc. in Beaverton, Ore.

"If you have five or six major application components that span different machines or systems, there's no way you can glue them together using servlets, RMI, or just plain Java on the server," says Paul Woeltje, Nike's senior manager of distributed application services. "That's a myth."

Nike had to implement a number of quick fixes, such as pushing batches of data back and forth between different applications. "Here we're getting off the mainframe because it's batch-oriented, and we're creating brand-new batch systems on this modern technology, because we don't have any better way to do it," Woeltje says.

Bean Power
A better way may be just around the corner. Sun's first complete Enterprise JavaBeans (EJB) specification was unveiled March 23 and represents JavaSoft's officially sanctioned approach to building server-side Java apps. Java components are dispatched to the EJB "executive," a run-time container that automatically gains the scalability and enterprise-oriented attributes that client components don't require. These attributes include transaction monitoring, concurrency control, and distributed security services.

"With EJB, we don't have to put the transaction, security, and life-cycle management of server components into our code," says Wayne Brazille, system architect with the Radiance Group Inc. in Boulder, Colo., an early user of prototype EJB tools, such as the Tengha application server from WebLogic Inc. in San Francisco. "It lets us focus on the business logic and the database access, as opposed to all these server-side servic es that we would have to buy or build," he says.

Enterprise JavaBeans 1.0 should kick-start a flood of development tools and application servers that support the newborn component specification. One plus: built-in support for Corba interoperability, which JavaSoft officials say could be a boon for IS shops looking to migrate, componentize, and port server-side business logic.

"We want to go down the Enterprise JavaBeans path, ultimately," says Mike Anderson, director of IS for $20 billion home-center retailer Home Depot Inc. in Atlanta, and an aggressive, early adopter of Java technologies. "We were a little ahead of the curve, and we standardized on our own server-side Java implementation. But we're looking at doing future development under the EJB model," he says.

In December, Home Depot signed a 10-year license with startup Novera Software Inc., a Burlington, Mass., developer of Epic, one of the earliest server-side Java development platforms.

But as Home Depot's IS dev elopment team found out, there's not much in the way of a formal server-side infrastructure for Java. Enterprise JavaBeans potentially solves some of the outstanding issues, such as transaction monitoring, but many server-side enterprise requirements will remain outside the realm of formal JavaSoft APIs for months, even years to come.

The alternatives: Build or rebuild entire infrastructures manually, or find third-party middleware or application servers that deliver the necessary server-side services that distributed enterprise systems can't run without. That's where comprehensive enterprise Java development platforms, such as Novera's Epic, come into play.

"We're using Novera as our server-side Java foundation, because the formal Java services are mostly just specs at this point," Home Depot's Anderson says. "This makes it easy for our developers to build quickly, because they don't have to rebuild the same infrastructure layers, like error handling and trapping, messaging, stack traces, u ser logons, security, and authorization. That should be hidden, so they can just focus on business logic. EJB doesn't solve any of that."

Buy Vs. Build
Early adopters of enterprise Java technology are moving forward and not waiting for the ink to dry on industry specifications. "We're more focused on technologies we can use and abuse today, as opposed to what is essentially specware from Sun, such as Enterprise JavaBeans," says Sanjeev Datta, director of Internet technology at Fidelity Investments Institutional Services Inc. in Boston. "Then again, Corba components suffer from the specware problem, too. If we had a real choice, we would rather go in a pure Java environment using RMI to talk to our back-end servers, but that's just not the reality."

At Harvard University in Cambridge, Mass., developers are migrating a centralized Unix application over to a modern distributed architecture, using server-side Java for application logic, and Corba objects for distributed communicatio ns.

The current host system, built in the late 1970s, consists of 300,000 lines of C code, and a whopping 4,000 function points. Ancient as it may appear, the old software remained one of the university's primary information systems, affecting about 40% of the university population in areas such as faculty and student records; transcripts; and grades.

But the old workhorse needed to be put out to pasture for a variety of reasons. While it still capably handles the basic transactional requirements of the institution, it was never intended to meet modern online analytical processing requirements, and it can't support broad-based access over the Web.

The new system was rolled out this month, after a 15-month development effort, says Ken Ledeen, CEO of Nevo Technologies Inc. in Cambridge, Mass.; Nevo was brought in to migrate Harvard's legacy system to a server-side Java solution. The server-side Java app was built using IBM's VisualAge for Java and Visigenic's Corba object request bro ker, and runs on Microsoft's Windows NT.

Server-Side Drawbacks
Ledeen's team learned firsthand that, while server-side Java and Corba objects make it easy to rapidly build distributed systems that offer broad user reach while leveraging legacy data, both lack many fundamental server-side notions demanded by enterprise systems.

"We had to build our own transaction-processing middleware," Ledeen says. "It's not as robust as something like BEA Systems' Tuxedo, but we needed a way of managing transactions. Java and Corba don't understand the notion of a session or transaction. That's in the specs, but nobody has implemented them yet. So we had to do a lot of the low-level work."

While the extra work may have added to the development load, the results speak for themselves. Now, any user can directly manage data simply by pointing a Web browser to a URL. There, a server-side Java application provides them with the tools to edit the data. "Harvard isn't really known for high-te ch, but they will be soon," laughs Ledeen.

Even though growing numbers of large IT shops are lauding the benefits of Java on the server, experienced pioneers warn that the choice of development tools remains critical.

"There's a lot of PR-ware out there right now," says John Melka, senior engineer for NationsBanc Services Inc., in Chicago. "The products look great on paper but often aren't fully cooked," he says. "You've got to put the thermometer in and see how rare the tool is. I like my steak rare, but I like my software well-done."

See related story, " Custom Apps Favored Over Java ."

See related story, " Handle Heavy Scalability Loads ."

See the table " Server-Side Java Development Tools And Platforms " as a PDF file.