关于SOA在银行系统中实施的一些讨论（简介，应用，开发，SOA和ESB）

家住海淀

如果做到了真正的松耦合，那还真的非常让人向往的

watchingheart

技术上的松耦合是容易实现的。业务上就不容易了。

家住海淀

原帖由 watchingheart 于 2011-8-4 15:16 发表
技术上的松耦合是容易实现的。业务上就不容易了。

技术架构上符合松耦合的要求，最后满足松耦合的要求的，老胡还真没有看到太多，多半是做到最后，搞来搞去就忘了，仅仅关注功能实现了

xracycq

垃圾系统 没事就宕机~~~~苏宁的顾问也是一帮水货哦~

qiaodong01sina

关注一下

crazy57002

一定要顶啊，写的怎么好啊

midzhou

不是用WebService就是SOA。WebService通常用于企业间的集成，SOA最主要还是关注自身的系统架构。

赞同，在目前的各业务系统各自建设的情况下，能做到企业间数据和应用的集成就相当头疼，SOA近期更应做为建设指导意见去遵循。

marsbay

最近几年经常见到 “产品工厂”“SOA”“胖核心 VS 瘦核心”等等词汇

如果抛开一切，整体来看，个人理想化的银行IT系统场景是什么呢

是建立在基础与ESB类的产品之上的 完全同构、同技术框架、同规范、高度可配置的产品化服务体系。基础技术架构，则是建立于集群的类云计算的主机群组之上。而数据架构，原则则是统一甚至唯一客户视图，统一甚至唯一账户视图，统一甚至唯一各类明细信息等等(在不考虑提高应用安全可用而做的同城灾备、异地灾备之外)。

也许就不会再有核心系统、信贷管理系统、信用卡系统等等这些说法，而均是被发布于SOA架构之上的可供同样在其之上的各类渠道交互层调用的服务群而已，这些群也许会被分为账务处理服务群，分户处理服务群，经营分析服务群，内控授权服务群等等。而这类服务群又是被高度配置化，使其在一定程度上具备快速配置发布产品的能力。

凡事怕然而，
然而，构建理想模型的困难重重或者说基本不可能。不管是打破原有架构，过渡到新架构的困难，还是构建一个这样的总线应具备的调动其他服务犹如调动内部函数一样高效准确，应具备的业务流程高可配置，技术流程高可配置的要求的困难，都将使其在落地之时经过重重裁剪。

再然而，抛开单纯技术的视角来看银行IT系统建设的问题，同构、同技术等等会带来注入商务、人力团队建设等等系列问题。所有这些，其实归根结底都是为了 能够更方便 更安全 更个人差异化 更低成本的提供银行业务给每个人使用。

21ming

好贴。。顶

watchingheart

原帖由 marsbay 于 2011-8-28 02:12 发表
最近几年经常见到 “产品工厂”“SOA”“胖核心 VS 瘦核心”等等词汇

如果抛开一切，整体来看，个人理想化的银行IT系统场景是什么呢

是建立在基础与ESB类的产品之上的 完全同构、同技术框架、同规范、高度可配置的产品化服务体系。基础技术架构，则是建立于集群的类云计算的主机群组之上。而数据架构，原则则是统一甚至唯一客户视图，统一甚至唯一账户视图，统一甚至唯一各类明细信息等等(在不考虑提高应用安全可用而做的同城灾备、异地灾备之外)。

也许就不会再有核心系统、信贷管理系统、信用卡系统等等这些说法，而均是被发布于SOA架构之上的可供同样在其之上的各类渠道交互层调用的服务群而已，这些群也许会被分为账务处理服务群，分户处理服务群，经营分析服务群，内控授权服务群等等。而这类服务群又是被高度配置化，使其在一定程度上具备快速配置发布产品的能力。

凡事怕然而，
然而，构建理想模型的困难重重或者说基本不可能。不管是打破原有架构，过渡到新架构的困难，还是构建一个这样的总线应具备的调动其他服务犹如调动内部函数一样高效准确，应具备的业务流程高可配置，技术流程高可配置的要求的困难，都将使其在落地之时经过重重裁剪。

再然而，抛开单纯技术的视角来看银行IT系统建设的问题，同构、同技术等等会带来注入商务、人力团队建设等等系列问题。所有这些，其实归根结底都是为了 能够更方便 更安全 更个人差异化 更低成本的提供银行业务给每个人使用。

核心系统、信贷管理系统、信用卡系统这些还是会有，但是多了一个虚拟层，用来发布服务，对外是看不到有多少个系统，接口与实现分开，服务是接口，系统是实现这些服务而已。从实现上，各系统没必要同技术框架、同规范，这个不同是由ESB来实现的。
不过你提到的同质化，可能是标准上的，不单是技术的一些标准，也包括对个系统的要求，比如配置参数化之类的，可以通过服务来改变参数。
另外个人感觉，别想着一口吃个胖子，不要考虑把业务的东西的放在ESB上，否则ESB会很快死翘，这也不是ESB的长处，ESB是干技术活的，作技术支撑的。我觉得统一业务视图那些应该是另一个集中化的系统来完成的。