银行业务Portal方案寻求讨论？

银行业务Portal方案寻求讨论？

手头有一个项目是开发各个银行接口，我们规划一个Bank Portal服务器。各个银行有各自的Socket接口、HTTP等接口，于是我们在服务器前端连接银行的地方又加入了一个我们的前置机，专门处理与银行的通讯接口的差异以及报文格式的差异。
同时Bank Portal的后端直接向我们的业务系统提供支持。

结构大概就是这样：
业务系统————〉Bank Portal————〉银行前置机(匹配银行的差异，一个银行一台) ————》各专业银行

现在我们在业务系统至Bank Portal的接口选型上遇到问题，现在有四个方案：1.ejb，2.Socket，3.Web Service，4.JMS

我们的业务情况是比较繁忙，每天有上千笔的交易需要提交到银行。因为银行交易不可能实时返回结果，所以业务系统与Bank Portal之间有互相的消息往来，基本上都是异步的消息。如果考虑互为服务器的话，那只有Socket才合适两边互建端口监听，但如果允许业务主动去查询交易结果。那这四种方式都应该是可以采用的？

我是主张Socket，当然Socket操作起来需要关心网络层处理。但，如果使用一些开源的封装网络操作的开源项目如QuickServer等工具，将消除这个缺点。
但由于使用EJB的习惯，很多人希望使用EJB。
Web Service当然优点是是可以跨平台，接口简单等。
JMS我就不太了解了，也是其他人的建议。
现在就是举棋不定，望高手们给个意见？

听了你的描述，感觉有些迷惑，你说的这个Portal似乎跟常见的“门户”没什么关系，比如weblogic portal, jboss portal。

话说回来，你担心的问题是什么？
1、性能？如果“每天有上千笔的交易需要提交到银行”似乎看不出在性能上做特别考虑的需要。
2、交易模式？是因为要支持异步交易模式么，另外银行提供的接口是什么？

建议你把技术上关键的问题按照优先级排列一下，相信你自己就能够得出答案了

bank portal 是个什么角色呢？好像是个birdge。
1第一个否决掉ejb。
2关于socket效率当然是最高的，但是也最容易出错，在交互的原语上一定要做到极细粒度的控制
3web service，你要求谁给你提供一个web 服务呢？银行前置机？
4jms,需要一个消息服务中心，所连接的点也要做适当的扩展，以便发送和接收消息。

JMS比较简单和易实现.

EJB可能是最好的选择....
无论是政治上还是从经济上..

那就MessageDrivenBean好了

现在回答有些晚，不过后来的人可能也会遇到。
我以前的公司是专门做银行的系统的。从我了解到的情况看，建议是：

如果有钱的话，可以用JMS，采用商业的MQ中间件，比如IBM，BEA等的产品，可以支持到银行的性能，而且你这里都是异步消息，用MQ会方便很多。
EJB太麻烦。
Socket调试修改起来太麻烦，但是如果以前做过或者以及有成熟的通讯框架在的话，可以考虑，性能应该是最好的。
WebService在性能和安全性上会有麻烦，如果有用到非JavaEE下的产品的情况下，可以考虑，但是这个时候似乎还没有Socket好。

can't agree more!
socket有很多通讯层面的问题要处理，这些jms都已经封装好了,
如果性能没问题就用jms。

同意楼上两位，在Java平台上做企业应用集成，JMS才是王道

每天也不过是几千笔的业务，JMS足矣。