不论在这个专栏中还是在外界，我都经常思考一个问题，看起来多么奇怪啊，我已经在讨论JTA（它是J2EE这个小世界中的一个小角落）的WLDJ方面工作有两年之多了，JTA自身是开发团队为了向其业主尽快交付某些有价值的东西而需要的一个小部件。让我们正视这一点，您最近一次看到需求文档上说“我们需要23个实体bean、7个消息驱动bean和一个XML接口，所有这些必须是事务式的，因为这样的话我们就会在20年的运营成本上每年节约10％”是什么时候？

　　您更可能听到的是类似于这样的论调——“我们需要将人才备用流程自动化；每次我们雇用一名新员工，HR人员和高级经理都要花大约一天半的时间来完成必要的步骤。我们需要将招聘的时间削减到不超过一小时：去吧，在6个月时间内完成这项工作，预算为15万美元。”

　　很容易不切实际地将这些文章视为毫无价值，认为J2EE没什么用，整个世界上应该都是既不出售也不提供技术、只提供业务问题解决方案的“解决方案提供商”。认为“阿司匹林”是每个业务问题的万能药方，只需加水即可！

　　每个业务问题的万能解决方案
　　然而，不同于头痛的是，业务问题并不是孤立存在的。一个单独的痛点只不过是一个点。如果没有对您的解决方案（无论这个解决方案从纸面上看有多诱人）有一个更为整体的认识，您除了将今天的疼痛减轻为明天的偏头痛之外，什么也做不了。

　　这些实际情况使得行业要从一个更为广阔的角度来看待应用程序服务器的发展问题，以及应该提供什么样的基础架构供应商（BEA仍然是惟一的独立供应商）。Gartner谈到，应用程序平台套件(APS)作为下一代应用程序服务器，已经阐明APS可以为一个组织在跨应用程序生命周期方面节省高达22％的产品上市时间，对代价不菲的开发人员和架构师的使用则可节省50％。因此不要对这一点感到惊异——他们预测APS将成为本世纪头十年的主要购买产品。

　　那么，什么是APS呢？如果考虑一个普通的项目需求——通常需要一个前端接口，对一些其间并入了过程流自动化的现有业务系统的集成，以及放置定置逻辑的位置。“Do It Yourself”人员可能会将其视为一次购买应用程序服务器、门户UI框架、EAI总线和编码的行动。然而，Gartner确定，使用APS这种方法处理解决方案流可以节省开支，因为在一个真正的APS门户中，继承和开发基础架构都统一在一个编程模型和基础架构之中了，而在DIY情况下，必须花费精力来分别理解基础架构的动件，而且必须完成这些工作之后方可进行将它们统一到一起（利用您需要维护和理解的自定义代码）的开发工作。这些都完毕之后，理解了三种组件技术的三个子小组才能开始构建其整个解决方案的各个部分。

　　从这一点可以看出，为给定的业务问题提供解决方案的最有效措施是拥有一支团队，其中包含了业务级的分析员和开发人员，他们使用APS技术来指定和实现端对端的解决方案。无疑，我在某种程度上是这种观点的支持者（不像Gartner和其他分析员，他们也看到了这一点），能为BEA工作，我感到很自豪，对于这个重要且持续增长的应用程序开发方法，我们已经在技术上有了两年的领先，因而在业界得到了广泛的认同，当前我们是惟一一家拥有产品级质量的APS产品的公司（这就是说，在您考虑SOA、SODA、ISE、ESB和其他迅速涌现的技术之前，首先要承诺对旧有的stovepiped式世界提供新级别的灵活性）。

　　这与我目前读到的有关谁在“J2EE 应用程序服务器之战”中拥有最大的市场份额中的论调背道而驰——即使是在最好的情况下，市场份额都以其主观性而臭名昭著，因为很多供应商在单独产品的间隔期并不发布跟踪销售数据。有些分析家说BEA仍处于领先位置，有些则说它已经滑落到了第二位，不管怎么说，有关这个问题的一段抨击之词会占据栏目的很大一段——不管事实真相如何，没有什么比得上一个爆炸性的标题。当您将APS方法的整个行业的进展与这场辩论中所比较的数据的不透明本质相加，您的感觉就是市场（总之，很快对市场进行了重新定义）上可能发生、也可能没有发生变化。保持头版！我想现在谈论胜利或者失败还为时尚早。

　　那么，回到应用程序服务器、J2EE、事务，不要再提这些文章了：是因为它们太小，不重要？不是这样。因为所有业务问题的最复杂的技术解决方案必须建立在一个坚实的基础之上，因此基础级的支撑仍然很重要，尽管使用APS可能就意味着在每个项目组中，所需的熟悉J2EE细节的人员数量可以减少。另外，正如混沌学爱好者所熟悉的，今天热带雨林一只蝴蝶翅膀的扇动可以引起明天城市中的一场风暴。

　　但在有关J2EE应用程序服务器市场作为基础架构行业成功的晴雨表这一点上，我并不知道哪个人试图通过与蝴蝶交谈来改变天气。