最近在北京做银行软件项目亲身感受小总结

最近在做国内某银行的现金管理项目,把这个项目中遇到的一些感受简单的总结一下:

 

   1:银行项目对软件的安全要求比较高,信息的发送接收都需要有安全保障,这个与其他项目的差别比较大,而且需要通过安全认证才可以,需要通过权威部门的安全检查,并能拿到证明才可以在银行真正实施。

   我们现在是采用的WCF通讯技术、采用数字证书的方式进行安全验证、类似SSL的信息通讯等来保证数据的安全性。

 

   2:需要多重密码,来保证系统的安全性,例如登录时有登录密码、进行数字签名确认时有签名密码、跟银行发生交互时需要进行安全交易、安全通讯密码,例如某个人破解了其中的一个密码,接着再持续破解2个密码比较难,所以至少进行了3道安全防护措施。

 

   3:所有的数据都需要进行数字签名,采用公钥、私钥的方式进行不对称的签名验证,已确保数据没有被别人篡改过,保证最终送交到银行的转账信息是绝对安全的,而且银行对所有传输过来的数据进行2次验证。

 

   4:所有的转账操作,都需要走工作流程,有至少2个签名或者至少3个人的签名等需求,意思是不光是一个人数字签名确认就可以了,还需要多个人的数字签名确认才可以进行最终的过账操作。

 

   5:数字签名有必要时还需要集成银行办法的Ukey方式的数字签名、而不是程序自己产生的数字签名方式,需支持多种数字签名方式的。

 

   6:所有的窗体、数据、按钮等都需要有严格的权限控制,并不是开放的系统,每个功能都需要严格达到银行的需要才可以通过功能验收。 

 

  ===============================

  这段时间深入研究学习了 WCF安全通讯方面的知识、数字证书、数字签名、非对称加密解密等,感觉这段日子过得很充实有兴趣的朋友们也可以往这方面多看看,不能成天研究 这个架构、那个框架、客户的实际需要才是最真实的。

 

 

将权限管理、工作流管理做到我能力的极致,一个人只能做好那么很少的几件事情。
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
开始项目时对Struts架构理解的并不是很深刻,导致项目有些模块 互相耦合的比较紧密,不利于以后扩展和改进。 1.SearchGene写的比较乱,程序可读性以及可维护性都不好,下一步拟通过接口编程来实现 查询字符串的自动生成。 2.BusinessDelegate写成了一个Singleton是否合适,每一个客户请求后都会new 一个业务对象 对其服务,是否有更好的解决办法以提高程序的效率。 3.Struts-config文件的Action设计的有些散乱,下一步改进。 4.业务对象和DAO合在一起了,降低了程序的扩展性和可维护性,下一步会把二者分开以降低各层 之间的耦合。 5.Struts1.2.7 的 Validator验证框架 不稳定,只能显示第一个参数,同时执行多个验证时参数的显示顺序也不对,是程序原因还是 配置不正确,再上网查找。 6.本项目大部分错误都用异常的形式来处理,异常虽可以使程序清晰,但也会消耗大量资源,若某些错误如密码错,余额不足等多次 出现则服务器响应速度必定会很慢,下一步将经常发生的错误使用硬代码来处理,减少资源浪费。 7.持久层操作大多依赖存储过程和触发器程序的部署会比较复杂,而且会使持久层和数据库耦合过紧,不利于维护,下一步准备用Hibernate 架构改进持久层,如有条件则还可用Spring框架来规范业务层,和统一整个项目。(学习Hibernate和Spring大约1个月时间)。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值