准确地讲.Net平台是什么？
如何将.Net的体系结构和J2EE对比？
从.Net的体系结构演绎出的一整套关于企业软件开发方案中我们能学到此什么？
在本文中作者将为你解开这些疑问。
廖永康
原文出处：
即使你没有专门针对微软平台写过程序，你可能也会听到过微软的.Net。这是微软对最近一连串和非视窗事件竞争的回答。如果你读到过有关新闻、来自微软的撰稿、或者通过在MSDN端浏览得到的不完整的技术资料、或者你注意到了微软专家开发者会议(会上已经演示了.Net平台)的话，你可能至少还有两大疑问：
* 准确地讲.Net平台是什么？
* 如何将.Net的体系结构和J2EE对比？
如果你再深入一步的话，你可能还有第三个疑问活跃在你的脑海里：
* 从.Net的体系结构演绎出的一整套关于企业软件开发方案中我们能学到此什么？
.Net框架是其生命周期的十分早期阶段的产品，微软.Net部门还会不断地更深入和仔细地开发它，但是无论怎样，我们已经能够从已有的资料对这些问题作出公正的正确的回答。
它是什么？(.Net是什么？)
现在在众多的论坛中对.Net的反思，使人不禁联想起三个瞎子摸象的寓言；根据你的洞察力，可能得到非常不同的结论：有人认为.Net是微软下一代Visual Studio的开发环境；有人认为它只是一种新的编程语言(C#)；还有人为它是基于XML和SOAP的一种新的数据交换和报文的工作框架。实际上，.Net包含了这几部份内容，而且还会更多。
首先，让我们看一些具体的细节，浏览一下组成.Net平台的一系列技术构件：
l C#：是一种新写的描述(书)构件的语言，它将C、C++和Java的元素集成起来，并增加一些特点如：元数据标记、相关元素的开发。
l “公共语言运行时”：它以中间语言(IL)格式，运行字节代码，用一种语言写的代码和对象只要编译器是针对这种语言开发的，显然能够编译成IL运行时。
l 一组基本的可从“公共语言运行时”访问的构件(元件)，它可提供各种功能(如：连网功能、包容器功能等等)。
l ASP.NET：是新的ASP版本，支持将ASP编译成公共语言运行时功能(所以用任何语言写的ASP脚本，都能和IL捆绑在一起)。
l 视窗格式和Web格式：一种新的可从Visual Studio访问的UI构件框架。(用户接口=UI)。
l ADO：将XML和SLAP用于数据交换的新一代ADO数据访问构件(元件)。
.Net和J2EE如何比较？
正如我们所能看见的.Net平台，在其伞型结构下有一个技术矩阵(宝塔)。显然微软为了抓住视窗平台的开发商，正在将这些技术变成现有平台如J2EE和CORBA的代用品。但是怎样对它们进行逐项比较呢？一种方法就是将.Net和J2EE作成以下对比列表：
.Net J2EE 关键差异
C#编程语言 Java编程语言 C#和Java均来自C和C++，最显著的特 点(如垃圾收集层次结构的名字空间)在两 个方面。C#借用了JavaBeans的某些构件概念(特性属性、事件等)，并增加了 某些自己的概念(如元数据标志)，但将 这些特点合并成不同的语法。 Java以Java虚拟机方式运行在任何平台上，而C#在可预见的将来，仅运行在视 窗环境内。C#隐含地结合到IL公共语 言运行时中，(见后)，然后按合理的顺 序(JIT)运行。编译成的字节编码或者整个编译成的自然编码。Java代码按照Java 虚拟机字节代码方式运行，它由VM解 析或JIT编译，或者整个编译成自然代码。
.Net公共元件(填补“.Net 框架结构的SDK”) Java核心API 高层的.Net元件，包括支持用XML和SOAP 的分布式访问(见ADO.NET)。
ASP.NET页面(ASP.NET) Java服务器页面(JSP) ASP.NET使用Visual Basic、C# 可能还有一 别的语言作为代码段。通过公共语言运行 时全部编译成自然代码(与此相对应<相反> 是象APS那样，每次都解析执行)。JSP使 用Java代码(段或者JavaBeans参考)，或者 编译成Java字节代码(按需或批编译要根据 JSP实现系统来决定)。 .Net公共语言运行时允许以多种语言的代码 (程序)在视窗环境下使用一组共享的元件。 优先于.Net框架的所有元件(公共元件、ASP.NET等)。
IL公共语言运行时 Java虚拟机和CORBA IDL和ORB Java的虚拟机规程，允许Java字节代码， 在任何平台上按JVM方式运行。 CORBA允许多种语言的代码使用一组共享 的对象，在任何带有ORB的平台上运行， 并不是紧密地集成到J2EE框架内。 同样的Web元件(如基于JSP的文件)在标准 的Java平台上是没有的，某些专有的元件 只能通过Java IDE等得到。
视窗格式和Web格式 Java的飘移 通过MS Visual Studio的IDE而不是在本文 所说的IDE，支持视窗格式和Web格式的 RAD开发，在许多Java的IDE和工具中都 支持“飘移”(Swing)。
ADO.NET和基于SOAP的Web服务 JDBC、EJB、JMS和Java XML库(XML4J、JA-XP) ADO.NET建立在位于HTTP协议顶部的XML数据 交换的基础上(指在远程数据对象和多个应 用程序捆绑之间的数据交换)。一般说来， .Net的Web服务假定了SOAP发信模型。 而EJB、JDBC等将数据交换协议和开发者 处理权分离，不工作在HTTP、KMI/JRMP或 IIOP顶层。
该表的比较只抓住了表面现象，这里再总结一下.Net和J2EE的比较：
l 特点：.Net和J2EE都提供同样优秀的特点，尽管提供的方法不同。
l 可移植性(Portability)：.Net的核心只工作Windows环境下，但从理
论上讲可以支持以多种语言开发(只要这些语言的子集/超集已经定义 好，并为他们建立了IL编译器)。也就是说：SOAP的能力允许在其它平台上的元件(部件)和.Net元件进行数据报文交换。而.Net中的一些元素：象SOAP，其恢复和查找协议，作为公共部份提供构架的核心部件(IL运行时环境、ASP.NET内部的视窗格式和Web格式元件“合同”等)仍由微软掌握，微软只扮演整个.Net开发环境和运行时环境提供者的角色。其实早就有了来自开发者协会要求微软公开这些规程，但是这和微软的标准经验相违背。
另一方面，J2EE只要遵循Java VM(规则)和一组平台需要的服务就可以在任何平台上工作(EJB包容器、JMS服务等等)。所有这些定义了J2EE平台的规程，都已经公开发表，并提供公众阅读。因此，许多供应商也提供兼容产品和开发环境。但是J2EE是单语言平台，若用其它语言调用或访问对象，可能需要通过CORBA，但是CORBA支持并不是平台普遍存在的部分。
巨大的前景：
上述最后的几点勾画出.Net和J2EE的某些关键性的差异，以及微软在这些方面所扮演的角色。微软现在正在为.Net做两件值得注意的事：通过将XML和SOAP集成到他们的信息传输方案中，从而为以其它编程语言开发商和非.Net部件打开通向.Net的道路。
通过让语言元件交叉互动，.Net正在释放Perl、Eiffel、Cobol和其它编程器，允许它们扮演微软“沙盘”的角色。这些语言的爱好者应该特别遵守规则，因为他们中大部分人在微软/SUN/OpenSource竞争中感受到约束和定界。因此，只要在他的元件发信层使用XML和SOAP，微软就能支持他们将开放性部件加到他们的平台上，从而摆脱对专用性的依赖。
正确的响应是甚麽？
对于微软的开发商，.Net是一个好的构架，你可以将许多事情交给微软的体系结构去完成。ASP.NET比ASP好，ADO.NET比ADO和DCOM出色，但有所差别，C# 比C和C++更好。.Net最初版将在2001年的某个时候可以得到，因此你有足够的时间准备。但是可以肯定，它将成为微软平台的缺省（约定）开发环境。如果您现在正在微软的开发构架中从事开发工作，将.Net的元件采纳到你的体系结构中，肯定能够获得利益。
但是，.Net平台的几个期望目标极高，但不能保证全部起步，至少在短期内完成不了。例如IL公共语言运行时在使开发者获益之前还有某些明显的障碍需要克服。想要把每一种语言和元件运行时集成起来，必须定义这种语言的子集/超集，并清晰地影射到IL运行时上，和必须定义结构，以便提供IL需要的元数据，然后和必须开发适用于两种编译语言结构（对象、部件等）的编译器（从XML到IL和从IL到XML），集成到IL部件字节代码中，同时还要生成对现有IL元件的语言专用接口。
这里还有一些历史的因由，必须开发非Java语言到JavaVM的众多桥梁，如：Jpython、PERCobol、The Tcl/Java Project。同时，如果有足够的兴趣，几年前就应将Bertrand Meyes和一些别的Eiffel folk一起放到Eiffel-to-Java VM系统中(几年后)，只有Jpython 例外。这些工具得到广泛的采纳，甚至在他们自己相关的委员会里也是这样，即使它们似乎能够提供一种方法，用你所偏爱的语言，为Java环境写代码(虽然不是整个J2EE构架)。然而为什么还这样缺乏热情？因为人们犹豫，不想承受从它们的开发语言中，将额外的翻译工作加到目标构架上。如果Java环境是目标，人们通常会选择学习Java。我预计，对.Net也是同样正确的。人们将会选择学习C#和用这种语言写.Net的部件。
另一点要注意：基于.Net的SOAP将用于分布式通信，谨防性能损失。SOAP基本上意味着在HTTP上的XML。HTTP不是一个高性能的数据协议，因此XML隐含一个XML语法解析层，也就是需要更多的计算开销。两者相结合会大大减少相对另一种发信/通信信道的事务处理速率。XML是一种非常丰富的、十分强大的发信用的元语言。HTTP是非常灵活可移动的，因此可以防止许多防火墙的损失，但是如果事务处理速率对你是优先考虑的话，请保持你的选项打开。
对于Java和开放资源委员会
请不要把.Net作为微软市场竞争的手段，继续以你们喜爱的方式理解.Net可能更容易接受。但是.Net并不是一种精巧的标志，而是微软策略的重大转移，将为其平台带来福音。他们正在为使其它的构架和平台在管理级上做得更好而奋斗。提供关于自身成本和无缝集成方面有用的可查询的统计资料。现在他们正努力把Java和开放资源自身所特有的元语言，逐步开放，然后力图直接满足开发商的需要。在过去一段时间里，由于他们没有做好，两件事情失败了。如果你认为自己是Java和无资源平台的福音的传播者，那么，竞争的性质就会改变。
另外，微软的IL运行时，至少可能有一个值得注意的目标：就是清除编程语言进入结构框架的障碍。Java清除了平台的障碍(当然在有限范围内，例如你不能没有硬件资源来制作软件)。但是为了用J2EE来作开发工作，你必须在Java环境下工作。而.Net是想让你使用你选择的语言来建造.Net应用程序，这是十分美妙的。尽管还有一些大问题没有解决。如：.Net中的IL方式什么时候和是否会实际上变成广泛使用的(工具)(如上所述)。不管怎样，这就表明了单语言的J2EE方式存在弱点。这个弱点的重要性可以怀疑，但是它依然存在，因此它值得Java委员会考虑。如果开发商真的认为是这样，那么就可以把力量放在Java字节代码生成器方面，以适应非Java语言，当然这需要组织和浓缩(汇总)。
再深入研究一下J2EE，立即可以得到一些结论。为了支撑该平台和.Net相较量的优势。首先XML支持要无缝地集成到结构框架中，我们且不说将XML SAX/DOM语法解析器作为一组标准服务或者在配置元件中，扩展XML的使用。这里需要XML的发信和操作处于随时可用状态。公认的做法是在JMS顶端用XML的内容发信，但是并不是所有的平台都有这种设施，XML空间是一堆杂乱无章的标准，非关键因素标准，API和DTD是你处理元语言时期望的。
但是微软已经将SOAP放在基础层，很难把某些可理解和有用的东西放到开发商手里。J2EE的倡议者需要用他们的平台做同样的事。记住一种可能性是将XML发信提供者层放在JMS的顶部。后面紧接着Java命名和目录接口或者带LDAP的JNDI、NIS和COS命名等等。这种和标准SOAP/BizTalk供应商，EBXML供应商等等的结合将是种令人印象深刻的语句(说明)。
澄清和更正：
由于本文在2000年8月份发表的，有40位读者以他们关心.Net和J2EE对比的想法返回给我们(见读者回信)，本文作者Jim Farley筛选过这些内容，同时用电子邮件回复他们，因此增加以下的澄清和更正。
澄清：
C#的编译特点和Java的编译特点对比似乎让读者产生混淆，为了更清楚一点，我们用另一种方法比较：C#代码总是以自然的形式运行。Java代码典型地是以解析型字节代码运行；C#可整个编译成自然代码，或者编译到公共语言运行时字节代码中，然后在执行期间逐次编译自然代码。另一方面，Java代码典型地以运行时解析型字节代码方式运行(据此，其交叉平台能力可以增长)。同时也能够以逐次编译上下文连接方式运行；也有了一些Java自然代码编译器(Jove、Bullet Train、JET等)。
作为旁注(附注)，微软要求遵循Java的约定解析性模式在这种模式中，设计用于虚拟机的字节代码，本身不用于自然代码优化，我没有看到有力的数据证明或反驳这个要求，(一般的应针对字节代码对比自然编译语言，或者特殊针对 Java对比C#)。
在回应中，有几位读者指出J2EE支持XML，这说明了这样一个事实：J2EE1.3版(现以草案方式发布)要求任何兼容J2EE的产品，必须包含Java XML SAX和DOM语法解析器。这正是我说的“把XML SAX/DOM捆绑到Java上。我已经要求他们采取进一步措施，以J2EE支持API方式直接支持XML协同工作。最理想的方法是基于J2EE的部件和服务，应让XML在某种程度上自动支持内建(对发信、接口描述、输出等)。
更正：
我在本文中说：C#“借用了某些JavaBeans的部件概念”。这句话没有证据，正如几位读者指出，更合适的说法是“微软C#的功能多于它们本身的COM和VB模型，这是由于来自其它已有的部件模型的影响".
