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
标签：
