那么，什么是WebLogic呢？

　　瞟一眼我的笔记本电脑，告诉我它是一个32.3MB 的JAR文件，解开后是大约73MB的Java程序。于是，将73MB除以每个CPU价格就可以算出许可证的费用，并可得到产品的价值。这听起来像是一个可笑的算法，但并非完全不可行。因此，下载我最喜欢的开源替代产品，看一下JAR文件大小，大约是66MB。既然其许可证费用基本上等于零，并而且有同样数量的“产品”，那你还等什么呢？选择是显而易见的！

　　显然，对任何软件产品的此类静态分析方法不会产生非常有意义的结果。开源无疑是生成大批代码的很好机制，而且从无私的开发者那里得到软件显然要比从被雇佣的开发团队那里购买其成果要便宜得多。

　　这个逻辑肯定存在一些错误...否则，为什么只销售基础架构许可证的BEA Systems会拥有超过30亿美元的市场，而且为什么（且不管所有与之相反的论调）开源应用程序服务器没有横行于全球的关键任务环境？

　　除了构成软件的代码行之外，软件显然还有内在价值。

　　那么，它受到支持了吗？BEA向客户提供24x7的关键任务支持。为客户提供保证，如果他们的关键系统失效，会有技术人员随时守候以诊断问题，无论这些问题是在中间件层内部或是外部，而且他们将修复这些存在于内部的问题。显然，对于像银行这样的组织，雇佣足够多的、有精深技术的员工来24*7地诊断任意问题，这是不划算的，这一点非常重要。

　　在需要时（能保证供应商的工程师根据需要在线解决问题）因缺乏可用产品供应商而产生瓶颈，这是技术辅助业务有效运营必不可少的一部分。这里纯开源软件出现了一个问题：开发是基于热心社区这样一个临时基础上完成的。当他们的软件用户遇到问题时，这些热心人显然不会或者不愿意停下自己的事业。因此，那些使用了开源基础架构的组织必须确保有内部资源来提供这一级别的支持。这样做不仅不划算（如上所述），而且熟练的系统开发人员实际上非常稀缺，但只有最熟练的开发人员才能应付这类任务。作为Microsoft的低水平技能的替代品，过去几年中人们一直转向简单的Enterprise Java 编程。更好的方式是通过业务关系来巩固业务，而不是依赖一组高价的技术专家。

生活在对公认事物的永恒恐惧之中

　　然而，所有这些都说明，软件支持是除许可证费用之外的重复收费，因此，虽然由技术专家业务带来的可用性和基础为使用无许可证的基础架构软件提供了很多理由，但它不可能是完美的，因为尽管出现了为开源软件基础架构提供产品服务的公司，但是关键任务应用程序还是没有明显向开源软件平台迁移。

　　我相信这个谜语的答案在于支持，但不是传统产品支持合同下提供的那类产品支持。这里我再回头描述一下我的意思...

　　如果看一下典型产品系统的软件架构，就会看到许多不断移动的部分。典型情况下，这些系统由一组业务组件构成，这些组件接收准备处理的消息（通常从输入可靠队列，或者从面向终端用户的应用程序）。处理的典型构成如下：应用一些业务规则（顺便提一句，这就是该系统的主要价值！），然后更新一个或多个数据库并潜在地发送一些更可靠的消息。通常，这些消息代表大量业务价值流（对银行是钱，对制造商是库存，对物流公司是出货）。因为这些东西的价值，需要确保每个消息只处理一次，而且一旦处理过，其处理结果不得丢失并且在查看时是一致的。提供保证通常是基础架构的任务（通常是事务管理器）。毕竟，从业务角度来看，应用程序的价值是业务规则：业务只假设技术正常工作。

　　为了将该架构引入到具体实例领域，让我们想像传入的消息在MQ Series队列中到达，应用程序数据保存在Oracle数据库中，且客户参考信息（可不断更新）保存在Sybase中。

　　我们的基础架构软件不只是本身不带瑕疵地工作，而且到MQ、Oracle和Sybase的接口也必须正常工作。

　　好了，你说很好。作为开发人员，将它投入产品之前，我将端到端地建立和测试该应用程序，然后就会知道它可以运行。开源应用服务器和WebLogic之间的区别是什么呢？事实证明，它们的区别非常巨大...想像一下你的测试计划。必须包含所有业务用例以确保它们成功完成。必须包含业务数据中的所有边缘用例以确保正确地处理边缘问题和错误。因此，现在我们有了测试计划，它将给我提供适度的信心：应用程序满足了业务需求。我们完成了，对吗？是的，如果我们在使用WebLogic以及数据库和MQSeries的受支持版本。您知道BEA已经从基础架构观点对这些进行过测试并且它都是可以工作的，因为文档上就是这么说的(http://e-docs.bea.com/platform/suppconfigs/ configs81/81_over/supported_db.html#1129093)。

　　如果使用没有针对外部系统进行过严格验证的基础架构平台，您就需要自己执行测试。但是，我们之前没有做过测试吗？对，没有。没有从基础架构的角度进行测试。假定我们需要对三个资源进行事务性访问，就需要测试这三个事务都能在成功的情况下提交工作，而且在失败的情况下能够回滚，这些我们已经在应用程序级做过测试了，但是我们还需要对下面几种情况进行测试：是否准备了{MQSeries|Sybase|Oracle}失败时回滚该事务；是否在成功准备之后{Sybase|Oracle|MQSeries}出现失败，但是在进行记录之前事务已正确回滚；是否{Oracle|Sybase|MQSeries}已进行了准备并且在事务日志之后发生失败，然后在恢复中正确地向前回滚。这是一个相当大的测试工作。而且如果改变了这些外部系统其中一个的版本，就至少得再一次运行这些测试的一个子集。这显然非常消耗时间，而且这还没有把事务处理生命周期期间，在不同点模拟失败的技术复杂度包含在内。这给项目计划增加了许多工作，或者说给开发引入了许多风险，您可以简单地选择假定这些东西正常工作，也就是假设所有这些测试都通过。但如果它们没有通过会怎样呢？当然，你可以求助于任何可能从开源社区获得的开发人员支持，但如果你的问题只是针对特定Sybase版本，最好期望理解这些代码的那些人也能拿到同一个版本，而且他们有时间再次生产并修复你的问题。但是别介意，这时你可访问资源，你可自己解决这些问题！如果是那样的话，祝你好运！

　　这些问题非常难以跟踪并且解决起来很复杂。这真的是老板希望你花时间处理的事情吗？如果不相信我，看一下WebLogic提供的一些围绕不同数据库驱动器实现问题的设置，你会想象着发现并修复其中一个(http://e-docs.bea.com/wls/docs81/jta/thirdpartytx.html#1038034)吗？更不要提在你开始引入像Oracle RAC这样的环境时发生的事情了，你认为测试和调试以获得WebLogic Server手册中的结论需要多长时间呢？

　　此类影响还将推波助澜：如果真的在生产系统中遇到问题，不仅是你要找工程师，还有……等等类似事情。按我们前面谈到的方法，他们也需要能对再次生产和修复这些问题所必需的数据库和外部资源进行访问，而且还要拥有这方面的经验。

　　对在开源框架上投资这种级别测试（而不是只是允诺处理生产问题）的任何组织而言，这都会是有关时间、精力和金钱的重大承诺。那么回报是什么呢？如果这个虚构的组织花时间在开源中测试并对开源产品进行修复，谁来为此买单呢？每个人都会从他们的努力之中得到感谢和好处，但是如何表示他们的感激呢？或者这个组织可能自己进行修复，并向那些需要修复能给他们带来的额外保障的终端用户收费。但是这难道不是一种软件许可证吗？！

　　值得一提的是，我所了解的所有开源应用服务器并不配备功能完整的事务管理器。我怀疑这次讨论中提出的这类问题可能印证了这一点：事务管理器，像所有其他软件一样，毕竟只是代码...

结束语

　　那么来做个总结吧，开源对于生成代码来说是一个绝妙的主意，世界上很多东西都运行在开源之上，每次你搜索用的google就运行在Linux上，很大一部分J2EE Web应用程序运行在Struts上，大部分Java运行在Log4j 、XMLBeans和Xerces等等之上，越来越多的应用程序运行在开源数据库上。但是所有这些开源项目都有两个共同点，首先，他们与有限数量的稳定外部系统交互：Linux与硬件和BIOS（它们变更的频率有多高呢？！），Struts与稳定和成熟的servlet API打交道，其余的只与Java系统本身交互。其次，除Linux和数据库引擎之外（它们都是众所周知的系统实现，其系统需求已经定义了10多年了，因此非常稳定），它们都是面向开发人员的工具包，但它们不处于事务处理的关键路径上。应用程序基础架构需要与相对无限的外部系统、队列、数据库、集群等连接，而且在管理事务关键路径时按照定义具有最大价值。

　　出于这些原因，我认为开源应用服务器将继续支持低容量、低风险的系统，它们的许可版本将继续使操作人员和业务所有者能够放心，因为他们知道这些软件一开始就设计为预测和管理意外事件。

关于 Peter Holditch

　　Peter Holditch于1996年9月作为北欧专业服务组织的一名顾问加入BEA。他现在在英国担任售前架构师。Peter拥有伯明翰大学的电子和计算机工程学位。工作之余，他喜欢做家具、酿啤酒和享受漫长而炎热的英国夏日。可通过peter.holditch@bea.com联系Peter。