从右边图形和数字，我们可以了解在大陆使用C/C＋＋语言的人数实在是众多，而Java
已经超过了Visual Basic。不过未来的发展情形则更令人好奇，因为在全世界的C/C＋＋
都开始逐渐走下坡之际，C/C＋＋在大陆的市场会不会也发生类似的现象呢？Visual Basic
和PowerBuilder会不会持续下滑？Java何时会成为霸主？C#又何时会迎头赶上？这些
问题都非常值得观察，因为这不但影响了各程序语言之间势力的消长，也代表着软件
工作市场的需求和变化。
有趣的是，在Windows和平台上，程序语言正以前所未有的生气蓬勃发展，而且
不同的程序语言间互相激荡、相互影响，再产生新的程序语言或是在原有的程序语言
中加入新的机制以符合新的需求。但是在Java平台，却几乎只有Java语言，没有其他
的选择。那么读者是喜欢单一程序语言的单纯，还是喜欢多种语言产生的灿烂火花呢？
我个人是比较喜欢多种语言的，因为我认为，我们可以通过欣赏不同程序语言的设计
精神和思想来吸收更多的知识和技术，通过不同程序语言彼此竞争的结果，可以嗅出
未来程序语言的发展方向，这大概也是因为我从大学时就特别喜欢程序语言和编译器
课程的结果吧。
知己知彼，百战百胜
就让我们以EJB服务器市场这个实际的竞争范例来看看信息产业是如何竞争和演化的
吧。三四年前，当EJB市场开始成长时，许多软件厂商相继投入这个潜力十足的市场。
当时，所有EJB厂商竞争的基准大概都是符合EJB规范、使用最新JDK标准以及执行效
率最良好的EJB服务器。当时竞争的EJB服务器可以用满山满谷来形容，为什么呢？因
为在这个阶段纯粹是以技术为决胜点，这个门槛并不高，拥有技术的软件人才多得是。
因此，这个阶段中有眼光和智慧的厂商便了解到，光凭EJB服务器引擎是无法作为胜
出的要件的，必须想办法增加竞争门槛以阻绝竞争对手持续逼近，或是增加〃软件服
务〃以提供竞争对手没有的功能。
到了EJB服务器竞争的第2阶段，逐渐胜出的EJB厂商便开始为EJB服务器加入各种服务，
其中一类是以增加商业应用服务为主，例如Portal Service、ERP Service等。而另
外一类则是以技术服务为主，例如分布式交易服务、安全服务等。由于这些软件服务
的加入，在EJB服务器竞争的第2阶段便逐渐产生了EJB服务器的领先群，许多其他的
EJB服务器厂商在眼看竞争无望之下自然地退出了市场，HP就是一个例子。
现在EJB服务器市场又进入了最后厮杀的阶段，因为在领先群中的厂商大都提供了类
似的服务。那么接下来要如何竞争呢？IBM很快就看到了关键点，那就是为WebSphere
加入整合开发平台的能力。通过并购Rational取得Modeling工具和技术，IBM可结合
原有的Java开发工具为WebSphere形成一个关键开发平台，同时吸引企业使用者以及
开发人员为WebSphere形成的企业平台开发更多的客制化服务，以便为WebSphere形成
势力强大的专属力量。这是WebSphere最大竞争对手WebLogic目前没有的优势。
从EJB服务器竞争的过程来看，致胜的关键便是软件人员是否能够看到别人看不到的
优势、并提供额外的服务。对于软件人员的发展，道理也是同样。大部分的软件人员
都只注重在特定的开发工具或是程序语言中精进，但似乎都是随着别人的脚步而前进，
少数软件精英除了在信息技术领域有高人一等的修为外，真正胜出的却是能够为自己
增加附加价值、提供创造力的能力。就像JBuilder的Chief ScientistBlake Stone，
为什么他能够在年纪轻轻的情形下成为领导者？许多资历、年纪都比Blake Stone
多的研发人员反而只能当工程师呢？很简单，因为Blake Stone更早地看到了JBuilder
的发展趋势和竞争策略，掌握了Java开发工具发展的动脉，能够为JBuilder开发团队
提供更多的价值，再加上坚强的技术实力，终于成为家喻户晓的Java天才。
我一直认为任何软件技术终将被大众所熟知和掌握，就像数年前的主从架构一样，因
此光凭借技术并不能让人领先多久。反而是通过平日不断培养的眼光和趋势、再加上
专业的技术才能够让软件人员保持在领先群中，并且掌握软件趋势的动脉。拥有这种
特质的软件人员能够不时的提供服务，不时地为团队提供持续的创新力，自然也就能
够百战百胜了。
结论
人类对于新事物的害怕，通常都是由于对新事物的无知所引起。同样，软件人员对于
未来的困惑和焦虑则来自不知如何是好，这也是对于未来趋势发展的无知所引起。本
节中，我们通过分析、观察和统计了解了以往、现在和未来软件趋势的发展，当事实
的走向豁然开朗之后，困惑和焦虑不再重要，软件人员反而应该反躬自省地自问：面
对未来，我们准备好了没有？
不管Java和两大平台之间的战争如何，不管哪一个软件组件或是程序语言会获得
最后的胜利，世界对于软件系统快速开发的要求不会因为那一方胜出而改变，软件人
员必须准备好面对这个趋势。想想，JBuilder以每半年一个新版本出现，Java JDK和
也几乎以1年半之间推出两个版本的速度在彼此争战之中，连传统的开发工具现
在也几乎以一年一个版本的速度出现。更夸张的是，Internet/Intranet的技术现在
几乎每3个月就有一番新的面貌，开发人员应该如何自处呢？
机会可能会降临在每一个人的身上，但是只有时时准备好的人才能够把握住机会，不
让它从手缝中溜走。
^v^v^v^v^v^v^v^v^v
第十一章 EJB对抗CORBA？有趣的假设
〃组件模型的两大巨头终将对决？〃
什么是？我们可以从各种技术角度探讨，NET的技术书籍也可以撰写成几十
本、甚至是上百本。但是Microsoft提倡，最重要的目的是提供一个足以和Java
平台对抗的〃企业平台〃（Enterprise Platform）。Microsoft希望企业能够使用作
为企业应用系统的核心平台，根据这个企业核心平台再开发各种应用系统，连接新式
的移动设备（Mobile Device），形成企业应用系统需要的完整信息供应链，提供类似
目前Java拥有的企业业务。Microsoft希望通过打入企业市场的企图是不言而喻
的。
为什么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上力
推/＋组件模型，希望它们成为Windows上的核心组件技术，提供企业在Windows
平台上开发企业应用系统的解决方案。其实以效率来说，＋的确是不错的。根据许
多的测试以及TPCC上公布的结果来看，＋的执行效率几乎是最好的。而前段时间The
ServerSide上公布的EJB对＋的评比更是闹得满城风雨。Java业界仍然不肯承认＋
比EJB来得有效率，但是以目前的数据来看，在Windows上EJB的确远远比不上＋。
在Microsoft多年的推展之后，/＋的确也有了不错的使用结果。根据2002年北
美关于＋的信息调查显示，使用＋技术的人占了34。3％，而且还有9％的人回答
将会采用＋。虽然＋在执行效率方面表现很好，但不可否认的是＋只能在Windows
平台使用，而且在Internet应用中使用不便，延展性也不若EJB，这都是＋致命的
缺点。
核心组件技术
既然Microsoft希望成为企业应用的平台，那需要提供什么呢？除了开发工
具之外，最重要的便是提供一个类似J2EE架构的软件解决方案，以吸引软件人员
为开发企业级的应用系统，帮助打入企业市场和Java平台竞争。
那现在的中有什么类似J2EE架构的技术呢？从下图我们可以清楚地看到，Microsoft
在中正逐渐建立起同SUN Java平台竞争的技术核心。Microsoft和SUN的虚拟竞争
平台现在几乎非常类似，不过，目前的Java在组件技术的领域远远超过了Microsoft
提供的解决方案。
Microsoft在中的组件技术是以组件配合＋为主。＋在中转为操作
系统的核心服务，提供事务管理（Transaction Management）的功能，而组件则可
以同时扮演中的可视化组件（Visual ponent）、数据感知组件（Data…Aware
ponent）以及中间件（Middleware ponent）。然而使用组件作为平台中
间件有许多问题。首先是组件必须依靠＋组件提供分布式事务管理能力；另外，
组件目前也没有像EJB一样的Fail…Over和Load…Balancing能力，这在企业级的应用
中是明显不足的。
此外，组件必须和＋一起搭配使用，这意味着程序员必须开发＋组件，而。
NET的原生工具无法开发＋组件，程序员还是必须使用原生的Windows开发工具。此
外，一旦使用了＋，代表此应用系统无法移植到其他的平台。如果Microsoft
把移植到Linux或是FreeBSD上，那使用＋组件的应用系统将无法移植到这
些平台之中。
那么，Microsoft是不是需要一个新的、能在平台使用的组件架构呢？就我的眼
光来看，如果Microsoft希望把平台定位在企业系统同J2EE竞争，那的确是需要
这种技术，但这对于Microsoft是有一点困难的。首先，Microsoft正忙于在一二年内
达到Java平台花了七八年的成果，正忙于开发本身、开发工具、下的数
据库，并且把所有的Microsoft Server应用程序移植到之下，可能一时无法投入
太多的资源来开发一个全新的企业级的组件架构。
另外，再看看Microsoft建立组件架构的历史就可以了解到，在这方面Microsoft的确
不太在行。期望Microsoft在短时间内在平台定义类似EJB的企业组件架构的规格
并且将其实现出来，似乎是不太容易的事情。
组件技术 结果
16位VBX 失败
32位VBX 失败
OLE 失败
尚可
ActiveX 失败
MTS 失败
＋ 不错
组件 不适合使用在企业级应用中
既然新创下的企业组件架构不是短时间内可以完成的，那是不是代表着在这
方面已经无法和J2EE竞争而提早出局呢？其实并不�