"组件模型的两大巨头终将对决？"
什么是.NET？我们可以从各种技术角度探讨.NET，NET的技术书籍也可以撰写成几十
本、甚至是上百本。但是Microsoft提倡.NET，最重要的目的是提供一个足以和Java
平台对抗的"企业平台"(Enterprise Platform)。Microsoft希望企业能够使用.NET作
为企业应用系统的核心平台，根据这个企业核心平台再开发各种应用系统，连接新式
的移动设备(Mobile Device)，形成企业应用系统需要的完整信息供应链，提供类似
目前Java拥有的企业业务。Microsoft希望通过.NET打入企业市场的企图是不言而喻
的。
为什么Microsoft急于打入企业市场呢？主要因为企业市场是获利最为丰富的市场，
也是Microsoft长久以来最想进入的市场。另外，Microsoft不希望Java独占企业市场、
进而产生对Microsoft的威胁，这是第二个关键因素。其次更重要的原因是，Microsoft
在客户端几乎已达饱和，继续成长的空间有限，需要另外能够持续成长的市场，而企
业市场、消费端市场、通讯市场以及游戏市场就是Microsoft注重的目标了。
Microsoft要想打入企业市场，需要面对的是表现愈来愈好的J2EE架构。目前J2EE已
经被愈来愈多的大型企业用作企业核心的信息技术。根据Gartner Group的调查，EJB
的架构将逐年增加，到了2003年将会拥有超过40％的使用率。这代表EJB将成为企业
应用系统的核心组件架构，更多的企业系统将使用J2EE来建制。
这些现象在大型的信息业界反映得非常真实和明显，例如台湾的台积电(TSMC)、联电
(UMC)和友达光电等都已经在使用Java和J2EE作为新一代信息系统开发的核心技术。
再看看目前EJB服务器的两大领导厂商产品--BEA的WebLogic以及IBM的WebSphere。
WebLogic和WebSphere除了已经成为许多企业的核心J2EE服务器、提供企业开发应用
系统的基石之外，还慢慢形成了企业应用系统的解决方案中心，并从其中衍生出许多
新的软件需求和应用。例如许多的Portal系统、ERP、CRM或Web Service应用都围绕
在这两个J2EE服务器的外部进行增值的应用。这种现象已经开始形成非常巨大的力量，
让EJB服务器的竞争从EJB核心服务器演变到EJB解决方案的地步，宛如一个黑洞在不断
地吸引新的应用和力量进入、使用这个架构。这种软件群聚的效应正是企业级信息技
术应该形成的现象，因为唯有如此，才能够让影响力不断扩大。当初Microsoft的
Windows就是这样，吸引了全世界程序员为Windows开发应用软件，以Microsoft Windows
为应用的核心，这才造就了Windows成为全世界客户端操作系统的霸主。
由此可见，一个核心软件技术对于信息应用的重要性。当初Microsoft在Windows上力
推COM/COM+组件模型，希望它们成为Windows上的核心组件技术，提供企业在Windows
平台上开发企业应用系统的解决方案。其实以效率来说，COM+的确是不错的。根据许
多的测试以及TPCC上公布的结果来看，COM+的执行效率几乎是最好的。而前段时间The
ServerSide上公布的EJB对COM+的评比更是闹得满城风雨。Java业界仍然不肯承认COM+
比EJB来得有效率，但是以目前的数据来看，在Windows上EJB的确远远比不上COM+。
在Microsoft多年的推展之后，COM/COM+的确也有了不错的使用结果。根据2002年北
美关于COM+的信息调查显示，使用COM+技术的人占了34.3％，而且还有9％的人回答
将会采用COM+。虽然COM+在执行效率方面表现很好，但不可否认的是COM+只能在Windows
平台使用，而且在Internet应用中使用不便，延展性也不若EJB，这都是COM+致命的
缺点。
.NET核心组件技术
既然Microsoft希望.NET成为企业应用的平台，那.NET需要提供什么呢？除了开发工
具之外，.NET最重要的便是提供一个类似J2EE架构的软件解决方案，以吸引软件人员
为.NET开发企业级的应用系统，帮助.NET打入企业市场和Java平台竞争。
那现在的.NET中有什么类似J2EE架构的技术呢？从下图我们可以清楚地看到，Microsoft
在.NET中正逐渐建立起同SUN Java平台竞争的技术核心。Microsoft和SUN的虚拟竞争
平台现在几乎非常类似，不过，目前的Java在组件技术的领域远远超过了Microsoft
提供的解决方案。
Microsoft在.NET中的组件技术是以.NET组件配合COM+为主。COM+在.NET中转为操作
系统的核心服务，提供事务管理(Transaction Management)的功能，而.NET组件则可
以同时扮演.NET中的可视化组件(Visual Component)、数据感知组件(Data-Aware
Component)以及中间件(Middleware Component)。然而使用.NET组件作为.NET平台中
间件有许多问题。首先是.NET组件必须依靠COM+组件提供分布式事务管理能力；另外，
.NET组件目前也没有像EJB一样的Fail-Over和Load-Balancing能力，这在企业级的应用
中是明显不足的。
此外，.NET组件必须和COM+一起搭配使用，这意味着程序员必须开发COM+组件，而.
NET的原生工具无法开发COM+组件，程序员还是必须使用原生的Windows开发工具。此
外，一旦使用了COM+，代表此.NET应用系统无法移植到其他的平台。如果Microsoft
把.NET移植到Linux或是FreeBSD上，那使用COM+组件的.NET应用系统将无法移植到这
些平台之中。
那么，Microsoft是不是需要一个新的、能在.NET平台使用的组件架构呢？就我的眼
光来看，如果Microsoft希望把.NET平台定位在企业系统同J2EE竞争，那的确是需要
这种技术，但这对于Microsoft是有一点困难的。首先，Microsoft正忙于在一二年内
达到Java平台花了七八年的成果，正忙于开发.NET本身、.NET开发工具、.NET下的数
据库，并且把所有的Microsoft Server应用程序移植到.NET之下，可能一时无法投入
太多的资源来开发一个全新的企业级的组件架构。
另外，再看看Microsoft建立组件架构的历史就可以了解到，在这方面Microsoft的确
不太在行。期望Microsoft在短时间内在.NET平台定义类似EJB的企业组件架构的规格
并且将其实现出来，似乎是不太容易的事情。
组件技术 结果
16位VBX 失败
32位VBX 失败
OLE 失败
COM 尚可
ActiveX 失败
MTS 失败
COM+ 不错
.NET组件 不适合使用在企业级应用中
既然新创.NET下的企业组件架构不是短时间内可以完成的，那是不是代表着.NET在这
方面已经无法和J2EE竞争而提早出局呢？其实并不一定，因为如果无法快速开发一个
新的组件架构，那为什么不使用已经存在且已经验证是适合企业应用的组件架构呢？
让我们想想.NET的特性和需求是什么，就可以推知什么组件架构最适合在.NET平台下
成为企业级的组件架构了。
什么组件架构已经使用过很长的一段时间，且经过了市场的验证呢？
→ CORBA、EJB和COM+
什么组件架构可以跨平台？
→ CORBA和EJB
什么组件架构允许多种语言开发和使用？
→ CORBA
从上面的问题中，我们已经看到答案是呼之欲出了。更关键的是上面的第3个问题。
由于.NET是一个语言中立的平台，程序员可以使用任何语言来开发.NET应用程序，因
此在.NET平台的组件架构必须能够让各种不同的程序语言来开发和使用，而不像EJB
一样只能使用Java语言。对比一下，CORBA正好符合语言中立的要求。此外CORBA是一
个跨平台的组件架构，可以随着.NET移植到各种平台。因此从各方面来看，CORBA实
在非常适合使用在.NET之中并成为.NET的核心组件架构。
CORBA和EJB
CORBA已经在企业应用系统使用了很长时间，是一个架构成熟、经过了市场严格考验
的组件技术。在CORBA之后的许多组件架构其实也都学习了CORBA。例如J2EE中的EJB
规格可以使用CORBA来实现，在EJB 2.0之后也要求EJB服务器必须和CORBA兼容，由此
可见CORBA组件架构的重要性和成熟性。目前，CORBA仍然是一个在持续发展中的组件
规格，OMG也持续为CORBA定义更为完整的核心和服务规格。
CORBA使用的Stub/Proxy以及组件服务架构深深地影响了COM+和EJB的实现架构，以致
COM+和EJB组件架构和CORBA都有许多神似的地方。
由于CORBA几乎是其他组件架构的始祖，因此CORBA绝对有能力、有份量和EJB分庭抗
礼。如果.NET能够在其平台上以CORBA作为核心组件架构，那么.NET就可以提供同J2EE
一样好的企业应用架构。虽然许多人会质疑在PC上执行企业应用系统会不会力量不够？
但是，随着64位的CPU(Intel和AMD)即将推出，Microsoft也准备推出64位的操作系统。
在.NET虚拟执行环境的保护下，如果再加上安全强固的CORBA，那么.NET的确可以提供
相当有竞争力的企业执行平台，与J2EE在中/低阶的企业应用中竞争。如此一来，
Java/J2EE就不再拥有企业应用中的绝对优势了。
既然CORBA对于Microsoft .NET平台的企业运算有这么大的助力，那么CORBA组件架构
在.NET平台上将以什么样的架构来提供服务呢？
CORBA For .NET
CORBA要如何在.NET平台上提供企业级的服务呢？由于CORBA使用IIOP通讯协议作为调
用CORBA服务的接口，因此传统的CORBA引擎(例如Borland的VisiBroker)，应该会为
CORBA伺服端和客户端产生可连接的DLL或是函数库，这些DLL和函数库就负责让客户
端通过IIOP调用伺服端的CORBA服务器。因此CORBA即使是执行在.NET平台中，也是使
用IIOP作为调用的通讯协议，如右图所示。
不过，在.NET下Microsoft是使用.NET Remoting机制作为远程和分布式沟通的通讯协
议。那么，.NET的CORBA开发工具要如何结合.NET的Remoting机制、并且允许.NET下
各种不同的语言通过IIOP调用远程的CORBA服务呢？
其实，这同在Windows下提供原生窗口开发工具开发CORBA应用系统几乎是一样的，只
是在.NET下CORBA引擎必须进行一些额外的工作以让.NET的开发工具和应用程序能够
使用CORBA技术。
首先，.NET下的CORBA开发工具必须能够提供.NET下主流程序语言的支持，这代表CORBA
For .NET必须为每一种程序语言产生客户端的CORBA.NET Stub和伺服端的CORBA.NET
Proxy。其次，为了和.NET Remoting机制结合在一起并提供IIOP的能力，CORBA For
.NET必须产生一个Adapter和.NET RemotJng作为沟通的机制，.NET Remoting通过这
个Adapter再调用最底层的CORBA For .NET引擎，CORBA For .NET引擎再把.NET
Remoting
的调用惯例转换为IIOP通讯协议。经由Adapter和CORBA For .NET引擎的转换之后，
就可以调用远程的CORBA服务和CORBA服务器，甚至通过RMI Over IIOP调用到远程的
EJB服务器，如下所示：
上面说明的架构还是比较详细的。由于在.NET下各种程序语言都会被.NET的编译器转
换为.NET的IL，因此CORBA For .NET工具可以产生一个IL型态的客户端CORBA.NET Stub
。
如此一来，不管程序员使用的程序语言是什么，都可以保证能够通过这个CORBA.NET
Stub来调用远程的CORBA服务。这个架构其实比以前Windows下的CORBA开发工具更容
易，因为在Windows下，CORBA厂商还必须为不同的程序语言产生不同程序语言的客户
端CORBA Stubs。现在.NET下CORBA厂商反而因为.NET几的特性而更轻松和一致了。
一旦CORBA厂商能够在.NET下实现CORBA For .NET，那么不但可以让.NET的程序员开
发真正企业级的.NET应用系统，更由于CORBA和EJB是兼容的，因此.NET下的CORBA服
务器也能够通过RMI Over IIOP调用和整合EJB服务器，提供.NET和J2EE无缝整合的能
力，并且允许使用者的应用系统能够从.NET平台顺利地移转到J2EE平台，如下所示。
更何况，现在许多的EJB服务器还能够像管理EJB对象一样地管理CORBA对象，这意味
着执行在Mainframe或是UNIX/Linux的EJB服务器能够管理和整合执行在.NET中的CORBA
对象或是CORBA服务。.NET有了CORBA这个解决方案之后，终于有了进入可提供企业级
应用程序架构的能力了。
巨人终将对决？
CORBA的复杂度使其一直未能被广大的程序员所接受，现在的CORBA本身已经非常安全
强固，而且经过了十几年企业市场的考验(即使是EJB也不过在企业市场才经历了2个
版本的洗礼)，CORBA的开发厂商应该已经清楚，CORBA不被大多数开发人员接受的原
因并不是CORBA不够好，而是CORBA太复杂。因此这些开发厂商应该舍弃CORBA中鲜为
理服务(Transaction Service)和安全服务(Security Service)。更进一步的是，如
果CORBA厂商能够在客户端提供.NET的组件来封装比较复杂的CORBA调用和存取机制，
并且结合数据存取的能力，那么，.NET下的程序员将能够以非常快的速度学习和使用
CORBA组件架构。如此一来，CORBA将有机会在.NET平台中大展身手，有机会成为.NET
平台中最有潜力的组件架构，也将有机会让CORBA一吐闷气，让世人了解CORBA的价值。
"EJB和CORBA两大巨人终将对决"？不，更正确的说法应该是J2EE/EJB终于找到了可敬
的对手--.NET/CORBA，而CORBA和EJB也将进入"既竞争又合作"的时代，当然前提是有
厂商推出CORBA For .NET的软件产品。
什么是.NET？我们可以从各种技术角度探讨.NET，NET的技术书籍也可以撰写成几十
本、甚至是上百本。但是Microsoft提倡.NET，最重要的目的是提供一个足以和Java
平台对抗的"企业平台"(Enterprise Platform)。Microsoft希望企业能够使用.NET作
为企业应用系统的核心平台，根据这个企业核心平台再开发各种应用系统，连接新式
的移动设备(Mobile Device)，形成企业应用系统需要的完整信息供应链，提供类似
目前Java拥有的企业业务。Microsoft希望通过.NET打入企业市场的企图是不言而喻
的。
为什么Microsoft急于打入企业市场呢？主要因为企业市场是获利最为丰富的市场，
也是Microsoft长久以来最想进入的市场。另外，Microsoft不希望Java独占企业市场、
进而产生对Microsoft的威胁，这是第二个关键因素。其次更重要的原因是，Microsoft
在客户端几乎已达饱和，继续成长的空间有限，需要另外能够持续成长的市场，而企
业市场、消费端市场、通讯市场以及游戏市场就是Microsoft注重的目标了。
Microsoft要想打入企业市场，需要面对的是表现愈来愈好的J2EE架构。目前J2EE已
经被愈来愈多的大型企业用作企业核心的信息技术。根据Gartner Group的调查，EJB
的架构将逐年增加，到了2003年将会拥有超过40％的使用率。这代表EJB将成为企业
应用系统的核心组件架构，更多的企业系统将使用J2EE来建制。
这些现象在大型的信息业界反映得非常真实和明显，例如台湾的台积电(TSMC)、联电
(UMC)和友达光电等都已经在使用Java和J2EE作为新一代信息系统开发的核心技术。
再看看目前EJB服务器的两大领导厂商产品--BEA的WebLogic以及IBM的WebSphere。
WebLogic和WebSphere除了已经成为许多企业的核心J2EE服务器、提供企业开发应用
系统的基石之外，还慢慢形成了企业应用系统的解决方案中心，并从其中衍生出许多
新的软件需求和应用。例如许多的Portal系统、ERP、CRM或Web Service应用都围绕
在这两个J2EE服务器的外部进行增值的应用。这种现象已经开始形成非常巨大的力量，
让EJB服务器的竞争从EJB核心服务器演变到EJB解决方案的地步，宛如一个黑洞在不断
地吸引新的应用和力量进入、使用这个架构。这种软件群聚的效应正是企业级信息技
术应该形成的现象，因为唯有如此，才能够让影响力不断扩大。当初Microsoft的
Windows就是这样，吸引了全世界程序员为Windows开发应用软件，以Microsoft Windows
为应用的核心，这才造就了Windows成为全世界客户端操作系统的霸主。
由此可见，一个核心软件技术对于信息应用的重要性。当初Microsoft在Windows上力
推COM/COM+组件模型，希望它们成为Windows上的核心组件技术，提供企业在Windows
平台上开发企业应用系统的解决方案。其实以效率来说，COM+的确是不错的。根据许
多的测试以及TPCC上公布的结果来看，COM+的执行效率几乎是最好的。而前段时间The
ServerSide上公布的EJB对COM+的评比更是闹得满城风雨。Java业界仍然不肯承认COM+
比EJB来得有效率，但是以目前的数据来看，在Windows上EJB的确远远比不上COM+。
在Microsoft多年的推展之后，COM/COM+的确也有了不错的使用结果。根据2002年北
美关于COM+的信息调查显示，使用COM+技术的人占了34.3％，而且还有9％的人回答
将会采用COM+。虽然COM+在执行效率方面表现很好，但不可否认的是COM+只能在Windows
平台使用，而且在Internet应用中使用不便，延展性也不若EJB，这都是COM+致命的
缺点。
.NET核心组件技术
既然Microsoft希望.NET成为企业应用的平台，那.NET需要提供什么呢？除了开发工
具之外，.NET最重要的便是提供一个类似J2EE架构的软件解决方案，以吸引软件人员
为.NET开发企业级的应用系统，帮助.NET打入企业市场和Java平台竞争。
那现在的.NET中有什么类似J2EE架构的技术呢？从下图我们可以清楚地看到，Microsoft
在.NET中正逐渐建立起同SUN Java平台竞争的技术核心。Microsoft和SUN的虚拟竞争
平台现在几乎非常类似，不过，目前的Java在组件技术的领域远远超过了Microsoft
提供的解决方案。
Microsoft在.NET中的组件技术是以.NET组件配合COM+为主。COM+在.NET中转为操作
系统的核心服务，提供事务管理(Transaction Management)的功能，而.NET组件则可
以同时扮演.NET中的可视化组件(Visual Component)、数据感知组件(Data-Aware
Component)以及中间件(Middleware Component)。然而使用.NET组件作为.NET平台中
间件有许多问题。首先是.NET组件必须依靠COM+组件提供分布式事务管理能力；另外，
.NET组件目前也没有像EJB一样的Fail-Over和Load-Balancing能力，这在企业级的应用
中是明显不足的。
此外，.NET组件必须和COM+一起搭配使用，这意味着程序员必须开发COM+组件，而.
NET的原生工具无法开发COM+组件，程序员还是必须使用原生的Windows开发工具。此
外，一旦使用了COM+，代表此.NET应用系统无法移植到其他的平台。如果Microsoft
把.NET移植到Linux或是FreeBSD上，那使用COM+组件的.NET应用系统将无法移植到这
些平台之中。
那么，Microsoft是不是需要一个新的、能在.NET平台使用的组件架构呢？就我的眼
光来看，如果Microsoft希望把.NET平台定位在企业系统同J2EE竞争，那的确是需要
这种技术，但这对于Microsoft是有一点困难的。首先，Microsoft正忙于在一二年内
达到Java平台花了七八年的成果，正忙于开发.NET本身、.NET开发工具、.NET下的数
据库，并且把所有的Microsoft Server应用程序移植到.NET之下，可能一时无法投入
太多的资源来开发一个全新的企业级的组件架构。
另外，再看看Microsoft建立组件架构的历史就可以了解到，在这方面Microsoft的确
不太在行。期望Microsoft在短时间内在.NET平台定义类似EJB的企业组件架构的规格
并且将其实现出来，似乎是不太容易的事情。
组件技术 结果
16位VBX 失败
32位VBX 失败
OLE 失败
COM 尚可
ActiveX 失败
MTS 失败
COM+ 不错
.NET组件 不适合使用在企业级应用中
既然新创.NET下的企业组件架构不是短时间内可以完成的，那是不是代表着.NET在这
方面已经无法和J2EE竞争而提早出局呢？其实并不一定，因为如果无法快速开发一个
新的组件架构，那为什么不使用已经存在且已经验证是适合企业应用的组件架构呢？
让我们想想.NET的特性和需求是什么，就可以推知什么组件架构最适合在.NET平台下
成为企业级的组件架构了。
什么组件架构已经使用过很长的一段时间，且经过了市场的验证呢？
→ CORBA、EJB和COM+
什么组件架构可以跨平台？
→ CORBA和EJB
什么组件架构允许多种语言开发和使用？
→ CORBA
从上面的问题中，我们已经看到答案是呼之欲出了。更关键的是上面的第3个问题。
由于.NET是一个语言中立的平台，程序员可以使用任何语言来开发.NET应用程序，因
此在.NET平台的组件架构必须能够让各种不同的程序语言来开发和使用，而不像EJB
一样只能使用Java语言。对比一下，CORBA正好符合语言中立的要求。此外CORBA是一
个跨平台的组件架构，可以随着.NET移植到各种平台。因此从各方面来看，CORBA实
在非常适合使用在.NET之中并成为.NET的核心组件架构。
CORBA和EJB
CORBA已经在企业应用系统使用了很长时间，是一个架构成熟、经过了市场严格考验
的组件技术。在CORBA之后的许多组件架构其实也都学习了CORBA。例如J2EE中的EJB
规格可以使用CORBA来实现，在EJB 2.0之后也要求EJB服务器必须和CORBA兼容，由此
可见CORBA组件架构的重要性和成熟性。目前，CORBA仍然是一个在持续发展中的组件
规格，OMG也持续为CORBA定义更为完整的核心和服务规格。
CORBA使用的Stub/Proxy以及组件服务架构深深地影响了COM+和EJB的实现架构，以致
COM+和EJB组件架构和CORBA都有许多神似的地方。
由于CORBA几乎是其他组件架构的始祖，因此CORBA绝对有能力、有份量和EJB分庭抗
礼。如果.NET能够在其平台上以CORBA作为核心组件架构，那么.NET就可以提供同J2EE
一样好的企业应用架构。虽然许多人会质疑在PC上执行企业应用系统会不会力量不够？
但是，随着64位的CPU(Intel和AMD)即将推出，Microsoft也准备推出64位的操作系统。
在.NET虚拟执行环境的保护下，如果再加上安全强固的CORBA，那么.NET的确可以提供
相当有竞争力的企业执行平台，与J2EE在中/低阶的企业应用中竞争。如此一来，
Java/J2EE就不再拥有企业应用中的绝对优势了。
既然CORBA对于Microsoft .NET平台的企业运算有这么大的助力，那么CORBA组件架构
在.NET平台上将以什么样的架构来提供服务呢？
CORBA For .NET
CORBA要如何在.NET平台上提供企业级的服务呢？由于CORBA使用IIOP通讯协议作为调
用CORBA服务的接口，因此传统的CORBA引擎(例如Borland的VisiBroker)，应该会为
CORBA伺服端和客户端产生可连接的DLL或是函数库，这些DLL和函数库就负责让客户
端通过IIOP调用伺服端的CORBA服务器。因此CORBA即使是执行在.NET平台中，也是使
用IIOP作为调用的通讯协议，如右图所示。
不过，在.NET下Microsoft是使用.NET Remoting机制作为远程和分布式沟通的通讯协
议。那么，.NET的CORBA开发工具要如何结合.NET的Remoting机制、并且允许.NET下
各种不同的语言通过IIOP调用远程的CORBA服务呢？
其实，这同在Windows下提供原生窗口开发工具开发CORBA应用系统几乎是一样的，只
是在.NET下CORBA引擎必须进行一些额外的工作以让.NET的开发工具和应用程序能够
使用CORBA技术。
首先，.NET下的CORBA开发工具必须能够提供.NET下主流程序语言的支持，这代表CORBA
For .NET必须为每一种程序语言产生客户端的CORBA.NET Stub和伺服端的CORBA.NET
Proxy。其次，为了和.NET Remoting机制结合在一起并提供IIOP的能力，CORBA For
.NET必须产生一个Adapter和.NET RemotJng作为沟通的机制，.NET Remoting通过这
个Adapter再调用最底层的CORBA For .NET引擎，CORBA For .NET引擎再把.NET
Remoting
的调用惯例转换为IIOP通讯协议。经由Adapter和CORBA For .NET引擎的转换之后，
就可以调用远程的CORBA服务和CORBA服务器，甚至通过RMI Over IIOP调用到远程的
EJB服务器，如下所示：
上面说明的架构还是比较详细的。由于在.NET下各种程序语言都会被.NET的编译器转
换为.NET的IL，因此CORBA For .NET工具可以产生一个IL型态的客户端CORBA.NET Stub
。
如此一来，不管程序员使用的程序语言是什么，都可以保证能够通过这个CORBA.NET
Stub来调用远程的CORBA服务。这个架构其实比以前Windows下的CORBA开发工具更容
易，因为在Windows下，CORBA厂商还必须为不同的程序语言产生不同程序语言的客户
端CORBA Stubs。现在.NET下CORBA厂商反而因为.NET几的特性而更轻松和一致了。
一旦CORBA厂商能够在.NET下实现CORBA For .NET，那么不但可以让.NET的程序员开
发真正企业级的.NET应用系统，更由于CORBA和EJB是兼容的，因此.NET下的CORBA服
务器也能够通过RMI Over IIOP调用和整合EJB服务器，提供.NET和J2EE无缝整合的能
力，并且允许使用者的应用系统能够从.NET平台顺利地移转到J2EE平台，如下所示。
更何况，现在许多的EJB服务器还能够像管理EJB对象一样地管理CORBA对象，这意味
着执行在Mainframe或是UNIX/Linux的EJB服务器能够管理和整合执行在.NET中的CORBA
对象或是CORBA服务。.NET有了CORBA这个解决方案之后，终于有了进入可提供企业级
应用程序架构的能力了。
巨人终将对决？
CORBA的复杂度使其一直未能被广大的程序员所接受，现在的CORBA本身已经非常安全
强固，而且经过了十几年企业市场的考验(即使是EJB也不过在企业市场才经历了2个
版本的洗礼)，CORBA的开发厂商应该已经清楚，CORBA不被大多数开发人员接受的原
因并不是CORBA不够好，而是CORBA太复杂。因此这些开发厂商应该舍弃CORBA中鲜为
理服务(Transaction Service)和安全服务(Security Service)。更进一步的是，如
果CORBA厂商能够在客户端提供.NET的组件来封装比较复杂的CORBA调用和存取机制，
并且结合数据存取的能力，那么，.NET下的程序员将能够以非常快的速度学习和使用
CORBA组件架构。如此一来，CORBA将有机会在.NET平台中大展身手，有机会成为.NET
平台中最有潜力的组件架构，也将有机会让CORBA一吐闷气，让世人了解CORBA的价值。
"EJB和CORBA两大巨人终将对决"？不，更正确的说法应该是J2EE/EJB终于找到了可敬
的对手--.NET/CORBA，而CORBA和EJB也将进入"既竞争又合作"的时代，当然前提是有
厂商推出CORBA For .NET的软件产品。
1677
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
