.NET对Sun ONE: Web服务开发平台对比测试

象所有新的软件系统一样, Web 服务需要一个丰富的支撑结构才能够生存下去. 微软公司希望它为这个新的软件环境设计的.NET 构架, 虽然还没有实际的发布, 能够成为Sun Microsystems 公司 Sun ONE的有力竞争者, 后者是基于Sun 公司已经建立的Java平台。

IT 系统的关键部分是适当的开发工具能够使开发者容易的为.NET 或者是Sun ONE(开放式网络环境).eWeek Labs 测试了微软和Sun公司相应的高端开发工具, Visual Studio .NET 企业Beta 2 版和Forte for Java 3.0 企业版beta(也即早期发布版本),查看它们对开发Web服务的公司的支持效果如何.

Visual Studio .NET 会在今年年底发布;其价格还没有宣布. Forte for Java 3.0 企业版将很快发布在Windows NT 4.0,Solaris 8 和 Red Hat 公司的 Red Hat Linux 6.2 并且其定价为1,995美元.

在对开发工具做出战略性的选择的时候, IT部门首先应考虑一下什么平台对它们来说更适合.

因为是一切从头开始, 微软在.NET里为Web 服务和互联网编程设计了新的编程模型. 在未来的20年内,它需要最昂贵和最复杂的Windows 开发技术的升级过程, 并需要对员工进行重新培训, 以及不少的改变--从细小的部分到大的部分--到现存的代码库, 特别对于Visual Basic 和基于VBScript的ASP(Active Server Pages) Web页面是如此.

希望开发.NET应用程序的人会发现Visual Studio .Net是不可或缺的, 这不仅是因为它出众的可用性和与.NET的高度集成, 而且是因为它在这个领域没有什么竞争对手.

Java 平台在六年前发布的时候也处在相同的境地, 但是它现在已经成熟了, 经过了良好的测试, 是一种稳定的服务器端编程语言.

Java开发者因而有更多的开发工具可以选择. Forte for Java 引起了人们的注意, 因为它增加了对创建EJB(企业版JavaBesns)的支持,而且它还能够使其代码运行于Sun-Netscape联盟的iPlanet 应用服务器上(我们测试了iPlanet 应用服务器6.0)和对基于XML(可扩展的标记语言)的Web服务的支持. 但是, 它不得不与更精细的产品竞争, 比如说Borland 公司的JBuilder. 另外, Forte for Java 缺乏对SOAP(简单对象访问协议)的支持是它的一大缺点.

但是这两种平台都有很大的缺陷--这些缺陷更多的是因为销售商的策略而不是技术的问题. 当然,Forte for Java 只支持Java编程而Visual Studio .Net 提供了一个单一的编程环境, 支持C++, C#, Visual Basic 和 ECMAScript(但没有Java)语言.

据Sun官员说, Forte for Java 的未来版本将支持多语言的开发.

微软则在.NET周围围上了一层神秘的气氛, 它用这个术语来同时指它的技术和它产品的商标. 让我们来明确一下: .NET中真正的新鲜事物是.Net Framework(.NET 运行和类库)和C#, 它们都会与Visual Studio .NET同时发布.

微软的服务器端程序都以.net作为后缀, 但这只是销售策略--这些服务程序其实根本没有用到.NET Framework. 第一个真正的.NET服务器会是微软SQL Server的下一个版本, 但它直到2003才会发布.

我们还必须清楚一点, 微软的开发者会发现使用.NET需要作很大的转变. 实际上, Windows程序的开发已经很难再改变了. 从核心来说, .NET是Windows 和 Web编程的一套全新的API. 在大约生存了20年后, 成熟的Win32, Windows COM(对象组件模型) 和微软基本类库已经开始退休了.

所有这些API仍然得到了支持, 而原始的Windows 程序还是可以用Visual Studio 编写. 但是, 微软现在的方向是朝向.NET 开发.

.NET在开发基于组件的应用程序的时候提供了很大的帮助, 特别是对那些使用了Web和XML技术的程序有很好的支持, 这是因为它被加强正是因为如下的原因: 一个新的运行环境和共享的系统, 这个共享的系统允许将用任何.NET语言编写组件混合使用, 一个新的类库, 新的Web 表单界面和数据库访问技术, 基于XML的连接协议, 基于文件的配置过程(这标志着Windows 注册表未日的到来), 以及一个新的安全模型.

软件移植的费用将取决于IT 部门希望实现多少这些平台上的改变.

微软的C#是C和C++语言的一个简化的后继语言, 而且, 毫不奇怪的是, 它和Java非常的相似. 但是, C#还是要求开发者学习一种新的语言.

Visual Basic 和 VBScript 都被改变了, 所以在老的程序在新的.NET平台上运行以前必须作出修改.

"我们的平台保持了百分之九十六的兼容性, 这意味着所有的东西都将能够继续使用," 微软的Scott Guthrie在华盛顿的多特蒙得说, 他是负责ASP.NET中ASP VBScript 代码兼容性的首席工程师.

但实际上, 当我们将一个基于VBScript 的ASP在线书店转换成ASP.NET 的时候需要做无数的语法上的改动, 加上必需的括号, 远程集合定义语句并将到.asp的链接转换成到.aspx文件的链接.

但是, 在我们对Visual Studio .NET 的测试中, 我们发现Web 服务被完整的集成在了这个产品里. 我们可以通过仅仅在一个普通的子程序的前面加上"WebMethod"关键字就可以将它变成可通过HTTP调用的基于SOAP的Web服务, 而且Visual Studiao 将基于SOAP的Web 服务和原始的Windows对象一样同等对待.

"Transaction"关键字允许子函数自动的参与到事务处理中来, 而一个很酷的"XMLAttribute"关键字则让我们做简单的XML转换, 比如说不需要使用XSL(可扩展的风格页语言)风格页(当然如果你想用也是可以的)就能够改元素的名字.

Visual Studio .Net Enterprise Architect 提供了新的程序建模功能, 包括概念的, 逻辑的和物理数据库模型化工具, 和完整的UML(Unified Modeling Language 通用软件模型化语言) 1.2 的绘图功能, 代码生成和对转换工程的支持. Visual Studio .Net还包括了编写PDA(个人数字助理)和移动电话应用程序的工具.

许多IT可能还会喜欢上新的编码规则的功能(可以在XML配置文件中设置), 当我们没有遵循设置的编码和HTML 风格的时候,它能在Visual Studio .Net的新任务列表窗口里发出警告.

对于创建Web服务, ASP 在技术上获得了最大的提升. 正如我们前面说的那样, ASP是一个负载均衡的Web 脚本语言而且早已有些力不胜任了. ASP .NET 作为Visual Studio .NET中Web 应用开发最本质的东西, 被彻头彻尾的改写了(实际上在C#中也是这样). 就象其对手JSP(JavaServer Pages) 一样, ASP .NET 现在也成为了一种编译语言.

如果开发者明确的定义他们的变量类型, 那么ASP程序会和C#一样快--也就是说, 它比以前快多了.

还有一个大的性能上的改善, 那就是ASP.net 增加了一个新的参数确定的缓冲子系统, 它能够缓冲整个页面, 或者页面的一部分,或者个别的Web 服务, 而缓冲的期限则由一个时钟或者是对文件系统的改变或者是一个应用程序事件来决定. 这是ASP. NET的一种改进, 以便它能跟得上潮流; Oracle, IBM 和Macromedia公司早就发布了拥有不同形式的缓冲方法的应用服务器.

ASP.NET有一个现代的状态处理机制; 目前ASP 的Session 对象是不能在串中使用的, 因为它不能远程的保存状态信息. 我们现在能够把状态信息保存在本地, 或者是在另一台服务器上的微软SQL Server 7.0 或 SQL Server 2000 数据库里.

我们不再需要Cookie了; 只要在ASP .NET 应用配置文件web.config 里设置"cookieless" 选项, ASP.NET就在URL里自动加上一个对话的标识符.

ASP 和ASP.NET使用不同的文件扩展名而且能够同时在同一个服务器上运行, 虽然它们并不享会话信息.

测试结果: Visual Studio.Net Enterprise Architect Beta 2

Visual Studio .Net 获得了Web和Windows 应用程序代码设计, 编辑和编译开发环境的最高分. 新的编码规则功能使得这个版本的开发平台对于已经建立了编码规则和设计风格的企业来说是特别有用的. 如果纯粹追求高的生产效率, Visual Studio .Net 遥遥领先.

短期的商业影响//无数的富有想象力的诸如动态帮助, 很好的代码自动完成和内建的任务列表功能极大的提高了编码效率, 但是.NET平台的这些改变, 必然引起培训和代码转换的费用.

长期的商业影响//这个版本的Visual Studio 能够使微软平台软件开发商们在转向新的.NET运行环境和C#语言的过程中可能遇到的棘手的问题平滑化. 它集中于基于标准的Web服务的开发将降低集成和B2B应用开发的费用.

优点:界面美观, 支持多语言应用程序开发和编辑的开发环境; 包括完整的前后端数据库支持和UML建模; 基于SOAP的Web服务和原始的Windows 对象一样得到了支持; 在HTML和原始的Windows 应用程序设计方面非常强大; 对PDA和移动电话开发支持的良好的尝试; 编码规则功能有助于标准化编程过程.

缺点:缺乏对Java的支持; Vidual Basic和ASP强制的语法改变要求对现有的应用程序进行代码转换.

不象.NET, Sun公司的Sun One 开发战略并不是高度的依赖于一种工具(即使是它自己的工具). Forte for Java 3.0企业版是这个领域强有力的竞争者, 它提供了一个很大的功能集合.

而与Visual Studio .Net相同的是, Forte for Java提供创建可以通过HTTP访问的高层对象的工具, 对XML和XSL编辑的强有力的支持, Web 脚本编写和底层编程的工具, 数据库编辑工具, 和源代码控制工具.

Forte for Java 3.0 企业版允许我们创建会话和实体EJB, 这是这个产品中的主要改变, 它使得Forte for Java 3.0 能够直接和其它高端的Java 开发工具竞争, 包括 Borland 公司的JBuilder 企业版.

虽然没有 Visual Studio .Net那样强大的编辑功能,Forte for Java提供了Java和JSP的编辑环境. 例如, Forte for Java 没有在文件中搜索和替换的功能, 也不能自动完成变量名.

使用其新的EJB 模板向导, 我们能够创建会话和实体EJB并在属性框里编辑它们的属性(目前这种支持在高端的Java工具里业已成为标准). 我们随后在iPlanet应用服务器和Sun 公司的J2EE(Java2 企业版)Reference Implementation 服务器上安装了这个测试用的EJB, 并在Forte for Java里注册了它们.

Forte for Java 3.0 企业版引入了一个新的支持Web功能的JavaBeans 和EJB系统. 使用新的Web服务向导, 我们创建一个基本的Web 服务然后选择我们应该用XML界面捆绑哪个Java方法.

不幸的是, 当我们使用这些功能创建Web服务的时候, 我们不得不使用基于XML--而不是其它的技术--的企业服务表示形式, 它可以通过Sun为这个目的提供的自定义JSP 置标库来进行访问 .

Sun 公司还发布了Macromedia的Dreamweavr和Adobe Systems 公司的GoLive Web 页面编辑工具的集成软件来为使用这些软件的用户自动化添加企业服务表示JSP置标的过程.

在Forte for Java的下一个版本中将提供对SOAP的支持.

测试结果: Forte for Java企业版3.0

使用Java 开发的大公司会发现Forte的这个新的企业版更适合它们的需要, 尤其是当它有了EJB和XML支持的时候. 但是那么开始使用Web 服务的公司希望使用一个支持SOAP的工具.

短期的商业影响//使用iPlanet 应用服务器的公司会因为Forte for Java 而提高它们的生产效率, 因为它比iPlanet的老的Application Builder 开发工具要好得多.

长期的商业影响//新的对会话和实体EJB的支持功能, 以及对J2EE程序的支持; 对基于XML的Web服务的支持; 可以将应用程序直接安装到iPlanet 应用服务器里; 包括TeamWare 源程序控制系统.

长处:新的对会话和实体EJB的支持功能, 以及对J2EE程序的支持; 对基于XML的Web服务的支持; 可以将应用程序直接安装到iPlanet 应用服务器里; 包括TeamWare 源程序控制系统.

缺点:缺乏对SOAP和其它标准的Web 服务的支持; 编辑环境功能较弱; 需要几百兆的内存才能很好的运行.