可伸缩性
可伸缩性是指添加更多工作量的能力。一般来说，附加的工作量是客户的增加引起的。可伸缩性是一个复杂的问题，笔者已经在几篇已经可以得到的文章中对此进行了深入探讨[1]。未来简化这个讨论，笔者将在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网站[2]得到。
在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系统中，哪一个最能代表
