1. 介绍
1.1. 本文目的
本文的目的在于针对中国电信行业EAI的建设，从技术层面提出几点架构性建议，供电信运营商在系统的规划中进行参考。其中涉及的内容是基于多年在电信业的经验进行陈述，同时注意到在这些关键的技术架构方面，直接影响到电信运营商业务支撑系统的长远规划。
1.2. 范围
本文包含以下主题：
·EAI技术路线
·电信共享信息/数据模型
·接口参考模型与适配器架构
·电信业务流程模版
·流程补偿机制的实现--保证交易的一致性
·EAI的高端解决方案--业务行为监控(BAM)
·解决EAI性能瓶颈
·电信行业EAI项目管理实施经验
2. EAI技术路线
2.1. EAI技术概述
企业应用集成(EAI)的核心是使用中间件连接企业应用。有多种不同类型的中间件可以提供EAI的功能。在选择EAI中间件时需注意以下的基本特征：
·通过中间件将不同的应用连接起来，保证应用的独立性，在不需要修改应用自身的业务逻辑的同时，又解决了数据共享问题。
·对核心共享业务数据模型的处理与支持。
·实现业务流程自动化。确保各个部门在采用不同的系统的同时可以协同完成同一个工作。
·使应用开发变得简单。中间件提供简单易用的编程接口，不需要考虑网络和操作系统的复杂性。所以使开发者将精力集中在业务逻辑的开发上，而不需要关心消息是如何传递的，中间件会来处理通信问题。
·支持应用架构的不断变更。可以方便地重新配制以增加或去除系统而不会影响其它系统。
·能够提供实时接口和批处理接口，能够提供同步和异步接口;
·必须保证数据的安全，只有目的应用可以读取;
·性能和数据吞吐量必须足够，并且具有灵活的可扩展性以适应企业的发展;
·必须具备恢复机制，当数据传输过程中发生连接中断等异常可以确保数据的恢复。
·对流程管理提供预定义的通用模版与行业模版。
2.2. 五大集成模式
业界公认的集成解决方案由五个组成部分：
·应用集成：通过HUB或总线架构，实现应用与应用之间的连接，完成相关的数据路由与数据格式转换。
·信息集成：实现数据集成，在异构的数据源之间实现数据层的直接整合。
·流程整合管理：实现业务流程管理，包括工作流管理、自动化流程两层面。
·人员整合：实现应用用户界面统一的接入与安全机制，利用门户技术进行构建。
·构建整合：通过J2EE应用服务器技术设计实现节点的应用。
目前只有IBM可以提供全部五种解决方案。
2.3. 第四代EAI技术
在系统应用集成领域，如下图所示，有四个重要的发展阶段：
第一代，手工接口。主要特征包括：涉及的应用数量较少、利用文件交换、利用批处理导入、批处理非实时性、高额维护费用、缺乏重用性、缺乏灵活性。
第二代，基于消息的端到端接口。主要特征包括：应用与接口的数量增加、异步消息、异构平台、专注传输与消息的可靠性、较快的集成周期。不足之处主要是：接口数量剧增且复杂、相应的增加维护与支持、缺乏可重用性。
第三代，星型(Hub/Spoke)架构。主要特征包括：基于消息的Hub架构实现路由与格式转换，替代端到端的设计、工作流开始产生并包含于Hub中、大数量的应用需要数据同步、实时或准实时的数据交换出现、以应用为中心的看法得到改变。不足之处主要是：对Hub、适配器、工作流的编程与管理较为昂贵，同时重用性较低。
第四代，EAI解决方案中心。主要特征包括：提供得到验证的行业业务流程模版库，而不是从空白开始建起、提供一个为未来的业务与IT流程发展的系统平台。提供共享数据模型实现机制、业务流程独立于应用、实时的客户驱动流程成为通用模式、由业务分析员设计的工作流驱动Hub与应用、遵循企业神经系统(ENS)模式(Gartner Group)、快速的设计、开发、提交与维护、较高的重用性、定制化的组件得到普遍认可。
2.4. 技术方案分期实施在技术实施中，可针对项目的实际情况，分阶段采用EAI的不同技术，通常分为两类：
·部分业务采用EAI技术，其它部分根据此部分的实施结果来确定采用的技术路线，总结展开EAI对业务的覆盖范围。此类模式通常适合在原有系统基础上进行EAI的改造。
·首先采用EAI的部分技术，特别是业务流程管理方面，而不是对EAI的全方位技术普遍采用。通常对工作流的实施可以放在后期执行。此类模式适合于新建业务系统的情况。
3. 电信共享信息/数据(SID)模型
3.1. 信息/数据共享介绍
什么是共享信息/数据?在NGOSS中使用一个简单的信息模型-共享信息和数据模型对数据进行定义和模型，即对所管理的数据的属性、操作和相互间的交互进行描述。共享信息和数据模型的目的是对信息和数据进行共享和管理。因此，该模型通过多种视角对整个NGOSS系统中不同应用系统的领域信息进行描述，包括业务视角、系统视角、实现视角和实时运行视角。业务角度是从基础的业务需求中确定合约组件，系统角度则提供了合约组件的详细内容。在NGOSS中，从业务视角和系统视角对共享信息和数据进行了描述。这些信息通过合约组件在NGOSS系统中共享和重用，当合约组件所需要的信息格式与通用的数据描述不一致时，需要将合约组件中的信息转换成共享信息和数据模型中定义的标准信息。
3.2. 从不同视角去看共享信息/数据
如图，从业务视角上看共享的数据和信息是指对业务实体的定义和相关属性的定义，它确定了业务系统对共享数据和信息的需求;而系统视角则从系统角度出发，通过对业务实体的静态和动态分析使用逻辑模型的方式对数据和信息进行了更深入的描述;而一个实现的视角则不仅将逻辑模型变成可以真正实施的物理模型，而且可以帮助我们验证所设计的共享数据和信息模型是否能够真正满足业务的需求;最后，共享的数据和信息通过运行在各个合约组件中进行共享。
在企业范围内，建立企业数据模型至关重要，属于企业技术的数据架构的核心内容之一。由于同样的数据类型有不同的数据结构，要找出具体的数据结构适合所有应用几乎是不可能。所以，不灵活的企业实体关系数据模型没有太大的使用价值。企业级的数据模型应该是可以指导开发逻辑数据模型的工具。在建立好企业数据模型后，如何将数据模型在企业的系统平台上承载起来，是一个现实问题。如下图所示，EAI平台是企业内稳定的架构部分，同时也是沟通企业各个应用系统的核心，因此将定义的企业数据模型承载到EAI平台将是一个较为理想的解决方案。一方面，避免了定义好的企业数据模型被束之高阁，有名无实，失去应用的价值;另一方面，EAI是扩充能力较强的平台，可以维持较好的数据模型的动态演进。
3.3. 通用业务对象(GBO)
通用业务对象是IBM WBI(WebSphere Business Integration)在集成电信应用系统时所定义的，是为了实现应用系统之间交互过程中的数据映射，从而满足数据共享的需求。
系统集成就是把多个应用系统整合在一起，每个应用系统通常会根据自己的需求来组织数据，这就造成相同的信息在不同的应用系统有不同的表现形式，同一个实体可能在应用系统A中采用简单的结构，而在应用系统B中使用复杂的结构，这给系统集成带来很大的困难。如果采用点到点的数据映射，系统集成的复杂性随应用系统的增多而指数级增大，而采用系统集成中间件就可以减少复杂性。系统集成中间件通过通用业务对象来实现数据在各个应用系统间的传输和共享。
通用业务对象是一组通用的、跨应用的、与领域相关的业务对象，它包含了所有应用系统相互通讯所需要的信息。各个应用系统通过数据映射把它们内部的数据信息转换成通用业务对象或反过来把通用业务对象转换成它们内部的数据格式，从而解决了不同应用系统之间的数据模型匹配问题。当应用系统变化时，只需提供新的数据映射使其能对应到通用业务对象即可，不需要对系统集成中间件进行修改。通用业务对象最大的好处是使系统集成中间件的业务处理逻辑与应用系统相对独立。
图1描述了在系统集成中使用通用业务对象的工作流程，具体描述如下：
(1)应用系统A把需要传送给应用系统B的数据信息组织成应用A业务对象。
(2)适配器A把应用A业务对象映射到通用业务对象。
(3)系统集成中间件根据事先定义的处理逻辑把通用业务对象传送给适配器B.
(4)适配器B把通用业务对象映射到应用B业务对象。
图1 在系统集成中使用通用业务对象的工作流程
适配器主要用来完成应用相关业务对象与通用业务对象之间的映射，它可以通过关系对应表自动完成映射。如图2所示，映射处理器根据关系对应表把应用业务对象转换成通用业务对象或反过来把通用业务对象转换成通用业务对象。
图2 适配器的工作模型
3.4. 共享信息/数据模型平台机制
数据模型不是包括各应用系统中的所有的数据元素，而是关于需要共享和可视的数据的模型。数据模型是以对各应用通用的并以行业标准词汇表达。例如自动化的业务流程，是通过通用业务对象(GBO)及其相关的活动表达的，应用把这些交易转换并反映到应用自身的数据库中。
WBI提供通用业务对象(GBO)的技术，该技术为建立数据模型提供了平台机制，使用户可以在此平台上构建通用业务对象，并与整个EAI平台的各模块协调融合。WBI同时提供了电信行业的通用业务对象模型，该模型是参照eTOM/TOM模型进行构建，并提供了程序代码基础的模版。
WBI提供了完整的机制来支持通用业务对象(GBO)。同时包含GUI的工具生成、维护通用业务对象(GBO)。
图3 数据架构与流程架构
如图3所示，利用WBI提供完整的技术架构模式，来完整的把业务承载平台的数据架构、业务流程架构有机的协同起来，利用其内在的机制完成整个架构的实现。
4. 接口参考模型与适配器架构
4.1. 设计理由和风险
适配器完成的功能是实现应用系统与EAI HUB之间的连接接口，主要包括数据与通讯两个层面。在适配器设计与选型方面，EAI技术提供的方案有多种形式，根据不同的情况作不同的选择。下面对常用的适配器类型进行分析。
基于数据库的接口与适配器
应用系统对外提供的接口是应用数据库，适配器通过对应用数据库的操作来实现EAI与应用间的交互。此类接口是应用系统可对外提供的最底层的接口类型，允许适配器直接访问应用的数据。针对此方式，尽管这也是常用方式之一，但其中有很多严重的不足。
使用数据作为应用的接口，意味着将数据的结构体设计暴露出来。当应用发生改变时，通常需要重新分析、甚至改变此数据接口。当应用系统的数据改变时，为了触发外部应用，通常需要使用基于应用数据库的外部触发器或使用低效的循环查询策略，这不是一个"干净"的解决方案，外部应用对维护数据的完整性也将负有责任，为此需要理解需要集成的应用系统的结构。总之，其结果将是一个难以维护的交错系统。
基于API的接口与适配器
应用软件，通常提供内置于软件库的API，作为与应用系统交互的接口。相对数据库接口而言，此类接口是一个更为"干净"的解决方案。其问题是相对某种平台，如操作系统、编程语言，此API库可能不存在，为解决此问题，需要开发底层的代码并进行长期的维护。同时当支撑其运行的产品进行升级时，通常需要对此API进行升级以保证其兼容。另外，基于API技术，当一用系统有事件发生时，一般难以提供自动通知功能，需要外部系统进行低效的循环查询。
基于组件的接口与适配器
基于J2EE与CORBA的分布式对象技术，使应用系统的接口有较好的可移植性。此类接口，可以屏蔽操作系统、编程语言的不同。此类接口属于紧耦合模式，属于发展中的技术，由于应用系统本身需要提供组件接口，在实际应用中限制了其应用。
基于消息队列的接口与适配器
应用系统对外交互的接口为消息队列，同时提供消息/数据传输的可靠性保障。业界领先的消息中间件同时提供同步、异步两种通讯方式。使用消息队列，消息系统可以管理很多通讯细节。此种接口方式为典型松耦合模式，是EAI技术普遍使用的方式之一，可以实现接口的重用能力。
4.2. 主流的的实现方式
分析各电信运营商EAI平台的建设情况，需要接入的业务应用系统，如：综合客服系统、资源管理系统、计费帐务系统，采用各自的应用服务器或交易中间件，具有不同的架构模式，对外提供不同的接口方式。在这种状况下，不利于整体系统的统一维护、后期升级改造，以及今后其他业务系统的接入。在此综合考虑以下几方面关键因素，EAI业界推荐采用基于消息队列的适配器，如下图所示。
说明：图中蓝色区域为重用体系，对应用连接提供统一接口。
采用基于消息的适配器比较其它方式有较为明显的优势，特别是对整体架构的规划与实施有较大的参考作用，随着系统承载平台的逐步完善，此架构会有更为显著的生命力与综合优势。下面简单对此进行陈述如下：
·提供统一的接口模式，最大程度地满足IT规划的总体要求，保障最大的ROI，在新系统构建之出至关重要。
·提供基于松耦合的接口方式，提高整个系统承载平台的可重用性，将系统的重用范围从流程扩展到接口层面。
·提高整体系统的可维护性，统一接口技术，并逐渐标准化，避免采用多种不同技术规范。一方面使承载平台维护人员专注在业界领先的标准技术上;另一方面便于系统的统一升级换代。
·基于消息队列的技术是一种成熟、稳定、开放的技术，开发维护简单、便利的技术手段，利于在实际项目中进行实施，降低项目的风险。
4.3. 对实现技术的要求
为实现此类统一架构，对消息中间件(队列)提出如下基本要求：
·支持多种操作系统。
·提供包括C、C++、Java、ActiveX等多种语言的API接口，从而实现与不同编程语言的应用系统连接。
·稳定可靠，保证数据传输一次而且只有一次。
·高性能。
5. 电信业务流程模版
提供行业流程模版或通用模版是第四代EAI解决方案的特征。通过参照模版，一方面可以缩短开放周期、提高代码质量，另一方面可以规范业务流程，实现流程优化。
IBM WBI提供遵循TMF规范的业务流程模版及通用模版。对业务流程模版的提供方式，一方面是提供文档，更重要的是提供基于IBM EAI的代码实现。
在IBM EAI解决方案中，针对电信行业提供了基于TMF规范的业务流程模版，在此仅列表说明：
用例(业务范围)：
1. Customer Order Handling
2. Customer Service Configuration and Activation
3. Resource Provisioning and Allocation
4. Customer Billing Management
5. Customer Problem Handling
6. Product Development and Retirement
针对以上6个用例，提供基于产品的流程模版。对每一用例提供一类工作流模版，每一工作流模版又与对应的自动化协调流程相配合。
6. 流程的交易补偿的实现
当一组流程需要与不同的应用系统发生交易时，如果其中之一出现失败，则需要进行交易在流程层面的回滚。在EAI领域，此类技术称之为流程的交易补偿，是保证交易与数据一致性的重要手段。IBM EAI提供流程的交易补偿机制，只需要定义相关的补偿节点。
7. EAI的高端解决方案--业务行为监控(BAM)
BAM(Business Activity Monitoring)是EAI技术当前发展最为快速、业务高级优化最有效的手段，其宗旨在于实时获得业务流程运行的状态，自动提供客观分析报告，以优化、改进业务流程，其改进包括技术层面，也包括人员、管理层面。从技术层面分析，包括流程建模的仿真，业务运行中各节点的分析反馈，业务报表生成。
提供能力：IBM可提供统一技术的适合不同操作系统、不同编程语言的适配器。
BEA：从应用层面，只能提供Java的实现技术，对C无此能力(通过Gateway转换)。
1. 解决EAI性能瓶颈
重要性：性能是困扰EAI在电信实施的重要问题。
提供能力：IBM WBI的性能是BEA技术的10-100倍，可提供专业测试报告
IBM EAI产品包提供了一整套的产品用来定义、分析和监控您的业务流程。在EAI的建设、试运行、生产环境不同的阶段，针对业务流程都需要提供实时的分析，报告和模拟仿真功能。
8. 解决EAI性能瓶颈
采用EAI中间件技术，关键业务流程都通过EAI HUB来实现，因此系统的性能对于电信行业是一个关键因素。其中工作负载集中体现消息中间件与EAI在路由、格式转换方面(Message Broker)。另外EAI系统对内存的分配管理技术、对高峰值的内存数据报的处理理论与技术、对高峰值的可靠传输的保障理论与技术多至关重要。这些将在实际项目的实施中至关重要，也是一些不成熟的EAI厂家在细节层面有意忽略(或根本没有意识)之处。
IBM EAI技术在业界的性能处理能力一直处于领先地位，这也是基于多年的产品发展日益成熟起来的。
9. 电信行业EAI项目管理实施经验
EAI技术被定位为企业的神经系统，是企业IT的架构基础。因此在业界的共识是，EAI的采用一方面是衡量某类产品的成熟度、可用性;更重要的是用户在选择一个长期的合作伙伴。同时我们必须面对的是EAI这种复杂技术的实施的风险。从全球角度来讲，只有50%的成功率，重要原因在于技术的复杂度与实施能力。
从国内EAI项目的实施状况来看，考虑到技术的复杂度与实施经验，目前主要采用与原厂商合作或全球知名的IT咨询服务商合作来进行。
10. 总结
以上论及内容是EAI技术的基础与主流，并未涉及产品层面的细枝末节，对于电信运营商通盘考虑EAI的选型应有一定的借鉴作用。 
