当前页面: 开发资料首页 → Java 专题 → J2EE vs..NET-建置XML架构的Web Service
J2EE vs..NET-建置XML架构的Web Service
摘要: J2EE vs..NET-建置XML架构的Web Service
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 .NET
-----------------------------
CORBA 支持 不支持
RMI/IIOP 支持 不支持
COM+ 不支持 支持
对新一代Web Services的支持:
J2EE .NET
-----------------------------
XML-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 是一个成熟稳定、高效能、而且自由开放的选择。
Java, java, J2SE, j2se, J2EE, j2ee, J2ME, j2me, ejb, ejb3, JBOSS, jboss, spring, hibernate, jdo, struts, webwork, ajax, AJAX, mysql, MySQL, Oracle, Weblogic, Websphere, scjp, scjd
↑返回目录
前一篇: Classpath的困惑
后一篇: 克服J2SE 1.3 ~ 1.4不兼容问题