企业应用集成（Enterprise Application Integration）的商机

关键词：EAI，中间件,EIS ,企业集成骨干网,J2EE ,WEB SERVICE,SOAP

相关名词解释：

EAI——EAI是利用通用的中间件，合并多种应用的新企业方案。

中间件——是独立于应用程序之外的软件，它提供服务用来协调不同的应用软件。

烟囱式应用——烟囱式应用能实现具体的企业目的，例如接受订单，或服务于某个部门，例如会计部门。在企业系统示意图里，这些应用是独立、垂直的，很像“烟囱”。由于它们不会与其它应用相互操作，所以烟囱式系统对于集成来说是一个重大挑战。

XML——即Extensible Markup Language，可扩展置标语言。应用于B2B或企业内部的应用程序间，是正在形成的信息通信标准。XML规定了应用程序之间的信息流的内容，极大地减少了在规定和维护通信应用程序方面的投入。

 

 

一．历史:企业应用集成

EAI (Enterprise Application Integration，企业应用集成) 是一种全新的战略企业解决方案，它利用通用的中间件（middle ware）融合了企业已有的应用软件、商业封装式应用软件以及新代码三方面的功能。 一般意义上的EAI通过建立底层结构，来联系横贯整个企业的异构系统、应用、数据源等，完成在企业内部的ERP、CRM、SCM、数据库、数据仓库，以及其他重要的内部系统之间无缝地共享和交换数据的需要。
　　有了EAI，企业就可以将企业核心应用和新的Internet解决方案结合在一起。然而，要构建一个有效的电子商务解决方案，必须使这些系统能够协调地工作。例如当用户通过Internet订购一个产品时,该产品需要被包装发运，用户需要付款，产品库存信息需要进行修改更新，原材料或新的备件需要被及时订购，这一系列的工作流都靠系统自动地推动。因此，电子商务并不是奇特的、抢眼的Web站点的问题，而是新的基于Web的系统和现有的在企业中运行的后台应用系统之间的集成问题。所以说，EAI的概念应当从基本的连接器扩展到工作流配置的层次。

EAI技术的发展经历了从不成熟到逐渐成熟的坎坷历程，回顾EAI技术的发展过程， EAI技术的演变经历了十多年的时间，产生了几代从不成熟到逐渐成熟的EAI技术，为企业带来不断增长的商业价值。下面对EAI技术的演变过程进行简要说明：　　

*20世纪60年代到70年代期间，企业应用大多是用来替代重复性劳动的一些简单设计。当时并没有考虑到企业数据的集成，惟一的目标就是用计算机代替一些孤立的、体力性质的工作环节。　　

*20世纪80年代，企业规模开始扩大，企业业务和数据日趋复杂，一些公司开始意识到应用集成的价值和必要性，很多公司的技术人员试图在企业系统整体概念的指导下对已经存在的应用进行重新设计，以便将它们集成在一起。此时， 点到点(Point-to-Point)的集成技术开始出现，在各个应用系统之间通过各自不同的接口进行点到点的简单连接，实现信息和数据的共享。点到点的应用集成也被称为第0代EAI技术。　　

*20世纪80年代末和90年代初，随着企业规模的进一步扩大，应用系统不断增加，简单的点到点连接已经很难满足不断增长的应用集成要求，企业迫切需要新的集成方法：可以少写代码，无须巨额花费，就可以将各种旧的应用系统和新的系统集成起来。第1代EAI技术的出现在一定程度上解决了这些问题，它采用CORBA/DCOM、MOM(消息中间件)等技术，实现了对企业信息的集成，促进了企业的进一步发展。　

*20世纪90年代中后期，企业业务的迅速发展以及与电子商务的结合对应用集成解决方案提出了更高的要求，局限于信息集成的第1代EAI集成技术很难实现企业业务流程的自动处理、管理和监控，基于业务流程管理/集成(BPM/BPI)的第2代EAI集成技术成为更加合适的集成选择方案。第2代EAI集成技术通过实现对企业业务流程的全面分析管理，可以满足企业与客户、合作伙伴之间的业务需求，实现端到端的业务流程，顺畅企业内外的数据流、信息流和业务流。第2代EAI集成技术是当前集成技术发展的主流。　　

    目前，EAI技术正向第3代集成技术演变：即根据不同行业集成技术的特点，推出基于行业的预建构集成包，预先解决行业共性的问题，从而缩短EAI项目开发周期。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

二．EAI的业务驱动力是什么

 

据IDC统计，在过去的10年中，全球企业在信息系统上一共投资18万亿美元。巨大的投资为企业建立了众多如下图所示的信息系统，以帮助企业进行内外部业务的处理和管理工作。

 

                    

 

 

 

 

 

 

 

企业的各个系统之间没有联系，整个企业的每个部分都陷入了“应用系统孤岛”：

根据META Group的统计，一家典型的大型企业平均拥有49个应用系统，33％的IT预算是花在传统的集成上，通过零星的“点对点”连接，是众多的“信息孤岛”联系起来，以便让不同的系统之间交换信息。如下图所示：

但这种点对点的连接非常的精密，触一发而动全身，这种系统模式的弊端很快就显示了出来。如何灵活的将各个系统整合起来，作为一个信息的有效化是企业最为关心的问题。

根据摩根斯坦利公司对大企业CIO的调查，在这些主管企业信息化人士所关心的问题中，如何将众多的企业应用系统集成起来，是他们最为关注的热点。如下图所示：

可以看到有36%以上的企业最关心的是如何将这些信息孤岛集成起来。而且这份调查是2002年的。随着信息化的进一步加深。这种需求只会增加，不会减少。

企业中各个部分孤立的信息系统无法有效地提供跨部门、跨系统的综合性的信息，诸如：某个主要的订单的状况怎样？谁是我的最重要的客户？这个季度的任务能否完成？等等。 孤立的信息系统也无法实现实时的信息存取和对业务流程的透视，无法实现对客户、供应商、项目、订单、资产等的全面掌控，无法实现企业价值链的全面的、彻底的透视和控制。
    于是，企业对应用整合的需求应运而生。具体来说，主要的内、外在的驱动力如下：
1> Web-based & Packaged应用系统的流行，如SAP，Intranet
2> 追求效率和控制成本
3> 兼并和收购
4> 技术的不断创新
5> XML技术的兴起

    目前，大公司已逐渐接受“企业集成骨干网”的概念。所谓“企业集成骨干网”实际上是建立一个集成的可扩展的应用软件总线结构，所有的应用可以“即插即用”。“企业集成骨干网”的模型如下图所示：

 

     

 

 

 

 

 

 

 

目前，企业对“企业集成骨干网”的需求急剧增加，企业应用集成（EAI）已经成为实现企业主要战略目标的必需手段和捷径。

如下所示为 EAI 的主要业务优势：

·          凭借能带来更高效率的EAI工具集，降低IT成本。以前，大多数组织通过编写大量代码来解决 EAI 的问题。使用更好的工具可以降低初始投资和节省时间，且减少了以后的维护成本。

·          通过将人工过程自动化来降低管理成本。对每个企业中存在的大量人工过程进行自动化可以省去大量人员开支。

·          通过更高效的价值链过程降低运营成本。对可以减少业务处理周期时间的关键价值链过程进行自动化可以降低很多方面的成本。例如，更高效的供应链可以降低货运成本。

·          通过推出新服务和节目来获得更高的客户满意度和忠诚度。EAI 项目本质上是为了比竞争者更快速地提供新信息和业务服务。例如，如果使用 EAI 工具连接适当的系统后，则可更方便地进行关键在线客户的“自助”操作。

·          更佳和更快的业务决策。汇总业务信息并且使其近乎实时可用，可以从根本上使您比竞争者更快地进行更佳的业务决策。

 

三．EAI的特性

中间件能够提供独立于应用程序的服务，用来协同各种应用程序工作，可以把它理解为实现这些服务的软件产品。在EAI中间件出现以前，企业总试图用专门的方法来实现应用程序的集成，但是，由于问题越来越复杂、规模越来越大，这些方法很快就被淘汰。基于中间件的EAI从以下几个方面降低了应用软件集成的复杂程度：

A)             封装应用程序功能的机制。因此应用软件的功能可以作为服务提供给其他应用程序。例如，账户应用程序既能进行开户服务，也能提供转账服务。

B)             应用程序共享信息的机制。例如，一个企业里的许多应用程序需要共享客户信息，而独立开发的应用程序很少以相同的方式组织、安排这些共享信息，EAI中间件能够在应用程序交换信息的过程中翻译和转化数据。

C)             应用程序协调企业流程的机制。例如，EAI中间件能够管理预定的企业工作流，也可以在业务流程环境中通过良好定义的方法由某一应用程序向其他应用声明事件。

由于EAI几乎不需要改变现有的遗留应用程序或封装式应用程序，而且很少需要扩展程序或定制接口，因此在开发新的应用程序时，EAI相当引人注意。EAI使用现有应用程序编程接口（API）和数据库。在没有API的特例中，EAI使用屏幕截取技术，通过应用程序的用户接口模仿普通用户，从而实现对应用程序的访问。屏幕截取是将显示在终端用户机器上、基于字符的屏幕的特定位置上的数据进行复制。

EAI的最终目的 是让企业简单、快速地集成不同的应用程序。通过合理应用EAI，企业能够利用现有资源来提供新的产品和服务，增进与客户、供应商和其他相关利益集团的联系，更新操作。另外，由于采用标准集成方式取代种类繁多的专用集成设计，EAI大大简化了企业应用程度间的互联。更重要的事，由于用先进的技术基础结构作开发基础，所以只要EAI大大简化了企业应用程序间的互联。更重要的事，由于EAI的新应用程序就能比传统方式开发的应用程序更快地投入使用。正是具备了这些新性能，它提高了企业的竞争力。

 

EAI提供了关键的新解决方案

EAI的最终目的就为企业提供关键的新的解决方案，其优势体现在以下几个方面：

·增进与客户的联系

·提供加强型供应链

·优化内部流程

·更快实施新的应用程序

下面进行具体分析

(1) 增进与客户的联系

EAI帮助企业全方位了解其客户（如图一所示），

 

每一位客户都将企业看成一个整体，而不是多个部门或部分。他们希望与之交易的企业能够识别自己。当与某个部门进行交易时，他们都不希望向其他部门重复那些他们都已经提供的信息；如果他们要求服务时被转到另一部门，却不得不重复对前一个部门说过的内容，他们会不满；老客户们则希望看到自己的长期支持受到重视。

企业希望能够利用它所掌握的所有客户信息，直到客户以前购买的产品能够促进其他产品的销售或前项交易的附加服务。客户有时会通过网络与企业联系，有时通过电话，有时亲自访问，无论哪种方式，所有这些信息都应该被整合、归纳。

要增进与客户的联系，需要集成应用。要全方位了解客户关系，则要求集成表单包含各个客户的相关信息，即使信息分散于不同部门的“烟囱式”的应有中也如此。

（2）增强供应链间的联系

除了增进与客户的联系，企业还需要加强与供应链上的其他合作伙伴乃至其他外部企业的联系。随着电子信息交换的迅速发展，通过目录清单来共享信息，企业能更加有效地协调各种活动，合作伙伴也能利用新技术来提供新服务。例如，建立与运输伙伴的电子联系，零售商也能实现先进的订单跟踪。

提高与客户的联系以及与供应链上的合作伙伴更高程度地集成信息，也就对安全提出了新的要求。如果用因特网作为通信渠道，而不是电话或者其他可靠方式，那么企业就必须确保信息的可靠性，适当控制权限以保证合作伙伴只能获得他们应该获得的信息。控制权限的一个重要功能就是：某个合作伙伴不能得到其他合作伙伴的相关交易信息。

对合作伙伴交易情况的集成要求与客户的类似，人们总是希望新的应用软件能集成好几种现有的“烟囱式”应用程序。使用类似可扩展标记语言（XML）的技术来支持信息交换，这在企业对企业（business-to-business，B2B）的自动集成方式中相当重要，用各种前段渠道对不同的关系提供不同程度的功能。企业需要融合或适配稍旧些的技术，例如EDI，从而和新的面向Web的技术实现交换。这些技术包括用于自动交换的XML技术以及用于小型合作伙伴的Web借口。这些融合和适配都是IT演进策略的一部分。

（3）改善内部流程

改善企业的内部流程对EAI发展起着重要的推动作用。EAI技术能简化企业内部各部门之间的信息流动。对于大多数企业，实施EAI工程的一个主要动力就是它能够为决策人提供集成信息。EAI技术能够协助建立数据库，用来分析市场趋势、评价交易效益以及评估企业内部机构的合作。另外，通过协调从“烟囱式”应用程序到数据仓库间的数据流，并通过将不同应用程序格式的数据转化为通用格式，EAI能够推动数据仓库的建立。

就像客户自助服务是一类重要的客户关系应用程序一样，雇员自助服务是一类重要的客户关系应用程序一样，雇员自助服务对于改善企业流程相当重要。连接Web的界面能让雇员更好地查询并获得工作所需要的信息。为方便管理或实现其他HR功能而建立的雇员自助网站越来越普遍。

EAI能够消除企业流程中的手工操作，防止数据的重复记录，EAI总是使用工作流自动化工具来作为连接所集成的应用程序之间的桥梁。

 

（4）减少市场化周期

让我们来看看现实情况：IT企业在开发关键业务（Mission-critical）应用程序方面的记录并不令人满意，针对这种情况，EAI技术一个最大的优点就是减少了新应用程序进入市场的时间。它从几个方面缩短了周期：

首先，EAI协调已有应用程序的性能。现有代码能够完成本身功能，而且已经经过调试。所需的是使新的前段通道（例如Web或新的复合应用程序）能访问现有功能。只要EAI结构安装就绪，就能用最直接的方式缩减市场化周期：因为几乎不需要添写代码。尽管最初建立合适的EAI结构需要一定的付出，但这还是值得的。企业一定愿意承担为建立EAI所需的投入已获得长期收益。

第二个优点是：利用中间件的EAI能让开发人员避开IT中的许多陷阱从而减少错误。例如，集成不同硬件和操作系统平台上的功能。同样，EAI也减少了应用程序的代码，但更重要的事，它能令开发的人员专心于该程序的业务部分，而不是整个系统，这也创造价值。在完成关键业务应用程序中，仅有30%的代码是业务逻辑部分（即真正实现业务目的的代码），剩下的是基础框架——许多商业EAI软件都包括。最近的一份研究表明，每年维护公司内部开发框架的费用占最初开发费用的15%—25%（Standish集团，1997）。因此，考虑到软件销售商的维护费，用EAI中间件取代公司内部框架能节约大笔维护费用。

 

 

四．EAI技术总览

EAI 集成包括：

1．用户界面集成(界面重组)

界面重组是一个面向用户的整合，他将原先系统的终端窗口和PC的图形界面使用一个标准的界面(有代表性的例子是使用浏览器)来替换。一般的，应用程序终端窗口的功能可以一对一地映射到一个基于浏览器的图形用户界面。新的表示层需要与现存的遗留系统的商业逻辑或者一些封装的应用如ERP、CRM以及SCM等进行集成。

企业门户应用(Enterprise Portal)也可以被看成是一个复杂的界面重组的解决方案。一个企业门户合并了多个企业应用，同时表现为一个可定制的基于浏览器的界面。在这个类型的EAI中，企业门户框架和中间件解决方案是一样的。

2．数据集成

数据集成发生在企业内的数据库和数据源级别。通过从一个数据源将数据移植到另外一个数据源来完成数据集成。数据集成是现有EAI解决方案中最普遍的一个形式。然而，数据集成的一个最大的问题是商业逻辑常常只存在于主系统中，无法在数据库层次去响应商业流程的处理，因此这限制了实时处理的能力。

此外还有一些数据复制和中间件工具来推动在数据源之间的数据传输，一些是以实时方式工作的，一些是以批处理方式工作的。

3．商务流程集成

虽然数据集成已经证明是EAI的一个流行的形式，然而，从安全性、数据完整性、商务流程角度来看，数据集成仍然存在着很多问题。组织内大量的数据是被商业逻辑所访问和维持的。商业逻辑应用并加强了必须的商业规则、商务流程和安全性，而这些对于下层数据都是必需的。

商务流程集成产生于跨越了多个应用的商务流程层。通常通过使用一些高层的中间件来表现商务流程集成的特征。这类中间件产品的代表是消息中介，消息中介使用一个总线模式或者是HUB模式来对消息处理标准化并控制信息流。

4．函数/方法集成

函数和方法集成包括直接的和严格的，在网络环境中的跨平台应用程序之间的应用到应用(A2A)的集成。它涵盖了普通的代码(COBOL,C++,Java)撰写、应用程序接口(APIs)、远端过程调用(RPCs)、分布式中间件如TP监控、分布式对象、公共对象访问中介(CORBA)、Java远端方法调用(RMI)、面向消息的中间件以及Web服务等等各种软件技术。

 

一般的EAI会包括上面的两种以上的集成。对大型的EAI系统，则会包括以上的四种方法的几乎全部。可见这种集成应用非常复杂，是非常高级和专业的一种整和技术。

 

目前，基于接口的体系结构考虑了这种对业务服务的灵活访问和客户机独立性的不断增长的需求。基于接口的体系结构包括 Web 服务、 J2C 连接器体系结构（J2C Connector Architecture，JCA）和 Java 消息服务（Java Message Service，JMS）等技术。它们还包括分离客户机代码和业务服务的实现的命令模式的所有变种。这些调用框架与 EAI 中间件之间可以相互调用。 以下列出有关的接口技术并详细介绍它们的一些特点。

1 ． Web 服务
Web 服务是面向服务的体系结构（Services Oriented Architecture，SOA）的实现。SOA 有松耦合的三方：提供者、代理和请求者。提供者提供的业务服务表示请求者无法直接看到的某个实现。请求者从代理那里了解它必须从提供者那里收发的信息结构以及访问该服务所用的协议。请求者一点也不了解提供者实现业务服务的方式。

Web 服务被定义为请求者与提供者之间的必需的业务接口而不是所有业务请求的共同管道。有些变数反映了 Web 服务的特点，包括：

• 它们可以是紧耦合的，它们的部署可以基于调用框架的使用。
• 它们以同步的请求／应答方式或异步方式来执行。
• 它们可由 J2EE 或非 J2EE 的提供程序来公开。
• 它们可能提供事务和安全性的支持（也可能不提供这种支持）。

2 ． JCA
Java 连接器体系结构主要处理的是以紧耦合的方式访问 企业信息系统（Enterprise Information System，EIS）的业务逻辑的需求。连接器体系结构提供了资源适配的支持，资源适配把 J2EE 安全性、事务和通信共享映射到相应的 EIS 技术。

起初，人们的意图是让连接器以同步的请求／应答方式来访问大型机上的旧的事务服务器，这也是当前多数连接器的工作方式。目前，标准的发展方向是更异步的双向连接性。

连接器的某些用户定义的变种更成熟，它们运行在逻辑连接方式下。同样，它们可被用作调用框架，以类似于 Web 服务的方式来选择适当的物理 EIS 目标和业务操作。

3 ． JMS
JMS 是异步的、基于消息的接口。您还可以使用 JMS 来访问分布于不同种类的系统中的业务逻辑。基于消息的接口支持以下功能：

·点到点和发布／预订机制。基于消息的框架可把信息传给其它应用程序而这些程序不必显式地请求它。相同的信息可被并行地传递给许多订户。

·节奏的独立性。JMS 框架以异步方式运行，但也提供模拟同步的请求／响应方式的功能。这使源系统和目标系统能够同时运行而不必等待对方。

·有保证的信息传递。JMS 框架可在事务方式下管理消息并确保消息的传递（但不确保传递的及时性）。

·不同种类的框架之间的互操作性。源应用程序和目标应用程序可在不同种类的环境中运行而不必处理有关它们相应的框架的通信和执行问题。

·使交换更流畅。改用消息方式后，信息交换的细粒度变细。

为什么不使用过去的方式直接对数据库的连接？

• 将业务规则集中到易于创建、使用和重用的组件中，从而方便了开发和维护。
• 提供了高级语言以注重开发业务规则，代替使用存储过程和有限的 SQL 语言来检查业务规则。
• 将数据访问集中到组件中，从而减少了应用程序中的重复代码，每个需要访问特定表的窗体都使用相同的组件。
• 如果使用类型化数据集，则可以使用智能感知功能来查询列名称，而不必记住它们。
• 集中式数据访问例程有助于维护工作，因为对任何数据访问例程的更改都只需进行一次即可。
• 可以随时将组件分离到不同的物理计算机上。这种灵活性使代码具有更好的可缩放性和集中性。
• 其他优点：集中式数据访问层。
• 其他优点：应用程序的可扩展性 - 可以添加 Web 领域以处理用户对数据库的请求的大量负载。
• 其他优点：用户可以通过 Internet 进行连接，但仍从桌面或基于 Web 的应用程序访问数据。

 

 

 

 

* EAI服务产品总览

·

 

 

 

五．从何处开始？

EAI在3～4年前崭露头角的时候，主要被用于企业中不同应用系统之间的整合，采用的方法还大多是系统之间点对点的集成，总线（也有称消息代理）这种集成模式还使用的很少。近年来随着XML、Web服务、特别是中间件技术的发展，赋予了EAI新的内涵。EAI能够进行不同应用系统之间数据的整合、应用的集成、业务流程的集成，总线的集成方式成为业内的主流

现在国内的EAI企业正在逐渐兴起。国内的大中企业对EAI的产品的需求正在形成。而在国内，除了银行，电信等非常大的母舰型企业已经初步实施了部分的EAI战略，其他的国有，私有大中企业仍然在对此望而却步。主要原因是EAI的实施耗费资金非常厉害。而且成功的少，失败的多。这些现状造成了很多企业想做EAI，但又害怕做EAI。

一个完整的EAI不可能在短期内完成。主要原因是企业需要有一个实施的过程。一般的经验是先对企业内部的部分部门做应用集成，从小处做起，然后慢慢的向其他部门推广。

从许多的EAI实施经验来看，总结成为以下四点：

首先是起步阶段 ，因为我们对这个阶段的很多东西不清楚，包括实施方法、标准的建立，都很模糊，这时候我们怎么去建立这种经验呢？我建议在一个低风险的项目里应用EAI技术，目的是形成企业信息总线建设的一个方法论，还可以建立一个可广泛采用的EAI结构，还有一点就是所有的业务人员、技术人员能够从中积累经验，通过一个项目的成实施，起到示范作用。

 第二个阶段是建立企业体系结构的阶段，它将起步阶段形成的体系结构和方法论，应用于其他系统，这时候我们将选择在哪些系统中应用它，在信息总线上去建立另外一些应用系统，通过这样建设起来的整个结构的一个雏形，这样第一阶段形成的经验，可以在这个阶段得到逐步的完善。

    第三个阶段，大面积的实施阶段。在整个企业范围内全面实施信息总线技术。在这个阶段，所有的系统都可以纳入到信息总线中，这个阶段的关键问题是要到相关部门的支持和协作，这是保证实施成功的重要基础。还有就是对人员，包括业务人员和技术人员进培训，建立实施的队伍。

第四个阶段，信息总线已经完全建成，而且产品成为了企业未来的基础设施 。所有新的应用都会在总线的架构下建设，并不断地纳入一些成熟的技术到这个框架里。在这个过程里，重点是不断地进行反馈，来完善体系结构和方法论。

从实际上来讲，我们这种规模的公司确实不适合承担这种规模的建设任务。但是，我觉得，这里有一个方法的问题。第一个阶段，我们没有钱，我们先做小的。通过这个项目，拿到第二个阶段的资金。第二个阶段，我们会有部分的钱，我们就可以 建立企业体系结构的具体工作 。到第三个阶段，我们就可以有足够的钱做完整的实施。这个概念有点象滚雪球，但实际上也正式公司的一种壮大过程。到了第四个阶段，我们有了成熟的产品，并且有了的 完善体系结构和方法论。然后就可以做实施相同行业的EAI项目。

六．技术解决方案和难点

我们将解决方案定义为三种主要的实现类型。这些实现基于对使用各种的服务运行组织部署以及 EAI 平台解决方案中所述的附加服务的分析。

·        典型的集中星型消息集成解决方案

它可在应用程序层完成 EAI 集成。该解决方案的特征为：位于中央的逻辑中心提供数据转换、传送、接收和交付服务以及其他附加功能，以解决异类应用程序集成中常见问题。此方法中，各种分布式应用程序通过中心使用消息进行通信，且中心执行这些进程的所有智能处理和状态管理任务。

 

·集中智能星型、分布式消息集成解决方案

这也能实现应用程序集成。与前述解决方案一样，此解决方案的特征为：位于中央的中心提供数据转换、传送、接收和交付服务以及其他附加功能，但在该变种中，所具有的分布式节点也处理上述任务。结果，形成了位于中央的基本中心和执行本地应用程序集成以及采用结构化或自动方式与中央中心通信的分布式处理节点。

 

·Web 服务解决方案

它通过将服务对 EAI 传统上在其中操作的正常信任域的外部公开来进行应用程序或过程集成。Web 服务解决方案一般特征为：通过使用基于标准的消息技术将当前（一般是以前遗留的）应用程序公开为 Web 服务，并将 Web 服务交互（经常也包括非 Web 服务交互）结合到更高级别的业务过程中。

 

现在综合以下，我们的开发面临的主要问题：

第一大问题：是先做功能模块，还是先做一个架构平台？

国内公司开发软件，很少有面向架构的，往往都是面向功能。但根据许多的开发和管理经验，我觉得要开发核心的产品模板和平台。很多人认为为确保工期，要先面向功能，把功能模块做好，再组成架构平台，这样即使平台失败了，还有功能。但我觉得完成了系统平台就像一块主板，功能模块就像一块块插卡。软件可以做到即插即用，任何一个业务模型产生的效果可以在其他的模块中很快地表现出来。针对不同的企业的复杂部门和业务，我们必须要先建立一个朴实的平台，这样才可以在二次开发中节约很多的成本。而且对实施EAI会带来很多不言而喻的好处。

第二大问题：是采用.NET还是采用J2EE（JMS+JCA）的技术架构？

EAI的主要实现是将企业内部不同部分的各种的应用软件在功能或数据的层次上整和起来，所以涉及到连接多个操作系统的多种不同的数据库。而且在表现的形式上也不完全是WEB的形式或桌面应用的形式。这种灵活性的系统，只能采用中间件技术来开发。我们会和多中操作系统打交道。也会和多种语言实现的应用软件打交道。要兼顾着么多的灵活性，现在唯一的选择就是web service或j2EE这两种技术。web service灵活，但在速度和高效上比不上J2EE。而J2EE在灵活程度上无法和web service相比。从公司目前的状况来看。我们没有专业的java队伍。所以也只有一条路可以选择：web service。他是很多语言都可以实现的技术，包括C，VB，DELPHI，JAVA，C#。而且微软现在的.net平台的主力抗衡J2EE的技术就是web service。他底层使用了SOAP+XML技术，在.net的封装下，具有非常简单和快速的开发环境。但.net缺乏跨平台的性质，如果涉及到其他的操作系统平台，我们可能需要用java或C来开发web service的一部分。

 

第三大问题：用Web Services整合.NET和J2EE

互用性（Interoperability）问题说起来容易但通常实现起来却比较困难。尽管Web service曾承诺要提供最佳的解决方案来衔接基于.NET和J2EE的应用程序，但其过程却并不简单。在使用SOAPBuilders和Web Services Interoperability Demo (WSID) 时还需要考虑许多问题。近期发布的Web Services Interoperability Organization (WS-I)对此也提供了很多有价值的深层见解。

用来解决互用性问题的Web services规范已经出台了，其中包括解决.NET和J2EE的互用性方案以及Simple Object Access Protocol (SOAP)、Web Services Description Language (WSDL)、Universal Description、Discovery和Integration (UDDI)等协议。了解它们真正能解决什么问题以及如何通过使用它们来解决问题是相当重要的（见图2）。

图2. 回顾基本的Web Services架构

SOAP规范定义了从HTTP到TCP/IP数据传送的消息格式，WSDL规范定义了如何描述一个Web service，而UDDI则定义了如何注册（register）和发现（discover）Web service描述。SOAP和WSDL是位于World Wide Web Consortium (W3C)底层的标准。W3C还负责定制HTML和XML领域的各种规范。

另外，W3C还为Web Services Architecture Working Group提供赞助，该组织负责开发一个用于包含基本规范的Web service参考架构（reference architecture）。如图2中可以看到架构规范的工作草案图表中所显示的SOAP、WSDL和UDDI的关系。Web service规范和实现它们的底层平台是完全独立开的，这和HTTP与HTML之间的情况相似，同时它们能在.NET和J2EE平台上运行的很好。想了解更多关于.NET和J2EE对Web service规范的支持差异的比较，请查阅Eric的文章“Decide Between J2EE and .NET Web Services”。

Web Services Architecture Working Group还制定了一些扩展规范（extended specification），比如在安全性、协调（orchestration）和事务处理方面的规范。用来实现这些规范的产品并不是很多，因此在这里我就不详细地介绍了，除非说到一些更为复杂的互用性问题，因为你必须了解Web service交互的每个部分是否支持其他规范，以及它们支持哪些规范。但从到目前为止的经验来看，即使是最基本的Web service规范也试图向互用性挑战，这是因为Web service技术存在于一个高级的抽象层中，它包括两种主要的交互方式（interaction style），每种都有其各自考虑的范围。

 

 

 

第四大问题 ：对非windows平台下的开发经验很少，技术力量差。

对各种企业，除了使用wondows平台外，还广泛采用了各种服务器自带的操作系统。这些操作系统以linux/unix等为主，但由不同的服务器公司自行开发，所以在其上的操作系统结构也不尽相同.对于一个技术团队来说，不可能对各种操作系统都熟悉，所以在具体的技术实施方面会遇到很多由于这种操作系统异构造成的困难。我觉得这些困难不是最主要的困难。因为我们可以先避开非windows操作系统的开发，把主体结构建立在windows操作系统之上。而对第三阶段的全面实施，可以请原生应用开发软件的生产组织提供技术支持，以克服这些非本质技术带来的困难。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

七．主要开发的周期计算

开发阶段	开发人月估计	开发项目经费
首先是起步阶段	28人月	4000元/人月
第二个阶段是建立企业体系结构的阶段	28人月	4000元/人月
第三个阶段，大面积的实施阶段	36人月	4000元/人月
第四个阶段，信息总线已经完全建成，而且产品成为了企业未来的基础设施 。	收益阶段	以后的每个同类项目可能需要的是原来的1/2投入
总计：	92人月	4000元/人月	368000元/人月

以上的开发都是针对一期的工程。价格和开发时间会比较长，但是在二次开发，通过 行业集成技术的特点，推出基于行业的预建构集成包。这样可以将成本节省到第一次的1/2~1/3左右，因此，可以对整个项目实现较高的利润。