Java 2企业版(J2EE)
VS
.NET平台
关于电子企业的两种设想
Roger Sessions
ObjectWatch, Inc.
March 28, 2001 6:59 AM
本白皮书版权归德克萨斯奥斯汀ObjectWatch有限责任公司所有。保留所有权利。禁止进行未授权的复制或再次发布。要获得复制或再次发布许可，请联系：roger@objectwatch.com。
.NET Framework与Visual Studio.NET. 8
绪论
一个没有赢利计划的电子商务站点就像一辆没有汽油的汽车。它看起来可能会很漂亮。可能会给人留下深刻印象。它可能会让你付出很大的代价。但最终，它哪里也不能去。
去年，人们对这个教训有了深刻的理解。电子企业（EBusiness）一个接一个地破产，但这并不是由于缺少客户，而是由于缺少在这些客户上赢利的计划
在即将到来的一年中，赢利将会像过去一样非常重要。但是，赢利的模式将从基于竞争转变为基于合作。用反话来讲，那就是最具竞争力的公司将是那些不必为竞争担心，而将主要精力集中在协作上的公司。
对于商务而言，橄榄球比喻（“将你的对手压扁！”）已经过去了。未来的商务比喻是交响乐团。整体协作的成功将决定每个单位的成功。
在电子商务中，协作意味着通过合作关系开展销售活动。这意味着利润共享。利润共享迫使我们在协作的每个步骤对盈利模式进行仔细检查。我们需要以最可能低的成本，让技术在协作环境的每个步骤中为电子商务服务。
今天，对于电子企业和电子企业协作有两种技术设想。一种是微软公司的设想，整体称为.NET平台。另一种是Sun公司的设想，整体称为Java 2企业版( Enterprise Edition，J2EE)。
在该白皮书中，笔者将对.NET平台和J2EE进行比较。笔者将会把重点放在笔者认为在未来的5年内将会对电子企业起推动作用的主要问题：协作与盈利能力上。笔者将讨论这两个平台的技术细节，但只讨论那些影响协作或盈利能力的细节。
需要指出的是，J2EE是一种规范，而不是一种产品。许多开发商在产品中实施了这种规范。最重要的两个J2EE开发商/产品是IBM'公司的WebSphere和BEA公司的WebLogic。根据Cutter Consulting[1]公司最近的研究报告，这两个开发商占据了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层电子商务体系结构
表示层
商务层
数据库层
HTTP
HTML
专利组件协议
数据库访问API
图1中所示的每层都有一个用途，一种体系结构，一个API。在本节中，笔者将给出一般的体系结构概述。在接下来的两节中，笔者将分析J2EE和.NET平台的差别
表示层负责与客户端的工作。利用MoneyBroker应用程序，这一层与基于浏览器的支付瘦客户端一起工作。
表示层接受来自网络浏览器的HTTP请求，然后返回一个浏览器可以显示的HTMl页面。不同的浏览器有不同的显示能力，因此表示层必须常常适应特定的浏览器（或其他瘦客户端设备）的HTML。
大量的商务逻辑在商务层内实施。对于MoneyBroker，包括保留客户帐户的逻辑，以及在支付帐单时转帐的逻辑。由于商务层位于表示层和数据库层之间，通常被称为中间层。
表示层通过一种方法传输协议，与商务层进行通信。对于.NET平台，这个协议通常是DCOM或SOAP。对于J2EE，这个协议是RMI/IIOP。
在J2EE和.NET平台中，商务逻辑通常被打包成了组件。一个组件就是通过详细定义的接口，用来进行交互的商务逻辑。
组件常常与对象（利用这项技术，它们通常有历史关系，但在其他方面有很少的共享内容）混淆。特别是，控制面向对象的程序设计和组件打包规则有很大的不同。笔者最近讨论了这两种技术的区别[2]，因此将不在此对此重新讨论。
商务逻辑通常需要昂贵的资源，如数据库连接，线程，TCP/IP连接，和消息队列连接。这些资源需求通常使得在任何时刻支持大量的客户端都变得很困难，而这则是大多数电子商务应用的一个需求。
为了解决这个问题，J2EE和.NET架构的商务层都包括一个复杂的、支持客户端中间资源共享的中间层结构。这种结构对于支持大量的客户端，获得高系统吞吐量是至关重要的。在J2EE中，这个中间层结构被称为Enterprise JavaBeans (EJB)。在.NET架构中，则被称为COM+。
第三层是数据库层，实际数据存储在该层中。对于MoneyBroker系统，数据库层用来存储客户的帐户信息和帐单支付记录。
尽管大多数大型企业还有利用驻留在数据层中的数据库的内部应用程序（不是通过电子商务体系结构），商务层仍是数据层的主要客户。商务层和数据层之间的通信使用特定的API进行：.NET架构使用ADO.NET，J2EE使用JDBC。
现在，让我们对这两种技术进行更详细的分析。
