15.5 Ten Considerations for Evaluating J2EE versus .NET

The two main technology contenders for running your enterprise are Java 2 Enterprise Edition, known as J2EE, and Microsoft's .NET. A major advantage of the software fortress model is that you don't have to choose between them, at least at an enterprise level. But within the fortress, I still prefer the simple world of homogeneity. So as you plan your fortresses , you will need to choose one or the other approach. How do you choose? Here are the top ten considerations that I think should guide your decision:

1. Do you need to run this fortress on a non-Windows platform? Once you have decided that you must run a fortress on a non-Windows platform, .NET is out of the picture. Although versions of .NET are coming out for non-Windows platforms, as of this writing none of these are ready for prime time. So if you must run your fortress on Unix or Linux, look to a J2EE solution.

   It is worth asking yourself why you think you need to run the fortress on something other than Windows. If the reason is that you think other platforms are more secure, more scalable, more reliable, or less expensive, you are probably wrong. There is little evidence that other platforms have any advantages in any of these areas.

   Of course, you might prefer a non-Windows platform for other reasons. For example, your code base may already run on another system and there is no advantage to be gained by porting it to Windows. You may already have Unix machines that you can leverage in your new fortresses.

   Bottom line: Use .NET for Windows, and J2EE for anything else.

2. Is cost of the fortress important? Predicting fortress costs can be a bit complicated, but for cost-critical systems it is well worth the exercise. Let's say we have a fortress F that is built with technology T. Assume F can be built up in incremental units of T _U , where each increment costs T _D dollars. If F is built with scale-out fortresses, then it might cost T _D dollars to add another machine to the cluster. If F is built with scale-up fortresses, then D is the additional cost of the next biggest machine. Assume that each T _D dollars adds the ability to process T _U units of work per minute. Assume that F is going to be asked to process a peak workload of P infograms per minute and an average workload of A infograms per minute. Got that? Let me review:

   • F is the fortress we're trying to build.

   • T is the technology we're using.

   • T _D is the dollar cost per incremental unit of adding new pieces of T.

   • T _U is the number of units of work per minute that each T _D dollars adds.

   • P is the peak workload (in infograms per minute) that F will be asked to process. P is independent of T because people outside the fortress will be shoving P at you, like it or not, regardless of what T you choose.

   • A is the average workload (in infograms per minute) that F will be asked to process. Like P, A is independent of T.

   We are almost ready to calculate the unit-of-work costs, but we are missing one piece of critical information. Can you see what it is?

   The missing piece of information is the nature of the drawbridge over which F will be receiving its infograms. This is important because if the drawbridge is asynchronous, we will need enough multiples of T _U to accommodate A. If the drawbridge is synchronous, we will need enough multiples of T _U to accommodate P. Because P is typically at least an order of magnitude bigger than A, the drawbridge makes a big difference.

   The overall cost of building F with technology T using a synchronous drawbridge will be A · (T _U x T _D ). The cost of building F with technology T using an asynchronous drawbridge is P · (T _U x T _D ). These calculations are all a bit approximate because they don't include the cost of the drawbridge itself and they assume that the ratio T _U /T _D is linear (an optimistic assumption), but they are a good starting point.

   It is difficult to compare T _U and T _D for J2EE and .NET. We have very few benchmarks comparing the two technologies, mainly because the J2EE community specifically defines its benchmarks to preclude participation by .NET. However, from the direct benchmarks we do have, the benchmarks we can extrapolate, and my discussions with people who have used both, I have come to some general conclusions that I believe are valid at least for business application and presentation fortresses, where we have the most data.

   For presentation fortresses and business application fortresses, I believe that a good rule of thumb is that the number of units of work you can process, T _U , for a given number of dollars, T _D , is 5 to 10 times higher for .NET than it is for J2EE. This assumption leads to the general prediction that if a fortress costs X dollars to build on .NET, it will cost between 5X and 10X dollars to build with J2EE. Because fortress hardware/software costs are typically in the range of 50,000 to 500,000 dollars, this cost difference can quickly add up. A .NET fortress with a predicted price tag of 500,000 dollars would have a predicted price tag of 2.5 to 5 million dollars if built with J2EE.

   As I said, these comparisons are mainly valid for business application and presentation fortresses. It is too early to predict what comparison we might get for other fortress types.

   Bottom line: Near as I can tell, cost analyses favor .NET by at least a factor of 5.

3. Do you need consultants ? If you will be hiring consultants, you will generally find it easier to hire expertise in the J2EE space than the .NET space. The expertise that exists in .NET is mostly in one of two places: small, mom-and-pop consulting organizations of less than 100 people or Microsoft Consulting Services (MCS). MCS is a mere shadow of the IBM equivalent organization, IBM Global Services. Whereas IBM Global Services is well positioned to come in and run your IT organization from beginning to end, MCS generally serves only in an advisory role, depending on smaller consulting organizations (mostly ones you have never heard of) to do the real work. If you have decided to use IBM Global Services to run your organization, you have also made a de facto decision to use J2EE (and probably Linux), regardless of whether that's the best decision.

   Bottom line: If you depend on outside consultants and prefer working with name -brand organizations, you will be better off in the J2EE space.

4. How much work do you have in the presentation fortress? The presentation fortress is one of the areas where .NET technologies have some important advantages. ASP.NET, for example, can significantly reduce the time involved in developing presentation fortresses, especially those that have complex and highly interactive presentations. .NET technologies will offer fewer advantages for presentation fortresses that are more data centric.

   The ASP.NET technology has four major advantages over the analogous J2EE technology (known as Java ServerPages):

   1. It is much easier to manage browser state, a very tricky issue in Java ServerPages.

   2. It is much easier to figure out what is happening on the browser side.

   3. It is much easier to write browser-independent code.

   4. It is much easier to purchase sophisticated visual controls.

   The major disadvantage of ASP.NET is that it depends on Microsoft's IIS (Internet Information Server) to provide an infrastructure in which to run. IIS has a long history of security problems. A careful analysis would show that IIS is no worse off than its competition, but because it is so widely used (and probably because it is from Microsoft), its security problems get much wider publicity than those of other (non-Microsoft) products. Whether the sentiment is reasonable or not, many companies don't trust IIS.

   Bottom line: Unless you are IIS-phobic, ASP.NET is a clear winner for developing presentation fortresses.

5. What connectors do your existing systems have? Connectors are mostly an issue for treaty management fortresses. These types of fortresses use the .NET technology known as BizTalk Server, or competitor products such as IBM's WebSphere MQ Integrator or TIBCO's ActiveEnterprise (these names seem to change on the drop of a hat, so don't count on them).

   All of these products are superficially similar in that they define interfaces that other systems must support to be integrated into their overall framework. From a software fortress perspective, these interfaces effectively define the drawbridge between the treaty management fortress (BizTalk Server and others) and the business application fortress (the ones you have either written or purchased).

   These interface implementations are usually known as connectors. For most large purchased systems, connectors must be written by the original system vendor. They are too complex for anybody who is not intimately familiar with the system to attempt.

   Unfortunately, there is no standard for these connectors. They are specific to the treaty management technology. So if you are in the lucky position of having to link together systems that already have prebuilt connectors to a particular treaty management technology, that technology will be your best choice for at least the treaty management system working with those systems.

   Bottom line: When you need to connect business application fortresses together, choose a treaty management fortress technology that those business application fortresses already support.

6. What is your existing skill set? The easiest technology to use is the technology that your developers already know. If they have expertise in Visual Basic, COBOL, or one of the other .NET-supported languages, then .NET will be easier for them to use. If they have expertise in Java, then one of the J2EE offerings will be easier.

   Bottom line: If your developers are very familiar with Java, they will be most productive with J2EE. If not, they will be most productive with .NET.

7. What is the long- term health of the vendors ? I think it is obvious that Microsoft, as the primary vendor of .NET, and IBM, as the primary vendor of J2EE, are going to be with us for a while. Anybody else is high risk. Sun, which owns the J2EE specifications, is facing tough challenges from both IBM, at the high end, and Microsoft, at the low end. BEA, which at one point I believed would be a major contender in the J2EE space, has just finished a disastrous quarter (second quarter, '02), with revenues down 28 percent over the same quarter in the previous year.

   Bottom line: IBM seems to be a safe bet in the J2EE space, and Microsoft seems to be a safe bet in the .NET space. Anybody else is high risk.

8. Will you need very high-end databases? The benchmark that is usually used to measure database performance is the TPC-C benchmark. This benchmark is relevant mostly to business application fortresses, which tend to stress databases to the maximum.

   Vendors are allowed to run the TPC-C benchmark with both clustered and nonclustered configurations. To run clustered configurations, you must partition your database. For most business application fortresses, partitioning databases is not a realistic option. Therefore, when looking at the TPC-C numbers , I tend to give more weight to the nonclustered configurations.

   At press time, the best performance for .NET technologies without partitioned databases is about 300,000 transactions per minute. The best-performing non-.NET systems can achieve 455,000 transactions per minute. If one allows partitioned databases, .NET systems can achieve over 700,000 transactions per minute. As I have said, however, this level of performance is probably not realistic for most applications.

   Unfortunately, the 455,000-transaction-per-minute non-.NET systems do not use J2EE. These systems are built on boring, tried-and-true transaction processing monitor (TPM) technologies. J2EE vendors do not participate in this industry standard benchmark, presumably because the performance numbers are too low.

   So although you can't get the highest possible performance with nonpartitioned .NET systems, you probably can't with J2EE either. Fortunately, the numbers you can get, the documented numbers for nonpartitioned .NET, are far in excess of what any but the most demanding applications would need. After all, 300,000 transactions per minute is still 432 million transactions per day!

   Bottom line: If you are a database user at the extreme high end, you probably can't use either .NET or J2EE. Otherwise, .NET will definitely meet your needs, and probably J2EE will as well (although we have less data to support the latter claim).

9. How well are Web services integrated into the platform? Web services are the basis for both Web service fortresses and heterogeneous synchronous drawbridges . SOAP, WSDL, and UDDI are all standards that generally fall under the umbrella term Web services . With the likely exception of UDDI, these are all important standards. You need them. But they are too complex to use directly. You need your platform to use these standards but make their use invisible to you. It is hard to evaluate how good a job vendors are doing in this area because the technology is changing fast. However, as you are considering different vendors, think about how you will be using Web services and look for excellent tool support that shields you from the ugly details.

   Bottom line: The less you need to know about Web services to use them effectively, the better.

10. What legacy tools are available for your particular legacy systems? There are no standards for building legacy fortresses. When choosing platforms for legacy fortresses, consider the options that the vendor provides. What do you need to do to wrap an existing legacy system into a legacy software fortress?

    There is no single right answer here. It will depend on the specific legacy application. In making a decision, you should answer at least the following questions:

    • What footprint, if any, is required on the legacy platform? Preferred answer : none.

    • What modifications need to be made to the legacy code? Preferred answer : none.

    • What performance does the technology support? Preferred answer : higher than you need.

    • How difficult is the technology to use? Preferred answer: easy.

    Bottom line: Choose legacy fortress technologies that support your specific legacy fortress needs. There will not be one answer for all legacy fortresses.