Get ready, because soon the big knock will be at your door and your boss will be standing there with a single question for you: Should we go with .NET or J2EE for our Web services?

Know a couple of things right off the bat. Big bucks will ride on your answer because, whichever direction your company takes, investment in a Web services platform will represent a substantial IT budget commitment. The other fact is that - smile as you might at what seems the improbable pairing of your boss with a cutting-edge technology question - both Microsoft (with .NET) and the Java community (Sun, Oracle, BEA, and others that have focused on J2EE) are flexing their muscles in a massive publicity campaign that is geared towards prodding high-level corporate executives into making commitments on one side or the other. Get ready because he or she will be pounding at your door soon, mainly because their boss probably will be prodding them for insights into the .NET vs. J2EE streetfight.

Higher-up executives will be keenly watching this decision-making process because they have picked up the buzz that the choice made here may fundamentally shape the enterprise's direction in the coming years. Listen to what Eric Rudder, a Microsoft senior vice president for developer and platform evangelism, said in an interview at Microsoft's Professional Developers Conference in October: "For companies, .NET and the world of XML Web services offer the opportunity to transform the way they do business." That's a mouthful because Rudder is saying this isn't simply an IT bet; it's a wager on how the enterprise should do business. And know that Java evangelists say much the same about J2EE - which means this decision is one that may put business' future on the line.

The fight intensifies because while both .NET and J2EE will get Web services managers where they need to go, there are huge differences between the solutions that, probably, will make one or the other ideal for a given organization. This dust-up isn't about cosmetics; it's about fundamental technological and business practices because J2EE and .NET are wildly different platforms. Where are the differences?

Making the Choice

Hold on for the answers but recognize at the starting point that the cautious choice for most Web services managers right now is to go with J2EE - if, that is, you want to run with the crowd. Analysts project a big lead for J2EE in enterprise installations throughout 2002, in part because J2EE comes into this race with a multi-year lead in deployments. .NET may be from Microsoft but it's the new kid on the block and, entering Q4 2001, it was still in beta, with no firm dates set for full release. Put those factors together and it's not surprising that Randy Heffner, a vice president at Giga Information Group, says that J2EE probably has a "3 to 1 lead" over .NET inside of the enterprise. Looking ahead, Heffner definitely sees .NET closing that gap ("Microsoft continues to make notable improvements in .NET," says Heffner) but at this moment in time the emphatic leader in large-scale organizations is J2EE by a landslide. Adds John Magee, senior director of Oracle 9i: "J2EE is running 3 to 1 ahead of .NET. inside enterprise."

David Bernstein, CTO of enterprise apps developer Chordiant Software, says much the same: "Not one customer has asked us about .NET. We are neutral on this. If a customer asked for .NET, we'd have no problem with the request. But nobody is asking." Should these votes nudge you into the J2EE camp? Not so fast. Microsoft can never be counted out of any fight so quickly and, for sure, the noise from top executives in Redmond, WA, is that Microsoft is staking a big chunk of the company's future on its .NET initiative. In an interview at that October PDC, Bob Muglia, group vice president of the .NET services group, said, ".NET is Microsoft's platform for XML Web services. It is the foundation for the next generation of software." The unmistakable message is that Microsoft is determined to bring .NET up to parity with J2EE in terms of features, performance, and installed base. Then, too, when the Redmond behemoth stakes out a position, smart Web services professionals sit up and take notice. "Microsoft is Microsoft. They will be there in this fight," says Pete Conner, a CTP at IT consultancy Primitive Logic.

Chew on this too: "The reality is that both .NET and J2EE will get users," says Jack Walicki, general manager of HP Web Services Operation and J2EE systems integrator. "It's no leap of faith to envision a company building services on both platforms." Even so, Walicki acknowledges that most businesses probably will standardize on either .NET or J2EE (HP, he says, uses J2EE "because that's the tool we were given"). To make this choice shrewdly, Walicki urges, "The key is to start by understanding what you've done so far, what technologies are you now using, and what do you want to accomplish with a Web services platform?"

"With our customers," he adds, "we don't start by telling them what to do or which to pick. We begin by asking them questions, to figure out where they are and where they want to get to. That's how the best choices will emerge."

A big issue, say the consultants, is that an enterprise that is already running plenty of UNIX or LINUX boxes and has attained a level of comfort with Java, probably will tilt towards J2EE. It's a proven tool for extending legacy systems and applications into Web services. Conversely, a business that is Microsoft-centric - particularly one that's looking to extend the desktop into Web services - probably will want to give .NET a hard look. Are these rules of thumb decisive? Hardly; they're starting points for arriving at a decision, say the analysts, and a lot more investigation needs to be done before any significant enterprise reaches a standardization decision.

Sound off for .NET

Just how do J2EE and .NET differ? J2EE, for instance, is a standard supported by upwards of 18 heavyweight IT players (BEA, IBM, Borland, Sun, Oracle, HP, and many others sell tool sets for implementing J2EE). .NET, by contrast, is a product (it's not yet shrink-wrapped but soon may be) that comes from a sole vendor, Microsoft, and support from major IT players is slender. There's a plus for .NET here, however; implementation will soon likely be as easy as making one call to Microsoft, whereas a J2EE implementation typically involves buying tools from multiple vendors and patching them together. Multi-vendor J2EE solutions are rarely elegant, are never plug and play, and patching them together into viable, working solutions usually isn't quick or easy. Forrester Research, for instance, reports (in "Putting J2EE To Work"), that "22 of the 50 technology decision-makers we surveyed said their J2EE projects took longer than planned, and 23 reported that their projects ran over budget." Simply put, a J2EE implementation is complex.

That's a common woe raised by independent developers.

Another plus for .NET is that time to market with applications generally will be faster than with J2EE because .NET includes an innovative "ASP.NET" feature that allows user interfaces to be put into different formats with a few mouse clicks and no rewriting of code. Ease of use is a core .NET goal. At the October PDC, for instance, Microsoft chairman Bill Gates, in a dramatic demonstration of .NET capabilities, used ASP.NET to build a Web service, then tested it, created a Windows front-end for it, and deployed it, all inside of 15 minutes.

A third plus for .NET: There are significant performance advantages over J2EE (which remains slow in its execution). Page load times are blisteringly fast say .NET advocates, and even J2EE fans admit that a speed-up in Java's performance is sorely desired. "A J2EE sore spot is performance; it's not where it needs to be," says Steve Baker, program manager for GraphON Corporation, a developer of Web infrastructure software.

Jumping Java Beans

Good as the pro-.NET arguments sound, the arguments in favor of J2EE are equally numerous. A key, says Frank Slootman, VP of product solutions at Borland, is that J2EE has been around for a half-dozen years, it's stable, proven technology that is supported by multiple vendors and, therefore, there is no vendor lock-in. For users, this means they can shop around, solicit bids from various vendors, kick a lot of tires, and keep hunting until exactly the right vendor and solution emerge. Java, adds Sun's Ralph Galantine, a J2EE marketing manager, is "supported by a community - that's a core strength." As the platform evolves, community members all get to put their two cents in and, says Galantine, that produces a smooth development process.

Other J2EE strengths include:

• Java is scalable, says Giga's Heffner. The high-end of .NET deployments remains to be seen, but already some of the world's biggest businesses are successfully running J2EE. It's a platform that's been proven to scale to handle demand. .NET's real-world scalability is unknown.
• Java is portable, adds Heffner, and while the "write once, run everywhere" mantra may have been oversold by the early Java advocates (apps written to run on mini-computers likely won't work on mobile phones), there nonetheless is a tangible portability to all Java apps that has yet to be demonstrated with .NET. Microsoft executives talk about easily moving apps from workstations to Win CE handhelds to cell phones, but little evidence of this has been seen in the field.

J2EE is designed, from the ground up, to afford extremely high levels of security and the industry is in wide agreement that J2EE succeeds. Microsoft, meantime, has offered assurances that .NET will deliver iron-clad security but even so, says Baker, "security has to be a question mark with Microsoft." Hackers and virus writers, of course, have had field days with various Microsoft products and while that's not a conclusive indictment (they've probably put more effort into cracking Microsoft products), it's cause for pause before jumping into a full-fledged .NET implementation before the full security story is known and thoroughly tested.

But a still larger question mark looms: Will .NET offer cross-platform compatibility? Microsoft, again, assures that compatibilities will be wide, but so far .NET stacks up entirely as a Windows application, while J2EE can be tweaked to run on many operating systems ("including Windows! We really are platform independent," says Sun product manager George Grigoryev). For smaller businesses, with limited IT resources, this may not be a tipping point in the decision process, but for sprawling businesses with diverse IT capabilities, J2EE has OS flexibility. "Java is OS agnostic - that's proven," says Oracle's Magee.

Placing Your Bet

So, which will it be for you? Understand that one way to go badly wrong with this decision is to get sucked into what sometimes seems almost a religious war between the Java, open-source crowd on one side and Microsoft on the other. At day's end, this choice ought to be made not on the basis of religious belief but because the option you pick will work best for your enterprise.

But take heart in this reality: A "final" answer may not be final after all. "Connectivity between .NET and J2EE ought to be possible with XML," elaborates HP's Walicki, "because there is no Microsoft XML or Sun XML, there is only XML." Plainly put, even once decisions are made, Walicki is saying that, technically speaking, ways to bridge the .NET-J2EE divide likely will emerge. So a company that places an initial bet on, say, .NET may later be able to hedge it with a side wager on J2EE.

How safe is that wager? Plenty of uncertainties need to be resolved before the interoperability of .NET with J2EE can be pronounced as a fact - but encouraging news for any Web services developer is that Web services themselves may prove to be the way out of the .NET-J2EE divide. At least that's the opinion of Annrai O'Toole, a cofounder of Irish middleware company IONA who now serves as executive chairman of Cape Clear, a Web services developer. He explains, "Web services offers the industry a solution to the bickering that has created 20 years of IT incompatibility." How? O'Toole goes on, "The arrival of widely accepted standards such as XML provides a common base platform that supersedes religious arguments over operating systems, languages, tools, and applications. Web services prepares the ground for a new era of cooperation, if you will: a third way."

"Web services," adds Conner, "has a huge future" - and a big slice of that future probably will be in creating ways for J2EE and .NET to interact and exchange information. Go ahead, tell your boss that. In other words, now is definitely the time to begin a sizable Web services commitment in order to deal with the fallout of the J2EE-.NET dust-up.