这篇文章的主题在于从技术的角度分析微软的分析和指责不成立。
要点：
- Pet Store 根本就不是一个performence benchmark的工具，他本来是为了作为指导学习
EJB的工具而存在的。
- Microsoft 的实现小心的避开了管理模块和Email发送模块，也就是说它没有完全实现J2EE
PetStore.
- Microsoft 的测试并不是严谨的。他的测试和Oracle的测试是在不同的软硬件平台之上的.
Oracle是在Sun workstation, Solaris 系统和Oracle Database下，而MS是在Windows 2000,
SQL Server 2000的情况下。关于软硬件平台的本身的性能，包括数据库驱动程序的性能完全没有
被分析。
- J2ee PetStore 的开发主要基于可移植性的考虑，而微软完全为了展示性能。他们实现是“非
正式使用程序的两种不同的功能集”。
- MS计算开发效率的方式不妥。微软采用计算LOC( Lines of Code)的方法，但是这个标准本身
就存在疑问。比如他的计算方法忽略了ASP和JSP中的所有HTML代码，而这是开发者面对的
一个重要开发任务。相反，MS却计算了application的XML描述文件的大小。而这些描述文
件都应该是deploy工具自动生成的。MS为什么要计算他们在内呢？
- MS 指出在中间层上.NET仅需700行代码10多个文件，而J2EE需要5400行代码和120个文件。
作者认为这是在不同的环境下得出的结论。.NET的实现采用储存过程，并且直接利用SQL server
2000输出XML.而J2EE考虑到的是可移植性，他采用BMP来实现与所有的数据库无关，而且没有利用
任何数据库本身的优化。这种不同的实现是“苹果和桔子”的关系。如果要求.NET per store
支持其他的数据库，或者j2EE使用CMP并且针对某个数据库作针对性的优化，情况就会不同。
- 有价值的讨论在于表现层。ASP.NET提供了模块化的，比较直接的方式来编写HTML,而JSP
仍然在采用传统的办法。j2EE本身缺乏对于流程控制和事件驱动编程的能力。后来作者又指出，
在他参与的项目中，通过采用Structs,他也部分获得了这种能力。
结论的最后部分认为：
For developers who are comfortable with limited choices, .NET is a
well-designed framework with good tools. J2EE provides greater freedom,
but the J2EE community can't ignore the need for tools that create powerful
and efficient applications in a timely manner.
.NET是一个组织良好的框架，他提供了很好的工具。J2EE提供了很大的自由度，但是J2EE
社会不应该忽略对于在有限的时间里开发强大和有效率的软件的工具的需求。
]