ejb这么用行吗？

有一个用于web开发的j2ee的开发框架，这样使用ejb：

ejb只服务处理事务方面的事情,
而且只有无状态sessionBean,
而且只有一个无状态的sessionBean,
sessionBean中有6、7种不同的事务方式的函数,
所有的Action通过AOP代理（用来决定Service的事务是何种）的方式去调用这个sessionBean中的一个方法（针对调用的参数不同而不同）,
然后这个方法再去调用Application Service，并将web层的参数传递过去。

这样，只有一个ejb，而且是固定的，所以开发人员不用考虑ejb的事。
布署当然也简单了。

我的疑问是：这样使用ejb有什么意思呢？
单纯从技术角度考虑，我认为是多此一举的，用Spring的Aop事务代理就能做事务，还用ejb做什么？
有人说客户想用ejb，所以这么做。

大家分析一下，这样做有什么缺点和优点呢？

完全是多此一举，不过是客户要求的就另当别论了，多忽悠点钱总是好事。

客户如果知道就一个ejb，能忍受这种忽悠吗？

一个EJB怎么了？过去我参加的一个项目就是只有一个无状态SessionBean做facade，后面调用成堆的的JavaBean业务组件。

用一个ejb的项目我也作过。
没认为有什么不好。。。
分层清析。。
拿来就用，
不必关心事务
不必关心多个数据源
不必关心异常与回滚。
除了非要在WSAD上开发以外还没发现什么不爽

首先，没这样用过
其次，确实重复，要么把AOP去掉，要么全部AOP

多半是全局事务和全局远程调用!这两点太吸引了!抛开这两点,ejb从技术角度应该没有太大的吸引力!

因为只用一个EJB，显然不存在事务的关联问题，那不用EJB也能解决事务问题。
多个数据源不用EJB时也不用考虑什么（除非让它们在一个事务，这样的情况一个EJB也会有问题的。）
异常与回滚是一个不用关心的地方，但Spring的Aop事务处理也能应付吧。

至于在WSAD上开发，倒不一定。可以用代理先不经过EJB，集成时再通过EJB。

我只是觉得这么用从技术上讲还不如不用。

客户布署时一看只有一个EJB，还不得急眼了。

请问DIZ，“全局事务”是否说得是JTA？如果是，不用EJB自己也可以利用JTA，JTA是容器提供的而非EJB提供的。另外，对于远程调用EJB确实是挺好的，不过现在多数企业都流行WEB SERVICE。

看过withoutEJB的人都知道，EJB的最大用处还是分布式应用。也就是状态缓存、集群以及失败恢复机制。但如果只用无状态的，应该是集群普适场景，也就是平行加多少台机器，把代码都copy布署到机器上就oK了。用不用EJB都应该没有什么影响。