在ATM和银行主机之间，通常有个大前置，主要用来做一些预处理工作，传统的金融平台大多采用c来处理，现在想接入网银，想改用j2ee来架构，也为以后的sop做准备，我想问的是在这种实时交易系统里应该用什么的架构。因为ATM是走TCP/IP协议的，而网银是http协议的。如果我web方面采用jsp+struts做页面层spring+hibenate做业务层，而ATM的接入采用application同样接入到到spring的业务层。由于交易量较大，必须1分钟处理1000笔交易（单ATM），这样的架构是否合适？另外，多线程如何去实现？请各位高手指点，特别是板桥大哥！
>必须1分钟处理1000笔交易（单ATM），这样的架构是否合适
关键是你的前置要做哪些工作，是否有复杂的业务逻辑，对于这样实时性比较高的系统，少用框架。
你不知道Spring+hibernate都是实时性很差的系统吗？Yin在本类别中帖子不是说了：Spring会产生大量垃圾，频繁启动垃圾回收机制，你的应有就得暂停，Spring的动态代理Proxy对象是每个请求信号都会产生的，1分钟处理1000笔交易，那么一分钟内至少1000个Proxy对象，还有其他附带对象，你需要多大内存才能不保证你的内存在短时间内能够调度得过来啊。
比较好的策略：分析你的系统在应付如此大访问量下的瓶颈所在。
如果确实需要业务组件，多台机器组成的分布式EJB系统可能更适合你这样系统，因为ATM机肯定有很长的Session存活期，Spring都没有Session管理框架，你保持一个Session一直不断Open，又占用内存，一分钟内如果非常多的ATM客户端接过来，又通过Session打爆你的主机内存。EJB的Stateful对Session可以在规定内存内进行管理。
如果你这个系统没有数据库，只是一个broker，转接者，使用JMS也比多线程强，千万别用多线程，就像就是现在过得再不好，没有出路，也不能回到原始社会一样。
首先，感谢板桥大哥的回复。前置所要做的工作通常是将ATM发送来报文解开，然后记流水到数据库,然后根据交易的类型重新按照主机的报文格式达包,发送到各自的主机.这个的确是实时性很强的系统。通常现在都是采用unix c来做的。可将来的趋势，也一定是要在j2ee下做。板桥大哥有什么进一步的建议？
你这个业务我推荐使用JMS异步系统，将记流水到数据库和报文发送使用异步机制实现，这样效率最大化，好的异步系统性能并不比同步差。
另外有个异步效率的问题很重要，异步机制注重的时各个环节点之间协调和效率，而不是单点性能，其实在一个协作系统中，某个单点性能再快，也会被性能差的单点综合掉。
您要是采用banq的方案有什么结果一定通知一声哈！看了这个精巧无比的极具经典特色的j2ee方案我直接无语……
公司刚刚完成4个小项目，两个用预存，两个不用自己写DAO，不好意思，效率和开发速度，层次隔离还是预存好，自己写个简单的业务代理来CALL预存就可以了，性能应该可以满足要求。条件是开发团队的SQL一定要过关！表示层简单ATM应该交互要求不高Struts就可以了，JSP就不要用了否则你的代码会很难看，象吃“苍蝇”，提醒以下注意数据检测问题，客户检测很破坏页面，很老火！用服务器端检测效率和用户体验都不会很好！好好写个客户端检测脚本吧，最好用OO来写，很舒服！如：RXG = “”；MSG=“”；就可以了不要用什么ONCLIK，什么的！