CORBA（Common Object Request Broker Architecture, 公共对象请求代理体系结构）是由OMG（对象管理组织，Object Management Group）提出的应用软件体系结构和对象技术规范，其核心是一套标准的语言、接口和协议，以支持异构分布应用程序间的互操作性及独立于平台和编程语言的对象重用。
CORBA经过近十年的发展，已逐步走向成熟，并成功地应用在我国许多大型的软件系统中，由此产生了对掌握CORBA技术的软件开发人员的大量需求。在此，我们应广大读者的要求组织了本次讲座。 本系列讲座分别介绍了CORBA的基本思想、体系结构以及CORBA应用程序的设计与开发，希望借此能帮助广大软件开发、设计人员，开阔思路，加深对CORBA的理解，进而真正掌握这门技术，并能在实际工作中加以灵活运用，更高效、迅速地开发出更强壮的软件系统，最终促进我国软件事业的蓬勃发展。
CORBA产生的背景
近年来，随着互联网技术的日益成熟，公众及商业企业正享受着高速、低价网络信息传输所带来的高品质数字生活。但是，由于网络规模的不断扩大以及计算机软硬件技术水平的飞速提高，给传统的应用软件系统的实现方式带来了巨大挑战。
首先，在企业级应用中，硬件系统集成商基于性能、价格、服务等方面的考虑，通常在同一系统中集成来自不同厂商的硬件设备、操作系统、数据库平台和网络协议等，由此带来的异构性给应用软件的互操作性、兼容性以及平滑升级能力带来了严重问题。
另外，随着基于网络的业务不断增多，传统的客户/服务器（C/S）模式的分布式应用方式越来越显示出在运行效率、系统网络安全性和系统升级能力等方面的局限性。
为了解决分布式计算环境（DCE，Distributed Computing Environment）中不同硬件设备和软件系统的互联，增强网络间软件的互操作性，解决传统分布式计算模式中的不足等问题，对象管理组织（OMG）提出了公共对象请求代理体系结构（CORBA），以增强软件系统间的互操作能力，使构造灵活的分布式应用系统成为可能。
正是基于面向对象技术的发展和成熟、客户/服务器软件系统模式的普遍应用以及集成已有系统等方面的需求，推动了CORBA技术的成熟与发展。作为面向对象系统的对象通信的核心，CORBA为当今网络计算环境带来了真正意义上的互联。
CORBA的发展历程
1. 对象管理组织（OMG）简介
OMG成立于1989年，作为一个非营利性组织，集中致力于开发在技术上具有先进性、在商业上具有可行性并且独立于厂商的软件互联规范，推广面向对象模型技术，增强软件的可移植性（Portability）、可重用性（Reusability）和互操作性（Interoperability）。
该组织成立之初，成员包括Unisys、Sun、Cannon、Hewlett-Packard、Philips等在业界享有声誉的软硬件厂商，目前该组织拥有800多家成员。
2. CORBA主要版本的发展历程
● 1990年11月，OMG发表《对象管理体系指南》，初步阐明了CORBA的思想；
● 1991年10月，OMG推出1.0版，其中定义了接口定义语言（IDL）、对象管理模型以及基于动态请求的API和接口仓库等内容；
● 1991年12月，OMG推出了CORBA 1.1版，在澄清了1.0版中存在的二义性的基础上，引入了对象适配器的概念；
● 1996年8月，OMG基于以前的升级版本，完成了2.0版的开发，该版本中重要的内容是对象请求代理间协议（IIOP，Internet Inter-ORB Protocol）的引入，用以实现不同厂商的ORB真正意义上的互通;
● 1998年9月，OMG发表了CORBA 2.3版，增加了支持CORBA对象的异步实时传输、服务质量规范等内容。目前，宣布支持CORBA 2.3规范的中间件厂商包括Inprise(Borland)、Iona、BEA System等著名的CORBA产品生产商。
CORBA体系结构概述
CORBA规范充分利用了现今软件技术发展的最新成果，在基于网络的分布式应用环境下实现应用软件的集成，使得面向对象的软件在分布、异构环境下实现可重用、可移植和互操作。其特点可以总结为如下几个方面：
1. 引入中间件（MiddleWare）作为事务代理，完成客户机（Client）向服务对象方（Server）提出的业务请求(引入中间件概念后分布计算模式如图1所示);
图1 引入中间件后客户机与服务器之间的关系
2. 实现客户与服务对象的完全分开，客户不需要了解服务对象的实现过程以及具体位置(参见图2所示的CORBA系统体系结构图);
3. 提供软总线机制，使得在任何环境下、采用任何语言开发的软件只要符合接口规范的定义，均能够集成到分布式系统中；
4. CORBA规范软件系统采用面向对象的软件实现方法开发应用系统，实现对象内部细节的完整封装，保留对象方法的对外接口定义。
在以上特点中，最突出的是中间件的引入, 在CORBA系统中称为对象请求代理（ORB，Object Request Broker）和采用面向对象的开发模式。
对象模型是应用开发人员对客观事物属性和功能的具体抽象。由于CORBA使用了对象模型，将CORBA系统中所有的应用看成是对象及相关操作的集合，因此通过对象请求代理（ORB），使CORBA系统中分布在网络中应用对象的获取只取决于网络的畅通性和服务对象特征获取的准确程度，而与对象的位置以及对象所处的设备环境无关。
图2 CORBA系统体系结构图
CORBA的主要应用方向及中间件产品介绍
CORBA规范的推出，重新调整了客户机与服务器之间的关系。客户机可以向服务器提出事务请求，同时也可以为下一个请求充当服务器角色。
由于CORBA系统引入了中间件的概念，即事务代理，由中间件完成客户机与服务器之间的通信，使得服务器对于客户机的位置相对透明，取消了原有分布式计算模型中客户机、服务器之间的一一对应关系。CORBA客户机可以在运行时动态获得服务对象的位置，并且可以对多个服务对象提交事务请求，因此，极大推动了分布计算的发展。
分布计算是指网络中两个或两个以上的软件相互共享信息资源。这些软件可以位于同一台计算机中，也可以部署在网络节点的任意位置。基于分布式模型的软件系统具有均衡运行系统负载、共享网络资源的技术优势。
另外，CORBA规范约束采用面向对象的分布式软件的构造方法，以接口定义语言的形式实现对象内部细节的完整封装，从而降低了软件系统的复杂程度，增加了软件功能的可重用性。CORBA提供到C/C++、Java、SmallTalk等高级语言的映射，很大程度地减小了对程序设计语言的依赖性，使软件开发人员可以在较大范围内共享已有成果。
正是以上特点推动了分布式多层软件体系结构的发展。目前，CORBA技术在银行、电信、保险、电力和电子商务领域都有广泛的应用。
软件市场中能够见到的CORBA中间件产品很多，但基于不同公司的产品战略以及研发方向，各个产品在服务性能、对高级语言的支持和所依赖的系统平台方面有很大区别。根据整理的资料，笔者对主要产品在上述几方面进行了分析（参见表1），供读者在选择时参考。 用JAVA开发CORBA应用实例
通用对象代理体系结构CORBA（Common Object Request Broker Architecture）是对象管理组织所定义的用来实现现今大量硬件、软件之间互操作的解决方案，CORBA也是迈向面向对象标准化和互操作的重要一步。
■ CORBA技术简介
简单地说，CORBA允许应用之间相互通信，而不管它们存在于哪里以及是谁设计的。CORBA1.1于1991年由OMG发布，其中定义了接口定义语言（IDL）以及在对象请求代理（ORB）中实现客户对象与服务器对象之间交互的应用编程接口（API）。CORBA2.0于1994年发布，规定了各个供应商之间的ORB的通信规则。
CORBA标准主要分为三个部分：接口定义语言（IDL）、对象请求代理（ORB）以及ORB之间的互操作协议IIOP。
ORB是对象之间建立Client/Server关系的中间件。使用ORB，客户可以透明地调用一个服务对象上的方法，这个服务对象可以在本地，也可以在通过网络连接的其他机器上。ORB截获这一调用同时负责查找实现服务的对象并向其传递参数、调用方法返回最终结果。客户并不知道服务对象位于什么地方，它的编程语言和操作系统是什么，也不知道不属于对象接口的其他系统部分。这样，ORB在异构分布环境下为不同机器上的应用提供了互操作性，并无缝地集成了多种对象系统。
在开发传统的Client/Server应用时，开发者使用他们自己设计的或一个公认的标准来定义用于设备之间通信的协议。协议的定义依赖于实现语言、网络传输和许多其他因素，而ORB的出现简化了这一过程。使用ORB时，协议是使用接口定义语言（IDL）定义的，而IDL是独立于语言的。并且ORB提供很强的灵活性，它使程序员选择最适合的操作系统、执行环境，甚至系统各个组件也可以采用不同的编程语言实现。更重要的是，它允许现有组件的集成。在一个基于ORB的解决方案中，开发者可以使用与创建新对象一样的IDL对遗留系统进行建模，他们创建"包装"代码以在标准化的软件总线与遗留系统接口之间传递信息。
使用CORBA，用户可以透明地访问信息，并不需要知道信息存在于什么软件中、使用什么硬件平台，以及位于企业网络的什么地方。作为面向对象系统的通信核心，CORBA为今天的计算环境带来了真正的互操作性。
■ CORBA与JAVA的相互关系
CORBA不只意味着对象请求代理（ORB），它还是非常全面的分布式对象平台。CORBA使JAVA应用可以跨越网络、语言以及操作系统，并为JAVA提供了一组分布服务，如分布式自我观察、动态发现、事务、关系、安全和命名等。
JAVA不仅是一种语言，它还是一个动态代码系统，它对运行对象来说是一个可移植的虚拟机（JVM）。JAVA为开发、管理、发布Client/Server应用提供了更简单的方式。人们可以通过将应用放在一个Web服务器上将这一应用发布给成千上万个用户，而不必关心它的安装和升级。JAVA还非常适合服务器的开发，它可以动态地将服务代码移向最需要它们的地方。
JAVA将会使CORBA对象能够运行在从主机、网络计算机到蜂窝电话等可编程的各种机器上，并简化了大型CORBA系统的代码发布。对客户和服务对象来说JAVA是很理想的编程语言，JAVA内置的多线程、垃圾收集和错误处理使编写健壮的网络对象变得很容易。
这两种对象模型可以很好地相互补充，CORBA处理网络的透明性，JAVA处理实现的透明性，CORBA为JAVA可移植应用环境提供了一个分布式的结构。
■ 使用JAVA开发CORBA应用
下面让我简要介绍一下开发CORBA的步骤。
使用JAVA开发CORBA应用需要如下五个步骤：
1. 使用IDL创建接口 (About.idl)
2. 下面的OMG IDL描述一个CORBA对象。
module About
{
interface Show
{
string ShowName();
};
};
将其存为Show.idl。
3. 编译接口并生成CORBA支持文件
我们用以下命令编译这个 IDL 接口：
idltojava Show.idl
idltojava是SUN公司的IDL编译器，可以免费从SUN公司站点上下载。
因为idltojava在编译IDL文件之前，需要进行预编译，而如果你的机器上没有预编译器，可以使用以下命令：
idltojava -fno-cpp Show.idl
编译后将在当前目录下生成About子目录，其中会包括一些支持文件，如有兴趣可以看一下，但一定不要修改。
4. 实现服务器 (ShowServer.java)
ShowServer的main() 方法，可完成以下任务：
（1） 创建一个 ORB 实例
（2） 创建一个服务对象实例（CORBA About 对象的实现）并通知 ORB
（3）获取一个命名上下文的CORBA对象引用，在该命名上下文中注册新的CORBA对象
（4）在命名上下文中将新对象注册在"About"名下
（5）等待对新对象的调用
实现服务器源程序如下：
import About.?;
import org.omg.CosNaming.?;
import org.omg.CosNaming.NamingContextPackage.?;
import org.omg.CORBA.?;
class ShowObject extends _ShowImplBase
{
public String ShowName()
{
return "\nMy name is Seymour!!\n";
}
}
public class ShowServer {
public static void main(String args[])
{
try{
// 创建和初始化 ORB
ORB orb = ORB.init(args, null);
// 创建服务对象并将其向 ORB 注册
ShowObject ShowRef = new ShowObject();
orb.connect(ShowRef);
// 获取根命名上下文
org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService");
NamingContext ncRef = NamingContextHelper.narrow(objRef);
// 绑定命名中的对象引用
NameComponent nc = new NameComponent("About", "");
NameComponent path[] = {nc};
ncRef.rebind(path, ShowRef);
// 等待来自客户机的调用
java.lang.Object sync = new java.lang.Object();
synchronized (sync) {
sync.wait();
}
} catch (Exception e) {
System.err.println("ERROR: " + e);
e.printStackTrace(System.out);
}
}
}
4.实现客户机 (ShowClient.java)
下面的应用程序客户机将完成以下任务：
（1）创建一个ORB；
（2）获取一个指向命名上下文的引用；
（3）在命名上下文中查找"Show"并获得指向该 CORBA 对象的引用；
（4）调用对象的 ShowName() 操作并打印结果。
import About.?;
import org.omg.CosNaming.?;
import org.omg.CORBA.?;
public class ShowClient
{
public static void main(String args[])
{
try{
// 创建和初始化 ORB
ORB orb = ORB.init(args, null);
// 获取根命名上下文
org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService");
NamingContext ncRef = NamingContextHelper.narrow(objRef);
//解析命名中的对象引用
NameComponent nc = new NameComponent("About", "");
NameComponent path[] = {nc};
About.Show ShowRef = ShowHelper.narrow(ncRef.resolve(path));
// 调用 Show 服务对象并打印结果
String show = ShowRef.ShowName();
System.out.println(show);
} catch (Exception e) {
System.out.println("ERROR : " + e) ;
e.printStackTrace(System.out);
}
}
}
5.构建和运行ShowName程序
（1）编译 .java 文件，包括 stub 和 skeleton（在About目录中）：
javac ?.java About/?.java
（2）启动一个MS-DOS命令解释器，输入以下命令，确保名字服务器处于运行状态：
tnameserv -ORBInitialPort 1050
（3）启动另一个MS-Dos命令解释器，输入以下命令，启动Show服务器：
java ShowServer -ORBInitialPort 1050
（4）再启动一个MS-Dos命令解释器Show应用程序客户机：
java ShowClient -ORBInitialPort 1050
这时屏幕上会出现"My name is Seymour!"的字样，说明实验已经成功了。
EAI技术分析
作者：沙晋（）
关键词：EAI，EIS，CORBA，J2EE，JCA
摘要：随着社会信息化进程的进一步加快，以及信息化技术的不断进步，很多公司开始发现在引进新的应用和系统的同时，如何保证公司旧有的应用和系统投资不至于被全部抛弃或替换是节省公司运作成本并有效利用公司资源的重要手段。但由于旧有应用和系统所采用的体系结构与新的系统存在及大的差异，往往使这些应用集成到新的系统中并不容易，本文就是针对在这种企业应用集成需求下的各种可用技术进行分析及建议。
阻碍企业将新旧应用系统集成在一起的问题似乎显而易见，不外乎由以下两点所组成：
所采用的体系结构不同；
所使用的技术不同；
但要完全跨越这两条企业应用集成的鸿沟却是存在巨大困难的。为了更好地解决这些问题，业界已经出现了许多相关技术及方案，如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的RMI-IIOP来调用CORBA的分布式对象。
2.2 Java2平台企业版J2EE
在近几年的企业应用系统开发中，J2EE无疑扮演了一个重要的脚色。开发业务逻辑或中间层组件的最重要的技术就是EJB，它提供了对主要的企业技术如事务、安全性以及持续性的支持，便利了业务组件的开发。尽管EJB受限于Java编程语言，但这种技术本身并不存在问题。同时，J2EE与CORBA技术所达成的一致性为低层组件的请求提供了可行之路，RMI-IIOP和JMS等技术无疑为J2EE提供了强有力的功能核心。
优点：
基于规范的平台，不受限于特定的操作系统或硬件平台，有大量实现商可以选择；
提供现代的组件体系结构，这种结构简化了复杂组件的开发；
提供主要的企业技术如事务、安全性以及持续性的支持，并以声明和编辑方式对这些服务提供支持。
相对成熟，支持大量中间件技术，能够为EAI提供满意的性能及可升级性。
缺点：
受限于Java编程语言，尽管可通过其他中间件技术（如CORBA）支持；
实现商之间的可移值性还达不到100%；
与特定于某个操作系统或平台的实现技术相比，性能还有待进一步提高，且资源占用量较大。
适用：
J2EE规范本身就提供了一个巨大的企业应用集成平台，基于Java使其不依赖于运行的硬件平台和操作系统，然而也使其受限于单一语言开发。但这一开发平台，目前已经有不同的厂商提供了符合规范说明的各种实现方法。J2EE支持大量中间件技术，和现有的系统能够协同工作。HTTP，RMI-IIOP，JMS，JDBC，JCA以及对XML，企业事务，企业安全方面的支持使其成为目前几种企业应用集成平台中的首选。
2.3 XML和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.6 J2EE连接器体系结构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规范，但实现的不同使得第三方所开发的资源适配器未必能正常发布或应用。
EAI技术分析
作者：沙晋（）
关键词：EAI，EIS，CORBA，J2EE，JCA
摘要：随着社会信息化进程的进一步加快，以及信息化技术的不断进步，很多公司开始发现在引进新的应用和系统的同时，如何保证公司旧有的应用和系统投资不至于被全部抛弃或替换是节省公司运作成本并有效利用公司资源的重要手段。但由于旧有应用和系统所采用的体系结构与新的系统存在及大的差异，往往使这些应用集成到新的系统中并不容易，本文就是针对在这种企业应用集成需求下的各种可用技术进行分析及建议。
阻碍企业将新旧应用系统集成在一起的问题似乎显而易见，不外乎由以下两点所组成：
所采用的体系结构不同；
所使用的技术不同；
但要完全跨越这两条企业应用集成的鸿沟却是存在巨大困难的。为了更好地解决这些问题，业界已经出现了许多相关技术及方案，如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的RMI-IIOP来调用CORBA的分布式对象。
2.2 Java2平台企业版J2EE
在近几年的企业应用系统开发中，J2EE无疑扮演了一个重要的脚色。开发业务逻辑或中间层组件的最重要的技术就是EJB，它提供了对主要的企业技术如事务、安全性以及持续性的支持，便利了业务组件的开发。尽管EJB受限于Java编程语言，但这种技术本身并不存在问题。同时，J2EE与CORBA技术所达成的一致性为低层组件的请求提供了可行之路，RMI-IIOP和JMS等技术无疑为J2EE提供了强有力的功能核心。
优点：
基于规范的平台，不受限于特定的操作系统或硬件平台，有大量实现商可以选择；
提供现代的组件体系结构，这种结构简化了复杂组件的开发；
提供主要的企业技术如事务、安全性以及持续性的支持，并以声明和编辑方式对这些服务提供支持。
相对成熟，支持大量中间件技术，能够为EAI提供满意的性能及可升级性。
缺点：
受限于Java编程语言，尽管可通过其他中间件技术（如CORBA）支持；
实现商之间的可移值性还达不到100%；
与特定于某个操作系统或平台的实现技术相比，性能还有待进一步提高，且资源占用量较大。
适用：
J2EE规范本身就提供了一个巨大的企业应用集成平台，基于Java使其不依赖于运行的硬件平台和操作系统，然而也使其受限于单一语言开发。但这一开发平台，目前已经有不同的厂商提供了符合规范说明的各种实现方法。J2EE支持大量中间件技术，和现有的系统能够协同工作。HTTP，RMI-IIOP，JMS，JDBC，JCA以及对XML，企业事务，企业安全方面的支持使其成为目前几种企业应用集成平台中的首选。
2.3 XML和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.6 J2EE连接器体系结构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规范，但实现的不同使得第三方所开发的资源适配器未必能正常发布或应用。
