遵循SOA规范的银行软件系统

遵循SOA规范（Service Oriented Architecture 面向服务架构）的银行软件系统，可以理解为是多个松散子系统协同工作的结合体。“松散” (松耦合) 意味着每个子系统（在SOA架构中被称为服务：Service）是独立开发，独立运行，但可能需要和别的子系统进行数据交换。比如有一个核心系统实现帐务处理的功能，另外还有ATM子系统，信用卡子系统，中间业务子系统等，需要和核心系统发生数据交换。为了实现子系统之间的协同工作和相互的数据通讯，需要专门的软件开发机制。因为原则上每个子系统的数据接口可能是不同格式的，可能导致无法直接通讯（就象中国人和美国人对话）．在SOA体系内，为解决这个问题，常用的方法是开发一个ESB (Enterprice Service Bus 企业服务总线)．简单的说，一个ESB程序就是一个万能翻译机：：当两个子系统需要通讯的时候，ESB可以把发送方的数据转化成接收方能接受的格式（有点象万能翻译机），传送给接收方．

SOA架构的优势在于每个子系统可以被重用（来源于面向对象开发中类的重用的理念），特别在有新的业务需求的时候．可以迅速整合所需的子系统，来搭建一个新的系统．因为在很多情况下，银行新的业务需求就是（至少部分是）原来一些老功能的组合．这样为新业务开发系统的过程就成了一个类似搭积木的过程．譬如一个银行的大客户系统：银行会给一些大客户专门开发一套结算系统．久而久之，就会有很多套结算系统，而且基本涵盖了大客户可能需要的所有功能．那银行可以利用SOA架构把每个功能开发成一个服务，就形成了一个大而全的体系．以后新的大客户如果需要新的系统，只需要到这个体系中抽取需要的功能，即组合成新系统．

衍生出2个问题：

1.　类似ESB的结构是必须的吗？除了"万能翻译",它有别的什么优点．如果每个子系统的都严格按统一规范来开发，包括它们的通讯借口，那为什么还需要ESB这样的结构？


2. Services之间明显是的松耦合，SOA要强调的似乎是通过某种机制（比如ESB）使它们结合成一个紧耦合的系统．不知道理解得对不对？[@more@]

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/25153496/viewspace-1043755/，如需转载，请注明出处，否则将追究法律责任。