D
dhl2001
Unregistered / Unconfirmed
GUEST, unregistred user!
注：原文请从http://61.155.114.20/xmlchina/download/book/j2eevsdotnet.doc
下载
Java 2企业版(J2EE)
VS
.NET平台
关于电子企业的两种设想
Roger Sessions
ObjectWatch, Inc.
March 28, 2001 6:59 AM
本白皮书版权归德克萨斯奥斯汀ObjectWatch有限责任公司所有。保留所有权利。禁止进行未授权的复制或再次发布。要获得复制或再次发布许可，请联系：roger@objectwatch.com。
绪论 4
关于MoneyBroker 5
电子企业需求 5
典型的电子商务体系结构 6
.NET平台体系结构 7
.NET Framework与Visual Studio.NET 8
.NET企业级服务器 9
UDDI协作基础结构 10
.NET平台：将一切合并到一起 13
J2EE体系结构 14
Java语言系统 15
客户端程序设计模型 15
中间层基础结构 16
程序员企业级API 16
J2EE：将一切合并到一起 17
J2EE与.NET平台的相似点 17
J2EE与.NET平台之间的差别 18
开发商中立性 19
整体成熟性 19
互用性与网络服务 20
可伸缩性 21
架构支持 24
语言 25
可移植性 26
客户端设备独立性 28
结论 28
术语表 30
商标信息 32
作者简介 32
致谢 32
绪论
一个没有赢利计划的电子商务站点就像一辆没有汽油的汽车。它看起来可能会很漂亮。可能会给人留下深刻印象。它可能会让你付出很大的代价。但最终，它哪里也不能去。
去年，人们对这个教训有了深刻的理解。电子企业（EBusiness）一个接一个地破产，但这并不是由于缺少客户，而是由于缺少在这些客户上赢利的计划
在即将到来的一年中，赢利将会像过去一样非常重要。但是，赢利的模式将从基于竞争转变为基于合作。用反话来讲，那就是最具竞争力的公司将是那些不必为竞争担心，而将主要精力集中在协作上的公司。
对于商务而言，橄榄球比喻（“将你的对手压扁！”）已经过去了。未来的商务比喻是交响乐团。整体协作的成功将决定每个单位的成功。
在电子商务中，协作意味着通过合作关系开展销售活动。这意味着利润共享。利润共享迫使我们在协作的每个步骤对盈利模式进行仔细检查。我们需要以最可能低的成本，让技术在协作环境的每个步骤中为电子商务服务。
今天，对于电子企业和电子企业协作有两种技术设想。一种是微软公司的设想，整体称为.NET平台。另一种是Sun公司的设想，整体称为Java 2企业版( Enterprise Edition，J2EE)。
在该白皮书中，笔者将对.NET平台和J2EE进行比较。笔者将会把重点放在笔者认为在未来的5年内将会对电子企业起推动作用的主要问题：协作与盈利能力上。笔者将讨论这两个平台的技术细节，但只讨论那些影响协作或盈利能力的细节。
需要指出的是，J2EE是一种规范，而不是一种产品。许多开发商在产品中实施了这种规范。最重要的两个J2EE开发商/产品是IBM'公司的WebSphere和BEA公司的WebLogic。根据Cutter Consulting 公司最近的研究报告，这两个开发商占据了J2EE市场59%的份额。Sun公司虽然只占有很小的份额，但却很重要，因为它控制着J2EE规范。
将J2EE的每个实施细节都与微软公司的.NET平台进行比较超出了本白皮书的范围。笔者将对Sun公司（J2EE规范的所有者）定义的整体J2EE设想与微软公司定义的整体.NET平台设想进行比较。为了使得整个讨论更精确，笔者将会把这个问题与一个假想的企业MoneyBroker联系起来，但是虽然这只是一个假想的企业，但所讨论的问题却与任何一个电子企业有关。.
关于MoneyBroker
MoneyBroker只是一个用于说明的假想企业。我们假定MoneyBroker的用途是允许进行在线支付。客户可以在一个MoneyBroker帐户内存款，然后在线进行支付帐单。为了吸引客户，MoneyBroker对于未付的存款余额支付利息。
客户可以直接或间接地支付帐单。直接支付在MoneyBroker 网站进行，客户可以登录、安排帐单支付。间接支付通过MoneyBroker合作伙伴进行。MoneyBroker合作伙伴是指那些在客户订购时，可以接受客户的MoneyBroker货币的零售商。当一个客户访问AustinKayaks.com（另一个假想的企业），订购一艘价值500美元的皮艇时，AustinKayaks.com可以提供的一种选择是通过MoneyBroker帐户支付。
MoneyBroker通过将未付的客户存款进行投资赢利。向帐户所有者支付的利率与投资获得的利率的差即为公司的赢利。
电子企业需求
MoneyBroker为了支持电子协作（eCollaboration，electronic collaboration），运行MoneyBroker的计算机系统必须包含一定的能力。在我的经验中，最重要的需求是：
· 互用性 – 系统必须能与协作系统共享信息。
· 可用性 – 系统必须高度可用；第一次由于MoneyBroker 系统停机而导致AustinKayaks失去一次销售机会，它将会很不高兴。第二次，AustinKayaks将会终止合作关系。
· 吞吐量 – 系统必须能支持高事务处理吞吐量，因为支付请求不仅来自于MoneyBroker自己的网站，而且间接地来自其合作伙伴的网站。
为了赢利，总的系统成本必须尽可能地低。在我的经验中，最重要的系统成本的决定因素有：
· 开发成本 - MoneyBroker系统的设计和实施成本。
· 系统管理成本 – 管理MoneyBroker系统的成本。
· 单位生产成本（Unit of Work Costs） - 处理MoneyBroker支付的成本。
· 可伸缩性成本 – 随着客户群的增加，给整个MoneyBroker系统添加吞吐量的成本。
在本白皮书中，这些问题将是笔者重点讨论的主要问题：3个主要的协作需求（互用性，可用性和吞吐量），4个主要的系统成本（开发成本，系统管理成本，单位生产成本和可伸缩性成本）。
典型的电子商务体系结构
现在的基于网络的电子商务体系结构通常是以如图1所示的3层结构和两个防火墙为基础的。这些体系结构并不支持电子协作。我们将在后面讨论支持电子协作所必需的变化。
图 1. 3层电子商务体系结构
图1中所示的每层都有一个用途，一种体系结构，一个API。在本节中，笔者将给出一般的体系结构概述。在接下来的两节中，笔者将分析J2EE和.NET平台的差别
表示层负责与客户端的工作。利用MoneyBroker应用程序，这一层与基于浏览器的支付瘦客户端一起工作。
表示层接受来自网络浏览器的HTTP请求，然后返回一个浏览器可以显示的HTMl页面。不同的浏览器有不同的显示能力，因此表示层必须常常适应特定的浏览器（或其他瘦客户端设备）的HTML。
大量的商务逻辑在商务层内实施。对于MoneyBroker，包括保留客户帐户的逻辑，以及在支付帐单时转帐的逻辑。由于商务层位于表示层和数据库层之间，通常被称为中间层。
表示层通过一种方法传输协议，与商务层进行通信。对于.NET平台，这个协议通常是DCOM或SOAP。对于J2EE，这个协议是RMI/IIOP。
在J2EE和.NET平台中，商务逻辑通常被打包成了组件。一个组件就是通过详细定义的接口，用来进行交互的商务逻辑。
组件常常与对象（利用这项技术，它们通常有历史关系，但在其他方面有很少的共享内容）混淆。特别是，控制面向对象的程序设计和组件打包规则有很大的不同。笔者最近讨论了这两种技术的区别 ，因此将不在此对此重新讨论。
商务逻辑通常需要昂贵的资源，如数据库连接，线程，TCP/IP连接，和消息队列连接。这些资源需求通常使得在任何时刻支持大量的客户端都变得很困难，而这则是大多数电子商务应用的一个需求。
为了解决这个问题，J2EE和.NET架构的商务层都包括一个复杂的、支持客户端中间资源共享的中间层结构。这种结构对于支持大量的客户端，获得高系统吞吐量是至关重要的。在J2EE中，这个中间层结构被称为Enterprise JavaBeans (EJB)。在.NET架构中，则被称为COM+。
第三层是数据库层，实际数据存储在该层中。对于MoneyBroker系统，数据库层用来存储客户的帐户信息和帐单支付记录。
尽管大多数大型企业还有利用驻留在数据层中的数据库的内部应用程序（不是通过电子商务体系结构），商务层仍是数据层的主要客户。商务层和数据层之间的通信使用特定的API进行：.NET架构使用ADO.NET，J2EE使用JDBC。
现在，让我们对这两种技术进行更详细的分析。
.NET平台体系结构
整个.NET平台体系结构可以分为4个主要部分：
· .NET基础设施和工具：用来构建和运行电子企业系统的基础设施和工具，包括Visual Studio.NET，.NET Enterprise Servers，.NET Framework。
· .NET基础服务：.NET服务包括一组用于Internet的信息共享服务，如Passport.NET (用于用户身份验证)，以及用于文件存储、用户偏好管理、日历管理的服务。这些服务将由微软公司以及微软的合作伙伴提供。
· .NET用户体验：这将是一个更广泛、更适应的用户体验，信息可以各种方式、在各种不同设备上提供。
· .NET设备：这种设备软件使得可以使用新的可以利用网络服务的智能Internet设备。
.NET Framework与Visual Studio.NET
也许.NET平台最重要的部分是.NET Framework。这是一个与操作系统紧密相关的综合运行环境。它包括面向组件的中间层基础结构(COM+)，Common Language Runtime (CLR) 环境，一个准时制编译器，一组使用.NET组件模型打包的操作系统库。.NET系统(可能不包括数据层，笔者将在互用性中进行讨论)中服务器侧的每层将运行支持.NET Framework的操作系统。
与.NET Framework密切相关的是主要的程序员开发工具，Visual Studio.NET。表示层程序员使用Visual Studio.NET来定义向瘦客户端系统提交HTML页面的逻辑。商务层程序员使用Visual Studio.NET以多种语言实现商务逻辑，然后将商务逻辑打包为COM+组件。
Visual Studio.NET是中性语言。它被认为是最好的开放的程序设计平台，可以插入多种语言。可以与Visual Studio .NET一起使用的“标准”微软语言由VisualBasic，VisualC++和VisualC#。其他语言可以通过第三方获得，包括富士通（Fujitsu）公司的COBOL语言，Interactive Software Engineering公司的Eiffel语言。许多其他种与Visual Studio兼容的语言，包括Haskell，Mercury，Oberon和Perl正在由大学研究方面进行调查。
Visual Studio.NET (实际上，是整个.NET平台)的语言中性对于.NET平台策略是至关重要的。它是通过将所有Visual Studio.NET语言翻译成一种称为Intermediary Language (IL)的通用语言而实现的。实际上，它是通过语言开发商创建的使他们的语言与Visual Studio.NET 兼容的IL翻译器实现的。这样的语言被称为.NET支持语言（.NETenabled language）。
IL文件通常以可部署的称为汇编组件（assemblies）单位进行打包。这些汇编组件被加载到通用运行语言（Common Language Runtime，.NET Framework的一部分）种，由IL编译器进行编译，然后在通用运行语言（Common Language Runtime ，CLR）内运行。CLR提供了许多特性，我们可以将这些特性与一种特定的语言联合起来，包括碎片收集，类型定义，多型方法解析，错误处理，和部署模型。
将语言特性合并到一种通用运行语言（CLR）中，而不是合并到一种特定的语言中，使得各种语言可以自由地在整个.NET平台内互用。碎片收集，类型定义和错误处理都以一种统一形式进行处理，从而实现了无与伦比的语言互用性。也许跨语言互用性给人印象最深刻的例子是在一种语言（比如说，C#）内定义一个基类，然后以一种完全无关的语言（比如说，COMBOL）重写各种方法。笔者在最近的文章中曾给了这样一个例子。
在表示层使用.NET Framework意味着，任何支持.NET的语言（换句话说，任何有IL解释程序的语言） 都可以用作表示逻辑的脚本语言。并且由于.NET Framework包括编译器，它还意味着对表示层脚本进行编译，而不是进行解释，从而显著地改善了性能。
我们正在看到，各种类型的瘦客户端（浏览器，蜂窝电话，电子写字板，等等）开始迅速增长，每一种客户端都支持自己的HTML子集。今天的表示层脚本必须首先确定客户端的类型，然后为该客户端创建特制的HTML。这种操作非常费时，易出错，并且在新客户端系统变得可用时很难维护。
Visual Studio.NET包括一个新的表示层程序设计模型，该模型设计用来简化为瘦客户端系统的激增所进行程序设计工作。这种新的程序设计模型称为ASP.NET。ASP.NET允许表示层逻辑为客户端中性。这种程序设计模型是以今天非常成功的VisualBasic程序设计模型为基础的。With ASP.NET, the presentation tier scripts ask controls (such as menus or pull do
wn boxes) to act in certain ways, and then
respond to events that those controls raise. It then
becomes the control's responsibility to deliver its functionality using the HTML best suited for a given client device.
设计一个ASP.NET应用程序只需将GUI控件（如菜单或下拉工具箱）从模板投放到设计桌面上。然后程序员以任何支持Studio .NET语言编写对控制事件响应的代码。由控件，而不是由程序员负责根据客户端的实际设备确定最好的解释方法ASP.NET架构负责判断客户端采取特定的动作（如按下按钮）。由于所有这些都是在表示层发生，因此同一个代码基可以正确地工作，而不论实际的客户端设备是否任何.NET技术。
控件/事件程序设计模型，将设备感知内置到了表示控件而不是表示逻辑中，从而大大减少了开发和维护阶段的工作。开发工作减少了，是因为一个简化的代码块可以解释客户端的需求，并对任何最终客户端设备的HTML需求进行处理。维护工作减少了，是因为我们可以通过下载我们使用的最新版本的控件，加入对新的客户端设备的支持。
.NET企业级服务器
.NET企业级服务器是一组附加的、设计用来提供专用的企业级服务的服务器产品。每个服务器产品都是单独定价的，从而在配置整体解决方案方面提供了最大的财务灵活性。一个企业只需为所需的服务付费。
最出名的企业级服务器是微软公司的Probably the highest profile SQL Server。这是微软公司的高端数据库产品，该产品的许多功能已经远远超过了本文的范围。足可以说，SQL Server是具有高性能、高可用性、高可伸缩性的关系数据库，是企业市场中一个强有力的竞争者。
但是，对于.NET平台使用户依赖SQL Server，没有任何意义。许多组织机构使用整个.NET平台来创建他们的电子商务系统，他们可以选择自己的数据存储技术，如Oracle或DB2。每个流行的数据库系统都可以用作.NET数据层。例如，Oracle可以通过数据库中性的ADO.NET接口访问。大型机数据库，CICS和IMS可以通过Host Integration Service (HIS)访问。
最新的.NET企业级服务器是Application Center Server（应用中心服务器） Server。这个产品是专门为那些需要24X7可用性和/或低伸缩成本的公司而设计。Application Center Server既是一个群集协调者，又是一个群集管理者。
Internet Security and Acceleration Server (Internet安全与加速服务器，ISA Server)重点解决表示层的需求。It ISA Server提供了两个重要功能：HTML页面缓存，可以显著提高许多重点的性能，以及防火墙功能。当然，防火墙功能对于保证任何重要的电子商务站点的安全是至关重要的。ISA Server为基于硬件的防火墙产品提供了一个低成本的软件解决方案。冒着冗余的风险，ISA可以与其他.NET产品一起使用，但这并不需要。
BizTalk Server是一个综合的、集成产品，主要用来将各种组织机构的操作联系在一起，并且允许该组织机构与合作伙伴的操作互用。
Commerce Server是用于创建电子商务站点的架构。它重点是解决电子商务零售业务的需求。使用Commerce Server提供的组件，并进行专门化，就可以快速地创建这样的网站。
UDDI协作基础结构
协作是电子企业的未来。正在定义以支持电子协作的行业标准集可以在Universal Description, Discovery, and Integration (UDDI)下进行分组。
虽然UDDI独立于.NET平台，但是大多数UDDI相关活动都是由微软公司倡导的。这样，看起来在.NET平台部分中描述UDDI比较合适。
UDDI标准归uddi.org协会所有，一点也不奇怪，该协会的网站为www.uddi.org。该协会由Ariba，IBM和微软公司领导，同时包括100多个支持公司，包括Andersen Consulting，波音，康柏，戴尔，惠普，福特，Loudcloud，Merrill Lynch，Rational，SAP AG，Sterling和Sun。要了解当前的支持者清单，请访问该协会网站。
UDDI是在一组现有的、获得广泛支持的基础标准上建立的。这些基础标准包括：
· HTTP – 用于在Internet上进行通信的标准协议。
· XML – 一个用于对数据和有组织字符串打包的、被广泛接受的工业标准。
· SOAP – 一个迅速出现的标准（主要由微软公司和IBM公司领导），用于对客户端工作请求和作为XML字符串的系统相应进行打包。SOAP代表简单对象访问协议（Simple Object Access Protocol）（这是一个令人迷惑的简称，因为它既不简单，也不与任何对象相关!）.
HTTP和SOAP组合被认为是未来所有的电子协作的基础。在本白皮书中，当笔者讨论SOAP时，将假定使用HTTP作为传输协议。尽管其他协议（如那些基于信息队列的协议）可以用来传输SOAP请求，但在电子协作体系结构中，这将是不可能的。
图2为最常见的基于电子协作体系结构的SOAP协议。由于在例子上下文中更容易进行解释，笔者将使用最初的电子企业原型MoneyBroker。让我们看看MoneyBroker是如何使用SOAP与AustinKayaks协作的，最终的结果是AustinKayaks允许客户使用MoneyBroker帐户付款。
图 2. 典型的基于电子协作的 SOAP协议
让我们根据图2，观察AustinKayaks和MoneyBroker 之间的电子协作。在使用浏览器工作的AustinKayaks客户(1)访问AustinKayaks URL，然后要求购买一个皮艇时，电子协作开始。请求作为HTTP请求(2)通过Internet传输。AustinKayaks表示层(3)接收到该请求，该表示层通过该站点使用的任何一种本地协议(4)向商务层发出请求。如果AustinKayaks是一个微软站点，那么本地协议可能是（但并不一定是）DCOM。
AustinKayaks商务层现在认识到，需要向MoneyBroker商务逻辑请求支付。 这个请求是在本地(处理中的)SOAP代理(5)上作出的。SOAP代理将支付请求打包为一个SOAP请求，然后使用HTTP (6)，通过Internet将其发送给MoneyBroker站点，在MoneyBroker站点请求被MoneyBroker表示层上的一个SOAP接收器 (7)接收。
SOAP接收器 (7)的唯一用途是将SOAP请求翻译为本地请求，通过本地协议(8)将其传输给MoneyBroker商务层 (9)，请求在此进行处理，并完成支付。然后，结果从MoneyBroker商务层被返回给AustinKayaks表示层，该表示层可以将结果翻译为适合该AustinKayaks客户的浏览器的内容。
SOAP是技术中性的。AustinKayaks和MoneyBroker不需要在使用何种技术建设网站上以致，只要各自的技术支持SOAP技术能够互用即可。
对于允许AustinKayaks使用MoneyBroker服务来说，SOAP功不可没，但是只有在AustinKayaks已经知道4件事情时才可以：MoneyBroker存在；可以找到MoneyBroker的URL；,MoneyBroker可以提供的服务；以及MoneyBroker 可以接受SOAP请求的确切格式。如果AustinKayaks不知道这些又怎么样呢？如果AustinKayaks只知道它需要帐单支付服务，但不知道哪些存在，它们位于何处，以及如何使用它们，又会怎样呢？
这就是使用UDDI的原因。UDDI定义了允许电子协作各方可以彼此找到的标准。描述UDDI标准的所有内容已经超出了本白皮书的范围。
这就是UDDI起作用的地方。UDDI定义了使得潜在的电子协作者可以彼此找到对方的标准。描述所有的UDDI标准（这些信息可以从网上获得 ）已经超出了本白皮书的范围，但是我们将讨论如下方面：
· 注册设备的URL，包含关于工业标准接口的信息，如帐单支付服务。
· 已经承诺支持工业标准接口（如MoneyBroker）的具体公司。
· 到这些设备的SOAP接口，潜在的协作者可以编程使用这些接口彼此找到对方。
· 一种用于描述SOAP接口的标准的技术中性语言。
在UDDI功能标准(HTTP, XML, SOAP)与UDDI电子协作标准之间，我们有一种技术中性的架构让企业一起工作。
.NET平台已经包含了XML和SOAP技术。微软公司是UDDI计划的三个领导者之一（其他两个为Ariba和IBM），因此很清楚这三个标准一成熟，我们就可以看到它们会被合并到.NET平台中。
我们有一个专门的小组来描述SOAP可以随时支付的商务逻辑，该小组的站点三使用了合适的UDDI标准来使得SOAP服务可以广泛使用。我们将这样的商务逻辑称为网络服务（Web Service）。
.NET平台：将一切合并到一起
图3显示了.NET平台的所有部分是如何结合到一起的。应将该图与显示这种体系结构的一般形式的图1进行比较。
图1. .NET平台电子商务体系结构
J2EE体系结构
与.NET平台相比，Sun公司的标准定义的J2EE体系结构有很少可以讨论的空间，因为就没有什么可讨论的。如果一个人注意某个具体开发商的产品，如IBM公司的WebSphere，那么就会看到其技术的最大的一部分是WebSphere专用的。比较所有开发商对J2EE的具体改进，已经超出了本文的范围，在我的经验中，大多数对J2EE作为一个平台感兴趣的公司对该标准的可移值性感兴趣。任何对可移值性感兴趣的人都会需要将他们自己局限于Sun公司所定义的标准。
J2EE体系结构可以被分为5部分：
· Java语言系统
· 客户端程序设计模型
· 中间层基础结构
· 程序员企业级API
· 非程序员可见API
最后一部分，非程序员可见API，包括定义了如何将其他产品插入到J2EE中的API，如连接器API，以及J2EE模型中被最近的改进有效替代的API，如JTA（Java Transaction API）。由于从比较微软和Sun公司计划的角度来说，非程序员可见API并不重要，因此在笔者的概述中将不涉及这些方面 (就如同笔者在.NET平台概述中并没有涉及功能相当的API一样)。
Java语言系统
在高层次上，Java语言系统看起来与.NET Framework类似。在这两种情况中，源代码都是被翻译成一种中间语言。但是，在.NET平台中，这种中间语言是MSIL，而在Java系统中，是Java Byte Code。在这两种情况中，中间语言被带入到运行环境中。在Framework中，运行环境是Common Language Runtime。对于Java，运行环境是Java虚拟机（Java Virtual Machine）。总体而言，Common Language Runtime和Java虚拟机有类似的功能，并且在技术进步方面，都无可置疑地在发展和彼此交互跃进。
这两种系统之间最重要的区别与源代码到中间语言的翻译有关。在.NET平台中，中间语言设计用来适应各种语言的需求。在Java中，中间语言设计用来满足Java的需求。虽然从理论上，从除Java外的语言生成Java Byte Code是可能的，但是实际上这还没有在任何一种商业产品中证明。
客户端程序设计模型
J2EE客户端程序设计模型重点集中在与浏览器的交互上。客户端程序设计模型有3部分：Java Applets，Java Servlets和Java Server Pages。
Java Applets用来对在浏览器内运行的Java代码进行打包。在.NET平台空间中，这在功能上与ActiveX相当。在笔者的经验中，applets或ActiveX组件使用的相对较少。电子商务体系结构一般都是以向表示层发出请求的浏览器为基础，然后表示层使用HTML页面进行响应。这种系统并没有使用ActiveX或Java Applets，因此笔者在本白皮书中并没有讨论这些技术的任何一种。
处理HTTP请求和HTML响应的重要技术是Java Servlets 和Java Server Pages 。这两种技术与微软空间中的ASP.NET（Active Server Pages）类似。
.NET平台与Java表示层中间的主要区别在于处理不同的客户端功能的方式。Java表示层沿用了以前的Microsoft ASP (pre .NET)模型，它使得表示层程序员的责任是决定最终的目的浏览器（或其他瘦客户端系统），瘦客户端系统的功能，以及如何生成HTML来充分发挥瘦客户端系统的优势。
中间层基础结构
对于J2EE，中间层基础结构是Enterprise Java Beans (EJB)。该规范的当前版本是2.0，可以从网上获得 。与J2EE相当的.NET平台是COM+。
在EJB和COM+之间，体系结构的差别非常少。这两种体系结构本质上是从MTS（Microsoft Transaction Server）派生出来的，是由微软公司在1996年引入的最初的面向组件的中间层基础结构。由MTS最先引入，然后合并到EJB和COM+中的重要想法包括：
· 通过组件示例的共享所实现的高可伸缩性
· 以中间层为中心的安全性
· 自动事务处理边界管理
EJB加入了一种新的体系结构想法，一项自动管理组件状态的技术。这项技术被称为entity beans（实体豆）。虽然这种想法具有吸引力，但是当前的实施却依赖于独立于数据库缓存的中间层数据缓存。很不幸的是，在这两种缓存之间没有保持一致性的机制。这意味着对实体豆的任何使用都会带来数据库损坏的高风险。在缓存一致性问题解决之前，在最佳试验技术方面，必须得不断考虑实体豆技术。
要连接EJB和COM+的深入比较，请参阅笔者最近的著作 。
程序员企业级API
我们调用Java Enterprise API 时的最重要部分如下：
· Java Database Connection (JDBC，Java数据库连接) 2.0 – 是用于从Java中访问关系型数据库的API 。这与.NET平台空间中的ADO.NET相当。
· Java Naming and Directory Interface (JNDI，Java命名与目录接口) – 是用于从Java中访问企业名称与目录服务的信息的API 。这与.NET平台空间中的Active Directory Services Interface (ADSI，活动目录服务接口)有点类似。
· Java Message Service (JMS，Java消息服务) 1.0 – 是用于异步工作流的Java API 。这在功能上与Microsoft Message Queue API相当，这个API已经被排队组件所替代。
J2EE：将一切合并到一起
图 4 显示了J2EE主要部分之间的关系，可以将其与图3和和图1进行比较。图3显示了.NET平台的相当的形象描述，图1中显示了相当的一般体系结构。
图4. J2EE电子商务体系结构
J2EE与.NET平台的相似点
图2中给出了J2EE与呢平台之间的所有相当之处。正如你所看到的，许多.NET平台功能范围在J2EE中没有对应功能。在某些情况下，至于是否支持这些功能，如果支持，支持情况如何，被认为是一个实施明确的决策，注意：要了解不熟悉的缩写词，请查看术语表。
图 2. 技术对应
技术 .NET J2EE
支持技术
发布协议 DCOM, SOAP RMI/IIOP
防火墙 ISA* 没有定义-
HTML页面缓存 ISA*, ASP.NET 没有定义
表示层技术
基础结构 IIS 没有定义
程序设计模型 ASP.NET Servlets, JSP
高可用性 NLBS*, ACS*, 其他 没有定义
负载平衡 NLBS*, ACS*, 其他 没有定义
管理 ACS* 没有定义
中间层技术
基础结构 COM+ EJB
程序设计工具 Visual Studio.NET 没有定义-
高可用性 ACS* 没有定义
负载平衡 ACS* 没有定义
安全性API COM+ Security Call Context JAAS
消息队列API MSMQ JMS 1.0
异步组件 Queued (COM+) Message driven beans (EJB 2.0)-
命名与目录服务 ADSI JNDI
数据层技术
分布式事务处理 MS-DTC JTS
关系型数据库API ADO.NET JDBC 2.0
层次型数据库API ADO.NET -
数据库存储 SQLServer** -
大型机数据库连接性 HIS* Java连接器
架构技术
电子商务架构 Commerce Server* -
B2B BizTalk Server* -
* 对于.NET平台是可选附加服务。
** SQLServer是正式的.NET平台数据库技术，但是可以使用任何支持ADO.NET的数据库，包括大多数数据库。
J2EE与.NET平台之间的差别
你可以看到在J2EE与.NET平台技术之间由很大的重叠。但是，如何在它们之间进行选择呢？在本节中，笔者将讨论我所看到的主要差别。
开发商中立性
许多公司购买J2EE，他们相信这可以给他们开发商中立地位。而实际上，这是Sun公司计划的一个确定目标：
配置和实施各种满足J2EE规范需求的产品是可能的。一个可移植的J2EE应用程序在这些产品 中的任何一个产品中被成功部署后，都可以正确地运行。
实际上，在不是Sun J2EE对手的人中，很少有人相信这是可以实现的。Paul Harmon是最重要的独立J2EE发言人之一，他是Cutter Consortium的首席顾问，广泛发行的Architecture/e-Business E-Mail Advisory的作者。虽然Harmon总是反对J2EE，但他最近对J2EE的开发商可移植性写了这样不同寻常的坦诚的评价。
EJB模型是否已经达到了我可以将EJB组件从一个EJB应用服务器移动到另一个服务器的程度？在大多数情况下不能。EJB规范不够全面。通过提供专有的解决方案来完善这个模型，确保他们的客户可以创建生产系统，EJB应用服务器开发商弥补了这一点。
Harmon总结了当今开发商中立的情况， 他的评论如下：
此刻，现实情况是如果你想开发一个EJB应用程序，你应当忠心于一个开发商。
今天的现实是，没有像开发商中立这样的情况。当然，.NET平台不是开发商中立的，它与微软公司的操作系统捆绑到了一起。但是两者都不是J2EE的实现。笔者可以给的最佳建议是，选择某一开发商，计划与其始终站在一起，这样可以充分利用该开发商所提供的平台优势。
整体成熟性
第一个J2EE规范，EJB规范在1998年提出，而第一个β版本出现于1999年。而这则是在与之相当的.NET平台技术，MTS，COM+的前身第一次实现的3年之后了。笔者在最近的一篇文章 中讨论了从MTS到COM+的发展过程。
在.NET平台比J2EE早出现两年的情况下，了解.NET平台比J2EE平台更成熟就不足为怪了。虽然我们有大量的使用.NET技术的高度可靠的网站（NASDAQ和戴尔就是众多例子中的两个），但我们不知道有哪个网站使用了J2EE平台。Paul Harmon又作了如下评论：
今天，任何一个正在尝试[基于J2EE的]公司范围的企业级系统的公司，都在尽力工作，更好的方法是让一个真正优秀的开发团队来帮助他们摆脱困境。更重要的是，它可能应当重新考虑一个综合的项目，并满足于初始近似。
互用性与网络服务
诸如笔者详细讨论的，.NET平台电子协作模型是以UDDI和SOAP标准为基础的。这些标准被100多家公司广泛支持。微软公司，IBM和Ariba是这个领域的领导者。Sun公司是UDDI协会的会员，并且认识到了UDDI标准的重要性。在最近的新闻发布会上，Sun公司负责Java群体开发的付总裁George Paolini说：
“Sun公司一直在工作，以帮助建立和支持开放的、基于标准的技术，来促进基于网络的应用的增长，并且我们认为UDDI是一个重要的、为B2B电子商务建立一个注册架构的项目。”
但是虽然Sun公司公开说相信UDDI标准，但实际上，Sun公司没有采取任何措施将任何一种UDDI标准合并到J2EE中。这包括最基本的、已经有一年多的UDDI标准，SOAP。正如IBM公司的Rod Smith（Emerging Technologies公司副总裁，该公司是Sun公司最强大的合作伙伴之一）所说：
迄今为止，Sun公司还没有对[UDDI]网络服务发表过得评论。但是我认为这样是有原因的。我认为他们正在考虑Java。当我们考虑网络服务的时候，我们正在倾听客户的声音和他们的需求，但事实是，客户已经有了不基于Java的系统和Java应用程序。因此，Sun公司仍然在坚持Java，但是在这个问题上非常平静。
实际上，Smith对Sun公司的互用性策略的分析一语中的。Sun公司将重点主要集中在了J2EE开发商与CORBA开发商的互用性上。Sun公司的互用性想法是，应当以所谓的IIOP通信协议为基础。
利用基于IIOP的互用性，有三个主要缺陷。
第一，它需要全世界都运行J2EE或CORBA，这是一个连Sun公司的合作伙伴都反对的假定。IBM公司的Rod Smith解释了IBM支持SOAP，而不是支持IIOP作为互用性开放标准的原因：
当发布声明，并说我们[IBM]将把SOAP作为开放标准，并将其相应提前时，响应是令人无法置信的和积极的，因为人们希望进行这样的集成工作。他们拥有基于微软的解决方案。他们同时拥有基于Java的解决方案。他们还拥有基于[Windows] NT的解决方案和基于Linux的解决方案。
第二个缺陷是，像所有通信协议一样，IIOP 应当服从在Internet上进行传输。这使得它不可能作为普遍的电子协作机制。
第三个缺陷是，即使全世界都同意使用IIOP和J2EE，即使在J2EE开发商中，对于确保互用性当前的IIOP规范也是不适当的。正如Paul Harmon所说的那样：
来自不同开发商的EJB应用服务器是否以能在更大的系统中咬接的方式实行了标准化？尽管使用Internet InterORB Protocol (IIOP)来支持EJB间的应用程序通讯，但仍不能随便地在一个网络中将多个EJB产品结合在一起。 将每个都依赖几个非标准工具进行平稳通信的两个EJB应用服务器仍然需要进行一些重要的程序设计工作。
今天的现实情况是，与J2EE相比，.NET平台有一个更加强大的技术中性的电子协作策略。IBM公司深信不已，UDDI，而不是IIOP才是正确的互用性方法，在这个问题上，这已经与Sun公司决裂了。在这一点上，令人痛苦但却很明显的是，尽管在UDDI上已经领先了10年，但却是一个完全的失败。
可伸缩性
可伸缩性是指添加更多工作量的能力。一般来说，附加的工作量是客户的增加引起的。可伸缩性是一个复杂的问题，笔者已经在几篇已经可以得到的文章中对此进行了深入探讨 。未来简化这个讨论，笔者将在MoneyBroker可能会在接下来的3年中遇到的问题的上下文中讨论可伸缩性。笔者将进一步简化这个讨论，而只考虑运行商务层和数据库层的成本，尽管对表示层进行类似的分析可能会得出类似的结果。
让我们假定，MoneyBroker的商务模型要求它今年每天处理10笔支付，明年为100万，而后年则为1000万。选择J2EE/Unix解决方案或.NET平台/Windows解决方案的相关成本有哪些呢？
为了判断MoneryBroker在接下来的3年中所需的机器规模，我们需要一个事务处理性能的标准的基准。事务处理吞吐量的工业标准基准是由所谓的Transaction Performance Council (TPC)协会规定的，该基准被称为TPC-C基准。TPC会员包括Sun、IBM、Oracle、BEA、微软和其他大部分销售中间层/数据库层产品的公司。
TPC-C基准评定了一个系统可以获得的最高工作量的等级。TPC-C基准定义的测量单位为tpmC，代表每分钟交易处理数（transactions per minute）。除了说该基准考虑的是在分布式订单输入系统环境中的交易处理外笔者将不对其进行讨论。该基准的说明可以在TPC网站 得到。
在MoneyBroker使用TPC-C数使其平台成为用户选择方面，正在面临两个问题。
第一个问题是TPC-C规定的交易处理与MoneyBroker交易处理完全不同。这需要MoneyBroker彻底审核TPC-C规范，猜测在工作量中多少 TPC-C交易才能与一个MoneyBroker交易相当。我们假定MoneyBroker计算得出它的一个交易与10个TPC-C交易相当，从而有大量的富余用于处理错误。
第二个问题是，没有一个J2EE开发商已公开发布自己的TPC-C数。这使得MoneyBroker很难计算J2EE实施的吞吐量，即AIX。有趣的是，虽然所有重要的J2EE开发商已经提交了TPC-C基准，但没有一个开发商已经提交了基于他们的J2EE技术的TPC-C数。
例如，对于IBM公司的WebSphere技术（包含在J2EE技术中的IBM公司的一个品牌）有6个基准。但是，如果有人研究WebSphere的结果，就会发现没有一个基准的代码是使用Java编写的，并且没有一个基准使用了任何的WebSphere J2EE性能。实际上，这些基准使用了IBM公司传统的Encina事务处理监控技术，该产品是同时包含在总的WebSphere品牌下。类似地，BEA公司使用了其传统的Tuxedo技术来运行他们的基准，Tuxedo技术是其WebLogic品牌的一部分，但是却没有包含在J2EE中。
由于我们没有J2EE性能数字，我们得必须估计J2EE实现的相关性能。由于J2EE 基于传统的事务处理监控程序（开发商已经确定了基准），但是仍然会增加Java程序设计语言。Java虚拟机和EJB（中间层）的开销，比较合理的推测是J2EE将可以完成与之相当的非J2EE系统（如Tuxedo性能）50%的性能。因此，笔者将使用一个50%调节系数来估计J2EE的吞吐能力。
下面我们使用TPC-C 信息对MoneyBroker行为进行分析。MoneyBroker正在试图确定购买何种系统。显然，MoneyBroker希望花费尽可能少的资金，但仍确信可以获得在客户使用量达到峰值时所需的吞吐量，还确信它的系统可以进行伸缩以满足接下来的三年内的需求。
今年MoneyBroker每天需要处理10万笔交易。这相当于每分钟处理70笔交易，峰值时大约为每分钟处理700笔。由于一个MoneyBroker交易处理等于10 tpmC交易，这等于工作量达到峰值时大约为7000。明年，这个数目增加10倍达到70000 tpmC，而后年，这个数目再增加10倍，达到700000 tpmC。
那么，在接下来的三年中，这些系统需要哪些支出(包括硬件和软件在内)？让我们从J2EE/Unix的可能支出开始，因此笔者将考虑在IBM公司的AIX操作系统、WebSphere和Oracle 8i系统中，哪一个最能代表J2EE/Unix系统。对于这种配置，有6个基准。按tpmC从最低到最高的次序排列，以及J2EE调整（前面已经讨论），结果如下：
公司 系统 tpmC 总系统成本
Bull Escala T610 c/s 16,785 $1,980,179
IBM RS/6000 Enterprise Server F80 16,785 $2,026,681
Bull Escala EPC810 c/s 33,375 $3,037,499
IBM RS/6000 Enterprise Server M80 33,375 $3,097,055
Bull Escala EPC2450 110,403 $9,563,263
IBM IBM eServer pSeries 680 Model 7017-S85 110,403 $9,560,594
如果我们考虑某些有代表性的.NET平台系统（这些系统太多，不可能全部考虑，但数字非常一致），结果如下：
公司 系统 tpmC 总系统成本
Dell PowerEdge 4400 16,263 $273,487
Compaq ProLiant ML-570-6/700-3P 20,207 $201,717
Dell PowerEdge 6400 30,231 $334,626
IBM Netfinity 7600 c/s 32,377 $443,463
Compaq ProLiant 8500-X550-64P 161,720 $3,534,272
Compaq ProLiant 8500-X700-64P 179,658 $3,546,582
Compaq ProLiant 8500-X550-96P 229,914 $5,305,571
Compaq ProLiant 8500-X700-96P 262,244 $5,305,571
Compaq ProLiant 8500-700-192P 505,303 $10,003,826
你可以理解MoneyBroker 面临的选择。今年它只需一个7000 tpmC系统。在Unix市场这将大约花费200万美元，而在.NET平台市场则需要花费27.3万美元。明年MoneyBroker将需要一个70000 tpmC系统，在J2EE/Unix市场需要花费950万美元，而在.NET平台市场则需要花费350万美元。后年，MoneyBroker则需要一个700000 tpmC系统。这些系统中，没有一个被评定为700,000 tpmC，但到面前为止最靠近的系统是1000万美元的.NET平台系统。如果一个与之相当的J2EE/Unix机器存在的话，估计需要花费4750万美元。
很明显，如果系统的成本是一个重要的考虑事项，与J2EE相比，.NET平台有很大的优势。可以预计要获得相同的功能，需要花的费用是在.NET平台上所花的费用的5到10倍。如果一个工作单位在.NET平台上花10美分，同一个工作单位则可能需要在J2EE/Unix上花50美分到1美元。
笔者需要再次指出，虽然这些.NET平台基准是实际机器的实际基准，但在这些J2EE基准中，没有一个真正存在。这些基准是外推基准结果，实际的系统不一定能真正获得这些结果。在J2EE开发商发布他们的基准数之前，我们必须记住，没有一个J2EE平台已经被证明可以任何代价的情况下处理这些高工作量。
架构支持
当创建一个大型的电子商务解决方案时，不用说没有人希望从头开始。而是希望在已经完整定义的、结果测试的电子商务架构基础上创建解决方案。使用这样的架构可以极大地降低开发成本，可能至少降低10倍。
.NET平台包括一个所谓的Commerce Server电子商务架构。在这一点上，在J2EE空间内没有与之相当的开发商中立的架构。利用J2EE，你应当假定你需要从头创建你的新的电子商务解决方案。Paul Harmon看来同意这种评价，说：
此外，无论选择哪一个[J2EE]开发商，如果你期望一个允许你很快实施的完善的电子商务应用程序，你将会有令人沮丧不已的体验。
如果使用MS Commerce Server作为你的电子商务基础，那么很可能会对开发系统的成本有很大的影响。Commerce Server尤其适合零售业务。这样的电子商务系统应当仔细考虑这项技术。
语言
在语言方面，选择很简单。J2EE支持Java，并且只支持Java。在可预见的将来，它将不会支持其他任何种语言。.NET平台支持出Java以外的其他任何种语言（尽管它支持一种在语法和功能上与Java相当的语言，C#）。实际上，倘若.NET平台像一辆语言独立的车辆一样重要，在不远的将来，很可能任何一种出现的语言都支持.NET平台。
某些公司对J2EE支持其他语言所打动。尽管IBM公司的WebSphere和BEA公司的WebLogic支持其他语言，但是他们都不是通过J2EE技术实现的。在J2EE平台种，只有两种正式的方法来访问其他语言，一种是通过Java Native Interface，另一种方法是通过CORBA互用。Sun公司推荐采用后一种方法。正如Sun公司著名的科学家和Java设计师Rick Cattell在一次采访种所说：
你可以通过Java Native Interface功能和通过CORBA调用C++。CORBA可能是推荐的方法，因为它通过了更大的灵活性，并且我们已经设计了在认可的环境中能够很好地与CORBA一起工作的J2EE 。
在CORBA体系结构中创建任何新代码都是一个很有问题地策略。CORBA是20世纪90年代受人喜爱地体系结构，但现在已经不再使用了。据笔者所了解，没有一个CORBA开发商（除IONA外）在CORBA上盈利，并且没有一个开发商（包括IONA在内）在继续向该技术投资。底线是如果有人希望以Java以外的任何一种语言进行开发，那么J2EE是不正确的平台选择。
当前某些非Java公司正在考虑在Java上进行重新标准化的可能性。要实现这一点，有三种可能的方法：
· 对现有职员进行再培训
· 雇佣新职员，并尽可能地替换现有职员
· 外包
再培训可能是最昂贵的选择。以我的经验，有很大的管理费用与将传统的程序员培训成精通面向对象的Java程序员有关。这是Gartner集团最近的研究的结果，得出得结论是将一个COBOL程序员培训成Java程序员，每人大约需花费6万美元 。 笔者相信，对于Visual Basic程序员，费用大体相当。并且在训练结束，你在生产力方面一无所得。你可以简单地雇佣一个现在可以编写与花费6万美元进行培训后编写的代码相同，但现在就可以使用Java编写该代码的程序员。在许多公司中，笔者曾经看到由于采用面向对象的技术损害生产力的情况，工作时间通常会浪费在了无休止的和没有成果的关于“正确的”面向对象的设计与分析的理论讨论上。
雇佣和/或替换职员同样代价昂贵。当前，Java程序员所要求的薪水比传统的Visual Basic/COBOL程序员高30%。在笔者的经验中，他们还有更高的新雇人员比率。
对于希望转向Java的公司来说，外包可能是唯一可行的选择。但是，假定外包可以完全使你摆脱上面提到的问题是不现实的，很显然，尤其是额外的程序员成本被转移给你的情况下，更是这样。
那么你应当使用什么语言呢？底线是，如果你有经过Java培训的职员， 并且已经有了合适的策略来确保对程序设计过程的有效管理，那么尽一切办法坚持下去。笔者个人喜欢使用Java作为程序设计语言，尽管笔者认为至少有其他好的语言。另一方面，如果你的店铺主要是由Visual Basic和COBOL组成，那么转向Java差不多肯定会是代价昂贵的、令人沮丧的一次体验。
你的语言选择并不会必定决定你在J2EE和.NET平台之间的选择。当然，如果你希望使用Java以外的某些东西，那么你就处于J2EE空间之外了。但是，Java的吸引力并不需要剥夺你使用.NET平台的权利 。.NET平台包括对C#（发音为C Sharp）支持，该语言是一种与Java很类似的语言，以至于许多人第一眼还不能将它们分辨开来。一个有经验的Java程序员可以在几小时内学会C#语法。
但是，如果你选择Java不是因为J2EE所声称的可移植性策略，那么C#或任何其他可以在.NET平台上运行的语言不大可能会让你愉快的。如果这样，很明显J2EE是你的选择。但是，在做出选择之前，一定要阅读有关可移植性的章节。.
可移植性
J2EE的许多吸引力在于可移植性方面的承诺。有两种可移植性。的一种是开发商可移植性。笔者将这种可移植性称为开发商中立（vendor neutrality），前面已经讨论（并拒绝）了这种想法。第二种可移植性是操作系统可移植性（operating system portability）。这指的是在不对代码做任何改动的情况下，将代码基从一个操作系统转移到另一个操作系统的能力。与开发商中立不同，大多数J2EE实施最可能采取操作系统可移植性。
J2EE最可能会采取操作系统可移植性的原因是，在很大程度上并不是由于J2EE任何固有的可移植性，而是大多数J2EE开发商支持多种操作系统。因此，只要一个公司忠诚于一个既定的J2EE开发商和一个既定的数据库开发商，从一个操作系统转向另一个操作系统是可能的。这可能是唯一一个最重要的J2EE平台超过.NET平台的益处，而.NET平台仅限于Windows操作系统。但是，微软公司向ECMA（对JavaScript进行标准化的团体）提交C#规范和.NET Framework的一个子集（称为Common Language Infrastructure）毫无价值。
为什么开发商可移植性/中立令人满意很明显，但是操作系统可移植性有什么好处呢？我们认认为，一般有两种类型的公司需要操作系统可移植性：独立软件开发商（ISV，Independent Software Vendor）和寻求可收缩性解决方案的公司。
独立软件开发商（ISV）在有大量的非Windows平台客户群时需要操作系统可移植性。一个开发商不可能向依赖于.NET平台的Unix客户销售一件产品。如果.NET平台比J2EE好还是不好无关紧要。它并不在Unix上运行。
如果独立软件开发商的产品必须销售给非Windows客户，尤其是当J2EE平台本身需要与独立软件开发商的产品捆绑在一起作为集成产品提供时，J2EE提供了一个可接受的解决方案。
如果独立软件开发商的主要客户群是Windows客户，那么应当选择.NET平台。它可以在成本低得多的情况下提供好得多的产品。
许多需要操作系统可移植性的公司并不是独立软件开发商。这些公司的大多数公司认为可移植性是通向可收缩性的道路。这些公司相信他们，随着吞吐量需求的扩大，他们可以通过将应用程序移植到更高端硬件平台来获得更高的可收缩性。
如果你相信操作系统可收缩性能够以任何方式帮助你获得可收缩性，你正在犯一个严重错误。可收缩性不是一个硬件问题；它是一个软件问题。最高的可收缩性可以通过寻求高度可收缩的平台，然后尽可能地发挥该平台的优势获得。寻求在多个平台上运行的J2EE实施，在可获得的可收缩性方面还需很长的时间。到目前为止，在获得高可收缩性的能力方面，最好的被证明的平台是.NET平台。
使用笔者在关于可收缩性的一节中给出的数字，.NET平台可以从每分钟处理16,000笔交易增加到超过每分钟处理500,000笔交易。IBM WebSphere J2EE/Unix技术，是J2EE种类最好的代表之一，可能不会好于每分钟处理17,000到110,000笔交易，而每笔交易的成本则更高。
因此，可移植性并不是像看起来那么简单。如果你真的需要可收缩性，很明显，在.NET平台和J2EE中，.NET平台是胜者。如果你必须支持非Windows平台，那么很明显，J2EE是胜者。
如果你需要可移植性，不依赖于一时的念头或某一特定独立软件开发商的财富，那么忘掉它吧。这种 可移植性根本不存在。因此你要认真地选择开发商。确信你了解，并且对该开发商的技术指导感觉满意。确信你的开发商对该平台有一个长期的承诺。最后，确信你的开发商有财政资源以在这个高度竞争的舞台上生存。
客户端设备独立性
笔者讨论了Java和.NET平台表示层程序设计模型之间的差别。主要差别是，利用Java，决定传输给客户端的最终HTML的是表示层程序员，而使用.NET，则是Visual Studio .NET控件。
这种Java方法有三个问题。第一个问题，它需要很多位于表示层的代码，因为每个可能的瘦客户端都行需要一个不同的代码路径。第二个问题，很难使用每个可能的瘦客户端系统对代码进行测试。第三个问题，很难给现有的应用添加新的瘦客户端，因为这样做会涉及搜索和修改数量惊人的表示层逻辑。
.NET Framework方法是编写与可视控件交互的设备独立的代码。负责根据客户端设备的能力确定传送何种HTML的是控件，而不是程序员。在.NET Framework模型中，一个人可能会忘记像HTML存在这样的事情！
这种方法解决了Java/老ASP方法的所有三个问题。一个人可以使用更少的代码。对代码进行测试更容易，因为只需对与控件的交互进行测试，而不是对客户端设备进行测试。最后，可以很容易地添加新的客户端设备，只需下载更新了关于瘦客户端设备的最新知识的控件的最新版本。
从成本角度看，.NET Framework方法是毫无疑问的胜者。如果表示层开发人员不再负责确定在客户端设备上显示哪些内容的话，开发、测试和维护将会容易得多（、便宜得多）。
结论
对于电子商务体系结构，我们有两个互相竞争的构想。
Sun公司的J2EE构想是以众多开发商可以实施的一族规范为基础的。任何公司都可以许可和实施该项技术，在这种意义上讲，J2EE是开放的，但是从只有一个开发商控制该技术来说，它是封闭的，是一个具有非常有限的与外界互相影响的自我满足的体系结构的孤岛。
J2EE的一个主要缺点是，选择该平台表明使用一种程序设计语言，一种不很适合大多数企业的语言。
J2EE的一个主要优势是，大多数J2EE开发商提供了操作系统可移植性。
微软的.NET平台构想是一个产品，而不是一个规范家族，带有用来定义互用性要点的规范。这种方法的住雅缺点是，如果限于Windows平台，那么为.NET平台编写的应用程序只能在.NET平台上运行。.NET平台有几个重要的优点：
· 开发应用程序的成本更低，因为可以使用标准的商务语言，并且可以编写设备独立的表示层逻辑。
· 运行应用程序的成本更低，因为可以使用商品硬件平台（成本是它们的Unix对手的1/5）。
· 伸缩的能力更大，被证明的可以支持客户端数是任何J2EET平台表明的可以支持的客户端数的10倍。
· 互用性更强，可以将工业标准电子协作内置到平台中。
这两个平台一个最有差别的特点是整个系统的可移植性。寻求的成本电子商务平台的公司可能会由于疏忽而忽视了微软公司提供的功能。电子商务总是需要高可靠性和出色的可收缩性。第一次，这些功能能够以基于Unix的解决方案的成本的一小部分就可以在商品硬件平台上获得。
术语表
· ADO.NET –用于访问数据层的.NET API。
· Application Center Server – 提供中间层负载平衡和一般群集（cluster farm）管理的.NET技术。
· Assembly - .NET平台中应用程序部署的单位。
· BizTalk Server – 在商务过程间，尤其是遗留的商务过程间提供结合方法的.NET技术。
· C# - 一种新的C++派生程序设计语言，在功能 、外观和感觉上与Java类似。
· CICS – 一种IBM大型机事务处理监视技术。
· COBOL – 一种主要的商务程序设计语言。
· COM+ - 设计用来支持商务组件的.NET中间层基础结构。
· Commerce Server -.NET电子商务架构。
· CORBA (Common Object Request Broker Architecture，公用对象请求代理体系结构) – 由OMG定义的最早的组件体系结构。
· Common Language Runtime – 对编译的IL语言提供支持的.NET运行时间。
· DB2 – 一种与 SQL Server竞争的关系型数据库产品。
· DCOM – 一般用来（不是专门用来）在.NET体系结构内与组件通信的微软协议。
· EBusiness（电子企业） - 一家在Internet上开展所有或重要的商务的公司。
· ECollaboration（电子协作） - 在Internet上进行的企业间的协作。
· ECommerce（电子商务） - 在Internet上进行的商务。
· Eiffel – 在某些企业中使用的一种重要的研究语言。
· EJB (Enterprise JavaBeans) – 为商务组件设计的J2EE中间层基础结构。
· Entity Beans（实体豆） - 一种EJB技术专用的组件模型，提供不同程度的状态管理。
· HIS (Host Integration Server) – 一种与IBM公司的大型机互用的.NET技术。
· HTML – 描述浏览器显示的工业标准。
· HTTP – 用于在Internet上进行通信的关于标准。
· IL (Intermediary Language，中间语言) - .NET平台使用的中间语言。
· IMS – 一种IBM大型机数据库技术。
· ISAS (Internet Security and Acceleration Server，Internet安全与加速服务器) – 提供防火墙保护和HTML页面缓存的.NET技术。
· ISV (Independent Software Vender，独立软件开发商)。
· J2EE - Java 2 Enterprise Edition（Java 2企业版）。
· JAAS (Java Authen
tication and Authorization Service，Java身份验证与授权服务) – 用于通信安全性的J2EE API。
· Java – 与J2EE关联的程序设计语言。
· Java Applets – 浏览器中用于下载和在客户端运行Java代码的打包技术。
· Java 2 Enterprise Edition（Java 2 企业版） - 一个描述Sun公司电子商务规范家族的通用术语。
· Java Byte Code – 在Java虚拟机内运行的中间语言。
· Java Connectors（Java连接器） - 用于插入不同的数据库技术的（程序员不可见的）J2EE API。
· Java Server Pages - J2EE技术，连同Java Servlets是用于表示层的程序设计模型。
· Java Servlets - J2EE技术，连同Java Server Pages是用于表示层的程序设计模型。
· Java Virtual Machine（Java虚拟机） - Java语言环境。
· JDBC (Java Database Connection，Java数据库连接) – 用于访问数据层的J2EE API。
· JMS (Java Message Service，Java消息服务) – 用于获取消息队列的J2EE API。
· JNDI (Java Naming and Directory Interface，Java命名与目录接口) – J2EE中使用的用于命名和定位具体示例的 API。
· JTS (Java Transaction Server，Java事务服务器) – 用于管理事务处理边界的J2EE API，主要被EJB自动事务处理边界管理代替。
· MS-DTC (Microsoft Distributed Transaction Coordinator，微软分布式事务协调器) –在分布式事务协调中，管理两阶段提交协议的.NET技术。
· MTS (Microsoft Transaction Server，微软事务服务器) – 最初的基于组件的中间层，设计用来支持具有高可收缩性的应用程序。
· .NET – 用于描述微软公司的电子商务平台的通用术语。
· .NET Building Block Services（.NET构件服务） - 帮助企业一起工作的协作服务。
· .NET Client Systems（.NET客户端系统）- .NET平台的子集，设计用来支持各种瘦客户端平台。
· .NET Enterprise Servers（.NET企业级服务器） - 一个可用于.NET平台的可选的企业级产品集合。
· .NET Framework（.NET架构） -.NET应用程序运行的整个基础结构。
· NLBS (Network Load Balancing Service，网络负载平衡服务) – 一种用于负载平衡和向表示层提供高可收缩性的.NET技术。
· Oracle – 一个与 SQL Server竞争的关系型数据库产品。
· OMG (Object Management Group，对象管理集团) –一个早期的工业协会，该协会定义了最初的CORBA规范。
· RMI/IIOP (Remote Method Invocation over Internet InterOrb Protocol，Internet InterOrb协议上的远程方法调用) – 用于与J2EE种基于CORBA协议的组件通信的协议。
· SOAP (Simple Object Access Protocol，简单对象访问协议) – 一个用于对方法请求打包的工业标准。
· SQLServer – 微软公司的高端数据库产品。
· TCP/IP – 一种推动Internet的低层通信协议。
· TPC-C – 一种以分布式订单输入系统为基础的工业标准基准，用于测量中间层/数据层的总吞吐量。
· tpmC (Transactions per Minute, as defined by C benchmark，由C基准定义的每分钟事务处理数) – 一个标准的测量由TPC-C基准定义的事务的方法。
· UDDI (Universal Description, Discovery, and Integration，通用描述、发现与集成) – 一组由uddi.org控制的工业标准，用来定义电子协作。
· uddi.org – 控制UDDI的协会。
· VisualBasic – 微软公司开发的一种流行的商务程序设计语言。
· Visual Studio.NET -.NET的程序设计环境。
· WebLogic – BEA公司的电子商务平台，是J2EE的一个子集。
· WebSphere – IBM公司的电子商务平台，是J2EE的一个子集
· Web Service（网络服务） - 一个可以通过SOAP协议随时支付的中间层商务组件。
· URL (Universal Resource Locator，通用资源定位符) – 一个标准的Internet地址。
· XML – 用于构建文本串的工业标准。
商标信息
Sun, Sun Microsystems, Java, JDBC, JavaBeans, Enterprise JavaBeans, JavaServer Pages, Java Naming and Directory Interface, Write Once, Run Anywhere都是Sun Micrososytems, Inc.的商标或注册商标。ObjectWatch是ObjectWatch, Inc.的注册商标。所有其他商标归其相应的公司所有。
作者简介
Roger Sessions是ObjectWatch, Inc.公司的首席执行官，该公司专门提供.NET平台和其他电子商务体系结构方面的体系结构层次的培训。他是世界上电子商务体系结构领域最重要的专家之一，著有5本书籍和大量的文章。他在全世界许多会议上发表过演讲。他使用CORBA，J2EE和.NET平台进行了大量的工作。他是阅读量很大、经常引起很大争议的《ObjectWatch通讯（ObjectWatch Newsletter）》的作者，该通讯现在可以在网上看到，地址：www.objectwatch.com。与Andrew Coupe一起，Roger Sessions是被高度关注的工作室Architecting Next Generating eCommerce Systems for.NET的共同作者。有关该工作室的信息，可以在网上获得： www.objectwatch.com。
致谢
非常感谢Dino Chiesa, Andrew Coupe, John Montgomery和Jacqueline Van Voris的认真审阅。感谢你们！
下载
Java 2企业版(J2EE)
VS
.NET平台
关于电子企业的两种设想
Roger Sessions
ObjectWatch, Inc.
March 28, 2001 6:59 AM
本白皮书版权归德克萨斯奥斯汀ObjectWatch有限责任公司所有。保留所有权利。禁止进行未授权的复制或再次发布。要获得复制或再次发布许可，请联系：roger@objectwatch.com。
绪论 4
关于MoneyBroker 5
电子企业需求 5
典型的电子商务体系结构 6
.NET平台体系结构 7
.NET Framework与Visual Studio.NET 8
.NET企业级服务器 9
UDDI协作基础结构 10
.NET平台：将一切合并到一起 13
J2EE体系结构 14
Java语言系统 15
客户端程序设计模型 15
中间层基础结构 16
程序员企业级API 16
J2EE：将一切合并到一起 17
J2EE与.NET平台的相似点 17
J2EE与.NET平台之间的差别 18
开发商中立性 19
整体成熟性 19
互用性与网络服务 20
可伸缩性 21
架构支持 24
语言 25
可移植性 26
客户端设备独立性 28
结论 28
术语表 30
商标信息 32
作者简介 32
致谢 32
绪论
一个没有赢利计划的电子商务站点就像一辆没有汽油的汽车。它看起来可能会很漂亮。可能会给人留下深刻印象。它可能会让你付出很大的代价。但最终，它哪里也不能去。
去年，人们对这个教训有了深刻的理解。电子企业（EBusiness）一个接一个地破产，但这并不是由于缺少客户，而是由于缺少在这些客户上赢利的计划
在即将到来的一年中，赢利将会像过去一样非常重要。但是，赢利的模式将从基于竞争转变为基于合作。用反话来讲，那就是最具竞争力的公司将是那些不必为竞争担心，而将主要精力集中在协作上的公司。
对于商务而言，橄榄球比喻（“将你的对手压扁！”）已经过去了。未来的商务比喻是交响乐团。整体协作的成功将决定每个单位的成功。
在电子商务中，协作意味着通过合作关系开展销售活动。这意味着利润共享。利润共享迫使我们在协作的每个步骤对盈利模式进行仔细检查。我们需要以最可能低的成本，让技术在协作环境的每个步骤中为电子商务服务。
今天，对于电子企业和电子企业协作有两种技术设想。一种是微软公司的设想，整体称为.NET平台。另一种是Sun公司的设想，整体称为Java 2企业版( Enterprise Edition，J2EE)。
在该白皮书中，笔者将对.NET平台和J2EE进行比较。笔者将会把重点放在笔者认为在未来的5年内将会对电子企业起推动作用的主要问题：协作与盈利能力上。笔者将讨论这两个平台的技术细节，但只讨论那些影响协作或盈利能力的细节。
需要指出的是，J2EE是一种规范，而不是一种产品。许多开发商在产品中实施了这种规范。最重要的两个J2EE开发商/产品是IBM'公司的WebSphere和BEA公司的WebLogic。根据Cutter Consulting 公司最近的研究报告，这两个开发商占据了J2EE市场59%的份额。Sun公司虽然只占有很小的份额，但却很重要，因为它控制着J2EE规范。
将J2EE的每个实施细节都与微软公司的.NET平台进行比较超出了本白皮书的范围。笔者将对Sun公司（J2EE规范的所有者）定义的整体J2EE设想与微软公司定义的整体.NET平台设想进行比较。为了使得整个讨论更精确，笔者将会把这个问题与一个假想的企业MoneyBroker联系起来，但是虽然这只是一个假想的企业，但所讨论的问题却与任何一个电子企业有关。.
关于MoneyBroker
MoneyBroker只是一个用于说明的假想企业。我们假定MoneyBroker的用途是允许进行在线支付。客户可以在一个MoneyBroker帐户内存款，然后在线进行支付帐单。为了吸引客户，MoneyBroker对于未付的存款余额支付利息。
客户可以直接或间接地支付帐单。直接支付在MoneyBroker 网站进行，客户可以登录、安排帐单支付。间接支付通过MoneyBroker合作伙伴进行。MoneyBroker合作伙伴是指那些在客户订购时，可以接受客户的MoneyBroker货币的零售商。当一个客户访问AustinKayaks.com（另一个假想的企业），订购一艘价值500美元的皮艇时，AustinKayaks.com可以提供的一种选择是通过MoneyBroker帐户支付。
MoneyBroker通过将未付的客户存款进行投资赢利。向帐户所有者支付的利率与投资获得的利率的差即为公司的赢利。
电子企业需求
MoneyBroker为了支持电子协作（eCollaboration，electronic collaboration），运行MoneyBroker的计算机系统必须包含一定的能力。在我的经验中，最重要的需求是：
· 互用性 – 系统必须能与协作系统共享信息。
· 可用性 – 系统必须高度可用；第一次由于MoneyBroker 系统停机而导致AustinKayaks失去一次销售机会，它将会很不高兴。第二次，AustinKayaks将会终止合作关系。
· 吞吐量 – 系统必须能支持高事务处理吞吐量，因为支付请求不仅来自于MoneyBroker自己的网站，而且间接地来自其合作伙伴的网站。
为了赢利，总的系统成本必须尽可能地低。在我的经验中，最重要的系统成本的决定因素有：
· 开发成本 - MoneyBroker系统的设计和实施成本。
· 系统管理成本 – 管理MoneyBroker系统的成本。
· 单位生产成本（Unit of Work Costs） - 处理MoneyBroker支付的成本。
· 可伸缩性成本 – 随着客户群的增加，给整个MoneyBroker系统添加吞吐量的成本。
在本白皮书中，这些问题将是笔者重点讨论的主要问题：3个主要的协作需求（互用性，可用性和吞吐量），4个主要的系统成本（开发成本，系统管理成本，单位生产成本和可伸缩性成本）。
典型的电子商务体系结构
现在的基于网络的电子商务体系结构通常是以如图1所示的3层结构和两个防火墙为基础的。这些体系结构并不支持电子协作。我们将在后面讨论支持电子协作所必需的变化。
图 1. 3层电子商务体系结构
图1中所示的每层都有一个用途，一种体系结构，一个API。在本节中，笔者将给出一般的体系结构概述。在接下来的两节中，笔者将分析J2EE和.NET平台的差别
表示层负责与客户端的工作。利用MoneyBroker应用程序，这一层与基于浏览器的支付瘦客户端一起工作。
表示层接受来自网络浏览器的HTTP请求，然后返回一个浏览器可以显示的HTMl页面。不同的浏览器有不同的显示能力，因此表示层必须常常适应特定的浏览器（或其他瘦客户端设备）的HTML。
大量的商务逻辑在商务层内实施。对于MoneyBroker，包括保留客户帐户的逻辑，以及在支付帐单时转帐的逻辑。由于商务层位于表示层和数据库层之间，通常被称为中间层。
表示层通过一种方法传输协议，与商务层进行通信。对于.NET平台，这个协议通常是DCOM或SOAP。对于J2EE，这个协议是RMI/IIOP。
在J2EE和.NET平台中，商务逻辑通常被打包成了组件。一个组件就是通过详细定义的接口，用来进行交互的商务逻辑。
组件常常与对象（利用这项技术，它们通常有历史关系，但在其他方面有很少的共享内容）混淆。特别是，控制面向对象的程序设计和组件打包规则有很大的不同。笔者最近讨论了这两种技术的区别 ，因此将不在此对此重新讨论。
商务逻辑通常需要昂贵的资源，如数据库连接，线程，TCP/IP连接，和消息队列连接。这些资源需求通常使得在任何时刻支持大量的客户端都变得很困难，而这则是大多数电子商务应用的一个需求。
为了解决这个问题，J2EE和.NET架构的商务层都包括一个复杂的、支持客户端中间资源共享的中间层结构。这种结构对于支持大量的客户端，获得高系统吞吐量是至关重要的。在J2EE中，这个中间层结构被称为Enterprise JavaBeans (EJB)。在.NET架构中，则被称为COM+。
第三层是数据库层，实际数据存储在该层中。对于MoneyBroker系统，数据库层用来存储客户的帐户信息和帐单支付记录。
尽管大多数大型企业还有利用驻留在数据层中的数据库的内部应用程序（不是通过电子商务体系结构），商务层仍是数据层的主要客户。商务层和数据层之间的通信使用特定的API进行：.NET架构使用ADO.NET，J2EE使用JDBC。
现在，让我们对这两种技术进行更详细的分析。
.NET平台体系结构
整个.NET平台体系结构可以分为4个主要部分：
· .NET基础设施和工具：用来构建和运行电子企业系统的基础设施和工具，包括Visual Studio.NET，.NET Enterprise Servers，.NET Framework。
· .NET基础服务：.NET服务包括一组用于Internet的信息共享服务，如Passport.NET (用于用户身份验证)，以及用于文件存储、用户偏好管理、日历管理的服务。这些服务将由微软公司以及微软的合作伙伴提供。
· .NET用户体验：这将是一个更广泛、更适应的用户体验，信息可以各种方式、在各种不同设备上提供。
· .NET设备：这种设备软件使得可以使用新的可以利用网络服务的智能Internet设备。
.NET Framework与Visual Studio.NET
也许.NET平台最重要的部分是.NET Framework。这是一个与操作系统紧密相关的综合运行环境。它包括面向组件的中间层基础结构(COM+)，Common Language Runtime (CLR) 环境，一个准时制编译器，一组使用.NET组件模型打包的操作系统库。.NET系统(可能不包括数据层，笔者将在互用性中进行讨论)中服务器侧的每层将运行支持.NET Framework的操作系统。
与.NET Framework密切相关的是主要的程序员开发工具，Visual Studio.NET。表示层程序员使用Visual Studio.NET来定义向瘦客户端系统提交HTML页面的逻辑。商务层程序员使用Visual Studio.NET以多种语言实现商务逻辑，然后将商务逻辑打包为COM+组件。
Visual Studio.NET是中性语言。它被认为是最好的开放的程序设计平台，可以插入多种语言。可以与Visual Studio .NET一起使用的“标准”微软语言由VisualBasic，VisualC++和VisualC#。其他语言可以通过第三方获得，包括富士通（Fujitsu）公司的COBOL语言，Interactive Software Engineering公司的Eiffel语言。许多其他种与Visual Studio兼容的语言，包括Haskell，Mercury，Oberon和Perl正在由大学研究方面进行调查。
Visual Studio.NET (实际上，是整个.NET平台)的语言中性对于.NET平台策略是至关重要的。它是通过将所有Visual Studio.NET语言翻译成一种称为Intermediary Language (IL)的通用语言而实现的。实际上，它是通过语言开发商创建的使他们的语言与Visual Studio.NET 兼容的IL翻译器实现的。这样的语言被称为.NET支持语言（.NETenabled language）。
IL文件通常以可部署的称为汇编组件（assemblies）单位进行打包。这些汇编组件被加载到通用运行语言（Common Language Runtime，.NET Framework的一部分）种，由IL编译器进行编译，然后在通用运行语言（Common Language Runtime ，CLR）内运行。CLR提供了许多特性，我们可以将这些特性与一种特定的语言联合起来，包括碎片收集，类型定义，多型方法解析，错误处理，和部署模型。
将语言特性合并到一种通用运行语言（CLR）中，而不是合并到一种特定的语言中，使得各种语言可以自由地在整个.NET平台内互用。碎片收集，类型定义和错误处理都以一种统一形式进行处理，从而实现了无与伦比的语言互用性。也许跨语言互用性给人印象最深刻的例子是在一种语言（比如说，C#）内定义一个基类，然后以一种完全无关的语言（比如说，COMBOL）重写各种方法。笔者在最近的文章中曾给了这样一个例子。
在表示层使用.NET Framework意味着，任何支持.NET的语言（换句话说，任何有IL解释程序的语言） 都可以用作表示逻辑的脚本语言。并且由于.NET Framework包括编译器，它还意味着对表示层脚本进行编译，而不是进行解释，从而显著地改善了性能。
我们正在看到，各种类型的瘦客户端（浏览器，蜂窝电话，电子写字板，等等）开始迅速增长，每一种客户端都支持自己的HTML子集。今天的表示层脚本必须首先确定客户端的类型，然后为该客户端创建特制的HTML。这种操作非常费时，易出错，并且在新客户端系统变得可用时很难维护。
Visual Studio.NET包括一个新的表示层程序设计模型，该模型设计用来简化为瘦客户端系统的激增所进行程序设计工作。这种新的程序设计模型称为ASP.NET。ASP.NET允许表示层逻辑为客户端中性。这种程序设计模型是以今天非常成功的VisualBasic程序设计模型为基础的。With ASP.NET, the presentation tier scripts ask controls (such as menus or pull do
wn boxes) to act in certain ways, and then
respond to events that those controls raise. It then
becomes the control's responsibility to deliver its functionality using the HTML best suited for a given client device.
设计一个ASP.NET应用程序只需将GUI控件（如菜单或下拉工具箱）从模板投放到设计桌面上。然后程序员以任何支持Studio .NET语言编写对控制事件响应的代码。由控件，而不是由程序员负责根据客户端的实际设备确定最好的解释方法ASP.NET架构负责判断客户端采取特定的动作（如按下按钮）。由于所有这些都是在表示层发生，因此同一个代码基可以正确地工作，而不论实际的客户端设备是否任何.NET技术。
控件/事件程序设计模型，将设备感知内置到了表示控件而不是表示逻辑中，从而大大减少了开发和维护阶段的工作。开发工作减少了，是因为一个简化的代码块可以解释客户端的需求，并对任何最终客户端设备的HTML需求进行处理。维护工作减少了，是因为我们可以通过下载我们使用的最新版本的控件，加入对新的客户端设备的支持。
.NET企业级服务器
.NET企业级服务器是一组附加的、设计用来提供专用的企业级服务的服务器产品。每个服务器产品都是单独定价的，从而在配置整体解决方案方面提供了最大的财务灵活性。一个企业只需为所需的服务付费。
最出名的企业级服务器是微软公司的Probably the highest profile SQL Server。这是微软公司的高端数据库产品，该产品的许多功能已经远远超过了本文的范围。足可以说，SQL Server是具有高性能、高可用性、高可伸缩性的关系数据库，是企业市场中一个强有力的竞争者。
但是，对于.NET平台使用户依赖SQL Server，没有任何意义。许多组织机构使用整个.NET平台来创建他们的电子商务系统，他们可以选择自己的数据存储技术，如Oracle或DB2。每个流行的数据库系统都可以用作.NET数据层。例如，Oracle可以通过数据库中性的ADO.NET接口访问。大型机数据库，CICS和IMS可以通过Host Integration Service (HIS)访问。
最新的.NET企业级服务器是Application Center Server（应用中心服务器） Server。这个产品是专门为那些需要24X7可用性和/或低伸缩成本的公司而设计。Application Center Server既是一个群集协调者，又是一个群集管理者。
Internet Security and Acceleration Server (Internet安全与加速服务器，ISA Server)重点解决表示层的需求。It ISA Server提供了两个重要功能：HTML页面缓存，可以显著提高许多重点的性能，以及防火墙功能。当然，防火墙功能对于保证任何重要的电子商务站点的安全是至关重要的。ISA Server为基于硬件的防火墙产品提供了一个低成本的软件解决方案。冒着冗余的风险，ISA可以与其他.NET产品一起使用，但这并不需要。
BizTalk Server是一个综合的、集成产品，主要用来将各种组织机构的操作联系在一起，并且允许该组织机构与合作伙伴的操作互用。
Commerce Server是用于创建电子商务站点的架构。它重点是解决电子商务零售业务的需求。使用Commerce Server提供的组件，并进行专门化，就可以快速地创建这样的网站。
UDDI协作基础结构
协作是电子企业的未来。正在定义以支持电子协作的行业标准集可以在Universal Description, Discovery, and Integration (UDDI)下进行分组。
虽然UDDI独立于.NET平台，但是大多数UDDI相关活动都是由微软公司倡导的。这样，看起来在.NET平台部分中描述UDDI比较合适。
UDDI标准归uddi.org协会所有，一点也不奇怪，该协会的网站为www.uddi.org。该协会由Ariba，IBM和微软公司领导，同时包括100多个支持公司，包括Andersen Consulting，波音，康柏，戴尔，惠普，福特，Loudcloud，Merrill Lynch，Rational，SAP AG，Sterling和Sun。要了解当前的支持者清单，请访问该协会网站。
UDDI是在一组现有的、获得广泛支持的基础标准上建立的。这些基础标准包括：
· HTTP – 用于在Internet上进行通信的标准协议。
· XML – 一个用于对数据和有组织字符串打包的、被广泛接受的工业标准。
· SOAP – 一个迅速出现的标准（主要由微软公司和IBM公司领导），用于对客户端工作请求和作为XML字符串的系统相应进行打包。SOAP代表简单对象访问协议（Simple Object Access Protocol）（这是一个令人迷惑的简称，因为它既不简单，也不与任何对象相关!）.
HTTP和SOAP组合被认为是未来所有的电子协作的基础。在本白皮书中，当笔者讨论SOAP时，将假定使用HTTP作为传输协议。尽管其他协议（如那些基于信息队列的协议）可以用来传输SOAP请求，但在电子协作体系结构中，这将是不可能的。
图2为最常见的基于电子协作体系结构的SOAP协议。由于在例子上下文中更容易进行解释，笔者将使用最初的电子企业原型MoneyBroker。让我们看看MoneyBroker是如何使用SOAP与AustinKayaks协作的，最终的结果是AustinKayaks允许客户使用MoneyBroker帐户付款。
图 2. 典型的基于电子协作的 SOAP协议
让我们根据图2，观察AustinKayaks和MoneyBroker 之间的电子协作。在使用浏览器工作的AustinKayaks客户(1)访问AustinKayaks URL，然后要求购买一个皮艇时，电子协作开始。请求作为HTTP请求(2)通过Internet传输。AustinKayaks表示层(3)接收到该请求，该表示层通过该站点使用的任何一种本地协议(4)向商务层发出请求。如果AustinKayaks是一个微软站点，那么本地协议可能是（但并不一定是）DCOM。
AustinKayaks商务层现在认识到，需要向MoneyBroker商务逻辑请求支付。 这个请求是在本地(处理中的)SOAP代理(5)上作出的。SOAP代理将支付请求打包为一个SOAP请求，然后使用HTTP (6)，通过Internet将其发送给MoneyBroker站点，在MoneyBroker站点请求被MoneyBroker表示层上的一个SOAP接收器 (7)接收。
SOAP接收器 (7)的唯一用途是将SOAP请求翻译为本地请求，通过本地协议(8)将其传输给MoneyBroker商务层 (9)，请求在此进行处理，并完成支付。然后，结果从MoneyBroker商务层被返回给AustinKayaks表示层，该表示层可以将结果翻译为适合该AustinKayaks客户的浏览器的内容。
SOAP是技术中性的。AustinKayaks和MoneyBroker不需要在使用何种技术建设网站上以致，只要各自的技术支持SOAP技术能够互用即可。
对于允许AustinKayaks使用MoneyBroker服务来说，SOAP功不可没，但是只有在AustinKayaks已经知道4件事情时才可以：MoneyBroker存在；可以找到MoneyBroker的URL；,MoneyBroker可以提供的服务；以及MoneyBroker 可以接受SOAP请求的确切格式。如果AustinKayaks不知道这些又怎么样呢？如果AustinKayaks只知道它需要帐单支付服务，但不知道哪些存在，它们位于何处，以及如何使用它们，又会怎样呢？
这就是使用UDDI的原因。UDDI定义了允许电子协作各方可以彼此找到的标准。描述UDDI标准的所有内容已经超出了本白皮书的范围。
这就是UDDI起作用的地方。UDDI定义了使得潜在的电子协作者可以彼此找到对方的标准。描述所有的UDDI标准（这些信息可以从网上获得 ）已经超出了本白皮书的范围，但是我们将讨论如下方面：
· 注册设备的URL，包含关于工业标准接口的信息，如帐单支付服务。
· 已经承诺支持工业标准接口（如MoneyBroker）的具体公司。
· 到这些设备的SOAP接口，潜在的协作者可以编程使用这些接口彼此找到对方。
· 一种用于描述SOAP接口的标准的技术中性语言。
在UDDI功能标准(HTTP, XML, SOAP)与UDDI电子协作标准之间，我们有一种技术中性的架构让企业一起工作。
.NET平台已经包含了XML和SOAP技术。微软公司是UDDI计划的三个领导者之一（其他两个为Ariba和IBM），因此很清楚这三个标准一成熟，我们就可以看到它们会被合并到.NET平台中。
我们有一个专门的小组来描述SOAP可以随时支付的商务逻辑，该小组的站点三使用了合适的UDDI标准来使得SOAP服务可以广泛使用。我们将这样的商务逻辑称为网络服务（Web Service）。
.NET平台：将一切合并到一起
图3显示了.NET平台的所有部分是如何结合到一起的。应将该图与显示这种体系结构的一般形式的图1进行比较。
图1. .NET平台电子商务体系结构
J2EE体系结构
与.NET平台相比，Sun公司的标准定义的J2EE体系结构有很少可以讨论的空间，因为就没有什么可讨论的。如果一个人注意某个具体开发商的产品，如IBM公司的WebSphere，那么就会看到其技术的最大的一部分是WebSphere专用的。比较所有开发商对J2EE的具体改进，已经超出了本文的范围，在我的经验中，大多数对J2EE作为一个平台感兴趣的公司对该标准的可移值性感兴趣。任何对可移值性感兴趣的人都会需要将他们自己局限于Sun公司所定义的标准。
J2EE体系结构可以被分为5部分：
· Java语言系统
· 客户端程序设计模型
· 中间层基础结构
· 程序员企业级API
· 非程序员可见API
最后一部分，非程序员可见API，包括定义了如何将其他产品插入到J2EE中的API，如连接器API，以及J2EE模型中被最近的改进有效替代的API，如JTA（Java Transaction API）。由于从比较微软和Sun公司计划的角度来说，非程序员可见API并不重要，因此在笔者的概述中将不涉及这些方面 (就如同笔者在.NET平台概述中并没有涉及功能相当的API一样)。
Java语言系统
在高层次上，Java语言系统看起来与.NET Framework类似。在这两种情况中，源代码都是被翻译成一种中间语言。但是，在.NET平台中，这种中间语言是MSIL，而在Java系统中，是Java Byte Code。在这两种情况中，中间语言被带入到运行环境中。在Framework中，运行环境是Common Language Runtime。对于Java，运行环境是Java虚拟机（Java Virtual Machine）。总体而言，Common Language Runtime和Java虚拟机有类似的功能，并且在技术进步方面，都无可置疑地在发展和彼此交互跃进。
这两种系统之间最重要的区别与源代码到中间语言的翻译有关。在.NET平台中，中间语言设计用来适应各种语言的需求。在Java中，中间语言设计用来满足Java的需求。虽然从理论上，从除Java外的语言生成Java Byte Code是可能的，但是实际上这还没有在任何一种商业产品中证明。
客户端程序设计模型
J2EE客户端程序设计模型重点集中在与浏览器的交互上。客户端程序设计模型有3部分：Java Applets，Java Servlets和Java Server Pages。
Java Applets用来对在浏览器内运行的Java代码进行打包。在.NET平台空间中，这在功能上与ActiveX相当。在笔者的经验中，applets或ActiveX组件使用的相对较少。电子商务体系结构一般都是以向表示层发出请求的浏览器为基础，然后表示层使用HTML页面进行响应。这种系统并没有使用ActiveX或Java Applets，因此笔者在本白皮书中并没有讨论这些技术的任何一种。
处理HTTP请求和HTML响应的重要技术是Java Servlets 和Java Server Pages 。这两种技术与微软空间中的ASP.NET（Active Server Pages）类似。
.NET平台与Java表示层中间的主要区别在于处理不同的客户端功能的方式。Java表示层沿用了以前的Microsoft ASP (pre .NET)模型，它使得表示层程序员的责任是决定最终的目的浏览器（或其他瘦客户端系统），瘦客户端系统的功能，以及如何生成HTML来充分发挥瘦客户端系统的优势。
中间层基础结构
对于J2EE，中间层基础结构是Enterprise Java Beans (EJB)。该规范的当前版本是2.0，可以从网上获得 。与J2EE相当的.NET平台是COM+。
在EJB和COM+之间，体系结构的差别非常少。这两种体系结构本质上是从MTS（Microsoft Transaction Server）派生出来的，是由微软公司在1996年引入的最初的面向组件的中间层基础结构。由MTS最先引入，然后合并到EJB和COM+中的重要想法包括：
· 通过组件示例的共享所实现的高可伸缩性
· 以中间层为中心的安全性
· 自动事务处理边界管理
EJB加入了一种新的体系结构想法，一项自动管理组件状态的技术。这项技术被称为entity beans（实体豆）。虽然这种想法具有吸引力，但是当前的实施却依赖于独立于数据库缓存的中间层数据缓存。很不幸的是，在这两种缓存之间没有保持一致性的机制。这意味着对实体豆的任何使用都会带来数据库损坏的高风险。在缓存一致性问题解决之前，在最佳试验技术方面，必须得不断考虑实体豆技术。
要连接EJB和COM+的深入比较，请参阅笔者最近的著作 。
程序员企业级API
我们调用Java Enterprise API 时的最重要部分如下：
· Java Database Connection (JDBC，Java数据库连接) 2.0 – 是用于从Java中访问关系型数据库的API 。这与.NET平台空间中的ADO.NET相当。
· Java Naming and Directory Interface (JNDI，Java命名与目录接口) – 是用于从Java中访问企业名称与目录服务的信息的API 。这与.NET平台空间中的Active Directory Services Interface (ADSI，活动目录服务接口)有点类似。
· Java Message Service (JMS，Java消息服务) 1.0 – 是用于异步工作流的Java API 。这在功能上与Microsoft Message Queue API相当，这个API已经被排队组件所替代。
J2EE：将一切合并到一起
图 4 显示了J2EE主要部分之间的关系，可以将其与图3和和图1进行比较。图3显示了.NET平台的相当的形象描述，图1中显示了相当的一般体系结构。
图4. J2EE电子商务体系结构
J2EE与.NET平台的相似点
图2中给出了J2EE与呢平台之间的所有相当之处。正如你所看到的，许多.NET平台功能范围在J2EE中没有对应功能。在某些情况下，至于是否支持这些功能，如果支持，支持情况如何，被认为是一个实施明确的决策，注意：要了解不熟悉的缩写词，请查看术语表。
图 2. 技术对应
技术 .NET J2EE
支持技术
发布协议 DCOM, SOAP RMI/IIOP
防火墙 ISA* 没有定义-
HTML页面缓存 ISA*, ASP.NET 没有定义
表示层技术
基础结构 IIS 没有定义
程序设计模型 ASP.NET Servlets, JSP
高可用性 NLBS*, ACS*, 其他 没有定义
负载平衡 NLBS*, ACS*, 其他 没有定义
管理 ACS* 没有定义
中间层技术
基础结构 COM+ EJB
程序设计工具 Visual Studio.NET 没有定义-
高可用性 ACS* 没有定义
负载平衡 ACS* 没有定义
安全性API COM+ Security Call Context JAAS
消息队列API MSMQ JMS 1.0
异步组件 Queued (COM+) Message driven beans (EJB 2.0)-
命名与目录服务 ADSI JNDI
数据层技术
分布式事务处理 MS-DTC JTS
关系型数据库API ADO.NET JDBC 2.0
层次型数据库API ADO.NET -
数据库存储 SQLServer** -
大型机数据库连接性 HIS* Java连接器
架构技术
电子商务架构 Commerce Server* -
B2B BizTalk Server* -
* 对于.NET平台是可选附加服务。
** SQLServer是正式的.NET平台数据库技术，但是可以使用任何支持ADO.NET的数据库，包括大多数数据库。
J2EE与.NET平台之间的差别
你可以看到在J2EE与.NET平台技术之间由很大的重叠。但是，如何在它们之间进行选择呢？在本节中，笔者将讨论我所看到的主要差别。
开发商中立性
许多公司购买J2EE，他们相信这可以给他们开发商中立地位。而实际上，这是Sun公司计划的一个确定目标：
配置和实施各种满足J2EE规范需求的产品是可能的。一个可移植的J2EE应用程序在这些产品 中的任何一个产品中被成功部署后，都可以正确地运行。
实际上，在不是Sun J2EE对手的人中，很少有人相信这是可以实现的。Paul Harmon是最重要的独立J2EE发言人之一，他是Cutter Consortium的首席顾问，广泛发行的Architecture/e-Business E-Mail Advisory的作者。虽然Harmon总是反对J2EE，但他最近对J2EE的开发商可移植性写了这样不同寻常的坦诚的评价。
EJB模型是否已经达到了我可以将EJB组件从一个EJB应用服务器移动到另一个服务器的程度？在大多数情况下不能。EJB规范不够全面。通过提供专有的解决方案来完善这个模型，确保他们的客户可以创建生产系统，EJB应用服务器开发商弥补了这一点。
Harmon总结了当今开发商中立的情况， 他的评论如下：
此刻，现实情况是如果你想开发一个EJB应用程序，你应当忠心于一个开发商。
今天的现实是，没有像开发商中立这样的情况。当然，.NET平台不是开发商中立的，它与微软公司的操作系统捆绑到了一起。但是两者都不是J2EE的实现。笔者可以给的最佳建议是，选择某一开发商，计划与其始终站在一起，这样可以充分利用该开发商所提供的平台优势。
整体成熟性
第一个J2EE规范，EJB规范在1998年提出，而第一个β版本出现于1999年。而这则是在与之相当的.NET平台技术，MTS，COM+的前身第一次实现的3年之后了。笔者在最近的一篇文章 中讨论了从MTS到COM+的发展过程。
在.NET平台比J2EE早出现两年的情况下，了解.NET平台比J2EE平台更成熟就不足为怪了。虽然我们有大量的使用.NET技术的高度可靠的网站（NASDAQ和戴尔就是众多例子中的两个），但我们不知道有哪个网站使用了J2EE平台。Paul Harmon又作了如下评论：
今天，任何一个正在尝试[基于J2EE的]公司范围的企业级系统的公司，都在尽力工作，更好的方法是让一个真正优秀的开发团队来帮助他们摆脱困境。更重要的是，它可能应当重新考虑一个综合的项目，并满足于初始近似。
互用性与网络服务
诸如笔者详细讨论的，.NET平台电子协作模型是以UDDI和SOAP标准为基础的。这些标准被100多家公司广泛支持。微软公司，IBM和Ariba是这个领域的领导者。Sun公司是UDDI协会的会员，并且认识到了UDDI标准的重要性。在最近的新闻发布会上，Sun公司负责Java群体开发的付总裁George Paolini说：
“Sun公司一直在工作，以帮助建立和支持开放的、基于标准的技术，来促进基于网络的应用的增长，并且我们认为UDDI是一个重要的、为B2B电子商务建立一个注册架构的项目。”
但是虽然Sun公司公开说相信UDDI标准，但实际上，Sun公司没有采取任何措施将任何一种UDDI标准合并到J2EE中。这包括最基本的、已经有一年多的UDDI标准，SOAP。正如IBM公司的Rod Smith（Emerging Technologies公司副总裁，该公司是Sun公司最强大的合作伙伴之一）所说：
迄今为止，Sun公司还没有对[UDDI]网络服务发表过得评论。但是我认为这样是有原因的。我认为他们正在考虑Java。当我们考虑网络服务的时候，我们正在倾听客户的声音和他们的需求，但事实是，客户已经有了不基于Java的系统和Java应用程序。因此，Sun公司仍然在坚持Java，但是在这个问题上非常平静。
实际上，Smith对Sun公司的互用性策略的分析一语中的。Sun公司将重点主要集中在了J2EE开发商与CORBA开发商的互用性上。Sun公司的互用性想法是，应当以所谓的IIOP通信协议为基础。
利用基于IIOP的互用性，有三个主要缺陷。
第一，它需要全世界都运行J2EE或CORBA，这是一个连Sun公司的合作伙伴都反对的假定。IBM公司的Rod Smith解释了IBM支持SOAP，而不是支持IIOP作为互用性开放标准的原因：
当发布声明，并说我们[IBM]将把SOAP作为开放标准，并将其相应提前时，响应是令人无法置信的和积极的，因为人们希望进行这样的集成工作。他们拥有基于微软的解决方案。他们同时拥有基于Java的解决方案。他们还拥有基于[Windows] NT的解决方案和基于Linux的解决方案。
第二个缺陷是，像所有通信协议一样，IIOP 应当服从在Internet上进行传输。这使得它不可能作为普遍的电子协作机制。
第三个缺陷是，即使全世界都同意使用IIOP和J2EE，即使在J2EE开发商中，对于确保互用性当前的IIOP规范也是不适当的。正如Paul Harmon所说的那样：
来自不同开发商的EJB应用服务器是否以能在更大的系统中咬接的方式实行了标准化？尽管使用Internet InterORB Protocol (IIOP)来支持EJB间的应用程序通讯，但仍不能随便地在一个网络中将多个EJB产品结合在一起。 将每个都依赖几个非标准工具进行平稳通信的两个EJB应用服务器仍然需要进行一些重要的程序设计工作。
今天的现实情况是，与J2EE相比，.NET平台有一个更加强大的技术中性的电子协作策略。IBM公司深信不已，UDDI，而不是IIOP才是正确的互用性方法，在这个问题上，这已经与Sun公司决裂了。在这一点上，令人痛苦但却很明显的是，尽管在UDDI上已经领先了10年，但却是一个完全的失败。
可伸缩性
可伸缩性是指添加更多工作量的能力。一般来说，附加的工作量是客户的增加引起的。可伸缩性是一个复杂的问题，笔者已经在几篇已经可以得到的文章中对此进行了深入探讨 。未来简化这个讨论，笔者将在MoneyBroker可能会在接下来的3年中遇到的问题的上下文中讨论可伸缩性。笔者将进一步简化这个讨论，而只考虑运行商务层和数据库层的成本，尽管对表示层进行类似的分析可能会得出类似的结果。
让我们假定，MoneyBroker的商务模型要求它今年每天处理10笔支付，明年为100万，而后年则为1000万。选择J2EE/Unix解决方案或.NET平台/Windows解决方案的相关成本有哪些呢？
为了判断MoneryBroker在接下来的3年中所需的机器规模，我们需要一个事务处理性能的标准的基准。事务处理吞吐量的工业标准基准是由所谓的Transaction Performance Council (TPC)协会规定的，该基准被称为TPC-C基准。TPC会员包括Sun、IBM、Oracle、BEA、微软和其他大部分销售中间层/数据库层产品的公司。
TPC-C基准评定了一个系统可以获得的最高工作量的等级。TPC-C基准定义的测量单位为tpmC，代表每分钟交易处理数（transactions per minute）。除了说该基准考虑的是在分布式订单输入系统环境中的交易处理外笔者将不对其进行讨论。该基准的说明可以在TPC网站 得到。
在MoneyBroker使用TPC-C数使其平台成为用户选择方面，正在面临两个问题。
第一个问题是TPC-C规定的交易处理与MoneyBroker交易处理完全不同。这需要MoneyBroker彻底审核TPC-C规范，猜测在工作量中多少 TPC-C交易才能与一个MoneyBroker交易相当。我们假定MoneyBroker计算得出它的一个交易与10个TPC-C交易相当，从而有大量的富余用于处理错误。
第二个问题是，没有一个J2EE开发商已公开发布自己的TPC-C数。这使得MoneyBroker很难计算J2EE实施的吞吐量，即AIX。有趣的是，虽然所有重要的J2EE开发商已经提交了TPC-C基准，但没有一个开发商已经提交了基于他们的J2EE技术的TPC-C数。
例如，对于IBM公司的WebSphere技术（包含在J2EE技术中的IBM公司的一个品牌）有6个基准。但是，如果有人研究WebSphere的结果，就会发现没有一个基准的代码是使用Java编写的，并且没有一个基准使用了任何的WebSphere J2EE性能。实际上，这些基准使用了IBM公司传统的Encina事务处理监控技术，该产品是同时包含在总的WebSphere品牌下。类似地，BEA公司使用了其传统的Tuxedo技术来运行他们的基准，Tuxedo技术是其WebLogic品牌的一部分，但是却没有包含在J2EE中。
由于我们没有J2EE性能数字，我们得必须估计J2EE实现的相关性能。由于J2EE 基于传统的事务处理监控程序（开发商已经确定了基准），但是仍然会增加Java程序设计语言。Java虚拟机和EJB（中间层）的开销，比较合理的推测是J2EE将可以完成与之相当的非J2EE系统（如Tuxedo性能）50%的性能。因此，笔者将使用一个50%调节系数来估计J2EE的吞吐能力。
下面我们使用TPC-C 信息对MoneyBroker行为进行分析。MoneyBroker正在试图确定购买何种系统。显然，MoneyBroker希望花费尽可能少的资金，但仍确信可以获得在客户使用量达到峰值时所需的吞吐量，还确信它的系统可以进行伸缩以满足接下来的三年内的需求。
今年MoneyBroker每天需要处理10万笔交易。这相当于每分钟处理70笔交易，峰值时大约为每分钟处理700笔。由于一个MoneyBroker交易处理等于10 tpmC交易，这等于工作量达到峰值时大约为7000。明年，这个数目增加10倍达到70000 tpmC，而后年，这个数目再增加10倍，达到700000 tpmC。
那么，在接下来的三年中，这些系统需要哪些支出(包括硬件和软件在内)？让我们从J2EE/Unix的可能支出开始，因此笔者将考虑在IBM公司的AIX操作系统、WebSphere和Oracle 8i系统中，哪一个最能代表J2EE/Unix系统。对于这种配置，有6个基准。按tpmC从最低到最高的次序排列，以及J2EE调整（前面已经讨论），结果如下：
公司 系统 tpmC 总系统成本
Bull Escala T610 c/s 16,785 $1,980,179
IBM RS/6000 Enterprise Server F80 16,785 $2,026,681
Bull Escala EPC810 c/s 33,375 $3,037,499
IBM RS/6000 Enterprise Server M80 33,375 $3,097,055
Bull Escala EPC2450 110,403 $9,563,263
IBM IBM eServer pSeries 680 Model 7017-S85 110,403 $9,560,594
如果我们考虑某些有代表性的.NET平台系统（这些系统太多，不可能全部考虑，但数字非常一致），结果如下：
公司 系统 tpmC 总系统成本
Dell PowerEdge 4400 16,263 $273,487
Compaq ProLiant ML-570-6/700-3P 20,207 $201,717
Dell PowerEdge 6400 30,231 $334,626
IBM Netfinity 7600 c/s 32,377 $443,463
Compaq ProLiant 8500-X550-64P 161,720 $3,534,272
Compaq ProLiant 8500-X700-64P 179,658 $3,546,582
Compaq ProLiant 8500-X550-96P 229,914 $5,305,571
Compaq ProLiant 8500-X700-96P 262,244 $5,305,571
Compaq ProLiant 8500-700-192P 505,303 $10,003,826
你可以理解MoneyBroker 面临的选择。今年它只需一个7000 tpmC系统。在Unix市场这将大约花费200万美元，而在.NET平台市场则需要花费27.3万美元。明年MoneyBroker将需要一个70000 tpmC系统，在J2EE/Unix市场需要花费950万美元，而在.NET平台市场则需要花费350万美元。后年，MoneyBroker则需要一个700000 tpmC系统。这些系统中，没有一个被评定为700,000 tpmC，但到面前为止最靠近的系统是1000万美元的.NET平台系统。如果一个与之相当的J2EE/Unix机器存在的话，估计需要花费4750万美元。
很明显，如果系统的成本是一个重要的考虑事项，与J2EE相比，.NET平台有很大的优势。可以预计要获得相同的功能，需要花的费用是在.NET平台上所花的费用的5到10倍。如果一个工作单位在.NET平台上花10美分，同一个工作单位则可能需要在J2EE/Unix上花50美分到1美元。
笔者需要再次指出，虽然这些.NET平台基准是实际机器的实际基准，但在这些J2EE基准中，没有一个真正存在。这些基准是外推基准结果，实际的系统不一定能真正获得这些结果。在J2EE开发商发布他们的基准数之前，我们必须记住，没有一个J2EE平台已经被证明可以任何代价的情况下处理这些高工作量。
架构支持
当创建一个大型的电子商务解决方案时，不用说没有人希望从头开始。而是希望在已经完整定义的、结果测试的电子商务架构基础上创建解决方案。使用这样的架构可以极大地降低开发成本，可能至少降低10倍。
.NET平台包括一个所谓的Commerce Server电子商务架构。在这一点上，在J2EE空间内没有与之相当的开发商中立的架构。利用J2EE，你应当假定你需要从头创建你的新的电子商务解决方案。Paul Harmon看来同意这种评价，说：
此外，无论选择哪一个[J2EE]开发商，如果你期望一个允许你很快实施的完善的电子商务应用程序，你将会有令人沮丧不已的体验。
如果使用MS Commerce Server作为你的电子商务基础，那么很可能会对开发系统的成本有很大的影响。Commerce Server尤其适合零售业务。这样的电子商务系统应当仔细考虑这项技术。
语言
在语言方面，选择很简单。J2EE支持Java，并且只支持Java。在可预见的将来，它将不会支持其他任何种语言。.NET平台支持出Java以外的其他任何种语言（尽管它支持一种在语法和功能上与Java相当的语言，C#）。实际上，倘若.NET平台像一辆语言独立的车辆一样重要，在不远的将来，很可能任何一种出现的语言都支持.NET平台。
某些公司对J2EE支持其他语言所打动。尽管IBM公司的WebSphere和BEA公司的WebLogic支持其他语言，但是他们都不是通过J2EE技术实现的。在J2EE平台种，只有两种正式的方法来访问其他语言，一种是通过Java Native Interface，另一种方法是通过CORBA互用。Sun公司推荐采用后一种方法。正如Sun公司著名的科学家和Java设计师Rick Cattell在一次采访种所说：
你可以通过Java Native Interface功能和通过CORBA调用C++。CORBA可能是推荐的方法，因为它通过了更大的灵活性，并且我们已经设计了在认可的环境中能够很好地与CORBA一起工作的J2EE 。
在CORBA体系结构中创建任何新代码都是一个很有问题地策略。CORBA是20世纪90年代受人喜爱地体系结构，但现在已经不再使用了。据笔者所了解，没有一个CORBA开发商（除IONA外）在CORBA上盈利，并且没有一个开发商（包括IONA在内）在继续向该技术投资。底线是如果有人希望以Java以外的任何一种语言进行开发，那么J2EE是不正确的平台选择。
当前某些非Java公司正在考虑在Java上进行重新标准化的可能性。要实现这一点，有三种可能的方法：
· 对现有职员进行再培训
· 雇佣新职员，并尽可能地替换现有职员
· 外包
再培训可能是最昂贵的选择。以我的经验，有很大的管理费用与将传统的程序员培训成精通面向对象的Java程序员有关。这是Gartner集团最近的研究的结果，得出得结论是将一个COBOL程序员培训成Java程序员，每人大约需花费6万美元 。 笔者相信，对于Visual Basic程序员，费用大体相当。并且在训练结束，你在生产力方面一无所得。你可以简单地雇佣一个现在可以编写与花费6万美元进行培训后编写的代码相同，但现在就可以使用Java编写该代码的程序员。在许多公司中，笔者曾经看到由于采用面向对象的技术损害生产力的情况，工作时间通常会浪费在了无休止的和没有成果的关于“正确的”面向对象的设计与分析的理论讨论上。
雇佣和/或替换职员同样代价昂贵。当前，Java程序员所要求的薪水比传统的Visual Basic/COBOL程序员高30%。在笔者的经验中，他们还有更高的新雇人员比率。
对于希望转向Java的公司来说，外包可能是唯一可行的选择。但是，假定外包可以完全使你摆脱上面提到的问题是不现实的，很显然，尤其是额外的程序员成本被转移给你的情况下，更是这样。
那么你应当使用什么语言呢？底线是，如果你有经过Java培训的职员， 并且已经有了合适的策略来确保对程序设计过程的有效管理，那么尽一切办法坚持下去。笔者个人喜欢使用Java作为程序设计语言，尽管笔者认为至少有其他好的语言。另一方面，如果你的店铺主要是由Visual Basic和COBOL组成，那么转向Java差不多肯定会是代价昂贵的、令人沮丧的一次体验。
你的语言选择并不会必定决定你在J2EE和.NET平台之间的选择。当然，如果你希望使用Java以外的某些东西，那么你就处于J2EE空间之外了。但是，Java的吸引力并不需要剥夺你使用.NET平台的权利 。.NET平台包括对C#（发音为C Sharp）支持，该语言是一种与Java很类似的语言，以至于许多人第一眼还不能将它们分辨开来。一个有经验的Java程序员可以在几小时内学会C#语法。
但是，如果你选择Java不是因为J2EE所声称的可移植性策略，那么C#或任何其他可以在.NET平台上运行的语言不大可能会让你愉快的。如果这样，很明显J2EE是你的选择。但是，在做出选择之前，一定要阅读有关可移植性的章节。.
可移植性
J2EE的许多吸引力在于可移植性方面的承诺。有两种可移植性。的一种是开发商可移植性。笔者将这种可移植性称为开发商中立（vendor neutrality），前面已经讨论（并拒绝）了这种想法。第二种可移植性是操作系统可移植性（operating system portability）。这指的是在不对代码做任何改动的情况下，将代码基从一个操作系统转移到另一个操作系统的能力。与开发商中立不同，大多数J2EE实施最可能采取操作系统可移植性。
J2EE最可能会采取操作系统可移植性的原因是，在很大程度上并不是由于J2EE任何固有的可移植性，而是大多数J2EE开发商支持多种操作系统。因此，只要一个公司忠诚于一个既定的J2EE开发商和一个既定的数据库开发商，从一个操作系统转向另一个操作系统是可能的。这可能是唯一一个最重要的J2EE平台超过.NET平台的益处，而.NET平台仅限于Windows操作系统。但是，微软公司向ECMA（对JavaScript进行标准化的团体）提交C#规范和.NET Framework的一个子集（称为Common Language Infrastructure）毫无价值。
为什么开发商可移植性/中立令人满意很明显，但是操作系统可移植性有什么好处呢？我们认认为，一般有两种类型的公司需要操作系统可移植性：独立软件开发商（ISV，Independent Software Vendor）和寻求可收缩性解决方案的公司。
独立软件开发商（ISV）在有大量的非Windows平台客户群时需要操作系统可移植性。一个开发商不可能向依赖于.NET平台的Unix客户销售一件产品。如果.NET平台比J2EE好还是不好无关紧要。它并不在Unix上运行。
如果独立软件开发商的产品必须销售给非Windows客户，尤其是当J2EE平台本身需要与独立软件开发商的产品捆绑在一起作为集成产品提供时，J2EE提供了一个可接受的解决方案。
如果独立软件开发商的主要客户群是Windows客户，那么应当选择.NET平台。它可以在成本低得多的情况下提供好得多的产品。
许多需要操作系统可移植性的公司并不是独立软件开发商。这些公司的大多数公司认为可移植性是通向可收缩性的道路。这些公司相信他们，随着吞吐量需求的扩大，他们可以通过将应用程序移植到更高端硬件平台来获得更高的可收缩性。
如果你相信操作系统可收缩性能够以任何方式帮助你获得可收缩性，你正在犯一个严重错误。可收缩性不是一个硬件问题；它是一个软件问题。最高的可收缩性可以通过寻求高度可收缩的平台，然后尽可能地发挥该平台的优势获得。寻求在多个平台上运行的J2EE实施，在可获得的可收缩性方面还需很长的时间。到目前为止，在获得高可收缩性的能力方面，最好的被证明的平台是.NET平台。
使用笔者在关于可收缩性的一节中给出的数字，.NET平台可以从每分钟处理16,000笔交易增加到超过每分钟处理500,000笔交易。IBM WebSphere J2EE/Unix技术，是J2EE种类最好的代表之一，可能不会好于每分钟处理17,000到110,000笔交易，而每笔交易的成本则更高。
因此，可移植性并不是像看起来那么简单。如果你真的需要可收缩性，很明显，在.NET平台和J2EE中，.NET平台是胜者。如果你必须支持非Windows平台，那么很明显，J2EE是胜者。
如果你需要可移植性，不依赖于一时的念头或某一特定独立软件开发商的财富，那么忘掉它吧。这种 可移植性根本不存在。因此你要认真地选择开发商。确信你了解，并且对该开发商的技术指导感觉满意。确信你的开发商对该平台有一个长期的承诺。最后，确信你的开发商有财政资源以在这个高度竞争的舞台上生存。
客户端设备独立性
笔者讨论了Java和.NET平台表示层程序设计模型之间的差别。主要差别是，利用Java，决定传输给客户端的最终HTML的是表示层程序员，而使用.NET，则是Visual Studio .NET控件。
这种Java方法有三个问题。第一个问题，它需要很多位于表示层的代码，因为每个可能的瘦客户端都行需要一个不同的代码路径。第二个问题，很难使用每个可能的瘦客户端系统对代码进行测试。第三个问题，很难给现有的应用添加新的瘦客户端，因为这样做会涉及搜索和修改数量惊人的表示层逻辑。
.NET Framework方法是编写与可视控件交互的设备独立的代码。负责根据客户端设备的能力确定传送何种HTML的是控件，而不是程序员。在.NET Framework模型中，一个人可能会忘记像HTML存在这样的事情！
这种方法解决了Java/老ASP方法的所有三个问题。一个人可以使用更少的代码。对代码进行测试更容易，因为只需对与控件的交互进行测试，而不是对客户端设备进行测试。最后，可以很容易地添加新的客户端设备，只需下载更新了关于瘦客户端设备的最新知识的控件的最新版本。
从成本角度看，.NET Framework方法是毫无疑问的胜者。如果表示层开发人员不再负责确定在客户端设备上显示哪些内容的话，开发、测试和维护将会容易得多（、便宜得多）。
结论
对于电子商务体系结构，我们有两个互相竞争的构想。
Sun公司的J2EE构想是以众多开发商可以实施的一族规范为基础的。任何公司都可以许可和实施该项技术，在这种意义上讲，J2EE是开放的，但是从只有一个开发商控制该技术来说，它是封闭的，是一个具有非常有限的与外界互相影响的自我满足的体系结构的孤岛。
J2EE的一个主要缺点是，选择该平台表明使用一种程序设计语言，一种不很适合大多数企业的语言。
J2EE的一个主要优势是，大多数J2EE开发商提供了操作系统可移植性。
微软的.NET平台构想是一个产品，而不是一个规范家族，带有用来定义互用性要点的规范。这种方法的住雅缺点是，如果限于Windows平台，那么为.NET平台编写的应用程序只能在.NET平台上运行。.NET平台有几个重要的优点：
· 开发应用程序的成本更低，因为可以使用标准的商务语言，并且可以编写设备独立的表示层逻辑。
· 运行应用程序的成本更低，因为可以使用商品硬件平台（成本是它们的Unix对手的1/5）。
· 伸缩的能力更大，被证明的可以支持客户端数是任何J2EET平台表明的可以支持的客户端数的10倍。
· 互用性更强，可以将工业标准电子协作内置到平台中。
这两个平台一个最有差别的特点是整个系统的可移植性。寻求的成本电子商务平台的公司可能会由于疏忽而忽视了微软公司提供的功能。电子商务总是需要高可靠性和出色的可收缩性。第一次，这些功能能够以基于Unix的解决方案的成本的一小部分就可以在商品硬件平台上获得。
术语表
· ADO.NET –用于访问数据层的.NET API。
· Application Center Server – 提供中间层负载平衡和一般群集（cluster farm）管理的.NET技术。
· Assembly - .NET平台中应用程序部署的单位。
· BizTalk Server – 在商务过程间，尤其是遗留的商务过程间提供结合方法的.NET技术。
· C# - 一种新的C++派生程序设计语言，在功能 、外观和感觉上与Java类似。
· CICS – 一种IBM大型机事务处理监视技术。
· COBOL – 一种主要的商务程序设计语言。
· COM+ - 设计用来支持商务组件的.NET中间层基础结构。
· Commerce Server -.NET电子商务架构。
· CORBA (Common Object Request Broker Architecture，公用对象请求代理体系结构) – 由OMG定义的最早的组件体系结构。
· Common Language Runtime – 对编译的IL语言提供支持的.NET运行时间。
· DB2 – 一种与 SQL Server竞争的关系型数据库产品。
· DCOM – 一般用来（不是专门用来）在.NET体系结构内与组件通信的微软协议。
· EBusiness（电子企业） - 一家在Internet上开展所有或重要的商务的公司。
· ECollaboration（电子协作） - 在Internet上进行的企业间的协作。
· ECommerce（电子商务） - 在Internet上进行的商务。
· Eiffel – 在某些企业中使用的一种重要的研究语言。
· EJB (Enterprise JavaBeans) – 为商务组件设计的J2EE中间层基础结构。
· Entity Beans（实体豆） - 一种EJB技术专用的组件模型，提供不同程度的状态管理。
· HIS (Host Integration Server) – 一种与IBM公司的大型机互用的.NET技术。
· HTML – 描述浏览器显示的工业标准。
· HTTP – 用于在Internet上进行通信的关于标准。
· IL (Intermediary Language，中间语言) - .NET平台使用的中间语言。
· IMS – 一种IBM大型机数据库技术。
· ISAS (Internet Security and Acceleration Server，Internet安全与加速服务器) – 提供防火墙保护和HTML页面缓存的.NET技术。
· ISV (Independent Software Vender，独立软件开发商)。
· J2EE - Java 2 Enterprise Edition（Java 2企业版）。
· JAAS (Java Authen
tication and Authorization Service，Java身份验证与授权服务) – 用于通信安全性的J2EE API。
· Java – 与J2EE关联的程序设计语言。
· Java Applets – 浏览器中用于下载和在客户端运行Java代码的打包技术。
· Java 2 Enterprise Edition（Java 2 企业版） - 一个描述Sun公司电子商务规范家族的通用术语。
· Java Byte Code – 在Java虚拟机内运行的中间语言。
· Java Connectors（Java连接器） - 用于插入不同的数据库技术的（程序员不可见的）J2EE API。
· Java Server Pages - J2EE技术，连同Java Servlets是用于表示层的程序设计模型。
· Java Servlets - J2EE技术，连同Java Server Pages是用于表示层的程序设计模型。
· Java Virtual Machine（Java虚拟机） - Java语言环境。
· JDBC (Java Database Connection，Java数据库连接) – 用于访问数据层的J2EE API。
· JMS (Java Message Service，Java消息服务) – 用于获取消息队列的J2EE API。
· JNDI (Java Naming and Directory Interface，Java命名与目录接口) – J2EE中使用的用于命名和定位具体示例的 API。
· JTS (Java Transaction Server，Java事务服务器) – 用于管理事务处理边界的J2EE API，主要被EJB自动事务处理边界管理代替。
· MS-DTC (Microsoft Distributed Transaction Coordinator，微软分布式事务协调器) –在分布式事务协调中，管理两阶段提交协议的.NET技术。
· MTS (Microsoft Transaction Server，微软事务服务器) – 最初的基于组件的中间层，设计用来支持具有高可收缩性的应用程序。
· .NET – 用于描述微软公司的电子商务平台的通用术语。
· .NET Building Block Services（.NET构件服务） - 帮助企业一起工作的协作服务。
· .NET Client Systems（.NET客户端系统）- .NET平台的子集，设计用来支持各种瘦客户端平台。
· .NET Enterprise Servers（.NET企业级服务器） - 一个可用于.NET平台的可选的企业级产品集合。
· .NET Framework（.NET架构） -.NET应用程序运行的整个基础结构。
· NLBS (Network Load Balancing Service，网络负载平衡服务) – 一种用于负载平衡和向表示层提供高可收缩性的.NET技术。
· Oracle – 一个与 SQL Server竞争的关系型数据库产品。
· OMG (Object Management Group，对象管理集团) –一个早期的工业协会，该协会定义了最初的CORBA规范。
· RMI/IIOP (Remote Method Invocation over Internet InterOrb Protocol，Internet InterOrb协议上的远程方法调用) – 用于与J2EE种基于CORBA协议的组件通信的协议。
· SOAP (Simple Object Access Protocol，简单对象访问协议) – 一个用于对方法请求打包的工业标准。
· SQLServer – 微软公司的高端数据库产品。
· TCP/IP – 一种推动Internet的低层通信协议。
· TPC-C – 一种以分布式订单输入系统为基础的工业标准基准，用于测量中间层/数据层的总吞吐量。
· tpmC (Transactions per Minute, as defined by C benchmark，由C基准定义的每分钟事务处理数) – 一个标准的测量由TPC-C基准定义的事务的方法。
· UDDI (Universal Description, Discovery, and Integration，通用描述、发现与集成) – 一组由uddi.org控制的工业标准，用来定义电子协作。
· uddi.org – 控制UDDI的协会。
· VisualBasic – 微软公司开发的一种流行的商务程序设计语言。
· Visual Studio.NET -.NET的程序设计环境。
· WebLogic – BEA公司的电子商务平台，是J2EE的一个子集。
· WebSphere – IBM公司的电子商务平台，是J2EE的一个子集
· Web Service（网络服务） - 一个可以通过SOAP协议随时支付的中间层商务组件。
· URL (Universal Resource Locator，通用资源定位符) – 一个标准的Internet地址。
· XML – 用于构建文本串的工业标准。
商标信息
Sun, Sun Microsystems, Java, JDBC, JavaBeans, Enterprise JavaBeans, JavaServer Pages, Java Naming and Directory Interface, Write Once, Run Anywhere都是Sun Micrososytems, Inc.的商标或注册商标。ObjectWatch是ObjectWatch, Inc.的注册商标。所有其他商标归其相应的公司所有。
作者简介
Roger Sessions是ObjectWatch, Inc.公司的首席执行官，该公司专门提供.NET平台和其他电子商务体系结构方面的体系结构层次的培训。他是世界上电子商务体系结构领域最重要的专家之一，著有5本书籍和大量的文章。他在全世界许多会议上发表过演讲。他使用CORBA，J2EE和.NET平台进行了大量的工作。他是阅读量很大、经常引起很大争议的《ObjectWatch通讯（ObjectWatch Newsletter）》的作者，该通讯现在可以在网上看到，地址：www.objectwatch.com。与Andrew Coupe一起，Roger Sessions是被高度关注的工作室Architecting Next Generating eCommerce Systems for.NET的共同作者。有关该工作室的信息，可以在网上获得： www.objectwatch.com。
致谢
非常感谢Dino Chiesa, Andrew Coupe, John Montgomery和Jacqueline Van Voris的认真审阅。感谢你们！
]