“云应用集成”通常可以和“基于云的数据集成”交换使用。

　　即使是本地（on-premises）软件，“数据集成”和“应用集成”通常也认为是同义，很多术语的交换使用没有理解二者间的显著区别，虽然这两个软件类别已经存在多年。

　　混淆很猖狂，在很多案例中，软件厂商加剧了这种混淆，等式的两端都尝试拓宽其产品的吸引力。

　　这是两种完全不同的集成类型，有独立的方法、方法论和工具。每一个有其自己的作用，一个用于管理事务，一个用于管理事务运行时的数据。了解哪一种方法适用于企业自身非常关键。

　　DI和EAI：两个不同的物种

　　十年多的时间里，“应用集成”（有时称为EAI）和“数据集成”（或者DI）有着明显不同的原则。尽管一些分析师团队预测两个产品分类会合并，现在发生还为时过早。这两个产品分类的基本架构之间的分割可以说是光年。

　　在本地数据中心，企业早早就决定使用像TIBCO或者webMethods这样的产品，而不是像Informatica这样的产品。webMethods直接同Informatica就具体业务竞争极其少见。通常企业尝试使用一个不合适的产品的案例中才会发生。

　　应用集成

　　根本上，应用集成在功能层将多种应用连接在一起。在事务或者服务调用层处理事情。应用集成知道聚集早一起的信息（像新客户的创建）的不同部分，从而创建出一个原子单元，这个原子单元在没有引入数据不一致（例如“损坏”）到系统中的情况下无法细分。

　　使用应用集成，像创建新客户这样的事务构成一个单元，尽管最终能分解成多种不同的部分。例如，在一个应用中创建客户，可能包含至少三个信息“二进制数字”——公司信息和多级地址。在目标应用程序中，那个信息很可能存储在不同的位置中（“公司”表格、“地址”表格和“收款人”表格）。没有收款人信息，拷贝地址信息没有意义。这就是数据损坏的一种形式。
　　此外，应用集成系统本身是典型的基于事件的，也就是说，一旦起源应用中“有什么发生了”，像创建新客户，这个事务就会发送到目标应用。目的就是做到“实时”，因此多种系统总是同步。

　　很多应用集成解决方案起源于消息队列或者“企业服务总线”产品，例如，IBM的MQ系列，他们面向实时性能、事务性、可靠性、可恢复性和一次且仅一次保证交付。

　　这种类型的集成软件的典型用例就是一旦客户记录放置好，生成发票并更新财务数据库。时间就是金钱。

　　数据集成

　　数据集成，顾名思义，处理数据的同步化，标准化、转换、映射、质量和传输，很可能是不同系统之间的大量数据。数据集成并不知道事务的概念。大多数案例中，这些产品在ETL（提取、转换和加载）软件中有自己的概念源，不是他们实际的源。他们代表一种ETL技术的演变。

　　使用数据集成，物理数据表示是抽象的，就像数据访问和传输。这样创建不同数据源（如系统中的一个客户记录如何“映射”到另一个系统的客户记录）之间的“映射”很容易，同时也引入了像转换和确认这样的事情。

　　哪一种更好？

　　数据集成不必应用集成优越，也不比应用集成差劲。只是简单的不同。七座SUV不会比两座跑车好，也不会差。只是分情况，有时候叫做跑车，有时候叫做七座SUV。

　　当事务跨越多个系统或者应用，应用集成就是修行之路。“分析”通常是数据集成；“操作”通常是应用集成。

　　云集成之乱

　　基于云的集成，例如，集成堆栈是基于云的，数据集成和应用集成之间的混淆更普遍，这当然是相对于本地软件而言。

　　在云端，应用集成和基于云的数据集成容易混淆主要有两个原因：

　　（1）两个术语到处使用，所以为什么云上不也这样呢？

　　（2）基于云的应用集成到目前为止并不存在。

　　云集成产品新分类

　　云集成解决方案新分类出现了：基于云的应用集成。这个种类由众所周知的开源企业服务总线MuleSoft牵头。其iON产品是第一个为应用集成而生的基于云的集成平台，而不是数据集成。软件的这个分类进化进一步证明了SaaS/云软件市场的成长和成熟。像MuleSoft的iON这样的产品正在促成集成的新类型，而且其利益是SaaS/云用户和厂商所喜爱的。