Spring vs. EJB
从scope（受众 / framework / platform）、component architecture和语义三方面对SPING和EJB进行了比较。说的比较客观。或者说是条理很清晰，思路也很对。
一、scope方面，ejb是以事务为中心，以电力行业为例，该行业需要处理大量数据，很少有OOmodel，而是做完entity分析，交给dba去优化，以数据性能为主，这样的系统里，数据操作的粒度就是transaction，而不是object或是别的。
component architecture意味着两个方面：component working(编写组件) 和 container working(编写容器环境)，spring的IOC和AOP是用在container working里的。spring的基础是javaBean，javaBean支持完整的OO建
模，因此Spring可以适用更多的结构,domain model和别的一些。
比较结果1：spring有一个理论上普适的组件模型，但是鉴于大型应用多为transaction-oriented，那么用Spring的理由就是domain model，ejb不能提供完整的OO模型而spring可以。
二、Component architecture有一个基本观点，就是component和context的分离，理想情况下，component只负责业务的实现，而container提供context，这个context指技术context，比如事务比如安全的支持。于是，component architecture的基本观点就是business关注点和technique关注点分离，business由component负责，technique由context或者叫container实现。那么很明确了，component architecture里有两种编程，针对component的和针对container的。
component的复用——容器外复用EJB效率很低。而spring以重写容器为代价实现复用。
部署——ejb的部署够复杂，但在EJB规范里有一个专门的角色来负责部署的。这里有一个调试困难的问题，这是EJB的硬伤，没办法，这甚至是组件开发的硬伤。
打成一个war和打成一个ear有多大的区别？那么部署的差异在哪？差异在EJB的deploy description和Spring的context.xml的编写上!在用Spring开发中要有一个人来写context.xml这个人往往比较了解系统，知道什么组件用什么拦截，那个组件依赖那个，甚至会是架构师在作这件事情，那么和EJB里对系统有大局观的人来做deploy有多大区别？可能就是Xml的编写吧，我想在工具的支持下就是熟练度的问题，因此我觉得部署上spring和EJB差不多，spring不用启server，调试放便些。
比较结果2：在component architecture上，spring灵活，ejb统一完整，各胜擅长，spring的灵活以降低复用为代价，但是如果有common的技术实现，的确很好复用，但是spring+一套common的技术实现也就约等于EJB了吧？
三、语义。EJB的复用有语义保证，spring呢？贫语义，一切都要开发者自己来实现。因此，如果EJB的环境语义可扩展并且可配置（比如去掉分布），那么Spring毫无优势，标准的一致的完整的组件架构使EJB会大有作为，但是现在并没有，才有了Spring的火爆.这是一种畸形的胜利，完备语义的输给了贫语义的，问题是什么，强迫消费...谁让EJB非得强迫客户去买用不到的分布式环境的单？
比较结果3：但是统一语义的威力不会因此掩灭，现在有两条路，spring联合os社区，制定lightweight j2ee语义集合，争取成为标准。第二，ejb实现技术语义可配置可扩展。
