EAI技术分析

摘要：随着社会信息化进程的进一步加快，以及信息化技术的不断进步，很多公司开始发现在引进新的应用和系统的同时，如何保证公司旧有的应用和系统投资不至于被全部抛弃或替换是节省公司运作成本并有效利用公司资源的重要手段。但由于旧有应用和系统所采用的体系结构与新的系统存在及大的差异，往往使这些应用集成到新的系统中并不容易，本文就是针对在这种企业应用集成需求下的各种可用技术进行分析及建议。

阻碍企业将新旧应用系统集成在一起的问题似乎显而易见，不外乎由以下两点所组成：

· 所采用的体系结构不同；

· 所使用的技术不同；

但要完全跨越这两条企业应用集成的鸿沟却是存在巨大困难的。为了更好地解决这些问题，业界已经出现了许多相关技术及方案，如CORBA，J2EE，XML，DCOM等等。本文不是为了向读者具体介绍这些技术及方案的实施，本文的目的根据在企业应用集成中可能出现的各种情况，分析不同技术的优缺点，并给出相应可行的建议。

 1.介绍EAI

EAI，也就是企业应用集成并不是一个新的概念。但步入九十年代后，EAI的重要性开始得以体现并倍受关注。原因很简单，企业需要不断改进他们应用系统的功能，作为企业利益最大化的工具，企业的管理者希望他们对其所作的投资能够得到回报。但显然的，企业的管理者们渐渐开始意识到，如引进新的应用系统不能与旧有应用系统很好的集成在一起工作，将导致过去投资被浪费，旧有的应用系统功能部分或全部被抛弃。这显然是企业的管理者们所不愿看到的，于是在纷纷采用新的体系结构进行应用系统开发同时，如何将旧有系统有效的集成进来开始正式走上各个公司的研究桌面。

在本文中，我们将企业的应用系统称为企业信息系统EIS。EAI的最终目的就是要将企业的各种EIS集成到一起，这一过程应尽可能不对已有的应用程序做出(过多)的修改，并实现数据共享和业务流程的集成。

当然，企业需要在EAI之前进行策划，以确定实施EAI在时间及成本方面的确优于完全引进新的应用系统。因为失败的EAI过程将会为企业带来更大的损失，集成风险的比重应该受到足够的关注。

后面，文中将给出几种不同集成技术的分析，指出应当采用的适当技术。但应该注意的是，集成技术还在不断的发展，所给出的建议未必是最优或在将来仍为最优，这也与笔者的经验有关，我们必须承认集成工作需要太多的知识，也相当复杂，特别是在所需集成的EIS数量较大且体系结构互异时，集成难度更是直线上升。因此，如何运用和组合文中所给出的集成技术及建议是需要读者好好考虑的，不要把它们当成模式，它们只是一些可选且未必最优的方案，也许EAI永远没有固定的模式。

有一点需要说明的是，文中对于使用不同语言的异构系统以Java和C++为例，相信它们能够代表目前的流行案例，便于读者理解及运用。

还有一点需要强调的是，本文中所涉及的集成案例都是以应用与业务集成为主，关于数据集成以太表示层集成不在本文的讨论范围之列。

2.技术解析

问题会使人思考，EAI的需求则驱使相关技术飞速发展，尽管这些技术还没有使EAI易如反掌，但它们的确使EAI的成功有了更大的保障。在本文中，我们将多多少少的涉及以下的一些技术规范。这里我们不是要详细描述每一种技术规范，因为其中的每一项都足以用几本书来讲解，而且这些书都已经存在了，这应该算是一个好消息。我们所需要做的，只是了解并分析它们的优缺点及适用性。

2.1通用对象请求代理结构CORBA

说到EAI就很难让人不联想到CORBA。毕竟，让不同编程语言协同工作的主要方法之一就是利用CORBA。作为一个分布式对象的体系结构，CORBA的最初目的就是能够使不同的编程语言、操作系统和软件平台之间实现协同工作。而且，发展到今天，CORBA2已经完全基于面向对象技术，CORBA3则是朝着基于组件的方向发展，其开放性使在不同的CORBA实现商之间进行沟通成为可能，部分甚至可以达到100%的源代码兼容。

· 优点：

· 以一种中间件的方式为不同编程语言提供协同工作的可能；

· 对操作系统没有特殊的要求和依赖，仅取决于实现商，但实现商可以选择；

· 有效长且成熟的发展历史，与许多流行的应用系统(如J2EE)在体系结构上关系密切。

· 缺点：

· 具体的性能与所选实现商的实现有关，且性能再好，中间件的一些服务始终都是瓶颈；

· 一般情况下需要修改源代码来实现对旧有应用软件的包装；

· 适用：

当需要集成的两个企业应用软件互为异构，由不同的编程语言实现时，Java与C++就是一个很好的例子。要这两种语言进行协同工作的几乎惟一的方法就是利用CORBA。当然，使用JDK所提供的功能特性JNI也是可能的，但其复杂性以及对Java可移植性的破坏使其不能胜任该集成工作。且JNI不具备分布实施的能力，它的目标也不在于此。

CORBA很适合于通过修改源代码来包装现有应用软件，为其他异构系统提供新的CORBA分布式对象。对于远程方式的请求，IIOP协议会是一个好的选择，例如通过J2EE的RMIIIOP来调用CORBA的分布式对象。

2.2Java2平台企业版J2EE

在近几年的企业应用系统开发中，J2EE无疑扮演了一个重要的脚色。开发业务逻辑或中间层组件的最重要的技术就是EJB，它提供了对主要的企业技术如事务、安全性以及持续性的支持，便利了业务组件的开发。尽管EJB受限于Java编程语言，但这种技术本身并不存在问题。同时，J2EE与CORBA技术所达成的一致性为低层组件的请求提供了可行之路，RMIIIOP和JMS等技术无疑为J2EE提供了强有力的功能核心。

· 优点：

· 基于规范的平台，不受限于特定的操作系统或硬件平台，有大量实现商可以选择；

· 提供现代的组件体系结构，这种结构简化了复杂组件的开发；

· 提供主要的企业技术如事务、安全性以及持续性的支持，并以声明和编辑方式对这些服务提供支持。

· 相对成熟，支持大量中间件技术，能够为EAI提供满意的性能及可升级性。

· 缺点：

· 受限于Java编程语言，尽管可通过其他中间件技术(如CORBA)支持；

· 实现商之间的可移值性还达不到100%；

· 与特定于某个操作系统或平台的实现技术相比，性能还有待进一步提高，且资源占用量较大。

· 适用：

J2EE规范本身就提供了一个巨大的企业应用集成平台，基于Java使其不依赖于运行的硬件平台和操作系统，然而也使其受限于单一语言开发。但这一开发平台，目前已经有不同的厂商提供了符合规范说明的各种实现方法。J2EE支持大量中间件技术，和现有的系统能够协同工作。HTTP，RMIIIOP，JMS，JDBC，JCA以及对XML，企业事务，企业安全方面的支持使其成为目前几种企业应用集成平台中的首选。

2.3XML和XSLT

XML除了大量应用在因特网技术及文档描述中外，在数据交换中也承担了一个重要的角色。作为一个独立的平台，只需用标准文本，XML能够被所有程序语言读写，一旦使用了DTD或Schema，XML的解释程序就能对文件内容进行验证并处理。XSLT同样是基于XML技术的，但它的作用是重新格式化并传输XML数据文件，从而得到一个全新指定格式的XML文档，相信读者已经可以想象这些技术在不同应用系统中进行数据交换时发生的巨大作用了。

· 优点：

· 内容由标准文本组成，任何平台和程序语言都可以使用；

· 各种程序语言的解释程序可以根据DTD或Schema对文件内容进行验证并处理；

· 格式的转换基本不受限制，可以满足不同应用系统的需求。

· 缺点：

· DTD在过去被大量的使用，但DTD本身不是XML，而是基于正则表达式的；

· 当XML内容较大时，解释程序的执行效率会是一个问题；

· 适用：

当不同的应用系统使用着各自的数据格式，或符合复杂的行业标准，而现在需要在各个应用系统之间交换数据，那么XML和XSLT提供了一个可行的手段。当然，XML并不能解决所有的数据交换问题，如何将各种不同的原始数据格式以XML文档来记录就是一件棘手的问题。但好的一面是各种平台及编程语言目前都已经很好的支持了XML及XSLT，一旦XML准备就绪，XSLT就准备将其转换成其他应用系统需要的数据格式。

2.4分布式组件对象模型DCOM

DCOM扩充了在网络中通过COM支持的对象，并允许COM应用软件分布在局域网中的多个计算机上。DCOM通过网络协议定义过程中的通信。在运行时，COM为客户程序和使用RPC的组件提供服务，而且遵循DCOM协议标准。

· 优点：

· 在Windows平台上提供基于COM体系结构的分布式处理；

· 在Windows平台上使用能够达到较为满意的性能要求。

· 缺点：

· 在跨平台使用中存在困难，且性能无法得到保障。

· 适用：

在Windows平台上进行集成实施的首选，但与其他平台及编程语言的协同工作需要借助于第三方厂商的支持。

2.5消息中间件MOM

企业消息传递使得应用程序能够跨多平台进行可靠的传输。通过使用可靠的消息队列，提供支持消息传递所需的目录、安全和管理服务，MOM确保验证过的应用之间消息传送的安全，它通常提供同步和异步的传输模式。在企业内部保证可靠的传输最通用的方法就是使用消息传递系统。CORBA和J2EE目前就支持MOM的工业标准接口。

· 优点：

· 为不同的企业应用系统提供了跨多平台的消息传输；

· 除支持同步传输模式外，还支持异步传输，有助于在应用间可靠地进行消息传输。

· 缺点：

· 与其他中间件技术一样，高流量的性能瓶颈问题正在改善；

· 适用：

如果要在多个平台上的应用程序之间保证可靠的传输，且这些应用程序并不在同一时间运行时，应用之间的RPC直接通信或传输数据将不能胜任，而消息中间件MOM会是一个好的选择。即使当请求建立时，接收方应用程序没有运行，这个请求也不会丢失，这就是异步传输的优势。

2.6J2EE连接器体系结构JCA

JCA是在J2EE1.3的版本规范中提出的，由EIS厂家来执行和提供。JCA的资源适配器是规范化的EIS代理，可插入到任务符合J2EE规范的应用服务器中，并通过应用服务器提供的标准EIS访问接口CCI来对EIS执行操作。JCA向基于EAI的应用程序开发者提供了通过一个将EIS整合进入J2EE的标准方法。此方法定义了一套开发者能在J2EE环境中使用的通用API和服务。

· 优点：

· JCA不仅能在数据上将EIS系统集成到J2EE应用中，它还能够将安全与事务等管理涉入到符合条件的EIS系统中。

· JCA的出现使得将遗留的EIS系统集成到J2EE应用中的操作复杂度由NxM减小为N+M。

· JCA由于基于Java技术，在多平台的移植过程中所遇到的阻力较小。

· 缺点：

· JCA是一种紧耦合的问题解决方案，它的实现需要涉及所希望集成的遗留EIS系统的API，并且对这些操作进行封装。

· JCA是基于Java技术的，尽管不需要所被集成的EIS系统也是Java实现，但通过JCA去使用该EIS的客户应用却必须是Java实现。

· JCA的实现并不容易，如果实现联接管理部分是JCA所必须的，则一旦加入了事务及安全管理则复杂度将急剧上升，如果是以CCI来实现则遇到的问题可能会更多。

· 适用：

JCA所提供的好处基本上是面向J2EE应用服务器及EIS系统供应商的，因为他们的产品往往是符合各种标准与规范的，JCA所给出的统一规范对于他们来说无疑是降低风险并减少开发成本的好武器。但对于一般的企业自产的应用系统而言，JCA就未必能够发挥太大的作用，相反，它有可能成为开发过程中的瓶颈。原因有几点，第一，JCA即资源适配器的开发并不是所有的开发者都能够胜任，它的开发模式与编写普通代码不同，JCA将设计模式中的Factory等模式发挥得淋漓尽致。第二，JCA作为一个统一的规范，它的实现也需要很多的标准与规范来支持，如XA分布事务等。而一个企业的自产应用系统往往并不具有这些标准与规范，所实现的资源适配器并不能享受JCA所提供的众多优点。第三，企业自行开发的资源适配器最终还是要插入到各种J2EE应用服务器中去，但作为第三方的开发者，不了解所使用的J2EE应用服务器的相关特征，甚至应用服务器中存在的缺陷，尽管双方都遵循JCA规范，但实现的不同使得第三方所开发的资源适配器未必能正常发布或应用。

3.参考文献

· 《J2EEEAI编程指南》：MatjazB.Juric等著，WROX，电子工业出版社

· 《J2EEConnectorArchitectureandEnterpriseApplicationIntegration》：RahulSharma等，AddisonWesley

· 《JavaNativeInterface》：ShengLiang，AddisonWesley

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友