)j2ee java2平台企业版
J2EE Java2平台企业版（Java 2 Platform,Enterprise Edition）
J2EE是一套全然不同于传统应用开发的技术架构，包含许多组件，主要可简化且规范应用系统的开发与部署，进而提高可移植性、安全与再用价值。
J2EE Java2平台企业版J2EE核心是一组技术规范与指南，其中所包含的各类组件、服务架构及技术层次，均有共通的标准及规格，让各种依循J2EE架构的不同平台之间，存在良好的兼容性，解决过去企业后端使用的信息产品彼此之间无法兼容，导致企业内部或外部难以互通的窘境。
在J2EE架构下，开发人员可依循规范基础，进而开发企业级应用；而不同J2EE供货商，同会支持不同J2EE版本内所拟定的标准，以确保不同J2EE平台与产品之间的兼容性。换言之，植基J2EE架构的应用系统，基本上可部署在不同的应用服务器之上，无需或者只须要进行少量的代码修改，即能大幅提高应用系统的可移植性(Portability)。
J2EE主由升阳与IBM等厂商协同业界共同拟定而成的技术规范，以企业与企业之间的运算为导向的JAVA开发环境。J2EE架构定义各类不同组件，如Web Component、EJB Component…等，而各类组件可以再用(reuse)，让已开发完成的组件，或者是经由市面采购而得的组件，均能进一步组装成不同的系统。
对于开发人员而言，只需要专注于各种应用系统的商业逻辑与架构设计，至于底层繁琐的程序撰写工作，可搭配不同的开发平台，以让应用系统的开发与部署效率大幅提升。
J2EE的核心规范是 Enterprise Java Beans（EJBs）。EJB依照特性的不同，目前共分为三种，分别是Session Bean、Entity Bean，以及 Message Driven Bean 。其中 Session Bean 与Entity Bean 算是EJB的始祖，这两种EJB规格在EJB 1.x版本推出时就已经存在，而Message Driven Bean则是出现在EJB 2.0的规格之中。
目前业界许多程序设计师，或者是网页设计人员，多利用JSP/Servlet的便利性，进而在J2EE服务器之上开发相关的应用，或是整合公司内部的各种资源。
Java 2平台依照应用领域的不同，共分为三大版本，分别是J2EE、标准版本J2SE（Java 2 Platform, Standard Edition）、微型版本J2ME（Java 2 Platform, Micro Edition），以及Java Card等。
从整体上讲，J2EE是使用Java技术开发企业级应用的一种事实上的工业标准(Sun公司出于其自身利益的考虑，至今没有将Java及其相关技术纳入标准化组织的体系)，它是Java技术不断适应和促进企业级应用过程中的产物。Sun推出J2EE的目的是为了克服传统Client/Server模式的弊病，迎合Browser/Server架构的潮流，为应用Java技术开发服务器端应用提供一个平台独立的、可移植的、多用户的、安全的和基于标准的企业级平台，从而简化企业应用的开发、管理和部署。J2EE是一个标准，而不是一个现成的产品。各个平台开发商按照J2EE规范分别开发了不同的J2EE应用服务器，J2EE应用服务器是J2EE企业级应用的部署平台。由于它们都遵循了J2EE规范，因此，使用J2EE技术开发的企业级应用可以部署在各种J2EE应用服务器上。
为了推广并规范化使用J2EE架构企业级应用的体系架构，Sun同时给出了一个建议性的J2EE应用设计模型：J2EE Blueprints。J2EE Blueprints提供了实施J2EE企业级应用的体系架构、设计模式和相关的代码，通过应用J2EE Blueprints所描述的体系模型，能够部分简化架构企业级应用这项复杂的工作。J2EE Blueprints是开发人员设计和优化J2EE组件的基本原则，同时为围绕开发工作进行职能分工给出了指导性策略，以帮助应用开发设计人员合理地分配技术资源。
| Microsoft; .NET 是 Microsoft XML Web services 平台。XML Web services 允许应用程序通过 Internet 进行通讯和共享数据，而不管所采用的是哪种操作系统、设备或编程语言。Microsoft .NET 平台提供创建 XML Web services 并将这些服务集成在一起之所需。对个人用户的好处是无缝的、吸引人的体验。 组成.net软件技术的组件 组件之一，“智能”客户端应用软件和操作系统，包括PC、PDA、手机或其他移动设备通过互联网、借助Web Services技术，用户能够在任何时间、任何地点都可以得到需要的信息和服务。例如：可以在手机上阅读新闻、定购机票、浏览在线相册等等。现在我们假设一种场景，如公司内使用的CRM系统，应用了.NET的解决方案后所有的业务人员便可以通过手机或PDA直接访问客户信息了。 如何创建“智能”终端 Web Services是智能终端软件的基础，微软为用户创建智能终端提供了一整套丰富的解决方案，包括： .NET Framework - 智能终端实现跨平台（设备无关性）的执行环境 Visual Studio .NET – 建立并集成Web Services和应用程序的快速开发工具 Microsoft Windows Server 2003 – 新一代的企业服务器，用于提供建立和发布各种解决方案 Microsoft Office Professional Edition 2003 – 内建的工具集也能帮助开发智能终端 现在发展最快的终端非手机莫属了，有两大阵营在开发SmartPhone技术，一个是微软为代表的Stinger应用于三星，另一个就是以NOKIA、爱立信、摩托罗拉组成的Symbian Web Services是.NET的核心技术。那什么是Web Services呢？正如Web是新一代的用户与应用交互的途径，XML是新一代的程序之间通讯的途径一样，Web Services是新一代的计算机与计算机之间一种通用的数据传输格式，可让不同运算系统更容易进行数据交换。Web Services有以下几点特性：Web services允许应用之间共享数据；Web services分散了代码单元；基于XML这种internet数据交换的通用语言，实现了跨平台、跨操作系统、跨语言。那微软的ASP和Web services究竟有什么不同呢，ASP仍然是一个集中式计算模型的产物，只不过是披着一层互联网的外衣。但Web Services却是一个迥然不同的精灵，它秉承“软件就是服务”的真言，同时顺应分布式计算模式的潮流。而它的存在形式又与以往软件不同。这种组件模式，小巧、单一，对于开发人员来讲，开发成本较低。 在这里指出Web services不是微软发明的，同样也不属于微软专有。Web services是一个开放的标准，和HTTP、 XML、SOAP一样。他们是一个工业标准而非微软标准，WS-I是为了促进Web Services互通性的联盟组织，最初是由IBM和微软所发起，其它的成员包括BEA System、惠普计算机（HP）、甲骨文（Oracle）、英特尔（Intel）和SUN 计算机（Sun Microsystem）。如今网络上存在的大多Web services其实没有使用.NET构架，Web services具有互操作属性，你同样可以使用Windows开发客户端来调用运行于Linux上面的Web services的方法。 先前提到的接口规范问题，在.NET中，Web service接口通常使用Web Services Description Language （WSDL）描述。 WSDL 使用XML来定义这种接口操作标准及输入输出参数，看起来很像COM和CORBA的接口定义语言（IDLS）Interface Definition Languages。接口定义后就必须使用一些协议调用接口，如SOAP协议，SOAP源于一种叫做XML RPC（XML远程进程调用remote procedure calling）的协议，而Java则根据XML-RPC发展了自己的JAX-RPC协议用来调用Web Services。发布和访问Web Services的接口就用到UDDI了，这里我们只需要知道WSDL使用XML定义Web Services接口，通过SOAP访问Web Services，在internet上寻找Web Services使用UDDI就行了，更多的Web Services将在最后一课介绍。 Microsoft提供了最佳的服务器构架—Microsoft Windows Server System—便于发布、配置、管理、编排Web Services。为了满足分布式计算的需要微软构造了一系列的服务器系统，这些内建安全技术的系统全部支持XML，这样加速了系统、应用程序以及同样使用Web Services的伙伴应用之间的集成。 Microsoft Windows Server System包括： Microsoft Application Center 2000 - 配置和管理Web应用程序 Microsoft BizTalk Server 2002 - 建立基于XML的跨应用和组织的商业逻辑 Microsoft Commerce Server 2002 – 能够迅速建立大规模电子商务的解决方案 Microsoft Content Management Server 2002 – 管理动态电子商务网站的目录 Microsoft Exchange Server 2000 – 用于进行随时随地的通讯协作 Microsoft Host Integration Server 2000 – 用于和主机系统之间传输数据 Microsoft Internet Security and Acceleration Server 2000 (ISA Server) – internet连接 Microsoft Mobile Information Server 2002 – 用于支持手持设备 Microsoft Operations Manager 2000 – 描述企业级解决方案的操作管理 Microsoft Project Server 2002 - 提供项目管理的最佳方案 Microsoft SharePoint Portal Server 2001 – 查询、共享、发布商业信息 Microsoft SQL Server 2000 – 企业级数据库 Microsoft Visual Studio .NET和Microsoft .NET Framework对于建立，发布并运行Web Services是一个完美的解决方案。 |
一、.Net和J2EE方向深入分析
文章来源：百度知道，http://zhidao.baidu.com/question/36242309.html
文章简介：作者简述自己的经历并对.Net和J2EE做些对比，不深入不系统。
提到.NET和J2EE，一般都会想到它们之间兵戎相见，水火不容的关系，毕竟两者都在努力地去虏获程序员的青睐，占领更多的市场份额。我无意去鼓吹.NET是如何如何之强大，J2EE是如何如何的成熟，也无意去探究NHibernate，Sprint.NET等等Project的起源，只想从一个程序员的角度去看待两者在互相竞争的过程当中到底相互借鉴了什么，同时探讨一下同时了解两个领域知识的必要性。好，让我们言归正传。
还记得2003年初，我到了DELL公司实习，所承担的工作任务就是建立一个Web Application供多个有密切联系的部门使用，以提高部门间的协作程度。在选择用什么技术来做这个Web Application的时候，我放弃了比较熟悉的ASP，进而选择了Asp.Net。正是做这个Project，我跟ASP.NET乃至.NET结下了不解之缘。当时第一次接触到ASP.NET，第一个感觉就是，它比ASP好多了，再也不用像写ASP那样在Html嵌套着一堆堆的Scriptlet，动态内容的呈现都包含在一个个方法中，如Page.OnInit()和Page.OnLoad()等等，这些方法让我看到Client端JS方法的影子。在开发ASP.NET页面的过程中，我需要做的就是在页面中引入不同的Web Control或者是HTML Control，这些Controls与HTML标签是何等的类似，除了它有ASP的prefix和那时看起来如Magic一般的runat="server"。这样的相似性让熟悉HTML和JS的我很快掌握了ASP.NET的基本应用，而我也以极高的效率完成了公司分配给我的任务，尽管我对诸如Request、Response、Session和Application这样的对象并不是十分了解。ASP.NET所带来的进步是革命性的，难怪有朋友认为ASP.NET是.NET家族中最为成功的产品了。我当时只是拿ASP.NET来跟ASP作对比，其优越性自然显露无遗，尤其是在控件设计方面的优势。事实上直到后来进入J2EE的开发领域，我依然对ASP.NET的开发方式赞赏有加。Microsoft在技术的创新上一直秉持削弱领域开发特性的原则，让开发人员能够在不同的开发领域中都可以轻松上手，游刃有余。ASP.NET的出现带来了WebForm，而在桌面程序开发中则有WinForm，两者相通的地方随处可见，这让原有的桌面程序开发人员可以平滑的过渡到Web Application开发中来；ASP.NET对于控件在设计以及使用上的支持堪称完美，也为网页设计人员进入ASP.NET开发领域扫除了不少的障碍。反观J2EE领域，做Swing开发的人员，如果要学习Web的开发，原有的知识几乎无用武之地了。在这个人气就是财富的年代，在一定层面上求同存异，让开发人员能够一通百通，无疑是一个十分明智的做法。J2EE领域也开始意识到了这一点，将Swing概念应用到Web开发的Wicket Framwork的发布着实是一个极大的进步啊。J2EE在降低Web开发的难度，吸引入门级开发人员方面需要向.NET好好请教一番了。
好，个人经历接着说。2003年底，我进入了一家软件公司从事J2EE的开发工作。当时公司技术部门负责人在面试我的时候提到了我缺乏J2EE的开发经验的问题，我信心满满的告诉他，我做过.NET的项目，而.NET和J2EE都是专注在企业级应用上的，因此肯定会很快上手，不会有什么问题。然而后来的工作证明了平台之间的差异性是很大的，从.NET过渡到J2EE并不是一件轻松的事情。没有了熟悉的Web Control，取而代之的是简陋的Tag Library；没有了简单易用的Event-Driven的方法，呈现眼前的是doGet、doPost、doHead和service这样看似丑陋的面孔。蜕变的过程是痛苦的，但是蜕变带来了进化。开发方式的改变让我可以从一个更加深入的层面去看待Web开发，而我开始重新认识Web Application。Web开发的复杂性在很大程度上源于Http是一个无状态的连接协议，Web Server不管你是Michael，还是Jordon，只要你在浏览器上使用了相同的URL，就会得到相同的资源。在这里，你必须清楚URL到底是什么的缩写。也许你会站出来反驳我刚才所说的结论，但是这种情况在只有静态HTML网页的年代是绝对正确的。随着时代的发展，资源已经不再局限于静态的HTML网页，随之出现了所谓的动态网页。这里的动态不是指充满Flash动画的网页，而是指网页的内容会根据不同的Request而发生变化。虽然Web的内容开始个性化了，但是仍然没有脱离Client发送Request，Server返回Response这样的模式。由于Http是一个无状态的连接协议，为了能够识别用户访问同一资源的状态，在J2EE的世界里，我们就得从Request、Response和Session这样的对象入手，控制这些对象的Life Cycle。因此，我们哪怕要进行最为简单的Web应用程序，都必须对Request、Response和Session这样的对象有充分的了解。关注这些基本的对象，让我们对于应用程序的Flow有更为准确的把握，能够更好地进行模块地划分，便于开发人员进行协作。然而在.NET的世界里，对Request和Session这样的对象关注远不如对Page的关注，从振河兄的Post就可见一斑了。ASP.NET开发降低了开发难度，却在一定程度上阻碍了开发人员对Web Application的整体把握，正如春鱼兄的Feedback中提到的，过分纠缠页面之间关系，“不利于系统整体架构的良好设计”。J2EE的应用程序可以让程序员在Web Application的整体架构上有一个很好的体现，.NET还是得好好努力啊！建议.NET的程序员能够尝试着利用J2EE的技术来开发一个简单的Web Application，我相信这样的一个过程会让你对Web开发有进一步的认识。
进入了J2EE的领域，除了开发方式变了，buzz Words也跟着改变了。两个使用频率极高的词汇充斥着每天的工作，一个是MVC，另一个则是Framework。我感慨于Pattern在J2EE中使用的广泛性，感慨于应用实现了MVC模式的Framework竟然可以让庞大的团队协同开发一个Project。那时的我开始相信Pattern的广泛应用给软件开发带来的变化是巨大而深远的，也开始阅读《Core J2EE Patterns》并从中获益。而在.NET的世界里，对Pattern的重视则远不如J2EE，尽管这样的情况在改变。说到了MVC，不得不对这样一个份量很重的词汇做些陈述了。jsp的发展经历了两个阶段：JSP Model1和JSP Model2。在Model1中是JSP和JavaBean的结合，在一定程度上实现了MVC，但是Model与Control之间的耦合仍然普遍存在；而Model2则真正实现了MVC：JSP作为Presentation层，负责数据的显示；Servlet充当着一个Request Dispatcher的角色，将Request分发至不同的处理Business的模块中，它就是一个指挥官，扛着Controller这面大旗；而VO则是一个数据的载体，是MVC三角中的Model。MVC的概念是进入J2EE开发领域必备的，从你做第一个简单的应用程序开始，从你看第一篇关于J2EE开发的文章开始，而丰富的开源MVC Framework也成为了我们学习MVC Pattern的良好教材。对J2EE有了初步的认识之后，就可以选择一些优秀的MVC Framework来研究了，例如WebWork和Spring。这对于学习系统整体架构设计方面是大有裨益的。
也许物极必反真的是一条不变的真理，J2EE领域中对于开发Framework的追求可谓之疯狂，大家朝这里看：Wicket - IntrodUCtion。你会发现可以用来开发Web Application的Framework竟然达到了55个，并且还在日益增加。事实上J2EE开发的软肋不在于Control这个层面，而是在View。许多天才的精力都耗在重复制造轮子上，却没有想办法去完善一个或者多个Framework，这不得不让人感到痛心啊！在这一点，J2EE是不是得向.NET好好学习一下呢？在.NET的世界里，最受关注的应该是控件的开发了，一个设计良好，功能强大的控件对于提高开发效率无疑是极好的助推器。很多.NET的开发人员都将精力花在设计控件上，.NET就像一个聚宝盆一样，不断汇聚开发人员智慧结晶。在J2EE的世界里，为了减少这种资源浪费的情况，Wicket Framework的出现了。它强调组件设计和组件重用，让开发人员集中精力于组件的开发，从而增强Framework的功能已经易用性。但愿，Wicket Framework能够为J2EE世界带来少许的改变吧！
二、J2EE与.Net之间的对比
文章来源：开发者在线，http://www.builder.com.cn/2007/0903/485990.shtml
文章简介：文章写的比较早，并且很零散和浅显。
目前而言J2ee于.net之争已经开始，由于竞争引起技术的快速发展，将传统的ASPPHPCGI大大抛在后面，随着预编辑技术的不断提高，以后程序员将面临着两大选择，一是从传统的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% 内存使用量
.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.0>Asp.Net beat1 >J2ee (Asp.net beat2目前没有测试）
中端比较
ColdfusionF 5.0=>J2ee>Asp.net beat1
高端比较
J2ee>CF5>Asp.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就属于高端的产品了。
三、Java vs C# —— 开发平台--- .Net? J2EE? 谁主沉浮
文章来源：博客，http://zhouhuaiheng.blog.163.com/blog/static/11752082007115102349422/
文章简介：以Microsoft的观点对比二者，有些偏于概念化。
对于 .NET 技术和 Sun J2EE (Java 2 Enterprise Edition, J2EE) 的对比，许多客户希望了解 Microsoft 对此的看法。事实上 .NET 和 J2EE 之间的比较很难进行，原因如下。
1. .NET（正式名称为 Windows .NET 框架）是作为 Microsoft Windows 组成部分的多种技术的优异集合；而 J2EE 只是一种书面规范。如果我们的讨论不限于纯技术领域（换句话说，对于服务器应用程序平台的商业价值进讨论），则必须比较相关的应用（例如应用于 IBM WebSphere Application Server、BEA WebLogic Server 或其他应用程序服务器）而不是单纯的比较 J2EE。
在产品之间进行比较才能得到令人信服的分析结果。举例如下：开发人员生产效率。在 J2EE 中，开发人员需要创建 4 个模块来建造一个 EJB。表面上看，这降低了开发人员的生产效率。但一些 Java 开发工具能自动完成其中部分工作，从而提高开发人员的工作效率。另一个例子：J2EE 的开发架构（类装入 JAR，JAR 装入 WAR，WAR 装入 EAR）复杂而难以理解。但一些工具可在一定程度上对其进行自动处理。因此，开发人员工作效率 — 衡量应用程序服务器商业价值关键因素 — 就可能因不同供应商工具的质量而变化。
2. "J2EE All-Star team"所产生的问题。分析人员在比较 .NET 和 J2EE 的各种因素时不难发现这个问题。例如，分析人员对开发人员工作效率的分析关注下列情况：A 公司产品的使用、B 公司应用程序服务器的性能、C 公司服务器的安全性或数据缓存性能、D 公司产品安装的难易程度，以及 E 公司产品的价格。这些情况都在某些方面与 J2EE 相关。考虑到下列功能和特点，J2EE 的确具有一定的优势：价格低廉、安装简便迅速、安全性高、具有良好的缓冲性能、带有优秀的开发人员工具软件等等。但问题是您无法同时享有这些优势。事实上，您在任意时刻仅可享有其中之一。这是由于不同厂商的产品不能保证彼此兼容。IBM 工具不能用于 BEA WebLogic 服务器，BEA WebLogic 服务器不能用于 Oracle 缓存引擎，Oracle 缓存引擎不包含在 Iona 的报价中，等等。人们有时错误地将"J2EE 综合指标"作为比较的基础，但这样做是不恰当的。客户必须进行针对相同产品和使用环境的一对一的比较，才能得出所需的结果。
3. 单纯比较 .NET 和 J2EE 忽略了应用程序平台的其余部分，而这些部分同样是至关重要的。J2EE 是一种规范，仅面向"应用程序服务器"。但大多数客户关心应用程序服务器、端口、商业服务器和分析工具、数据库、脱机数据和便携性、信息代理、应用程序集成、内容管理器、智能客户端和其他众多方面的内容。作为对客户需求的响应，所有主要的厂商都致力于开发集成化的平台，以便提供全面的解决方案。集成化平台的例子有 Microsoft 平台（包括 Windows 客户端和服务器、Windows .NET 框架、Visual Studio .NET 和 Microsoft Enterprise Server）；BEA 的 WebLogic 平台；IBM 的 WebSphere 平台；Oracle9i 平台；以及 Sun One。如果我们仅对平台问题的一个方面（应用程序服务器）专门进行讨论，则存在"全局和局部"的问题。虽然这样的比较是有一定的作用，但应将之作为更大范畴的平台问题的一部分加以考虑。
抛开上述因素，下列内容即为 Windows .NET 框架和基于 J2EE 的产品的主要相同点和不同点（仅代表 Microsoft 的观点）。
--------------------------------------------------------------------------------
相同点：
1. Windows .NET 框架和 Java 都使用了一种托管的运行时环境，都将源代码转换为一种中间语言，然后将其编译为本地的可执行代码。两种环境都提供垃圾收集、动态类加载和异常。
2. .NET 和 Java 都采用基于组件的设计、多形性、继承和接口。两者都提供基础类库以执行输入/输入、XML 处理、使用连接缓冲访问数据库、进行文本处理、网页脚本编辑和其他操作。
3. 两者都通过特定厂商的产品提供。J2EE 规范本身独立于厂商存在，但符合规范的实际产品必定实现与规范无关的功能，例如管理或部署功能。因此，这些必定是特定厂商的产品。例如 Microsoft Windows 和 .NET。
4. Windows .NET 框架和基于 J2EE 的产品都结合并用于第三方产品。例如在后台数据库领域中，.NET 和基于 J2EE 的应用程序都可以访问 Microsoft SQL Server、IBM DB2、Oracle、Informix、Sybase 和其他数据库上存储的数据。此外，.NET 和基于 J2EE 的系统都可以访问常用的消息中间件，例如 Microsoft MSMQ 或 IBM MQSeries。与此类似，两者也都可以访问目录系统、第三方开发人员工具、代码版本控制系统、防火墙等。
--------------------------------------------------------------------------------
不同点：
1. 体系
J2EE 为单语言的平台，便于在不同操作系统上使用。这意味着如果要利用 J2EE，项目可以使用多种操作系统，但开发人员可能必须重新接受 Java 培训。Microsoft 将 Windows .NET 框架作为 Windows 的一部分提供。开发人员可以使用多种语言，无须接受新语言的培训。而 Windows .NET 框架为 Windows 的一部分。
2. 应用范围
a. .NET 包括代码、产品、工具和架构，用户可通过 .NET 充分利用网络中的计算资源，包括台式机、服务器和其他设备。.NET 通过标准通讯协议（统称为"XML Web 服务"）连接所有这些设备 。（如果目标系统符合"XML Web 服务"标准，则 .NET 应用程序可以连接任何系统而不受语言或平台的限制，甚至连接到 J2EE）。.NET 模型为大规模分布式计算模型，具有大量进行通讯和信息交换的节点。
b. J2EE 为面向服务器的模型，不利用网络外围的资源和计算能力。通常，基于 J2EE 的产品仅支持服务器端应用程序。J2EE 基本上将 PC 视为 HTML 浏览器，并将其他设备视为哑终端。对于"XML Web 服务"，最新的协议标准支持分布式计算；而最新版本的 J2EE 规范未就"XML Web 服务"进行规定，但基于 J2EE 的产品可通过插件支持 Web 服务。但是，采用插件的方式可能有一些缺陷，例如，虽然 Web 服务组件可以调用部分类型的 EJB，仍不清楚当前的规范是否允许 EJB 调用 Web 服务。
3. 编程模型的一致性
Windows .NET 框架为服务器、台式机和其他设备提供一致的、面向组件的模型。J2EE 提供 EJB 作为服务器端的组件模型；提供 JavaBeans 用于客户端或本地组件，提供 Servlet 用于生成 UI，并为移动设备提供另一种模型。甚至在 EJB 内部也存在至少 3 种不同的子模型并分别具有不同的定义。
4. 功能
a. Windows .NET 框架提供以版本区分的类加载器，这意味着应用程序开发人员可以确保在更新部分代码后，其应用程序正常工作。Java 和 J2EE（当前）不具有区别版本的类加载器，这意味着开发人员和管理员无法保证在运行时执行正确的代码。这导致厂商投入更大的努力以保证基于组件的应用程序的可靠性。当然开发人员也可以仅依靠自己的信心。
b. Windows .NET 框架在语言层显示类属性，并以此简化程序编制。例如，使用源代码中的一个简单的属性可以将 .NET 组件标记为事务性组件。又例如，可以通过一个属性指定将 .NET 组件序列化为 XML 的方式。这种机制极大的简化了许多编程工作。Java 不在语言层显示属性，但 Sun 正在考虑如何修改这种语言使之具有此功能。此类更改大致在两至三年内完成。
c. 对于便携机或不持续连接网络的设备，.NET 支持脱机数据访问。用户可以脱机使用数据，然后与原始的数据源重新同步。目前 J2EE 或 J2SE 都不明确支持脱机数据访问；需要此功能的 J2EE 开发人员必须编写"管道代码"。
d. Windows .NET 框架提供基于事件的模型以建造基于 Web 的用户界面，类似于众所周知的 Visual Basic 中智能客户端的事件模型。ASP.NET 模型使建造、显示和维护基于 Web 的用户界面更加简单。相比之下，J2EE 不在 JSP 中支持此类模型。第三方扩展程序可提供部分相关功能，但其效果和易用性不及 ASP.NET。一种推荐的 J2EE 的增补软件 Java Server Faces 可以提供此功能。但最早要在 J2EE 1.4 版本中才会包含该软件。此后，供应商在大约一年之后才会提供对该功能的支持。
e. J2EE 支持对象相关的数据映射模型，称为 EJB Entity Beans。Entity Beans 的目的是便于开发人员从关系存储中建造对象。但是这种概念在实际应用中存在下列问题：
i. 易用性：在进行数据交互时，开发人员需要放弃众所周知的、曾被指定使用并受到广泛支持的结构化查询语言 (Structured Query Language, SQL)，转而使用非专用的查询语言 EJBQL。虽然类似于 SQL，但 EJBQL 的功能较弱（例如，在当前的规范中没有 ORDER BY 子句，您也不能使用特定数据库的 SQL 扩展），其规范也未事先定义。另外，建立对象间的关系和依赖性比较困难，对象和 XML 之间的翻译是一个手动过程。
ii. 性能：基于 EJB 的系统的性能仍不得而知。目前未公开任何 Benchmark 测试的结果。根据客户反馈，放弃 Entity Beans 并转而使用更直接的数据访问策略极大地提高了效率。这是 EJB Entity Beans 未被广泛采用的关键原因。
在 Windows .NET 框架中，数据访问基于 DataSet 术语；DataSet 包含可靠的数据源中的部分数据，并由于一个或多个 SQL 查询进行描述。DataSet 中的数据可能保留固定的联系，开发人员可以直接对数据进行操作，可以实现数据与 XML 之间的相互转换，可以使用标准的 SQL 筛选数据，并进行其他操作。总之，与 EJB Entity Beans 相比，.NET DataSet 模型提供了更丰富、更简便和更常用的数据访问方式。
5. 易用性
a. 配置 - 早期的 J2EE 通过部署描述文件完成配置，部署描述文件为 XML 文件，与实施业务逻辑的实际代码完全不同。这种方法存在一些问题。首先，对于特定类的元数据，有时对代码的更改和对元数据的更改是相互依赖的。对两个不同文件必须同步的要求可能导致出错。第二，对于"应用程序层"元数据，在 J2EE 中无法继承早期的元数据。相对于 J2EE，Windows .NET 框架可以将属性直接附加到源代码中的类，避免了上述问题。.NET 中的元数据模型允许自定义扩展，因此开发人员可以创建并使用自己的属性。在 Windows .NET 框架中，外部的配置元数据包含在配置文件的架构系统中，配置文件从父级文件中继承设置，用户可以仅指定更改的设置，因此文件很小，使用简便。这样就避免了 J2EE 模型的第二个问题。
b. 数据库连接池 – 在 Windows .NET 框架中，可根据需要自动建立并管理缓冲池。在 J2EE 模型中，用户必须单独配置并管理连接池。
c. XML Web 服务 – 在 .NET 中建立"XML Web 服务"就像添加类的属性一样简单。虽然一些基于 J2EE 的产品正试图在 Java 中模仿该功能，但 .NET 已明确提供了更简单的方式建造并使用可交互操作的"XML Web 服务"。
d. 部署 – 若要在 .NET 中部署应用程序，管理员只需复制文件。在 J2EE 中，管理员必须将完成编译的文件捆绑到 JAR，转换为 WAR，再转换为 EAR，然后将所有文件打包并通过特定服务器的"部署工具"运行，然后复制结果文件。这个包含多个步骤的部署过程意味着典型的编辑/编译/调试周期明显加长了。此外，由于动态类加载的需要，更新一个单独的类通常需要重新启动基于 J2EE 的服务器。
6. 成本
a. 对于部署，运行在 Windows .NET 框架上编写的服务器应用程序需要 Windows Server 许可，其价格要明显低于三种兼容 J2EE 的服务器的许可。部署由 4 台 Web 服务器构成的服务器场的价格差异可以达到数十万美元。例如，购买 4 台装有 4 枚处理器的 Microsoft Windows Server 2003 (Enterprise) 的许可并组成服务器场，需要花费不到 $16,000（按照零售价计算的总额）。如果同样为这些服务器购买 WebSphere Application Server 5.0 许可，则每一枚处理器需要 $12,000，或总共花费 $192,000。其价格比达到 12 : 1。大多数最常用的基于 J2EE 的应用程序服务器的价格与此相仿。[值得注意的是：我们目前仍假定它们具有相同的性能；但是据 Middleware Company 在 2002 年 10 月的报告显示，在使用相同硬件的情况下，在 Windows .NET 框架上建造的应用程序的性能比常用的基于 J2EE 的应用程序服务器上建造的同样的应用程序的性能要高出 2-4 倍。因此 Windows 实际的效费比优势高于 12 : 1。]目前已有基于 J2EE 的免费、开放源代码的应用程序服务器，但没有兼容 J2EE 的类似产品。这又是一个规范和产品的问题：用户需要在产品之间进行比较来讨论购买许可的花费。
b. Windows .NET 框架的部署工具价格更低。用于 .NET 的集成开发工具 - Visual Studio .NET 的许可费用要显著低于 J2EE 厂商的开发工具的价格。作为业界最佳的开发工具，Visual Studio .NET 已获得了一系奖项。对 Visual Studio .NET 及其竞争产品进行评估的客户评价，使用 Visual Studio 的开发人员的生产效率显著高于使用最佳 Java 工具的开发人员（请参阅 Giga，2002 年 6 月）。
c. 使用 Windows .NET 框架的开发和维护费用更低。据专家分析，典型开发项目中的软件购买和许可费用仅占项目费用的一小部分。通常，软件开发和维护费用约占整个项目周期成本的 50-80% (Glass, 2002; Kemerer, 1995; Gartner, 2001)。据 Middleware Company 2002 年 10 月的调查显示，在 Windows .NET 框架上开发的特定应用程序的代码长度仅为在基于 J2EE 的平台上开发的程序的代码长度的 1/3。较短的代码意味着更轻松的维护工作。
--------------------------------------------------------------------------------
总结
很明显：在对实际产品进行评估以前无法确定购买的产品。将 Microsoft Windows Server 和 Windows .NET 框架与（Sun 的规范）J2EE 进行比较有一定的作用，但如果没有实际的产品比较，规范定义的比较是没有意义的。现在我们可以得出一些结论。
J2EE 采用了以服务器为中心的体系，并将重点放在 EJB 和解决"对象关系映射问题"。J2EE 缺乏对 XML 和 Web 服务的支持。Windows .NET 框架的体系为通过协议标准和 XML 进行的大规模分布式计算，充分利用服务器、台式机和其他设备的计算功能。
与在 Windows .NET 框架上编写的应用程序相比，J2EE 应用程序需要更多的代码来执行同样的任务。
J2EE 的管理和部署模式类似于大型机，强调保护或限制对有限计算资源的使用，并进行资源优化。Windows .NET 框架体现的理念为，计算机的计算能力不断提高，价格也更加低廉，但开发仍是一项艰巨的任务。
总之，如果项目规定必须能够在多种操作系统之间选择使用开发平台；可以忽视购买许可的费用；可以限制（培训）开发人员必须使用单独的编程语言；可以忽视代码的版本控制；重视分配并限制价格相对低廉的计算资源；可以使用昂贵和复杂的开发和管理工具；可以接受编写冗长的代码 – 则 J2EE 可能是一个正确的选择。 但是，如果用户重视开发人员的生产效率的提高；期望获取最高的效费比；希望通过使用标准通讯协议实现可互操作性；希望为基于台式机和移动设备的应用程序提供广泛的支持；希望简化部署 – 则在 Windows .NET 框架上建造用于 Windows Server 的应用程序才是正确的选择。
若要获取 .NET 的详细信息，请参阅 HTTP://WWW.MICROSOFT.COM/NET
