企业应用集成EAI建设的最后一公里

作者：

欢迎访问e展厅 展厅 3 CIO信息化管理展厅 电子商务/企业门户, IT运维管理, 制造执行系统MES, 流程管理BPR/BPM, SOA/SaaS/云计算, ... 针对国内的实际情况，考验厂家们的产品能力重点经常不在EAI产品自身的特点、功能、适配器的数量。 EAI的发展过程 过去10年中，EAI技术使用并加速了众多技术的应用和成熟，如工作流（BPM）技术、适配器（Adapter）技术、Web Services技术等。根据 EAI领域的专业论坛Business Integration.com（即EAI Journal）的数据，目前EAI在全球的市场超过30亿美金！围绕着EAI技术提出的RTE（Real Time Enterprise）、APS（Application Platform Suite）、ESB（Enterprise Service Bus）等解决方案和技术架构层出不穷。 Business Integration认为市场的飞速增长来源于两个主要方面：需求的增长和新技术的出现与成熟。 EAI从最初出现到现在需要解决的问题场景发生了巨大的变化。70年代初中期的EDI技术可以算作是EAI技术的雏形。80年代中期，EAI技术迎来了第一次发展，那时UNIX系统和C/S结构逐渐成为可以采用的技术架构，而同时众多关键应用仍部署在大型机上（某些应用一直沿袭到今天，如银行业），解决开发系统与大机互连成为了当时EAI需要解决的主要问题。 90年代初，随着C/S架构成为主流的应用架构，中间件概念的出现和应用，CORBA规范的推出等主要的技术里程碑，以及众多ERP、MRP II、CRM等打包软件的出现，导致EAI技术也发生了变化，当时主要解决的问题在于如何利用中间件（包括MOM）技术实现与打包应用的互连。 90年代中后期，.COM的泡沫在成就了无数的百万富翁的同时，也带来了J2EE技术的大发展，包括90年代末期出现的Web Service和XML技术等。同时，CIO们面对日益增多的“信息孤岛”和不断变化的市场需要，72%（来自Gartner 2003年的一份报告）的CIO寄希望于EAI技术和方案。此时，EAI所肩负的职责，涵盖了包括应用服务器、数据转换和映射、适配器技术或应用连接技术、MOM技术、集成代理器技术（Integration Broker）、工作流技术、门户技术等众多技术。 需要指出的一点是，目前EAI技术的主要产品厂商主要来自国外，包括BEA、IBM、TIBCO、WebMethods等。其产品和技术在国外的场景下都有大量的案例，但是国内的情况与国外的情况存在许多重要的不同，如国外大量存在的COTS软件、客户拥有相对清晰的IT发展规划、技术实力相对雄厚的系统集成商和独立软件开发商等。因此，针对国内的实际情况，考验厂家们的产品能力重点经常不在EAI产品自身的特点、功能、适配器的数量。 本文的目的并非详细阐述各个技术的组成和技术细节，而是希望在概述一个相对完整的EAI技术组成后，结合笔者在目前电信行业正在进行的几个EAI项目中的经验，讨论EAI方案由技术到一个具体项目的实施转变中需要着重考虑的问题。 EAI技术的组成和架构概述 有关EAI技术的定义众多，下面首先给出来自TMF NGOSS 4.0 TNA 分层服务框架和eai-industry-consortium中关于ESB的架构图示。 eai-industry-consortium的ESB实际侧重了对一个EAI架构的消息处理、数据转换和应用连接三个层面的讨论，强调了以MOM技术为核心架构信息处理引擎，通过JMS、JCA、Web Services等异步方式达到与周边目标系统的松偶合集成。 而TMF今年推出的NGOSS 4.0中TNA架构的定义中详尽地描述了分层服务架构的TNA框架，将ESB的框架定义为SIM的一个重要组成部分，此外更加全面地讨论了电信行业TNA架构，包含： * 基础服务机制：主要是现在应用服务器、网关、集群等技术； * 基础框架服务：包含服务命名、查找、定位、调用等技术； * OSS框架服务：包含了那些组成业务服务的基础OSS服务，如日志服务、鉴权服务等； * OSS应用：具体的BSS/OSS服务组件； * 流程服务：包含BPM/BAM等技术，将流程控制与组件实现剥离； * 策略和安全管理：全前言的AAA控制； * SIM：信息共享模型和架构。 来自Gartner Group对应用平台套件（Application Platform Suite）的描述则是目前为止从技术角度最为全面和权威的描述，也是全面阐述EAI所需的技术堆栈的描述，如图2。 主要包含以下几个组成部分： * 交易处理应用服务器：承载电信企业海量和高性能的交易处理引擎； * 应用集成的集成代理器：包含了消息处理、数据映射、流程管理、适配器技术等完整的集成代理技术； * 用户交互的门户集成平台：承载多渠道、多协议、多人群的访问平台； * 共享的中间件基础设施，提供SOA、EDA的支持； * 共享元数据管理、数据共享模型和实现平台； * 集成的企业管理平台，支撑运营和管理； * 集成的开发部署平台，提供从门户、消息、数据转换、适配器、工作流、交易处理的集成开发、部署环境。 通过上述7部分组成一个完整的企业EAI的基础架构。 EAI的最后一公里 从中国的电信行业目前的情况来看，不同的运营商对EAI技术的需求重点各不相同，并非每一个项目中均会应用前面描述的完整的EAI架构中所有的技术，但是基础架构的搭建则是几大运营商的共同关注点。 通过参与中国电信、中国网通的几个EAI项目的建设，以下几个方面的问题应是客户、厂商共同考虑的重点。 数据模型和数据操作 EAI项目中不可或缺的部分是对企业的整体数据模型和数据操作的设计和考虑。数据模型是逻辑上的模式设计，而数据操作是物理上的技术问题。 数据模型的定义需要解决电信企业内部的“国际语”问题，而数据操作则是针对此数据模型在企业内部林立的软件、数据库中如何交互的问题，涵盖了数据同步、数据映射、数据转换、应用互连、流程控制等多个层面上的技术和方案。 独木桥问题 先进的EAI技术主要采用基于应用服务器的架构，即EAI星型架构，在企业内部不同应用域中依靠不同的EAI星型架构的联盟形成企业内部端到端的信息交互和服务共享。 显然，虽然并非所有的应用均需经由EAI平台，但是EAI平台还是会成为承载很多数据交互、数据同步、服务调用等的核心HUB。某种意义上，企业内部流程调度、信息交互的独木桥是否就形成了呢？ 因此，解决独木桥问题十分关键，也应成为选择EAI产品的重点。目前Server-based的EAI解决方案则依托相对成熟应用服务器技术，将集群技术、负载均衡技术引入到EAI平台的流程引擎、信息代理等各个层面，搭建多个平行的桥梁，增大EAI平台的吞吐量，从而解决独木桥问题。 流程设计 工作流技术无疑是目前电信行业解决方案的热点之一，尤其在BEA和IBM上个月的联合BPEL4J的白皮书发布后，工作流技术走向成熟和标准的步伐也在稳步加快。 但是在实施实际的项目中，我们发现流程设计对项目的影响远远大于某个产品的流程引擎的具体功能。主要的问题体现在以下几个方面： * 流程颗粒度。流程中调度的组件的颗粒度到底在什么水平上，什么情况下剥离出子流程或原子流程。颗粒度问题背后带来的是流程引擎执行的负载、后端数据交互的颗粒度以及数据库资源的负载等多方面的问题。 * 流程设计范式。异常流程、特殊流程、断线流程等众多流程的处理机制十分重要，往往影响到业务的顺利执行、插销、并行等要求。 * 有状态流程和无状态流程。有状态流程意味着状态信息的保存、管理和传递甚至是全局事物的控制，相对无状态流程而言对性能的影响以及复杂性都较高。合理利用有状态流程和无状态流程对系统运行态十分重要。 * 同步流程和异步流程。通常，前台业务受理采用同步流程，后台批处理采用异步流程。但是，同步往往意味着紧耦和，异步意味着De-couple。因此，合理利用异步流程和同步流程的结合对系统架构和未来的变更十分重要。 分布式支撑能力 以中国电信为例，一般一个省的用户在千万数量级，每月需要处理的各类工单在几十万的规模。显然，单纯考虑某个引擎、总线的吞吐能力，更为重要的是考量产品的分布式能力。 分布式能力也包含多个层面： * 组件的分布式，主要考量承载应用组件的应用服务器的分布式部署和运行的能力； * 消息处理的分布式，即前面谈到的独木桥问题； * 工作流引擎的分布式能力，即是否考验支撑多个工作流引擎的分布式集群架构。 * 依类型不同需要各行其道 目前有一种不够准确的理解，即引入了EAI方案和产品，则所有应用各类请求均需要经过EAI平台复杂的应用互连、数据交互、信息传递、数据转换、流程管理才能到达目的地，因此对EAI平台的处理能力、每秒支撑的信息包吞吐量、流程引擎数目、支撑的并发用户数给予了非常严格的高指标。 其实，EAI是一种解决方案而非一个产品或几个产品，是一种总体架构而非一个简单的工程。EAI解决方案底层的设计框架是SOA（面向服务的架构）理念。依照SOA架构建设、改造、封装各类企业服务，使这些服务可以被简单地发现、调用、管理。只有在前端所需的服务需要几个不同的后台服务或系统依照一定的逻辑步骤进行重组（Re-group）或需要集成人为的判断、操作时才引入流程管理的概念，包括自动化流程和人工介入流程。 原有的大量小事务密集型的OLTP应用（如缴费、查询操作）、后台的批处理操作、ETL操作等并不需要经由EAI平台复杂的集成逻辑和流程管理才能进行。 因此，在设计电信企业的整体EAI架构时，一定对每个不同的应用类型进行分析，达到各行其道的设计思路。 集成手段的多样性 谈到集成适配器（Adapter）只是众多手段中的一种，而且在针对COTS软件，如SAP、Siebel、Clarify时可以简化开发和部署周期。国内的情况是基本没有COTS软件在线，国内系统集成商的软件七国八制，国外的EAI专家面临国内的遗留系统恐怕也只能采用JNI、JMS、Http、Socket、DB Adapter等手段。 因此，先阶段考量集成能力的关键是否可以很方便地支持在于上述那些技术类型的集成手段的开发和部署。 用户规划的考虑 除去众多的技术问题之外，用户在EAI相关项目中也十分重要。EAI项目的建设是“牵一发，动全局”，又是基础建设成分多、短平快的效果不多的长期工程，涉及的技术也十分复杂。因此，用户的项目需求掌控、项目范围界定、项目进度把握等在EAI项目将会直接影响项目的成败。 EAI技术、解决方案、项目管理等各个方面都具有特殊性。因此，希望“将EAI由艺术转变为科学，由科学转变为成功的项目”，也需要对包括业务分析、架构设计、产品技术、项目管理等各方面的知识和能力进行一次EAI。(end)

文章内容仅供参考 (投稿) (如果您是本文作者，请点击此处) (12/4/2004)