Which is better to do J2EE or MS.NET from Industry Prospective?

I met one of old friend of mine on MCA examination center in New Delhi. He has completed BIT from IGNOU with me only in 2004.

I reached the examination center very early, I guess around 12:30 PM (IST) (Exam was supposed to start at 2 PM), so I was having too much time to relax before the examination, I was just scrambling around the MCA examination center aiming to find any of my old friend so that we can have a chat, of course on past life at PCTI, Pitampura, it was my Learning center for my BIT course.

Finally around 1:00 PM (IST) I met the guy I have just talked. He was just surprised to see me that I have also come for the examination. After a little bit old gossips. He came to the point and asked me the same question that my batch mates ask me.

“Which is better to do J2EE or MS.NET from Industry Prospective?”

I took few seconds to tell him “Go for .NET technologies”

And as normal phenomenon, he asked me again “Why so…why not J2EE…”

After that we just talked about the benefits of .NET over J2EE.

The first point I have discussed that Ease of Use and easy to Learn

Microsoft .NET offers a better integrated lower cost, easier to use, and more manageable environment for software development than the Java J2EE platform. It also offers a much better way to take advantage of low-cost Intel-based servers for enterprise-scale applications.

Relative to .NET, enterprise software development on the J2EE platform is like trying to count a herd of sheep by counting the legs and dividing by four. Sure, it can be done, but it takes longer, costs more, and is harder to change in response to future business challenges and opportunities.

A few years ago J2EE was a more competitive option because the Windows/Intel server platform was still not quite ready for very large-scale enterprise application deployment. That is no longer so. With Windows Server 2003, increasingly capable Intel-based server hardware, and the rapidly maturing Window/Intel server applications from Microsoft and other software vendors, Microsoft .NET is now able to meet even very large-scale enterprise applications requirements.

He asked again “What circumstances favor .NET over J2EE?”

The most important advantage for .NET over J2EE is in circumstances where minimization of total cost is a high priority. Notwithstanding "figures don't lie but . . ." claims to the contrary, Windows on Intel servers delivers much more bang for the buck than the mainframe or UNIX-based platforms typically used for J2EE deployment. If total cost of ownership (TCO) really matters then .NET is the obvious choice over J2EE.

A second important advantage for .NET over J2EE is anywhere Windows-based server infrastructure and related development and deployment skills are already in place. An organization with skilled BASIC, C, C++, and COBOL programmers already in place, that is already familiar with the Windows development environment, will get much further much faster and at much lower cost using .NET than by trying to turn everyone into Java programmers.

Third, projects aiming to take advantage of the opportunities created by the new Web services standards favor .NET over J2EE as well. Although the Java world is working hard to catch up, crucial Web services standards like XML, SOAP, and WSDL are built into .NET by design while they are still only, in effect, 'bolted on' to J2EE. Development and deployment of Web services applications is significantly easier, faster, and less costly on the .NET platform than it is on J2EE.

Overall, .NET is the better choice.

But I guess some of my friends who are working with J2EE technologies convinced him that J2EE is better and since we have also learned Java better in BIT course J2EE will be better option for you.

So he asked again “Are there any circumstances that favor J2EE over .NET?”

The obvious one is when applications, for one reason or another, absolutely must run on something other than Windows on Intel systems. If an application really must run on, say, IBM mainframes or Sun Solaris boxes, then Java/J2EE may be the only option (albeit a costly one).

The second is simply prior commitment to the Java platform and associated ready availability of Java/J2EE development, deployment and administration skills in-house. In effect, the more an organization or some organizational sub-unit is already using Java/J2EE, the more circumstances are likely to favor continuing to do so. But despite promises of easy, rapid development, the J2EE platform is a daunting one with a steep and difficult learning curve. So J2EE is a plausible option only for organizations that have already climbed that slope and paid the price of learning the platform -- not for those that have not already done so.Third, J2EE is a somewhat more appealing choice for organizations where there is a large proportion of existing UNIX-based IT infrastructure (e.g. Solaris, HP/UX, AIX and so forth) already in place. As a rough rule of thumb, the greater the proportion of UNIX-based servers already in place, the greater the relative advantage for J2EE versus .NET.

Then I told him a story to explain him that how big organizations are using .NET for building Web applications.

MIT have chosen .NET over J2EE as the toolkit for developing Internet applications. MIT comes from the open-source and UNIX world (and a lot of people there do anything they can to avoid anything Microsoft-related), so it would make sense for them to choose a more vendor-neutral platform (e.g., Apache/Tomcat/Java) and all the other open development tools available.

Would that be a fashion statement as well? What are the particular advantages of .NET over J2EE that made it the superior choice? In my mind, I would look at a solution that didn't require paying Microsoft's excessive licensing fees, and that used as much open-source software as possible.

And what about security?

A poorly-configured Apache server can be as bad as a poorly configured IIS server, but isn't it apparent that .NET servers will be less secure than their open-source counterparts (given the security track record of Microsoft products --at least in the short term)?

MIT as a whole is pretty wealthy but individual IT budgets tend to be modest. With only $1 or $2 million to spend per system MIT needs to put its money into capabilities that are valued by end-users. A true J2EE system would involve EJB and container-managed persistence. All of that automatically generated SQL code from the application server can be 100X slower than hand-authored SQL, which means MIT would have to buy 100 times as much computing hardware to support the same application.

Not to mention that projects that built on top of J2EE are famously unproductive, expensive, behind-schedule, and inflexible. If you had a $20 million, 3-year budget to build something simple like photo.net, you could certainly do it with J2EE (or raw C with the Oracle C library for that matter). But MIT needs to produce things sort of like photo.net with a few undergrads hacking away over a summer. And they need to be able to tear down 20 percent of it and add another 50 percent the next summer as ideas evolve.

J2EE also looks like a classical IT dead end. There are dozens of different application servers and execution environments for Java. All have subtle differences so that an application built for, say, WebLogic won't run under Tomcat or Websphere. Maybe the application be ported by changing only 1 percent of the code but it isn't obvious which 1 percent. This is the same situation that Unix presented in the early 1990s. An AIX application wouldn't just work on SunOS or HP-UX. Close but not compatible. Faced with all of these choices, most application developers chose to develop only for Windows. In the amount of time it would take MIT to evaluate and select the right Java application server, V1.0 of a system could be built and launched using the Microsoft tools.
Anyway, it wasn't my decision. So if MIT wants something that can be maintained and extended by its students and graduates.

Microsoft .NET is a logical choice for that reason as well.