按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
对手。不过，当大部分的软件服务都被加入之后，剩下来的当然就是从整合开发工具
以及分析/设计软件上动脑筋了。
这也是为什么当初BEA会和WebGain合作而IBM也不愿意放弃VisualAge For Java的原
因。即使Visual Café和VisualAge For Java已经无法在Java开发工具市场成为第一
位的工具，但由于使用EJB技术的企业愈来愈多，也有愈来愈多的企业要求结合Java
开发工具和Modeling工具以便开发大型的Java以及J2EE应用系统。IBM很显然也注意
到了这个市场和需求，于是在Borland并购了TogetherSoft、Rational感觉到巨大压
力的时候，立刻找上Rational。由于IBM出手阔绰，再加上Rational自知要独自面对
Borland和TogetherSoft的联军没有多大胜算，因此也很快答应了IBM的条件，正式由
IBM接收了Rational。
在IBM确定并购Rational之后，这股软件公司之间重量级的并购潮不但没有结束，反
而更为暗潮汹涌，因为IBM并购了Rational之后，开始对BEA和Microsoft产生更大的
影响。IBM在取得了Modeling工具之后就在EJB服务器中取得了整合的优势，对于BEA
将有更强大的攻击力。而BEA在原本已经逐渐落居下风的EJB战役中如果还面临IBM整
合Modeling的攻势，那么情势必将更为恶劣。因此，当时我认为BEA将是IBM这桩并购
案最大的受害者。果然之后不久，许多专业媒体都评论了BEA不利的局势，预言BEA最
强的支持者将会是Borland，甚至许多人也传出BEA将并购Borland的消息。对于这个
传言，BEA的响应似乎是正面的，因为现在BEA已经和Borland有所合作，而BEA和Borland
的产品线也非常互补，没有什么严重的冲突。不过，我个人还是希望Borland能够维
护独立的软件公司。
另外一个受影响的软件厂商则是Microsoft。Microsoft在以前早就和Rational有合作，
不过Microsoft还是那个调调，在自己没有Modeling工具之前希望和Rational合作，
但是一旦有了类似的工具之后（即Visio），就停止了和Rational的合作，这种做法类
似当初Microsoft和Sybase的合作关系。不过，在IBM取得了Rational之后情势又不同
了，因为现在IBM拥有了非常完整的产品线，IBM可使用这条产品线，以强大又完整的
J2EE架构正面攻击Microsoft的。因此，后来也传出了Microsoft有意并购Borland
以取得Modeling工具的风声。如此一来，Microsoft不但可以在．NET上提供全世界最
好的开发工具、Modeling工具，又能够取得需要的组件模型，即CORBA，以
对抗EJB，可以说是一举数得。不过在开发工具方面，Microsoft和Borland有严重的
重复，又可能会引起独占市场的疑虑，因此我个人认为，这是不太可能的结合，真的
要说，那么双B（Borland和BEA）的组合反而比较可能。
不管未来的发展如何，应该发生在2003年的大战终于在2002年末正式提前开打，Borland
也即将进入另外一个新的转变。
^v^v^v^v^v^v^v^v^v
第九章 软件技术和平台的大竞赛
2002年的2月，Microsoft终于推出了，也击败了许多爱看Vaporware好戏的人。
的出现，代表了窗口平台的软件开发将进入一个新的领域，对于窗口平台上开发
工具厂商也有深远的影响，因为是有史以来变动最大的窗口平台。第一次，
Microsoft把窗口变成一个虚拟执行环境，通过SOAP/Web Service技术，把窗口和各种
行动以及电子装置整合在一起，提供了下一代的整合虚拟数字世界。这个影响是深远
的，它不但冲击了操作系统，影响了下一代窗口操作系统的发展方向，也改变了开发
工具在这个虚拟执行环境中的角色。开发工具厂商必须重新定义、定位开发工具在
中扮演的角色以及未来的发展趋势。
Windows3。0和3。1曾为窗口平台带来了最辉煌的时代，造就了C/C＋＋四大天王（Borland、
Symantec、Wat和Microsoft）、C/S双雄（PowerBuilder和Gupta）、COBOL两大家（RM
COBOL和Acu COBOL）以及无数充满活力的开发工具厂商。图形用户界面的盛行也让各种
Framework充斥于市。随着C/C＋＋语言的流行，其他语言很快便退居2线。MFC的出现让
Symantec和Wat退出市场，VB和Delphi的快速成长则让C/S双雄饮恨不及。开发工具
市场在Windows 98之后有了快速而巨大的变化。最后，除了Microsoft和Borland
等少数厂商之外，大部分的开发工具厂商都逐渐退出了这个竞争最激烈、门槛最高的
市场。随着的推出，Microsoft又把竞争门槛再度拉高。这次Microsoft瞄准的是
企业信息市场以及Java平台，程序语言和开发工具的竞争不再是Microsoft关心的重
点，Microsoft的重点是如何在窗口平台提供类似Java已经发展将近10年的计算环境。
不过，这个目标却苦了开发工具厂商，因为他们必须面对新的虚拟执行平台、新的编
译技术和新的Framework。更糟糕的是，开发工具厂商必须在中找到一条新的生
存之道，由于包含了：
■ 一个虚拟执行环境mon Language Runtime（CLR）
■ 一个庞大且完善的Framework Framework
因此开发工具厂商必须在这两者以及两者交错产生的软件元素中找到新的技术、新的
应用和新的利基，才能够持续在中生存。更麻烦的是，Microsoft已经提供了一
个开发工具范例Visual Studio，它比当初SUN的失败作品Java Workshop好得
太多。这不但证明了Microsoft是一个比SUN更精于开发工具的厂商，而且，其他的开
发工具厂商要想凸显其产品更在Visual Studio之上，也将是一件更艰苦的工作。
也许的出现会加速淘汰更多的开发工具厂商，让平台上的开发工具厂商更纯
化，最后只剩下最具实力的少数厂商。目前各家开发工具厂商如何适应的冲击？
它们会提出什么新的软件技术同Microsoft以及其他厂商竞争？谁会是最后的胜利者？
这都将是非常有趣的事情，仔细观察并分析这些问题，或许从中也能学到许多的宝贵
经验。
和Java的发展过程提供了许多耐人寻味的东西。有趣的是，和Java虽然在现
在以及未来的发展有许多类似的表现，但是这两个平台的骨子里却有一些重要的差异。
其中最明显的，就是JVM和CLR分别如何执行最终的应用程序以及单一语言对语言中立
的考验。除此之外，Java和对于中间件组件技术的对抗也是最激烈的一环，因为
中间件技术将是未来主宰系统架构的主要因素，SUN和Microsoft都希望自己力推的平
台成为新的应用标准。
Java和的竞争，虽然从虚拟执行环境、程序语言、Framework一直延续到最新的
软件技术SOAP/Web Service和数据存取技术，但是组件模型仍然是其中最重要的，
因为它代表的目标市场企业信息领域，才是这两家必争之地。Java和的组件模
型是程序语言设计之奇、Design Pattern之美、数据存取架构之广以及设计构想之深
的结晶。组件模型不但是SUN和Microsoft市场的关键，也代表了两家领导厂商的软件
技术实力以及系统架构的思想逻辑。因此在讨论Java和竞争时，充分了解J2EE以
及在组件模型方面的发展是很重要的。通过了解这两个阵营在组件技术的竞争，
我们也可以很容易掌握未来Java和的发展趋势。因此随后的文章将从Microsoft
和SUN发展组件模型的历史和趋势开始讨论，让读者了解Java和中位居关键地位
的技术演进，以及组件模型如何影响Java和的未来走向。在本文后半部分，我们
将讨论对于窗口平台中开发工具厂商的影响，以及未来开发工具的适应和发展趋
势。
Microsoft的组件模型
Microsoft的组件模型一直在很稳定的发展中。舍弃繁杂的OLE细节之后，才真
正地奠定了Windows组件模型的核心，开始可以提供制作企业逻辑对象的能力。D
开始提供远程访问和分布式计算以及对象回收的机制，让组件模型能够提供企业
级计算的能力。不过在D的时代，客户端仍然是通过Proxy/Stub直接和对象互
动，还未到达像EJB组件模型那样由虚拟服务器控管以提供系统服务等功能。但是，
Microsoft很快在MTS 1。0中正式加入了这个功能，至此，组件模型能够顺利地加
入企业核心服务，例如Object Pooling、Role…Based安全权限和交易管理等功能。严
格地说，在MTS出来之后，组件模型才有资格成为关键性系统的核心组件模型。也
因为MTS，才有后来的Microsoft DNA架构。在Windows 2000中，MTS正式成熟演进到
＋1。0，除了把MTS调整得和操作系统更契合之外，最重要的进步是大幅提升了执行
效率，因此，Microsoft的TCPP数据大都是以＋加VC＋＋撰写的。
在不久前推出的Windows XP中，＋又进步到1。5版。在＋1。5版中，Microsoft对
＋进行了许多改善，其中最重要的便是再次提升了＋的执行效率，让它比＋1。0
更快。此外，延展性也是＋1。5的调校重点。Microsoft为＋1。5加入了Partitioning
功能，企图让＋的Application能够在不同的Container服务器（DllHost。exe）中执
行，提供对象并联的架构，以增加＋应用系统的延展性。不过，从＋1。5目前实
现的程度来看，这应该是初步的规划，未来应该还有很大的进步空间。
此外，＋1。5也加入了Application Pooling的机制，让程序员可以控制＋ Container
服务器执行的数目。当Container服务器的执行数达到右图中集区大小的数目之后，
Windows操作系统便会重复使用已经存在的Container服务器，而不会允许客户端继续
建立新的Container服务器，如此一来，就不会让客户端启动太多的Container服务器
以拖垮Windows操作系统。
而应用程序回收（Application Recycling）功能则是Microsoft为了克服＋内存泄漏
（Memory Leak）问题加入的。在＋1。5中，程序员可以指定＋的Application在一
定时间、或是在＋的Application的内存使用到达一定的数量、或是被调用了一定
的次数、或是被启动了一定的次数之后就重新启动＋的Application。这样，可以
让Container服务器结束运行，而操作系统则可以回收因为＋对象泄漏的内存。在
＋尚未像EJB或是一样以虚拟执行环境进行Garbage Collection之前，这倒不
失为一个好方法，因为Windows 2000和XP在进程安全控制方面有了大幅的精进。
此外，＋1。5的组件服务程序也允许程序员直接管理和设定旧的/D组件，不
需要再使用DCNFG。exe程序。1。5的组件服务程序整合了所有型态的组件，是相
当不错的功能。
从＋1。5的发展来看，其他的许多功能都属于小进步，未来＋的发展将会很小，
进而＋会真正地转变成Windows的核心服务之一。未来Windows的组件模型应该是由
的组件架构来接棒，因为Microsoft仍然需要�