通过本文主要向大家介绍了j2ee和 net的区别,j2ee net,j2se和j2ee的区别,javaee和j2ee的区别,j2ee和java的区别等相关知识,希望对您有所帮助,也希望大家支持linkedu.com www.linkedu.com
关于.NET技术与Sun公司的Java2企业版（J2EETM）相比较，许多客户都想了解Microsoft公司的观点。由于以下的几个原因，.NET和JEE的比较有点棘手：
1) 一般来说，Windows .NET Framework是Microsoft的Windows系统中经过精心定义的技术部分，而J2EE则是一个书面的协议。如果不局限于学术方面的讨论，换句话说，就是在几个应用平台上讨论这个话题的商业价值，那么仅仅比较J2EE和一个实际应用的工具是没有意义的。
这样实际应用的工具如：IBM公司的WebSphere应用服务，BEA的WebLogic服务或是其它类似的应用服务。
要想得到令人满意的分析，只有进行产品之间的比较，例如比较开发效率。使用J2EE，开发者需要创建4个组件来建立一个单一的EJB。表面上看来，这只不过是为开发效率付出的一点代价而已。但是Java的一些开发工具隐藏了一些开发技巧，降低了效率。另一个例子，J2EE的部署体系十分复杂难解，类嵌入 JAR，而JAR嵌入WAR，WAR又嵌入EAR。但是在一定程度上，有些工具能自动完成部署进程。上述情况导致决定一个应用服务商业价值的关键因素开发效率因不同的销售商而有差异，这主要取决于开发工具的效率。
2) 关于"J2EE全明星队伍"的问题。当比较.NET和J2EE所有组件的集合时，这个问题就产生了。例如，分析者考虑开发效率时可能碰到下列问题，A公司的产品， B公司的应用服务程序， C公司的安全规则， D公司简便安装， E公司决定价格。所有这些都可能和J2EE有关。集合上述这些特征属性，J2EE工具看起来还行：价格便宜，安装简便，速度快，安全性高，有超高速缓存，并且有好的开发工具，等等。但这些都无关痛痒—因为不可能同时获得所有的这些特性。事实上，一次只能得到一个准确的特性。因为这些产品来自不同的公司，它们不可能合作无间。例如，IBM公司的工具不能和BEA公司的WebLogic服务同时工作，因为后者是用的Oracle公司的缓存引擎，而 Oracle的引擎不能用Iona的价格获得，等等诸如此类。人们有时候会误将"J2EE的所有特性集合"作为比较的基础；但这是不合理的。客户需要的是知道一对一，产品对产品的比较。
3）比较.NET和J2EE而忽视其它应用平台是十分重要的。J2EE是仅关注应用程序服务器的规范。但是绝大多数客户对下列这些感兴趣：应用程序服务器，端口，商业服务器和分析工具，数据库，分离数据和流动性，信息代理，应用程序集合，容量管理，智能客户端等等。作为对客户要求的回应，这些因素应该统一工作，所有的主要销售商应该推行整合的平台。例如Microsoft的平台（包括Windows系统的客户端和服务器，Windows .NET Framework，Visual Studio.NET Framework，和Microsoft企业服务器）；BEA的WebLogic平台；IBM公司的WebSphere平台；Oracle的平台；还有Sun公司的一个平台。将精力集中在这些平台的一个难题（应用服务器）上将会导致一个类似"树林和森林"关系的问题。这样的一个比方是合适的，但是它应该被考虑到一个更广阔平台的一部分。
从Microsoft的角度来看，和那些不常见的警告相比，这些是Windows .NET Framework和基于J2EE的产品的关键性的异同点。
相似点
1） Windows .NET Framework和Java都有一个受控的运行时环境，它不但将源代码转换成中间语言，而且将这些中间语言编译成本地的可执行代码。两个环境都支持碎片整理、动态类加载和异常处理等。
2） .NET和Java都倡导和支持基于组件的设计、多态性、继承和接口等，也提供基础类库来执行I/O、XML处理、带有连接池的数据库接入、文本操作与网页脚本编写等。
3） 两者都经过特有的销售商的产品进行发布。J2EE规范自己是"销售中立"的，但实际上那些遵从规范的产品都必须实现规范外的特性，例如管理特性或是展开特性。因此，这些产品必须是对应特定的销售商。例如Microsoft公司的Windows和.NET系统。
4） Windows .NET Framework和基于J2EE的产品都和第三方的产品一起工作。例如，在后端数据库领域，.NET和基于J2EE的应用程序能访问储存在Microsoft的SQL服务器、IBM的DB2、Oracle，Informix、Sybase等服务器里面的数据。再举一个例子，.NET和基于J2EE的系统能访问流行的信息中间设备，如Microsoft的MSMQ或是IBM的MQSeries。同样，也包括文件系统，第三方开发工具，代码版本系统，防火墙等。
不同点
1） 原理
J2EE是一个单一语言的平台，关注跨平台的可移植性。这就意味着，要利用J2EE，设计方案能使用多个操作系统其中的一个，但开发者必须接受关于Java的培训。Microsoft提供的.NET构架作为Windows系统的一部分。开发者能使用多种语言，并且效率很高而不用进行一种新语言的重新训练。但.NET Framework是 Windows系统的一部分。
2） 宽度和广度
a. .NET包括代码、产品、工具和构架，来利用网络上全部的计算资源，包括设备、个人电脑和服务器等。.NET使所有的这些设备能经过标准通讯协议全部连接在一起，即所谓的"XML WEB服务"。（.NET应用程序可以和任何一个系统连接，无论系统用什么语言和平台，甚至是J2EE。只要目标系统遵照XML WEB服务标准。）.NET模型是广泛的分布式计算，它和许多代码互相通讯并交换信息。
b. J2EE是面向服务器的模型，它并不开发网络上的智能和计算功能。总的来说，基于J2EE的产品只支持服务器端的应用程序。J2EE一般把PC只看作是一个HTML的浏览器，而将这些设备认为是哑终端。至于 XML WEB服务，现有的协议标准支持分布式的计算，现有版本的J2EE规范并没有提到XML WEB服务的问题，但是基于J2EE的产品在添加了附加装置后也可以支持XML Web服务。然而，添加附加装置也就意味着有严格的限制。例如，还不清楚现有的规范是否允许EJB调用Web服务，虽然Web服务的组件能调用一些EJB程序。
3） 编程模型的一致性
Windows .NET Framework提供了一个跨服务器、PC和其它设备的一致的、面向组件的模型。而J2EE提供EJB作为服务器端的组件模型；为客户端或是本地组件建立开放的完全用Java编写的API；为用户界面提供servlet；也为移动设备提供另一种不同的模型。甚至在EJB内部也有至少3种明显不同的子模型，每一种子模型都有不同的语言定义。
Microsoft的.NET编程模型与Java平台相比较，在各种服务器和客户端上有更好的一致性。J2SE是基于开放的完全用Java编写的API，而J2EE是基于Java servlet和EJB。
DH Brown, 2002年7月
4） 功能
a. Windows .NET Framework 提供一个能识别版本的类加载器，这就意味着应用程序的开发者能确保他们开发的应用程序在一部分代码已经更新的情况下仍能运行。而Java和J2EE（现有的）没有版本识别的类加载器，这就意味着开发者和管理员不能保证代码被执行时是正确的。或是说，开发者只能靠运气来保证这一点。
b. Windows .NET Framework 显示了语言层面上的类属性—这就使得编程更加简单。例如，在源代码中只用一个简单的属性就能把.NET组件标志为处理模式。或者说，一个.NET组件和 XML的串行化可以在一个属性中被定义。这个机制大大简化了许多编程任务。而Java不显示语言层上的类属性，虽然Sun公司考虑到要修改Java语言来改变现状。这种变化估计在两三年内才能第一次实现。
c. .NET还支持分离数据访问，这主要用于在移动设备或是偶尔联网的场合里运行的应用程序。数据能被脱机操作，接着再和起始数据重新同步。而不论是J2EE还是J2SE现阶段都不支持分离数据访问，需要这项功能的 J2EE开发者必须自己写"plumbing code"。
d. 为建立基于网络的用户界面， Windows .NET Framework提供基于事件的模型，这些模型类似于流行的Visual Basic中的智能客户端模型。ASP .NET 模型使得建立、发布和维护一个基于网络的用户界面变得更加容易。与之形成对比的是，J2EE在JSP中不支持这样的模型。有一些第三方的扩展程序部分弥补了这些功能，但是它们的实用性和简便性不能和ASP .NET相比。作为一个推荐的J2EE附加程序，Java Server Faces可能做到这一点。但这个附加程序并没有包括在J2EE的1.4版本以前。而要获得销售商的支持，则又需至少一年的时间。
e. J2EE支持一个对象相关的数据映像模型，它被称作EJB Entity Beans。这样是为了允许开发者更容易地从一个相关的数据库建立对象模型。然而，实际上把这个想法编程实现却要面对下列问题：
Ⅰ. 易用性：当那些熟知的、正规定义的、被广泛支持的结构化查询语言（SQL）和开发者的数据相互作用时，开发者不得不放弃它们，而使用一个被称为EJBQL 的弱定义查询语言。和SQL相类似，EJBQL的功能并不强大（例如，在现有的规范中，它没有ORDER BY的语句，这样开发者就没法使用特定数据库的 SQL扩展），而它的语义也没有被正规定义。还有，在对象间建立联系和附属关系十分困难，而且在对象间和XML以及后端之间的数据翻译是手动控制的。
Ⅱ.性能：基于EJB系统的性能仍是一个未知数。没有提供公开的基准。客户反映，得到的性能远远偏离了Entity Beans，并且转向一个更直接的数据访
1) 一般来说，Windows .NET Framework是Microsoft的Windows系统中经过精心定义的技术部分，而J2EE则是一个书面的协议。如果不局限于学术方面的讨论，换句话说，就是在几个应用平台上讨论这个话题的商业价值，那么仅仅比较J2EE和一个实际应用的工具是没有意义的。
这样实际应用的工具如：IBM公司的WebSphere应用服务，BEA的WebLogic服务或是其它类似的应用服务。
要想得到令人满意的分析，只有进行产品之间的比较，例如比较开发效率。使用J2EE，开发者需要创建4个组件来建立一个单一的EJB。表面上看来，这只不过是为开发效率付出的一点代价而已。但是Java的一些开发工具隐藏了一些开发技巧，降低了效率。另一个例子，J2EE的部署体系十分复杂难解，类嵌入 JAR，而JAR嵌入WAR，WAR又嵌入EAR。但是在一定程度上，有些工具能自动完成部署进程。上述情况导致决定一个应用服务商业价值的关键因素开发效率因不同的销售商而有差异，这主要取决于开发工具的效率。
2) 关于"J2EE全明星队伍"的问题。当比较.NET和J2EE所有组件的集合时，这个问题就产生了。例如，分析者考虑开发效率时可能碰到下列问题，A公司的产品， B公司的应用服务程序， C公司的安全规则， D公司简便安装， E公司决定价格。所有这些都可能和J2EE有关。集合上述这些特征属性，J2EE工具看起来还行：价格便宜，安装简便，速度快，安全性高，有超高速缓存，并且有好的开发工具，等等。但这些都无关痛痒—因为不可能同时获得所有的这些特性。事实上，一次只能得到一个准确的特性。因为这些产品来自不同的公司，它们不可能合作无间。例如，IBM公司的工具不能和BEA公司的WebLogic服务同时工作，因为后者是用的Oracle公司的缓存引擎，而 Oracle的引擎不能用Iona的价格获得，等等诸如此类。人们有时候会误将"J2EE的所有特性集合"作为比较的基础；但这是不合理的。客户需要的是知道一对一，产品对产品的比较。
3）比较.NET和J2EE而忽视其它应用平台是十分重要的。J2EE是仅关注应用程序服务器的规范。但是绝大多数客户对下列这些感兴趣：应用程序服务器，端口，商业服务器和分析工具，数据库，分离数据和流动性，信息代理，应用程序集合，容量管理，智能客户端等等。作为对客户要求的回应，这些因素应该统一工作，所有的主要销售商应该推行整合的平台。例如Microsoft的平台（包括Windows系统的客户端和服务器，Windows .NET Framework，Visual Studio.NET Framework，和Microsoft企业服务器）；BEA的WebLogic平台；IBM公司的WebSphere平台；Oracle的平台；还有Sun公司的一个平台。将精力集中在这些平台的一个难题（应用服务器）上将会导致一个类似"树林和森林"关系的问题。这样的一个比方是合适的，但是它应该被考虑到一个更广阔平台的一部分。
从Microsoft的角度来看，和那些不常见的警告相比，这些是Windows .NET Framework和基于J2EE的产品的关键性的异同点。
相似点
1） Windows .NET Framework和Java都有一个受控的运行时环境，它不但将源代码转换成中间语言，而且将这些中间语言编译成本地的可执行代码。两个环境都支持碎片整理、动态类加载和异常处理等。
2） .NET和Java都倡导和支持基于组件的设计、多态性、继承和接口等，也提供基础类库来执行I/O、XML处理、带有连接池的数据库接入、文本操作与网页脚本编写等。
3） 两者都经过特有的销售商的产品进行发布。J2EE规范自己是"销售中立"的，但实际上那些遵从规范的产品都必须实现规范外的特性，例如管理特性或是展开特性。因此，这些产品必须是对应特定的销售商。例如Microsoft公司的Windows和.NET系统。
4） Windows .NET Framework和基于J2EE的产品都和第三方的产品一起工作。例如，在后端数据库领域，.NET和基于J2EE的应用程序能访问储存在Microsoft的SQL服务器、IBM的DB2、Oracle，Informix、Sybase等服务器里面的数据。再举一个例子，.NET和基于J2EE的系统能访问流行的信息中间设备，如Microsoft的MSMQ或是IBM的MQSeries。同样，也包括文件系统，第三方开发工具，代码版本系统，防火墙等。
不同点
1） 原理
J2EE是一个单一语言的平台，关注跨平台的可移植性。这就意味着，要利用J2EE，设计方案能使用多个操作系统其中的一个，但开发者必须接受关于Java的培训。Microsoft提供的.NET构架作为Windows系统的一部分。开发者能使用多种语言，并且效率很高而不用进行一种新语言的重新训练。但.NET Framework是 Windows系统的一部分。
2） 宽度和广度
a. .NET包括代码、产品、工具和构架，来利用网络上全部的计算资源，包括设备、个人电脑和服务器等。.NET使所有的这些设备能经过标准通讯协议全部连接在一起，即所谓的"XML WEB服务"。（.NET应用程序可以和任何一个系统连接，无论系统用什么语言和平台，甚至是J2EE。只要目标系统遵照XML WEB服务标准。）.NET模型是广泛的分布式计算，它和许多代码互相通讯并交换信息。
b. J2EE是面向服务器的模型，它并不开发网络上的智能和计算功能。总的来说，基于J2EE的产品只支持服务器端的应用程序。J2EE一般把PC只看作是一个HTML的浏览器，而将这些设备认为是哑终端。至于 XML WEB服务，现有的协议标准支持分布式的计算，现有版本的J2EE规范并没有提到XML WEB服务的问题，但是基于J2EE的产品在添加了附加装置后也可以支持XML Web服务。然而，添加附加装置也就意味着有严格的限制。例如，还不清楚现有的规范是否允许EJB调用Web服务，虽然Web服务的组件能调用一些EJB程序。
3） 编程模型的一致性
Windows .NET Framework提供了一个跨服务器、PC和其它设备的一致的、面向组件的模型。而J2EE提供EJB作为服务器端的组件模型；为客户端或是本地组件建立开放的完全用Java编写的API；为用户界面提供servlet；也为移动设备提供另一种不同的模型。甚至在EJB内部也有至少3种明显不同的子模型，每一种子模型都有不同的语言定义。
Microsoft的.NET编程模型与Java平台相比较，在各种服务器和客户端上有更好的一致性。J2SE是基于开放的完全用Java编写的API，而J2EE是基于Java servlet和EJB。
DH Brown, 2002年7月
4） 功能
a. Windows .NET Framework 提供一个能识别版本的类加载器，这就意味着应用程序的开发者能确保他们开发的应用程序在一部分代码已经更新的情况下仍能运行。而Java和J2EE（现有的）没有版本识别的类加载器，这就意味着开发者和管理员不能保证代码被执行时是正确的。或是说，开发者只能靠运气来保证这一点。
b. Windows .NET Framework 显示了语言层面上的类属性—这就使得编程更加简单。例如，在源代码中只用一个简单的属性就能把.NET组件标志为处理模式。或者说，一个.NET组件和 XML的串行化可以在一个属性中被定义。这个机制大大简化了许多编程任务。而Java不显示语言层上的类属性，虽然Sun公司考虑到要修改Java语言来改变现状。这种变化估计在两三年内才能第一次实现。
c. .NET还支持分离数据访问，这主要用于在移动设备或是偶尔联网的场合里运行的应用程序。数据能被脱机操作，接着再和起始数据重新同步。而不论是J2EE还是J2SE现阶段都不支持分离数据访问，需要这项功能的 J2EE开发者必须自己写"plumbing code"。
d. 为建立基于网络的用户界面， Windows .NET Framework提供基于事件的模型，这些模型类似于流行的Visual Basic中的智能客户端模型。ASP .NET 模型使得建立、发布和维护一个基于网络的用户界面变得更加容易。与之形成对比的是，J2EE在JSP中不支持这样的模型。有一些第三方的扩展程序部分弥补了这些功能，但是它们的实用性和简便性不能和ASP .NET相比。作为一个推荐的J2EE附加程序，Java Server Faces可能做到这一点。但这个附加程序并没有包括在J2EE的1.4版本以前。而要获得销售商的支持，则又需至少一年的时间。
e. J2EE支持一个对象相关的数据映像模型，它被称作EJB Entity Beans。这样是为了允许开发者更容易地从一个相关的数据库建立对象模型。然而，实际上把这个想法编程实现却要面对下列问题：
Ⅰ. 易用性：当那些熟知的、正规定义的、被广泛支持的结构化查询语言（SQL）和开发者的数据相互作用时，开发者不得不放弃它们，而使用一个被称为EJBQL 的弱定义查询语言。和SQL相类似，EJBQL的功能并不强大（例如，在现有的规范中，它没有ORDER BY的语句，这样开发者就没法使用特定数据库的 SQL扩展），而它的语义也没有被正规定义。还有，在对象间建立联系和附属关系十分困难，而且在对象间和XML以及后端之间的数据翻译是手动控制的。
Ⅱ.性能：基于EJB系统的性能仍是一个未知数。没有提供公开的基准。客户反映，得到的性能远远偏离了Entity Beans，并且转向一个更直接的数据访