论Spring与EJB的组件架构

你用spring的事务语义还不是要绑死在spring上？所然可以替换语义实现，但是语义等价是必须的。关键还是语义，我很赞成在ejb的语义下把spring做为实现技术，spring缺少的是一套公认的完整的语义支持。
而ejb3开放语义实现机制其实是一个很好的契机，也是我对ejb最后的希望。如果可能，将会是lightweight ejb container和heavyweight ejb container并存

预测胜负其实我觉得意义不大的。

第一，包括Sun自己在内都已经承认了EJB2的失败

第二，EJB3已经在往轻量级框架方向发展，这也是整个Java业界的一个共识了

第三，行业领导厂商已经把盈利的重点转移到卖商业逻辑框架上，例如portal，workflow，cms等等，虽然未必如ozzzzzz所说那样会摧毁App Server市场，但是这个市场已经不成为他们的一个关注焦点了。

1.就像robbin说的，任何framework都有自己的约定要遵守，ejb2是复杂了一些，spring比起ejb的进化，重要的一个就是统一的组件home，也就是container。但是我一直认为container应该隐藏在naming service之后，作为实现技术。spring把container和naming service和在一起，虽然很简单但我个人不是很认同。至于ejb技术代码比spring少，理论上如此，而且ejb用的技术都是j2se里的，这也是sun的聪明，以来java core library不会给人特别不好的印象，因为他看起来是语言的一部分。
我承认ejb组件模型并不成功，但个人觉得spring矫枉过正，完全没有组件/容器约似乎也不是好事.
2.在component-based development里，传统的cycle是design-〉code->Test-〉deploy，这个没办法，eclipse的plug-in也要部署，不过比较简单而已，ejb的缺点在于部署作得太复杂了。但是我觉得cbd里有一个人来粘合技术和业务还是对的。

gigix,spring要求的是JavaBean，比POJO要求高一点

例如javabean要求公开的构造函数，所以这也算是一个约束

ejb3我觉得应该向mof2的emof/cmof划分学习，分成essential ejb和complete ejb两部分,eejb是injection，事务等基本语义，cejb是分布，集群等技术语义的集合，这样sun就市场进行了划分，轻重有别。即保证了可用，又保证了大厂的利益。当然关键是容器环境可配置，这些都直指向了mop和aop

至于商业逻辑框架，更狠的是卖行业标准元模型，电力的iec61970就是例子。ibm那个金融的也有这个企图。

帮助林星贴一下，他刚注册发不了贴：

语义和重用

我认同庄表伟的重用在业务级别价值才最大的说法。不过，我觉得技术层面和业务层面的重用都是存在的。只不过，两者的目的和标准都不同。技术层面关注的是如何保证组件的各种不同维度的特性的分离，例如持久化、事务支持等。如果我们能够分离这些特性，并用同样一种描述形式来描述某一种特性，特性的替换就成为可能，重用度也就增大了。而这里就是语义的关键了。在任何一个设计中，如果要支持不同的持久化机制，当然需要设计共同的接口，接口其实就是一种语义，当然，我们还可以用配置文件来说明，这也是一种语义，而且比接口更加的灵活。而在jsr175出来之后，我们还可以使用annotation，这个就更加方便了。这就是一种语义了，这种语义可以为人所理解，也可以为机器所理解。Raimundox提到spring是贫语义，可能的一个想法就是spring对特性的标准化仍然不够，但我倒是觉得spring在这一点上已经做的不错了，他把各种特性都组织为bean的形式。不过，因为spring是从实践开始整合的，而不像EJB是从规范开始整合的，在语义的统一上，spring做的还是不够，但这个是双方的角色决定的，而不是设计的问题。因此，我们也可以想象，当EJB3和annotation普及之后，这种情况会发生变化。

但是业务层面，更重要的重用是针对领域的。业务模式已经为此做了很多的工作，但是否足够呢？我觉得还远远不够。目前大家试图把领域方面的模型统一在MDA之下，但这个目标也是相当困难的。黑箱重用的组件是否能够一统天下呢？这个目前看来也是相当困难的。不同的领域适合于采用不同特点的模型，那么，如何划分领域？领域划分到何种程度？数据为中心、流程为中心的设计模型之间是否能够统一。这些都是业务层面需要考虑的问题。

达成共识了。我也同意说应该有一个人来负责技术和业务的粘合，大多数程序员只要用OO的方式实现业务逻辑就可以了。出于这个考虑，“大多数程序员”当然就应该在POJO上开发了，他们没必要知道这个POJO是要deploy到EJB容器还是别的什么容器。

我的看法:

1.
ejb3 是模仿spring建立的体系结构,ejb3跟spring的关系就像jdo跟hibernate的关系,老的ejb体系已经垂死,ejb3使轻量级容器有了更多选择.
2. 到了ejb3时代,有可能spring修改符合ejb3,也有可能部分中间件厂商拿spring作内核来实现ejb3. 就像hibernate和entity bean的关系一样.
3.
ejb3仍然会是j2ee的核心模块,但由于spring的开放性,用户不再会对ejb3的需求付费,用户付费的核心是分布式事务.
4.
纯中间件服务器的利润会暴跌,因为许多应用不需要分布式事务,主流中间件厂商会把业务核心转向portal,eai,数据仓库等方向.

兄弟，你没发现你的立场在变化？spring从"贫语义"变成了"缺少的是一套公认的完整的语义支持"。
完整与否我不知道，因为没看到不完整的例子。ejb和spring相比，我看是spring相对更加完整一点点。至少spring的服务范围要大于ejb。
至于公认，这个就更加难说了。很多时候，公认归公认，是不是使用就是另外一回事情。

我认为pojo作为一种组件模型应该强化语义约定，这样只要语义保证，deploy到哪都无所谓。