InformationWeek: The Business Value of Technology

t's been a little more than a year since Sun Microsystems released Java 2 Enterprise Edition (J2EE), its comprehensive Java platform for enterprise-scale development.

Java 2 Enterprise Edition isn't a single product. It's a series of specifications that vendors use to build products, most notably application servers. Sun finally realized the whole of Java was greater than the sum of its parts, so it started to bundle and integrate its Java products into a coherent platform, J2EE.

The J2EE-based application servers are far more than just the Java Development Kit (JDK) with a few add-ons. They're whole platforms for enterprisewide development and deployment, with services that offer networking, high performance, and high availability, as well as a variety of connectivity technologies for data access.

The features include Enterprise JavaBeans (EJBs); Corba; XML messaging; Java Server Pages (JSP), Sun's answer to Microsoft's Active Server Pages for displaying dynamic data in a Web browser; Java Servlets; Java Naming and Directory Interface (JNDI) to access directory services; Java Database Connectivity (JDBC); and Java Message Service (JMS) for asynchronous messaging.

There's no question about it--Java 2 Enterprise Edition is complex. To be certified as J2EE-compliant, an application server must pass a battery of 13,000 validation tests. For that reason, J2EE-compliant application servers are only now hitting the market, and just a handful are available. They include BEA WebLogic Server from BEA Systems Inc., Total-e-Server from Bluestone Software Inc., WebSphere from IBM, and iPlanet Application Server from iPlanet E-Commerce Solutions.

Rapid Acceptance
Now that the application servers are rolling out, J2EE is rapidly becoming the middleware of choice, according to analysts. "J2EE is the standard for application-server middleware today," says Daryl Plummer, group VP for Internet and E-business technologies at Gartner. "If you don't have J2EE compliance, you'd better be Microsoft; if you're not Microsoft, you better get J2EE compliance real quick."

J2EE's success is coming at the expense of Corba and proprietary Remote Procedure Call-based servers. "There was a huge swing to Corba a few years ago, but [companies] aren't using it now," says Anand Raman, manager of business development for Impetus Computing Systems Inc., a consulting and development firm in Milpitas, Calif.

Fueling the J2EE momentum is the acceptance of Java and the fact that developers know their code will work on any platform once an application server is certified as J2EE-compliant. And, of course, there's the cost savings that comes with Java's "train once, deploy anywhere" option, says Rick Saletta, market team leader for J2EE at Sun in Cupertino, Calif. "The really sharp companies see that J2EE is the fastest and least expensive way to deploy solutions on the market."

It's this cross-platform compatibility that Sun wanted, and what keeps application server vendors on their toes, Saletta says. If IBM or BEA falls behind, a customer can jump to SilverStream Software Inc. and know that his Java code will run on that server. "If you're not satisfied with the quality of the product being delivered to you, you can change vendors," he says. "That's a freedom enterprises want, because they don't know where the Web will take them in the next few years."

Playing Well With Others
IT departments also have the freedom to mix and match services for complex systems, because J2EE compliance ensures interoperability. Before Java 2 Enterprise Edition, integrating message brokers, directory services, database access, and an application server from different vendors meant writing a lot of code to tie them all together.

EncrypTix Inc., a provider of secure document-delivery services over the Internet and wireless devices, chose multiple vendors to power its services. The bulk of them run on BEA's WebLogic, but some, such as directory services and messaging, are handled by other vendors' products.

"I did not want BEA to be the only vendor we had here, running our business on one vendor's package," says Jack Archer, lead architect with the El Segundo, Calif., company. The main reason EncrypTix chose to mix and match was so it could scale up each service. No single vendor could offer the best performance for every aspect of the J2EE spec.

"The cost of multiple products is slightly higher, but in the end, because of the scalability, it allowed us more flexibility with our hardware purchases," Archer says. "The end result, with long-term costs, was the same--if not cheaper. It didn't hurt to have multiple vendors bidding over things."

Still In The Early Stages
Demand for J2EE products and services is only starting to pick up. Gartner expects the market for application servers and J2EE-related tools to grow to $1 billion this year. But currently, the market is growing slowly because of a shortage of tools vendors. Most of the tools on the market have been incorporated into an integrated development environment, which means they're sold with an application server, Plummer says. SilverStream, Bluestone, IBM, and BEA all provide their own tools with their server.

So far, the level of J2EE deployment is basic. Most companies are using Java applets and Java Server Pages, not more advanced functions such as Java messaging and Enterprise JavaBeans. There are three reasons for this, according to Plummer. First, JSPs are simpler, so more people can build them. Second, many companies have a learning curve to address with EJB and J2EE. Finally, says Plummer, "about 80% of programming jobs don't require a lot of complexity. They don't need distributed transactions, for example, so they are in a realm where JSP can do the job quite well."

Enterprise JavaBeans, in particular, have a steep learning curve. "We're definitely starting to use EJBs, although I will profess I don't know what EJBs are--but I'm trying," says Jim Miller, chief technology officer of Creditex, an online credit portal serving financial institutions in New York. "From my understanding of EJBs, it makes sense to use them and we will eventually. It's definitely true that we haven't had the need to do a lot of complicated things using EJBs."

LevelSeas, a business-to-business service provider supporting companies that ship via cargo ships, is content to keep things simple. "My opinion on software engineering is we have to deliver the products our customers want in the shortest time possible," says Mark Sear, CTO for the London company. "I think our industry suffers from grotesque overengineering at times."

But Impetus' Raman reports some interest in EJB-based applications, especially in the insurance and financial-services markets. For mission-critical or high-performance applications, JSP servlets don't offer enough scalability, security, and distributed computing capabilities. "If I'm developing a small Web site, yes, a JSP servlet will do. But not for an enterprise-scale application," Raman says.

However, creating a small-scale JSP servlet and then rewriting it as an EJB later, when more computing power is needed, would cost too much time and money. "Some people would rather do the heavy work now," Raman says. "You might not scale it to an extent where it would take care of 500,000 users immediately. But to write something to take care of 50,000 or 75,000 and then redo it in the future to enable clustering and load balancing--that's a major effort."

To make deployment easier, Sun has introduced a technology called Java Web Start (see sidebar), which automatically puts Java applications, not applets, on a client computer. Every time the application is run, the Java Web Start checks back to the deployment server for updates. If the updates are found, Java Web Start automatically downloads and installs the updated code.

But perhaps even more important than the new product is the rollout of a Java release schedule that actually makes sense. "A year ago, there was one [Java] spec coming out this week, another spec coming out next week, and a third coming out a month later. No one could build an app server without revving it every three week," says Arnold Epstein, CTO for SilverStream. "Now, they don't release those individual specs off cycle. They think about how [the specs] work together and move them forward together."

The new release schedule is a sign that people want the APIs as a whole, not just individually, Archer says. "There was the undercurrent that we were starting to use the specs on an integrated basis," he says. "It's a sign of maturity that people were using these together. It means someone has looked at it from an integrated point of view. If I'm using them all at once and get an integrated release and get a feeling that they were put together as a group, I'd feel a whole lot better."

Talent Pool Is A Puddle
LevelSeas' Sear also says the company is more or less forced to go slow with advanced Java features because the talent pool for Enterprise JavaBean programmers is "as dry as the desert." "An awful lot of people badge themselves as J2EE consultants," Sear says. "What they mean is they've used Java on an app server, and that's a different thing altogether."

Gartner's Plummer agrees. "There hasn't been a lot of growth in the consulting services because the skills are not easy to find," he says. "When you get into the tough part [of Java programming], like component clustering, they don't have the skills."

"We are having a heck of a time finding qualified J2EE personnel," Archer says. "If we find someone who has looked at a J2EE spec, it's unusual." Many of the applicants who come in to EncrypTix are self-taught. They know the basics of Java, but not J2EE or advanced features such as EJB.

But Archer is patient, because J2EE is still new. "Java itself is mature, but J2EE is not," he says. "I don't think you can blame Sun. They're doing the best they can, considering it's not a cash cow for them."

Sun Gets High Marks
For some time, the Java community was almost rebelling against Sun's control over the Java specification, demanding that the company turn over Java to a standards body such as the International Standards Organization. In summer 1999, Sun backed off its plan to resubmit Java to the European Computer Manufacturer's Association, causing some open-source evangelists to raise the roof, threatening to create their own open-source Java. But nothing came of it.

A year later, Sun introduced Java Community Process 2.0, a committee for managing the development of the Java spec. The Java Community Process includes major technology vendors, such as IBM, Compaq, Fujitsu, BEA Systems, Hewlett-Packard, WebGain, Bluestone, and Computer Associates.

Sun has given up veto power and total control over the Java spec. Now, a two-thirds majority of the executive committee must vote to make changes to the Java language, virtual machine, or infrastructure of the platforms.

"The Java Community Process has changed development significantly," says SilverStream's Epstein. "What used to happen is a bunch of guys at Sun and a few friends at other companies talked about problems and wrote a spec as best they could. Now we have a process where every integral vendor can talk about the shortcomings they see and everyone can work together to address the spec and move it forward."

Archer has been involved in other middleware and distributed application standards efforts, including the ill-fated Corba and Distributed Computing Environment. But he thinks Sun got it just right.

Distributed Computing Environment was too strict, says Archer, which didn't allow for enough competitive differentiation between vendor implementations. And Corba was too loose. For example, an object-request broker from Iona Technologies can't communicate with one from BEA. "Sun appears to try to split the difference," Archer says. "You can't make vendors all do the same thing. At the same time, you can't let people walk off and do whatever they want. Sun has encouraged reference implementations, but they don't use them as a hammer against vendors."

Sear thinks it's just as well that Java remains in the hands of a company with a financial investment. "The problem with standards bodies is that, without any form of commercial directive, standards bodies go nowhere," he says. "There has to be a financial incentive."

Future Direction
On Jan. 16, Sun unveiled the beta program for J2EE 1.3, which will have two notable changes: further XML integration to support enterprise application integration and XML services such as Universal Description, Discovery, and Integration (UDDI) and connectors to enterprise apps such as SAP R/3, PeopleSoft, and Baan. J2EE 1.3 will be available later in the year.

XML support has been well-received. "J2EE has to add more features and support for loosely coupled systems," Plummer says. "The future is loosely coupled, outside and across the firewall. It needs asynchronous messaging, XML-based package transport, and interfaces for external registries like UDDI."

"I think the main thing is to make sure Java and XML continue to operate more as a team," Sear says. "That interoperability will be more important to me. I want all of my components written to spew out XML."