EAI技术纵览

EAI 技术背景

EAI （ Enterprise Application Integration ）企业应用集成近来伴随着企业信息系统的成长正在迅速升温。在早期单一部门级小型 C/S 应用阶段，企业和开发商并没有集成系统的需求与必要；而时至今日，企业应用从 OA 到 MIS ，从 Call Center 到 Enterprise Portal ， ERP/CRM/SCM 等横跨 Intranet /Internet 的分布式系统 Step by Step 地部署建立起来，而这些各司其职的信息系统却缺乏互联互通数据共享事务协作的能力，形成了网络时代的信息孤岛。抽象归纳一下，如果期望的信息体系有以下一个或多个需求：

１．体系内有一个以上的信息系统。

２．各个系统可以建立在不同时期或不同平台。

３．信息系统都能相对独立地工作。

４．系统间需要数据共享或业务协作以及跨平台事务处理。

５．统计分析查询信息数据可以覆盖整个体系或来自特定系统。

６．有时需要增加或替换一些系统并平滑地与其它旧有系统继续协作。

７．具备体系与体系的交互能力，就像体系内所能做到的一样。

８．延长体系和系统的生命周期，提高可用性并降低耦合复杂度与维护成本。

那么，不可避免地企业将面对信息系统整合这一技术课题。

EAI 就在这样的需求驱使下走上了 IT 技术舞台。 EAI 的主导性原则是：降低企业应用整合的成本、风险与复杂度，建立一个有序的协作性强的多系统企业架构。在 EAI 概念提出之前，企业已经有一些传统的信息交换与系统整合方式来满足上述需求解决交互问题，如自定义格式、 EDI 和 XML 格式的数据文件交换、共享数据库、调用特定厂商提供的 API 或组件接口等， EAI 其实并不是取代前者的技术，而是综合现有应用集成技术与手段，为企业应用整合提供分析设计思考方法与架构模型的理论支持。本文将从 EAI 的分析导向、架构模式、实现技术、安全策略、产品浅析等几个方面渐进式地为大家介绍 EAI 技术。

EAI 分析导向

EAI 的分析导向不是要为决策者或架构师们提供一种 EAI 实施的向导，而是传递一种 EAI 系统分析的思考方式。确切地讲是在规划和指导 EAI 体系需要把握和平衡的不同层次多个侧面， EAI 分析导向应当是在整个 EAI 项目的体系规划架构设计开始之前，就应当训练的思考方式和确立的审视标准，并且贯穿于整个 EAI 项目的始终。

要建立完善可靠的 EAI 技术体系模型，应该权衡分析并满足以下几个方面的需求：

a.       应用整合导向（ Application Integration-Oriented ）

应用整合导向的思考出发点为如何整合现有的和未来的应用系统，以实现资源共享与信息互联。首先需要明确每一个系统在企业信息化的时间和空间中所承担的业务。在一个或多个系统间建立可用性强的企业应用，把分散的、孤立的应用按企业业务需求和信息体系规划按实际应用进行集成。应用整合可根据企业需求与系统特点灵活选择从数据层、业务逻辑层、用户界面层等多个层面开展。如医疗业的 IHE （ Integrating the Healthcare Enterprise ）目标就是为了整合医疗机构体系中的 HIS 、 RIS/PACS 、 LIS 、 CIS 、 ICU/CCU 等应用系统。

b.      流程自动化导向（ Process Automation-Oriented ）

流程自动化导向是以实现企业流程的自动化，缩短流程时间，提高工作效率并降低工作成本与人为出错几率为目标的思考方式。在两个以上系统与应用间完成文档、信息或任务的业务流转，减少非必要的人为干预和工作量，建立协作性强的流程自动化体系。现在流行的 BMP(Business Process Management) 业务流程管理与 BPA （ Business Process Automation ）业务流程自动化都是这种概念的延伸。如 WfMC （ Workflow Management Coalition ）工作流管理联盟规范，其核心的价值体现就是互操作性（ Interoperability ）。

c.       事务处理导向（ Transaction-Oriented ）

事务处理导向的着眼点是事务的处理，首先明确事务处理中的分布在不同应用不同系统中的各种元素，并对事务处理的参与者进行角色划分，对事务类型进行抽象归纳，建立业务处理策略的制定与调整机制以具备业务调整自适应的能力，实现事务的协作者所必须的功能与接口，提供可用的事务协作元素并保障事务的建立、分配、审核、执行、回溯可以顺利地在分布体系下完成。

d.      分布对象导向（ Distributed Object-Oriented ）

分布对象导向是采用面向对象的思考方式描述与构建分布式信息系统，从信息系统的基本元素——组件（ Component ）上提供分布式计算的能力，将分布式系统中的业务逻辑与功能集合抽象成特定的对象，并通过定义对象间的通信规则和关联关系以组成分布式系统的整体框架。如 RPC 、 CORBA 、 EJB 、 DCOM 、． NET 等对象模型都是基于分布式对象的应用体系技术。

各实施导向之间并不是互斥和孤立的，而是一个从宏观到微观的渐进分析过程。每个应用整合项目中都需要设计多项业务流程、每个业务流又有可能由一到多个的事务组合而成，而可抽象的每种事务类型则是由大量的分布式对象来描述与协作。在实际的 EAI 系统架构设计时，应当综合考虑多种导向的思想，兼顾应用、流程与事务、业务对象等多个层面的分布化应用协作问题，才能从千头万绪复杂多变的企业应用体系中抓住 EAI 体系架构的关键环节，剥丝抽茧地明确企业的分布应用体系需求及特点，为体系的设计规划提供前提保障。最终达到减小应用系统的相互关联性，缩减系统交互和集成的复杂度，优化和改进现有业务流程，提高自动化程度，减少人为干预与出错几率，建立独立性强，延展性好的分布应用的目的。

EAI 架构模式

       架构模式（ Architecture Pattern ）是区别于设计模式（ Design Pattern ）的概念，设计模式是为了提高软件的灵活性和重用性，在不断发展变化的项目与设计中针对某一类特定问题的解决方法抽象与实现思想归纳，故也被称为微架构模式（Ｍ icro Architecture Pattern ） , 而架构模式虽然与设计模式有许多共通之处，但着眼点则是更为宏观的 High-Level Design ，是设计模式的思想放大与概念深化，是面向整个系统架构的全局方案模型。

EAI 架构模式的目标是为 EAI 的成功实施提供一组基础技术理论支持，是得以解决 EAI 架构设计中的若干问题的具体的模式化的结构模型，正确地灵活地应用 EAI 架构模式，是 EAI 项目成功实施的重要保障，正如牢固的完美的建筑物都植根于科学理论和精确计算的建筑框架一样：

a.       集成适配器 (Integration Adapter) 模式

意图：转换已有的应用接口到期望接口

参与者：一个或多个的客户端应用、集成适配器和一个服务服务端应用

图１：集成适配器模式

集成适配器模式提供一种导出可重用应用服务的灵活方法，此架构模式与设计模式中的适配器模式的意图相同，另外集成适配器模式的另一个意图则是为多个客户端应该提供可重用的接口。客户端应用通过集成适配器来调用服务端应用，集成适配器转换被导出的公用 API 为服务器端 API 。适配器不知道客户端应用的存在。在非侵入式（ nonintrusive ）的适配器设计中，适配器对服务器端是透明的，而在侵入式（ intrusive ）适配器设计中，服务端应用在一些情况下需要做一定修改。

正如文章开始所描绘的那样，企业信息化是呈阶段性发展的，在此过程中后进系统大量的基础数据往往需要从旧有系统中获取。集成适配器模式，比较适合解决新老系统的协作整合问题。 Sun 在 J2EE1.3 中推出的 JCA （ Java Connector Architecture ） Java 连接器架构就符合集成适配器模式， JCA 的目标就是在 Java 新世界与旧有的 EIS （ Enterprise Information System ）企业信息系统间通过 CCI （ Common Client Interface ）建立通用的集成适配规范。

b.      集成消息器 (Integration Messenger) 模式

意图：描述减少应用间通讯关联性的方法

参与者：被集成的应用、集成消息器

图２：集成消息器模式

集成消息器是一个物理层上的分布式逻辑实体。集成消息器模式描述减少应用交互逻辑的应用集成架构，显著的益处就是可以降低应用间的通讯依存性，建立起更为灵活的集成机制，在应用间传递消息并提供位置透明的服务。集成消息器模式可支持的通信方式有：

１．一对一同步（请求 / 应答） 由一个客户端应用和一个服务端应用构成，客户端在阻塞模式下等待服务端对请求进行处理。

２．一对一异步（消息队列）。由一个客户端应用和一个服务端应用构成，客户端在非阻塞模式下等待服务端对请求进行处理。

３．一对多异步（发布和预定）。由一个客户端和一个或多个服务端组成，可由多个预定者订阅同一个发布事件。

在此涉及到在应用间进行交互，与 EAI 密切相关的概念——应用交互模型（ Application Interaction Model ），包括以下三种模式：

１．消息代理器（ Message Broker ）

２．消息队列（ Message Queuing ）

３．发布和订阅（ Publish ＼ Subscribe ）

在本模式中，应用负责实现应用交互逻辑，应用交互的语义对集成消息器完全透明。通讯模型是多样化的，但其目的是一致的——最小化应用间的通讯依赖性。异步模式对比同步模式的优点在于，异步模式可以确保数据被安全可靠地发送和接收，而不必担心因为网络或其它异常而导致的数据丢失；缺点则是异步模式会导致将同步消息处理事务拆分成了消息发送 / 入队，消息接收 / 出队两个分段事务，实时性与交互体验比同步模式差。由于集成消息器是基于消息传递的松耦合技术，消息在发送方和接收方的平台、应用上保持中立，易于实现跨平台系统的集成。另外，通过消息代理机制还可以完成诸如数据转换、消息分发、路由、缓冲、存储等特定功能。 JMS （ Java Message Service ） Java 消息服务中体现了集成消息器模式的架构思想。

c.       集成外观 (Integration Facade) 模式

意图：减小客户端与服务端应用的关联性，提供一个连接到后台应用的简化接口

参与者：一个或多个的客户端应用、集成外观和一个或多个的服务端应用

图３：集成外观模式

集成外观架构模式与外观设计模式的意图一致，但集成外观架构模式为减小客户端应用与服务端应用的依赖关系提供更高层的简化接口，提供灵活的可重用的应用和应用集成服务。集成外观能为一个或多个客户端提供一个简化接口。客户端应用调用集成外观的简化服务，集成外观抽象服务器端的功能并把集成外观的接口转换成服务端应用接口，使服务端应用更易于使用。客户端应用程序完成实际工作，而集成外观将自身的接口转换成服务端应用接口。其交互模型是客户端或服务端之一的单向性交互。集成外观不知道客户的存在，服务端应用也不知道集成外观的存在。通过从多个服务端应用系统中抽象出统一外观接口，就可以简化客户端的集成难度，达到对多个服务应用的方法一致性调用，屏蔽了其原有的复杂性。

d.      集成中介器 (Integration Mediator) 模式

意图：封装应用交互逻辑，最小化应用关联性

参与者：集成中介器、参与的应用（ Participating Applications ）

图４：集成中介器模式

集成中介器模式是封装应用交互逻辑与降低应用间耦合的应用集成架构方法。其重要优点有：

１．最小化了应用间的依赖性和旧有系统的影响。

２．通过集中式的应用交互逻辑简化了分布式交互的复杂度与维护工作量。

３．在封装的应用交互逻辑的基础上易于建立可重用的服务。

这些优势为实施者提供了更为灵活的集成方法，并改善了商务的敏捷性。与集成消息器相比，集成中介器知道有哪些应用存在。集成中介器包含了应用交互逻辑，负责控制和协调应用间的交互，应用程序直接与集成中介器交互，而不需要面对不同的应用程序。各应用间通过与集成中介器的直接交互，降低了应用间互相调用所存在的复杂度，达到了最小化应用关联的目的。而与集成外观相比，集成中介器为应用提供的是不分客户与服务的双向存取功能。并且集成中介器通常也由物理上的服务器实现，而不仅仅是统一的抽象接口逻辑。

e.       流程自动化器 (Process Automator) 模式

意图：减小流程自动化逻辑与应用的关联性的架构方法描述

参与者：活动服务（ Activity Service ）、流程控制器和应用

图５：流程自动化器模式

流程自动化器模式描述最小化流程自动化控制逻辑与信息系统依存关系的架构方法，借此所有的系统交互（及人的交互）都由活动抽象从流程控制器中得以隐藏。

主要优点有：

１．可以经济地实现强大的流程自动化解决方案。

２．可获得空前的业务流程分析能力（如流程瓶颈、统计信息、错误信息和资源利用等）。

３．此种架构可获得空前的重定义和快速部署流程自动化应用的灵活性。

４．与集成外观模式和集成中介器模式类似，应用集成逻辑是封装并且可共享的。

５．流程自动化应用工具贴近管理者角度，减少了商业角度与 IT 世界的语义分歧，最小化从商业需要到 IT 解决方案的转换发生错误的可能。

流程自动化器模式可以通过灵活的系统集成架构改善交易的灵活性，交易需要高质量的业务流程、降低缩短业务周期、降低处理成本。相同的流程每天都被重复地执行无数次，流程自动化器可以自动地为这些流程建立活动的排序机制，流程自动器的核心是活动的排序和控制（自动或手动）。以流程自动化器模式为基础，在企业分布式体系下实现业务流程管理和业务流程自动化的难度将大大降低。

EAI 架构模式中的这五种模式有一个共同目标：减小应用间的耦合度。不同的模式，总在不同的层次上进行解耦的工作。集成适配器是在接口层，集成消息器是在通讯层，集成外观和集成中介器是在应用层。流程自动化器则是在业务逻辑层。在架构层面适当地解耦，是坚固而灵活的 EAI 解决方案的本质。通过在复杂的企业体系环境下灵活地应用 EAI 架构模式，可以将繁杂而纷乱的分散应用系统整合为庞大但有序的分布应用系统，为整个 EAI 项目的成功实施和项目切割奠定了坚实稳健的基础。在合理的成功的建筑框架中添砖加瓦，势必会比在沙漠中建造海市蜃楼般的空中楼阁更为可靠。

EAI 实施技术

EAI 技术的层次划分目前可谓仁者见仁，智者见智，如有将 EAI 分为三层，从低到高分别是基础设施层（ Infrastructure layer ）、应用互操作层（ Interoperability Service layer ）和文件层（ Content Layer ）；而不少应用开发商将 EAI 按集成的资源分为从低到高的数据（ Date ）层、应用（ Application ）层和商业逻辑（ Business Process ）层，而另外的观点认为在这三层的基础之上，还有用户界面（ User Interface ）层的集成。在此之外，至少还可以找到不下三种的层次划分提法，百花齐放百家争鸣向来是学术界与产业界的盛世，不同的出发点和分析角度自然会得出截然不同的结论，笔者毫无妄论之意，只根据自身工作经验抽象出 EAI 技术实现手段的三个层次：最底层协议层由支持同 / 异步消息交换的各种通讯协议组成，由异步的基于数据交换的数据层和由具有同步实时性的分布式组件技术构成的应用层（包括界面层和业务层，都是被这些应用所实现的），越是采用底层的技术，其耦合度就越低，集成的灵活性也就越强，但可操作性 / 交互能力就越弱；反之，采用上层的技术可获得较好的交互能力和操作体验，但耦合关联度就会加大，集成的灵活性会受到较多的限制。而事实上每一种较上层的技术都是对比其低层的一种或几种技术的封装特例和综合应用。

图６：信息系统交互／集成途径及EAI实施技术分层

a.       协议（ Protocol ）层

协议主要是由实现 OSI （ Open System Interconnection ）开放系统互联参考模型的通讯协议组成，信息交换的两端只需要按协议约定完成请求 / 响应，对两者的操作系统、应用软件没有任何限制。协议层主要包括被 Internet 广泛采用的 TCP/IP 及其基础之上的 FTP/HTTP/POP3/SMTP （其中某些上层的协议可通过收 / 发的事务分段实现异步处理，如 FTP 、 POP3 、 SMTP 等）等基于 Socket 连接的技术（ Socket 甚至还是某些特殊的本地进程间的通讯方式，如在 Service 和 Application 之间），也包括在小型以太网时期流行的 IPX/SPX 、 NetBIOS 等协议，另外管道（ Pipe ）技术也是一种系统间通讯的方式（如 SQL Server 等数据库提供的 Named Pipe 数据连接；操作系统还可以提供 Anonymous Pipe 等）。使用协议层的实现手段，可为信息集成的开发与应用提供较多的灵活性，但为满足应用互操作的上层需求将必须付出较大的工作量与成本代价。

b.      数据（ Data ）层

数据层主要是通过异步方式进行数据的传递，数据的发送 / 接收双方通过先后对数据的写入 / 读出完成信息的交换。包括数据库（如通过 ODBC 、 JDBC 、 OLE DB 等通用数据库连接方式）、消息队列（操作系统的消息队列机制其实也算是消息队列的一个特例，只不过它是在应用与应用间完成消息传递）和直接文件交换（如 Flat File 、 EDI 及 XML 等格式的文件交换）三种途径，这三种方式多数情况下对交换双方的操作系统和应用软件没有限制，并且异步模式也能对批量处理和离线作业提供良好的支持，具有开发工作量小，技术难度低等特点，很多早期原始的信息交换都是采用数据层的实现技术。

c.       应用（ Application ）层

应用层主要由各种流行的分布式对象组成，具有对象化的开发和应用模型，调用简单实时性好，可操作性 / 交互能力强，但平台无关性差等特点，早期的分布对象技术，多数是从 RPC 技术衍生进化而来，其中又一度以 CORBA （ Common Object Request Broker Architecture ）平台中立、语言中立、定义完善而广受支持； RMI 、 EJB 和 DCOM 、． NET 等组件在其各自的分布式平台下也被广泛应用；而近两年兴起的 Web Service/SOAP 更是由于既具备对象化的操作能力与较大的集成灵活性（仅受限于 SOAP 协议本身）而大受业界的青睐，原因也正在于它很好地平衡与把握了交互与集成这柄双刃剑。近年来大量涌现的中间件厂商一方面灵活地封装商业逻辑为企业建立起可重定义可重定向的分布式商业信息体系，一方面也为企业应用层面的集成起到了积极的推动意义。

2002 年 2 月，旨在保证跨平台、跨应用、跨编程语言的来自不同厂商的 Web Service 间的互操作性的 WS-I （ Web Services Interoperability Organization ） Web 服务互操作性组织成立，目前已获得 Microsoft 、 IBM 、 Sun 、 SAP 、 BEA 、 Oracle 、 Sybase 、 Intel 、 Borland 、 HP 等绝大多数厂商的支持；而同年 8 月发布的旨在统一 Web Service 业务流程协作与整合方面的标准 BPEL4WS （ Business Process Execution Language for Web Services ） Web Service 的业务流程执行语言规范也受到广泛支持，从最初的由 IBM 、 Microsoft 、 BEA 三家厂商发起，目前会员已包括 Oracle 、 PeopleSoft 、 SAP 、 Sun 、 Tibco 、 Business Process Management Initiative (BPMI.org) 、 Workflow Management Coalition (WfMC) 等公司和机构；以及 UDDI 、 WSDL 、 WS-Coordination 、 WS-Transaction 、 WS-Security 、 WS-Attachment 、 WS-License 等技术的成熟完善。这些为兑现当初 Web Service 向世界所作的平台应用无关低耦合度互操作性等承诺铺平了道路， Web Service 已经真正进入了成熟的商用化阶段，将要在企业应用与系统集成方面大展拳脚了。

EAI 安全策略

       信息系统是现代化企业的命脉，信息系统的数据丢失、信息泄露、内容篡改、越权访问等都将是企业不可承受之重。企业应用集成由于涉及 Intranet/Internet 等错综复杂的网络环节，安全因素更不容忽视。在自始至终从 EAI 项目的需求分析、设计开发、测试部署及应用运行的整个 EAI 应用体系的生命周期内，安全都应当是最为重要的一个环节。构筑安全的电子交易模式，应满足以下五个方面，这也是 OSI 规定的五种标准的安全服务：

１．数据保密：防止信息被截获或非法存取而泄密。

２．对象认证：通信双方对各自通信对象的合法性、真实性进行确认，以防第三者假冒。

３．数据完整性：阻止非法实体对交换数据的修改、插入、删除及防止数据丢失。

４．防抗抵赖：用于证实已发生过的操作，防止交易双方对发生的行为抵赖。

５．访问控制：防止非授权用户非法使用系统资源。

建立安全的企业信息平台，应从以下几个方面着手：

a.       从管理高度重视安全体系

人是社会活动和生产活动中最活跃的因素，要建立安全的企业信息体系，首先应从管理高度重视企业的信息安全，企业中上到领导层下到操作员，都应认识到安全对企业的重要意义，才有可能有意识、有针对地加大在安全方面的重视和投资。对内则可以通过建立管理制度、员工操作培训、用户策略制定、访问权限划分等机制降低来自企业内部的安全隐患；对外则可以通过建立保密制度和技术投资来规避信息安全风险，保证企业信息系统的安全。

b.      用技术手段建立安全体系

通过技术手段规避安全隐患的几个方面：

网络安全：安全的应用体系只能建立在安全的基础平台之上，企业信息化规划与架构设计中就应当充分考虑到信息安全问题，建立内置的系统级的安全策略，如采用内外网隔离、子网划分、防火墙、域权限等等技术提供基础网络安全。

应用安全：安全的应用应满足信息交换的完整性、一致性、保密性和有效性等多个方面的需求。如在信息系统的分析、设计、开发、测试、验收、部署、应用等多个环节把握安全准绳，发现并弥补可能被恶意利用的漏洞；使用 SSL （ Secure Socket Layer ）、 SET （ Secure Electronic Transaction ）、 PKI （ Public Key Infrastructure ）等技术保障电子交易的安全等。

操作安全：系统操作权限的设置应遵循最小化原则，即为操作用户提供能满足其工作需要的最小使用权限，避免误操作和越权访问；另外，还需要建立系统日志机制记录应用运行与用户操作的情况。

c.       有法律制度保障安全体系

在管理与技术体系之外，法律支持也颇为重要，有健全完善的法律制度才能为电子商务、电子政务等行业建设提供可靠保障。如，我国政府最近正在审议的《中华人民共和国电子签名法》草案，相信将对督导中国电子交易的发展壮大起到意义深远的影响；另外，尽快建立健全我国在计算机及网络犯罪方面的立法工作也势在必行，有了国家法律做后盾才能对网络黑手起到震慑和惩戒的力度。

EAI 产品浅析

J2EE/Unix/Linux 和． NET/Windows 是目前企业应用平台的两大阵营，两个体系在成熟度与易用性、高性能与低成本、开放性与兼容性、占有率与增长率等多个层面上竞争角力，而 EAI 的众多技术产品与解决方案提供商也主要是围绕这两大企业应用平台分庭抗礼。

a.       IBM WebSphere Business Integration

WebSphere 是 IBM 庞大的基于 J2EE 的电子商业平台的核心，整个软件家族提供了开发、部署、应用、管理等一整套解决方案， WebSphere Business Integration 正是其中专注于企业应用集成与流程自动化领域的一组软件产品，主要包括被更名为 WebSphere MQ 的商业通讯中间件服务 MQSeries ，和在 2002 年被 IBM 重金收购的 EAI/BPM 软件供应商 CrossWorlds 和 Holosofx 的软件产品，整合后的 WebSphere Business Integration 覆盖模型、集成、连接、监控和管理五个方面近二十个软件模块，并提供大量成熟的行业与跨行业解决方案参考。其目标是连接应用和实现流程自动化，建立单一化统一化和现代化的企业基础架构。所有的应用都可以跨越不同的环境、开发语言、传输方式和数据格式来共享数据。可以设计和规划独立运行或与人交互的商业流程。企业信息体系可获得按照商业需求灵活智能地路由和传递信息的能力。可帮助企业模拟行业特有的业务流程在企业内部与合作伙伴、客户间的业务活动的流转，在定制和套装的应用程序间整合这些流程。将企业流程与供应商和客户通过连接起来，并提供业务流程监控和业务性能管理的功能。在最新 V4.2.2 版的 Business Integration 中，同步连接能力、监控和调试跟踪等功能都得到了大大的加强。 Business Integration 正如其所在的庞大的 WebSphere 体系一样， 具有产品线完善、功能细分明确、组合协作能力强、解决方案灵活、平台一体化等特点，蓝色巨人博大精深的软件模型与解决方案体系由此也可见一斑。

b.      BEA WebLogic Integration

WebLogic 原本是一家独立的公司， 1998 年被慧眼识珠的 BEA 看中，收购后成为 BEA WebLogic Platform 。在 2002 年前 WebLogic 曾是 J2EE 应用服务器领域的龙头老大，无奈后来被 IBM “随需应变”的 WebSphere ，夺取了桂冠，只得屈居第二。 BEA WebLogic Platform 与 IBM WebSphere 具有很多共通点，如都是基于 J2EE 平台，都是套装化软件体系，商业应用服务软件的相同市场定位等。虽然较之 IBM WebSphere 产品线， BEA WebLogic Platform 多少显得有些薄弱，从系统架构、功能模块、解决方案、技术支持力量等多方面落后于前者，但能在这个“只有第一第二，没有第三”的残酷竞争环境中生存发展，也确有其过人之处。在最新版式的 BEA WebLogic Integration 8.1 中， BEA WebLogic Integration 是其重要产品之一，提供了较为完善的企业业务系统集成方案，包括应用服务器、业务流程管理、应用集成和 B2B 集成等功能。为开发、集成和管理业务流程提供了直观且强大的实施方法，它能使 IT 技术以单一的解决方案培训适用于所有应用，在跨不同项目部署资源时具有更大的灵活性和可伸缩性，并且提供的开发和运行时框架，将所有业务集成组件统一到一个单一、灵活的环境之下。这些组件涵盖业务流程管理、数据转换、业务伙伴集成、连通性、消息代理、应用监控和用户交互等。 BEA 较之 IBM 当然是“小巫见大巫”，但灵活性却比较强，比如对 EJB 等标准支持的产品化响应速度，而 IBM 之所以能有近百年的发展历史，风雨飘摇，岿然不动，步步为营稳中求胜才是其生存发展的法宝。

c.       Microsoft Biztalk Server

Microsoft 长久以来一直是桌面应用领域的霸主，而从． NET Enterprise Servers 概念的提出开始，其试图一改以往自己树立的桌面应用提供商的形象，正式进军市场潜力巨大的企业应用领域。尽管从微软的财务年报来看目前微软的 Business Solutions 部门尚处于亏损状态，但改头换面统称为 Windows Server System 的微软商用服务软件体系却在不断成长完善中。而其中的 Biztalk Server 就是面向企业 EAI/BPA 领域的服务器产品。最近刚刚问世的 Biztalk Server 的第三个版本 Biztalk Server 2004 客观来讲已相对成熟，虽然相较于 IBM WebSphere 还只能算是“轻量级选手”，不过对中国大多数的中小规模企业来说，却是比较有竞争力的产品。一方面是因为这些企业的应用平台多数部署于 Windows 环境，系统底层支持会比较平滑，一方面微软所谓“ Do More With Less ”的市场策略也的确符合中国企业信息化要求少投入多产出的客观现状。不过 Biztalk Server 的价格（ Enterprise Edition 为 2 万 5000 美元、 Standard Edition 为 7000 美元、 Partner Edition 为 1000 美元）看似不高，但“水份”不小：首先， Biztalk Server 只能依赖于 SQL Server/Windows 运行，新出的 Biztalk Server 2004 更是把开发、配置、部署、管理的环境嵌入到了 Visual Studio ． NET 当中，这些价格不菲的平台软件 Bill 当然也是会一文不少地寄帐单给你的。从功能来看，正式基于． NET 和支持 Web Service 、具备企业内部与贸易伙伴间的整合能力、流程管理与自动化、业务规则制定与监控等功能有所增强、遵循了 BPEL4WS 并提供灵活的行业加速器和适配器等等，的确也当刮目相看了。 附赠的一条来自微软内部人士的消息是 Longhorn 中 Avalon 、 Indigo 、 WinFS 三大特性中 WinFS 是基于 Yukon 数据库引擎（原理类似于在 NTFS 文件系统之上加一层类 MSDE 〈 Microsoft SQL Desktop Engine 〉无管理界面的数据引擎），并且 Yukon 引擎完全内建于系统底层之中。以上这点是众所周知的，真正让人吃惊的是 Biztalk Server 的 EAI/BPM/BPA 商业流程、业务规则和活动监控引擎也将会成为潜在 Longhorn 底处的一枚重镑炸弹，也就是说 Longhorn 系统将把 Biztalk Server 引擎作为其 Indigo 网络架构中 Web Service 的一部分，整合到系统底层当中去。希望 IBM 等其它 EAI/BPM 厂商不会就此事又与微软打起旷日持久的垄断官司来，也不要又被欧盟寄罚单了。

目前 EAI 领域尚处于春秋战国的纷争时期，参与的技术厂家较为众多，无论是领袖群伦的行业巨无霸，还是企业应用软件领域的后起之秀，数据库或操作系统发家致富的淘金者，都觊觎着企业应用领域的这块大蛋糕，争先恐后地想要分一杯羹。相信经过两三年的市场竞争考验与优生劣汰， EAI 技术能够更加成熟与完善起来，将企业信息化推向更深更广的应用高度。

总结

       企业信息化是一个长期的发展渐近过程，而 EAI 技术是其发展上升的过程中所不能避免的问题。建立强壮而灵活企业信息体系的关键，就是通过 EAI 技术，将孤立的分散于企业内与企业伙伴间的应用系统联系起来，形成资源共享、业务协作的分布式商业应用体系。

无论是 EAI 的导向思想，还是架构模式，都是为成功解决企业信息系统集成中的种种难题，提供科学的方法与理论依据。 EAI 概念的引进与实践，必将为企业降低信息投资的成本与风险，提高业务竞争力与企业应变能力，在信息孤岛间建立起沟通共融的桥梁，为分布式跨应用、跨企业的商业协作体系的建立提供强大的技术基础和理论参考。

注：本文涉及技术与产品较广，作者在写作中参考了国内外的众多技术资料，在此表示感谢。另外，本文部分观点源于笔者自身的工作经验，仅供参考。