to ray_linn
COM+根本无法和EJB/Corba相比，你这个伎俩如同当初微软推出NPetstore，将自己和强大对手比以显得自己高大，微软玩企业服务市场还嫩得多....，无关主题话题打住，也请ray_linn多贴一些主题相关话题，需要讨论.Net和java比较欢迎到"综合区"..
就是不谈COM+，我还是得说，你对EJB 3.0的理解完全是错的。
EJB 3.0 !=EJB 2.X+Xdoclet
不等于就不等于，有什么好争的。我以前开发ejb都是ejb2.0+xdoclet，在这里xdoclet只是用来生成对应的xml配置的。估计bang的意思是ejb3.0=ejb2.x+annotation
下面是我以前好象哪里看过的，不知道对不对（我没有用过ejb3.0):
ejb3.0针对ejb2.x改变主要有两点：
一、以pojo的方式代替旧的的那些继承，接口之类的。但我想这只是编程形式上的改变，底层实现应该还是差不多。
二、就是对cmp2.x模型做了很大的变动（这个可以看bang给出的slide)。好象很多东西和hibernate很类似。
不知道还有没有其它的了。如果真只是这样的，我想对那些理解了ejb2.x和hibernate,spring之类思想的人，ejb3.0基本上应该是能马上上手的吧。
我自己补充一下，免的被人抓住把柄。
刚刚想起来了，上面的东西是几个月以前从ejb3.0的草案里看到的。现在不知道有没有补充了其他的东西。上面第二点说的意思是持久层，而不单是cmp entity bean。
象采用annotation之类的技术，和com+的相似也不奇怪啊，做com+的有什么好洋洋自得的，真是奇怪。类似的技术xdoclet不也早用了，只不过不象jdk1.5那样集成到运行环境里而已。
dabb是明白我的意思的，EJB3.0 = ejb2.x + xDoclet(Annotation)
其中Ioc我已经隐含了，因为没有ico，xDoclet/Annotation是对程序编写不会起到根本的简化。
我基本赞成dabb的两点，只能说以类似POJO方式处理EJB3的依赖关系，但是jakarta99竟然得出EJB3 = POJO，那就是极端了。
以前我还看到有人在程序员杂志上发文，EJB3就是hibernate呢，，这些都是受了外国人的扰乱，自己不加消化照搬照抄，结果人家老外经过讨论澄清：EJB3 != Hibernate，现在没人说了。
> 我自己补充一下，免的被人抓住把柄。
> 刚刚想起来了，上面的东西是几个月以前从ejb3.0的草案里看
> 降摹Ｏ衷诓恢烙忻挥胁钩淞似渌亩鳌Ｉ厦娴诙闼档囊
> 思是持久层，而不单是cmp entity bean。
> 象采用annotation之类的技术，和com+的相似也不奇怪啊，做
> om+的有什么好洋洋自得的，真是奇怪。类似的技术xdoclet不
> 苍缬昧耍徊还幌jdk1.5那样集成到运行环境里而已。
小GG，在COM+工作的时候，EJB还没影子呢，更谈什么Xdoclet，此类似的技术和COM+ Annotation也毫无相似之处好不好？COM+的容器会根据Annotation将所涉及的安全、事务横切入方法调用之前，这是AOP而不是XML说明！。
Banq倒好，所涉及的关键东西，这也省略不说了，那也不省略不说了，最后啊A+B=C。
对于EJB 3.0，其工作方式与COM+类似，决不是Xdoclet+EJB2.1=EJB3.0，懂吗？没玩过EJB 3.0的dabb
to ray_linn
这是最后警告你（否则删贴了），你发一些有技术含量的帖子，你要真想比较EJB3和COM+，你自己最好另开新帖。
EJB3 f成 EJB3.0 = ejb2.x + xDoclet(Annotation)
@Nf法在不太任
p看之下好像有道理
但断肓私 EJB2 c EJB3 的差c改M的程序T碚f
泻艽蟮恼`
因 EJB3 改M了很多 EJB2 的缺c
像是持久拥母倪M, IoC c AOP 使用, 有很多.....
@可不是 EJB3.0 = ejb2.x + xDoclet(Annotation) 就能看的出
磉@Y求知的人
可不是只想看@W等式
更何r@是有}的等式
1. 不使用 xDoclet 能不能蛲瓿 EJB3 的 ??
ans: 然可以, 所以@ "+ xDoclet" 就有}了
2. 如果f xDoclet [含了Ioc / AOP, 那是否可以f xDoclet = IoC + AOP ??
我想@不用我回答了吧
ray_linn ,你可真会断章取义啊。你这种人才到武则天时代一定很吃的开，比当程序员有前途多了。
对于ejb3.0何必先玩过？熟悉一点的人看过一些规范也就明白差不多了，需要的时候自然可以随时上手，当然一些细节需要经过自己体验才知道。
按你的说法，何必ejb3.0才和com+相似，ejb2.x,1.x不都一样道理。事实上从分布式体系架构这个角度看也是应该一样，除了底层通讯协议和实现细节。至于你所说的ejb3.0和com+相似，恐怕更多指的是annotation+pojo这些表现形式方面吧？你所说的annotation实现方式是aop方式，而非xml配置形式的，这点确实有些区别，但即使是xml配置形式的，其底层由容器实际运行的代码，其实也是一种aop方式的实现。当然我还不知道现在已经实现ejb3.0的容器（比如jboss)对这方面的实现方式，是类似aspectj这种字节码级别的实现吗？还是和原来ejb2.x一样的实现方式。我想后者可能性能会更好一些。
呵呵, 讨论技术也能掐起来, 热闹啊.
对于EJB3, 或者说, JSR 220 这样一个复杂的SPEC来说, 简单地说它是或者不是EJB2.x + xxx都是不完全错也不完全对的.
J2EE SPEC的一个核心思想, 甚至与整个COMPUTER SCIENCE的核心思想, 是分而治之, 分层次, 分角度, 分场合. 对于JSR220而言, 也需要分层次, 分角度看待.
从简化客户端的角度来说, EJB3的客户端视角的确是POJO + IOC.
从EJB开发者角度说, COMPONENT CONTRACT仍然要求提供各类INTERFACE, 这里大多数是从EJB2X继承来的. 当然, 注释(JSR127)和工具的使用将会简化这个任务, 但是从技术细节角度看, EJB3的COMPONENT CONTRACT的确是 EJB2X + ANNOTATION, 或者承袭了 EJB + XDOCLET的衣钵.
从容器开发者角度看, 可以想象BEA, ORACLE 和 IBM是不会把现有的CODE推倒重来的. 事实上, COMPONENT CONTRACT对EJB2X的继承也保证了容器合同必定是继承EJB2X的. 当然, JSR220本来就是BEA, ORACLE 和 IBM这些人写的, 他们当然要最大限度地利用现有程序. 所以, 从容器实现上看, EJB3的容器必然是 EJB2X容器 + 注释编译 + IOC注射容器的布局.
对EJB2.X割裂比较厉害, 甚至完全脱胎换骨的, 是实体/永久层API. 这部分内容甚至已经超出了JAVA EE的范畴. 这部分有这么几个特征:
1. 客户端视角: 毋须质疑, 是 HIBERNATE 和 TOPLINK 的基因. JBoss的Gavin King, oracle toplink的几大architect就摆在专家小组上, 这两家恰恰又是两个最早的EJB3 RI提供者. 说ENTITY BEAN 3.0不是HIBERNATE/TOPLINK来的, 就好比说ANNOTATION的设计没有参考XDOCLET, 是要让人笑出鼻涕, 笑掉短裤的.
2. 离线模式(disconnected mode)!!!: J2ME, J2SE, mobile app, cell phone, anyone? 脱离了J2EE容器的 PERSISTENCE, 赢得的将是整个世界! 把离线模式写进JSR的意义是如此深远, 以至于我都要哭了...
最后, 关于COM+, 呵呵. JAVA 和 MICROSOFT互相抄袭/学习不是一年了. .Net Remoting不就是RMI? EJB不就是MTS+COM? JSP不就是ASP? COMPILED ASP不就是JSP? C不就是JAVA, 而JSF不就是VB?
归根到底, 整个JAVA EE 5, 甚至包括J244 1.4 的JSF, 根本设计目的是为了简化开发模式(尤其是客户端开发模式), 和规范开发工具(这是ANNOTATION被标准化的另外一个动机: 方便IDE操作METADATA). 而"简化开发模式", "丰富开发工具", 最终的目的是和.NET竞争.
所以啊, 有些同志们一讨论技术, IBM, MICROSOFT就笑了.
可以Banq，没办法这么有条理的说出来，他把Client Side和COMPONENT CONTRACT，都混在一起，淅沥糊涂一锅子熬，其错误难免。
hehe,
刚刚才看见就这个问题在另外一楼里面已经火并过了, 腥风血雨啊.
其实banq他是完全从component和clieng开发者角度看问题, 他那个公式也是在描述component和clieng开发者的开发体验. 从这个意义上说, 有他的道理.
banq的问题是过于自负了. 不过jakarta也是的, 其实如果一开始就正面摆明他的立场, 我想banq会立刻同意的. 可惜两位大侠一上来就打无谓的口水仗, 却不客观讨论问题的实质. 技术问题能掐到这地步, 我晕~~~~~
不过两位还是大侠, 希望能化敌为友. 曾经看到统计数据讲亚洲地区, 除日本以外参与开源工作的开发人员很少. 实在希望看到中华同胞, 不论你生在哪边, 在IT领域有更多更好的作为.
最致命的是他的等式，从Component还是从Client都是错的！二者怎么也不能划上等号：这叫钉是钉 铆是铆~~
也正是因为如此，未来Container对EJB 2.X的支持不过是个向下兼容的举措而已。 因为EJB 3.0不等于 EJB 2.x+香蕉+苹果+魔法药水就能变出来的。
咱辩论的时候要一条条列出来，不可以弄混了。
这个“高手”嘛，大概是分成两种滴。一种是axman那种，解决实际问题滴，虽然没有见过他有超前发表过什么“新”技术文章的介绍，但是烦是什么疑难问题，一般他都可以解决掉。另外一种就是经常地会对“新”技术发表一些评价，介绍，教程之类的，可以帮助初学者快速入门。
jdon框架虽然可能在某些“高手”眼里，是没什么大不了的，因为从理论上来手，“高手”嘛，这些东西想做，只要花时间去做也是做的出来的，至于花不花时间去做那就看“高手”高兴不不高兴了，（但在我看来，通用框架要弄的成熟稳定，要经过不少时间的测试，实战，优化，重构，恐怕不是”理论高手“在那边想想就能弄出来）。所以jdon框架的市场可能更适合中级水平的设计者。至于”高手“嘛，如果你的理论水平只是跟他们水平差不多或则多一点，在”高手“眼里，当然你的东西是不屑一顾了。这就象那个联想的什么家伙说的什么鸡蛋看鸭蛋，鸭单看鸵鸟蛋的道理。
所以虽然从理论上说“高手”也可以做出jdon差不多的框架，但请扪心自问，能不能超越它呢？