Letters to the Editor: ‘Rumble’ causes a stir

“Rumble in the Jungle: J2EE Versus .Net, Part 1”

Humphrey Sheil and Michael Monteiro

Does vendor lock-in matter? How reliable are Microsoft’s server software products?

Michael and Humphrey,

While I find your article informative, I take issue with a couple of items. First, I find your statement, “On the other hand, .Net locks you into Microsoft. For example, .Net runs only on Wintel machines. Depending on your organization, that lock-in may or may not be an issue,” fatally flawed. Anyone running a serious business should be concerned about single vendor lock-in; you completely tie your organization’s fate to that vendor. History is replete with companies that, at the time, were safe bets, but then later fell on hard times, making life for their customers very bad. Openness serves the interests of customers better than any vendor can.

Second, I take issue when you state, “In the area of stability, Microsoft efforts have paid off, reaching 99.999-percent reliability with Windows 2000.” This quote is based on what factual data? Your 99.999-percent availability figure equals just 5 minutes and 17 seconds of unscheduled downtime in a year. I have personally never seen a Windows 2000 server achieve anything close to this, and believe me I have the experience to prove it. I also haven’t seen anyone who could achieve any decent uptimes of Windows servers, of any version, without clustering the machines. Of course, for any platform, this would be the only way to achieve 99.999-percent availability. You shouldn’t include such quotes without a link to some statistical data the showed that to be true.

Andrig T. Miller

Andrig, Michael Monteiro: In the article, I say that .Net locks you into Microsoft, which may or may not be an issue depending upon the organization. I agree that choosing a vendor represents an important decision. You certainly don’t want to make a sizable investment in a vendor unable to stand the test of time. However, many companies have and continue to bet that Microsoft will continue to thrive. Sure, life offers no guarantees, but few things come with such assurances. Further, vendor dependence, though perhaps to a lesser degree, exists in the J2EE (Java 2 Platform, Enterprise Edition) world as well. I’m sure you would agree that while a company can choose any J2EE vendor, it often becomes impractical to move to another vendor once a choice has been made. As for your second point about Microsoft’s reliability, you are correct to say that one cannot achieve 99.999-percent reliability with a server operating system alone (you mention clustering). That reliability level requires a combination of technology (software and hardware), highly trained people, and solid processes. To help people achieve that reliability level, Microsoft offers the Windows Datacenter Program that outlines a series of rigorous performance and customer-service requirements that original equipment manufacturers (OEMs) must meet. From an operating system perspective, an Aberdeen Group report, “Proving-the-Point: Interviews with Next-Generation Windows 2000 Dot.coms,” concluded that customers achieved 99.967-percent reliability using Windows 2000 without additional hardware support. Humphrey Sheil: Vendor lock-in represents one of the major differences between the two platforms. .Net represents complete and total lock-in to the Microsoft technology stack, while J2EE allows you to build applications against a common specification, then pick your preferred vendor. Michael’s point concerning moving from vendor to vendor within the J2EE world formerly was relevant and continues to be for certain applications and vendors, but today a well-constructed application will port quite easily from one vendor to another. I have personally ported applications across BEA WebLogic, JBoss, and IronFlare Orion. Most problems encountered were incorrect interpretations of the Enterprise JavaBean (EJB) specification by application code, not by the vendor’s implementation.

How to scale in a .Net environment

Humphrey and Michael,

In your article, you say, “In the .Net world, developers employ remoting to increase security and ease maintenance, but not to improve scalability… “

I would like to see evidence that backs that statement up. It is a known fact that distributed systems (such as those created using .Net remoting) have increased security risks, simply because there are more machines and the network to control. Just look at how complex DCOM (Distributed Component Object Model) security can get as opposed to plain old COM security. It’s the same for maintenance. .Net remoting increases maintenance nightmares!

Also, why don’t developers use .Net remoting for scalability? Isn’t adding more machines the best way to scale? Web servers are only on the front end, where most processing doesn’t occur. What about the middle tier? Does .Net remoting ring a bell there?

Tarak Modi

Tarak, Monteiro: I agree that because distributed systems are more complex, they can require more configuration maintenance. My comment about employing remoting to increase security comes from the notion that the Web server generally proves more vulnerable than an application server because the Web server is often located within the DMZ. By distributing objects onto another machine within the corporate LAN, companies have the option of introducing a more restrictive line of defense (that is, another firewall) between the Web server and the application server. To be clear, systems that employ .Net remoting can scale. My main point: Developers don’t chose remoting for scalability reasons alone. Instead, it is often chosen for reasons like increased security.

Whereas Java does support other languages, .Net supports them badly

Michael and Humphrey,

I am surprised you are not aware of the many languages written for the JVM. Many build Java byte code directly from the source like Kawa and allow you to interoperate with Java objects. (See “Programming Languages for the Java Virtual Machine.”)

Furthermore, I am surprised you do not recognize that, like CORBA/COM and other interface layers, the CLR (Common Language Runtime) supports a least common denominator of language features. For example, C# is little more than a clone of Java. Also, Visual Basic had to change syntax so much to work with the CLR that old projects will not even compile. If a language has to be rewritten in order to interoperate with the CLR, is it really the same language?

I had expected JavaWorld to dispel some of the unwarranted hype that surrounds .Net. Instead of a critical review, the article seems to simply be an affirmation of both companies marketing lines.

Thomas Vaught

Thomas, Monteiro: While the Common Language Specification (CLS) may not support some language features for a particular language, you are not correct to say that the CLR supports a “least common denominator” of features. On the contrary, the CLS supports a majority of the language features available in a variety of programming languages (more than 20 at present). For proof, consider how different the language features of LISP and C# are, yet the CLR supports them both. As for your other comments, I’m not sure what part of the article you are responding to. Yes, C# is very Java-like in appearance, but I’m not sure what you mean by it being little more than a clone of Java. Yes, Visual Basic and Visual Basic.Net are not the same language. They do contain several important syntactical differences, but they share many more syntactical similarities. The key point is that developers can write .Net applications using any language that supports the CLS. True, the CLS does not support all features for all languages, but it does support most features for a variety of languages. Sheil: Thanks for the link on other languages supported by the JVM. Although I am aware of languages like JPython, I believe that other languages for the JVM are unimportant. I think the Java platform’s main advantage is a stable language common across all devices with a rich set of APIs and libraries to offer developers the functionality they need to complete their jobs. Introducing new languages means introducing additional complexity in maintenance and duplicated skill sets (potentially a bugbear on .Net projects also), which I always try to avoid. As for your comments about unwarranted hype, don’t fall into this trap. .Net represents for me the only challenge to J2EE. With Microsoft’s support, .Net is guaranteed to be around for the long haul. I still believe that the J2EE platform represents the best technology stack, but we need to continually improve it to remain best in class.