EAI从接口走向服务

EAI在近两年成为企业信息化建设的热点。应该说EAI建设是企业对他的信息系统建设的一个总结。从EAI建设的驱动力来说，EAI是为了解决企业内的"蜘蛛网"、"信息孤岛"等问题而产生的。企业通过建设EAI系统，有效地降低了接口数量，并且在各个信息系统之间架起了沟通的桥梁。EAI为许多企业疏通了脉络，提高了信息系统的整合能力。

随着技术的发展，EAI的核心理念在近年来又有新的突破。随着WebService的兴起，EAI面向服务的特征越来越明显。可以说，下一个阶段的EAI系统，是建立在"面向服务"的理念上的整合体系，比现在大部分企业的"面向接口"的整合体系又向前迈进了一大步。

首先让我们来看一下目前企业在实施EAI系统时候采用的一些技术手段。

一、传统的EAI思路和发展过程

企业建立各种信息系统是为了能够提高业务处理的效率、增强企业的竞争能力。由于各种原因，很多企业都存在着一个个信息孤岛：信息系统往往为不同的部门而设计开发，不同的应用之间不能共享业务处理流程和信息、不能有效的协同工作，这大大降低了信息系统的作用。随着竞争的日益加剧，企业迫切需要消除信息孤岛，使各个应用间既相互独立又能有效协同工作，将不同的应用集成一个完整的企业级信息化环境中，并能够实现与其他企业间的集成。这就是所谓的EAI，企业应用集成。

企业应用集成就是通过相应的软件技术将企业已有的和新建的各种业务系统集成起来，共同完成企业的各种商务活动，并能够灵活快速地适应企业的发展和市场的变化.

从企业应用集成的架构来看，比较有代表性的有两种：总线型的集成架构和星型的集成架构。

总线型的集成架构的原理是：各个应用系统的接口都面向于信息总线。信息在总线中流动、传递。他的优点是应用系统只需要编写面向总线的接口，从而避免n*n个接口的编写。tibco等公司的集成产品是这种架构的代表之作。架构图如下：

星型结构的提法比较笼统，它的原理是信息和应用都集中向一个核心处理器。这个核心处理器或许是一个应用服务器，或者是一个数据仓库。比如ibm的集成方案，就是以mq为集成核心的。而webmothods则是以一个数据仓库为集成核心的。这种架构的优势在于。架构图如下：

总之，传统的集成方案有一个重要的特征，他们都是面向各个信息系统的接口的。他们对各个应用系统的接口进行基于某些特定标准的处理，从而到达系统整合的目的。通过实施企业应用集成，可以有效地解决信息系统的接口的问题。

二、从接口型EAI走向服务型EAI

接口型的EAI系统有不可克服的难点：一是没有真正实现统一的身份认证、状态认证、安全控制等的基础服务。二是制造了一个庞大而昂贵的核心系统。三是接口型的EAI系统在处理"长事务（Long Transcation）"的时候有很大的困难。

企业的信息技术部门，从本质上讲，是一个提供信息服务的部门。企业内的各种信息系统，为企业的内外用户提供了全方位的信息服务。而系统与系统之间，从以往的眼光来看，是通过接口来实现联系的。这种思路正在逐步的改观，应用系统与应用系统之间，也应该走向一种互为服务的关系。正是在这种跨应用系统的、面向服务的理念的驱动下，WebService在这两年得到了比较快的发展。

Web Service 是一系列标准的集合。它提供了一个分布式的计算模型，用于在Internet 或者intranet上通过使用标准的XML协议和信息格式来展现商业应用服务。用WebService来实现EAI，需要涉及到对被集成的各个应用系统本身进行改造，使之符合面向服务的体系。具体的结构图如下：

用Web Service实现EAI的关键部件有：

1.UDDI：统一描述、发现和集成（Universal Description, Discovery, and Integration，UDDI）。UDDI服务可帮助企业针对Web服务及其它可编程资源进行组织并编制目录。通过对UUDI服务中的物理分布、组织机构、服务方式等一系列分类方案加以应用，企业可以建立起一种用来描述并发现相关服务的结构化与标准化方式。

2.支持Web Service的应用服务器：J2EE v1.4 开始就全面的支持Web Service 了。而.NET从一开始就是支持Web Service的。除此之外，也有一些其它的平台是支持Web Service的。

3.应用系统的Web Service：毫无疑问，这一个步骤是实施的关键和难点。要想让企业原有的系统转而支持Web Service，需要对企业原有的系统进行改造。这个工作是艰难而充满风险的。

4.界面层次的整合。由于Web Service规范的标准性和简单性，企业门户系统（Portal）可以非常方便的实现信息系统界面层次的整合。

让我们来看一个整合实例：

在实际商务活动中，经常会涉及到分析客户的欠款情况。如果没有EAI系统，我们会到CRM系统中查找客户的联系信息，然后到ERP系统中查找客户的供应信息。这是两个完全独立的过程。在建立了"接口型"的EAI系统之后，我们可以通过一个界面得到比较全面的信息。但是这还是不够的。如果建设了"服务型"的EAI系统之后，这个请求会经过CRM和ERP系统的协同分析之后，将一个更有价值的、更加全面的模型返回给用户。如下图：

我们可以看到，整合后的业务流程为：

1.在登录企业门户之后，用户发出请求信息；

2.支持企业门户框架的应用程序通过浏览私有的UDDI注册中心获得关于CRM和ERP应用的Web服务的目录；

3.Web服务的位置和WSDL绑定信息被传送给应用服务器；

4.应用程序调用CRM系统发布的Web服务得到客户的信息，如名字、通信地址、电话以及客户的Email。这个通讯过程是基于SOAP交互的；

5.应用程序调用ERP系统发布的Web服务获得客户的供应信息，诸如应收款项，当月订单和客户交易历史记录。这个通讯过程也是基于SOAP交互的；

6.信息被应用服务器格式化。请注意，这个过程可能是一个交互的过程。

7.经过深度分析后的信息模型被发给最初的调用用户。

显然，面向服务的EAI对企业的各个信息系统提出了更高的要求，而这也将会是真正实施起来所要面对的最大难题。在一个企业内，总会有一些系统是很难升级到支持WebService的。在这种情况下，我们或许不得不首先用传统的接口型的整合产品对它们进行初步的封装，然后在一个标准的接口的基础上，再来实现服务的抽取。

总之，面向服务是信息系统的一项重要的特征。而这种面向服务，不仅指的是面向企业的内外用户的服务，而且，在面对企业内外的其他信息系统时，他也应该体现出一种服务提供者的姿态。而面向服务的EAI，也必然会在今后的几年内走向成熟，并占据重要的市场份额。