"Down she came, 1,500 pounds of longhorn beef with a speckled red hide, four feet of horns, and a majestically glowering look in her red-rimmed eyes."
--Wayne King

I couldn't help myself. There aren't a lot of quotes about longhorn cattle out there, but this one hit me pretty squarely. "Majestically glowering" is a pretty good description of a .NET programmer in a roomful of WebSphere folks--or vice versa.

So What's This All About?

Over the last few months, we've done a good job of cutting through the hype that hindered objective comparisons of Java, SQL, and RPG. Clearheaded analysis showed that each tool has its place. Some shops will never need Java. Most should consider a combination of RPG and servlets. Under certain circumstances, some new applications might best be written in 100% Pure Java. However, anyone telling you to toss your existing (working!) RPG systems into the trash and rewrite them in Java is simply looking for the fastest path to your wallet.

So, now that we have a clearer indication of where Java, SQL, and RPG are most useful, it's time to turn to that other great question surrounding Web development today: J2EE or .NET? Interestingly, this issue has in many minds become "WebSphere vs. .NET" or even "IBM vs. .NET," but it really depends on the context. When you're talking about the Java language itself and the specifications that drive it, you're talking about Sun and the Java Community Process. However, as the specifications have passed from a technical description of a language to a more theoretical interpretation of application design, Sun has left more and more out of the specifications, remarking only that they are "left to the implementation." This is the void into which IBM and particularly WebSphere have leapt, thus blurring the line between Java, J2EE, Sun, IBM, and open source.

Because of all of this, answers here are going to be a bit murkier than in our previous topic. While common sense and a couple of benchmarks made it clear where the strengths of Java, SQL, and RPG each lie, the question of J2EE and .NET is more complex. Not only that, the question is growing more difficult as the companies attempt to differentiate themselves in the market while at the same time the technologies evolve closer to one another from a feature/function standpoint. And because of my familiarity with the WebSphere, I'm going to focus on WebSphere vs. .NET.

In order to make a first-pass comparison, in this article I will compare...

• The basic features of the two technologies
• The security models
• The tools
• The philosophies
• The companies

The Features

As the two platforms evolve, functionally they actually converge more than diverge. There are very few features you can point to in one technology that don't exist on the other. JavaServer Pages (JSP) for J2EE is the equivalent of Active Server Pages (ASP.NET). Component Object Model (COM+) technology is the same as Enterprise JavaBeans (EJB). In some places, the differences are larger: Thick-client programming is a lot different in the two languages, and Windows has the clear advantage, although the Eclipse Rich Client Platform (RCP) is a great advance in that area for J2EE applications. In other places, the differences are getting smaller: Active Data Objects (ADO.NET) now includes a try/catch syntax for error handling that is a carbon copy of the corresponding Java syntax, right down to the curly braces.

As to functional comparisons, the facts are somewhat thin. Performance and scalability tests seem to be equivocal; studies underwritten by Microsoft show .NET besting WebSphere, while IBM-funded benchmarks show WebSphere at the top of the pack. Simple comparisons degrade into finger-pointing and name-calling, with each side insisting that the other is wrong and the press merrily publishing whatever gives them the most exposure.

This last point is getting to be horrendous. For example, The Middleware Company recently published a document "leaked to the press purported to be from IBM." The document still isn't verified to be an IBM document, but it's out there online for the reading, including Microsoft's response to the alleged IBM document. Who publishes unattributed documents? Who responds to them? Oh yeah, the entire "blogsphere," that's who. In this world of instant Internet access, anybody can publish anything, and it's guaranteed that the story will be picked up by some other yahoo with a PC and a modem. Suddenly the story has "multiple sources," so it must be credible. Oh, don't get me started.

The Security Models

This topic is interesting. Security is a huge deal in the Web world, thanks to the multi-billion-dollar virus industry, and the approaches to the issue are quite complex. Java was designed from the ground up for security, and because of that it generally exceeds .NET security capabilities. For example, .NET runs compiled code, while the Java Virtual Machine (JVM) always runs bytecode. And while the HotSpot compiler in the JVM eventually compiles code down to machine level, it keeps all the bytecode security information in place and thus is technically more secure than the compiled .NET code.

On the other hand, .NET continues to catch up and even pass J2EE in some areas, particularly application areas such as user authentication.

Many of the issues are design issues that ultimately boil down to business decisions. You can easily change your Java security settings using command line switches. This makes it easier to have different security policies on the same machine, but it also opens a door of vulnerability to knowledgeable programmers. .NET on the other hand tends to have security for the entire machine set by configuration files, which disallows some of the flexibility of the Java approach but also makes it easier to lock down an individual's access.

The Tools

This topic by itself can begin a war. The entire issue of Visual Studio versus WebSphere Studio is a bitterly contested one, and I have yet to see a person who has taken an "either/or" position. I'm a big fan of the WebSphere tools primarily because of their incredible integration with the iSeries. Plus, the Microsoft offering is getting quite complicated; Visual Studio has splintered into over half a dozen different offerings, many of which you cannot even beta test without a subscription to the Microsoft Developer's Network. Ironically, the smaller versions that you can download without cost are called "Express" editions. And in order to access even those, you have to join Microsoft Passport. I'm quite averse to joining any Microsoft offering and especially Passport after the credit card information debacle of a few years back, but I may have to do so pseudonymously in order to get a look at the new 2005 editions.

In recent history, especially as IBM was floundering between various architectures for its tools (such as CODE/400 and VisualAge), it was evident that Microsoft had a lead when it came to its toolset integration. Microsoft has a look and feel that has evolved over time to include all of its products, and it's likely that the 2005 version will continue to provide that sort of common user experience. This is not insignificant; the better the integration, the shorter the learning curve and the easier a programmer can incorporate new languages. Since the .NET philosophy centers around multiple languages, it's easy to see why this is an important goal of Visual Studio.

At the same time, IBM standardization on the Eclipse framework and the steady advances being made there may allow it to meet or even exceed the integration capabilities of Visual Studio. Already, the Eclipse RCP allows developers to write fast, powerful applications that perform well and look good across platforms. If the RCP look and feel become accepted, that will only be more momentum for the Eclipse platform and consequently for the WebSphere Studio products built on top of it.

Finally, the plug-in capabilities of Eclipse currently vastly exceed those of Visual Studio .NET. The sheer number of plug-ins for Eclipse is unmatched by any other development environment.

Comparing the Philosophies

The big question--really, the only question--is how each company's approach affects your business in the long run. Unfortunately, it's not easy to distinguish the effects of each approach. Except for Sun, which seems to have no direction, the other companies seem to be pushing toward a future where there are no independent computer programmers and you lease your software the same way you subscribe to cable TV. Let's see how they intend to get there.

Sun

I'm still unsure as to what Sun's philosophy is. The company seems stuck between a commercial future for Java and a full acceptance of the open-source community. It wants to claim Java as an open product, yet exercise complete control over its direction. This is a company that can't figure out how to make money off the most successful computer language ever designed. Run away quickly, with your hand over your wallet.

Microsoft

The Evil Empire, Microsoft has always had the same view: Crush all competition and then squeeze every penny out of customers. Nothing has changed, except perhaps the introduction of "leased software." This would be the ultimate Microsoft future. With no competition, you'd be forced to use whatever software Microsoft pushed on you. The software would be "free" on your PC; in fact, you wouldn't be able to remove it. After you were completely locked into this "free" software, Microsoft would announce a "transaction fee" as well as a "software maintenance fee." For this price, you'd get new releases of the free software and a 1-800 number for phone support. New releases would break old releases, requiring more purchases. Also, the new Palladium chips would continuously broadcast who you are to Microsoft to make sure you are paying your transaction fees.

Microsoft will continue to push a transaction-based economy, with both hardware and software as commodities.

IBM

Interestingly, IBM's goal is not so different. While the company may indeed hook you up with Business Partners for custom software, it's just as happy to sell you Java-based off-the-shelf solutions that run on any of its servers. You'll just be charged for additional capacity as your needs ramp up. IBM will also sell you new or additional servers of whatever type strikes your fancy. Why not? The new WebSphere J2EE applications will run on any of them.

Both IBM and Microsoft see software as a commodity. In fact, the only real difference between Microsoft and IBM is that Microsoft wants one operating system that supports many languages, while IBM is shooting for a single language that runs on virtually any hardware and any operating system.

The Companies

As I've shown, there are huge differences between J2EE and .NET. In the end, though, the two technologies seem to be merging in many ways, at least from a functional standpoint. J2EE provides things one way, Microsoft another, but the same tools seem to emerge. Because of this, it may finally just boil down to the companies and their philosophies. Unlike the iSeries, which is a clear winner over any other platform for business transactions, there is no such clear distinction between J2EE and .NET. Therefore, you have to take a "bigger picture" view to provide you with some distinctions.

Sun

One thing about Sun is that it's been remarkably consistent over the past five or six years. New releases of Java keep coming out, and both the language and the platform have seen enhancements. My biggest problem with Sun has been the lack of movement in the Java language itself; the relatively minor syntax enhancements (such as generics) in the new Tiger release should have been made over a year ago. It looks to me like the Java language is inextricably linked with the Java platform, and they fight over a finite pool of resources. Because of this, one side or another is often getting the shallow end of the resource pool, and for the last several years, it's been the language.

At the same time, from what I've been able to deduce, the platform side isn't exactly blinding anyone with its forward acceleration. Windows continues to catch up on many fronts, at least theoretically (an issue I'll address in a moment). Of course, that's a standard Microsoft technique: Wait until somebody invents something and then re-implement it in a slightly better fashion that just happens to be Windows-specific.

Microsoft

Sun takes too long getting good ideas agreed upon, much less designed, developed, and delivered. On the other hand, Microsoft does the opposite: It promises great things and then delivers questionable releases. Longhorn is the codename for the next version of Windows. Longhorn has been slated for release on numerous occasions, and exactly what is in the package has also been subject to change. And I don't mean little changes like whether or not it will support handhelds; I mean fundamental changes, such as whether there will be a server version and whether it will include the new WinFS file system (current answers: yes on server and no on WinFS).

This software has been in development for years, and it's slated for "beta" release in 2005 with "release" in 2006. Unless Microsoft makes some huge changes in quality control, that means the software will actually be roughly of beta quality in 2006. And since this software includes major upgrades in everything from UI to security, it seems unlikely to me that the software will be without major problems once it hits the real world. Add the introduction of a new file system soon after that, and it seems to me that 2006 is going to a very interesting year for early adopters of Microsoft products (and 2005 will be a long year as they wait for things to appear).

IBM

IBM has been anything but complacent. Its embrace of Java and Linux has been nothing short of astounding, and the long-term vision seems clear: IBM wants the world to consist of completely platform-independent software that can run on any of its machines. IBM still wants to sell machines, and software that can run on any of its machines is a plus. Those of who understand that software that runs everywhere typically runs badly everywhere or who love the unique capabilities of the iSeries are not particularly enamored of that view of the future.

So Is There an Answer?

When I ask my Magic 8-Ball if there's an answer to this conundrum, it keeps coming up "Reply Hazy, Try Again." I think I got an outsourced 8-Ball. In any case, the question really comes down to which philosophy better fits your vision of the future. Are you comfortable in a completely homogeneous Microsoft environment where you pay for each transaction and for every user, or do you prefer the IBM philosophy of multiple hardware options, with the ability to lease extra power as you need it? Do you want multiple languages all ultimately doing the same thing or one language across your entire enterprise? Would you rather go with a company that continues to push the open-source movement, driving software prices to commodity levels (by the way, as an ISV, I don't think this is a good direction), or a company that does everything it can to lock you into a single platform that it can then set prices on like a software version of OPEC?

Whom do you trust?

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been working in the field since the late 1970s and has made a career of extending the IBM midrange, starting back in the days of the IBM System/3. Joe has used WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. Joe is also the author of E-Deployment: The Fastest Path to the Web, Eclipse: Step by Step, and WDSC: Step by Step. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..