语言

在语言方面，选择很简单。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[1]。

在CORBA体系结构中创建任何新代码都是一个很有问题地策略。CORBA是20世纪90年代受人喜爱地体系结构，但现在已经不再使用了。据笔者所了解，没有一个CORBA开发商（除IONA外）在CORBA上盈利，并且没有一个开发商（包括IONA在内）在继续向该技术投资。底线是如果有人希望以Java以外的任何一种语言进行开发，那么J2EE是不正确的平台选择。

当前某些非Java公司正在考虑在Java上进行重新标准化的可能性。要实现这一点，有三种可能的方法：

• 对现有职员进行再培训
• 雇佣新职员，并尽可能地替换现有职员
• 外包

再培训可能是最昂贵的选择。以我的经验，有很大的管理费用与将传统的程序员培训成精通面向对象的Java程序员有关。这是Gartner集团最近的研究的结果，得出得结论是将一个COBOL程序员培训成Java程序员，每人大约需花费6万美元[2]。 笔者相信，对于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的解决方案的成本的一小部分就可以在商品硬件平台上获得。