11.3 .NET versus the J2EE Approach


Given everything going on in the business application fortress, you might expect huge differences between Microsoft's .NET and Sun's J2EE architecture. In fact, you will find vendors disagreeing with many of my recommendations in this chapter (and for that matter, this whole book). The disagreement is not because of differences in the two technologies. It is due to the fact that these vendors are basing their recommendations on a traditional three- tier architecture (or even worse , a clientserver architecture), whereas I am basing my recommendations on a software fortress architecture.

As far as the discussion so far in this chapter is concerned , there is no difference whatsoever between J2EE and .NET. Transaction boundary management, security, scalability, and reliability all work exactly the same in the two technologies.

The important business application fortress technology differences between .NET and J2EE are in these areas:

  • Language approach

  • Cost

  • Platform support

Let's look at each of these.

11.3.1 Language

J2EE and .NET have a similar language architecture. Source code is transformed into running business application fortress components as follows :

  1. A programmer creates source code conforming to the rules of a particular programming language.

  2. A translator transforms the source code into a low-level language.

  3. The low-level language is packaged into a deployable unit.

  4. A runtime infrastructure is asked to run the deployable unit.

  5. Before running the deployable unit for the first time, the runtime infrastructure compiles the low-level language into binary code.

As you would expect, Microsoft and Sun use different terms to describe the various players. Sun calls the low-level language Java bytecode ; Microsoft calls it Microsoft intermediate language ( MSIL ). Microsoft calls the deployable unit an assembly ; Sun calls it a Java Archive ( JAR ) file. Sun calls the runtime infrastructure the Java Virtual Machine ( JVM ); Microsoft calls it the Common Language Runtime ( CLR ).

The only substantive difference between the two language architectures has to do with the design of the low-level language. Whereas Sun's Java bytecode has been designed specifically for Java, Microsoft's MSIL has been designed to support any programming language. The result is that J2EE is effectively a closed language architecture, accommodating Java and little else. Microsoft's .NET is more of an open language architecture, usable with any programming language that has an MSIL translator. Such languages include FORTRAN, COBOL, Smalltalk, Eiffel, and many others.

Both approaches have advantages. Programmers who want to use nothing but Sun-approved Java will be happy only with the J2EE architecture. Programmers who want to use other languages and don't particularly care if Sun has approved their language choice will be happier with the .NET approach.

Microsoft's .NET does support two Java derivative languages: J# and C# (pronounced "jay sharp" and "cee sharp," respectively). Of these two, J# is the more Java-like, but I consider C# the preferred choice. J# is a language in which Microsoft has little interest, so it is at higher risk for future support. C#, on the other hand, is a more modern language, a language in which Microsoft has invested heavily and a language backed by an independent standards body (unlike either J# or Java). The syntax of C# is close enough to Java that Java programmers can learn it readily.

11.3.2 Platform Support

The various J2EE vendors and Microsoft have taken two different approaches to platform support. The J2EE vendors have generally taken a platform- agnostic approach, so if one writes to IBM's WebSphere J2EE implementation, for example, it will readily port to any operating system on which WebSphere runs, including the Windows platform. Microsoft, on the other hand, has built .NET for Windows and for Windows only. Microsoft has submitted portions of .NET for independent standardization, and non-Windows versions of pieces of .NET will likely someday become available. Even when this happens, however, it is highly unlikely that a major .NET business application fortress will be able to port easily to a non-Microsoft version of .NET, and it is equally unlikely that Microsoft will ever develop a non-Windows version.

The nonportability of .NET across platforms has an analogy in the J2EE space. Generally the lack of portability is not a cross-platform issue as much as it is a cross-vendor issue. Porting from one vendor to another is just as difficult in the J2EE space as it will likely be in the .NET space. Even though J2EE claims to be a vendor-agnostic platform, in reality any serious J2EE business application fortress application would need to leverage so many vendor-specific features that porting that application from one vendor (say, IBM's WebSphere) to another vendor (say, BEA's WebLogic) would be very difficult.

11.3.3 Cost

The final point is cost, which has two aspects. One is development cost. The other is cost per unit of work (say, the cost of processing an infogram in a business application fortress).

It is difficult to compare development costs because there are no widely accepted standards for making these measurements. However, Microsoft generally gets high marks for its development tools. In addition, developers I have spoken to who have built for both .NET and J2EE generally seem to believe that .NET is much easier to use. No doubt, however, the J2EE vendors will disagree with this assessment.

The cost per unit of work is a little easier to quantify. We do have good standards for measuring cost per unit of work. One of those most relevant for business application fortresses is the venerable TPC-C benchmark, which measures the cost of running database- intensive transactions, which are typical of a business application fortress workload. Using this benchmark and others, and talking to many people who have implemented running systems, I believe that the unit-of-work costs will be about one-tenth as much on a .NET system as on a J2EE system running on a non-Windows platform, and about one-fifth as much as a J2EE system running on either a Windows or an Intel Linux platform.

There are two ways you can look at this. You can ask how much a unit of work (say, processing an infogram) costs on the two platforms. According to my predictions, if it costs 10 cents in .NET it will cost 50 cents in J2EE/Windows and a dollar in J2EE/non-Windows. You can also ask how many units of work you can process for a given costsay, on a 500,000-dollar system. My predictions indicate that if 500,000 dollars buys you 10,000 units of work per minute on J2EE/non-Windows, that same 500,000 dollars will buy you 20,000 units of work per minute on J2EE/Windows and 100,000 units of work per minute on .NET/Windows.



Software Fortresses. Modeling Enterprise Architectures
Software Fortresses: Modeling Enterprise Architectures
ISBN: 0321166086
EAN: 2147483647
Year: 2003
Pages: 114

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net