E-business choice: Java or Windows?

With the recent rise in acceptance and deployment of Internet applications, corporations have quickly come to realize that the applications they build must meet not only the needs of today, but those of tomorrow as well. A poor choice in implementation technologies today can turn success to failure.

For this feature, we’ve pitted two outspoken Test Center experts against each other as they discuss the potential benefits and drawbacks of implementing Windows 2000 versus Sun’s Java 2 Platform, Enterprise Edition (J2EE) as a middleware standard.

Yager: Somewhere amid the noise of the Microsoft antitrust trial, Outlook email viruses, and the unveiling of .Net, Microsoft shipped Windows 2000 Server. It has gone largely unnoticed, mostly thanks to Microsoft’s lack of effective marketing. This new server OS includes a complete set of enterprise middleware facilities: transactions, distributed objects, a robust database, and guaranteed messaging are all in Windows 2000 and available to every application. Combined with the Internet Information Server (IIS) Web server and a powerful scripting facility, Windows 2000’s middleware rounds out a powerful environment for enterprise applications. And it’s all included in the price of Windows 2000.

Fielden: Although it may be true that Windows can provide a comprehensive solution for deploying business applications, one of my big problems with it is that it does so in an extremely proprietary manner. This forces third-party vendors, companies, and end users to conform to a closed system. Moreover, given my background as a system architect, I have a huge problem with anyone who suggests implementing a solution that runs on only one platform — the PC. Unlike the Java 2 Platform, Enterprise Edition (J2EE), which allows users to pick the platforms that make sense for their businesses, Windows 2000 removes that choice and encourages the concept of server farming, much to the delight of hardware and software vendors — each of whom are looking for a slice of the pie.

I admit that when businesses were in the midst of client/server computing, Windows often proved to be the best strategic direction. However, in today’s post-PC era, Java does a vastly superior job at positioning itself across a much larger base of consumer devices and server platforms.

I agree with you that the capabilities of Windows 2000 have improved greatly since the NT days; unfortunately, so have the product’s complexities. When you consider the amount of effort it takes to get mandatory services such as Active Directory running, I just cannot in good faith recommend it. And when you look at the number of vulnerabilities Windows has had over the past few years, specifically with security, I would far rather leverage other choices that are better suited to the rigors of an enterprise-level e-business.

Similar services; similar choices?

Yager: J2EE’s menu of enterprise application services is remarkably similar to Windows 2000’s, so J2EE can’t win this one on core features. J2EE is Java, which those already coding in Java see as an advantage. I like Java well enough, but I prefer to choose my language for each project, and I code to Windows 2000’s services using C++ and JScript.

Fielden: As one who just admitted liking choice, why would you recommend something that offers so little of it? If you look at the popularity of Java in the industry now, it would be a safe bet to get behind it, especially considering it’s backed by known entities such as Sun, IBM, and Oracle, to name only a few. You mentioned coding to Windows 2000’s services — how is that different from coding to the Java specification? Using the Windows 2000 services provides no edge. Both provide the user with connectivity and reuse capabilities.

When you consider cost, you must also take into account the availability of resources to perform the work. I would be willing to wager that although a large number of developers are skilled in C++, a larger number can be found in the Java camp.

As to mixing application languages, I am the first to agree that the language chosen should fit the need. You should note that business applications written using J2EE could include the use of functions coded in many languages other than Java, such as C++.

Costs and resource needs

Yager: I am struck speechless that anyone would pay 5,000 per CPU for J2EE when Windows 2000’s enterprise facilities are built in to the OS. Because J2EE is written in Java, you need lots of beefy hardware to run J2EE apps. An ,800 Windows 2000 license handles up to four CPUs and 25 client licenses, and it runs on fast, affordable PC servers. As for long-term expense, all costs associated with Windows are lower: training, hardware service, and software support. J2EE is a money pit by comparison.

Fielden: Where did you get the 5,000 price? I’ve been able to download J2EE (see Resources) and create a myriad of business applications that run fine on a multitude of platforms that cost significantly less than the price needed to support a large enterprise with Microsoft technologies.

The statement that J2EE requires beefy hardware to be successful is a myth. In fact, if you were to compare identical business environments of 10,000 or more users the Windows configuration would require much more hardware, as memory and disk requirements are higher for Windows than for J2EE.

As far as skill goes, those who can code to Java also can code to the J2EE specification. Windows 2000 requires huge amounts of systems knowledge to make it work correctly. Moreover, Microsoft’s change in object strategy from its own COM (Component Object Model) to the broader SOAP (Simple Object Access Protocol) will cause huge headaches for developers and for businesses that have invested a lot in COM. According to a recent Gartner report, Microsoft’s COM should no longer be viewed as a viable strategy. Java, on the other hand, with its huge following and compartmentalizing capabilities via both JavaBeans and Enterprise JavaBeans, makes it easy to leverage others’ work.

J2EE’s edge

Yager: Windows 2000 is built on Windows NT 4.0 technologies. There are plenty of experienced Windows developers in the labor pool. Unfortunately, most are unfamiliar with Windows 2000’s new enterprise services. Microsoft has been lazy about spreading its enterprise message. In fact, the company spent this year’s Professional Developers Conference focusing entirely on .Net. I think that gives Sun a one-to two-year window to establish J2EE. J2EE may even gain a foothold in the Windows space among those who don’t realize comparable services are already in the Windows 2000 OS.

Fielden: Tom, we both know that J2EE is already well-established in the marketplace. The fact is that more than 50 percent of Windows NT code was replaced to create Windows 2000, and that is a huge educational hurdle for developers.

Developers also will need time to learn about .Net (SOAP and C#). This is a huge expense for businesses and a time-drain for companies trying to be competitive in the new economy. It is Microsoft’s change from COM to SOAP that will give J2EE the edge. In addition, although Microsoft was a primary provider during the client/server era, we’re moving toward Internet-based computing, for which J2EE is much better suited.

Who’s a hog?

Yager: J2EE deserves a Guinness World Record for being the world’s biggest CPU and memory hog. A 5,000 Sun server would be considered barely adequate for J2EE. Windows 2000’s services are written in C++, and they run fast and smooth on far less costly hardware. As for stability, experienced administrators can build Unix, Linux, and Windows servers that run nonstop. IS managers are traditionally more willing to spend money on top-shelf Unix administrators, thinking that anyone who has ever used Windows can operate enterprise Windows servers. That’s wrong, and it has kept alive the myth of Windows server instability. Bulletproof Windows servers are a reality; you just have to know how to build them.

Fielden: Tom, I had to laugh when I read your comment about the requirements for running J2EE applications, as I am using it to run business applications on hardware valued at less that ,000 and have seen no degradation in performance versus high-end configurations running the same applications. Your argument is more applicable to enterprise business applications running on the Windows platform. It is well known that Windows is a glutton for hardware resources.

You may be able to build a stable Windows server environment, but the fact is that over the years Microsoft has become sloppy with its development efforts. Windows code keeps getting bigger and more complex.

Competing objects

Yager: Let’s remember that Sun yanked Java off the standards track. Sun has used its Java monopoly to fix ridiculously high license fees for J2EE. Aside from that, Sun and Microsoft have similar approaches to openness. Both vendors actively court developers, and those developers create many commercial and freely available Java and Windows enhancements. Sun’s standards edge is J2EE’s use of CORBA as an object layer. Microsoft chose SOAP, which is much easier than CORBA to code for and manage. But CORBA has a huge following, so Microsoft is definitely playing catch-up on object standards.

Fielden: Tom, you have an interesting outlook on things. Sun does not have a monopoly on Java. Microsoft chose to move away from the Java community when it found it could not take over the marketplace. In openness, there is no comparison between Windows and Java, as the former is closed and quickly moving to legacy status given the shift to the post-PC era. The latter is much more open and more closely aligned with Internet technologies.

The only freely available “enhancements” I’ve seen come from the Java development community. Although I admit CORBA and COM are both equally complex to deal with, I cannot see how one is easier than the other. Microsoft needs to avoid slipping up in its move from COM to SOAP. It stands to alienate many developers who have invested a great deal of time and effort in learning COM.

In addition, SOAP does not belong only to Microsoft. It is a standard and other vendors are well ahead of Microsoft in implementing more of the specification in a way that is truly open. For example, IBM has implemented SOAP more fully, in a more open manner, and has released it to the open source community. Thus, Java developers can also easily take advantage of SOAP should they so choose.

Source: www.infoworld.com