Figure 5. 函数/方法的集成
面向函数和方法的集成一般来说是处于同步模式的，即基于客户(请求程序)和服务器(响应程序)之间的请求响应交互机制。
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示例
下面的Figure 6显示了在一个在企业内使用Web服务的例子。在这个例子中，在应用服务器中运行的企业门户从多个内部应用集成信息，并提供一个跨越这些应用的业务处理的入口点。企业门户应用通过内部应用程序使用私有UDDI注册中心(Private UDDI Registry)来获得可提供的Web服务的技术信息，并且在企业内部Intranet上调用这些服务。一些经常被调用的Web服务的绑定信息将被企业门户应用缓存，这样得以避免花费在动态绑定上的资源和时间。在这个例子里面，Web服务把企业门户和CRM、ERP应用程序松散的集成在一起。
