分享
 
 
 

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

王朝java/jsp·作者佚名  2006-01-08
窄屏简体版  字體: |||超大  

正确的响应是甚麽?

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

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有