针对国内的实际情况，考验厂家们的产品能力重点经常不在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。