按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
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仍然需要一个提供虚拟执行环境的组件架构，
以提供良好的Garbage Collection和Partitioning的功能，进一步和EJB竞争企业系
统的延展性，而这个征兆可以从稍后讨论的发展看得出来。
SUN的EJB组件模型
经过了将近2年的时间后，SUN终于在最近推出了新一版的EJB 2。0功能规格，很快也
被BEA和Borland的BES实现出来。SUN在EJB 2。0中提出了许多先进而复杂的功能，目
的是为了大幅强化EJB作为企业核心组件架构的本钱，以便在企业系统中和Microsoft
下一代的组件竞争。
从SUN定义EJB的规范开始，就展现了其和不一样的观念。EJB一开始就非常重视
Design Pattern和组件种类，例如Session Bean和Entity Bean各自负责不同的角色，
再借助于Java的Garbage Collection，提供了成为企业信息系统组件必要的基础。但
是，在EJB 1。x中，所有的Bean Instance之间的调用都是使用Remote Interface方式，
因此在许多的应用方面付出了较大的开销，导致一些情况下执行效率不佳。在EJB 1。x
中发展出了许多的Design Pattern来改善这种现象，例如鼓励使用Coarse…Grained对
象，以减少网络Round…Trip和Bean之间的调用次数。
在EJB 2。0中，SUN终于为改善这个问题而提出了Local Interface。所谓Local
Interface，是指当Bean Instance在同一个EJB Container中时，EJB Container可以
使用Local Interface调用来代替Remote Interface调用，这样可以增加3倍以上的对
象启动效率。另外，SUN加入Local Interface功能的重要原因是为了支持EJB 2。0中
大幅强化的CMP（Container Managed Persistence）功能。
简单地说，EJB 2。0中的CMP允许程序员使用EJB Query Language来定义Bean之间的关
系。只要程序员使用EJB QL定义了一个Bean和另外一个Bean的关系（Relationship），
那客户端便可以在存取了主要Bean之后，再通过Bean定义的Finder或是Selector方法
取得所有的从属Bean。如果读者不太了解这个意思，可以参考下面的示意图。在客户
端建立主CMP之后，可以通过主CMP的Finder或是Selector方法取得所有的从属Bean，
此时，主CMP便可以通过EJB QL向数据源查询所有相关的数据，再由EJB Container根
据查询的数据自动建立从属Bean、并且和主CMP建立关联。如此一来，2。0的CMP可以
免除程序员自行撰写存取数据和建立CMP的程序代码的麻烦，并且允许EJB Container
使用最佳化的方式从数据源存取数据和建立CMP。为了增加这个过程的执行效率，EJB
2。0的功能规范要求这种Bean必须支持Local Interface，当然，这也代表