2002年的2月，Microsoft终于推出了.NET，也击败了许多爱看Vaporware好戏的人。
.NET的出现，代表了窗口平台的软件开发将进入一个新的领域，对于窗口平台上开发
工具厂商也有深远的影响，因为.NET是有史以来变动最大的窗口平台。第一次，
Microsoft把窗口变成一个虚拟执行环境，通过SOAP/Web Service技术，把窗口和各种
行动以及电子装置整合在一起，提供了下一代的整合虚拟数字世界。这个影响是深远
的，它不但冲击了操作系统，影响了下一代窗口操作系统的发展方向，也改变了开发
工具在这个虚拟执行环境中的角色。开发工具厂商必须重新定义、定位开发工具在.NET
中扮演的角色以及未来的发展趋势。
Windows3.0和3.1曾为窗口平台带来了最辉煌的时代，造就了C/C++四大天王(Borland、
Symantec、Watcom和Microsoft)、C/S双雄(PowerBuilder和Gupta)、COBOL两大家(RM
COBOL和Acu COBOL)以及无数充满活力的开发工具厂商。图形用户界面的盛行也让各种
Framework充斥于市。随着C/C++语言的流行，其他语言很快便退居2线。MFC的出现让
Symantec和Watcom退出市场，VB和Delphi的快速成长则让C/S双雄饮恨不及。开发工具
市场在Windows 98之后有了快速而巨大的变化。最后，除了Microsoft和Borland
等少数厂商之外，大部分的开发工具厂商都逐渐退出了这个竞争最激烈、门槛最高的
市场。随着.NET的推出，Microsoft又把竞争门槛再度拉高。这次Microsoft瞄准的是
企业信息市场以及Java平台，程序语言和开发工具的竞争不再是Microsoft关心的重
点，Microsoft的重点是如何在窗口平台提供类似Java已经发展将近10年的计算环境。
不过，这个目标却苦了开发工具厂商，因为他们必须面对新的虚拟执行平台、新的编
译技术和新的Framework。更糟糕的是，开发工具厂商必须在.NET中找到一条新的生
存之道，由于.NET包含了：
■ 一个虚拟执行环境--Common Language Runtime(CLR)
■ 一个庞大且完善的Framework--.NET Framework
因此开发工具厂商必须在这两者以及两者交错产生的软件元素中找到新的技术、新的
应用和新的利基，才能够持续在.NET中生存。更麻烦的是，Microsoft已经提供了一
个开发工具范例--Visual Studio.NET，它比当初SUN的失败作品Java Workshop好得
太多。这不但证明了Microsoft是一个比SUN更精于开发工具的厂商，而且，其他的开
发工具厂商要想凸显其产品更在Visual Studio.NET之上，也将是一件更艰苦的工作。
也许.NET的出现会加速淘汰更多的开发工具厂商，让.NET平台上的开发工具厂商更纯
化，最后只剩下最具实力的少数厂商。目前各家开发工具厂商如何适应.NET的冲击？
它们会提出什么新的软件技术同Microsoft以及其他厂商竞争？谁会是最后的胜利者？
这都将是非常有趣的事情，仔细观察并分析这些问题，或许从中也能学到许多的宝贵
经验。
.NET和Java的发展过程提供了许多耐人寻味的东西。有趣的是，.NET和Java虽然在现
在以及未来的发展有许多类似的表现，但是这两个平台的骨子里却有一些重要的差异。
其中最明显的，就是JVM和CLR分别如何执行最终的应用程序以及单一语言对语言中立
的考验。除此之外，Java和.NET对于中间件组件技术的对抗也是最激烈的一环，因为
中间件技术将是未来主宰系统架构的主要因素，SUN和Microsoft都希望自己力推的平
台成为新的应用标准。
Java和.NET的竞争，虽然从虚拟执行环境、程序语言、Framework一直延续到最新的
软件技术--SOAP/Web Service和数据存取技术，但是组件模型仍然是其中最重要的，
因为它代表的目标市场--企业信息领域，才是这两家必争之地。Java和.NET的组件模
型是程序语言设计之奇、Design Pattern之美、数据存取架构之广以及设计构想之深
的结晶。组件模型不但是SUN和Microsoft市场的关键，也代表了两家领导厂商的软件
技术实力以及系统架构的思想逻辑。因此在讨论Java和.NET竞争时，充分了解J2EE以
及.NET在组件模型方面的发展是很重要的。通过了解这两个阵营在组件技术的竞争，
我们也可以很容易掌握未来Java和.NET的发展趋势。因此随后的文章将从Microsoft
和SUN发展组件模型的历史和趋势开始讨论，让读者了解Java和.NET中位居关键地位
的技术演进，以及组件模型如何影响Java和.NET的未来走向。在本文后半部分，我们
将讨论.NET对于窗口平台中开发工具厂商的影响，以及未来开发工具的适应和发展趋
势。
Microsoft的COM组件模型
Microsoft的COM组件模型一直在很稳定的发展中。舍弃繁杂的OLE细节之后，COM才真
正地奠定了Windows组件模型的核心，开始可以提供制作企业逻辑对象的能力。DCOM
开始提供远程访问和分布式计算以及对象回收的机制，让COM组件模型能够提供企业
级计算的能力。不过在DCOM的时代，客户端仍然是通过Proxy/Stub直接和COM对象互
动，还未到达像EJB组件模型那样由虚拟服务器控管以提供系统服务等功能。但是，
Microsoft很快在MTS 1.0中正式加入了这个功能，至此，COM组件模型能够顺利地加
入企业核心服务，例如Object Pooling、Role-Based安全权限和交易管理等功能。严
格地说，在MTS出来之后，COM组件模型才有资格成为关键性系统的核心组件模型。也
因为MTS，才有后来的Microsoft DNA架构。在Windows 2000中，MTS正式成熟演进到
COM+1.0，除了把MTS调整得和操作系统更契合之外，最重要的进步是大幅提升了执行
效率，因此，Microsoft的TCPP数据大都是以COM+加VC++撰写的。
在不久前推出的Windows XP中，COM+又进步到1.5版。在COM+1.5版中，Microsoft对
COM+进行了许多改善，其中最重要的便是再次提升了COM+的执行效率，让它比COM+1.0
更快。此外，延展性也是COM+1.5的调校重点。Microsoft为COM+1.5加入了Partitioning
功能，企图让COM+的Application能够在不同的Container服务器(DllHost.exe)中执
行，提供对象并联的架构，以增加COM+应用系统的延展性。不过，从COM+1.5目前实
现的程度来看，这应该是初步的规划，未来应该还有很大的进步空间。
此外，COM+1.5也加入了Application Pooling的机制，让程序员可以控制COM+
Container
服务器执行的数目。当Container服务器的执行数达到右图中集区大小的数目之后，
Windows操作系统便会重复使用已经存在的Container服务器，而不会允许客户端继续
建立新的Container服务器，如此一来，就不会让客户端启动太多的Container服务器
以拖垮Windows操作系统。
而应用程序回收(Application Recycling)功能则是Microsoft为了克服COM+内存泄漏
(Memory Leak)问题加入的。在COM+1.5中，程序员可以指定COM+的Application在一
定时间、或是在COM+的Application的内存使用到达一定的数量、或是被调用了一定
的次数、或是被启动了一定的次数之后就重新启动COM+的Application。这样，可以
让Container服务器结束运行，而操作系统则可以回收因为COM+对象泄漏的内存。在
COM+尚未像EJB或是.NET一样以虚拟执行环境进行Garbage Collection之前，这倒不
失为一个好方法，因为Windows 2000和XP在进程安全控制方面有了大幅的精进。
此外，COM+1.5的组件服务程序也允许程序员直接管理和设定旧的COM/DCOM组件，不
需要再使用DCOMCNFG.exe程序。1.5的组件服务程序整合了所有型态的COM组件，是相
当不错的功能。
从COM+1.5的发展来看，其他的许多功能都属于小进步，未来COM+的发展将会很小，
进而COM+会真正地转变成Windows的核心服务之一。未来Windows的组件模型应该是由
.NET的组件架构来接棒，因为Microsoft仍然需要一个提供虚拟执行环境的组件架构，
以提供良好的Garbage Collection和Partitioning的功能，进一步和EJB竞争企业系
统的延展性，而这个征兆可以从稍后讨论的.NET发展看得出来。
SUN的EJB组件模型
经过了将近2年的时间后，SUN终于在最近推出了新一版的EJB 2.0功能规格，很快也
被BEA和Borland的BES实现出来。SUN在EJB 2.0中提出了许多先进而复杂的功能，目
的是为了大幅强化EJB作为企业核心组件架构的本钱，以便在企业系统中和Microsoft
下一代的.NET组件竞争。
从SUN定义EJB的规范开始，就展现了其和COM不一样的观念。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，当然，这也代表着这些会
建立关系的Bean必须执行在一个相同的EJB Container中。EJB 2.0的CMP增加了功能
和效率，但是也增加了Bean之间相互依靠的关系，这会影响EJB程序员在设计系统时
的布局。此外，EJB 2.0的CMP虽然提供了这么强大的功能，但这也是不同厂商实现的
EJB服务器执行效率有差距的地方。不同EJB服务器使用的实现方法的不同，会大大影
响执行效率。这就是为什么SUN定义了ECperf标准来检验和评比EJB服务器的真正执行
效率的原因，这稍后会谈到。
因此，在EJB 2.0功能规格中，SUN定义了数个机制来增加EJB服务器的执行效率，这
在EJB的架构已经很完整的情形下是很自然的下一步。当然，除了上述的功能外，EJB
2.0功能规格也增加了MDB(Message Driven-Bean)，MDB可以让程序员使用异步的方式
传送信息，事实上把原本JMS的功能加入到EJB的功能规格中，是为了对抗Microsoft
把MSMQ整合进COM+。请看EJB进化的示意图，我认为EJB 2.0最重要的进步便是执行效
率、OR Mapping以及EJB的查询语言。EJB的查询语言开启了未来和JDO(Java Data
Object)的整合，目的是和Microsoft在.NET中定义的OPath和数据对象相互竞争，这
在稍后也会再说明。至于OR Mapping，则是一个非常复杂的机制。它规范了Bean
Instance和数据源之间的关系，这个标准可能会让许多小的EJB服务器厂商退出EJB市
场，或是无法完整地支持EJB 2.0的功能规格。
再看看Local Interface的意义。在EJB 1.x中，客户端调用Bean Instance时，在
Container中Bean和Bean之间都是使用Remote Interface的方式进行调用，如下图所示：
事实上，图中显示的启动模式是非常浪费资源的，因为图中的Bean都属于同一个
Container之中，为什么要使用缓慢的Remote调用模式呢？因此在EJB 2.0中定义了
Local Interface。如下图，现在只有在跨越网络或是跨越不同的Container时才需要
使用Remote调用模式，这大大地改善了使用的资源和调用效率。
更好的是在EJB 2.0中，一个Bean可以同时定义Remote Interface和Local Interface。
如此一来，Bean的使用者和组合者(Assembler)可以更有弹性地分发和部署EJB Bean。
在EJB 2.0中，Bean只要从EJBLocalObject继承下来，就可以拥有Local Interface的
功能。例如程序员可以用下面的程序代码来提供Local Interface的功能。本质上，
实现和定义Local Interface的方式和原本的Remote Interface非常类似，因此EJB
的程序员可以很自然地学会这个新的EJB功能。
public interface YourobjectClass extends EJBLocalObject
public interface YourobjectClass extends EJBLocalHome
了解了EJB 2.0增加的功能之后，现在就可以回到前面朋友询问我的问题了，为什么
在EJB中没有看到任何像COM一样的线程模型之类呢？事实上这很简单，因为EJB是一
个标准功能规格，并不包含如何实现的细节，在一般的EJB书籍中当然看不到类似的
东西。而且，COM之所以有这么复杂的各种线程模型，是因为COM发展的包袱以及历史
的因素所造成的。不过，这并不代表在EJB中没有线程模型的问题，因为EJB厂商如何
实现EJB功能规格会深深地影响EJB服务器的效率。因此，线程模型反而是EJB程序员
应该知道的东西，只是依据不同的厂商而有不同的结果，不像COM功能规格是由
Microsoft定义的，也是由Microsoft实现的，因此会有一致的执行行为。
EJB的线程模型应该是使用Object Per Client的模型。这个意思是说，EJB Container
会为每一个请求的客户端建立一个独立的Bean服务。因此，如果EJB厂商没有特别进
行最佳化的工作，那EJB使用的模型应该是类似COM中的STA，也就是说，一次只有一
个Worker线程在Bean Instance中执行。下图就显示了这个架构，对每一个客户端就
启动一对Worker Thread/Bean Instance。
上图叙述的是正常的情形，那如果让两个客户端同时存取一个Bean Instance时，会
发生什么情况呢？下图就显示了这个架构。在这个情形中，如果有两个客户端要同时
存取Bean Instance，那EJB Container如何控制呢？在一般的EJB书籍中，似乎也没
有看到和同步处理有关的范例，难道说，可以不进行任何的处理就让两个客户端同时
存取吗？这当然不会，因为此时EJB Container就会进行管理，以STA的模式控制同步
存取，因此客户端的存取必须依序(排队)来调用Bean Instance。
这个情形也可以直接从Bean的实现程序代码中看出，例如下面的程序代码是EJB的标
准范例Entity Bean的实现程序代码。请注意，在这个Bean类别中定义了数个private
变量，并且在Bean的方法中直接存取和处理这些private变量，完全不需要考虑任何
的同步处理机制，这就是因为EJB Container一般就是使用Object Per Client的模型
以及类似COM的STA的线程控制模型。
这只是一般的EJB Container可能会使用的模型，但有一些EJB服务器提供了最佳化的
机制，可能会提供更为有效率的方式。下面的表格列出了COM/COM+和EJB在线程模型
方面的比较：
因为不同的应用程序服务器厂商实现而不同
读者必须注意的是，上表并不代表COM+是比较好的，只能说COM+提供了较多的选择，
可以让有经验的程序员调整执行效率。但是，相对地也让情形复杂了许多，而且COM+
的MTA线程模型也不容易实现。
正由于EJB功能规格会因为不同的EJB厂商实现而有不同，因此，除了前面提到的EJB
2.0中CMP和OR Mapping会影响EJB服务器的执行效率之外，如果再结合线程模型和对
象建立的技术，那下面列出的问题是影响执行效率的重要因素：
●如何实现和控制Worker Thread。事实上这就是EJB Server中Thread Pooling的机制
●如何实现和控制EJB Bean Instance。这就是EJB Server中Object Pooling的机制
为了让EJB服务器有公平的效率比较基础，SUN定义了ECperf标准让使用者能够用来评
量各家EJB服务器的执行效率，以避免各说各话的情形。从这一点也可以看出，SUN现
在开始注重EJB服务器的执行效率因素了。
为什么我说线程模型会因为不同的EJB服务器而有不同呢？现在让我们以实例来看看
EJB服务器的行为。下图是我使用4个Delphi建立的客户端应用程序，并且使用SIDL技
术来调用Borland Application Server-BAS中的一个Stateless Session Bean的结果。
从图中可以明显地看到，即使是在有4个客户端的情形中，BAS仍然使用了MTA模式，
只建立一个Stateless Session Bean，并且让4个Worker线程同时存取，因此执行效
率非常高，使用的内存资源也非常少。
而下图则使用4个Delphi客户端应用程序调用Stateless COM+对象(使用Both线程模型)，
从图中可以看到，COM+使用Object Per Client的模式，建立了4个COM+对象服务4个
客户端，虽然执行效率也非常高，但是使用的资源稍比BAS多。
接下来，再让我们讨论一下未来Microsoft的组件模型以及SUN的组件模型的演进趋势。
Data Access Technology
在未来，Microsoft和SUN的组件模型大概都会强调数据存取的技术，因为从前面讨论
的EJB 2.0 CMP的内容中我们可以知道，现在SUN已经在为对象和数据之间建立连接的
技术了，而未来的JDO技术将进一步紧密结合数据对象的观念，让程序员面对的所有
东西都是对象，不再有数据和对象不一样的观念和使用方式。
不过别以为Microsoft只会呆在原地，在PDC 2002中Microsoft已经宣示了未来ADO.NET
的发展方向。ADO.NET未来将会结合数据和组件的观念，让.NET的程序员以对象的观
念来代表数据，就像EJB中的CMP/BMP一样。如此一来，.NET的程序员可以像EJB一样
声明代表数据源中数据的数据类型，并且使用以XML格式封装的数据对映叙述器(Data
Descriptor)来连接数据对象和数据源之中的数据。如此一来，.NET的组件模型也提升
到和EJB 2.0加上未来JDO一样的层次。
例如程序员可以定义如下的数据类型：
public abstract class Customer {
public abstract string Name{get; set;}
[Link(Account)] public abstract IList Accounts {get;}
}
public abstract class Account {
public abstract float Amount {get; set;}
public void CalculateTotal() {
// business logic
}
}
并且定义上述Customer和Account之间的连接关系，这和EJB2.0中新的CMP功能一样，
然后再定义如下的对象/数据对映器，把对象和数据源连接起来，请特别注意下面
relationship的部分：
最后，程序员可以使用如下的形式通过数据对象存取数据，并且在数据对象之间自动
形成关联的关系。这非常有威力，和EJB/JDO不相上下。事实上，ADO.NET和EJB/JDO
实现的观念和想法非常类似，这是巧合还是模仿呢？基本上可以说，这两大阵营都有
互相参考对方技术的地方。
下图就是未来ADO.NET的数据对象架构，程序员只需要修改Schema Mapper就可以连接
到不同的数据源，例如MS SQL Server或是Oracle等。
除了ADO.NET的数据对象外，Microsoft也开始定义类似于EJB QL的对象查询语言，目
前暂时称为OPath。当然，我们可以进一步地讨论更为深入的组件技术问题，不过由
于篇幅的限制，就让我们以后在专门讨论技术的书籍中继续说明好了。
下图很清楚地说明了Microsoft和SUN组件模型的发展趋势。从图中，我们几乎可以知
道这两者非常类似，发展的方向也趋于一致。未来比较的因素可能是执行效率、延展
性、能够执行的平台以及开发工具的支持程度和使用的方便性吧。
综合上述内容，从最近Microsoft的COM+/.NET的推出、SUN的EJB 2.0功能规范的完成、
以及中间件厂商实现的EJB应用程序服务器来看，Microsoft似乎也已经开始采用类似
Java的虚拟执行环境以及EJB的模型来重新塑造.NET的组件模型了。COM+将逐渐退居幕
后提供系统核心服务，甚至会慢慢地消失于未来.NET的执行平台之中。不过由于.NET
的进入门槛不低，而且目前仍然有大量的原生Windows开发人员以及Windows应用程序，
因此，这个从COM组件模型完整转换到.NET的过程可能仍然需要数年之久，而COM在现
在开始的数年内仍然是Windows平台上最重要的中间件技术。
据Gartner Group的调查和估计，在2003到2004年使用EJB技术开发的Java应用系统将
占整个Java平台的40％左右，这表示EJB技术已经获得了大型企业和专业软件厂商的
认可，是企业级的组件模型。EJB 2.0必须开始增加执行效率，故此加入了Local
Interface。此外延展性也成为EJB应用程序服务器的发展重点，因为EJB应用程序服务
器势必将承载更多的存取，以担负起企业的关键应用。因此，EJB厂商开始在EJB服务
器中切割虚拟伺服环境，并且在每一个虚拟伺服环境中执行不同的软件。例如一个虚
拟伺服环境负责执行JSP/Servlet Container，而另外的虚拟伺服环境则执行EJB
Container等，如下图所示。这样做的好处是不但每一个Container更安全，而且应用
程序服务器的延展性将更为优秀，因为在多CPU的机器中可以分配专门的CPU给不同的
Container，并且在一个EJB服务器中可以同时执行多个EJB Container。
这里有一个很有趣的区别，那就是由于Microsoft掌握了操作系统，Microsoft可以尽
量地把.NET的虚拟执行环境移往操作系统的核心，提供更为良好的执行效率；但是由
于提供EJB的厂商没有这项优势，因此必须以更好的实现方式来开发EJB应用程序服务
器，这也是为什么SUN以ECperf这个标准来评定各家EJB应用程序服务器的执行效率的
原因。但是从目前EJB服务器的实现观念和技术看，仍然是领先于Microsoft的.NET。
不过不要小看Microsoft，虽然.NET在2002年的第一季才推出，但是Microsoft已经在
开发.NET的第2个版本了，.NET的发展步伐是很快速的。
中间件技术将会继续不断地发展下去，各种新的组件观念和实现技术也将持续地出现。
组件模型技术和中间件已逐渐取代早期的程序语言和数据库服务器，成为现在信息架
构的主导力量，Microsoft和SUN都希望成为这个领域的领导者。不过谢谢信息市场的
竞争力量，让这两家大厂都无法消灭对方，反而由于竞争的力量造成了组件模型不断
地创新，使信息人员能够持续地使用新的、更好的、更成熟的中间件技术，来实现日
趋复杂的信息系统，虽然这个学习的过程很辛苦，但这也是信息行业让人感觉到有趣
味的地方，因为你不会总觉得工作是一成不变的。
只是现在Web Service的兴起让组件模型的界限开始显得模糊了，而Web Service也是
Microsoft.NET和下一版Java JDK强调的重点功能。看起来，Web Service技术将会开
始把组件模型逐渐地转换为面向组件服务，让组件模型的决胜点从面向功能逐渐转向
面向服务。以后哪一个组件模型能够提供企业级的服务模型，将会是决定系统使用的
架构的关键点，而这个现象已经可以从一些中间件厂商最近的动作中隐约的看出。
.NET对于开发工具厂商的影响
.NET的推出，对于所有开发工具厂商而言都是一大挑战，这除了牵涉到技术层面之外，
还包含了复杂的产品定位的问题。相对于当初Windows 3.0/3.1推出时各个开发工具厂
商百家争鸣的盛况比起来，如今的.NET平台就显得逊色了许多。当然这主要的原因在
于.NET中语言不再是重点，再加上语言可以内嵌在Microsoft的Visual Studio.NET中，
这顿时让许多的开发工具厂商失去了定位以及竞争优势。如果开发工具厂商只是做一
个语言的Plug-In到Visual Studio.NET中，那将很难生存下去。
对于像Borland的Delphi、C++Builder以及Sybase的PowerBuilder而言，如何在新的
.NET环境中保持竞争优势是很重要的问题。因为在.NET中，应用程序执行环境、Common
Language Runtime(CLR)以及.NET Framework都是由Microsoft所掌握，其他工具厂
商如何在Microsoft一手控制的环境中营造出竞争优势呢？另外在.NET中，开发工具
厂商必须把应用程序编译成Common Intermediate Language(CIL)的格式，再由JIT编
译器编译成原生机械码执行，如下图所示。
因此，如果开发工具厂商要在.NET环境中继续提供竞争产品，那至少必须在下面的三
个领域中找到答案，并且做出实际的解决方案：
■ 编译器的竞争--如何把程序语言最正确且有效率地编译成CIL
■ .NET Framework的竞争--如何在.NET Framework上进行加值的工作，并且定位产
品竞争力
■ 开发工具本身功能集(Feature Set)的竞争
从编译器角度来说，由于.NET的CLR内建的Virtual Execution System(VES)支持一般
的程序语言功能，同时又提供了丰富的对象模型支持能力，以提供面向对象语言对映
到CLR的能力，因此.NET可以说是OOP-Friendly的执行环境，这非常有助于面向对象
程序语言在.NET中实现，例如对C/C++、Object Pascal等真正的OOP来说是个好消息，
而Microsoft的新语言C#就是一个好的OOP实现范例。但是对于使用脚本语言作为骨架
的开发工具(例如PowerBuilder)来说，可能就需要花上许多的功夫重新规范，以便能
够适当地使用CLR的特性。当然除了程序语言之外，如何开发出一个有效率的CLR编译
器更是开发工具厂商需要费心的地方。
在Framework方面，Microsoft的.NET Framework摆明了要和SUN的J2EE/J2SE/JEME等
竞争，而且花了许多的资源打造.NET Framework，力求能够提供给程序员最好的开发
功能。但是，对于开发工具厂商来说则是有喜有忧。一方面，Microsoft虽然提供了
良好的.NET Framework，可以减少开发工具厂商需要花费的成本；但另一方面，开发
Framework的权力掌握在Microsoft手中，特别是Microsoft也有Visual Studio.NET作
为竞争产品，因此如何定位便成了重要的问题。就我的看法，如果开发工具厂商无法
在.NET Framework上进行增值的工作，那最后仍然难逃被淘汰的命运。
即使开发工具厂商能够克服前面讨论的两个问题，最后仍然要回到产品本身的竞争力
上来。没有集成开发环境、组件架构、调试环境和高生产力，仍然无法和Visual
Studio
.NET竞争。开发工具厂商不但要像以往一样提供一个集成开发环境，甚至还必须做得
比Visual Studio.NET更好、更具创意。这也不是一件容易的事情，因为这必须有突
破性的想法。例如，其中的一种可能就是再把.NET的通用性延伸，除了像.NET不把语
言的差异作为重点之外，也不把CIL产生的结果作为差异。由于CIL是一组标准的中介
信息，开发工具厂商可以继续把CIL转化为.NET、原生窗口应用程序、Linux应用程序，
甚至是移动设备上的程序代码，如下图所示。
如此一来，这种开发工具将更为广泛和实用，也是开发工具极好的竞争优势，特别是
现在仍然有许多的软件厂商需要继续开发小而快的原生窗口应用程序。
Microsoft .NET的出现不单对于Microsoft本身有重大的意义，对于窗口平台上所有
开发工具厂商和SUN都有巨大的影响。开发工具厂商正面对着从Windows推出以来最严
格的考验，这是一场生与死的竞争。对于SUN来说，.NET代表的是Microsoft正式全面
地向Java平台挑战，时间将决定JVM和CLR的胜负，而Java单一语言的通用性也将面临
.NET语言中立的考验。至于传统的窗口程序设计人员而言，也许正如"魔戒传奇"中的
哈比人一样，明知前途坎坷，仍然必须选择走向严寒的雪山或是诡谲的地道，因为目
的只有一个：在新一波的软件技术和平台中找到一条生存之路。
