首页 > 编程 > .NET > 正文

J2EE vs. Microsoft.NET 之 Web Services

2024-07-10 13:05:00
字体:
来源:转载
供稿:网友
j2ee vs. microsoft.net 之 web services
                   ——建置xml架构的web services之比较
作者:佚名    本文选自:cnjsp  2002年04月30日
i. 序

在本文中,我们将深入的比较两种可用来建置商业xml web services的平台,分别是sun microsystems 所提供的java 2 enterprise edition (j2ee)以及microsoft所提供的 .net平台。

虽然j2ee代表的是一个公开的标准,而 .net是单独一家厂商的标准 (虽然.net试图取得ecma的标准,但是却只有在最基础的部分被ecma采纳变成标准,请参考http://msdn.microsoft.com/net/ecma/,在企业的应用上却没有标准化),反观java平台,确是所有除了microsoft以外的各大厂商都遵循着jcp的标准制定所有规格 (请参考http://www.jcp.org ,您会发现所有的java技术都是协调各大公司而来)。

尽管在标准化上java遥遥领先,但我们仍然将只针对服务器端的web services架构做探讨。例如:我们的讨论将不涉及 jini 或是office xp,我们也不会讨论java跨足solaris、linux、mac os x、以及windows平台,而.net只跨windows 98/me/2000/xp等windows平台的事实。我们更不会讨论 "跨语言" 这个java早已试图达成,microsoft又拿来当成.net的重大特点,却根本不是这回事的功能。(请参阅http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html,大家可以发现java早就达到所谓跨语言的功能,smalltalk、eiffel、lisp、prolog、basic等语言都可以顺利转换成java bytecode,不像.net号称跨语言,却出现cobol.net这种怪物,原本的语言要削足适履来配合.net,所以才产生vb.net、cobol.net这一大串产品)。号称跨语言喊了半天,原来连自己的vb 6.0都跨不过去。在读完本文之后,您将会更加了解这两种架构的彼此优缺点,而且在制定贵公司下一代web services决策时将有更明确的考量。

ii. 前言

下一代的分布式运算时代已经来临了。在过去几年中,xml 被广泛的运用于电脑运算环境中,以达到在全球信息网上共享信息的远大目标。如今,它可以更进一步地提供运算能力上的分享。从技术的观点来看,web services的出现并不能算是分布式计算机运算的新革命。它可以结构化的呈现信息,甚至是程序内部的讯息,因而很自然地比xml应用程序更加引人注目。

iii. 工业标准与企业标准

透过web services,任何应用程序可以在网络上顺利地整合在一起。web services的基本原理是利用标准的网络协议(例如:http)来传送xml讯息。这是一种非常轻便的沟通机制,因此可以让任何程序语言、中间层组件或平台很轻易地整合进来。一般工业上或企业内部会接受成熟且广为厂商采用的业界标准,更尤其是已经受过市场考验行之有年的标准。有了web services,您就可以快速且低成本的整合两个企业、部门或甚至是两个程序。

要建置web services必须得采用业界通用的web services技术。现在让我们来看看web services究竟是什么。首先您必须先知道如何建置以及使用web services。其实web services是种很简单的xml界面,适用于商业、应用程序以及系统服务。说穿了也就是将既有的技术旧衣新穿而已。web services其实是一种新一代的分布式服务,在这之前,有corba、dcom、com+、rmi,都是用来实作分布式架构的技术,而且也被证明运作的非常顺利;而新一代的分布式服务,采用的是xml技术,如xml-rpc和soap就是最佳的例子,新一代的分布式技术可以用寄有的通讯协议做基础(如smtp、ftp等),但是目前最受欢迎的方式仍然是将xml基植于http这个广受欢迎,但是效能并非最佳的通讯协议上。即使如此,这些新一代的技术尚未通过时间的考验,或许他们有可能运作得很成功,也可能有些许的风险存在。

面对这么多的分布式技术,j2ee平台与.net平台的支持程度如下表:

对旧有分布式技术的支持:

j2ee.netcorba支持不支持rmi/iiop不支持com+不支持支持

对新一代web services的支持:

j2ee.netxml-rpc支持不支持soap支持支持

从上述两个图表之中我们可以得知,对于姿态保守的公司而言,j2ee支持了较为广泛应用于现有企业系统的分布式运算服务,而.net平台仍然只支持延伸自com与dcom的com+,其技术前身mts com+比enterprise javabeans技术早了三年,不消说,我们可以推断j2ee提供的分布式服务比.net的技术领先三年。此外,目前企业内部使用之大型主机所使用的皆为corba技术,j2ee对旧有技术的支持当然是最佳的,因为com+只能在windows平台上运行。

如果是态度前卫的公司,使用j2ee者可以选用xml-rpc(http://java.sun.com/xml/jaxrpc/index.html)或是soap(http://java.sun.com/xml/jaxm/index.html)技术,sun microsystems更提供了 java web service developer pack (http://java.sun.com/webservices/webservicespack.html) 供开发者开发web services。反观.net技术,只提供对于soap的支持。在对于既有分布式技术支援不足的情况下,对新一代分布式技术的支持又无法提供弹性的选择,风险之大,是可以预估的。

就算新一代的web services非常稳定好了,他的稳定度常常会被底层作业系统的稳定度所影响,如果你选用.net,就会被绑死在公认最不稳定的windows平台上,更糟糕的是,.net还只能在microsoft官方的网页服务器上运作,相信之前使用iis的朋友,在遭受过nimda等不断出现的病毒恶梦之后,会不会对其安全性与稳定性产生质疑? 但是,如果您选用的是j2ee技术,那么在诸多遵循标准的厂商所提供的应用程序服务器中,您可以选择最符合您需要,成本最低,而且又认为最佳的平台。

您可以到http://www.soapware.org/directory/4/implementations查询既有的soap实作品,看看有多少是针对java所设计的实作品。

总而言之,我们就平台的稳定性,服务器的稳定性,以及产品的多样性这三方面来考量,j2ee彻底击败.net技术。

下列的技术都是已为业界所采用,而且也是通往web services的最佳途径:

- 提供web services的人员使用自己的程序语言、组件与平台来开发、连接与布署web services。

- 提供web services的人员以wsdl (web services description language)定义web services。wsdl文件可以让其它人知道web services的功用。

- 提供web services的人员以uddi (universal description, discovery, and integration6)将web services注册。 uddi让程序开发人员可以布署web

- 使用者透过uddi登录来找寻web services。

- 使用者的程序会结合web services,并透过soap (simple object access protoco) 或xml-rpc来呼叫web services。xml-rpc或soap 在http协议上提供一 份xml格式的讯息传递。这是所有web services共同的沟通协议。

请注意,上述的机制是建置web services并让它运作的一种途径。虽然有其他方法可以做到,但我们认为这些技术是最重要且将广为业界采用的一种。

由此可知,实际上我们尚未有一致的方式来建置web services,建构上仍然有许多的困难需要克服。以soap、ebxml以及服务串流的规格来说,众家厂商意见各异了。而且soap最常被宣传的: 与程序语言无关,与特定平台无关这两项特点,会在您尝试着使用apache soap与microsoft soap toolkit产生的web services进行沟通时,彻底地粉碎(译注:这是因为xsi:type属性在实作上有分歧的关系)。除了是对于实作上细节的理解有差异之外,更重要的原因是因为有人刻意地破坏标准。

即使如此,对于web services来说,仍然有不少好消息:

- 很难得的,所有的厂商,包括sun microsystems与microsoft等大厂,均同意soap、 wsdl以及uddi 是有潜力的好产品,因此他们将在未来的产品中进

- 所有意见不一的厂商都团结在一起,共同为建立web services的标准并广植 web services的应用而努力。

iv. 使用j2ee 以及microsoft.net来开发web services

如果您想开发一个有用的网络服系统。所面临的挑战并非表面上所看如此简单。您的web services必须可靠、普及、不容易出错、有弹性而且必须让大家愿意接受。这些严格的要求并不亚于任何企业等级的商业应用程序。

j2ee 以及 .net 是现有用来开发服务器端企业级应用程序的技术延伸。这些技术的早期版本并非专门用来开发web services用。如今web services已经成为趋势,于是两大阵营也随之调整各自平台的解决方案,因此您现在已经可以使用这些技术来开发web services了。j2ee 以及 .net的共通愿景就是希望能达成开发web services的基础工程,例如:跨平台的xml沟通、负载平衡以及交易。与其自己重新撰写这些基础工程,倒不如在可提供这些服务的平台上撰写应用程式。

但是,当开发到一定规模的应用程序时,会产生一定的复杂度,这个时候就必须有开发工具的辅助,如果您选用了其中一种平台,那么您可以选用的工具如下表所示:

开发新一代web services的开发工具:

j2ee平台的工具有 :

  • jbuilder (borland)
  • forte for java (sun)
  • weblogic workshop (bea)
  • jdeveloper (oracle)
  • visualage for java (ibm)
  • visual cafe (webgain)


.net平台

只有visual stdio.net

从这里可以看出,您可以在您既有的企业解决方案提供厂商那边,取得最佳的工具和解决方案,而且从免费的基本版本到付费的专业版本都有,各人可以根据不同的需求来做最佳的选择,而不是只能寻求单一厂商所提供的工具和解决方案。

v. j2ee

java 2 platform, enterprise edition (j2ee) 被设计成专门用来解决多层式企业解决方案的开发、布署以及管理上的问题。在sun microsystems 所带领的诸多厂商的努力之下,j2ee 已经成为一种业界标准。对您而言,最重要的一点就是,您必须先了解j2ee是一种标准,而非一种产品。您不能说"下载"

j2ee,而是下载一系列的adobe acrobat pdf 档案,这些档案会仔细说明应用程序与所在容器(container)之间的运作规定。透过遵守j2ee的规定,应用程式可以被部署在各种平台上的容器中。j2ee阵营的目标是提供客户有多重选择产品与工具的机会,并以此带动良币驱逐劣币的效应,让最好的产品成为市场上的赢家。要达成此理想的唯一的方法就是所有的厂商都要符合j2ee标准。

在交易安全方面,sun microsystems更与许多提供电子商务平台的厂商合作,例如:bea、ibm以及oracle等,共同制定j2ee。sun microsystems更发起一个java标准制定组织java community process (jcp),专门随时构思新决策来改善j2ee。 sun microsystems之所以这样作的理由是因为,要达到电子交易安全最好的方法,就是要请所有的专家共同来制定严格的规范--唯有这样的作法才能成功地达成他们整合市场的目标。j2ee 是一种java的应用。您的j2ee 组件必须被转译成bytecode并在java的执行引擎下执行jre。值得一提的是,即使是相容于j2ee平台的容器,大多数都是以java技术实作而成的。相较于microsoft.net在正式发行没多久时间就因为安全上的错误而发表service pack1来说 (详见http://support.microsoft.com/directory/article.asp?id=kb;en-us;q317396&sd=msdn&,使用.net却还没有去下载的朋友请赶紧连上去看看,以免恶梦重现) ,我们应该更了解一件事,就是:安全性是大家的事,决不是单一厂商就能决定的。

vi. j2ee 以及web services。

j2ee 在以往的java程序语言中被定位成开发伺服端应用程序的架构。它可以被用来建置传统的网站,软件组件或是web应用程序(web application)。到了最近,j2ee更被扩充成可支持xml web services的标准。这些web services可以和其他用j2ee或非j2ee标准所开发的web services沟通。

j2ee应用程序存在于一个容器之中,这个容器提供企业级应用程序所需的服务,当然也具有企业所需要的品质,例如:交易、安全以及persistence services。

商业层级负责商业程序与资料逻辑。在大型规模的j2ee应用程序中,商业逻辑是利用enterprise javabeans (ejb) 组件技术所建置。由此可知,这个层级专门用来负责商业程序以及资料逻辑的处理。它可以透过java database connectivity (jdbc)、sql/j来连接数据库,或是透过java connector architecture (jca)技术来连结既有系统。它更可以利用java用来处理xml的api (jaxp, java api for xml processing),并透过web services技术(包括:soap、uddi、 wsdl以及ebxml)来连接其它协力厂商所提供的商业应用程序。因此协力厂商们可以透过web services技术(包括:soap、uddi、 wsdl以及ebxml)让j2ee程序彼此连接起来。所以只要利用java servlets (这是一种支持http请求/响应的java技术)就可以从协力厂商的web services中接受请求了,并予以响应。java servlets使用jaxp/jaxr/jaxm/jax-rpc等技术来提供web services运作时的所有功能。web services目前是扩充链接库的型态存在,目前已经着手将web services并入j2ee下一版的规格之中,并成为业界共通的标准。传统的客户端程序,例如java applet或桌面应用程序,将直接以internet inter-orb protocol (iiop)来连接ejb组件而非透露web services,如果要使用web services也可,但是因为通常客户端的应用程序都会和j2ee应用程序出自同一家厂商,因此根本不需要xml web services来扮演沟通的角色,就算真的有需要,也是没有问题的。浏览器以及无线装置则可以连接到java server pages (jsp),这些jsp则有着各企业自行使用html、xhtml或wml所设计的使用者界面。

vii. 微软的 .net 平台

microsoft .net 是一项可以让企业开发智能型与企业级web services的产品。在此要特别注意的是,.net与j2ee最大的差异:.net是一项产品策略,而j2ee则是一项标准。microsoft.net可说是windows dna的大翻修,这是微软先前提供开发企业级应用程序的平台。windows dna 包含许多现有产品的技术,包括microsoft transaction server (mts)与com+、microsoft message queue(msmq)以及microsoft sql server 数据库。而新的 .net framework 则是设计来取代这些技术的,并加入web services层级以及程序语言的改进。

.net应用程序存在于一个容器中,这个容器提供企业级应用程序所需的服务,

例如:交易、安全以及讯息服务。.net应用程序的商业层级是透过.net managed 组件所开发的。这个层级负责商业程序与资料逻辑。它可以透过active data objects(ado.net)来连接数据库,或是在现有的系统中使用microsoft host integration server 2000所提供的服务,例如:com transaction integrator (com ti)。当然它也可以透过web services技术(包括:soap、uddi、 wsdl以及biztalk)来连接协力厂商的商业应用程序。因此协力厂商们可以透过web services技术(包括:soap、uddi、 wsdl以及biztalk)让.net程序彼此连接起来。传统的客户端程序、浏览器以及无线装置则可以连接到active server pages(asp.net),这些asp.net则有着各企业自行使用html、xhtml或wml所设计的使用者界面。

viii. 比较分析

就产品上市时间而言:

在今日的市场上若要开发一个商业上的解决方案,时间就是金钱。错失一个小小的机会,影响所及,将导致一个公司成为市场先驱或成为落后的追赶者。要加快产品上市时间的方法之一就是选择可以快速开发程序的web services平台。这将让开发人员可以快速地开发与维护程序代码,降低开发时程。sun j2ee 与microsoft .net 两者都提供一些执行机制,让软件开发人员可以避免触碰到一些底层复杂的部分。除了在平台、程序语言以及企业架构上支持xml web services的中间层外,sun j2ee 以及 .net还分别透过java runtime environment (jre)与common language runtime (clr)提供基础层面的服务。 j2ee还提供许有多.net没有的功能,这些功能可以加速产品上市时间,例如: 状态管理服务,这让开发人员可以撰写较少的程序代码而且不用管理状态,因此可以说是高阶且快速的软件开发环境。状态管理服务可以让您开发组件保持状态。persistence services (entity beans)让程序开发人员在开发应用程序时,不需额外撰写连接数据库的程序代码,因此让数据库程序将变得易于开发与维护。programmatic transactions让您可以拥有更多的交易控件。而custom tags 让程序开发人员与网络设计人员可以更紧密地合作。



最后,我们觉得j2ee与.net所提供的这两种程序的开发环境是完全不同的。.net号称有强大的程序开发工具 visual studio.net,java也有各家厂商(borland、sun、bea、ibm等) 的整合式开发工具可供选择使用; 在学习难度和系统设计及开发过程上面,.net也是完全采用java自始就采行的对象导向分析设计技术,学vb.net或是c#要花的的工夫和学java没有两样,而且到系统架构设计上,ooad、uml、design patterns等方法也是双方都采行的标准步骤。所以在就平台的稳定性,服务器的稳定性,以及产品的多样性等方面来考量,j2ee彻底击败 .net技术,两者在程序开发上的方法也归于一统,j2ee又已经经过这几年市场上众多企业用户的实际检验,所以我们相信比较起前科累累而且还在婴儿期的 microsoft .net系列技术来说,j2ee 是一个成熟稳定、高效能、而且自由开放的选择。

<全文图文并茂版请至 http://www.javatwo.net>

[/td]
发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表