-------------------------------------------------------------------------------
摘要

Web的繁荣正在结束，这一点我们要正视它。我们必须与时俱进，随时代而变。如果你象我一样，你会发现那些公司已经将注意力向内转移到了一种叫EAI（企业应用整合）的事物上。你可能会问，“我知道J2EE（Java2平台，企业版本）和Java，但我不知道EAI”。你可能不知道它，但你正在了解它的路上。Java为EAI提供了一个理想的语言，因为它可以在多数操作系统上运行并从EAI工具销售商那里取得良好的支持。另外，J2EE提供了EAI要求的安全、消息及可靠性服务。在这篇文章中我将解释EAI及如何使用你现有的J2EE和Java技术去整合应用。

在90年代，公司购买打包的软件解决方案比如SAP、Oracle ERP、PeopleSoft、JDEdwards、Siebel、Clarify等等。尽管这些打包的软件解决方案分别工作得很好，但它们建立了信息孤岛。在许多场合，每个系统都会产生多余的信息（象客户信息）。因此，当公共数据改变时，则只有通过手工在每个系统更新相关的信息，这一过程很快会变得非常麻烦。最后，交叉存在于系统中的一些数据变成不一致。当人们注意到因此而发生的数据重复输入、数据不一致和信息孤立的问题时，他们决定找到一个方法以整合系统。从那开始，企业应用整合（EAI）诞生了。

一、企业应用整合

EAI 将分离的应用结合成一个应用的合作联盟。存在两种针对整合应用的逻辑综合架构：直接point-to-point连接和基于中间件整合。 

1、点对点（Point-to-point）整合

EAI开发者从事点对点整合是因为他们发现其容易理解并且当只有少量系统要整合时可以快速实现。一个点对点综合例子：一个应用程序直接利用JDBC（Java数据库连接）调用另一个应用程序的数据库表。最初，当你整合两个应用时，点对点整合解决方案象是正确的选择；然而，当你整合额外的应用时，你会发现一种情形如下图1所示。



图1 一个点对点整合的最后阶段

考虑所有这些，点对点整合的基础构造证明是脆弱的。每个应用都紧密地与其它应用通过它们的点对点连接联系在一起。在一个应用中发生改变就会打破与它有关的应用整合。另一个缺点是要求支持的整合点的数目。如果你有五个互相整合的应用，你将需要10个不同的整合点，如图2所示。因此，每个额外的应用要被整合和维护将变得很困难。 



图2 点对点连接的数目

为了避免上述问题，我们需要一个中间层将一个应用的改变从另外应用中隔离出来。

2、基于中间件整合

中间件正起到提供一个应用程序间协调点的作用。中间件提供通用接口，所有整合应用可以用其相互传递消息。每个接口定义了一个由另一个应用程序提供的商业过程。图3显示了使用中间件面向服务架构的一个逻辑描述。



图3 基于中间件整合

一个面向服务架构让你添加和替换应用程序而无须影响其它应用。如果你有五个应用要整合，你只需有五个整合点。和点对点方案比较，基于中间件方案更易于支持众多的整合应用并要求较少的维护。另外，中间件能够执行复杂的操作—交换、聚集、路由、分离和转换消息—当数据在应用到应用传递时。仅有的不利方面是：建立中间件的添加初始化的复杂性和用中间件API转化已存在的应用。 

二、整合方式

一旦你选择了逻辑EAI架构，你必须选择整合方式。EAI有五种通常整合方式： 

数据级整合 

用户界面（UI）级整合 

应用程序级整合 

方法级整合 

1、数据级整合

使用数据级整合，你可以整合应用程序使用的后端数据仓储。数据级整合能够基于推或拉技术。用基于推技术，一个应用程序可用SQL调用（通过数据库链接或存储过程）在另一个应用程序上的数据库表。基于推数据级整合将数据推进另一个应用程序的数据库中。相反，基于拉数据级整合利用触发和轮询。触发捕获数据的改变并将识别信息写入表接口。适配器能够轮询整合应用程序的表接口并取回相关数据。当一个应用程序要求被动通知另一个应用程序数据变化时你可以使用基于拉数据级整合。 

当整合应用程序不提供任何API或客户接口时可使用数据级整合，并且你应密切关注商业操作如何影响你的应用程序的数据模型。数据级整合是缺乏API的应用程序唯一的选择。 

在数据级整合中，从依赖系统传播的变化绕过整合应用程序，因此所有插入、更新和删除都能对整合应用程序访问的数据进行操作。开发常用数据库网关或触发和存储过程实现数据级整合。重要的不利方面：保障整合应用程序的数据完整无缺。例如，一些包含上千个表的ERP系统。一个表可能依赖于其它的表，并且整合应用程序是这些依赖的唯一实施者。 

2、UI级整合

UI级整合 将整合逻辑连结到用户接口代码。UI级整合是基于脚本或代理。基于脚本的UI级整合将整合代码嵌入到UI组件事件中，通常使用客户机/服务器应用程序如PowerBuilder或Vantive。例如，当你单击添加用户屏幕的Submit按钮时，数据必须被送到应用程序的数据库和一个JMS（Java消息服务）。基于代理的UI级整合使用整合应用程序接口将数据从传统系统传递到终端。 

当你不能简单直接访问数据库时或当你的商业逻辑嵌入在用户接口中时使用UI级整合，大型机和客户机/服务器应用程序为UI级整合提供了典型的候选。大型机一般不能访问友好数据存储并且通常不能提供公共API。对于这部分，许多客户机/服务器应用程序将商业逻辑嵌入到客户端。在这些情况中，UI级整合提供了访问和维护数据完整的唯一途径。 

在多数情况，UI级整合是你最后的手段。添加逻辑脚本去快速捕获客户机/服务器应用程序中的事件随着作为整合级维护的增长及变化的发生而变得困难。在其它情况，UI变化能够打破整合触发和逻辑。此外，UI的维护和整合代码的维护紧密永久地连结在一起。 

3、应用程序级整合

应用程序级整合，可能整合应用程序的最好途径是使用整合应用程序的综合框架和API。应用程序接口让你调用商业逻辑去保护数据的完整性。整合API例子包括Siebel的Java DataBeans和SAP的JCA(J2EE连接器架构)。宁愿使用应用程序级整合是因为它对于整合应用程序是透明的并且能保护应用程序的数据完整。 

4、方法级整合

方法级整合， 一个较少频繁使用的应用程序级整合的超集，将多重应用程序的公共操作聚到一个单独的前端整合应用程序的应用程序中。 

当每个整合应用程序提供一套相似的API或函数方法时使用方法级整合。典型的，你创建一个聚集应用程序前端使用分布式组件（CORBA，企业JavaBeans (EJB)，DCOM (分布式组件对象模型)，等等）。一个前端整合组件可能类似于：

//一个前端应用程序组件的代码

addCustomer (CustomerInfo ci) {

ERPComponent.addCustomer(ci.getName(), ci.getAddress(), ci.getEmail());

ECRMComponent.insertCustomer(ci.getFName(), ci.getLName(), ci.getAddress(), ci.getEmail());

}

方法级整合要求整合应用程序支持一个RPC（远端程序调用）或分布式组件技术。所有和整合应用程序相互影响的应用程序都通过前端应用程序如此处理。因此，如果一个客户端应用程序想要添加一个客户，它将调用前端组件的addCustomer()方法。组件将添加客户到ERP和CRM（客户关系管理）系统。 

方法级整合的主要缺点滋生于应用程序与前端组件的紧密结合。在整合应用程序API的改变打破前端应用程序组件和依赖它们的应用程序。当你拥有基于CORBA整合技术或一个分布组件技术时使用方法级整合。因为方法级整合是一个比应用程序级整合更复杂的形态，用中间件推行应用程序级整合更有意义。 

5、怎样选择一个整合方式

选择适当的整合方法在基于约束建模中通常是一个练习。智慧的作法是，查看每个系统并将可能的接口定义到应用程序中。在有些情况，应用程序没有任何API；因此后端数据存储是仅有的选项。在其它情况，API和一个CORBA基础构造可能存在；因此使用应用程序级整合。


三、核心整合组件

现在我们看了不同的整合方法，让我们再看一下在多数EAI解决方案中提到的核心特征及服务。下面的核心特征及服务是你的整合解决方案中重要的建设组成部分。 

1、通用XML模式

一旦你 
为每个目标应用程序选择一个整合方法，就要确定一个通用的整合XML模式以包含所有整合对象及它们相关的属性。你开发的整合模式必须考虑每个整合应用程序的XML模式和应用程序XML模式的未来。多数打包的ERP和CRM应用程序包括它们自己的XML模式以描述它们的内部商业对象。你需要将萃取的数据从这些应用程序中转换到整合的XML格式然后到目标应用程序的XML格式。来自其它应用程序的中间XML格式在一个应用程序的XML模式中孤立地变化。如果你不使用中间XML格式，你将不得不定义从每个应用程序到其它应用程序及后端的映射。 

2、数据转换

转换 指将XML或非XML数据从一种格式转换成另一种格式。这是整合的一个重要部分。被分类进数据类型及语义的转换。 

一个数据类型转换指将属性值从一种应用程序格式转变成另一种。例如，一个应用程序可能使用"M"和"F"描绘性别而另一个应用程序则使用"Male"和"Female"。另一个数据类型的转换例子，考虑将一个XML元素从：

<EMPLOYEE_ID>111</EMPLOYEE_ID>

转换到：

<EMPLOYEE_NUMBER>111</EMPLOYEE_NUMBER>

相反，一个语义转换是将数据从一种格式转换成另一种格式。例如，Oracle存储客户的姓名在first、last、和middle初始化字段。另一方面，SAP存储一个客户的姓名在一个单独的使用一种lastName，firstName格式的字段里。从Oracle发送数据到SAP要求一个语义转换将last name用逗号与first name连接。 

数据转换是定义过程的典型部分。 

3、定义过程

每个应用程序对于完整的商业操作都有明确的定义。穿插应用程序的整合过程同样是真实的。你必须理解事件、系统（来源、中间、目标）和路由等对于整合应用程序的要求。例如，一个大型的公司可能拥有12个应用程序存储着多余的客户数据。当一个新的客户被插（事件）进一个应用程序时，你必须定义一个过程以传播信息到其它11个系统。11个系统每一个系统会根据不同要求的字段用不同的格式提供客户信息。有时你在目标系统处结束前会通过中间系统路由消息。你最终将用物理整合架构实现这些信息。 

四、物理整合架构

物理整合架构 涉及实现一个基于中间件整合方案所必需的物理软件组件。基于Java 的EAI支持三层架构：消息汇流排、集中和JCA。 

1、消息汇流排架构

在消息汇流排架构，每个应用程序连接到一个消息汇流排(更象一个多点传送网络)。每个整合应用程序与一个与多点传送网络相连的整合节点相关联（也被叫作一个适配器）。整合节点运行在和整合应用程序同样的逻辑单元或与访问整合应用程序的客户或API级同样的逻辑单元（见图4）。每个整合节点使用多点向其它整合节点广播信息。当一个应用程序想要和它的对等共享信息时，它发送一个多点消息在网络上。每个消息有一个相关的主题。参与的整合节点拾起消息并检查它们是否感兴趣。如果它们感兴趣，整合节点通过调用在与它结合的应用程序上的一些商业逻辑来处理消息。消息汇流排是和Tibco Rendezvous共用的。 



图4 消息汇流排架构

优点：用一个消息汇流排架构，你能够传播一个单独消息到多个客户端。当一个多址组播包发送出去后，任何感兴趣的应用程序能够拾起并处理这个包。如果多个客户端要求一样的数据，你能够再发送一次。

缺点：消息汇流排架构经常有安全的问题。支持基于授权认证访问多址组播包不是不可能但十分困难。基于多址组播整合架构在网络上丢弃的包任何网络成员都能够看见。

消息汇流排架构也增加了网络流量。多址组播包否定了交换机和桥的智能路由。作为整合节点的同一个网络中的每个客户处理多址组播包到开放系统互连模型（OSI）的应用层。客户然后消耗CPU处理丢弃无效的包。 

第三个缺点是缺乏集中管理。每个整合节点必须利用一些RAID（磁盘冗余阵列）配置类型以支持消息日志文件的完整——一种花费昂贵的建议。 

作为另一个缺点，考虑消息汇流排架构的专利权。通常，Tibco是实现消息汇流排仅有的销售商。 

最后，多址组播包在没有协议转换器的帮助下不能穿过网络边界。如果另一个应用程序在一个分离的网络或子网中被整合，另一个过程必须拾起多址组播包将它们转换成单点传播包，然后传送包到其它网络的另一个过程。在远程网络中的过程为远程网络上整合节点的接收将单点传播包转换回多址组播包。 

2、集中架构

与消息汇流排架构相比较，在一个集中架构 中每个整合应用程序与一个整合节点相关联。每个整合节点作为到整合应用程序的一个JMS事件监听器和接口服务。JMS提供消息持久性、消息过滤、事务处理和确保消息被交付以及路由到目标应用程序(见图5)。当一个应用程序必须和其它应用程序会话时，它发布消息到JMS控制中心。监听器（消息驱动bean）发送消息到商业过程以应用商业规则、转换、路由逻辑和工作流管理。 

与消息汇流排架构相比，用一个集中式JMS架构，所有整合节点都和一个代替多址组播网络的JMS服务器通信。另外，集中架构倾向于基于单点传播。单点传播包允许在不同网络和子网的应用程序轻易就可与其它对话而无需协议转换器的帮助。因为交换机和路由器能够智能地路由单点传播包，客户只接收与它们有关的包。这同时也将黑客阻止在网络段外并能得到相关综合信息。此外，一个集中架构全面改进了安全。多数J2EE服务器支持SSL (安全套接字层)和授权认证访问JMS服务器。最后，集中架构易于管理让你在一个单独场所管理你的持久消息和事务日志。 



图5 集中JMS架构 

优点：首先，一个集中架构改善了维护和管理。在消息汇流排架构中，每个整合节点保护与确认保证消息相关的日志文件。结果，每个消息汇流排节点都需要一个RAID。然而，集中架构仅在JMS服务器上需要一个RAID。

与路由和转换相关商业规则位于集中消息服务内。在集中调度中你将很容易找到调试和问题解决方案因为你能查看日志文件并找出某个地方的错误。消息汇流排架构要求你询问不可信的整合节点，坐标信息并在多处位置解决问题。 

集中架构也能更好地利用网络资源。单个消息很少无需转换送到多个应用程序。这也减轻了对于整合应用程序多点传送协议的好处。交换机和桥能够利用由一个单点传播框架的MAC（媒体访问控制）地址提供智能路由。友好网络单点传播包不要求协议转换而能与另一个网络或子网对话。 

最后，集中架构支持基于标准的消息象JMS，允许你转换不同的销售商执行并给开发者一个统一的通讯接口。 

缺点：集中架构缺乏标准的整合节点（适配器）。尽管一个整合节点标准不存在，但流行的开放适配器开放资源适配器框架支持JMS、套字接、文件、IBM WebSphere MQ、Tibco Rendezvous和数据库。

3、J2EE连接器架构

JCA 是一个根本不同的整合方法，将整合组件放在J2EE应用程序服务器上，给你集中架构的维护和管理好处。然而，JCA适配器要求远程API（看图6）——能够在一个远程主机上调用商业逻辑的类。几个远程API例子包括CORBA，EJB，DCOM，JDBC和RPC。JCA标准化到企业信息系统（EIS）的接口这样你就能够在任何J2EE兼容服务器上使用一个单独的JCA适应适配器。JCA 1.0很好地支持事务、安全和资源管理。然而，因为JCA规格是1.0版本，它还有一些局限性。首先，它缺乏一个异步消息机制。第二，所有请求都是单向的。第三，它不支持基于事件的过程。BEA WebLogic已经通过添加对事件的支持扩展了JCA 1.0，但解决方案是有专利权的。 



图6 J2EE连接器架构 

优点：JCA有与集中式架构一样的维护和管理优点，包括集中维护、管理和商业规则。友好网络JCA象集中式架构一样直接支持J2EE服务。JCA有一个标准化适配器接口以支持多应用程序服务器和EIS的额外优点，以及为确保完整传播、事务处理和资源池而标准化语义。

缺点：JCA 1.0的缺点与规范的未成熟有关。首先，JCA不支持在EAI方案中要求的异步调用。第二， JCA 1.0仅支持从应用程序服务器到EIS的调用。最后，JCA 1.0不支持定义从EIS接收应用程序事件的任何语义。JCA象是用驱动整合过程的入口目标对准基于入口的整合。JCA 1.5规范增加支持JMS插入功能，EIS事件通知和异步方法。

五、基于Web服务架构

虽然基于Web服务的简单对象访问协议（SOAP）整合相对较新，但一些人主张它将代替我们所知道的EAI。我不完全同意这种主张，但我明白在什么地方SOAP是一个很有用的整合工具。 
SOAP定义了一个基于XML的对象——调用在任何传输协议上都有用的协议，通常是HTTP。SOAP强大实力之一是它的语言的独立。用任何语言写的应用程序客户都能够调用在基于SOAP Web服务上的方法，只要方法传递正确的XML。主要的缺点：SOAP不为事务处理、可靠交付或保证通讯定义语义。 

让我们检查一种SOAP失败的情形。让我们说你想要用SOAP代替JDBC与一个数据库交互。你可能想通过暴露数据库为一个基于SOAP的Web服务，用任何语言写的客户都能访问那个数据。但你想过客户端将直接产生示加工的XML消息吗？不，它们或许会使用一个基于XML的API（可能是XDBC（XML数据库连接））。每种语言将有它自己的你必须学习的XDBC API；最后你必须问你自己你得到了什么？ 

图7显示了一个典型的商业-to-商业（B2B）问题。 

图7 典型的B2B问题使用多供应商解决方案（图片另存可看详图） 

图7的B2B问题，每个伙伴有一个不同的B2B解决方案。伙伴A使用WebLogic整合(WLI)。为了和伙伴A的集线器互动，它们必须运行一个WLI辐条在它们的站点上。每个辐条必须轮流与伙伴站点的后端应用程序整合。过程在每个伙伴的不同B2B解决方案中重复。当更多的伙伴加入时，支持它们的整合点和软件将变得笨拙。每个伙伴现在需要系统管理员理解Vitria、webMethods和WLI。

相反，图8显示了在Web服务中整合的一个解决方案。

图8 一个在Web服务中证明有效的情形（图片另存可看详图） 

在图7中显示的解决方案不同于图8，每个伙伴现在能够运行它自己的软件而无需运行其它伙伴的软件。所有SOAP消息首先放在持久队列中，然后一个确认立即返回。其保持每个伙伴与它的伙伴松散地连结。消息驱动bean处理消息并操作事务处理，复制消息过程，可靠交付和保证与后端系统的通讯。在每天的结束时，一个成功操作的记录消息传递给伙伴以调和一致。 

六、整合实践

现在你理解了不同的架构，让我们将你学习的应用到真实世界整合我所面临的问题。 

1、需求描述

一个大公司购买了WebLogic整合工具通过一个COBAL应用程序整合用户信息，一个特定的机构内部的应用程序，一个打包的软件应用程序和一个数据仓库。 

行为和事件

任何应用程序都能产生事件。XML将在所有应用程序和数据仓库间双向传递： 

COBOL应用程序产生一个新的客户文件在一个特定的目录。一个过程拾起并转换文件到XML。信息必须被送到每个应用程序。用户信息更新过程通过COBOL商业接口用JAM（针对大型机的Java适配器）可存取。 

数据仓库，仅作为一个信息接收者，不传播信息。 

用户和打包应用程序通知COBOL应用程序任何用户信息的改变及接收新用户事件。 

转化和路由

从COBOL应用程序来的信息必须由COBOL文件格式转换成XML。 

安全

系统间的所有消息都要求加密。 

事务处理

文件传输必须支持事务处理和持久。一个文件被送到服务器之后，它必须被处理。如果服务器关机，所有持续消息必须稍后被处理。 

2、应用程序的描述

应用程序1:特定的COBAL CICS (用户信息控制系统) 应用程序运行在OS/390。基于文件接口使用一个指定的COBAL格式。 

应用程序2:分布式应用程序提供API。 

应用程序3:内部定制的没有API的应用程序使用一个相关的数据库。 

应用程序4: 数据仓库为DSS（决议支持系统）和OSS（操作支持系统）从所有系统聚集信息。 

3、解决方案架构

图9显示了解决方案架构。虚线箭头指示在网络接口上的消息方向——或是基于JMS或是基于大型机。实线指示内部过程通迅。



图9 整合实际解决方案（图片另存可看详图） 

解决方案推理

（1）因为客户决定购买WLI并在其已存在的基础构造上构建，所以我们不能选择消息汇流排。 

（2）整合应用程序不支持通过一个网络传输进行事件通告，所以我们不能使用JCA。 

（3）在节点间要求被开发适配器管道支持的加密技术。管道担当资源与接收器组件间的过滤组件。每个适配器利用由资源组件、任何数目的过滤管道和一个接收器组件组成的开放适配器框架。资源组件监听来自JMS主题/队列、文件、套字接、数据库、RV消息的事件或客户事件。一旦触发，资源组件就通过任何配置的管道传递信息。在我们的例子中，我们使用管道加密和解密。当管道完成时结果信息传递到接收器（目的地）。接收器可以是JMS主题/队列、文件、套字接、数据库、RV消息或一个客户目的地。 

（4）JMS提供完整或没有消息事务处理语义。 

（5）WLI的数据整合插件能够将非XML格式与XML格式互换。 

七、小结

在这篇文章中，我已经介绍了EAI的基础知识、EAI架构和EAI方法。你已经了解了每种EAI架构的优点和缺点，EAI相关服务的重要性以及如何用Java和J2EE帮助整合。使用这些知识，你现在就能够用Java设计EAI解决方案了。