J2EE 和 .NET之间的对比m

J2EE 和 .NET之间的对比

编者按：
　　.NET的理论可以说是照搬J2EE，用ASP+作交互VB.NET作后台，提供一个类似J2EE的完全解决方案，由于使用了C#，所以大大提高了速度，（C++ 比 Java快12 倍比VB快6倍），看起来使用C可能会超过使用JAVA的程序，但是JAVA是分布式运行，加上可以多系统的混合使用，在大型的分布服务器上，JAVA的效率是极高的。所以说可以这样理解，J2EE在IBM 、SUN等大公司的支持下很快会在高端占领绝大部分的市场，而.NET是免费的，SQL server还很低廉，加上XP本身就包含ASP.NET服务器，所以会很快占领低端的WEB市场。 不过有很多免费的J2EE服务器啊，而且是开源的，对于中小企业来说是很好的选择。不能认为J2EE比.NET贵。
　　目前而言J2EE于.NET之争已经开始，由于竞争引起技术的快速发展，将传统的ASP\PHP\CGI大大抛在后面，随着预编辑技术的不断提高，以后程序员将面临着两大选择，一是从传统的ASP转行到ASP+(C#) +VB.NET的格局，或着投入J2EE +J2SE的怀抱。
　　大家现在可能对与J2EE与.NET到底哪里好，凭什么说PHP、CGI将无法与这些新的技术竞争呢？
　　其实J2EE也不是什么新技术了，97年就有了。最近由于最近单位搞 J2EE的工程，我有性事实的领略到了J2EE + J2SE的魅力。
　　J2EE是JAVA的整体解决方案，J2SE是客户端解决方案，我了解的是IBM的J2EE解决方案，后台使用DB2 7.1数据库，前台使用IBM Web Sphere的Web JAVA服务器，加上J2SE的JAVA客户端程序，天天大约要存储10000条文件，平均每1小时并发用户大于30人，日使用人数达500人的 大型企业OA系统。
　　使用J2EE的解决方案可以大大加快速度，基本上服务器CPU占用率不超过80% 内存使用量400M左右，（使用DELL 4600）相比之下ASP + SQL Server的速度根本就不能比，不是说SQL Server慢，而是ASP慢，预编译技术，就是用内存作为数据库的计算区域，化一部分硬盘为存取区，平时不操作数据库，计算的时候在内存总运行，结构保存在存取部分，当存取区满了再一次保存到数据库，大大提高了运行速度和服务器的负载，相比之下，及时编辑的ASP\PHP\CGI就慢多了，因为每次访问都要读取数据库，这样服务器压力就相当大了，而更多地内存和硬盘空间帮不上忙，这样就会造成瓶颈，这也是为什么有磁盘矩阵的服务器编译预编译的程序要大大快于IDE的服务器了。
　　.NET的理论可以说是照搬J2EE，用ASP+作交互VB.NET作后台，提供一个类似J2EE的完全解决方案，由于使用了C#，所以大大提高了速度，（C++ 比 JAVA快12 倍比VB快6倍），看起来使用C可能会超过使用JAVA的程序，但是JAVA是分布式运行，加上可以多系统的混合使用，在大型的分布服务器上，JAVA的效率是极高的。所以说可以这样理解，J2EE在IBM 、SUN等大公司地支持下很快会在高端占领绝大部分的市场，而.NET是免费的，SQL server还很低廉，加上XP本身就包含ASP.NET服务器，所以会很快地占领低端的WEB市场。
　　现在让我们谈谈Coldfusion，它现在可以说一种比较聪明的做法，他使用预编辑技术，但是最关健的核心语言变成了可选择的形势，可以使用“C++”可以使用“JAVA”，甚至可以混用，这就大大的扩大的应用面积，即可以在大型分布系统用也可以在小型的单独服务器上执行，可以说是折中的方法，这个可以说是Macromedia进军程序开发市场的一个核心战略，不但泥补了Macromedia在程序开发上的不足，还取得众家之所长，加上Colufusion技术历史悠久（95年就已经得到广泛的应用了），还有jrun的支持，他可能会很快地占领部分中端市场，为J2EE和ASP.NET之争火上焦油。速度上的比较是:
　　低端比较
　　Colufusion 5.0ASP.NET beat1 J2EE (ASP.NET beat2目前没有测试）
　　中端比较
　　ColdfusionF 5.0=J2EEASP.NET beat1
　　高端比较
　　J2EECF5ASP.NET beat1 （据说ASP.NET beat2 速度是1的数倍，由于刚刚推出目前还不能下结论）
　　以上三种都是使用预编辑技术的语言，本人没有对传统PHP、ASP、CGI作比较， 因为那样不公平，也没有什么可价值，因为不是一个时代的产品。从可用的简易程度上来说，基本上都是C为基础（JAVA也是一种C)，写起来都相差不多，可以说他们都是近亲，呵呵！所以上学会一个了其他的都相差不多。
　　目前主要是成本上的差异，其中ASP.NET最便宜，系统自带，再买一个SQL Server 和VS.NET也不过6-7万人民币，Coldfusion 5.0相对在数据库方面比较灵活，下到Access上到Oracle 8.0都可以用。系统方面也非常的灵活，你既可以用免费的Linux,也可以用Windows系统,同样也可以用SUN的Solaris。也就是说Coldfusion Server 5 +Coldfusion Studio + 数据库价格可以在5 - 10万 之间，J2EE成本就高了，一套IBM J2EE (DB2 + Web Sphere)就得10万左右，加上系统软件，假如用SUN那就是天价了！所以从成本考虑ASP.NET适合低端，Colufusion可以在中间部分，J2EE就属于高端的产品了。

2007-09-17

J2EE与.NET的比较

关键字: J2EE .NET 比较

在企业应用软件开发领域，往往存在两种选择，那就是J2EE和.NET。

.NET来自于微软，是一套全能的框架平台，支持C++、C#、J++、VB、ASP等语言，能够解决C/S、B/S和单机等结构的软件开发需求。.NET平台将这些语言编译成CLR语言，使它们可以无差别的运行在.NET Framework上，是2000年以后微软最为重要的软件开发套件产品。.NET框架入门门槛较低、使用方便，并且微软对其提供了良好的文档支持和在线服务，目前已经拥有了一大批使用者和拥护者，也为很多程序员创造了良好的就业机会。

准确来说J2EE并不是框架，而是许多技术规范的集合。SUN公司1995年推出Java语言，其先进的理念、优美的语法、完善的面向对象思想、强大的语言特性、对微型设备和网络的良好支持，使得Java语言受到了世界上很多程序员的喜爱，并逐渐成为了世界上最受欢迎的程序开发语言。直到今天，Java语言一直是世界上程序员使用得最多的语言，各大语言都渗透到各个领域，并找到适合其发展的土壤，相信几年内这个排名不会被改变。随着经济发展，大型的分布式系统，远程协作访问系统，电信金融等行业软件企业软件需求越来越大，SUN公司不失时机的组成了JCP组织，通过联合世界上一些先进的软件公司和技术领导者，来定义JSR规范，逐渐形成了以Java语言为核心的J2EE技术群，已经推出近300项规范，涵盖软件开发的各个方向，大有做到无所不包之势。由于参与制定规范的公司，譬如IBM、富士通、BEA、ORACLE等公司技术实力雄厚，并且对规范都提供了软硬件支持，这些支持都是企业软件开发领域的支柱级作品，加上其平台无关性及开源作品繁多可选择性较强等特点，使J2EE阵营一直处于领先地位，有效的避免了出现一家独大的现象，使这一领域一直处于良性竞争的态势下，发展迅猛。在觉察到J2EE这一支奇兵出现的后，微软推出了.NET Framework，欲与之抗衡，但一直处于下风。

2000年以来关于J2EE和.NET之间的争论从来就没有停止过，这里本人不做定论，只列出他们各自的特点。

.NET：

1．  技术来自于一家公司

2．  支持多种语言

3．  软硬件均需要付费

4．  多数设计模式最佳实践灵感来源于J2EE阵营

5．  仅支持Windows操作系统

6．  无开源社区支持，是以框架开发者为主导的设计

7．  门槛很低，使用方便，学习成本较低

8．  新技术更新较慢

J2EE：

1．  技术来自于多家公司

2．  支持一种语言

3．  开源产品众多，免费框架居多，硬件和中间件需付费

4．  成果众多，相应的最佳实践设计模式层出不穷

5．  平台移植性好，支持所有操作系统，这一方面成本降低

6．  开源社区活跃，很多规范都是一线人员自己做出来的或者大量听取一线开发者的意见

7．  门槛较高，由于多且杂，需要开发人员花费很长时间才能熟悉整个体系

8．  这一阵营技术更新很快，新技术新标准层出不穷，适合技术爱好者

如何选择，请君自便。

注：如何学习J2EE技术

1．  通读规范

2．  看Sample

3．  写Demo

4．  读原码

5．  做项目

浅析J2EE与.NET平台之优劣 

作者：宋振宇  来源：CCW
 
毫无疑问，程序员，软件开发商，企业IT经理一直都在密切的关注着J2EE和.NET的发展，但是选择一个在性能，价格，时间上满足他们需求的平台却并不是一件简单的事情。本文试图在技术上做一个简单的比较，希望对于他们做选择时有所帮助。

一.技术概观

在表现形式上，J2EE是一组规范，而.NET更象是一组产品。但它们的目的都是为了企业应用提供分布式的，高可靠性的解决方案.它们在架构上有着很多的相似之处，下表是一个简单对照:
 

J2EE

.NET

通信协议

Remote Method Invocation over Internet InterOrb Protocol (RMI/IIOP)，XML

编程语言

Java

C#，VB.NET，COBOL

运行时环境

Java Virtual Machine (JVM)

Common Language Runtime (CLR)

胖客户端

Java Swing

Windows Forms

目录服务

Java Naming and Directory Interface (JNDI)

Active Directory Services Interface (ADSI)

数据访问

Java Database Connection (JDBC)，Java Connectors

ADO.NET

异步消息处理

Java Message Service (JMS)

Microsoft Message Queue

表示层技术

Servlets， Java Server Page(JSP)

ASP.NET

中间层组件模型

EJB，JavaBean

COM+，COM

安全访问

JAAS

COM+ Security
Call Context

事物处理

Java Transaction Server (JTS)

Microsoft Distributed Transaction Coordinator (MS-DTC)

开发工具

WebGain Visual Café
Borland JBuilder
IBM VisualAge 等
(第三方提供，规范本身没有定义)

Visual Studio

J2EE平台的构成

EJB - J2EE 中间层，完成商业逻辑；

JAAS - J2EE 处理认证和授权的API;

Java Connectors - J2EE 用于连接异种数据源的API，对上层来讲是透明的;

JSP， Java Servlets - J2EE的表示层技术，用于生成用户界面;

Java Virtual Machine - Java 语言运行环境；

JDBC - J2EE数据库访问；

JMS - J2EE的异步消息队列；

JNDI - J2EE的名字查找API，独立于目录服务器；

JTS - J2EE用于处理交易的API；

RMI/IIOP - J2EE的分布式对象的通讯API，提供了和CORBA交互的能力。

.NET平台构成

.NET Framework - .NET应用运行的基础；

IL (Intermediary Language) - 所有的.NET语言首先被编译成该中间语言，然后在CLR中运行；

SOAP - 用于服务访问的工业标准；

DCOM - 组件间通信协议；

MS-DTC - 用来在.NET平台上使用两阶段提交协议来处理分布式交易；

CLR - .NET应用的运行时环境；

COM+ - .NET的中间层模型，用于构建商务逻辑；

ADO.NET - .NET 对数据访问的API。

此外.NET平台还包括其他一些产品象Application Center Server，BizTalk Server ，NLBS (Network Load Balancing Service)，Commerce Server，Enterprise Servers，HIS (Host Integration Server)，ISAS (Internet Security and Acceleration Server)用来提供象防火墙，安全访问，B2B交易，负载平衡等服务.J2EE规范本身没有定义这些服务，但可通过选择第三方产品来满足类似的要求。
二.技术比较

1.一 vs 多

一种语言vs多种语言，一个平台vs多个平台.这似乎是大家最喜于津津乐道的话题，也似乎是所有问题的焦点。

两种平台主流的开发语言Java和C#在架构上有着惊人的相似：虚拟机技术，基于沙箱的安全模型，分层的命名空间，垃圾回收等。所以从第一眼看上去，C#简直就是Java的克隆。但微软并不这样认为，微软的说明是：“它集成了C++， Java，Modula 2，C和Smalltalk等多种语言的精华，对它们共同的核心思想象深度面向对象(deep object-orientation)，对象简化 (object-simplification)等都一一做了参考。”一方面，C#的大多数关键字来源于C++，使它在书写上有别于Java。但另一方面，C#的严格的类型转换等概念却明显来自于Java(当然，它的原始类型的定义更严格，并且据微软声称没有影响到效率.)，使其在内涵上有克隆之嫌.但即是Java，其有些特性也和Smalltalk颇有渊源.所以评价一种开发语言的优劣不仅是看其外在的表现形式，更重要的是其实实在在的功效.作为一种新语言，C#加入了基于XML的标记，可以被编译器用来直接生成文档，C#的另一个特点:一站式软件(one-stop-shopping software)强调了自解释( self-describing) 的编码方式，即头文件，IDL(Interface Definition Language)，GUID和其他复杂的接口无需再被引用.也即是C#，VB.NET等代码片断可以任意的被加入到其他语言中.这无疑在多种语言混合编程的模式中是一次飞跃，但是，其难维护性也是不言而喻的。

微软的.NET的平台提供了象C#，VB.NET，COBOL等多种开发语言，C#是新的，而其他的每一种语言都是在原有的基础上改造而来.这是微软煞费苦心并且也是不得以的要为习惯于这些语言的程序员铺一条便捷之路.但是，这些语言的改造与其说是整容到不如说是一次开膛破肚的大手术.首先是观念变了，Basic，Cobol等语言先天的缺少面向对象的内涵，现在却变成了面向对象的语言，这就不是要求其传统的程序员仅仅熟悉一些额外的关键字那么简单的问题了.基于面向对象的软件分析设计开发测试是完全不同于基于传统过程性语言的质变，所以这一过程的转变对传统程序员来讲也是一个痛苦和漫长的过程.在传统程序员面前，微软看似提供了丰富多采的解决方法，但对于实际问题而言，却怕是有些力不从心.所以一个简单的办法是:直接使用C#.对于独立软件开发商来讲，其转换成本不容忽视.其次，在一个软件项目中使用多种语言，开发商必须同时拥有多种语言专家和多个独立的难以互相支援的开发小组，无疑的，这也使其软件的维护的成本已非线性的曲线增长.多样性是双韧剑，实施时需仔细斟酌.

跨平台是J2EE的最大卖点，也是至今为止还绊住微软的栅栏.当开发商完成了符合J2EE规范的软件时，其客户可以依据其喜好和实力来选择不同应用服务器.从基于open source的免费软件到高端满足B2B需求的商业套件来搭建自己的平台.但是由于J2EE的规范还不完善，各个J2EE服务器的提供商为了使其提供其各自理解的完整的功能，不得不添加一些额外的特性.这就使得使用了这些特别功能的应用软件，绑定到了特定的应用服务器上.随着J2EE规范的发展，这种差别会逐渐减小.

微软的跨平台解决方案是Web services，它解决的是异种平台上不同应用之间的连通性问题.从技术角度讲，它除了以XML为介质之外没有什么新意.但它的重要意义在于:它是微软这样一个重量级选手所推出的，前景不容小视.构造和使用 Web services 的过程较为简单:

服务提供者用他所选择的语言构造服务;

服务提供者用WSDL(the Web Services Description Language)来定义该服务;

服务提供者在UDDI (Universal Description， Discovery， and Integration )中注册该服务;

使用者的应用程序从 UDDI中查找已注册服务;

使用者的应用程序通过 SOAP (the Simple Object Access Protocol )来调用服务.(SOAP使用HTTP来传递基于XML为表现形式的参数)

正如我们所讨论的: Web services解决的是异构平台上服务连通性的问题，但在现实中所更迫切需要的是如何在异构的平台上构造具有可扩展性，高可靠性，高可用性，故障冗余，错误恢复能力的企业应用.缺少这一点，从结构上讲，.NET平台还远未完善.

2.中间层

基于组件的软件开发技术可以在较高的级别上实现软件复用，加快企业软件开发的进程.在J2EE构架中， JavaBean和EJB(Enterprise JavaBeans) 被用来完成事物逻辑.其中EJB和 JavaBean 有着类似的模型，但它被用来创建分布式的企业应用.它定义服务器端组件的模型，具有以下一些特性:

生存期模型；

访问模型；

安全模型；

事物处理模型；

会话处理模型；

数据封装模型；

部署模型

根据这些模型，简单的编码就可完成复杂的功能。

在微软的.NET平台中，旧的COM 和 COM+的组件模型被新的组件模型所代替。增加了象基于沙箱的安全模型和垃圾回收等功能.并且实现了多重接口继承，扩展的元数据和新的代理模型等.旧有的COM和COM+组件也可被映射到新的运行环境中。

综上所述，两众架构在基于组件的中间层的设计上各有千秋，对于创建分布式的，复杂的，高效的，高可靠性的的应用程序都有着足够的能力。

3.表示层

两种架构都同时支持胖客户端和瘦客户端.即C/S模式和B/S模式.对于C/S模式，J2EE提供了替代Java AWT的Java Swing，同时作为可视化组件的JavaBean也可用来构造系统。对于B/S结构的表示层，J2EE使用 servlet ，JSP(Java Server Page) ，HMTL，WML，XML等工具来实现。

微软的胖客户端技术则由 Windows Forms代替了MFC.它们起的作用相同，在结构上 Windows Forms 被插入到.NET的运行时框架(runtime framework)和组件模型 (component model)中.在瘦客户模型中， ASP.NET代替了旧有的ASP和 HMTL， WML ，XML作为表示层。在 ASP.NET 中，C#，VB.NET等语言的代码片断可被自由引用.ASP.NET 页面被首先转换成中介语言( Intermediary Language)，然后再被 中介语言及时编译器(just-in-time IL compiler)编译，最后运行于公共语言运行环境中，并且 ASP.NET 提供了页面的缓冲，所以，其运行速度要远远快于ASP。

大体上，两种架构所使用的表示层的技术非常类似，虽在细节上各有所长，但总体功能当在伯仲之间。

4.数据访问

J2EE 和 .NET 已不同的形式支持数据的访问。JDBC和ADO一样和所连接的数据库无关，并且通过连接，命令语句和结果集来对数据进行操作.所以属于中间层次的 API.更高一级的数据封装和数据管理是通过实体EJB (entity EJB)来完成的.基于容器管理的实体EJB使开发更快捷，管理更方便.事实上，由于实体EJB的load()和store()方法的同步机制，将大大缓解因并发而使数据库产生的瓶颈.也可以采用不属于J2EE规范的第三方数据访问工具，象WebGain的 TopLink。

而微软的.NET的数据访问工具则由基于XML的ADO.NET代替了基于COM组件的ADO.任何以XML为输出的数据源都可以作为 ADO.NET 的数据源.相应的结果集升级为数据集 (DataSets)，命令语句则升级为数据集命令(DataSetCommands).从形式来看，微软的ADO.NET更新潮和时髦一些，基于XML的特性使其可以处理极其丰富的数据源，并且，因其构架在HTTP协议之上，易于穿透防火墙，使沟通更为便利.但由于XML本身的基于标记的特性，很明显限制了在有超大数据量和有网络瓶颈的应用中的使用.而J2EE的数据访问规则则显得略有单薄，但同时却更简单，更有效.并且通过对应用程序有效的层次的设计，对于数据库和基于XML的数据源的访问，也是可以无缝的整合的。

三.整体评价

在微软还没有足以和Java平台相对抗的产品的时候，微软所乐于做是大声的宣传:"write once， debug everywhere"。而它的对手则更乐于这样评价它:"微软开始也喜欢Java，他们喜欢它的方式是让它死去，他们当然也憎恨它，他们甚至憎恨每一个以J开头的单词。"但是现在，形式不同了，微软有了足以自豪的.NET他们可以已他们自己所喜好的方式来对J2EE和.NET来做各种比较。最热闹的应该算是微软出示的第三方对.NET Pet Shop和J2EE的 Pet Store的综合比较了.有兴趣的读者可以到MSDN，www.onjava.com，IBM开发者原地等网站看到相关评论。

&bsp;

J2EE

.NET

易用性

**

***

扩展能力

***

**

多平台支持

****

*

多语言支持

*

****

可靠性

***

***

性能

***

***

可管理性

***

***

重用性

****

**

负载平衡

***

***

开放标准

*****

*

就企业而言，内部众多系统的整合、系统的延展性、安全性是更需要注意的议题，而这些都是J2EE的优势，也是微软的不足处。 在效率方面，J2EE阵营主张通过硬件的效能增加来弥补软件的不足.开放标准，功能强大，易于移植这些都是J2EE的卖点。但让人奇怪的是IBM的WebSphere和BEA的WebLogic在J2EE市场占了大半壁江山，而作为规则制定者的SUN却在做壁上观。

微软确实提供了从桌面的办公软件，开发工具，到后台服务器数据库的全方位的产品。 但统一平台的使用者可能要牺牲跨平台的好处，并也有可能由此就被无穷无尽的锁定在微软的许可证的汪洋中.更简单，更快捷，更高效是微软的目标，随着时代的发展，我们也许会看到更完美的技术解决方案。

比较 Microsoft .NET 和 J2EE 的构成技术

作者：佚名  日期：2006-3-4 18:17:16  来源：不详  点击：  次  评论

即使你不在微软的平台上写程序，你可能也听过 Microsoft 推出的「.NET」平台，此技术是用来对付非微软阵营的兵器。如果你读过微软的新闻稿，或者你浏览过 MSDN 的内容，还是你出席了微软的专业程序员会议（也就是「.NET」平台现身的地方），你可能仍有两个疑问：

「.NET」平台到底是什么？
「.NET」架构和 J2EE 有哪些差异？

如果你想得更远一点，你还会有第三个问题：

我们能从「.NET」架构中学到一些哪些有助于推展企业软件开发的思维？

目前，「.NET」架构尚嫩，许多细节仍有待微软的「.NET」小组厘清。虽然如此，我们仍然能够从现有的信息中得到上述问题的解答。
「.NET」平台到底是什么？
现今大家对于「.NET」平台的看法有点类似寓言「瞎子摸象」，观点不同，自有不同的想法。有些人说「.NET」是微软的下一代 Visual Studio 开发环境；有些人说它是一个新的程序语言（C#）；还有些人说它是以 XML 和 SOAP 为基础的资料交换与传递讯息的机制。其实，上述三者都是「.NET」想扮演的角色，而且还不止于此。

让我们先得到一些较具体的观念。下面列出「.NET」平台内部的组成：

C# 是一个「新程序语言」，用来撰写类别和组件。C# 融合了 C/C++ 和 Java 的特色，还多了一些其它的特色，比方说 metadata tag。
一个「通用语言的执行时期系统（common language runtime）」，用来执行 IL 格式的程序代码。任何语言的原始程序只要被编译成 IL 格式之后，就可在「.NET」平台执行。
一组「基础组件」，提供多样的功能（例如：网络），以供执行时期系统使用。
「ASP+」，是新版的 ASP，能让 ASP 被编译成 IL 的格式。
「Win Form」和「Web Form」，是一组新的 UI 组件骨架，供 Visual Studio 使用。
「ADO+」，是新版的 ADO，使用 XML 和 SOAP 来进行资料存取和资料交换。
「.NET」和 J2EE 有哪些差异？
如你所见，「.NET」平台是一堆技术的组合。微软把这些技术当作现有技术（例如：J2EE 和 CORBA）的另一种选择，但实际上比较起来又是如何呢？下面是我们的一些分析比较：

Microsoft.NET

J2EE

主要差异

C#程序语言

Java程序语言

C#和 Java都源自 
C/C++。两者有相当多共同的主要特色（包括：自动内存管理、阶层式名字空间）。C#从J
 avaBeans学来一些组件观念（propertie/attribute、event），还新增了一些特色（比方说 
metadata tag），但是使用不同的语法。

Java
 可以在任何有 Java 虚拟机器的平台上执行。C#
 目前只能在 Windows 上执行。

C#
 使用IL的执行时期系统。透过 just-in-time (JIT)
 的编译方式或原生码编译方式来执行。Java 程序是透过
 Java 虚拟机器来执行，但是也可以编译成原生码。

「.NET」通用组件

Java core
 API

高阶的「.NET 宋体'; BACKGROUND: rgb(238,238,238); FONT-SIZE: 10pt; mso-spacerun: 'yes'">」组件将支持透过 
XML和 
SOAP 宋体'; BACKGROUND: rgb(238,238,238); FONT-SIZE: 10pt; mso-spacerun: 'yes'">来存取。（请看下面 
ADO+的介绍）

Active
 Server Pages+ (ASP+)

Java
 ServerPages (JSP)

ASP+将可以使用 
Visual Basic、C#、和其它语言来撰写程序片断，然后被编译成IL的格式（不像以前的 
ASP每次都需要直译）。JSP使用 Java的程序代码，编译成 
Java的 
bytecode（可以需要时才编译，也可以预先编译好）。

IL执行时期系统

Java虚拟机器、CORBA
 IDL、CORBA
 ORB

「.NET 宋体'; BACKGROUND: rgb(238,238,238); FONT-SIZE: 10pt; mso-spacerun: 'yes'">」允许不同的程序语言使用 
Windows上的同一套组件。

Java
 允许 Java bytecode 在兼容的虚拟机器上都可以执行。

CORBA
 允许不同语言和不同平台的对象互相沟通（必须有适合的
 ORB）。J2EE 中可以使用CORBA，但两者的整合度不算是很紧密。

Win Form和 
Web Form

Java Swing

类似的 Web组件在标准的 
Java平台中付之阙如，有些其它厂商在 
Java IDE中提供一些组件。

MS
 Visual Studio IDE 提供 Win Form 和 Web Form 的 RAD
 工具，目前尚未有其它厂商宣称要支持 Win Form 和 Web
 Form。许多 Java IDE 工具都支持 Swing。

ADO+和 
SOAP 宋体'; BACKGROUND: rgb(238,238,238); FONT-SIZE: 10pt">的Web服务

JDBC、EJB 宋体'; BACKGROUND: rgb(238,238,238); FONT-SIZE: 10pt">、JMS和 Java
 XML链接库（XML4J、JAXP）

ADO+允许透过 
HTTP  宋体'; BACKGROUND: rgb(238,238,238); FONT-SIZE: 10pt; mso-spacerun: 'yes'">进行 
XML资料交换（在远程资料对象和多层的程序之间），也就是SOAP。「.NET」的 Web服务使用 
SOAP的讯息模型。EJB、JDBC等则是把资料交换的通讯协议交由程序员自行决定，用 
HTTP、RMI/JRMP或 
IIOP都可以。

上面是各项技术的比较，下面是两者的整体比较：

特色：「.NET」和 J2EE 都提供许多相似的特色，虽然方法不见得完全一样。

　

可移植性：「.NET」只能在 Windows 上运作，但是理论上可以支持许多语言。而且，「.NET」支持 SOAP，使得不同平台的组件可以和「.NET」的组件交换讯息。虽然「.NET」中有些技术（比方说 SOAP 和其 discovery 与 lookup 机制）是公开的规格，核心的技术（比方说 IL 执行时期系统、ASP+、Win Form 与 Web Form）都还是由微软所把持，而且微软将会是「.NET」完整开发工具和平台的唯一提供厂商。

J2EE 则可以在任何有 JVM 的平台上执行，只要有兼容的服务（比方说：EJB 容器、JMS 等）即可。J2EE 的一切标准都是公开的，许多厂商都提供兼容的产品和开发工具。但是 J2EE 是一个单一语言的平台，如果要和其它语言平台沟通必须透过 CORBA（目前 J2EE 平台上不见得有支持 CORBA）。
整体来看
上面的各项分析指出「.NET」和 J2EE 的主要差异。微软正在「.NET」上做两件值得注意的事：开放「.NET」给其它程序语言的使用者，并开放「.NET」给非「.NET」组件的使用者（透过 XML 和 SOAP）。

因为「.NET」允许其它语言的组件整合进来，「.NET」赋予 Perl、Eiffel、Cobol 和其它语言的程序员在微软的平台上做事。各种语言的爱好者尤其喜欢这点，因为他们中多数人才不在乎微软和 Sun 以及开放阵营之间的战火。
大家的反应如何？
对微软的程序员来说：
如果你一直守着微软的架构，那么「.NET」的出现是一件好事。ASP+ 比 ASP 好；ADO+ 比 ADO 好；C# 比 C/C++ 好。「.NET」平台差不多要到 2001 才会现身，所以你还有时间准备。毫无疑问地，它将会变成微软预设的开发环境。如果你现在正在使用微软的开发工具，未来移转到「.NET」之后，你也会享受到这种种好处。

然而，「.NET」平台的一些目的太过崇高，不保证能达得到（至少短期内是如此）。比方说，IL 执行系统有一些很明显的难题待克服，想整合进此系统的每个语言必须清楚地定义如何对应到 IL，以及 IL 所需的 metadata。某语言要兼容于 IL 来必须提供编译器（x 语言转 IL，和 IL 转 x 语言）。

这有前例可寻。有许多编译器可将非 Java 语言转成 JVM 可执行的程序，这些语言包括了 JPython、PERCobol、the Tcl/Java project，有趣的是，连 Bertrand Meyer 和一些 Eiffel 语言的家伙也早在几年前就做出 Eiffel-to-JavaVM 的工具。其中只有 JPython 是成功的，其它的工具好象都没人在用，甚至连这些语言本身的族群都不用，虽然这些工具的出现使得他们能使用最爱的语言来写 Java 程序。为什么就是无法引起大家的热诚？我相信这是因为人们怀疑混合两种异质的语言环境会水土不服。如果他们想写在 JVM 上执行的程序，他们宁可花时间去学 Java 语言。我想，同样的情况也会出现在「.NET」平台上，人们宁可花时间去学 C# 来写「.NET」程序，而非使用其它语言。

还有一点要注意的：「.NET」使用的 SOAP 架构的性能值得观察。SOAP 使用 HTTP 来传递 XML。HTTP 不是有效率的通讯协议，而且 XML 还需要额外的文件剖析（parse），这又是计算上的负担。两者的结合会使得交易的速度大大低于其它方案。XML 是一个用途广、健全、又具涵义的讯息机制，而 HTTP 是一个广泛又能避免许多关于防火墙的问题，但是如果效率对你来说很重要，那么你应该多瞧瞧其它的方式，而不要用 SOAP。

对 Java 和 Open Source 族群来说：
「.NET」很容易被视为微软基于市场需求所推出的解决方案。其实，「.NET」是微软开始策略改变的征兆。以往微软在面对其它架构和平台有不错的战果，现在他们面对了来自 Java 和 open source 的压力，开始有了「开放」的迹象，也试着直接去满足程序员的需求，这可是和以往的老大作风大不相同。如果你是 Java 或 open source 的爱好者，请注意：这场战争的本质已经有所改变了。

而且，微软的 IL 执行时期系统有一点值得注意的目标：消弭程序语言和 API 之间的藩篱。Java 消弭了平台间的藩篱，但是如果你想使用 J2EE，你就必须搭配 Java 语言。「.NET」想让你使用你喜爱的语言来开发「.NET」程序，这点是很了不起的（但结果是否会成真仍是个大问号）。从这点来看，J2EE 就比不上「.NET」，但是这点应该不算太重要。

J2EE 如果想迎战「.NET」，有几个议题应该立刻被注意到。首先，J2EE 应该将 XML 好好地整合进来。我不是指制定 XML SAX/DOM 的 API，也不是指拿 XML 当作设定档格式，我说的是 XML 的讯息交换和处理应该被加进 J2EE。当然，目前你可以用 XML 格式当作 JMS 讯息内容，但整个 J2EE 却不会因此受益。XML 是一堆标准的集合，包括业界标准的 API 和 DTD，这应该都是资料交换时可以享受到的好处才是。

但是微软把赌注下在 SOAP 上，而且正积极地将 SOAP 的相关信息传送给程序员。J2EE 也应该如此，我想到的方法之一是在 JMS 上加一层 XML messaging provider，并整合进 Java Naming and Directory Interface（JNDI）和 LDAP、NIS、COS Naming 等技术。这样就等于是结合了 SOAP/BizTalk provider、ebXML provider 等技术。


本文作者：Jim Farley，着有 Java Distributed Computing、Java Enterprise in a Nutshell（合着）