既然新创下的企业组件架构不是短时间内可以完成的，那是不是代表着在这
方面已经无法和J2EE竞争而提早出局呢？其实并不一定，因为如果无法快速开发一个
新的组件架构，那为什么不使用已经存在且已经验证是适合企业应用的组件架构呢？
让我们想想的特性和需求是什么，就可以推知什么组件架构最适合在平台下
成为企业级的组件架构了。
什么组件架构已经使用过很长的一段时间，且经过了市场的验证呢？
→ CORBA、EJB和＋
什么组件架构可以跨平台？
→ CORBA和EJB
什么组件架构允许多种语言开发和使用？
→ CORBA
从上面的问题中，我们已经看到答案是呼之欲出了。更关键的是上面的第3个问题。
由于是一个语言中立的平台，程序员可以使用任何语言来开发应用程序，因
此在平台的组件架构必须能够让各种不同的程序语言来开发和使用，而不像EJB
一样只能使用Java语言。对比一下，CORBA正好符合语言中立的要求。此外CORBA是一
个跨平台的组件架构，可以随着移植到各种平台。因此从各方面来看，CORBA实
在非常适合使用在之中并成为的核心组件架构。
CORBA和EJB
CORBA已经在企业应用系统使用了很长时间，是一个架构成熟、经过了市场严格考验
的组件技术。在CORBA之后的许多组件架构其实也都学习了CORBA。例如J2EE中的EJB
规格可以使用CORBA来实现，在EJB 2。0之后也要求EJB服务器必须和CORBA兼容，由此
可见CORBA组件架构的重要性和成熟性。目前，CORBA仍然是一个在持续发展中的组件
规格，OMG也持续为CORBA定义更为完整的核心和服务规格。
CORBA使用的Stub/Proxy以及组件服务架构深深地影响了＋和EJB的实现架构，以致
＋和EJB组件架构和CORBA都有许多神似的地方。
由于CORBA几乎是其他组件架构的始祖，因此CORBA绝对有能力、有份量和EJB分庭抗
礼。如果能够在其平台上以CORBA作为核心组件架构，那么就可以提供同J2EE
一样好的企业应用架构。虽然许多人会质疑在PC上执行企业应用系统会不会力量不够？
但是，随着64位的CPU（Intel和AMD）即将推出，Microsoft也准备推出64位的操作系统。
在虚拟执行环境的保护下，如果再加上安全强固的CORBA，那么的确可以提供
相当有竞争力的企业执行平台，与J2EE在中/低阶的企业应用中竞争。如此一来，
Java/J2EE就不再拥有企业应用中的绝对优势了。
既然CORBA对于Microsoft 平台的企业运算有这么大的助力，那么CORBA组件架构
在平台上将以什么样的架构来提供服务呢？
CORBA For
CORBA要如何在平台上提供企业级的服务呢？由于CORBA使用IIOP通讯协议作为调
用CORBA服务的接口，因此传统的CORBA引擎（例如Borland的VisiBroker），应该会为
CORBA伺服端和客户端产生可连接的DLL或是函数库，这些DLL和函数库就负责让客户
端通过IIOP调用伺服端的CORBA服务器。因此CORBA即使是执行在平台中，也是使
用IIOP作为调用的通讯协议，如右图所示。
不过，在下Microsoft是使用 Remoting机制作为远程和分布式沟通的通讯协
议。那么，的CORBA开发工具要如何结合的Remoting机制、并且允许下
各种不同的语言通过IIOP调用远程的CORBA服务呢？
其实，这同在Windows下提供原生窗口开发工具开发CORBA应用系统几乎是一样的，只
是在下CORBA引擎必须进行一些额外的工作以让的开发工具和应用程序能够
使用CORBA技术。
首先，下的CORBA开发工具必须能够提供下主流程序语言的支持，这代表CORBA
For 必须为每一种程序语言产生客户端的CORBA Stub和伺服端的CORBA
Proxy。其次，为了和 Remoting机制结合在一起并提供IIOP的能力，CORBA For
必须产生一个Adapter和 RemotJng作为沟通的机制， Remoting通过这
个Adapter再调用最底层的CORBA For 引擎，CORBA For 引擎再把 Remoting
的调用惯例转换为IIOP通讯协议。经由Adapter和CORBA For 引擎的转换之后，
就可以调用远程的CORBA服务和CORBA服务器，甚至通过RMI Over IIOP调用到远程的
EJB服务器，如下所示：
上面说明的架构还是比较详细的。由于在下各种程序语言都会被的编译器转
换为的IL，因此CORBA For 工具可以产生一个IL型态的客户端CORBA Stub。
如此一来，不管程序员使用的程序语言是什么，都可以保证能够通过这个CORBA
Stub来调用远程的CORBA服务。这个架构其实比以前Windows下的CORBA开发工具更容
易，因为在Windows下，CORBA厂商还必须为不同的程序语言产生不同程序语言的客户
端CORBA Stubs。现在下CORBA厂商反而因为几的特性而更轻松和一致了。
一旦CORBA厂商能够在下实现CORBA For ，那么不但可以让的程序员开
发真正企业级的应用系统，更由于CORBA和EJB是兼容的，因此下的CORBA服
务器也能够通过RMI Over IIOP调用和整合EJB服务器，提供和J2EE无缝整合的能
力，并且允许使用者的应用系统能够从平台顺利地移转到J2EE平台，如下所示。
更何况，现在许多的EJB服务器还能够像管理EJB对象一样地管理CORBA对象，这意味
着执行在Mainframe或是UNIX/Linux的EJB服务器能够管理和整合执行在中的CORBA
对象或是CORBA服务。有了CORBA这个解决方案之后，终于有了进入可提供企业级
应用程序架构的能力了。
巨人终将对决？
CORBA的复杂度使其一直未能被广大的程序员所接受，现在的CORBA本身已经非常安全
强固，而且经过了十几年企业市场的考验（即使是EJB也不过在企业市场才经历了2个
版本的洗礼），CORBA的开发厂商应该已经清楚，CORBA不被大多数开发人员接受的原
因并不是CORBA不够好，而是CORBA太复杂。因此这些开发厂商应该舍弃CORBA中鲜为
人用的服务，先提供一个完整的CORBA引擎以及企业应用最重要的两个服务事务管
理服务（Transaction Service）和安全服务（Security Service）。更进一步的是，如
果CORBA厂商能够在客户端提供的组件来封装比较复杂的CORBA调用和存取机制，
并且结合数据存取的能力，那么，下的程序员将能够以非常快的速度学习和使用
CORBA组件架构。如此一来，CORBA将有机会在平台中大展身手，有机会成为
平台中最有潜力的组件架构，也将有机会让CORBA一吐闷气，让世人了解CORBA的价值。
〃EJB和CORBA两大巨人终将对决〃？不，更正确的说法应该是J2EE/EJB终于找到了可敬
的对手/CORBA，而CORBA和EJB也将进入〃既竞争又合作〃的时代，当然前提是有
厂商推出CORBA For 的软件产品。
^v^v^v^v^v^v^v^v^v
第十二章 回到C/C＋＋的王国
〃让我们重返荣耀之都吧！〃
当年Windows平台C/C＋＋开发工具四大天王一战，在Microsoft取得了市场的主导力量
之后，C/C＋＋开发工具的市场和竞争反而缓慢了下来，Windows上C/C＋＋开发工具的进
步也开始牛步化。VC＋＋一连两三个版本的进度幅度并不大，除了稍后推出的ATL还有
新意和技术革新，VC＋＋编译器除了在C/C＋＋语言上更趋近于标准之外，MFC本身几乎已
经没有什么大的进步了。在Wat和Symantec退出市场之后，VC＋＋也顺利地接受了
Wat和Symantec的市场。而Borland C/C＋＋虽然也损失了大量的市场，并且失去了
C/C＋＋的王座，但是在数年后，Borland推出C/C＋＋Builder，以C/C＋＋ RAD工具、以及
更符合ANSI C/C＋＋标准和VC＋＋进行市场的区隔，也慢慢地收复了一些失地。虽然
Borland C/C＋＋工具系列已经无法像以前一样是市场第一的C/C＋＋开发工具，但是
Borland在Windows的C/C＋＋开发工具市场仍然占有30％强的市场份额。
C/C＋＋开发工具在C/C＋＋ Framework一战之后，开发的重点却似乎模糊了起来。由于VC
＋＋没有强劲的竞争，因此整个的发展速度缓慢下来。不过C/C＋＋技术在C/C＋＋语言、函
数库（Library）和通用Framework方面却快速地如雨后春笋般兴起。特别是在C/C＋＋语
言的标准化更为完善、以及Template的功能被C＋＋ Standards mittee接受而且被
广泛地由C/C＋＋编译器支持之后，各种支持和使用Template的Framework、C/C＋＋函数
库也快速地占据了C/C＋＋开发者的心灵，成为有力的程序技巧之一。在Java日益兴盛、
开始威胁C/C＋＋的市场时，反而激发了C/C＋＋语言前所未有的高度发展。不过，目前
C/C＋＋开发工具以及C/C＋＋编译器是否跟上了C/C＋＋这么快速的发展脚步呢？在本章继
续讨论之前，也许应该让我们先看看目前C/C＋＋市场的现况。
日不落帝国
曾几何时，C/C＋＋是征服全世界的语言之一。在数年前C/C＋＋语言全盛的时期，我记得
几乎所有的应用系统都选择使用C/C＋＋来编写，如从系统程序、公用程序、软件包到
项目开发，因此也造就了C/C＋＋开发工具横扫软件销售市场的现象。但是随着RAD工具
和Java的逐渐受欢迎，让C/C＋＋开始从许多的市场撤退。特别是当Java兴起之后便快
速取代了以往C/C＋＋在跨平台语言的主导角色，让C/C＋＋语言在这个市场受到Java最大
的威胁。不过，C/C＋＋仍然在许多方面的应用不可否认地具有绝对的优势，特别是在
需要高度执行效率的应用系统中，例如驱动程序和低阶的系统程序等。那么C/C＋＋目
前的市场到底有多少？有没有像两、三年前许多信息机构预测的那样，Java将会大幅
抢走C/C＋＋的市场、并且吸引大量的C/C＋＋程序员呢？让我们以实际的数据来看看目前
的状态。
右图是全世界专业信息机构对于C/C＋＋开发工具市场规模和使用状况的调查结果。从
这个结果图形中我们可以得知几个非常重要的C/C＋＋信息：
首先请读者注意的是，就整体来说C/C＋＋开发工具的市场的确是处于小幅的下降趋势
之中，根据Gartner Group的调查，C/C＋＋市场是以5％的幅度下降，而根据Evans Data
Survey的调查，C/C＋＋市场则是以3％的幅度下降。不过稍后我们会说明，C/C＋＋开发
工具是在哪些平台和应用中产生变化。
另外一个值得注意的地方，是C/C＋＋语言主要是用于三个应用领域之中，分别是客户
端、伺服端和维护现有的应用程序。从图中我们也可以发现C/C＋＋语言被使用的转变
状态，在工业应用方面，C/C＋＋开发工具仍然有很大的成长，这当然是因为C/C＋＋语言
被广泛用于驱动程序的开发，例如显示卡驱动程序、网卡驱动程序等。此外C/C＋＋语
言也被用于移动设备的开发，例如Nokia为了和Microsoft的Smart Phone对抗而推出
的Symbian手机系统。当然，在操作系统、系统程序和低阶核心应用方面C/C＋＋语言仍
然有着不可取代的地位。
但是，C/C＋＋在其他方面的应用的确是在下降之中，特别是在企业的应用系统方面。
例如目前在大型项目、软件包、MIS和企业内部的应用系统中，使用C/C＋＋语言的比例
的确在下降。其中主要的原因是C/C＋＋语言本身的难度较高，因此生产力也不如其他
语言和开发工具。加上较易使用的RAD工具和Java出现之后，C/C＋＋语言在这些领域的
影响力是大不如前的。这个现象也非常契合台湾地区目前的状况，在前几年C/C＋＋兴
盛的阶段，几乎大部分的软件包厂商和SI以及系统厂商的确都是以C/C＋＋开发工具为
第一选择。不过由于C/C＋＋需要的人力素质较高，而且生产力无法大幅提高，因此在
目前软件包和项目的开发大多都由Delphi、VB、PowerBuilder以及Java所瓜分。
至于C/C＋＋开发工具使用的操作系统分配状况，则可以由右面的调查结果来说明。
从图中我们可以发现，UNIX/Linux操作系统平台仍然是占了最大的使用平台，这当然
是由于UNIX/Lmux本身就是使用C/C＋＋语言开发的。而且在UNIX/Linux平台我们可以发
现，C/C＋＋开发工具的规模仍然在成长，可达成10％左右的年成长幅度。由此可知，
虽然Java现在已经入侵UNIX/Linux平台，但是对于C/C＋＋的影响仍然不太显著。
C/C＋＋开发工具第二个最大的�