我们知道，大多数企业都有由过去遗留下来的异构的系统、应用、商务流程以及数据源构成的应用环境。应用环境的通信状况是混乱的，只有很少的接口文档，并且维护代价也非常的昂贵。而数字时代市场的合并又提出了一些附加的问题，即公司的联合和兼并能够指数级的增加系统综合的复杂性。
当企业向B2B电子商务协作方向迁移时，他们首先要做的是审阅他们内部的系统、应用以及商务流程。一些商务流程会横跨多个内部应用，在企业能够有效的和外部网络连接之前，这些应用必须能够实时动态的进行通讯。
随着诸如企业资源规划(ERP)、客户关系治理(CRM)、供给链治理(SCM)以及企业门户(EnterPRise Portal)等多种商业应用的引入，激增了企业信息系统的应用分割。早期这些系统被设计成自包含的“黒盒”系统，只有很少或者更本没有方法来访问它内部的数据和商务流程。虽然现在许多这些应用都提供了更好的访问他们的内部数据和商业逻辑的方法，可是把这些系统和企业里其他系统集成仍是一个巨大的挑战。
图1的每一个节点都包含它自己的数据，而这些数据可能会在节点之间共享。共享这些数据代表性的方法是通过数据传输方法，包括一批数据处理以及数据输入输出服务来完成。 之所以采用这种方法是因为一个节点的数据对其他节点来说不是实时存在的，而后者也不能在处理时分析和做决定。进入讨论组讨论。
什么是企业应用集成?
不断增长的客户和商业伙伴对实时信息的期望的持续增加，为了满足这种期望的需要，企业被迫连接他们的那些异构的系统来增加产出、提高效率以及，最终的，使顾客满足。为使一个组织内部IT系统互相通信，导致了企业应用集成(EAI)的发展。EAI通过建立底层结构，来联系横贯整个企业的异构系统、应用、数据源等。EAI解决方案的起源可以追溯到那些提供双向的解决方案以完成在企业内部的ERP、CRM、SCM、数据库、数据仓库以及其他重要的内部系统之间无缝地共享和交换数据的需要。
EAI不是一个能彻底解决最终问题的方案，他更可以说是正在建立一个灵活的、标准化的企业应用底层架构，可以答应新的基于IT的应用和商业处理能够更轻易和更有效的被部署。新的底层架构答应企业中的应用能够实时的，无缝的互相通信。
EAI的类型
EAI解决方案可以呈现许多种形式并以多种级别出现。EAI合适的级别依靠于许多因素，包括公司的大小、公司的行业类别、公司应用的集成度或是项目的复杂度以及预算等等。
这里列出了EAI的中间件解决方案的4个类型：
● 用户界面集成
● 数据集成
● 商务流程集成
● 函数或方法集成
当我们看到这些解决方案的类型，要注重的是我们在讨论解决方案的样式而不是具体实现。
用户界面集成(界面重组)
界面重组是一个面向用户的整合，他将原先系统的终端窗口和PC的图形界面使用一个标准的界面(有代表性的例子是使用浏览器)来替换。一般的，应用程序终端窗口的功能可以一对一地映射到一个基于浏览器的图形用户界面。新的表示层需要与现存的遗留系统的商业逻辑或者一些封装的应用如ERP、CRM以及SCM等进行集成。
企业门户应用(Enterprise Portal)也可以被看成是一个复杂的界面重组的解决方案。一个企业门户合并了多个企业应用，同时表现为一个可定制的基于浏览器的界面。在这个类型的EAI中，企业门户框架和中间件解决方案是一样的。进入讨论组讨论。
数据集成
数据集成发生在企业内的数据库和数据源级别。通过从一个数据源将数据移植到另外一个数据源来完成数据集成。数据集成是现有EAI解决方案中最普遍的一个形式。然而，数据集成的一个最大的问题是商业逻辑经常只存在于主系统中，无法在数据库层次去响应商业流程的处理，因此这限制了实时处理的能力。
此外还有一些数据复制和中间件工具来推动在数据源之间的数据传输，一些是以实时方式工作的，一些是以批处理方式工作的。
下面列出了一些数据集成的方法：
1.批传输
2.数据合并
3.数据复制
4.析取、转换、装载解决方案(ETL Solution)
ETL解决方案(如上图所示)，是基于ETL引擎的，从不同的应用程序析取、转换、过滤和装载数据到数据仓库和(或)数据市集。现在ETL已经是企业实现数据集成的一个非常有效的途径。
商务流程集成
虽然数据集成已经证实是EAI的一个流行的形式，然而，从安全性、数据完整性、商务流程角度来看，数据集成仍然存在着很多问题。组织内大量的数据是被商业逻辑所访问和维持的。商业逻辑应用并加强了必须的商业规则、商务流程和安全性，而这些对于下层数据都是必需的。
商务流程集成产生于跨越了多个应用的商务流程层。通常通过使用一些高层的中间件来表现商务流程集成的特征。这类中间件产品的代表是消息中介，消息中介使用一个总线模式或者是HUB模式来对消息处理标准化并控制信息流。下面的图示在一个较高的层次说明了一个开放的商务流程的组成：
函数或方法集成
函数和方法集成包括直接的和严格的，在网络环境中的跨平台应用程序之间的应用到应用(A2A)的集成。它涵盖了普通的代码(COBOL,C++,java)撰写、应用程序接口(APIs)、远端过程调用(RPCs)、分布式中间件如TP监控、分布式对象、公共对象访问中介(CORBA)、Java远端方法调用(RMI)、面向消息的中间件以及Web服务等等各种软件技术。
面向函数和方法的集成一般来说是处于同步模式的，即基于客户(请求程序)和服务器(响应程序)之间的请求响应交互机制。
Web服务
Web服务提供了一个分布式的计算技术，用于在Internet 或者intranet上通过使用标准的xml协议和信息格式来展现商业应用服务。使用标准的XML协议使得Web服务平台、语言和发布者能够互相独立，这是EAI解决方案的一个理想的候选者。
通过开放的Internet标准：Web服务描述语言(WSDL，用于服务描述)，统一描述、发现和集成规范(UDDI，用于服务的发布和集成)，简单对象访问协议(SOAP，用于服务调用)和Web服务流语言(WSFL，用来定义工作流，这尚不是一个W3C标准)，Web服务消除了现存解决方案(如CORBA和DCOM)中的互用性问题。
EAI和Web服务
Web服务不是EAI或者是EAI的一部分，更甚者，Web服务是另外一个技术，Web服务能够使EAI成为真正可能的、便捷实施的，同时又引人注目的解决方案。Web服务能彻底地改变传统的EAI中点对点的集成处理方式。
使用Web服务，通过松散的应用集成，一个企业可以仅仅实现EAI的一个子集，即能取得实效。与之相反，EAI要实现一个全盘的方案，来紧密的集成和联系支持公司业务的所有的系统和应用。在公司内部不同的业务系统和技术单体中可能需要花费数年的持续的努力，高投资以及为之配备的充实的资源。
Web服务，以这样一种松散的服务捆绑集合形式(也可以说是一个非凡得解决方案)，能够快速、低代价地开发、发布、发现和动态绑定应用。就当代Web服务的技术发展水平来看，Web服务可以实现应用程序之间的函数或方法级的集成。他们不是自然的基于事务的，同时仅提供了基本的“请求/响应”功能。然而，在下一代的Web服务中，在功能上和技术上都会更先进，将会提供用户接口封装和安全性，他们将能够包装一个应用程序并且把他嵌入到其他的应用程序中去。
现有的主要关注于应用集成的EAI解决方案将不得不因此而改变。在将来，包装好的应用程序将使用如XML、SOAP、WSDL和UDDI技术来把他们的函数或方法作为Web服务的界面来显示。因此，EAI解决方案将不得不提供一个对服务集成的广泛的支持，而不仅仅是应用集成。进入讨论组讨论。
传统EAI解决方案和Web服务之间的显著的不同
下面是传统的EAI解决方案和Web服务之间的一些基本的不同点：
(注重：有一些不同点所描述的Web服务的特点可能并非是Web服务目前有的特性，而是考虑了Web服务被提议的未来的改进)
简单性：毫无疑问，相比于典型的EAI解决方案(也许包括分布式技术如DCOM和CORBA)，Web服务更便于设计、开发、维护和使用。既然开发和使用Web服务的平台框架已经预备好了，创建跨越多个应用程序的商务流程处理将变得相对简单。
开放标准：不像有所有权的EAI解决方案，Web服务是基于开放标准诸如UDDI、SOAP、HTTP的。这个可能是导致Web服务被广泛接受的最重要的因素。事实上基于现存的开放标准消除了企业潜在地为了支持新出现的Web技术的投资的需要。
灵活性：既然EAI解决方案需要点对点集成，一端的改变必须告知另外一端，这自然使集成变得非常的生硬，同时也是浪费开发人员的时间的。基于Web服务的集成是非常灵活的，因为他是建立在发布服务的应用程序和使用服务的应用程序之间的松散耦合。
便宜：EAI解决方案，诸如消息中介，其实施是非常昂贵的。而Web服务的实施则会变得便宜而快速。
范围：EAI解决方案，诸如消息中介，把应用程序作为一个单个的实体来集成。然而Web服务答应企业把大的应用划分为小的独立的逻辑实体并且包装他们。举例来说，企业可以为一个ERP应用的不同的商业组件进行包装。如订单治理、接受购买订单、订单情况、订单确认、帐户接受、帐户支付等等。
高效性：已在前面几点提到的，Web服务答应应用程序划分为一些小的逻辑组件，因为在小粒度基础上集成应用程序，集成将变得更轻易。这也使Web服务的EAI解决方案比传统的EAI解决方案更有效率。
动态：Web服务通过提供动态的服务接口来实施一个动态的集成。然而传统的EAI解决方案都是静态处理的。
用Web服务的EAI示例
下面的[图表]显示了在一个在企业内使用Web服务的例子。在这个例子中，在应用服务器中运行的企业门户从多个内部应用集成信息，并提供一个跨越这些应用的业务处理的入口点。企业门户应用通过内部应用程序使用私有UDDI注册中心(Private UDDI Registry)来获得可提供的Web服务的技术信息，并且在企业内部Intranet上调用这些服务。一些经常被调用的Web服务的绑定信息将被企业门户应用缓存，这样得以避免花费在动态绑定上的资源和时间。在这个例子里面，Web服务把企业门户和CRM、ERP应用程序松散的集成在一起。
流程步骤如下：
1.在登录企业门户之后，用户发出请求信息；
2.支持企业门户框架的应用程序通过浏览私有UDDI注册中心获得关于CRM和ERP应用的Web服务的技术；
3.Web服务的位置和WSDL绑定信息被穿送给应用服务器；
4.应用程序调用CRM应用发布的Web服务得到个人的信息，如名字、身份证号码、地址以及用户的Email。这个通讯过程是基于SOAP交互的；
5.应用程序调用ERP应用发布的Web服务获得银行帐号信息，诸如银行帐号号码，结余和用户交易历史记录。这个通讯过程也是基于SOAP交互的；
6.信息被格式化后，被发给起初的调用用户。
从哪里开始
企业在内部应用程序中使用Web服务来实施应用集成的项目，应当从函数、应用程序接口(API)，或者远端过程调用(RPC)级别开始这一进程。这个将使企业内使用和实施Web服务的IT技术人员熟悉Web服务技术，当企业将来使用Web服务进行外部集成(B2B集成)项目时，将会有助于项目的有效进行。在Intranet内控制、治理、寻找、执行和维护Web服务相对来说也比通过企业防火墙在Internet上使用Web服务更为轻易。进一步来说，它将帮助企业来比较和鉴别，使用标准化和相对便宜的Web服务解决方案相对于昂贵的传统的EAI解决方案到底是不是对提高企业的产出率更有帮助。
然而，要求企业抛弃现存的EAI底层架构并且盲目的转向开发基于Web服务的解决方案来替代它是不太现实的。企业不会停止使用提供完整事务服务的EAI中间件框架。在使用Web服务的场所，不是替代(现在还不是)，而是应该使用Web服务来支撑现存的下层结构。
经过一段时间，Web服务将逐渐的由一个EAI解决方案进化为一个B2Bi(B2B Intergration)解决方案。
结论
通过一个被Web标准支持的方法而不是一个有私有知识产权的系统，Web服务提供一个中立的平台来集成应用程序，从而被用于集成不同的应用系统。依靠Web服务，企业能够实时地访问不同部门、不同应用、不同平台和不同系统的信息，这已是Web服务被接受的最重要和最有力的因素之一。在企业”冒险”在B2B中使用Web服务实施应用集成之前，企业应当首先在他们内部的非面向事务的一般商业流程集成中使用Web服务。进入讨论组讨论。
