架构关键点分析：

    ESB实现机制：

    选择一：WebSphere Enterprise Service Bus 优点：内置的转换、路由中介，并且可以通过客户化中介扩展；采用标准的编程模型（SCA, SDO）。

    选择二：WebSphere Message Broker

    优点：灵活的转换、路由能力；对负载均衡、高可用性上有很好的支持；支持基于MQ的可靠传输；支持多样化的连接方式。

    结论：此场景主要是业务部门级别应用，涉及的应用大多数都采用标准化技术，如：XML、Web Service等，也没有特别的分布式应用的需求。因此采用选择一，并利用WebSphere Adapter for CICS将非标准化的CICS应用连接到WebSphere Enterprise Service Bus。在随着企业向SOA全面转型的以后，建议引入Message Broker作为企业服务总线的骨干，当前方案中的WebSphere Enterprise Bus作为一个业务部门级别的节点接入骨干，形成整个企业的服务总线。

    应用服务的集成：

    选择一：Web Service

    优点：支持分布式调用；跨平台；支持开放性标准。

    选择二：EJB

    优点：支持分布式调用；支持不同的J2EE中间件平台。

    结论：企业服务总线是基于J2EE的实现，采用EJB的方式暴露应用服务，具备更好的性能。因此选择方案二。即使将来希望采用Web Service方式，在WebSphere Application Server上也能够很方便的将EJB（Session Bean）暴露为Web Service。

    贷款系统的集成：

    选择一：通过Web Service访问贷款系统。

    优点：支持开放性标准。

    选择二：直接通过JDBC访问贷款系统数据库。

    优点：支持分布式调用；性能较高。

    结论：通过Web Service 访问贷款系统，应用层访问的方式，保证业务的完整性，隔离具体的业务实现。同时避免直接访问数据库带来的安全策略等问题。因此采用选择一。

    最终，方案的架构涉及以下IBM的产品。

    IBM WebSphere Process Server提供的流程引擎、人工任务引擎和业务规则引擎为流程服务、人工服务以及基于业务规则的服务提供运行环境。

    IBM WebSphere Enterprise Service Bus提供的连通性能力以及转换、路由中介能力为企业服务总线提供运行环境。

    IBM WebSphere Business Adapter 的连通性能力帮助我们将基于CICS的核心系统功能暴露为功能服务。

    IBM WebSphere Application Server提供的J2EE容器为新开发的功能服务提供运行环境。

    为了验证架构的可扩展性，可以引入一些变化的场景来分析。

    保险公司的多样化支持

    由于各家保险公司的IT建设水平参差不齐，因此架构需要能够支持不同形式的接入。
   
    对于能够独立提供服务网关的保险公司，采用Web Service或者socket的方式通过ESB接入。

    对于不能提供服务网关的保险公司，可以实现一个人工服务，该人工服务遵循与合作伙伴服务同样的服务规约。可以让保险公司的人员访问该人工服务，或者由银行职员通过传真、电话确认信息，然后访问人工服务。

    上面这两种形式的担保服务，对于业务流程是透明的，ESB会根据用户选择的保险公司，将请求路由到保险公司的服务网关或者人工服务。在保险公司建立或者升级自己的服务网关的时候，系统只需要配置或者修改ESB就可以满足业务的需求。

    评估信用等级的变化

    现阶段，国内还没有统一的信用评估方案，随着相应的业务环境变化导致对信用评估带来的变化，是可以预计到的。

    短期的变化可能是信用评估的规则发生变化。由于每年各地的平均收入水平变化，信用评估的规则可能相应的调整。基于业务规则实现的计算信用等级服务，可以灵活的进行规则的修改。

    长期的变化可能是引入统一的信用评估平台。由国家或者第三方机构提供一个全国范围内统一的信用评估平台。只需要将现有的评估信用等级业务子流程替换为外部的统一信用评估平台提供的合作伙伴服务，通过ESB来弥合传输协议和消息格式的不同，整个业务流程依然保持不变。

    通过对上述变化场景的简单分析，我们验证了架构的可扩展性。当然这种可扩展性只能是在一定的程度上满足业务的变化，也只有通过对业务变化的前瞻性分析，对系统架构进行修正，才能更好的保证架构的可扩展性。这整个过程是一个迭代进行的过程。