——学习EAI及用java整合你的应用 摘要
Web的繁荣正在结束，这一点我们要正视它。我们必须与时俱进，随时代而变。假如你象我一样，你会发现那些公司已经将注重力向内转移到了一种叫EAI（企业应用整合）的事物上。你可能会问，“我知道J
2EE（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元素从：
111
转
