拟用EJB3实现一个大型在线支付系统

数据库确实是瓶颈之一。大致上我把JPA的性能与Hibernate划等号，比起JDBC肯定是有所不如，所幸还不是数量级的差距。面对ORM和声明式事务的诱惑，是否可以就此折衷一下呢。

其实这个问题还是归集到without EJB的论点：是否轻量级framework在我的项目的要求范围内能完全覆盖EJB容器带来的一切？尤其是集群、事务、线程池和对象池？ 此外有没有人知道EJB规范和容器的将来发展趋势，它能够带来什么额外的企业级好处呢？ 架构本来就是不易改变的抉择，一旦架构定下来，将来要迁移的话会比较痛苦的。

因为刚巧正好做过这种系统，所以贸然插两句。

在线支付，尤其是和银行接口的部分，主要的工作就是按照不同的银行API搞搞加密解密，然后转到银行页面，据我所知，几乎所有的银行都要求在自己的https界面进行支付（目的是要避免用户在非银行host的界面输入卡号密码），所以，你说这个支付系统“没有界面”，从业务的实现角度，对此，我表示怀疑。

此外，因为大量的计算都是加密解密，在交易处理上，无非就是确认交易身份无误之后，update支付记录中的一个标志而已，并不存在必须要在事务中处理的“复杂操作流程”。而支付系统之外的库存系统只需（而且必须）保证同一笔交易（状态变更事件）的唯一付货行为。这是业务处理逻辑，而不是技术层面需要考虑的问题。

基于上述两点，我认为：

1，为完成交易，此系统很有可能必须要有界面，或者说，web界面。

2，为性能计，此系统更没有ejb的必要。访问量上去了，就整它多个web+单个db来处理，足矣。

我觉得这位兄弟有点本末倒置，首先楼主描述的就是一个大型应用，项目的关键很可能在于软件本身的质量，无可疑，经量级的架构可以带来短线利益，但是随着用户的业务扩充随时可能需要存变更上大型业务逻辑，轻量级容器为了提高性能会把业务和事务封装在固定的Api里，一旦用户的需要超出其管理的范围，通常设计上都会跳出原先的结构寻找一些系统外的解决办法最后导致软件结构绑定业务逻辑，丧失扩展能力和更多的性能。


举个例子:NotePad的确运行的很快，也很好用，但是人们为什么要去用Word呢？如果你认为这个Project就用NotePad就可以搞定，完全没必要去考虑word.

公司请你们来就是要提供权威的解决方案，不要前怕狼，后怕虎的，ejb设计上的错误后期完全可以修改，不会有很大的影响。这个也是使用ejb的好处之一。

ejb在响应上是有优势的，应为它会和数据层保持连接并且sync。缺点在于并发访问由于容器性能瓶颈。

观点偏离，现在讨论的是业务层上的需求，并非软件需求。考虑的好像有点片面。

一听见大型应用这几个字，我只看见一部分人已经开始两眼放光，没有调查，没有犹豫，大声喊出他们心中的那几个“大词”——EJB、分布式。这样的现象很奇怪，EJB充其量只不过是远程调用的方案之一，JPA也只是hibernate的子集，一味地神化，玩概念，忽悠人，没什么意义吧。说了几句，得罪莫怪。

业务层的需求关ejb啥事？

有什么业务需求决定了采用什么技术方案，而不是反过来，拿着技术方案去生套业务需求。

先考虑实际业务，再考虑要不要ejb，哪里偏离？如何片面？

看你写的，我感觉银行的业务<10个！业务层关ejb啥事？那你说关谁的事，谁来处理业务层！

我们只是罗列解决方案，大家讨论。没有什么忽悠的吧！


......


这个挺有意思的!是真的,有点象 －－ 你是你爸爸的儿子！:)

看你写的，我差点就要怀疑自己是不是真做过在线支付的“大型系统”了。。。

并不是把业务放到某个p“层”里去才叫做业务层，ok？

打个不甚恰当的比方，本来就是在客户端用javascript就可以搞定的事，你非要搞个服务器端接口，整个ajax来时尚一把。把到网络上跑它几个个来回，美其名曰“业务层”能“分布式”“集群”云云。我 diu ~~~（对不起，不和谐了）。

要是想忽悠甲方，让丫多买一堆机器，多花N倍银子，利润翻它N番，没问题，明说就是了嘛，大家都明了。别拿什么“高性能”“集群”“分布式”“业务层”，这些老掉牙的破烂玩意儿来说事，ok？真好像大家都没玩过似的。