先看：
http://www.microsoft.com/china/msdn/library/dn_voices_webservice/html/netjava.asp#net10
微软抢手的一点总结：
我们相信使用存储过程的.NET实现不但是一种比J2EE BMP模型更为高级的设计模式，而且还能提供比其更好的性能和扩展性。该应用程序的两个版本的基准数据证实了这一点。
我的观点：
J2EE中的任何一层不依赖于特定的产品，所以不用存储过程，并不是因为设计模式。
文章一再强调的.Net优点：Cache,Stored Procedure,XML Web Service， 扩展性好和高性能也是被作者过分夸大（某些测试项竟高出28倍）
基于J2EE的解决方案要引入这些特性是轻而易举的，至少我在Java项目中也使用Cache和XML Web Service，并不觉得扩展很麻烦，相反我可以自己组态，深入事务内部。而且EJB2.0中大大提高了CMP应用场合的兼容性，这可是.Net尚不具备的（ASP.Net服务器控件中还没有类似的功能）
下面稍微比较一下两种解决方案：（以下纯属个人观点）
性能方面：
最终用户衡量的唯一标准：
性能瓶颈主要在中间层以下：EJB1.0或EJB1.1的效率确实不怎么样，不如轻量级的解决方案性能来得好，比如：硬编码直接访问数据库，对象关系映射，采用存储过程封装商业逻辑，采用对象库存储。特别是BMP管理起来代码文件特别多，发生业务变更时更需要重新配置服务器，影响了业务的连续性，但.Net的解决方案也不见得好啊！
页面缓存和对象缓存：J2EE没有相应的标准，但某些应用服务器扩展提供了相应的标准，用法不一，提供的功能也不相同，目前我只使用了对象缓存和少量的页面缓存，效果相当好（昨天刚升级了一把，可以在线通过网页直接命令存储中的某个对象或页面重新装载，但尚不具备同时支持登录和未登录的两种页面显示缓存，我将使用FilterServlet提供这一功能）
开发效率方面：
对我们来说选择开发工具的最需要衡量的就是这一因素：
表现层开发：J2EE这方面非常欠缺，把这一任务丢给了应用服务器厂商和编程人员，不象.Net拥有很牛的.Net Studio，不过Jbuilder 6已经出来了，支持EJB2.0 也不算太落后，但一直没有解决方案的就是页面用户控件（当然Turbine的Action Event也算一种），缺乏可视化设计和Servlet应用程序框架生成。我期望的一种方式是具有象.Net Studio一样的可以所见即所得的编辑模板(Template)，绑定用户按钮事件处理。目前可以通过JavaScript库，模板库及宏库略微缓解一下Servlet的开发。ASP .Net和Servlet都支持动态更新表现层。（目前我已经支持通过数据库储存某些需要实时修改的模板供主模板调用）
商业逻辑层开发：
在这层的工作应成为高级程序员的重点而且应作为公司财产保护起来，大家的精力主要是要维护起公司商业库的升级和功能扩展，并进行良好的配置管理（应采用ClearCase，CVS对库的管理能力太差啦！）。
配置及发布：
发布和配置应完全独立开来，所有的配置项都应该可调（路径，数据库连接，EJB描述文件等），很可能正式发布的数据库表名，字段定义并不和开发人员的一致（如果开发产品的话，这点很重要！)
.Net只能通过存储过程方式来提供所谓的解决方案，而J2EE这方面做得非常全面，如果商业库是符合发布迁移规范的，系统管理员完全可以做到任何细节可控。这一过程需要商业逻辑层开发人员的努力。
XML支持能力：
.Net一直叫嚣的就是我集成了XML和Web Service，但JDK1.4也搞出了XML规范，这方面已经差不多了，不过.Net的易用性好得很，而且就此一家，程序员不必费心思选组件或产品。
在采用XML和XSLT的开发模式中：微软的SQL Server 2000直接提供了HTTP Query到XML数据的功能，不过我用dbxml也能做得这一点嘛，还适用于大多数的主流RDBMS，更牛！这种开发模式应该是未来的方向。
分布式组件，消息服务和事务服务支持等方面：
我的经验不足还不能评价。
.Net用COM，DCOM，MSMQ和MTS
J2EE用EJB,JMS和JTS
安全性方面：
通过网页授权方式：
.Net支持的验证方式：Windows, Forms, Passport,None
Servlet支持通过扩展也能支持这些，而且通过丰富的加密算法（例如AES)也很容易集成到自己的解决方案中
Passport足以显示微软的野心，不过其安全性有漏洞，上个月就出过问题，停了三天。SUN正联合几个大厂商开发针对Passport的相同产品规范。
