第十一章 EJB对抗CORBA？有趣的假设"组件模型的两大巨头终将对决？"什么是.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和EJBCORBA已经在企业应用系统使用了很长时间，是一个架构成熟、经过了市场严格考验的组件技术。在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 .NETCORBA要如何在.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中鲜为人用的服务，先提供一个完整的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的软件产品。
