INTRODUCTIONThe .NET platform consists of many things wrapped into a single name. It offers first of all a language-agnostic model, some languages from Microsoft (C#, C++, VB.NET etc), among others from other vendors, that can all interoperate as desired.
Secondly, all of these languages compile down into an intermediate format, which must be translated into native machine code before it can be executed; this is the responsibility, among others, of the Component Language Runtime, the runtime model of .NET. CLR is, in many ways, the heart and soul of the .NET platform, just as the Java Virtual Machine (the JVM) is of the Java platform.
Thirdly, like Java, the .NET platform ships with a rich and impressive set of libraries with pre-canned functionality built in. UI support, Database access support, remoting support, XML, and more, all come as part of the .NET SDK, and are available to all languages equally.
Lastly, as is to be expected, .NET is also a marketing strategy (just as Java is to Sun) that seeks to discredit its competitors and praise its partners. Unlike Java, it is not an attempt at vendor neutrality, but is firmly controlled by Microsoft; it is not a specification, but an actual binary set of bits.
COMPARISONS OF J2EE AND .NETCLR and JVM: - .NET also offers a fully JIT-compiled model, in that all code compiled for the CLR is compiled into Intermediate Language (IL) byte codes, which are then, at runtime, translated into native code as the code is loaded into the CLR. Like the JVM, this allows for greater long-term optimization opportunities, as well as greater portability and easier language generation, and will serve significant advantages when 64-bit platforms begin to make their move into the market space.
Sun's literature says that Java's VM was designed to allow any Java program to be run on any platform with a compliant VM. On the other hand, Microsoft emphasizes that their virtual machine, called the Common Language Runtime (CLR), was designed to allow code written in any language to run under .NET, which is primarily associated with Windows. CLR for FreeBSD is available.
JVM provides no way of encoding type-unsafe features of typical programming languages, such as pointers, immediate descriptors (tagged pointers), and unsafe type conversions. Furthermore, in many cases the JVM lacks the primitives to implement language features that are not found in JavaTM, but are present in other languages. Examples of such structures include unboxed structures and unions (records and variant records), reference parameters, varargs, multiple return values, function pointers, overflow sensitive arithmetic, lexical closures, tail calls, fully dynamic dispatch, generics, structural type equivalence etc.
In contrast to the JVM where all storage locations (local variables, stack slots, arguments) are 4 bytes wide, storage locations in the CLR (Common Language Runtime) are polymorphic, in the sense that they might be 4 bytes (such as a 32 bit integer) or hundreds of bytes (such as a user-defined value type), but their type is fixed for lifetime of the frame. Natural sized types offer a significant advantage over the JVM, which prematurely commits all storage locations to be 32 bits wide. This implies for example that values of type long or double occupy two locations, which makes things unnecessarily hard for compiler writers.
A unique feature of the CLR is that it's metadata is user extensible via the notion of custom attributes. The JVM does not allow compilers to take the address of local variables, hence it is impossible to implement byref arguments directly. Instead compiler writers have to resort to tricks such as passing one-element arrays, or by introducing explicit box classes (the JVM does not support boxing and unboxing either).
The CLR supports the usual variety of (conditional) branch instructions (such as br, beq, bge etc.). There is no analog of the JVM "jump subroutine" instruction. Also the CLR does not limit the length of branches to 64K as the JVM does (which might not be a big deal for humans programming in Java, but it is a real problem for compilers generating JVM byte code).
CLR is already strictly more powerful than the JVM as a multi-language platform.
CLIENT-SIDE TOOLS
For J2EE application development we have tools called Jbuilder, Visual Age, Sun[tm] ONE Studio 4(Forte) etc. For .Net application development we have Microsoft's Visual Studio .NET. IDE. VS.NET is as good as or better than any Java IDE on the market. In general, it does what you expect and then goes at least one step further. One of my favorite features is the way it checks syntax and highlights errors as you type. The error description shows up when you place the mouse cursor over the highlighted syntax. Most importantly, it includes built-in support for discovering and reading the definition of web services based on the Internet-standard SOAP and UDDI protocols. This makes it easy to build applications that consume web services. Even the debugger is somewhat incredible in that it can step seamlessly from local code, to remote code and even into stored procedures provided you are using Microsoft SQL Server.
WEB SERVICES
Web services are services offered via the Web. In a typical web services scenario, a business application sends a request to a service at a given URL using the SOAP protocol over HTTP. The service receives the request, processes it, and returns a response.
Support for Web services is tightly integrated into Visual Studio .NET. It provides both, support for the development of Web services and support for accessing Web services. The development of a Web service in Microsoft .NET results in a DLL, which can be deployed to the Internet Information Server. Forte for Java, the development environment of SunONE integrates support for Web services as well.
The Microsoft SOAP implementation has been fully integrated to Microsoft .NET. Classes for handling SOAP messages and communication are contained directly within the Microsoft .NET Framework. The SOAP support of SunONE is not as integrated as within Microsoft .NET. Microsoft provides the UDDI Software Development Kit to handle UDDI registry information or operate a local UDDI registry for test purposes. The SDK is implemented as a managed code class library that provides a simple programming model to manipulate the request and response data necessary to interact with a UDDI registry from Visual Studio.NET applications. There is almost no support for UDDI within the SunONE IDE.
DATABASE CONNECTIVITY
Both platforms have to support the major requirement of business, that of obtaining data from the relational database. For Java developers, this is done most typically using the JDBC libraries and an appropriate driver from the database vendor. Under .NET, this role is relegated to the ADO.NET libraries.
ADO.NET applications can take advantage of the flexibility and broad acceptance of XML. Because XML is the format for transmitting datasets across the network, any component that can read the XML format can process data. ADO.NET data components in Visual Studio encapsulate data access functionality in various ways that help us program more quickly and with fewer mistakes. ADO.NET accommodates scalability by encouraging programmers to conserve limited resources. Because any ADO.NET application employs disconnected access to data, it does not retain database locks or active database connections for long durations.
PRICE COMPARISION
Let us first consider the price of development environment. At the time of writing the price of Visual Studio .NET Enterprise version is US $1779. Sun's Sun[tm] ONE Studio 4 Enterprise version price is US$ 1995. For latest price information please refer the following links.
- http://msdn.microsoft.com/vstudio/howtobuy/pricing.asp
- http://wwws.sun.com/software/sundev/jde/buy/
Now consider the deployment environment. A consortium called the Transaction Performance Council (TPC) specifies the industry standard benchmark for transactional throughput and the benchmark is called the TPC-C benchmark. TPC members include Sun, IBM, Oracle, BEA, Microsoft, and most other companies that sell for the middle/data tier. The TPC-C benchmarks rates the highest workload that a system can achieve. The unit of measure is tpmC, for transactions per minute as defined by the TPC-C benchmark.
For J2EE application we have to buy WebLogic, websphere, iPlannet etc. That again depends whether the platform is AIX, UNIX, Solaris etc. The application server price varies according to the target platform. The .NET platform includes the following .NET Enterprise Servers. Many of these are repackaging of existing products under a common marketing term: - SQL Server 2000 is Microsoft's relational database.
- Exchange 2000 Server is a messaging and collaboration platform useful in developing and running core business services and is now tightly integrated with Windows 2000.
- Commerce Server 2000 offers you quicker and less complicated development and deployment of customizable online e-commerce solutions.
- Application Center Server 2000 lets us manage clustered servers.
- Host Integration Server 2000 gives you access to selected legacy systems running on other platforms (primarily IBM-based).
- Internet Security and Acceleration (ISA) Server 2000 offers firewall and Web caching capabilities.
- BizTalk Server 2000 is Microsoft's XML-based collaborative e-business solution for integrating applications, trading partners and business processes via the Internet.
Now consider hardware from well-known vendors for both servers.
J2EE Severs
| Company | System | tpmC | Total Sys. Cost | | Bull | Escala T610 c/s | 16,785 | $1,980,179 | | IBM | RS/6000 Enterprise Server F80 | 16,785 | $2,026,681 | | Bull | Escala EPC810 c/s | 33,375 | $3,037,499 | | IBM | RS/6000 Enterprise Server M80 | 33,375 | $3,097,055 | | Bull | Escala EPC2450 | 110,403 | $9,563,263 | | IBM | IBM eServer pSeries 680 Model 7017-S85 | 110,403 | $9,560,594 |
.NET Servers
| Company | System | tpmC | Total Sys. Cost | | Dell | PowerEdge 4400 | 16,263 | $273,487 | | Compaq | ProLiant ML-570-6/700-3P | 20,207 | $201,717 | | Dell | PowerEdge 6400 | 30,231 | $334,626 | | IBM | Netfinity 7600 c/s | 32,377 | $443,463 | | Compaq | ProLiant 8500-X550-64P | 161,720 | $3,534,272 | | Compaq | ProLiant 8500-X700-64P | 179,658 | $3,546,582 | | Compaq | ProLiant 8500-X550-96P | 229,914 | $5,305,571 | | Compaq | ProLiant 8500-X700-96P | 262,244 | $5,305,571 | | Compaq | ProLiant 8500-700-192P | 505,303 | $10,003,826 |
Now just compare a .Net server and J2EE server cost for same tpmC value.
COMPARISON OF BENCHMARKING APPLICATIONS.
Here is the comparison of Sun's Petstore and Microsoft's Petshop applications.
The main benefit of Microsoft .Net is that it's a complete platform -- J2EE is only oriented toward server development. More than that, J2EE is just a specification set -- you must purchase an expensive (usually $15,000/CPU) implementation of the J2EE specifications to make them real. Microsoft .Net, by contrast, is a set of products and services. In addition, Microsoft .Net has XML Web services built into the platform rather than as a simple bolt-on to a tool. This leads to substantial performance and developer productivity gains. Microsoft .Net was also built for integration through XML Web services using protocols and file formats such as SOAP, WSDL, and UDDI.
Let us compare rest of the features of .NET and J2EE as shown below.
| Parameter | J2EE | Microsoft .NET | | Platform | JRE Supported OS | Windows (CLR for FreeBSD is available) | | Languages | J2EE supports Java, and only Java | More than 20+, supports Java also | | Client side tools | Jbuilder, Visual Age, Forte, SunOne Studio | Visual Studio.NET | | Web Client | Java Applets are used to package Java code that will run within the browser | This is functionally equivalent to ActiveX | | Web tier | Java Servlets, Java Server Pages | ASP.NET, web services, web applications | | Middle Tier | Enterprise Java Beans (EJB). The current implementations of entity beans are dependent on middle tier data caches that are independent of the database caches. Unfortunately, there is no mechanism for maintaining coherency between the two caches. This means that any usage of entity beans introduces a high risk of database corruption. EJB flavors include (stateless and stateful) session beans and entity beans (component- and bean-managed), | .NET Remoting
COM/.NET Component The key ideas first introduced by MTS and then incorporated into both EJB and COM+. The first of the J2EE specifications, the EJB specification, came out in 1998. While .NET currently only includes support for components similar to stateless session beans
This represents a difference in architectural vision between Microsoft and the Java Community Process (JCP). | | Database Connectivity | Java Database Connection (JDBC) 2.0 - The API for accessing relational databases from Java | ADO.NET | | Directory services | Java Naming and Directory Interface (JNDI) - The API for accessing information in enterprise name and directory services from Java | This is somewhat similar to the Active Directory Services Interface (ADSI) in the .NET platform space | | Message Queue | Java Message Service (JMS) 1.0 - The Java API for asynchronous workflow. | This is functionally equivalent to Microsoft Message Queue API, which, in the component space, has been superceded by queued components | | Security | Java Authentication and Authorization Service (JAAS) | COM+ Security Call Context | | Interoperability | Sun has primarily focused on interoperability between J2EE vendors and, to a limited extent, with CORBA vendors. Sun's idea of interoperability is that it should be based on the communications protocol called IIOP. | The .NET platform eCollaboration model is, as I have discussed at length, based on the UDDI and SOAP standards. The reality today is that the .NET platform has a much stronger technology neutral eCollaboration strategy that does J2EE. IBM is so convinced that UDDI, rather than IIOP, is the correct approach to interoperability that it has broken with Sun over this issue. At this point, it is painfully obvious that IIOP, despite its ten year head start over UDDI, has been a complete failure | | Commerce | There is no equivalent vendor-neutral framework in the J2EE space | The .NET platform includes such an eCommerce framework called Commerce Server | | Clustering | Sun Clustering | Windows NLBS,
Application Center Server 2000 | | Web Security | Role based | Role based security
Code access security | | Types | Have primitive types and classes, primitive types are built-in; we write classes | Value types and reference types
Value types == primitive types that we can write
Reference types == class
All types extend System.Object | | Parameter passing | Pass-by-value semantics
Copies of object references are passed, not objects | Both pass-by-value and pass-by-reference
Exposed at the CLS/CLR level--languages can choose to support or not | | Exception | Exception-enforcement at compile-time only | CLR supports exceptions | | Components | Through well-known idioms (get/set methods, listeners)
Greater customization through BeanInfo. | Explicit support via attributes in IL
Again, languages support as they wish
Delegates provide loose coupling of callbacks
Events use delegates and IL attributes | | Polymorphism | All methods are virtual
Exceptions include private and static methods | All methods are nonvirtual by default
Methods can be marked virtual
Methods can also "hide" base-class virtuals | | Deployment | Deployment is a .jar file, sometimes
Configuration--manifest files,. properties files, deployment descriptors | Deployment is always an assembly (.EXE or .DLL)
Configuration--all done via XML (No Registry!) | | Versioning | Versioning is mentioned in manifest
No loader support | Version info exposed via attributes
Loader fully supports versioning | | Metamodel | Use java.lang.reflect (Reflection)
Allows for runtime discovery of type info
Use ClassLoaders for run-time manipulation of code | Use System.Reflection for run-time discovery
Use System.Reflection.Emit to create types | | GUI client apps | AWT was the first
Swing supercedes AWT in a big way | WinForms provide traditional GUI access
WebForms provide web-centric UI controls | | XML | Support through JAXP and external libraries
Used extensively in J2EE for deployment descriptors
Parsers, XSLT will be rolled into JDK 1.4 | Support intrinsic in System.XML.dll
Includes XPath, XSLT, XInclude, and so on
Used for configuration files |
LATEST INFORMATION
Microsoft has released the JUMP toolkit and J#.NET, making it as simple as possible to move from Java to C#. The C# language itself is designed to make Java ports quick, simple, and painless.
Halcyon Software has released iNET, a C#-to-JVM byte code translator, which plugs into the Visual Studio.Net suite of tools. iNET allows C# to be used to generate JVM byte code, later be executed within a Java Virtual Machine. The hook here is that the developer is targeting the Java runtime but working, learning and building in .NET languages.
Remotesoft has released Java.NET, a tool for running native Java code within the .NET environment. This convergence tool targets .NET as the runtime environment for the resulting application, written in Java. The product includes .NET-language access to Java class libraries and translation of native Java source to .NET-compatible C# and MSIL.
CONCLUSION
Microsoft .NET provide enterprise solutions in an efficient, scalable and cost effective manner. It supports so many features that cannot be done by J2EE. Hence with in few years Microsoft .NET definitely overtakes J2EE and make enterprise solution easier.
REFERENCE
The J2EE homepage: http://java.sun.com/j2ee
The Microsoft .NET homepage: http://www.microsoft.com/net
|
Articles 