正确的响应是甚麽？
对于微软的开发商，.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语言，当然这需要组织和浓缩(汇总)。
