锁定老帖子 主题:银行业务Portal方案寻求讨论?
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2006-11-21
手头有一个项目是开发各个银行接口,我们规划一个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我就不太了解了,也是其他人的建议。 现在就是举棋不定,望高手们给个意见? 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2006-11-23
听了你的描述,感觉有些迷惑,你说的这个Portal似乎跟常见的“门户”没什么关系,比如weblogic portal, jboss portal。
话说回来,你担心的问题是什么? 1、性能?如果“每天有上千笔的交易需要提交到银行”似乎看不出在性能上做特别考虑的需要。 2、交易模式?是因为要支持异步交易模式么,另外银行提供的接口是什么? 建议你把技术上关键的问题按照优先级排列一下,相信你自己就能够得出答案了 |
|
返回顶楼 | |
发表时间:2006-11-23
javajia 写道 结构大概就是这样: 业务系统————〉Bank Portal————〉银行前置机(匹配银行的差异,一个银行一台) ————》各专业银行 现在我们在业务系统至Bank Portal的接口选型上遇到问题,现在有四个方案:1.ejb,2.Socket,3.Web Service,4.JMS bank portal 是个什么角色呢?好像是个birdge。 1第一个否决掉ejb。 2关于socket效率当然是最高的,但是也最容易出错,在交互的原语上一定要做到极细粒度的控制 3web service,你要求谁给你提供一个web 服务呢?银行前置机? 4jms,需要一个消息服务中心,所连接的点也要做适当的扩展,以便发送和接收消息。 |
|
返回顶楼 | |
发表时间:2006-11-23
JMS比较简单和易实现.
|
|
返回顶楼 | |
发表时间:2006-11-23
wolfsquare 写道 JMS比较简单和易实现.
EJB可能是最好的选择.... 无论是政治上还是从经济上.. |
|
返回顶楼 | |
发表时间:2006-11-23
抛出异常的爱 写道 wolfsquare 写道 JMS比较简单和易实现.
EJB可能是最好的选择.... 无论是政治上还是从经济上.. 那就MessageDrivenBean好了 |
|
返回顶楼 | |
发表时间:2007-03-18
javajia 写道 银行业务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我就不太了解了,也是其他人的建议。 现在就是举棋不定,望高手们给个意见? 现在回答有些晚,不过后来的人可能也会遇到。 我以前的公司是专门做银行的系统的。从我了解到的情况看,建议是: 如果有钱的话,可以用JMS,采用商业的MQ中间件,比如IBM,BEA等的产品,可以支持到银行的性能,而且你这里都是异步消息,用MQ会方便很多。 EJB太麻烦。 Socket调试修改起来太麻烦,但是如果以前做过或者以及有成熟的通讯框架在的话,可以考虑,性能应该是最好的。 WebService在性能和安全性上会有麻烦,如果有用到非JavaEE下的产品的情况下,可以考虑,但是这个时候似乎还没有Socket好。 |
|
返回顶楼 | |
发表时间:2007-03-18
basicbest 写道 javajia 写道 银行业务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我就不太了解了,也是其他人的建议。 现在就是举棋不定,望高手们给个意见? 现在回答有些晚,不过后来的人可能也会遇到。 我以前的公司是专门做银行的系统的。从我了解到的情况看,建议是: 如果有钱的话,可以用JMS,采用商业的MQ中间件,比如IBM,BEA等的产品,可以支持到银行的性能,而且你这里都是异步消息,用MQ会方便很多。 EJB太麻烦。 Socket调试修改起来太麻烦,但是如果以前做过或者以及有成熟的通讯框架在的话,可以考虑,性能应该是最好的。 WebService在性能和安全性上会有麻烦,如果有用到非JavaEE下的产品的情况下,可以考虑,但是这个时候似乎还没有Socket好。 socket有很多通讯层面的问题要处理,这些jms都已经封装好了, 如果性能没问题就用jms。 |
|
返回顶楼 | |
发表时间:2007-03-22
同意楼上两位,在Java平台上做企业应用集成,JMS才是王道
|
|
返回顶楼 | |
发表时间:2007-03-30
Godlikeme 写道 can't agree more!
socket有很多通讯层面的问题要处理,这些jms都已经封装好了, 如果性能没问题就用jms。 每天也不过是几千笔的业务,JMS足矣。 |
|
返回顶楼 | |