In-Depth

J2EE and .NET servers weigh in

• By Jack Vaughan
• May 1, 2003

The verbal punches tossed in the clash between Java and .NET may never end -- but for now it seems that the app servers supporting these software environments both have a place. Evidence suggests that most large companies will support both Java and .NET. The “battle,” in reality, falls short of the hype. The scene is almost like that in a heavyweight prizefight, where the weigh-in holds more terror than the fight itself.

The question facing corporate IT planners is where and when either of these application servers should be used. From some points of view, the scale measuring the two platforms is almost equal.

Issues that decide the day may be complexity of the application, performance required, availability of knowledgeable talent and, as always, programming style.

Pierre Fricke of D.H. Brown, Port Chester, N.Y., offers a shorthand view of how the two systems compare: “The J2EE platform is richer, the .NET platform is simpler.” There is room for both, he emphasized.

But the richness of J2EE Fricke describes comes at a cost. Richer capabilities mean J2EE can be a more difficult programming task than .NET. In this light, it is worth noting that recent moves by Java tools providers seek to address the issue by easing the jobs of J2EE designers and developers. Sun has targeted several popular J2EE-XML bindings for out-of-the box treatment and eased deployment. With its release of WebLogic Workshop last year, BEA clearly set the stage for a slew of simplified tags for J2EE. With views of its upcoming Domino tools, IBM has also disclosed some direction toward custom JSP tags that provide a more “wizard-like” design environment.

One quick way to simplify J2EE development, some observers note, is to use the simpler elements of the platform, skipping complex EJB component elements if possible.

The JBoss open-source server is finding use in some of these places. For many, a Tomcat Java servlet and page server handles most of their app server needs. By the same token, Microsoft’s ASP.NET may also fit a simple bill.

While J2EE advocates promote ease of use, Microsoft naturally claims it has addressed “richness-related” issues on its platform, pointing to architectural updates that .NET adds to previous Microsoft-distributed architectures, improved caching and effective coupling with the underlying OS.

Project, process and function

D.H. Brown’s Fricke says most large companies will support both application platforms. For the large concerns, he said, “the decision is made based on a project, process or functional area focus.” Meanwhile, smaller companies’ decisions will be driven by solution providers.

For ISVs, particularly, Fricke said, J2EE will continue to show favor because of its cross-platform traits. They cannot forgo going to Linux and Unix as well. “Even if the Unix base may be shrinking, Linux, in particular, is growing,” he said. Of course, J2EE on Windows is not unheard of, one might add. Most of these same ISVs will target the Windows OS; fewer, the .NET elements that ride above it.

“Where distinctions are drawn,” said Fricke, “is in the area of cross-platform support vs. multiple language support.” J2EE lists a number of supported operating systems to its credit, while .NET is firmly a Windows thing. Meanwhile, Fricke counts Java as the language of J2EE; and C#, C++, Visual Basic and Cobol as languages supporting .NET.

Style, or culture, is also at play here. The J2EE culture, according to Fricke, is more like that of mainframes and Unix, where some assembly is required. The .NET culture is more integrated, like that of AS/400 and NT, he said.

Timing is elastic in software, where vying technologies constantly leapfrog one another. This has given the .NET architecture benefits and drawbacks.

“.NET came later and had the advantage of being later,” said Fricke. Its creators were able to look at what J2EE creators had done. The accompanying drawback is that .NET is new, and developers and architects need to learn more about how it works in the wild.

And, said Fricke, .NET’s relative ease of development (with plentiful and useful program wizards) fades as large-scale, high-complexity applications are pursued. Those are, almost by definition, heterogeneous, and not a Microsoft strong suit. Also, “you can’t ‘wizard’ your way to a complex supply-chain app,” quipped Fricke, who added that “those advantages dissipate at that level.”

In sum, said Fricke, “if Java skills are scarce or not readily available, use .NET. If new applications are to be deployed on non-Windows [operating systems], use J2EE.”

The new OS?

Although app server distinctions may be overstated, the app server will continue to be an area of interest, especially as operating systems come to be seen more as commodity items. The advent of Linux has, in part, lent credence to this notion.

Fricke and others note that operating systems are no longer the primary application platform for modern apps. Behind the scenes, a general decline in OS influence may be occurring in the market.

At the annual IDC Directions confab held recently in Boston, Paul Mason, the Framingham, Mass.-based analyst firm’s group vice president for infrastructure software, enforced this idea. He said that by 2007, revenue for integration servers, application servers, Web servers and clustering software would combine to surpass server OS revenue.

This trend drives some packaging schemes that might not have been anticipated in the past. At the same time, it has moved to ease integration tasks of developers. Solaris and Java originator Sun Microsystems has formed combo packs of its SunONE server and Solaris OS. It is not lost on some that those tacks could come off Microsoft’s course chart.

Nor does it surprise many that .NET is now being described as more of an architecture and developer’s game. As long has been the case with Microsoft, the naming of products is a constantly moving target and, in the final rev, the debut .NET server ended up wearing the Windows moniker.

Stamford, Conn.-based Gartner analyst Yefim Natis counted J2EE’s strengths as including multivendor support, mature scalable implementations and a clear, formal architecture. .NET strengths, as he estimated them, included deep integration with the Windows OS, high productivity development and an easy combination of multiple programming languages.

Both J2EE and .NET approaches lag behind mainframe-based OLTP systems when it comes to supporting ultra-high transaction rates. Natis has suggested that projects targeted at 100 to 1,000 concurrent users are those where .NET and J2EE tend to compete.

Other rooms, other scales

Performance is just one issue facing those deciding between the two platforms. But it gains attention now and then. Both approaches have been criticized as being slow in their times, but Java has gained a reputation for adding performance as it has matured. Thus, the outcry was all the greater in the Java camp late last year when a benchmark produced by The Middleware Company, which compared Microsoft’s software to the J2EE platform, found Microsoft ahead. The benchmark was faulted by some, and its originator has worked subsequently with others to improve its usefulness as a measure.

The favorable result for Microsoft “took J2EE fans by surprise,” said Salil Deshpande, president, The Middleware Company, Austin, Texas. “They started poking holes at it and we encouraged that by hosting it on our Web site,” he said. Deshpande said administering the benchmark differently could have improved J2EE results. Now, working with a panel of experts, The Middleware Company is preparing a “case study” -- Deshpande would choose to skip the term “benchmark” -- that will be freely downloadable.

Still, he said, close performance results should not be surprising. “Each platform does mainly the same three kinds of I/O: front-end HTTP, interprocess communications and back-end DB calls.” Both platforms employ variations on virtual machine technology, so there is not a basic absolute bias to running on a “native” platform, he indicated. Vendors for both solutions also work hard to create the tightest code when they need to put the “pedal to the floor” for key functions.

Scalability is a distinct issue from performance, Deshpande said; but, he added, both platforms can scale well in the hands of good architects. “There is nothing inherent about the technology that prevents them from scaling well,” he said.

The role of skills is further emphasized. Said D.H. Brown’s Fricke: “You can produce good performing systems on both platforms.” Of course, the inverse proposition is also true.

This particular benchmark, while flawed, does offer a lesson, Ovum Analyst Gary Barnett wrote in “A nasty wake-up call for J2EE,” ADT, January 2003, http://www.adtmag.com/article.asp?id=7085: “It is an act of denial to pretend that .NET doesn’t pose an alternative to J2EE.” He indicated that J2EE fans cannot endlessly overlook its programmatic complexity, while touting its speed.

“J2EE must be simpler, and it must run faster. If it cannot meet these challenges, it will wither on the vine and a great chance to change IT will be squandered,” wrote Barnett.

Room for both

In a way, the advent of Web services, Service-Oriented Architectures and enterprise infrastructure buses has somewhat dimmed the bright light shining on the .NET–Java controversy. Many people hope objective discussions by thoughtful architects will replace heated discussions by application platform zealots, or at least that the arguments will move out of app servers and into Web services forums.

As a founder and key force behind early Java app server star NetDynamics, and now founder, chairman and CEO of Model N, a South San Francisco, Calif., maker of software for revenue execution apps, Zack Rinat has a unique perspective on these issues. “For the developer community and enterprises, J2EE and .NET are two important technologies that need to work in concert with each other,” he said.

“There’s actually room for both [platforms],” he added, “as long as the vendors pushing these technologies have the customer in mind, and are not embarking on a religious war.”

J2EE has at least a near-term advantage for integration tasks, but the divergence between the two platforms should not be oversold, said Gordon Van Huizen, vice president for product management at Sonic Software Corp., Bedford, Mass.

“Over time, they are becoming more and more comparable. Microsoft looked at the J2EE stack, added some deployment improvements and did some remarkably similar things,” he said.

For application development, with basic criteria, it will be “exceedingly difficult to tell the difference” between the platforms, Van Huizen said.

With reporting by Colleen Frye and Rich Seeley.

See the related stories “Java environment focuses on up-front modeling” and “Windows Server 2003 ships”, or click here to read an ADT Briefing Book on the latest releases from Microsoft.