《EAI三年规划建议书(以BEA产品为例).docx》由会员分享，可在线阅读，更多相关《EAI三年规划建议书(以BEA产品为例).docx（30页珍藏版）》请在三一办公上搜索。
1、目 录一、剖析建行系统集成现状1三、毕博公司对建行三年EAI规划的建议1四、数据大集中4五、制定交换方法和建立其他系统7六、金融信息交换平台71、选择统一的技术和标准81.1、J2EE平台92、门户技术112.1、门户要求112.2、两级门户个性化实现方案122.3、多种前端接入实现方案133、整合层143.1、概述143.2、系统接入子层153.2.1、内部整合163.2.2、B2Bi183.2.3、设备前置193.3、输出整合193.4、BPM204、统一的安全认证机制214.1、建立客户信息管理系统224.2、建立认证LDAP服务器224.3、实现单点登录235、操作管理245.1、概述
2、245.2、分级门户同步应用管理实现方案256、开发部署27七、未来展望27八、规划实施的建议28一、剖析建行系统集成现状中国建设银行的应用系统环境经过多年的金融电子化、信息化建设，已经取得了长足的发展。到目前为止，中国建设银行基本上建成了支撑全国金融业务快速发展的三级网络体系和三大业务支撑系统。核心业务处理系统，支撑中国建设银行的储蓄、对公、信用卡等传统业务的发展。中间业务处理系统，支撑中国建设银行的个人信贷、代理缴费、个人理财等新兴业务的发展。管理信息系统，支撑中国建设银行优化资源管理，信息共享等内部职能的发展。在业务支撑系统的建设过程中，由于各大系统的集成商在技术设计和技术实现上缺乏全盘
3、考虑，导致中国建设银行目前的应用系统环境存在或多或少的弊端。这些弊端主要体现在：1、各个系统独立运作，缺乏统一规划和实施，导致各自的软硬件环境差异巨大，系统间的信息共享十分困难。2、各个系统的数据格式没有统一标准，不同系统间的接口没有统一规范，导致各自的信息也就很难被其它系统有效利用。3、各个系统极少有具备快速调整、灵活扩展的能力，这导致系统的生命周期很短，即使不断在更新换代，却很难适应业务的快速发展。4、众多应用系统的软硬件环境的不一致性导致中国建设银行的整个应用系统环境异常复杂，管理和维护十分困难。三、毕博公司对建行三年EAI规划的建议基于以上的分析以及多年和建行合作的理解和认识，毕博认为
4、，在保证数据集中，强大的企业运算的基础上，中国建设银行的应用系统环境需要有一个统一、灵活、简洁、易于扩展的应用基础架构，从而为中国建设银行的快速发展注入强大的技术动力。具体而言，毕博公司建议如下：在未来的三年中，中国建设银行应尽快建立功能强大的全国数据中心，以实现全国数据的大集中，解决目前信息分立的问题。同时，考虑哪些数据应保存在中心数据库中，制定相应的数据交换格式和交换程序，并建立与核心业务数据相配套的各种系统，如客户信息系统、决策分析系统等等。还需要找到集中和分散的结合点。既要保证数据的有效的统一管理，又要保证各地业务的独立和自主性。然后建立一个中心级和省级两级的以工作流形式驱动的金融信息
5、交换平台，在中心，使用这个平台，实现原有以及将来针对中心核心数据库开发的各种信息应用系统（如客户信息系统、数据挖掘系统等）与全国数据中心的互连通道；而在省级的金融信息交换平台则是各支行各种系统互连的基础平台；两级平台还可以作为总行和各级行的连接通道，可以负责数据的上传和下行，既能够保证数据集中到中心，又能够保证各省的独立性；既保护现有投资，也能够保证总行对各支行的管理和监控能力，还能够通过工作流驱动对现有的各种系统的调用迅速整合金融产品、快速响应市场的需要，从而提高中国建设银行的整体竞争能力。建设完成之后，整个建行的IT集成框架如下图所示，在省级和中心建立两级信息交换平台，两级之间通过TCP/
6、IP连接在一起，具体的实现方法将在下面章节讨论，这样的结构，能够保证各省的独立性，各省能够利用这个省级平台开展本地的业务，整合本地的各种系统，快速推出有本地特色的金融产品，而中心的信息交换平台则有几个功能，一个是负责从各省到中心的数据的上传和下行，并且在中心还可以开发与总行相关的各种后台系统和前置系统，这些系统也可以利用交换平台的路由与省级进行交互。这里所说的总行后台系统，是指与中心数据配套的各种系统，如客户信息系统、分析决策系统等等。而总行前置系统也是个借用的概念，指的是有前台表现界面的系统，例如总行级别的信贷系统、风险预警、国际结算等系统。整个方案的特点如下：1、 中心采用大机形式，能够保
7、证中心强大运算和交易能力，是整个框架的基础；2、 中心与省级互联采用通用的TCP/IP协议，能够保证整个框架的可扩展性和管理性，至于为何采用TCP/IP，而不是大机的专用协议，将在下文论述；3、 建立两级信息交换平台，既能够保证数据集中到中心以及总行的管理监控能力，也能够满足地方的独立性和自主经营能力。下面，将就如何实现这些步骤，详细描述如下：四、数据大集中金融体制改革和市场竞争要求中国建设银行等国内银行不断提升业务管理水平和风险控制能力。中国加入WTO后，国内外企业的合作将进一步加强，国内外资金往来将更加频繁和数额巨大，银行的国际业务合作也会增加。中国银行业需要抵御更多的来自国际金融市场的风
8、险，银行的决策分析将更加重要，因此，尽快建立全面、多维、集中的数据中心，为决策分析提供依托，是中国银行业也是中国建设银行的当务之急。同时，在银行业的竞争中，服务正逐步成为竞争的焦点。银行服务品牌的提升、服务成本的降低以及服务质量的提高亦将更多地依靠先进的信息系统来实现。而统一的应用系统和集中的管理也将发挥规模效益，促进银行服务的标准化和竞争力。因此，数据大集中是目前国内各大商业银行的大势所趋，也是银行实现统一管理和决策，解决由于原来的数据分布在各地，要层层上报汇总而导致的信息不畅，难以及时根据数据信息对市场做出反应，难以进行监管的种种弊端的方法。利用数据中心的强大处理能力将全国核心数据汇总于一
9、处，也有利于开发出良好的分析和挖掘工具，有利于进行决策、监管和推出市场需要的金融新产品。数据大集中也使银行面临着一些棘手的问题需要解决，例如集中后的系统处理速度问题、安全性、可扩展性和可管理性等，另外一个问题是，从国外银行“分散集中分散”的发展轨迹来看，集中和分散也是一个相对的问题。在银行系统中，数据集中到何种程度才能既满足统一管理决策的需求，又可以满足地区业务发展的差异性需求呢？这就需要各个银行在数据集中与分散之间寻找到一个最佳的平衡点，而这同样是对各个IT企业提出的课题。毕博认为，在全国数据中心采用大机系统或者类大机系统和大规模数据库，利用其强大的I/O吞吐能力和交易处理能力无疑是解决数据
10、大集中的处理速度问题的良好方法。而且大机系统的B1级安全级别以及历史上很少出现系统故障的记录也很好地解决了系统的安全问题。所以在全国数据中心采用大机模式是目前的唯一客观可行的解决之道。解决了全国数据中心后，便会面临着将哪些数据保存在中心的问题，也涉及到将来各省与中心如何连接，各种前置机如何改造的问题。由于不管将哪些数据保存在中心，至少核心业务将集中到中心进行处理，所以无论如何，我们都会面临着前置机改造的问题。目前，通用的做法是采用“大集中”与“设备前置”相结合的原则，“大集中”是指全辖核心业务集中处理，这有利于统一规范业务经营管理，顺应金融电子化发展潮流；“设备前置”系统是指各分支行系统采用前
11、置机的方式，负责支持本地业务的通讯、处理、路由、清分等工作，要求将以往多前置机的处理方式集成为一个“设备前置”，给分支行的本地业务的扩展带来了方便和灵活的条件。“大集中”和“设备前置”的有效配合是银行集中管理思想的体现，“大集中”没有“设备前置”的有效支持，无法对分支行的本地经营带来帮助，不能有效的分担主机的系统开销，不能减缓网络的压力，将束缚“大集中”的手脚，无法实现真正意义的“大集中”。由于大机是如此优秀，所以有不少人会主张设备前置或者叫大前置也采用大机模式。但是采用这种“大机一统天下”的模式是否就万事大吉了呢？在这里，我们应该本着客观的态度去看待这个问题，我们知道，夸大或者过度依赖某一种
12、技术都是不可取的，而是应该根据客观的需要采用与之相适应的技术，不应该对任何技术过于迷信。下面我们对大机模式和非大机模式进行分析，并根据建行目前的IT状况选择合适的模式。大机模式通常都是封闭的，如IBM的Mainframe，其它系统只能通过SNA卡或者网关设备（如IBM的COMMUNICATION SERVER）与之通信，并需要消耗一定的主机资源。这样的系统由于其独特性而可扩展性不强，不易于与目前已经存在的各种各样金融系统进行整合和交互，而且大机主机资源非常有限，一旦资源分配完了，必须再购买新的主机，所以，这种大机模式必须采用大量的资金来购买大机主机和大量的SNA连接设备。而且需要培养大量的大机
13、编程和维护人员，这样的代价无疑是很高的。另一种思路是走开放的路子，采用TCP/IP等网络通讯协议，在大机的前端放置交换设备，负责做SNA和TCP/IP的转换，在广域网的传输和各支行采用TCP/IP协议，这样就有效地保护了各支行的原有投资，也达到了各支行本地业务的独立性和自主性。毕博认为，由于目前建行各省均已实现了省一级的数据集中，大多采用了Tuxedo的技术，并且各省也已经在这个基础上实现了很多适合本省业务的信息系统，也培养了大量的开发和维护人员。因此推翻原来的系统而强制实行其他模式不是一种现实客观的做法。所以毕博公司建议在设备前置方面应采用开放的做法。这样也很好的解决了集中和分散的平衡问题，
14、也保证了系统的可扩展性和管理性（关于毕博公司的大前置方案可参看附件）。也为下一步建立金融信息交换平台奠定一个良好的基础。因为一个良好的金融信息交换平台必须是开放的。五、制定交换方法和建立其他系统在数据大集中和大前置建立后，根据所选用的形式不同，这时应该规定哪些数据保存在中心数据库中，并制定相应的交换格式和交换方法。由于这些与所选择的方式以及以后的金融信息交换平台有很大的关联性，甚至有可能与未来的金融信息交换平台融为一体，所以这里不详细展开讨论，而在下面的信息交换平台中提及其可能用到的技术。在中心数据仓库逐步建立后，我们应该建立与之相配套的各种系统，例如客户信息系统，对中心数据库进行挖掘分析的系
15、统、信贷系统、风险预警、国际结算等等，这些系统的建立与后面的金融交换平台所采用的技术有很大的相关性，总而言之，必须能够与金融交换平台很好地互连。鉴于篇幅的原因，这些系统在本建议书中不再展开讨论。六、金融信息交换平台银行中有各种各样的系统，这些系统要进行交互，必须建立一个金融信息交换平台。以便有效的利用现有资源，同时适应新的业务创新的要求。这样一个信息交换平台需要众多技术的支持，主要有以下方面：1、提供统一的应用技术和标准，为应用系统提供稳定、可靠、高性能、可扩展等最有力的技术支撑。2、提供门户技术来满足众多渠道的接入，众多客户访问的个性化和多样化需求，帮助中国建设银行为客户、合作伙伴和内部员工
16、提供统一的企业形象和一站式服务。3、提供集成技术来整合中国建设银行的现有应用系统资源，实现信息和资源共享，优化商业流程，以及实现与合作伙伴的信息共享和资源互通。4、提供统一的安全机制，为各个应用系统提供统一的认证、授权、审计等应用层整体安全方案。5、提供统一的和可扩展的系统管理机制，来简化应用系统环境的管理。6、提供简单易用的开发、部署工具，加快应用开发人员的项目开发，实现新业务快速的推向市场，占领市场制高点。也就是说，整个金融信息交换平台可以由六个部分组成，如下图所示：这六个方面相辅相成，统一的应用技术和标准决定着整个信息交换平台的形式和对内对外的通讯方式；也决定着其他五个方面的技术方向。门
17、户技术是整个平台对外的“脸面”，它必须能够支持多种渠道的接入，并且返回合适的格式和信息给各渠道。而集成技术则是整个交换平台的通路，负责连接各种系统，完成交换平台和各种系统的数据格式的转换，并且利用工作流引擎调度各种系统协同工作。而统一的安全机制则是整个信息交换平台的前提之一，用户要实现整个建行所有系统的单点登录，必须将各系统的安全机制统一到这个交换平台上来。统一的和可扩展的系统管理机制可以方便地对交换平台进行监控和管理。简单易用的开发部署工具有利于快速开发，为整个平台更好改变和增加应用以适应市场需要。1、选择统一的技术和标准要建立一个统一的简单的信息交换平台，必须选择单一的技术和标准。所选择的
18、技术和标准必须是些公开的标准，而且应该在企业级应用领域有大量的实施案例；另外，这些技术和标准还必须在可预见的未来有很好的前景，这样才能保证金融信息交换平台在短期内不至于被淘汰，并且能够有更好的应用前景。目前，从各种系统和应用实施的情况来看，只有J2EE平台。随着三层/多层企业信息系统结构的深度发展和下一代分布式计算模型Web Service的出现，企业应用中关于平台、框架、语言的竞争也愈演愈烈。J2EE平台在过去几年里一直引领着企业应用的潮流， J2EE是描述产品的标准，现在有很多符合J2EE标准的产品。在可以预见的未来，它将是构建企业信息系统应用的基础性平台，尤其是开发和部署Web Serv
19、ice的重要平台。尽管可以同时使用几种系统平台和语言，但对于企业来说，还需要选择一个战略性的平台来实现数据的无缝集成，加速企业应用的部署。而要做出正确的选择，首先需要充分了解J2EE平台的特点和优势。1.1、J2EE平台Java于1996年由Sun公司推出，当时它的主要用途是制作产生动态网页的Applet。后来，人们发现Java的“一次开发，多次运行”、纯面向对象的特性、垃圾回收机制和内置的安全性特别适合于开发企业应用系统。于是，企业应用开发商纷纷在Java标准版的基础上各自扩展出许多企业应用API，其结果导致基于Java的企业应用呈爆炸式增长。但是各企业系统API之间又不能相互兼容，破坏了J
20、ava的平台独立性。 鉴于此，Sun公司联合IBM、Oracle等大型企业应用系统开发商于1998年共同制订了一个基于Java组件技术的企业应用系统开发规范，该规范定义了一个多层企业信息系统的标准平台，旨在简化和规范企业应用系统的开发和部署。这一规范和其定义的平台就构成了J2EE。目前J2EE的最新版本是J2EE 1.3（J2EE 1.4还不是一个成熟的版本）。需要注意的是，J2EE本身是一个标准，而不是一个现成的产品（虽然现在有很多符合J2EE标准的产品），它由以下几个部分组成： J2EE规范。该规范定义了J2EE平台的体系结构、平台角色及J2EE中每种服务和核心API的实现要求。它是J2E
21、E应用服务器开发商的大纲。J2EE兼容性测试站点。Sun公司提供的一个测试J2EE应用服务器是否符合J2EE规范的站点，对通过该站点测试的产品，Sun公司将发放兼容性证书。J2EE参考实现。即J2EE SDK，它既是Sun公司自己对J2EE规范的一个非商业性实现，又是为开发基于J2EE企业级应用系统原型提供的一个免费的底层开发环境。J2EE实施指南。即BluePrints文档，该文档通过实例来指导开发人员如何去开发一个基于J2EE的多层企业应用系统。J2EE是除微软以外，SUN、IBM、HP、Oracle等各家公司力推的标准和平台，在企业级应用中占据着主导地位。在应用开发时，J2EE定义的四层
22、模型可根据实际情况灵活运用。由于大多数组件都可以访问数据库、EJB组件和企业信息系统，所以通过不同层的取舍及组合，可以衍生出许多应用软件开发模型，如基于Web的四层模型、基于桌面应用的三层模型（不包括Web层）、B2B模型（不包括客户层）等。如果应用系统比较简单，一般不用EJB作为逻辑层，而直接用Web组件来实现商业逻辑和数据访问，毕竟EJB的开发和部署费用还相当高。在平台的成熟度方面， J2EE在1999年形成了其成熟的架构，并且到今天已经有相当成熟的经过检验的企业应用系统。J2EE另一个重要特征就是它的架构开放性，它本身是一系列规范，而不是产品，任何符合这一规范的产品都是J2EE兼容的。这
23、使得J2EE从制订之初就得到了广泛的支持。IBM、Oracle等都相继开发了符合J2EE的应用服务器，它们的产品相互之间甚至可以兼容。从上面的分析以及以往的应用经验，我们有理由相信，目前在企业级应用中，我们应该选择J2EE。选择了J2EE，也就决定了我们的各种系统的互联需要遵循J2CA（J2EE Connector Architecture，J2EE连接器体系结构）规范。而信息的传递也将采用XML格式。在可预见的未来，Web Service也将进入我们的系统应用中，所以我们在选择平台产品也应该考虑其对Web Service的支持程度；而且，应该铭记在心的是，我们所选择的Web Service是
24、要满足企业级应用的Web Service，不是简单的Web Service，而应该是能够进行交易和安全监控的复杂的Web Service。综上所述，在信息交换平台选择的应用技术和标准，毕博推荐选择J2EE平台，信息交换采用XML格式，并考虑使用Web Service作为系统互联的将来的一种标准。关于XML、Web Service 等相关知识请参看附件。这里不再描述。2、门户技术2.1、门户要求门户（Portal）的概念来源于网站，在企业级应用中借用过来，特指为企业内外的各种用户，包括职员、客户、合作伙伴提供一个统一的连接入口，并根据用户的登录方式（如使用浏览器或者手机）、登录帐户权限和资料情况
25、为用户提供个性化的界面，并使用户能够通过这个个性化的界面使用本企业内部能够提供给该用户的系统功能或者服务。根据建行的业务要求以及IT系统的现状，满足建行需要的门户产品应该满足以下要求：1、 必须是J2EE技术实现，或者与J2EE有良好的接口。2、 必须提供一整套的门户基础服务（Portal Foundation Services），简化复杂的门户开发、维护和安全性，最大限度地发挥IT资源的总体效率。还应该为管理与客户和伙伴的交易提供了丰富的商务服务功能。3、 应该提供个性化和互动管理（Personalization and Interaction Management），可以通过模糊或清晰的个
26、性化改善用户体验，提高客户满意度和生产效率。4、 应该提供智能管理（Intelligent Administration），节约门户管理的时间和人力，在让门户用户访问所需资源的同时，降低IT管理的负担。还可让企业快速把握动态的市场机会，从而提高了企业的敏捷性。5、 提供强大的集成服务（Integration Services），采用标准方法，降低门户集成成本，同时借助Web Services实现企业内外的应用集成。它还应提供统一的访问者界面，并提供从分布式资源中搜集到的资料信息。6、 提供搜索、协作、社区和集成功能7、 提供规则引擎，并可实现分级的门户方案。8、 能够提供方便的单点登录解决方案
27、。9、 和金融信息交换平台的其他部分有很好的交互沟通能力。以上这些要求，都是适合建行需要的门户产品要满足的。只有提供了这些基本功能，才能构造一个适应新时代电子金融需要，满足各层面的用户需求的门户平台。在这些要求中，有些门户产品例如Web Logic公司的WebLogic Platform中的Portal部分就能满足需要。而综观整个门户和金融信息交换平台的关系，可能要解决几个问题：1、 单点登录问题。2、 中心和省级两级门户个性化的实现方式。3、 与金融信息交换平台的整合层的交互问题。4、 多种前端接入问题。单点登录问题在“统一的安全机制”一节中讨论，与整合层的交互问题在整合层部分讨论。下面主要
28、讨论 毕博所建议的两级门户个性化的实现方案和多种前端接入的实现方案。2.2、两级门户个性化实现方案两级门户个性化必须以实现单点登录为前题，我们为中国建设银行设计了两级门户个性化解决方案。在一个统一认证域中要实现不同级别门户的分别个性化设置会用到几方面的技术特性。1、 总行要建立统一的LDAP服务器存储客户信息，LDAP服务器只负责身份验证，而访问规则则是由另外设立的统一的策略服务器负责。在策略服务器内除了要记录用户是否已经登录外，还应保存用户的访问规则，该规则将会在访问中决定用户请求的资源是否允许被该规则访问。2、 在本地的Portal中会存储访问者的详细信息，包括除了从LDAP中获得的基本资
29、料和策略服务器中用户的访问规则以外存储在其他系统中的详细用户信息。通过 Portal中所带有的UUP(Unify User Profile)接口可以将各种数据源中存储的用户信息统一抽取出来形成一个完整的用户视图。3、 通过Portal的Rule Engine(规则引擎)可以按照用户的详细资料及其所具有的规则来确定如何为该用户分配资源或如何个性化该用户的使用规则。通过以上三点，我们可以实现在任何一个级别门户中用户都具有相对独立的和完整的个性化访问策略，从而实现两级门户的个性化策略。2.3、多种前端接入实现方案在可预见的未来建设银行的接入前端必定会以多种方式存在，例如手机访问、PDA访问、笔记本无
30、线访问、文字终端等。那么为了系统能够适应未来应用趋势的发展，我们为建设银行设计了多种前端设备统一接入解决方案。该方案核心部分是如何实现对接入端设备类型的判断。BEA的产品与其他产品最大的不同在于不是以网关位置来判断接入设备而是以访问协议来判断。通过该技术可以最准确最简便的判断出目前的接入设备类型。同时依靠Platform内置的内容翻译器可以自动对所提供的内容按协议及策略进行转化以适应当前的接入设备。通过BEA特殊的协议确定机制和自动内容翻译机制可以实现及其具有扩展性门户策略以适应未来几年内不断变化的应用需求。 协议确定机制和自动内容翻译机制属于整合层与门户交互的一部分，详细可参看整合层部分的相
31、关内容。3、整合层3.1、概述整合层是信息交换平台的通路。从过去的集成方式来讲存在有很多问题。首先各种集成都是以开发专有接口的形势相互连接，它会带来以下几个问题：1、 专有接口与互联的两个系统任何一方都有紧密地相关性，任何一边的系统升级都会导致系统间接口的重新编写。2、 两系统的互连接口会为两端系统都带来不稳定性因素。由于专有接口与系统的紧密相关性当接口出现故障时会导致两端系统的数据或是交易不稳定，从而影响系统的正常运行。3、 系统之间的联机事务处理信息无法互传，安全信息无法互传。开发专有接口外联其他系统时，原有的联机事务信息只能重新开始或进行无关性嵌套，破坏了对整体数据一致性的保障。从技术角
32、度来讲只有开发相当复杂的底层程序才能对事物进行跨系统的保障，且这种开发不具备重用性，浪费开发成本。同样安全信息的传递也存在该问题。4、 只能进行点对点通信，很难在两个以上的系统间实现整体性应用。针对以上种种问题，毕博认为整合层必须是一个基于成熟的J2EE产品的统一整合平台方案。而整个方案的核心在于要提供丰富集成手段，和优秀的事务管理及安全管理机制。这个整合层可以将任何一种系统集成进来，而集成方式均以松耦合的方式进行。必须提供灵活可靠的系统整合方式。针对建设银行现有状况我们认为整合层应该包含以下部分： 最低层是系统接入子层，负责连接各种各样的后台子系统，也是本系统与外部系统连接的通路（B2Bi）
33、。最上层是输出整合层，其主要工作就是与Portal或者直接与各种终端打交道。而在两层之间是BPM层，也就是所谓的工作流层或者叫做商务事件处理层，其主要工作是定义和执行各种工作流程，以工作流的形式驱动各种后台子系统相互交互，并且将各种数据经过输出整合层的转换，以适合的终端形式展示给用户，实现用户与后台各种子系统的交互。在用户看来，他只是在完成一个个工作流程或者操作流程，而无须关心他到底与哪些后台子系统打交道。3.2、系统接入子层系统接入子层主要负责连接各种后台子系统，这些属于内部的整合，内部整合应该采用J2CA标准，用其他标准如Web Service等来补充，也可以称这样的整合方式为“信息总线”
34、，这个子层还有一个功能是与外部系统打交道，也就是要实现B2Bi；另外的功能是中心与省级信息交换的通道，这个一般采用XML的格式，用异步也就是发送JMS消息的方法来完成，当然，这个只是初步的建议，具体可以根据实际情况来选择；另外，这里还考虑将大集中的“设备前置”放在这个子层，至于放在这里的原因请看后面章节的描述。综上所述，整个系统接入子层的组成部分如下图所示：3.2.1、内部整合内部整合，一般要遵循J2CA规范（J2EE Connector Architecture，J2EE连接器体系结构）。J2CA是J2EE规定的，如何与传统系统连接，实现EAI，也就是企业信息系统整合的规范。对于J2CA的知
35、识，可以参看附件。简单地说来，要为每一个遗留系统（我们可以将每一个需要连接的非Java编写的子系统称为“遗留系统”）开发适配器（adapter），然后通过适配器与遗留系统交互。由此可以看出，要成功地运用J2CA规范实现内部整合，需要实现交换平台的产品应该有一个集成框架（Integration Framework）和适配器开发工具包（Adapter Development Kit）。集成框架是方便地将各种适配器部署和交互的地方；而适配器开发包则可以让开发人员在没有现成的适配器的情况下利用这个开发包方便地开发系统所需要的各种适配器。除了支持J2CA的整合方式外，这个产品还应该提供数据整合或者数据交
36、换的功能，至少要支持XML与XML之间的转换，XML与二进制文件之间的转换。另外，该产品还应该提供Web Service的支持，以便在将来或者甚至是现在将各种子系统通过Web Service的方式进行集成。还应该提供对大机的整合方式，这样，如果性能允许，可以利用这个作为与大机连接的方式。例如BEA就提供这样的产品，BEA WebLogic Java Adapter for Mainframe可与BEA WebLogic Integration互操作，它在Java应用系统、IBM CICS或IMS应用系统之间，提供了双向的、在线“请求-应答”集成。由于它为Java开发人员和大型机编程人员提供了相
37、似的环境，因此开发人员在开发协作的应用系统时不需要额外的技能。根据目前建行各种系统的分析，至少要考虑以下集成：与Tuxedo的集成目前，建行有不少系统使用了Tuxedo，所以我们第一个要考虑的是如何与Tuxedo的集成，需要平台有Tuxedo的适配器。在毕博看来，这类集成由于原本已经使用BEA产品作为基础架构的系统，所以变得相对简单、一致，而且可以实现相对复杂的整合应用逻辑。从技术角度来讲，BEA免费提供的WTC(WebLogic Tuxedo Connecter)可以实现J2EE与TPMoniter产品间的双向沟通，并且可以传递安全与事物的信息，实现异构系统的完美整合。而且BEA公司也提供T
38、uxedo Adapter。与WebLogic Server的集成建设银行现有的网银和信贷系统都是通过BEA WebLogic Server来实现的。所以选择交换平台产品的时候要考虑的。如果使用BEA 的产品就相对简单，BEA Platform是架构在WebLogic之上的产品，其低层是WebLogic Server，而BEA WebLogic 之间的通讯具有同协议、同架构、同模式的特性。所以在系统连接层不需有过多的开发，也可以拥有丰富的通信手段。例如JNDI互调、RMI远程调用、JMS通知等。这类系统与新系统间可以应用WebLogic自有的T3协议进行沟通。T3时WebLogic Serve
39、r间通信的私有协议。使用它的好处是传输更加快捷，且可以跨防火墙进行通信。而且T3协议的使用方法与http完全相同。在编写T3协议的通讯应用中使用的技术完全是标准的J2EE应用。无须编程或管理人员在学习其他新技术。与BO的集成建设银行有一些系统如风险预警是采用BO来实现的，该系统的核心数据部分内容由于是BO系统内部封闭资源，所以无法以与WebLogic通信的方式来进行整合。除了利用J2CA或者Web Service来集成外，对这样系统，我们还建议通过WebLogic Server来传递底层资料，而上层应用数据信息通过URI Portlet来采集。URI Portlet是WebLogic Port
40、al内部自带的Portlet应用。它利用了Web Service技术，动态地将远程系统的输出直接捕获，输出在当前应用中，从而可以轻易的实现整合的目的。与文件系统的集成系统应该提供相关文件系统的适配器。用适配器的方式来集成。与数据库的集成系统应该提供相关数据库的适配器，用适配器来集成。与Socket的集成有些更古老的系统是用Socket来实现的，所以系统应该提供Socket的适配器，用适配器来集成。对各中间业务的集成及其他系统的整合除了J2CA的集成方式外，我们还可以考虑使用Web Service来进行集成。作为目前全球比较成熟的无关性集成手段Web Service具有成熟的通讯和集成标准，可以
41、提供安全与事物的传递功能。因此，在这类系统中使用Web Service对其集成是较清晰且易于实现的。这方面的集成需要两方面的开发工作，从BEA WebLogic Platform来讲,内部提供的企业级Web Service开发工具Workshop可以将Web Service的开发、设计、调试的工作集于一身，把Platform端的开发工作两降到最低。而在中间业务系统上的Web Service开发工作则与系统环境有关，例如在Delphi上可以使用Delphi的专有SOAP开发包，使Web Service的开发简单化。另一方面Web Service的应用优势在于可以尽量避免改动原有应用，而整合应用都
42、以附加服务的形势存在，最大限度的避免了大量开发和系统变更。有关Web Service 和 Workshop的知识，请参看附件。3.2.2、B2BiB2Bi主要用于与系统外的其他系统互联，比如与友行、基金公司、电信等的互联。当然，如果需要我们也可以在省级和中心两级交换平台互联的时候采用B2Bi的方式。由于目前的B2B强调的是供应链和采购，按照这一定义来建设B2B的企业肯定会受益无穷。除了供应链和战略采购活动外，这些扩展的定义还包括需求链中的各方，如分销商、代理和零售商，业务伙伴，如银行、保险公司、保健服务商以及后勤服务商。在某些情况下，这一定义甚至还包括企业内分散的系统，如刚刚收购的公司内的工作
43、流和系统或已有的海外业务单位的工作流系统。B2B集成的复杂性随着业务伙伴的增加而提高了。虽然一些点到点（Point-to-Point）解决方案借助Internet的广泛连接性，改善了传统的B2B系统，如EDI，但大部分解决方案仍缺乏实施B2B所需的强大的工作流管理和伙伴管理功能。许多企业仍依赖不可伸缩的架构体系或专有技术，其结果是要求大量的培训和集成工作，以实现企业信息系统的连接。采用这些技术，企业运营虽然可以暂时地得到改善，但他们发现这种做法缺乏灵活性，或者拥有成本太高。一个完善的B2B集成平台让企业能够与所有的业务伙伴实现在线互动和协作。让企业能够管理正在进行的交易和从分销商、零售商到供应
44、商、制造商以及其它服务供应商的关系。在技术方面，一个完善的B2Bi平台应该支持领先的开发语言和B2B标准，包括Java、RosettaNet和cXML。关于B2Bi的知识，可以参看附件。3.2.3、设备前置大家可能对于将大集中的设备前置放在这里觉得很奇怪。从逻辑和理论上来讲，为了结构清晰，设备前置应该是由整个整合层来完成。但是在目前的情况和实际应用中，由于我们要保证大前置的效率，我们应该将设备前置单独提出来，因为大前置涉及到大量的交易处理，需要的是快速反应，所以我们应该单独从专有技术例如Tuxedo来实现设备前置，只是在逻辑上将它当作信息交换平台的一部分。目前的信息交换平台的其他部分包括工作流
45、还是用于实现那些以异步方式，系统交互要求高的功能。当然，我们还是要求设备前置要和整个信息交换平台的其他部分有良好的接口，以便实现一些与设备前置有交互的功能。在可预见的将来，等系统性能提高后，我们再将设备前置在物理上与信息交换平台的其他部分融为一体。讨论完系统接入子层后，我们接着讨论如何实现输出整合子层。3.3、输出整合输出整合主要完成将流转的数据，按照特定终端所需要的特定格式进行转换，然后与终端的显示模版进行拼装，然后在特定终端进行显示。很难界定输出整合究竟应该归属与门户还是整合层，这里为了描述方便，将它归入整合层中。输出整合主要由三个部分组成，我们可以称之为协议确定机制、自动内容翻译机制和前
46、端拼装机制。协议确定机制的作用是确定终端是用什么协议接入的，例如浏览器采用HTTP协议接入，手机利用WAP接入等等。然后可以从协议确定终端需要什么样的内容，例如应该向浏览器传送HTML页面，向手机传送WML页面。自动内容翻译机制是个双向的过程，首先它可以向终端输送合适的内容，例如向浏览器输送HTML页面，向手机输送WML页面。另一方面，它可以从终端返回的页面中将所需要的数据内容抽取，进入平台流转或者操作。这个要依赖于XML、XSLT等技术，详情请参看附件。前端拼装机制是在前两种机制不能满足的情况下，另外为某些特定终端开发的专门的拼装器，它们主要完成例如返回的窗口界面微调等等功能。有了输出整合这
47、个子层面，我们可以很方便地与各种各样的终端进行交互，也很方便将终端的数据抽取出来，然后与后台的各种子系统进行交互。3.4、BPMBPM处于系统接入子层和输出整合子层之间，它能够以工作流的形式灵活地通过系统接入子层调度各种后台的子系统，也可以通过输出整合子层与各种终端交互，还可以实现各后台子系统与各种终端的灵活交互。除了在各级信息交换平台可以以工作流的形式实现本级各种后台系统与终端的灵活交互，我们还能够利用工作流调度机制实行中心与省级之间、省级与省级之间的灵活调度。这样我们就实现了一个强大的，能够及时进行调整适应市场需要的金融信息平台。业务工作流将整个企业内的任务、活动、决策和事件汇合成一个持续
48、不断的流，确保了企业业务的不断发展。即使企业受益于应用系统集成、业务工作流自动化，他们仍要依赖人员处理意外的事情，并做出关键业务决策。无论是强调对外部客户和合作伙伴的支持还是完全针对企业内事务，业务工作流的大部分仍依赖人力和应用逻辑来维持日常的业务流。此外，开发和管理业务工作流要求业务分析人员和IT人员具有专业技能。许多企业工作流仍依赖以应用为中心的工作流工具，并需要在应用之间进行手工编程，这些方法加剧了业务计划和IT工作之间的分割。即使手工程序是自动的，这些缺乏灵活性的、艰苦的编程连接仍是耗时、耗费资源的。一个完善的业务工作流管理功能应该为应用到应用的工作流、涉及到人工参与和系统、应用与人之间的混合工作流提供方便的解决方案。凭借其针对IT人员的基于Java的工作流引擎和针对业务分析人员的直观的设计和管理功能，可以让每个人都能专注于自身业务能力的建设，让业务分析人员设计、执行并优化工作流，让IT人员专门提供技术技
