毕博建设银行EAI规划建议书.doc

《毕博建设银行EAI规划建议书.doc》由会员分享，可在线阅读，更多相关《毕博建设银行EAI规划建议书.doc（15页珍藏版）》请在三一办公上搜索。

1、1 建设银行EAI规划建议书1.1 建行系统集成现状中国建设银行的应用系统环境经过多年的金融电子化、信息化建设，已经取得了长足的发展。到目前为止，中国建设银行基本上建成了支撑全国金融业务快速发展的三级网络体系和三大业务支撑系统。核心业务处理系统，支撑中国建设银行的储蓄、对公、信用卡等传统业务的发展。中间业务处理系统，支撑中国建设银行的个人信贷、代理缴费、个人理财等新兴业务的发展。管理信息系统，支撑中国建设银行优化资源管理，信息共享等内部职能的发展。在业务支撑系统的建设过程中，由于各大系统的集成商在技术设计和技术实现上缺乏全盘考虑，导致中国建设银行目前的应用系统环境存在或多或少的弊端。这些弊端主

2、要体现在：1、各个系统独立运作，缺乏统一规划和实施，导致各自的软硬件环境差异巨大，系统间的信息共享十分困难。2、各个系统的数据格式没有统一标准，不同系统间的接口没有统一规范，导致各自的信息也就很难被其它系统有效利用。3、各个系统极少有具备快速调整、灵活扩展的能力，这导致系统的生命周期很短，即使不断在更新换代，却很难适应业务的快速发展。4、众多应用系统的软硬件环境的不一致性导致中国建设银行的整个应用系统环境异常复杂，管理和维护十分困难。1.2 建行EAI最佳实践1.2.1 统一标准1.2.1.1 信息标准（SelfSubscribing）：XML/FIX/SWIFT UDDI/SOAP/WSDL

3、1.2.1.2 统一的技术平台（架构）J2EE（JMS/JCA）1.2.1.3 统一的开发部署工具1.2.2 门户技术（EIP）1.2.2.1 门户要求门户（Portal）的概念来源于网站，在企业级应用中借用过来，特指为企业内外的各种用户，包括职员、客户、合作伙伴提供一个统一的连接入口，并根据用户的登录方式（如使用浏览器或者手机）、登录帐户权限和资料情况为用户提供个性化的界面，并使用户能够通过这个个性化的界面使用本企业内部能够提供给该用户的系统功能或者服务。根据建行的业务要求以及IT系统的现状，满足建行需要的门户产品应该满足以下要求：1. 必须是J2EE技术标准实现，或者与J2EE有良好的接口

4、；2. 按照三层或者多层（Ntiers）的架构进行开发和规划；3. 必须提供一整套的门户基础服务（Portal Foundation Services），简化复杂的门户开发、维护和安全性，最大限度地发挥IT资源的总体效率。还应该为管理与客户和伙伴的交易提供了丰富的商务服务功能；4. 应该提供个性化和互动管理（Personalization and Interaction Management），可以通过模糊或清晰的个性化改善用户体验，提高客户满意度和生产效率；5. 应该提供智能管理（Intelligent Administration），节约门户管理的时间和人力，在让门户用户访问所需资源的同时

5、，降低IT管理的负担。还可让企业快速把握动态的市场机会，从而提高了企业的敏捷性；6. 提供强大的集成服务（Integration Services），采用标准方法，降低门户集成成本，同时借助Web Services实现企业内外的应用集成。它还应提供统一的访问者界面，并提供从分布式资源中搜集到的资料信息；7. 提供搜索、协作、社区和集成功能；8. 提供规则引擎（Rule Engine），并可实现分级的门户方案；9. 能够提供方便的单点登录（SSO）解决方案；10. 与企业信息基础设施（Infrastructure）有很好的交互沟通能力，实现业务与管理、服务与协作等手段的集成。以上这些要求，都是适

6、合建行需要的门户产品要满足的。只有提供了这些基本功能，才能构造一个适应新时代电子金融需要，满足各层面的用户需求的门户平台。在这些要求中，有些门户产品例如BEA公司的WebLogic Platform中的Portal产品部分就能满足需要。而综观整个门户和金融信息基础平台的关系，可能要解决几个问题：1. 单点登录问题。2. 中心和省级两级门户个性化的实现方式。3. 与金融信息基础平台的整合层的交互问题。4. 多种前端接入问题。单点登录问题在“基础架构”一节中讨论，与整合层的交互问题在整合层部分讨论。下面主要讨论毕博所建议的两级门户个性化的实现方案和多种前端接入的实现方案。1.2.2.2 两级门户个

7、性化实现方案两级门户个性化必须以实现单点登录为前题，我们为中国建设银行设计了两级门户个性化解决方案。在一个统一认证域中要实现不同级别门户的分别个性化设置会用到几方面的技术特性。总行要建立统一的LDAP服务器存储客户信息，LDAP服务器只负责身份验证，而访问规则则是由另外设立的统一的策略服务器负责。在策略服务器内除了要记录用户是否已经登录外，还应保存用户的访问规则，该规则将会在访问中决定用户请求的资源是否允许被该规则访问。在本地的Portal中会存储访问者的详细信息，包括除了从LDAP中获得的基本资料和策略服务器中用户的访问规则以外存储在其他系统中的详细用户信息。通过 Portal中所带有的UU

8、P(Unify User Profile)接口可以将各种数据源中存储的用户信息统一抽取出来形成一个完整的用户视图。通过Portal的Rule Engine（规则引擎）可以按照用户的详细资料及其所具有的规则来确定如何为该用户分配资源或如何个性化该用户的使用规则。通过以上三点，我们可以实现在任何一个级别门户中用户都具有相对独立的和完整的个性化访问策略，从而实现两级门户的个性化策略。1.2.2.3 多种前端接入实现方案在可预见的未来建设银行的接入前端必定会以多种方式存在，例如手机访问、PDA访问、笔记本无线访问、文字终端等，而且这种方式将成为银行开展业务和服务的主体。那么为了系统能够适应未来应用趋势

9、的发展，我们为建设银行设计了多种前端设备统一接入解决方案。该方案核心部分是如何实现对接入端设备类型的判断。/*BEA的产品与其他产品最大的不同在于不是以网关位置来判断接入设备而是以访问协议来判断。通过该技术可以最准确最简便的判断出目前的接入设备类型。同时依靠Platform内置的内容翻译器可以自动对所提供的内容按协议及策略进行转化以适应当前的接入设备。通过BEA特殊的协议确定机制和自动内容翻译机制可以实现及其具有扩展性门户策略以适应未来几年内不断变化的应用需求。 协议确定机制和自动内容翻译机制属于整合层与门户交互的一部分，详细可参看整合层部分的相关内容。*/1.2.3 信息基础平台1.2.3.

10、1 整合层（Integration）Internal(Adapter，Tools，Liquid Data )/ External(Gateway(FIX/SWIFT)整合层是各类系统接入企业信息总线的接口。在EAI技术发展的初期，大多产品关心的是信息系统整合(Enterprise Application Integration)。这些产品有些侧重于后台数据的迁移和整合，通过建立数据仓库来实现一定程度的应用集成，其实这仅仅完成了数据共享而不能实现业务的整合；还有一些技术试图通过一种中间语义来弥合不同平台、不同技术体系、不同编程语言。这些产品技术和其相应的策略，虽然在应用中收到了部分的效果，但与之

11、所期望的目标还有很大的差距，尚不能快速地、完美地解决实际问题。传统EAI技术在实现跨系统、跨平台的业务时，需要不同系统之间开发通讯接口。一般这样的接口都是根据当时所涉及的系统而定制的，采用私有和专用的逻辑连接（Private Connection）而不具备通用的技术标准，因而不能被重用(Reuseable)。当一个系统要与N个系统的情况进行整合的情况下，则至少需要开发（N1）系统接口，还必需对N个系统的内部业务逻辑有一定的理解和把握。这种整合方式都是以系统点对点间专有的技术接口形成，会带来以下问题： 专有接口与互联的两个系统任何一方都有紧密地相关性，任何一边的系统升级都会导致系统间接口的重新编

12、写。 两系统的互连接口会为两端系统都带来不稳定性因素。由于专有接口与系统的紧密相关性当接口出现故障时会导致两端系统的数据或是交易不稳定，从而影响系统的正常运行。 系统之间的联机事务处理信息无法互传，安全信息无法互传。开发专有接口外联其他系统时，原有的联机事务信息只能重新开始或进行无关性嵌套，破坏了对整体数据一致性的保障。从技术角度来讲只有开发相当复杂的底层程序才能对事物进行跨系统的保障，且这种开发不具备重用性，浪费开发成本。同样安全信息的传递也存在该问题。 只能进行点对点通信，很难在两个以上的系统间实现整体性应用。随着时间的积累和不断增长的业务需求，需要更多的代码、软件和硬件。这不仅造成重复开

13、发和大量资源的浪费，而且使系统越来越复杂、直至无法控制。显而易见，采用开发接口的这种方式来实现系统通讯存在着诸多弊端，属于短期、临时性的行为，不能作为长期的规划和解决方案。在这种情况下，EAI的概念开始由整合（Integration）发展演进为协同（Interoperability）和聚合（Convergence）的思想方法，通过信息总线技术即消息中间件实现企业信息系统的集成。目前，建行的业务系统中包含了各种体系架构、接口、协议标准和通讯连接方式。采用信息总线进行整合时，必须将这些静态私有连接、数据对象、底层系统服务等接入到信息总线中。如果不能做到这一点，而仅仅将新的应用系统建立在信息总线上就

14、无法实现整合的真正目的。整合层就是实现各类传统技术体系的应用系统接入企业信息总线而设置的。整合层的核心在于要提供丰富集成手段，和优秀的事务管理及安全管理机制。这个整合层可以将任何一种系统集成进来，而集成方式均以松耦合的方式进行。必须提供灵活可靠的系统整合方式。我们根据建行现有系统、以及未来业务的发展，对整合层做了如下的规划： 企业内部（Internal）：业务应用系统处理：1. 大机专有接口系统（SNA与相应网关设备）；2. 基于Socket的接口（ATM/POS）等；3. C/S应用系统COM/DCOM、CORBA/IIOP等；4. 系统服务接口：RMI/RPC/SNMP等。这些系统有些可以

15、通过开发Adapter来实现接入信息总线，而有的要采用Gateway方式接入信息总线。Adapter的开发应采用开放式的技术架构，如JCA和JMX。或者直接采用商业产品，如：BEA WebLogic Java Adapter for Mainframe。对结构化数据和非结构化数据（文件系统）的处理：通过XML与J2EE的EJB技术，将静态数据块和查询抽取转换为流动的数据（Liquid Data）与服务（Service），促进并实现信息的快速流动与共享。 企业外部（External）：企业外部业务主要包括证券业务、基金业务、保险业务、国内与国际清算业务以及与人总行间的数据报送等。这些系统及其接口

16、都是业已存在，并具有一定的技术规范。对这类系统的整合集成，无论是国内的分业运营模式、还是国外的混业经营模式，我们认为采用Gateway的技术方式较为理想。对于业务比较单一、构成简单的业务系统，Gateway只是实现信息总线接入而已。当业务发展扩大、或者内容较为复杂、涉及更多的机构实体时，Gateway应采用诸如SWIFT/FIX等的技术标准体系来实现。1.2.3.2 信息总线层（Information Bus）消息中间件（MOM）信息总线是进行系统和业务整合的核心基础。采用信息总线技术后，系统之间通过一条公共的信息通道进行协同。由于采用了开发和标准的信息结构，在技术上通道内的所有信息内容都能够

17、被任何一个应用系统理解并使用。在实际应用中，每个应用系统根据业务需求只需要侦听和收集自身所关心的业务信息即可。每个相对独立的应用系统，只要根据标准定义开发出与总线之间的适配器（Adapter），就可以简单、快捷地纳入信息技术总线，而不需要具体了解其他系统的技术细节。（语法调整）信息技术总线构成了企业的信息化平台，使整个系统架构化繁为简，并获得了良好的可伸缩性。1.2.3.3 安全层（Security）加/解密与授权/认证（SSL, SSO, Authorization/Authentication）：LDAP/CIF1.2.3.3.1 建立客户信息管理系统（CIF）我们认为，总行应该对用户信息

18、管理包括客户信息管理有足够的认识，数据大集中，也要考虑建立整个总行的用户信息管理系统，包括客户信息管理系统（以下为了表述方便，将统一称为客户信息管理系统）。因为客户信息是建行的重要资源，也是我们识别客户、为客户提供更好的服务的基础。所以应该建立一个完善的客户信息管理系统，在全国中心建立后，总行应该制定统一的客户信息规范。然后根据规范建立客户信息系统，至于这个客户信息系统采用集中的方式，还是各省存放，中心对比整理的方式，可根据具体需要而定。所谓的集中方式，是指将客户信息管理系统只建立在全国中心上，各地都需要经过中心来取得客户信息。这样的方式比较简单统一，但缺乏灵活性。所谓的各省存放，中心对比整理

19、方式，是指总行制定客户信息规范，由各省自行建立自己的客户信息系统，然后中心通过信息基础平台将数据同步到中心存放，并对比各省客户信息系统，保证各省客户信息的一致性。这种方式比较灵活，但是机制比较复杂。这里将不讨论建行应该采用哪种方式建立客户信息系统，而是强调客户信息系统对于建行的必要性。1.2.3.3.2 建立认证LDAP服务器尽管可以直接使用客户信息系统来进行统一认证的工作，但是我们仍然可以利用LDAP服务器来建立认证的入口。这样做的好处有很多，例如不将核心的客户信息系统太过暴露；还有就是LDAP服务器存放的数据量少，可以快速认证，只有要实现复杂的个性化时才到客户信息系统去寻找客户信息。当然，

20、要建立LDAP服务器与客户信息系统的同步机制，否则就没有意义了。采用LDAP服务器的好处还有很多，例如可以将客户认证集中于一点，然后加强这个单点的安全，这样黑客的攻击更加困难；而且也易于总行的证书发送机制，易于总行进行控制管理调度等等优点。1.2.3.3.3 实现单点登录有了上述的准备后，我们就可以实现单点登录（SSO，Single Sign-on）了。实现单点登录有两种方法，一种方法是购买第三方SSO产品，例如业界比较著名的Siteminder。另一种方法是自行开发实现。使用成熟的第三方SSO产品相对比较简单，只需购买实施即可，这里不再讨论。自行开发要涉及很多方面的工作。我们下面举例说明单点

21、登录该如何实现。所举的例子是如何实现两级门户的单点登录方案。 在本图中，我们为建设银行设计了统一安全认证分级门户建设的解决方案。从物理上在总行设立统一的CA认证服务器和LDAP服务器负责系统层的安全与认证。总行和几个大型分行分别建立Portal服务器。在Portal服务器与CA、LDAP服务器之间单独建立策略服务器，策略服务器在整个系统中起到确认登录情况与分配用户登录规则的核心机能。独立而统一的策略服务器可以保证后台能够统一接入多种认证方式，同时不影响前端的门户架构及门户应用模式。另一方面独立的统一策略服务器也使用户在不同级别的门户间请求路由时无需再次确认身份，而只需到策略服务器取得已注册的身

22、份及其所具有的策略。从Portal角度来讲Portal本身可以负责自身的内部资源访问，因此各地的Portal都可以定义自己的规则引擎，当Portal从策略服务器取得当前请求客户所拥有的规则时，Portal便可以通过规则引擎对该规则进行核对，分配相应的资源给该请求客户。从管理角度讲，总行管理人员可以管理包括LDAP及策略服务器在内的所有资源。而分行管理人员只能管理其管辖范围之内的Portal资源，而对任何涉及更高级别的资源管理则只能通过对总行门户的资源请求，然后经有总行门户管理人员确认管理内容。通过实现以上认证、资源分配与管理，三方面的实现方案可以在建设银行内实现统一的单点登录策略。使行内任何一

23、个员工在任何网络地点都可以获得特定策略访问指定资源。1.2.3.4 工作流引擎层（BPM）1.2.3.5 工作流基本概念工作流是业务过程的计算模型，即将相应的业务逻辑和业务规则在计算机中以恰当的模型进行表示并对其实施计算。业务过程是若干业务活动的集合，这些业务活动按照一定的规则前后链接在一起，相互协作，以便达到一个共同的目标。业务活动则是能够完成特定的功能的一个实际环节，它在信息系统中通常针对具体的应用逻辑。为了对工作流管理系统的开发起到一个指导作用，工作流管理联盟（WfMC）给出了工作流系统的一个通用框架工作流参考模型。在工作流参考模型中，工作流引擎是工作流管理系统的核心。工作流引擎主要包括

24、机构模型、信息模型和控制模型三种模型，前两者合称为工作流引擎的数据模型。工作流引擎是为工作流管理系统在定义提供支持、同时在运行时提供解释和执行服务的一组数据模型和软件。因此从功能上看工作流主要包括工作流可视化过程建模、工作流引擎驱动、客户端任务管理三个模块。为保障众多工作流产品的互用性，WFMC提出了基于XML的XPDL标准。凡遵循XPDL标准的工作流产品，均可实现三个模块的无缝集成。可视化建模工具流程逻辑应用逻辑流程逻辑应用逻辑流程逻辑应用逻辑数据库接口（数据库通信协议）D B M S机构模型信息模型日志信息应用数据引擎控制器C/C+接口Java接口工作流应用框架1.2.3.5.1 工作流可

25、视化过程建模工作流所谓工作流的定义指的是由谁来定义和开发工作流的应用。业务人员和专业技术人员相结合。工作流产品提供图形化的界面供业务人员（或者结合专业人员）定义业务逻辑和规则，具体的应用逻辑则由专业开发人员完成。建立真正复杂、灵活而且可扩展的应用系统，必须将工作流的开发融合到信息系统的开发过程中，从整个信息系统的角度来定义工作流中的业务规则、任务流转以及相关角色。工作流定义涉及部分机构模型和信息模型。机构模型指任务承担的部门、团队以及个人的信息。信息模型包括活动类型、业务规则、任务指派1.2.3.5.2 工作流引擎工作流引擎控制模型将机构模型和信息模型有机地结合在一起，它根据其中定义的业务规则

26、对业务过程中的各项业务活动的流转以及任务指派等工作进行控制和协调。具体包括以下几个部分l 调度中心调度中心接受从外部接口发送过来有关流程控制的请求（如业务初始化、获取任务以及结束任务等），然后根据不同的请求类型调用相应的处理模块完成与本次请求相关的操作并将结果返回。l 任务管理任务管理主要根据调度中心的指示完成诸如任务创建、任务状态的转换以及相关数据的维护等工作。如图所示。初态PendingWaitingProcessingPausing终创建任务同步完成获取任务结束任务挂起复位汇聚同步任务状态转换图l 任务指派任务指派处理只是针对常规交互活动，通常情况下，在任务状态由“Pending”切换到

27、“Waiting”过程中完成任务的指派工作，即处于就绪状态的任务在通常情况下都确定了其执行者（FCFA除外）。任务指派过程首先根据任务指派基准确定可以执行此任务的群体人员，通常情况下这是一个包含多个人员的集合；然后根据任务指派方法确定由这个群体中的哪些个体来执行任务。l 依赖检查依赖检查指的是活动的前依赖规则的检查，调度中心在将任务切换到就绪状态之前将进行相关的前依赖规则检查，只有满足检查条件的任务才可以进行状态的切换。前文已经描述了前依赖规则在数据模型中的表示方法，这里主要讨论在控制模型中是如何对各种前依赖规则进行处理的。l 转发控制当应用发出“结束任务”的外部请求时，该请求将触发调度中心启

28、动“转发控制”。转发控制的主要依据在工作流数据模型中定义的后转发规则，后转发规则定义了当前活动与其后继活动之间的关系。l 启动控制启动控制负责常规自动活动的所对应的自动执行体的启动并对其活动进行监控。对于业务人员来说工作流引擎是不可见的。工作流产品开发商负责工作流引擎的实现。1.2.3.5.3 客户端任务管理工作流引擎将涉及机构模型和信息模型数据推松到客户端，客户获得各种任务列表。客户可以查询任务列表，定义任务优先级，管理任务执行状态。1.2.3.5.4 工作流标准目前市场上运行的工作流产品众多，但在三种模型的标准上各行其是，大都难以实现集成。鉴于此WFMC提出基于XML的XPDL标准，它参考

29、了众多比较成功的工作流产品，全面定义了机构模型、信息模型、控制模型等三种模型的统一标准，同时它采用先进的XML格式，从而保证了所有基于XPDL开发的工作流产品可以实现跨网络跨平台的无缝集成。因此本系统采用基于XPDL的工作流产品。1.2.3.6 工作流管理的实现本系统采用基于XPDL标准的工作流引擎，提供工作流过程定义、过程活动分配、任务管理、工作流过程记录及日志管理等功能，实现具有高度兼容性的抵债资产业务过程自动化管理手段。1.2.3.6.1 工作流程过程定义本系统利用图形化的手段设计工作流过程。业务人员可以方便自定义各类活动，并灵活的设置每个活动的开始条件、结束条件、活动间的复杂关系以及跳

30、转规则。工作流实例启动后，工作流将在工作流引擎的推动下依照设计好的过程运行。从而实现抵债资产管理的自动化管理。1.2.3.6.2 角色管理及工作流活动分配工作流中每一个活动需要由不同的角色来完成，工作流实例产生的任务也必须发送给指定的执行人，系统中的工作流活动分配用于完成这个功能。工作流活动分配的前提是角色管理，即对工作流过程中涉及到的所有操作角色的管理工作流活动分配为每一个活动分配需要的执行角色，这样工作流任务将自动在各个角色之间流转，提高管理效率。1.2.3.6.3 工作流任务列表在本系统中，每一个工作流过程的实际产与者看来，工作流就是一个个待处理任务列表。通过工作流任务列表，每个角色将自

31、动获得待完成任务列表，对待完成任务进行等级设定，将非常容易了解自己一段时间内的分配任务、已完成任务、未完成任务、已转交任务，及时发现工作中的问题和症结，改变工作方式，从而提高工作效率。1.2.3.6.4 工作流过程日志系统的工作流过程日志将对工作流执行的每一个活动进行记录，一可以提供系统管理员监控管理工作流执行过程的依据，二可以为过程分析和改进提供支持。采用工作流系统可以实现动态的工作流程配置，使流程描述逻辑抽离出来（Non Hardcoding）。当工作流程发生改变时，业务逻辑不用重写，仅需要简单的配置和部署就可以完成重组过程。这个系统，还要具有友好的图形化方式、进行动态的部署和配置集成于信

32、息基础平台上各个应用系统间的工作流程和信息流程，而不需要再次编程开发的工作。使企业能摆脱频繁开发，反复修改的恶性循环，从而更好地适应市场和业务的发展变革。1.2.3.7 监管层（Monitor）除了统一的应用技术和标准、门户技术、整合层和统一的安全认证外，信息基础平台还应该易于操作和管理。信息基础平台应该提供丰富的命令行、基于Web的管理界面等多种手段来方便平台管理人员操作和管理整个信息基础平台。完善的操作管理应该考虑以下方面的管理： 配置管理平台应该有良好的配置管理界面，至少应该能够让管理人员简单而方面地进行各种应用组件和系统的部署和管理功能。应包括功能管理、工作流、适配器、报文管理及其它平

33、台有效运行必须的配置信息等等。 资源管理系统应该系统丰富的资源管理功能，至少要实现对各种数据库资源、文件资源的管理。 系统发布管理系统应该实现对后台各种接入子系统的管理，可以方便地在平台中发布或者卸载任何一个后台子系统。 渠道接入管理系统应该实现对各种接入渠道，各种接入终端的管理，可以方便地将新的终端接入到平台上来，也可以方便地去掉某种终端。 性能和效率系统应该提供对运行时各个系统的性能和效率的监控和调节。 事务管理系统应该提供事务的监控功能。 异常处理系统支持超时控制，异常处理保证平台不能崩溃，异常信息需要保存到日志，并可以送往合适的展示渠道。 日志系统系统应该提供丰富的日志功能。记录系统运

34、行的各种状态，建立多级或者多种日志，例如交易日志、系统日志、跟踪日志、错误日志等等，平台还应该提供日志的备份、清理、查询功能 稽核接口系统还要提供稽核、审计的接口，以实现安全管理、业务跟踪等功能，并在必要的条件提供给上级主管部门。由于以上种种管理和监控功能是在一个分级的信息基础平台上实现的，所以功能极其复杂，不可能有一家产品就能够提供完善，我们还需要另行开发才能完成完备的管理和监控功能。这就需要我们所选择的产品对外提供良好的管理编程接口。同样，在技术实现时建议采用J2EE的JMX的编程接口，并且要提供符合JMS标准的消息服务器。这样，我们才能够编写出完善的能够管理我们这个非常复杂的信息基础平台

35、的管理和监控工具。1.2.4 建立消息、数据定义体系并确定质量服务标准（QoS）系统服务（SNMP）、数据服务（XML Metadata）与应用服务（SWIFT、FIX）划分实时服务与非实时服务划分内部服务与外部服务划分（企业内外、分支机构与总部）P2P服务与P/S服务划分加密强度划分容错系统与非容错系统划分（Single Failure Point）管理信息与业务信息划分1.3 EAI案例个人汽车信贷服务系统1.4 附录：消息中间件产品与技术介绍1.4.1 Tibco RendezvousTibco Rendezvous是Tibco公司的核心软件产品之一。在此基础之上，Tibco公司还开发了

36、大量的用于EAI的软件产品，包括应用服务器（Application Server）、工作流引擎（Business Process Manager）等。Tibco公司最为专业EAI产品提供商，其产品被国外许多大型金融机构所采用。尤其是Tibco Rendezvous，在实时性、可靠性方面具有优异的表现，因而成为事实标准被广泛应用于证券、外汇、期货（权）买卖交易、汇兑支付以及实时清算业务中。 Tibco Rendezvous产品具有完备、典型的信息总线的特征，具体体现在以下几方面： 实时性 (Real-time)Tibco Rendezvous对网络UDP协议作了优化，而且由于信息总线基于多点广播

37、(Multicast)发送的方式（Public/Subscribe），充分挖掘网络的传输潜力。因而， Tibco Rendezvous具有非常可观信息吞吐速度，能够满足诸如证券交易这样对实时性要求极高的应用。 单次可达 (Send only once and Receivable)在传送信息过程中，Tibco Rendezvous可以承受网络故障、甚至是主机系统掉电这样的故障，而保证收发状态（State）的完整性和消息序列（Message-package Sequence）的正确性。当故障排除和系统恢复后，信息仍然可以继续收发，并不需要上一层应用系统干预、或者重新发送。这种被称作单次可达的机制

38、，在金融系统的实际运用中具有极其重要的意义。 负载均衡（Load Balancing）大型的业务系统，必须要具备负载均衡能力。Tibco Rendezvous基于信息总线实现了应用的负载均衡。各类（前端）应用请求、或者是订单，通过Tibco Rendezvous及其工作流系统分配到不同的应用系统、或者是同一系统的不同的主机。这就是动态的、可配置的负载均衡机制，可以使系统拥有更大的灵活性和伸缩性，亦可实现在不中断业务的情况下对系统的升级、维护。 分布式消息队列（Distributed Queue）与传统的消息中间件不同，Tibco Rendezvous采用了分布式的消息队列（Message Qu

39、eue）同时在发送端与接收端维护两个消息队列，从而在技术架构上避免了发生单点故障（Single point failure）的可能性。 容错（Failure-Tolerance）Tibco Rendezvous通过信息总线的负载均衡机制，可以自动的屏蔽故障节点（Failure-Node）,并基于分布式消息队列机制，把部分送达和未发送的消息路由（Routing）到其他正常节点，为应用系统提供非常可靠的容错能力。 分布式事务管理（Distributed Transcation）Tibco Rendezvous还通过RVTX提供了分布式事务管理的功能，可以使通讯的应用系统之间实现跨平台、跨系统的一致

40、性事务操作。当位于Tibco Rendezvous上一个应用系统进行发送（Send）和提交（Commit）时，事务管理即开始启动直至每个接收端都接收并完成各自的事务为止；任何一个步骤失效都会导致全体的事务会滚，包括最初的发送端。 远程守护进程（RVRD）Tibco Rendezvous上述的所有特性都可以通过远程守护进程（RV Remote Daemon）在互联网（Internet）这样的广域网络上实现（WAN）。 网络设备支持（Network Support）为了进一步提高和优化网络传输性能，实现在广域网络上的快速和可靠工作，Tibco与网络设备厂商Cisco公司合作开发了一个新的网络协议P

41、GM（Pragmatic general multicast）。PGM为大多的网络硬件设备所支持，如：路由器等。PGM将软、硬件技术结合起来，可以成十倍提高企业现有网络的带宽性能。 支持开放式技术标准（J2EE/JMS）基于JAVA的J2EE架构体系在应用开发领域起着越来越重要的作用，逐渐成为快速组件化、跨平台应用开发的标准。顺应这一趋势，Tibco Rendezvous同时支持Java消息服务标准JMS(Java Messaging Services)，使应用系统中的EJB组件可通过JMS直接获得Tibco Rendezvous的实时可靠的技术特性。此外，Tibco公司还提供了两个与信息总线

42、产品密切相关的系统： 集成工作流引擎（BPM）由于工作流系统在信息总线应用中的重要作用，Tibco还推出了BPM（Business Process Mamager）系统。这个系统，可以使用户通过友好的图形化方式、动态的部署和配置集成于Tibco Rendezvous上各个应用系统间的工作流程和信息流程，而不需要再次编程开发的工作。 集成管理信息系统（Hawk）伴随着系统集成规模越来越大，系统与主机及其相关设备的管理维护工作也越来越复杂。为此，Tibco推出了应用于Tibco Rendezvous的管理信息系统Hawk。Hawk系统通过图形化的方式，可以实时监控整个系统的运行，并进行管理、配置和

43、维护等工作，充分体现了信息总线技术的优势。1.4.2 BEA MessageQ BEA的MessageQ前身就是集成在其著名的Tuxedo产品中。Tuxedo作为早期的、知名的中间件系统，在金融行业有着广泛应用。很多国际知名金融企业都采用了BEA的解决方案，如：德意志银行、嘉信（Charles Schwab）公司等。MessageQ产品同样具有优异的实时、单次可达等的特性，在很多方面与Tibco Rendezvous相当作为J2EE产品主要厂商之一，BEA MessageQ与J2EE的产品集成非常简便，可以与BEA优秀的应用平台产品，如：应用服务器、集成平台、工作流系统等，一起构成理想的总体解决方案。1.4.3 IBM MQ SeriesIBM MQ Series是IBM公司的著名的消息中间件产品。由于IBM公司的影响力和MQ Series产品的长期发展历史，MQ Series在各行各业中都拥有着广大的用户群。按照IBM的发展策略，MQ Series与IBM其他产品，如：WebSphere、CICS等构成了系列解决方案。