WEB开发网
开发学院WEB开发Jsp 且看微软的.Net和Sun公司的J2EE如何对垒(2) 阅读

且看微软的.Net和Sun公司的J2EE如何对垒(2)

 2008-01-05 08:59:38 来源:WEB开发网   
核心提示:正确的响应是甚麽? 对于微软的开发商,.Net是一个好的构架,且看微软的.Net和Sun公司的J2EE如何对垒(2),你可以将许多事情交给微软的体系结构去完成,asp.net比ASP好,这句话没有证据,正如几位读者指出,ADO.NET比ADO和DCOM出色,但有所差别

正确的响应是甚麽?

对于微软的开发商,.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模型,这是由于来自其它已有的部件模型的影响".

 


Tags:微软 Net Sun

编辑录入:爽爽 [复制链接] [打 印]
赞助商链接