J2EE vs. Microsoft.NET(7)

原创 2001年08月13日 20:43:00
Performance 

A platform performs if it yields an acceptable response time under a specified user load. The definition of what is 'acceptable' changes for each business problem. To achieve acceptable performance, it is important that the underlying web services infrastructure empowers you to build high-performing systems. 

The primary bottleneck when building web services is usually integration with back-end database systems. The reason for this is that most enterprise applications are data-driven systems with much more data logic than business logic. Given that the database is usually the bottleneck, any possible tactics for reducing database load will result in a significant wins. 

J2EE reduces database traffic through two tactics: 

Stateful business processes allow you to maintain business process state in memory, rather than writing that state out to the database on each request. 

Long-term caching (provided by some implementations) allow for database data to be cached for long periods of time, rather than re-reading database data upon each request. 
It should be noted that both maintaining business state in-memory and caching must be used with caution, and may result in problems if developers are not properly trained on when to (and when not to) use these features. This is a fundamental difference between the J2EE and .NET approaches to building web services: J2EE's advantage is that it gives programmers more control over lower-level services such as state management and caching. Well-educated developers can tap into these features to improve the quality of their deployment. But it is of vital importance that developers are properly educated on when to make these tradeoff decisions, or error may be introduced into systems. 

By way of comparison, Microsoft.NET does not offer these tactics for improving performance. There are no opportunities for performance wins, but at the same time, there are no opportunities for developers to introduce errors into systems. 

When trying to choose between whether these features are important for your organization, consider the quality of your developers. If they are well-educated and do not require much hand-holding, then they will likely find the flexibility and performance gains from a J2EE system as valuable. If your developers require more hand-holding, then the Microsoft approach is clearly superior. 



Scalability 

Scalability is essential when growing a web services deployment over time, because one can never predict how new business goals might impact user traffic. 

A platform is scalable if an increase in hardware resources results in a corresponding linear increase in supported user load while maintaining the same response time. By this definition, the underlying hardware (Win32, UNIX, or Mainframe) is irrelevant when it comes to scalability, because both J2EE and .NET allow one to add additional machines to increase user load while maintaining the same response time. The major implementations based on J2EE architecture, as well as .NET, provide load-balancing technology that enable a cluster of machines to collaborate and service user load that scales over time. 

The significant difference between J2EE and .NET scalability is that since .NET supports Win32 only, a greater number of machines are needed than a comparable J2EE deployment due to processor limitations. This multitude of machines may be difficult for organizations to maintain. 




VI. Conclusions 

--------------------------------------------------------------------------------

The J2EE verses .NET battle will be the soap opera of the decade for geeks to watch. But there are promises and realities about both platforms. For example, J2EE is a rather brilliant move on the vendors' part, but should not be seen as an altruistic initiative. All vendors that participate in J2EE are after financial gains, as well as an effective weapon against Microsoft. J2EE enables these vendors to collaborate together and stand ground. Many of these vendors have undergone recent mergers and acquisitions themselves, and so organizations must exercise good judgment when choosing such a platform. 

As far as Microsoft.NET, that is far from an altruistic initiative. It is a monopolistic initiative dressed in altruism. Microsoft has been claiming that .NET is about open and interoperable web services, when in reality Microsoft is already making their web services closed and proprietary. Microsoft will likely increase the costs of their solutions if a monopoly can be achieved, and innovation will be slowed down significantly. 

So what's a company like yours to do? Both platforms are useful, and both can lead you to the same destination. Which platform is right for you? When deciding, we recommend you concentrate on the larger business issues. Think about your existing developer skillsets, your existing systems, your existing vendor relationships, and your customers. Those almost always drive the decision, not the minor features. 

Arguments supporting both platforms 

Regardless of which platform you pick, new developers will need to be trained (Java training for J2EE, OO training for .NET) 
You can build web services today using both platforms 
Both platforms offer a low system cost, such as jBoss/Linux/Cobalt for J2EE, or Windows/Win32 hardware for .NET. 
Both platforms offer a single-vendor solution. 
The scalability of both solutions are theoretically unlimited. 
Arguments for .NET and against J2EE 

.NET has Microsoft's A-team marketing it 
.NET released their web services story before J2EE did, and thus has some mind-share 
.NET has a better story for shared context today than J2EE 
.NET has an awesome tool story with Visual Studio.NET 
.NET has a simpler programming model, enabling rank-and-file developers to be productive without shooting themselves in the foot 
.NET gives you language neutrality when developing new eBusiness applications, whereas J2EE makes you treat other languages as separate applications 
.NET benefits from being strongly interweaved with the underlying operating system 
Arguments for J2EE and against .NET 

J2EE is being marketed by an entire industry 
J2EE is a proven platform, with a few new web services APIs. .NET is a rewrite and introduces risk as with any first-generation technology 
Only J2EE lets you deploy web services today 
Existing J2EE code will translate into a J2EE web services system without major rewrites. Not true for Windows DNA code ported to .NET. 
.NET web services are not interoperable with current industry standards. Their BizTalk framework has proprietary SOAP extensions and does not support ebXML. 
J2EE is a more advanced programming model, appropriate for well-trained developers who want to build more advanced object models and take advantage of performance features 
J2EE lets you take advantage of existing hardware you may have 
J2EE gives you platform neutrality, including Windows. You also get good (but not free) portability. This isolates you from heterogeneous deployment environments. 
J2EE has a better legacy integration story through the Java Connector Architecture (JCA) 
J2EE lets you use any operating system you prefer, such as Windows, UNIX, or mainframe. Developers can use the environment they are most productive in. 
J2EE lets you use Java, which is better than C# due to market-share and maturity. According to Gartner, there are 2.5 million Java developers. IDC predicts this will grow to 4 million by 2003. 78% universities teach Java, and 50% of universities require Java. 
We would not want to use any language other than C# or Java for development of new mission-critical solutions, such as a hacked object-oriented version of C, VB, or COBOL. 
We are finding most ISVs and consulting companies going with J2EE because they cannot control their customers' target platforms. We believe this application availability will result in J2EE beginning to dominate more and more as time goes on. 
In conclusion, while both platforms will have their own market-share, we feel most customers will reap greater wins with J2EE. We feel the advantages outweigh those offered by Microsoft.NET. That is our preferred architecture, and we stand behind it. 


J2EE学习篇之--Spring技术详解

Spring是一个开源的控制反转(Inversion of Control ,IoC)和面向切面(AOP)的容器框架.它的主要目得是简化企业开发....
  • jiangwei0910410003
  • jiangwei0910410003
  • 2014年05月28日 10:15
  • 6502

J2EE——Jsp的学习

JSP(Java  Server Page)Java服务端网页,是一种动态的网页技术,这和.NET中的ASP的功能是一样的。JSP是由sun规定的一套标准一套规范,也是J2EE的13规范之一。说一句...
  • liujiahan629629
  • liujiahan629629
  • 2014年02月17日 19:27
  • 5290

64位Windows操作系统部署ASP.NET Web应用常见问题

IIS 6切换32/64位运行模式 一、32位模式 1、cscript%systemdrive%\inetpub\adminscripts\adsutil.vbs setw3svc/appPool...
  • wildboy2001
  • wildboy2001
  • 2013年05月13日 13:56
  • 4640

.net(偏web) vs j2ee的一些框架选型

带链接的完整版本: http://files.cnblogs.com/lovecindywang/.net.pdf http://files.cnblogs.com/lovecindywang/j...
  • ddxkjddx
  • ddxkjddx
  • 2012年08月07日 14:11
  • 467

.Net vs. J2EE

  • 2012年11月16日 10:02
  • 2.08MB
  • 下载

.Net VS J2EE

  • 2007年07月31日 14:35
  • 2.08MB
  • 下载

浅析J2EE与.NET平台优劣

J2EE .NET 通信协议 Remote Method Invocation over Internet InterOrb Protocol (RMI/IIOP),XML 运行时环境 J...
  • lansechuixue
  • lansechuixue
  • 2011年11月21日 23:17
  • 863

J2EE架构和.NET架构的相关知识

1.J:ZEE架构 J2EE(Java 2 Platform Enterprise Edition)是由Sun公司主导、备厂商共同制定并得到广泛认可的工业标准。业界各主要中间件厂商如IBM、Orac...
  • yaonianlong
  • yaonianlong
  • 2013年10月10日 08:58
  • 605

一个简单单点登录SSO的实现(.net到j2ee)

单点登录实现的方式有很多,这里介绍一种
  • jrn1012
  • jrn1012
  • 2014年05月15日 21:26
  • 1115

J2EE与.NET技术架构的比较

●技术与应用 J2EE与.NET技术架构的比较 岳福香 (电信科学技术第十研究所  西安  710061) 摘  要:从体系架构、移植性、性能、安全性、稳定性、可扩展性、成熟度、第三方厂商...
  • cztq15
  • cztq15
  • 2012年11月20日 10:17
  • 1714
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:J2EE vs. Microsoft.NET(7)
举报原因:
原因补充:

(最多只允许输入30个字)